【失敗プロジェクトから学ぶ】テスト工数超過の真実：隠れた原因を特定しコストを最適化する戦略
プロジェクトマネジメントにおいて、テスト工程はプロジェクト成功の鍵を握る重要なフェーズです。
しかし、計画段階での見積もりの甘さや、単体テストでの不十分な分析が原因で、テスト工数が大幅に超過する事例が後を絶ちません。
本記事では、大手通信会社のシステム開発プロジェクトを題材に、初心者PMが直面する典型的な課題を深掘りします。
予期せぬバグの多発やリソース不足による遅延といった問題に対し、どのような原因追求と解決策が効果的であったのかを実例を基に解説。
さらに、リスク管理や事前対策の重要性についても触れ、テスト工数を最適化するための戦略を提案します。
初心者PMが陥りやすい落とし穴を回避し、プロジェクトを成功に導く実践的な方法論をお届けします。
初心者PMが陥りやすい失敗
1. 要件変更への対応遅れ
クライアントからの要件変更に迅速に対応できず、結果としてテスト工程にしわ寄せが来るケース。
解決策：要件変更時には、影響範囲を即座に分析し、計画を見直す柔軟性を持つ。
2. テスト範囲の過小評価
テスト範囲を狭く見積もり、重要なバグを見落とすことがある。
解決策：包括的なテスト計画を立て、必要に応じて範囲を見直す。
3. リソース管理の不備
テスト要員のスキルや経験を考慮せずに割り当てを行い、効率が低下するケース。
解決策：各メンバーの強みを活かしたリソース配分を心掛ける。
4. テスト自動化の過信
テスト自動化ツールに過度な期待を寄せ、人手による確認を怠る。
解決策：自動化と手動テストのバランスを適切に取る。
5. リスク管理の軽視
テスト工程でのリスクを軽視し、問題発生時に迅速な対応ができない。
解決策：事前にリスクを洗い出し、対応策を準備しておく。
プロジェクトの状況
1. プロジェクトのスコープと体制
顧客は大手出版会社。
顧客の情報システム部で新規構開発を実施。
情報システム部の窓口は木村。
プロジェクトオーナーは情報システム部の山田。
システム化スコープは受注管理、出稿管理、営業管理。
中堅SierのA社が開発ベンダーとして参画。
A社は全開発工程の成果物の納品、システムリリースの責任を負う。
A社の開発体制は業務チーム、基盤チーム、テストチーム、管理チームで構成。
A社のPMは佐藤（初心者PM）。
2. プロジェクト目標
品質目標：100%の不具合修正
スケジュール目標：予定通りのリリース
コスト目標：予算内でのシステム完成
3. プロジェクトの進捗状況
現在のプロジェクトは結合テスト工程である。
所要期間の50%を消化した時点で、想定外の不具合が多発している。
テストの実行とプログラムの修正に計画以上の工数が発生している。
PM佐藤は顧客の木村に、リリースの延期を依頼したが、
『品質基準をクリアするように工夫して欲しい。』
しかし、佐藤は状況を把握しているが、具体的な問題や解決策が分からない状態である。
問題の設定
今回の問題は、プロジェクトで起きた事象を、さまざまなプロジェクト情報から考え、『コストマネジメント領域』で発生した問題として取り扱いました。
また、今回のプロジェクトの問題をこのように設定しました。
”想定外の不具合による結合テストの工数超過”
また、この問題を放置することで、コスト目標である予算内でのシステム完成を逸脱する恐れがありました。
原因の追求
原因を特定するためには関係者へのヒアリングが重要である。
しかし、闇雲に関係者から聞き取りを行っても時間の無駄であることから原因の仮説を3つ立てた。
1. 原因の仮説と検証
仮説1
結合テストの工数が間違っていた。
仮説の検証
有識者が算出したテスト工数と同じであったか？
【 検証結果 】
有識者の算出したテスト工数と同じであった。
仮説2
総合テストの所要期間が間違っていた。
仮説の検証
有識者が算出した所要期間と同じであったか？
【 検証結果 】
有識者の算出した所要期間と近い数字であった。
仮説3
単体テストのバグ分析が行われなかった。
仮説の検証
単体テストでテスト密度やバグ密度の組み合わせ分析を行ったか？
【 検証結果 】
密度分析は行わずテスト消化数と修正数をテスト管理していた。
2. 今回の問題の原因
単体テストのバグ分析が行われなかった。
また、探偵テストで発生した不具合の傾向を分析せず、結合テストを進めていた。
解決策
私は3つの解決策を準備しました。
解決策A:
単体テストをやり直す
この解決策では、結合テストを一時中断し、単体テスト工程に立ち戻ります。各モジュールのバグ密度やテスト密度を詳細に分析し、不具合の発生源を特定します。
その上で、必要に応じて単体テストケースを見直し、不具合の再発防止策を徹底的に講じます。
これにより、結合テストに移行する際の品質を保証し、後工程でのリスクを大幅に削減します。
利点
バグの発生源を徹底的に洗い出し、品質を根本から改善。
結合テスト以降の工程での手戻りを最小化。
欠点
スケジュールの大幅な遅延が予測される。
解決策B:
技術力の高いメンバーを増員する
この解決策では、技術力の高いエンジニアを新たに投入し、現在のチームを強化します。
具体的には、単体テストで検出された不具合を迅速に分析し、不具合の原因や傾向を特定するプロセスを加速させます。
同時に、結合テスト項目の見直しと改善を進め、品質を向上させながら計画されたスケジュール内でプロジェクトを進行します。
利点
スケジュール遅延を最小限に抑えながら品質を向上。
チーム全体の生産性向上が期待できる。
欠点
技術力の高いメンバーを確保するための追加コストが発生。
解決策C:
スケジュールの延期と増員を組み合わせる
解決策Bの基盤に加えて、スケジュールの延期も提案します。
このアプローチでは、技術力の高いメンバーの増員を行いつつ、結合テストおよび総合テスト工程のスケジュールを適切に延長します。
これにより、品質向上を図りながら、計画を現実的な範囲で調整します。
利点
品質を徹底的に改善できる。
チーム全体の負担を軽減し、効率的な作業が可能。
欠点
顧客の了承を得る必要があり、調整に時間がかかる可能性。
現在のプロジェクトの状況とこれらの解決策の案をPO山田へ提言しました。
PO山田の意向
品質について：単体テストの分析による結合テスト項目の精度を上げることに問題なし。
リリース日について：リリース日の延期はできない。
このことから、解決策Bを採用しました。
また、この解決策を施行することで、開発ベンダーA社は技術力の高いメンバーを増員することにより、計画工数を30%超過することになりました。
教訓（リスク管理表へ整理）
今回の原因は、流用を前提にしていたことから調査が不十分ということであった。
このような事態を、事前に回避することはできる。
それは、プロジェクト計画の段階でこれらを実施することで防止できるのである。
テスト密度とバグ密度の分析及び、不具合の原因や傾向の調査実施を方針とする。
単体テスト工程で不具合の分析から原因と傾向を把握して結合テストの対策を検討する。
まとめ
テスト工数の超過や予期せぬバグの発生は、プロジェクト全体の遅延や品質低下につながります。
初心者PMは、要件定義の徹底、詳細なテスト計画の策定、そしてコミュニケーションの強化を意識することで、これらの課題を克服できます。
また、陥りやすい失敗例を事前に把握し、同じ過ちを繰り返さないプロセス構築が重要です。
プロジェクト管理に関する疑問やお悩みはありませんか？
iPM naviのLINE公式アカウントで、今すぐ気軽に質問できます！
あなたに役立つアドバイスが届きます✨
👉 ［LINEで質問を簡単受付！］
【次のアクション】
成功と失敗を学んだら、シミュレーターで自己スキルをチェックしましょう！
👉 ［スキルをシミュレーションする］
#コスト
#テスト