工数をケチって、テストで痛い目にあった話

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

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

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

---

総合テストになって、仕様を熟知しているメンバーが居なかったらどうなるでしょうか？

このようなケースは、多くのプロジェクトで見られます。

特に、順調に進捗していたプロジェクトに限って起こるものです。

順調なあまり「コストを抑えるチャンス」と考えて、上流工程を担当していコスト高のメンバーを外してしまう。

利益を増やせると焦ってしまうPMが起こすミスです。

そして、プロジェクトが破綻という結末に。

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

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

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

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

今回は、『工数をケチって、テストで痛い目にあった話』というテーマです。

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

・プロジェクトの状況

・問題の設定

・原因追求

・解決策

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

👍 このコラムは

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

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

気付き学び　：
★★★★★(有識者のリリースタイミング)

お役立ち　　：
★★★★★(コスト管理)

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

プロジェクトの状況

1.プロジェクトのスコープと体制
・顧客は大手通信会社。

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

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

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

・システム化スコープは倉庫管理、物流管理、在庫管理。

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

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

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

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

2.プロジェクト目標
品質目標：100%の不具合修正

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

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

3.プロジェクトの進捗状況
現在、プロジェクトは総合テスト工程である。

総合テスト工程を開始して5日間が経過していた。

総合テストが所要期間の50%を消化した時点で、順調だったプロジェクトが遅延し始めた。

総合テストから新規のテストメンバーを投入したが、仕様のキャッチアップに時間が掛かり、予定通りにテストが進まない。

リリース日を遅延させないようにするには、流用できなかった機能の設計を行う必要があった。

そのために、PM佐藤は顧客の木村に、リリースの延期を依頼したが、

『総合テストが50%消化した時点でそのような報告をされても社内の調整ができない。』

『当初の計画通り進めてほしい』 と一蹴された。

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


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

問題の設定

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


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

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

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

”弱小体制による総合テストの進捗が遅延”

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

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

原因の追求

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

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

1.原因の仮説と検証

仮説1
総合テストの所要期間が間違っていた。

【 仮説の検証 】
有識者が算出した所要期間と同じであったか？

【 検証結果 】
有識者の算出した所要期間と同じであった。

仮説2
総合テストの作業工数が間違っていた。

【 仮説の検証 】
有識者が算出した作業工数と同じであったか？

【 検証結果 】
有識者の算出して作業工数と近い数字であった。

仮説3
要件を正確に理解しているメンバーがいなかった。

【 仮説の検証 】
上流工程で設計を担当したメンバーが体制に入っているのか？

【 検証結果 】
上流工程で設計を担当したメンバーが一人もいなかった。

2.今回の問題の原因
要件を正確に理解しているメンバーがいなかった。
と判明した。

また、テスト仕様書を基本設計の段階で作成したことから、総合テストのテスト体制は要件を熟知していたメンバーを外し、スキルの低いメンバーで構成していた。

解決策

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

解決策A
テスト作業の均質化のためにテストツールを採用し、ツール熟達度を上げてからプロジェクトを再開する。

解決策B
要件を熟知したメンバーを再度アサインして、テスト結果の分析とテスターへのレクチャーを行う。

解決策C
要件を熟知したメンバーを再度アサインして、テスト結果の分析とテスターへのレクチャーを行う。 その上で、スケジュールを延期する。


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

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

⚫︎ 品質について テスト結果の分析とテスターへのレクチャーを行うことに問題なし。

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


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

また、この解決策を施行することで、開発ベンダーA社は要件を熟したメンバーの再投入とレクチャーにより、計画工数を30%超過することになった。

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

今回の原因は、流用を前提にしていたことから調査が不十分ということであった。

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

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

・総合テストに必要なスキルを定義する。

・要件を熟知しているメンバーを必ずアサインする。

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

♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪＼ お知らせです ／
失敗しないプロジェクトの方法を学びませんか？♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪

・プロジェクトで困ったことが起きた！

・どうやってマネジメントすればいいんだ！

・専門家に聞くにしても高いお金が必要！

・ネットで調べるのも時間が掛かる！

一般的なPM教材は概念ばかり…実践的な教材はないのか！

こんなことを感じてる方は、無料で利用できるプロジェクトマネジャのポータルサイトiPM naviをご利用ください。

iPM naviは、大手コンサルファームの社員・卒業生がプロコンサルとして、サポートする無料で利用できるプロジェクトマネージャのポータルサイトです。

ファームならではのノウハウやメソッドのコミックエッセイから専門家監修の基礎知識まで、幅広いコンテンツを配信しています。

また、業界初！お悩みワードを選ぶと解決ヒントになるコラムが検索できサービスも無料で使えます！

詳しくはiPM naviのサイトで確認してください。

サイトはこちら↓

iPM navi | プロジェクトマネジメントの基礎から応用まで学べる

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