このブログがリファインされました！
より分かりやすく、実践で活用しやすい情報に更新しました。
リファインのポイントは以下のとおりです。
初心者PMが陥りやすい失敗例を新セクションとして追加し、具体的な対策を提示
最新のプロジェクトマネジメント手法と工数管理の改善例を詳述
解決策の実施に伴う具体的な成果と課題を詳細に分析
リファインされた内容を確認したい方は、無料会員登録をしてください！
会員になると、他のリファインブログや追加コンテンツも閲覧可能です！
writing by MIRIO *このコラムはiPM naviで配信しています 総合テストになって、仕様を熟知しているメンバーが居なかったらどうなるでしょうか？ このようなケースは、多くのプロジェクトで見られます。 特に、順調に進捗していたプロジェクトに限って起こるものです。 順調なあまり「コストを抑えるチャンス」と考えて、上流工程を担当していコスト高のメンバーを外してしまう。 利益を増やせると焦ってしまうPMが起こすミスです。 そして、プロジェクトが破綻という結末に。
こんにちは、プロコンサルのMIRIOです。 私が参加しているiPMでは、PM初心者のスキルアップやDX時代に適応したいPMのリスキリングのサポートとして、iPM TRAININGを運営しています。 その中のオプションサービスとして、『トラブルプロジェクトの実例から学ぶ失敗しないマネジメント』をお伝えしています。 このコラムでは、読者のあなたへ、実際に私がPMアドバイザーとして参画し解決した、トラブルプロジェクトの実例を紹介します。 今回は、『工数をケチることでテストで痛い目にあいます❗️』というテーマです。 あなたのマネジメント業務で活用できるように、解決までのアプロローチを以下の順番でお伝えします。 ・プロジェクトの状況 ・問題の設定 ・原因追求 ・解決策 ・教訓（リスク管理表へ整理）
プロジェクトの状況：工数削減 テスト効率化
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%超過することになった。
教訓（リスク管理表へ整理）
今回の原因は、流用を前提にしていたことから調査が不十分ということであった。 このような事態を、事前に回避することはできる。 それは、プロジェクト計画の段階でこれらを実施することで防止できるのである。 ・総合テストに必要なスキルを定義する。 ・要件を熟知しているメンバーを必ずアサインする。 今回のトラブルプロジェクトをリスク管理表に整理したので、あなたのマネジメント業務で活用して頂ければ幸いである。
最後まで、読んでいただき有難う御座いました。
プロコンサル MIRIOさんのコラムを、もっと読むにはiPM naviメンバーサイトへログインして下さい。 アカウントをお持ちでない方は、画像をタッチして無料メンバーに登録して下さい
（無料）iPM naviの無料会員になると！こんな特典があります！
初心者PM向けの実践ノウハウを今すぐチェック！プロジェクト成功のコツが詰まっています。
プロジェクト管理を学びたいけれど、どこから始めればいいか迷っていませんか？初心者PM向けに特化した『プロジェクトリハーサルシミュレーター』をぜひお試しください！
- 詳細説明:
このシミュレーターでは、プロジェクト運営で直面しがちな『予算オーバー』『遅延』『仕様変更』等といった課題を疑似体験しながら、実務に役立つスキルを楽しく学べます。