意外に勘違いしている要件定義のゴール
お疲れ様です、ゆーろー@常駐しないPMOです。
わたしがプロコンサルとして参加しているiPM naviのコラムをご紹介します。
writing by Osamu Hirayama *
このコラムはiPM naviで配信しています。
ITプロジェクトで要件定義を簡単に言うと『システムにおいて、実装すべき機能や満たすべき性能などのを明確にしていく作業』です。
要件定義のゴールが曖昧になると設計・開発・テストで不要なコストが発生して、ITプロジェクトは破綻することもあります。
こんにちは、プロコンサルの平山 理です。
iPM PREMIUMで運営しているオンラインサロンでは、プロコンサルが企業さまのPMへ個別のレクチャーやプロジェクトの後方支援を行なっています。
その活動を通じて、プロジェクトを成功に導くために活用した大手コンサルファームならではの特別なノウハウやメソッドをコラムにしています。
今回のコラムは、SIerに勤務している20代後半の新米PMの方からのご相談となります。
PMからのご相談
■相談者
SIerに勤務している20代後半の新米PM
■相談内容
わたしは、IT企業に勤務している20代後半の新米PMです。
弊社は、WEBシステムのマネジメント業務がメイン作業であり、上流工程からITパートナーに作業を依頼しています。
①弊社は、ITパートナーへ要件定義からリリースまでを一括でお願いしています。
②毎回のことですが、詳細設計工程、結合テスト工程において要件との食い違いが起こります。
③原因は、ITパートナーの仕様理解不足です。
④そのため、手戻り作業における工数の増加が発生しています。
⑤毎回のことなので、どうにかこの状況を改善したいと思っているのですが、良い方法はありますか？
■相談のポイント
①詳細設計工程、結合テスト工程において要件との食い違いが起こる。
②原因は、ITパートナーの仕様理解不足である。
③相談者は、改善策を模索している。
こんな時は、こうしてみれば良いですよ！
このように前提条件を整理しました。
・ITパートナーの要件定義の技量が低い。
・要件定義のゴール設定が間違っている。
教科書では、要件定義を『実装すべき機能や満たすべき性能などのを明確にしていく作業』と解説しています。
そのため、開発プロセスは各工程の成果物が、次の工程のINPUT情報になるように組み立てなければなりません。
そもそも要件定義のゴール設定が違えば、後続工程で仕様の食い違いが起こるのは当然のことです。
それではどうやって、要件定義のゴールを決めれば良いのでしょうか？
アプローチしていきましょう！
アプローチ1
顧客からの要件を5W1Hで整理する。
アプローチ2 要件に優先度をつけて開発スコープを確定する。
👍 アプローチ2を上手に行うには
優先度をつけるのに参考になるコラムです↓
アプローチ3
開発スコープから必要とされる開発工数を算出して、お客さまと協議し予算を確定する。
アプローチ4
要件定義のゴールは、『ITパートナーが正しく要件を理解している』こととして、これをマイルストーンとしてWBSスケジュールに組み込む。
👍 アプローチ4を上手に行うには
メンバーが要件を、きちんと理解しているかをチェックするのに参考になるコラムです↓
今回のご相談は、PM初心者だから起こしてしまった問題ではありません。
決して、稀なケースではなく、顧客の要求を、丸々飲み込むようなコスト・スケジュールを意識しないベテランPMも多いのです。
要件定義のゴールを設定することで、後続工程での仕様の食い違いが改善されます。 そのゴールとは、マイルストーンです。
多くのPMは、今回の場合であるとマイルストーンを『要件定義終了』といった開発工程やイベントの終了をWBSスケジュールに書き込んでいると思います。
マイルストーンは、プロジェクトの中で工程遅延を許さないような大きな節目ということです。
そのため、今回は『ITパートナーが正しく要件を理解している』をマイルストーンとしてセットしたわけです。
マイルストーンの設定が、上手なPMはプロジェクトの成功経験も多いものです。
ぜひ、工程・作業のゴールを決めるようにして下さい。
★★★ 45秒で分かるiPM navi ★★
無料メンバーの登録（こちら）
iPM naviの活用方法（こちら）
★★★ ぜひ、お立ち寄りください ★★
最後まで読んでいただき有難う御座いました。
いいなと思ったら応援しよう！
