仕様漏れが発覚した時のリカーバリー方法

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

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

---

プロジェクトは、計画段階でスコープを決めます。

そのとき、既存システムの改修がメインであれば、顧客の要求を実現させるために、予め『システム仕様』、『業務仕様』を併せて調査しなければなりません。

意外にも、この調査が不十分なケースが多いものです。

そのシワ寄せが、プロジェクトの詳細設計工程、テスト工程で発覚したら、大きな手戻りとなります。

そうなるとプロジェクトは失敗する可能性が高いものです。

👍 このコラムは

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

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

気付き学び　：★★★★★(遅延PJのリカバリー方法)

お役立ち　　：★★★★★(リカバリー計画)

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

---

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

iPM PREMIUMで運営しているオンラインサロンでは、プロコンサルが企業さまのPMへ個別のレクチャーやプロジェクトの後方支援を行なっています。

その活動を通じて、プロジェクトを成功に導くために活用した大手コンサルファームならではの特別なノウハウやメソッドをコラムにしています。

今回のコラムは、SIerに勤務する26歳のPMの方からのご相談となります。

PMからのご相談

■相談者
SIerに勤務する26歳のPM

■相談内容
わたしは、SIerに勤務する26歳のPMで今回初めてPMをやらしていただいてますが、詳細設計で大きなトラブルを抱えています。

①わたしは既存システムに対する機能追加のプロジェクトを行なってます。

②現在、詳細設計工程の終盤を迎え、プログラム製造工程に向けて業務要件・システム要件の誤認識や抜け漏れの再確認レビューを行いました。

③レビューの結果から、一部の機能設計に業務要件を満たしていない不具合がありました。

④原因は、システム調査（詳細設計工程の前に実施）を行ったメンバーのスキル不足により、調査範囲を間違ったことでした。

⑤当該プロジェクトは、スケジュールがタイトであるためリリース日を延期するのが難しいです。

⑥現状を踏まえ、プロジェクトオーナーと協議したところ「まずはどのようにリカバリーするのか？提案が欲しい」、「その提案が許容範囲であれば前向きに検討する」と合意しています。

⑦しかし、どのように解決すれば良いかアイデアがありません。


■相談のポイント
①相談者は、詳細設計工程の終盤でレビューを行ったところ業務仕様の抜け漏れ・誤認識を発見した。

②業務仕様の抜け漏れ・誤認識の原因は、システム調査を行ったメンバのスキル不足であった。

③当該プロジェクトはタイトなスケジュールであるが、お客さまはリカバリー提案が許容範囲であれば検討する。

④相談者は、詳細設計のリカバリーの方法がわからない。

こんな時は、こうしてみれば良いですよ！

このように前提条件を整理しました。

・ITパートナーは、優秀なメンバーを召集することができる。

・リカバリー計画を検討する上でお客さまの協力が得られる。

・顧客は、リカバリー計画を受け入れる代わりに追加要求は行わない。

既存システムの改修プロジェクトでは、事前調査を十分に行ってください。 特に新しい仕様（業務・システム）が、既存業務・システムにどのような影響を与えるのか？これを徹底的に調査しなければなりません。

しかし、様々な理由によって不十分な調査で終わってしまい、プロジェクトが危機状態になることがあります。

そのため、PMは効果的なリカバリー策を講じなければなりません。 まずは、このことを認識して、この問題をアプローチしていきましょう！

*このアプローチはDX時代に適応したリスキリングしているPMの方にも実用的に使えます。

*プロジェクトマネージャ試験の論文対策にも役立ちます。


アプローチ1
今回のプロジェクトでシステム調査を行うために必要とされるスキルを洗い出して、スキル保有メンバーを召集する。

アプローチ2
詳細設計で見つかった業務仕様の抜け漏れ・誤認識の範囲を業務単位、システム単位で整理する。

*下表は『整理一覧』の事例フォーマット、事例を使ってアプローチしていきます。

アプローチ3
整理一覧をもとに、既存システムに対して具体的に『何が抜け漏れしていて』、『どのように修正すれば良いのか』を業務単位・システム単位で調査する。

アプローチ4
調査結果をもとに、詳細設計の見直し範囲の優先度を設定する。
*顧客を含め協議することを推奨する。

【　注意点　】
・顧客のビジネスへの機会損失を与える範囲は優先度を高くすること。

・当該アプローチは可能な限り、お客さまを含め協議することを推奨する

👍 アプローチ4を上手くやるには
感覚では優先度を設定してはいけません。 大手コンサルファームでも使っているメソッドを参考にして下さい↓

アプローチ5
詳細設計作業の『見直し計画』を作成する。

【　見直す内容　】
(1)詳細設計を修正することで発生する手戻り作業とその工数を明確にする。

(2)詳細設計を修正することで発生する追加作業とその工数を明確にする。

(3)改めてお客さまと要件の確認が必要とされる範囲（業務単位・システム単位）を明確にする。

(4)上記(1)～(3)の内容をWBSに盛り込み、対応できる体制を作り、WBSが煩雑になる場合は、別途リカバリー計画書を作成する。

*品質基準の見直しが必要な場合は、顧客と見直した基準を合意する。


アプローチ6
見直し計画を顧客と合意する。

---

まとめ

スコープは、プロジェクト計画の段階で、大枠を決めていきます。

その段階で、詳細まで分かっていればスコープ漏れや誤認識はありません。

しかし、顧客自身も要件を分かっているようで、分かっていない、SIerもある程度の予測は立てられても、確信がない...

これは仕方のないことで、工程が進むにつれてスコープが明確になっていきます。

このことを、分かっているPMであれば、絶妙なタイミングで、ビシッ！ビシッ！とスコープを確定していけるものですが、今回のように初めてPMをやる方、既存システムの改修も含めたプロジェクトとなれば、難易度は計り知れないものです。

いざ、あなたが今回の相談者と同じような立場になったら、ポイントはこちら！

・業務仕様の抜け漏れや誤認識の範囲を業務単位、システム単位で整理する。

・設計の見直し範囲の優先度を設定する。

・計画の見直しを行う（顧客の合意が必須）

今回のケースは、これらをしっかり実施しても、当初の計画に戻ることはできません。

しかし、PMであれば、誠心誠意を持って最後まで逃げずに、プロジェクトに責任を持って下さい。

---

★★★　45秒で分かるiPM navi　★★

無料メンバーの登録（こちら）

iPM naviの活用方法（こちら）

★★★　ぜひ、お立ち寄りください　★★

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