writing by MASA *このコラムはiPM naviで配信しています プロジェクトは、計画段階でスコープを決めます。 そのとき、既存システムの改修がメインであれば、顧客の要求を実現させるために、予め『システム仕様』、『業務仕様』を併せて調査しなければなりません。 意外にも、この調査が不十分なケースが多いものです。 そのシワ寄せが、プロジェクトの詳細設計工程、テスト工程で発覚したら、大きな手戻りとなります。 そうなるとプロジェクトは失敗する可能性が高いものです。
監修：えのきのキャリア 2003年に大手コンサルファームにジョイン。 数年間のオープン系システムのインフラエンジニアを経験したのち、プロジェクトマネジメント関連業務へキャリアチェンジ。 以降中小から大規模までさまざまなプロジェクトにおいてPM/PMO業務に従事。 製造業、メディア、金融、官公庁など、業界を問わず経験しており、クライアントの様々な文化に柔軟に対応している。近年ではシステム関連の知識を生かし業務コンサルテイング領域でも活動中。
こんにちは、プロコンサルのMASAです。
iPM PREMIUMで運営しているオンラインサロンでは、プロコンサルが企業さまのPMへ個別のレクチャーやプロジェクトの後方支援を行なっています。 その活動を通じて、プロジェクトを成功に導くために活用した大手コンサルファームならではの特別なノウハウやメソッドをコラムにしています。 今回のコラムは、SIerに勤務する26歳のPMの方からのご相談となります。
MASAのキャリア 2004年に大手コンサルファームBにジョイン。 大手事業会社をクライアントに持ち、クライアント社内で活用する品質マネジメント基準・開発プロセス基準の策定に従事。また、PMOとしてクライアントのプロジェクト推進及び品質維持に貢献しプロジェクトを成功に導いた。 2016年に大手コンサルファームMにジョイン。
大手エネルギーインフラ会社のガバナンス部門にて、大規模システム開発プロジェクトのマネジメント品質管理に従事。PMOとしてプロジェクト運営における問題点の可視化とプロジェクトマネージャおよび上位層への改善提案によりプロジェクトを成功に導いた。
目次
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であれば、誠心誠意を持って最後まで逃げずに、プロジェクトに責任を持って下さい。 最後まで、読んでいただき有難う御座いました。
わたしのコラムで、あなたのお役に立てれば幸いです。
品質管理・スコープ管理、今回のようなリスク対策、これらをコラムとして配信していこうと思ってます。
ぜひ今後とも応援を宜しくお願いします。
*Back Numberはこちらです↓
*無料メンバーへ登録するとMASAのBack Numberが読みたい放題です❗️ 無料登録はこちら（MASAのBack Numberを読む）