このブログがリファインされました！
より分かりやすく、実践で活用しやすい情報に更新しました。
リファインのポイントは以下のとおりです。
失敗事例の具体化：実際に起こりうる失敗の経緯や背景を詳しく解説し、教訓を明確にしました。
解決策の実践性を向上：具体的なアクションプランや成果例を挙げ、初心者でも実行しやすい内容にしました。
スキル習得の重要性を強調：初心者PMが身につけるべきスキルを整理し、優先順位をわかりやすく提示しました。
リファインされた内容を確認したい方は、無料会員登録をしてください！
会員になると、他のリファインブログや追加コンテンツも閲覧可能です！
writing by OSAMU *このコラムはiPM naviで配信しています プロジェクト計画ではスコープを明確にしていきます。 しかしスコープの確定条件と確定日の応用行わないPMがいます。 そうすると、要件通りのシステムが完成できずプロジェクトが破綻するケースがあります。 何故、このようなトラブルが起こるのでしょうか？ それは、「スコープの確定条件の取り決め」に不備があるからです。
こんにちは、プロコンサルのOSAMUです。 私が参加しているiPMでは、PM初心者のスキルアップやDX時代に適応したいPMのリスキリングのサポートとして、iPM TRAININGを運営しています。 その中のオプションサービスとして、『トラブルプロジェクトの実例から学ぶ失敗しないマネジメント』をお伝えしています。 このコラムでは、読者のあなたへ、実際に私がPMアドバイザーとして参画し解決した、トラブルプロジェクトの実例を紹介します。 今回は、『スコープの合意なしにプロジェクトを進行して破綻...』というテーマです。 あなたのマネジメント業務で活用できるように、解決までのアプローチを以下の順番でお伝えします。
プロジェクトの状況
1.プロジェクトのスコープと体制 ・顧客は大手鉄鋼会社。 ・顧客の情報システム部で新規構開発を実施。 ・情報システム部の窓口は木村。 ・プロジェクトオーナーは情報システム部の山田。 ・システム化スコープは商品管理、資産管理、顧客管理。 ・中堅SierのA社が開発ベンダーとして参画。 ・A社は全開発工程の成果物の納品、システムリリースの責任を請け負う。 ・A社の開発体制は業務チーム、基盤チーム、テストチーム、管理チームで構成。 ・A社のPMは佐藤（初心者PM） 2.プロジェクト目標 品質目標：100%の不具合修正 スケジュール目標：予定通りのリリース コスト目標：予算内でのシステム完成 3.プロジェクトの進捗状況 現在、プロジェクトは結合テスト工程であり、3日間（10%消化）が経過した。 木村から 「一部の要件が確定していないという課題が未解決である。」 「この状態で、要望通りにシステムは完成できるのか！」 と厳しい指摘があった。 佐藤は状況を把握しているが、具体的な問題や解決策が分からない状態である。 **守秘義務により企業名・団体名・個人名等は架空名称となります。
問題の設定
*私がアドバイザーとして、プロジェクトに参画して解決させた経緯のスタートです。 問題を考える場合は、どのマネジメント領域で発生したかを分類することで、後続のアプローチがスムーズに行え、得られた結果の根拠も説得力を持つ。 そこで、今回の問題は、プロジェクトで起きた事象を、様々なプロジェクト情報から考えをもとに考たところ『スコープマネジメント領域』で発生した問題として取り扱った。 また、今回のプロジェクトの問題をこのように設定した。 ”スコープの合意なしにプロジェクトを進行させている” また、この問題を放置することで、スケジュール目標であるリリース日を逸脱する恐れがあった。
様々なプロジェクト情報とは
プロジェクト計画書、レービュー結果報告書、要求変更書、レビュー対象物、作業実績情報、作業範囲記述書、要件定義書、成果物一覧、課題問題整理表、役割分担表、要員の選定根拠、勤務表、成果物、関係者からのヒアリング結果
原因の追求
原因を特定するためには関係者へのヒアリングが重要である。 しかし、闇雲に関係者から聞き取りを行っても時間の無駄であることから原因の仮説を3つ立てた。 1.原因の仮説と検証 仮説1 仕様に関する不明ていがQA管理されていなかった。
仮説の検証
OA管理表で解答未記入はあったか？ 【 検証結果 】 全て解答済みで解決していた。
仮説2 設計書の未修正があった。
仮説の検証
設計書の変更履歴が正確に更新されていなかった？ 【 検証結果 】 全ての正しく更新されていた。
仮説3 スコープの確定日程と確定条件の取り決めがなかった。
仮説の検証
プロジェクト計画書に「スコープ確定の条件等」が整理され記載されていなかった？ 【 検証結果 】 プロジェクトスコープの記載はあったが、確定条件等は見当たらなかった。
2.今回の問題の原因
スコープの確定日程と確定条件の取り決めがなかった。
解決策
わたしは3つの解決策を準備した。
解決策A
要件が確定している範囲のみをスコープ対象とする。
解決策B
要件定義のゴールを設定し、クリティカル部分のみ要件を再定義する。
解決策C
要件定義のゴールを設定し、全ての要件を再定義する。
現在のプロジェクトの状況とこの解決策の案をPO山田へ提言した。
PO山田は、このような意向があった。
⚫︎ スコープについて
クリティカル部分のみ要件を再定義することに問題はない。
⚫︎ スケジュールについて
スケジュールの延期はできない。
このことから、解決策Bを採用した。
また、この解決策を施行することで、SIerは要件定義に対する工数が30%超過することになった。
教訓（リスク管理表へ整理）
今回の原因は、スコープの確定日程と確定条件の取り決めがされていないということであった。 このような事態を、事前に回避することはできる。 それは、プロジェクト計画の段階でこれらを実施することで防止できるのである。 ・スコープ確定のスケジュールと条件を決める。 ・スコープ確定となる条件成立をマイルストーンとする。 今回のトラブルプロジェクトをリスク管理表に整理したので、あなたのマネジメント業務で活用して頂ければ幸いである。
最後まで、読んでいただき有難う御座いました。
プロコンサル OSAMUさんのコラムを、もっと読むにはiPM naviメンバーサイトへログインして下さい。 アカウントをお持ちでない方は、画像をタッチして無料メンバーに登録して下さい。
（無料）iPM naviの無料会員になると！こんな特典があります！
初心者PM向けの実践ノウハウを今すぐチェック！プロジェクト成功のコツが詰まっています。
Comments