テスト計画のミスでスケジュール遅延

お疲れ様です、ゆーろー@常駐しないPMOです。

わたしがプロコンサルとして参加しているiPM naviのコラムをご紹介します。

今回のコラムは大手コンサルファームで活躍している”えのき”さんが、実際にPMアドバイザーで参画した炎上プロジェクトの実例となります。

---

プロジェクト計画では、スケジュール作成します。

しかし、テストの難易度からテスト日数の算出を行わないPMがいます❗️

計画ミスにより、スケジュールが遅延してプロジェクトが破綻するケースがあります。

なぜ、このようなトラブルが起こるのでしょうか？

それはテストの難易度を理解するアプローチに不備があるからです。

こんにちは、プロコンサルのOSAMUです。

私が参加しているiPMでは、PM初心者のスキルアップやDX時代に適応したいPMのリスキリングのサポートとして、iPM TRAININGを運営しています。

その中のオプションサービスとして、『トラブルプロジェクトの実例から学ぶ失敗しないマネジメント』をお伝えしています。

このコラムでは、読者のあなたへ、実際に私がPMアドバイザーとして参画し解決した、トラブルプロジェクトの実例を紹介します。

今回は、『テスト計画のミスでスケジュール遅延』というテーマです。

あなたのマネジメント業務で活用できるように、解決までのアプロローチを以下の順番でお伝えします。

・プロジェクトの状況

・問題の設定

・原因追求

・解決策

・教訓（リスク管理表へ整理）

👍 このコラムは

むずかしさ　：
★★☆☆☆（PM初級者向け）

ボリューム　：
★★★☆☆(5分-8分で読める)

気付き学び　：
★★★★★(スケジュールのミスによるリスク)

お役立ち　　：
★★★★★(スケジュール管理)

仕事の実用性：
★★☆☆☆（有識者のサポートが必要かな）

もっとOSAMUさんのコラムを読みたい方はiPM naviへメンバー登録（無料）してください。登録は（こちら）

---

プロジェクトの状況

1.プロジェクトのスコープと体制

・顧客は大手エンターテーメント会社。

・顧客の情報システム部で新規構開発を実施。

・情報システム部の窓口は木村。

・プロジェクトオーナーは情報システム部の山田。

・システム化スコープはタレント管理、給与管理、営業管理。

・中堅SierのA社が開発ベンダーとして参画。

・A社は全開発工程の成果物の納品、システムリリースの責任を請け負う。

・A社の開発体制は業務チーム、基盤チーム、テストチーム、管理チームで構成。

・A社のPMは佐藤（初心者PM）

2.プロジェクト目標

品質目標：100%の不具合修正

スケジュール目標：予定通りのリリース

コスト目標：予算内でのシステム完成

3.プロジェクトの進捗状況

現在、プロジェクトは結テスト工程であり、所要期間の50%が経過した。

結合テスト計画のテスト数・作業工数・割当人数・所要期間を有識者のレビューで合格をもらったにも関わらず、大幅に進捗が遅延した。

そのため、顧客の情報システム部 木村にリリース延期を依頼した。

しかし、木村から

「計画が正しいにも関わらず遅延の原因が分からない。」

「そんな状況で、リリースの延期は認められない。」

「当初の計画通り進めて欲しい。」

と一蹴された。

佐藤は状況を把握しているが、具体的な問題や解決策が分からない状態である。

**守秘義務により企業名・団体名・個人名等は架空名称となります。

---

問題の設定

*私がアドバイザーとして、プロジェクトに参画して解決させた経緯のスタートです。

問題を考える場合は、どのマネジメント領域で発生したかを分類することで、後続のアプローチがスムーズに行え、得られた結果の根拠も説得力を持つ。

そこで、今回の問題は、プロジェクトで起きた事象を、様々なプロジェクト情報から考えをもとに考たところ『スケジュールマネージメント領域』で発生した問題として取り扱った。

また、今回のプロジェクトの問題をこのように設定した。

”テスト項目ごとの実行計画のミスによるスケジュール遅延”

また、この問題を放置することで、スケジュール目標であるリリース日を逸脱する恐れがあった。

様々なプロジェクト情報
プロジェクト計画書、レービュー結果報告書、要求変更書、レビュー対象物、作業実績情報、作業範囲記述書、要件定義書、成果物一覧、課題問題整理表、役割分担表、要員の選定根拠、勤務表、成果物、関係者からのヒアリング結果

---

原因の追求

原因を特定するためには関係者へのヒアリングが重要である。

しかし、闇雲に関係者から聞き取りを行っても時間の無駄であることから原因の仮説を3つ立てた。

1.原因の仮説と検証

仮説1
想定外の不具合が多く発生していた。

【 仮説の検証 】
バグ管理表に想定外の不具合の記載はなかったか？

【 検証結果 】
想定外の不具合の記載はなかった。

仮説2
過剰にテスト項目が多かった。

【 仮説の検証 】
有識者の算出したテスト項目数も計画と同じだったか？

【 検証結果 】
計画と同程度であった。

仮説3
テスト難易度の設定が間違っていた。

【 仮説の検証 】
テスト項目に難易度の記載はあったか？

【 検証結果 】
難易度は記載されていなかった。

2.今回の問題の原因

テスト難易度の設定が間違っていた

と判明した。

また、テストの難易度がテスト実施日数に影響することを知らず、テスト項目を同じ分量で担当者へ割り振っていたことが分かった。

---

解決策

わたしは3つの解決策を準備した。

解決策A
テスト難易度を設定せず新規メンバーを投入してテストを続行する。

解決策B
テスト難易度を設定して、一人当たりの分量を見直す。

解決策C
テスト難易度を設定して、一人当たりの分量を見直す。その上でスケジィールを延期する。

現在のプロジェクトの状況とこの解決策の案をPO山田へ提言した。

PO山田は、このような意向があった。

⚫︎ 品質について
テスト難易度を設定して、一人当たりの分量を見直すことに問題なし。

⚫︎ リリース日について
リリース日の延期はできない。

このことから、解決策Bを採用した。

また、この解決策を施行することで、開発ベンダーA社はテストの難易度を設定する工数が必要となり、計画工数を30%超過することになった。

---

教訓（リスク管理表へ整理）

今回の原因は、テストの難易度の設定が間違っていた（または、行なっていない）ということであった。

このような事態を、事前に回避することはできる。

それは、プロジェクト計画の段階でこれらを実施することで防止できるのである。

・結合テスト計画として、テストの難易度が設定されていることを方針として盛り込む。

・結合テストでテストの難易度から、実施日数を検討して最適なスケジュールをする。

今回のトラブルプロジェクトをリスク管理表に整理したので、あなたのマネジメント業務で活用して頂ければ幸いである。

なぜ、プロジェクトが破綻したのか？

今回、プロジェクトが破綻したのは、PM経験が少ないことによるプロジェクト計画の策定を失敗したからです。

PM経験が浅い方は、プロジェクト計画で何を考えれば良いかが曖昧になっているケースがあります。

プロジェクト計画で、重要なのはプロジェクトを成功させるための要素を認識していなくはなりません。

プロジェクト計画を構成するは3つの要素
WHY：
なぜプロジェクトを行うのか。

WHAT：
どのような作業を行なって、どんな成果物を作るのか。

HOW：
どんな成功に導くための手段や方法を用意するのか。

破綻するプロジェクトは、3つの要素に対して、これらのことが出来ていないからです。

・どれか一つが漏れてしまった。

・間違った手順で作ってしまった。

・正しいメソッドやノウハウを使えなかった。

そのため、PMはプロジェクト計画を立てる時に、以下を意識してください。

1.構成を順番通りに、

2.正しい手順で、

3.メソッドやノウハウを使って、

4.「プロジェクト計画書」に、まとめる。

もし、あなたがこれらを意識していけど、

「勉強したいけど、何から手をつけていいか分からない」

「今の勉強方法が実践で使えるか自信が持てない」

「体系的にプロジェクトマネジメントを学び体験したい」

このように感じているなら、iPM TRAININGにチャレンジしてください。

あなたのプロジェクト計画書を作るスキルUPをサポートするサービスです

iPM TRAININGのご案内 | iPM PREMIUM

最後まで、読んでいただき有難う御座いました。