エンジニアが現場で使えるPMOの失敗回避術第4回

【テストエンジニア編】「テストは最後で良いよね」と言われる現場が、なぜ品質と納期の両方を失いやすいのか

第4回の今回は、テスト工程が後ろに追いやられがちな体制の落とし穴と、PMOがスケジュールの段階でテストを「最初から組み込む」ための打ち手について解説します。

6:30

はじめに

「エンジニア」とひと口に言っても、ソフトウェア、フロントエンド、サーバーなど、その役割によって現場で直面するトラブルはさまざまです。
本連載では、PMO(Project Management Office)として多くの現場を経験してきた甲州が、それぞれのエンジニアが抱える課題の回避策を深掘りしていきます。

第4回は、プログラマーが生み出したコードの品質を担保する「テストエンジニア」に焦点を当てます。彼らの現場では、期待通りに動かない「バグの発見」という責務と、開発の遅れのしわ寄せによる「テスト期間の短縮」という、相反する課題が常に隣り合わせです。

本記事は、単にテストケースを実行する立場から一歩進み、テスト戦略の立案から実行、そしてプロジェクト全体に影響を及ぼす「管理」の視点を持ちたい方にぜひ読んでいただきたい内容です。

テストエンジニアは、テスト工程全体を任され、プロジェクトの品質を左右するキーパーソンとしてキャリアアップが可能です。テスト工程の管理を担当するシニアテストエンジニアなどの経験豊富な方には、すぐに役立てられる実践的な内容となっています。

また、現在はテスト実行のみを行っている方も、テスト工程がプロジェクト全体の品質に果たす真の位置づけと、キャリアアップへの関連性を理解する一助になるはずです。

品質と納期、その両立をどう図るのか。一緒にみていきましょう。

プロジェクト全体におけるテスト工程は
重要度が低く扱われリリース後に炎上する

まず紹介したいのは、テスト工程の扱いが軽視されることによって引き起こされた2つの失敗事例です。

1つ目は、
要件定義や設計工程で、想定していた要件が決まらず時間を要し、できると思っていた技術的内容が「できない」ことが発覚し、設計が思うように進まなかったパターンです。
要件定義・設計工程が伸びるとプロジェクト全体に影響を及ぼします。しかし、予定していたリリース日は変更せずに、テスト工程の期間を短くすることになりました。
具体的には、実行するテスト件数を少なくし、最低限のテストのみを実施することでリリースに間に合わせようと調整したのです。
結果、このプロジェクトではシステムリリース後に多くの不具合が見つかり、改修作業に翻弄されることになってしまいました。

2つ目は、
要件定義、設計、開発工程は予定通り進行していましたが、テスト工程に入ると多くの不具合が発生し、改修してはテストを行い、また別の不具合が検出される、これを繰り返してしまったパターンです。
予定通りのリリース日を迎えたものの、システムリリース後も不具合の検出は止まること無く出続け、最終的には、システムを一旦停止し、3ヶ月後に改めてリリースし直すこととなってしまいました。

なぜプロジェクトは炎上へと向かうのか？ベンダーと発注者が抱える「3つの自己都合」

先の失敗事例を見ると、「なぜもっと早く手を打たなかったのか」と感じるかもしれません。しかし、実際にプロジェクトの渦中では、関係者それぞれに「このまま行けるはず」「今は動きたくない」と感じさせてしまう理由があります。品質リスクを軽視し、問題の先送りを許してしまう、ベンダー側と発注者側、それぞれの都合を見ていきましょう。

システムベンダー側の「楽観的な見積もりと先送り」

要件定義や設計工程が伸びた際、システムベンダーはテスト工程への影響を軽視しがちです。彼らは以下のように考えている可能性があります。

「設計が多少伸びてもテスト自体はやることは一緒だし、テストケースも変更後のものを作るのだから、テスト期間は変えなくて大丈夫だろう」
「数カ月先の工程を今から伸ばす話をしても仕方がない。問題が顕在化したら、そのときに相談すれば問題ないだろう」
「テスト工程が膨らんでも、最悪、残業でカバーしたり、増員すればなんとかなるだろう」

つまり、スケジュールの遅延はテスト工程で人員や工数を投入して吸収できるという、楽観的かつ短絡的な考え方が働いているのです。

発注者(事業会社)側の「計画変更への抵抗」

一方、発注者側は、計画変更に伴う社内手続きや説明の煩雑さから、スケジュール変更を避けようとします。

「もともとこの計画で社内承認を取っているので、変更するには結構な説明資料を作らなくてはならない」
「変更した部分は当初予定していた部分から大きく変わるわけではないし、まだ何カ月もあるのだから、システムベンダー側がリカバリしてくれるだろう」
「システムベンダー側は発生している不具合もその都度改修してくれているから、このまま行けば問題はなさそうだ」

当初の計画を信じたい、あるいは問題から目を逸らしたいという心理が、品質リスクの議論を遠ざけていると言えるでしょう。

どちらにも共通する「面倒を避けたい」という心理

ベンダー側、発注者側どちらにも共通しているのが「できるだけ計画しているスケジュールを変更せずに進めたい」という強い心理です。

スケジュール変更を行うことで、自分が「ダメ」「能力がない」という評価につながるのを避けたい
変更するための説明や手続きに多くの時間を要するため、できるだけ防ぎたい

この「できるだけ面倒なことはせずに、今のままでなんとか乗り切りたい」という考えが、炎上の可能性をどんどん高めます。
初めは小さな懸念でしかなかったものが、リリース日が近づくにつれて無視できないリスクとなり、話すタイミングを失います。結果としてなし崩し的にリリース日を迎え、前述の事例のようにシステムリリース後に炎上してしまうのです。

どうすれば炎上を回避できるのか？
QCDのバランス調整というPMOの視点

前述したプロジェクトの失敗事例を回避するために、どのような打ち手が必要だったのでしょうか。回避策の1つに、システムベンダーと発注者(事業会社)の双方が、品質(Q)、費用(C)、納期(D)の三要素のバランスを客観的に管理する「PMOの視点」を持つことが挙げられます。

１つ目のプロジェクト例(要件・設計の遅延でテスト期間が短縮されたケース)では、設計工程が延伸した段階で、テスト工程への影響の可能性に関してプロジェクト全体で共有し、議論することが重要でした。

プロジェクトの内容ごとに調整は異なりますが、大原則として「要件定義、設計工程を伸ばしたら、同じ期間だけテスト工程も伸ばす必要がある」と考えるべきです。
もちろん、調整や工夫によってリスクを最小限に抑えて進めるプロジェクトもありますが、まずは機械的にマスタースケジュールを見直し、全体に影響を及ぼす可能性があることを共有することが第一歩です。
また、プロジェクトの途中段階で計画の妥当性や品質リスクを判断するための「マイルストーン」をいくつか設定します。

成功するプロジェクトでは計画段階でプロジェクト途中にマイルストーンを設けることがほとんどですが、失敗するプロジェクトはこれを設けないことが多く見受けられます。

２つ目のプロジェクト例(テスト中に不具合が多発し、リリース後に炎上したケース)では「モグラたたき」状態を止めることが重要です。
一旦プロジェクトを停止してテスト結果や不具合内容を分析し、根本的な原因を深掘りします。その結果、特定のメンバーが対応した開発部分の問題や機能の影響範囲の把握不足、類似の不具合への横展開不足など、多くの対策が見えてくるはずです。

根本的な問題に対して手を打つためには、通常のテスト工程とは別に「強化テスト」の期間を設ける必要があるかもしれません。また、品質に不安がある状態で無理にリリース日に合わせるのではなく、リリース日をずらす検討も必要になります。

多くのプロジェクトで「リリース日(D)は絶対に動かせない」と思われがちですが、プロジェクト状況や優先すべき内容を相談することで、意外と調整できることは多いです。

PMOの視点とは、品質(Q)、費用(C)、納期(D)のトレードオフを明確にし、プロジェクトの目的達成に最適なバランスを取ることです。

調整の議論で検討すべき選択肢の例は以下の通りです。