『仕様変更・追加で頭を悩ますのはやめよう』PMのストレスをなくす方法を伝授！
仕様追加・変更は日常茶飯事です、ルールを作ることでプロジェクト運営は安定します。
noteマガジン：問題解決のロジカルツールはこちらを読んでください。
このような疑問を抱えているPM初心者・未経験者の悩みを解決できる記事になっています。
今回のテーマ
プロジェクト計画における『コミュニケーションマネジメント』の検討の中で、『仕様変更・追加のルールが準備しなかった』ことにより、『プロジェクトが停滞した』という問題が起こりました。
この問題を取り上げていきます。
※プロジェクト検証の結果をお伝えするにあたり、架空の企業である「株式会社XYZ」での出来事として紹介します。
参考：このような方にもお役に立つ記事となっています
✅仕様追加・変更が起こったときに焦ってしまう方
✅CTO、プロジェクト責任者の方
👍この記事の信頼性
1,000以上のプロジェクトに携わった現役PMO林 雄一郎が、実際に起こったトラブルプロジェクトを解決した実話です。
この記事は、そのときの検証結果となります。
目次
Prologue
【プロジェクト概要】
株式会社XYZは、市場シェアの拡大と業務コストの削減のために、新規プロジェクトを立ち上げることになりました。
プロジェクトの目的として、売上の10%増加と業務コストの20%削減を掲げています。目的を達成させるためには、個々の目標の設定が必要です。
品質目標は、レスポンスタイム、受け入れ合格に数値目標を設定しました。コスト目標は、開発費用を1800万円以内として、スケジュール目標は、リリース日を10月1日、主要なマイルストーンをユーザーテストによる品質判断としています。
また、プロジェクトの開始は、4月1日。開発期間を6ヶ月としました。
【プロジェクトの登場人物】
▷山田
株式会社XYZの事業部長であり、プロジェクトオーナー。
▷木村
株式会社XYZの社内調整役。
クライアント窓口であり、ITベンダーとコミュニケーションを取る。
▷佐藤
このプロジェクトの開発を担当する株式会社ABCのプロジェクトマネージャーであり、今回初めてプロジェクトマネージメントを行うプロマネ初心者。
また、同社はプロマネ初心者の佐藤をフォローアップするために、The manager's（PMOコミュニティー）の『PMOリモート』を利用。
▷PMO（YUICHIRO HAYASHI）
The manager's Barに所属。
プロマネ初心者の佐藤のPMアドバイザーでありリモートで支援。
【プロジェクト状況】
現在のプロジェクトは、基本設計工程である。
当該工程が所要期間の50%を消化した時点で、仕様変更が多発したことから、当初の要件の品質を担保できなくなり、設計の品質劣化が起こった。
そこで、プロマネ初心者の佐藤は『再度要件を整理して要件定義をやり直したいこと』を依頼した。
クライアント窓口の木村の解答は『様々な部署から、改めて要望が出てきている。また、変更に関するルールはお互いに決めていない。当初の計画通り進めて欲しい』と要望された。
プロマネの佐藤は、状況の把握をしているが、具体的な問題が分からず打つ手もなかった。
そこで、PMOのわたしはへサポートを求めてきた。
わたしは、お客さま先に常駐しないPMOであるため、PMOリモートで今回のトラブルを解決した。
PMOリモートは、PMが、好きな時に、好きな場所で、プロジェクト経験豊富なPMOのビデオ通話、メールでオンラインサポートする新しい形のPMOサービスです。
フル常住型のPMOサービスと比べても、遜色の無いサービスをリーズナブル料金なので、大幅にコストが削減でき、プロジェクトを成功に導きます。
また、PMOリモートをご利用いただくことで、プロマネ初心者の方は、『マネジメント力』と『経験力』を身に付けることができます。
>>PMOリモートの詳細なサービスを確認する
プロジェクトを検証しました
検証は、STEP1-STEP4の順番で行いました
STEP1
今回の問題は、プロジェクトで起きた事象を、様々なプロジェクト情報を元に考えたところ、『品質マネジメントエリア』で起こっている問題として取り扱うことにした。
そして、『変更管理ルールが無いことから品質劣化』、このように問題を設定した。
STEP2
この問題は、品質目標である要望達成率100%を逸脱している。
そこでPMOの私は、原因の仮説を立て検証を行った。
【原因の仮説】
(1)リスクバッファ工数が間違っている
(2)リスクを吸収する所要期間が間違っている
(3)変更管理ルールが無い
そして、仮説に対して調査を行い検証した。
【仮説の検証】
(仮説1)リスクバッファ工数が間違っている
▷有識者が算出したバッファ工数も計画と同じであったか？
➡︎YES
(仮説2)リスクを吸収する所要期間が間違っている
▷有識者が算出したリスクを吸収する所要期間も計画と同じであったか？
➡︎YES
(仮説3)変更管理ルールが無い
▷プロジェクト計画書に変更管理の取り決めがされているか？
➡︎NO
問題の根本的な原因は、『仮説3』と判明した。
また、プロマネ初心者の佐藤は要件定義工程でクライアントから品質合格を受理していたことから、後続工程での仕様追加や変更は起こらないと判断していことが分かった。
STEP3
この問題を放置することは、デスマーチプロジェクトの危険があるため、PMOの私は解決策を３つ考え、プロジェクトオーナーの山田と協議した。
【解決策の候補】
解決策A：
全ての仕様変更を当該プロジェクトで達成するように、プロジェクト計画を見直す。
解決策B：
変更管理ルールを策定し、ビジネスインパクトの強い仕様変更のみを当該プロジェクトで吸収し実現する。
解決策C：
変更管理ルールを策定し、ビジネスインパクトの強い仕様変更のみを当該プロジェクトで吸収し実現する。そして、スケジュールを延期する。
調査の結果から、要件定義工程でクライアントから品質合格を受理していたことから、後続工程での仕様追加や変更は起こらないと判断していことが分かっている。
その状況をプロジェクトオーナーの山田へ説明し、山田の意向を踏まえ解決策を決定した。
【採用した解決策と採用の根拠】
山田の意向は、ビジネスインパクトの強い仕様変更のみを対象にすることに問題はないが、リリースの延期はできないとの要望があり『解決策B』を採用した。
【解決策の実行に伴うダメージ】
また、今回の解決策を実施したことで、変更管理ルールの策定による工数が30%超過した。
今回の問題における原因は、変更管理ルールがなかったということである。
今後、このような事態を避けるために、以下を教訓とした。
【教訓】
(1)プロジェクト計画で、スコープ計画の検討を行う時に、変更管理ルールを策定し合意する。
(2)各工程で、仕様追加や変更が発生した場合は、品質、コスト、スケジュール、スコープへのリスクを調査して、クライアントと協議する。
STEP4
最後に、今回プロジェクトで起こった問題を課題問題整理表に記述し、今後のプロジェクトの教訓として役立てるためにリスク管理表に記述した。
このリスク管理表は、ITベンダーのプロジェクト情報として保管され、他チームへの情報共有として利用することになった。
🔎PMOのよもやま話
今回のテーマですが、変更管理ルールをプロジェクトで取り入れていなかったことでトラブルになったケースです。
意外にも変更管理ルールを取り入れていない、取り入れていても機能していないプロジェクトが多いものです。
特に、初めて取引をするクライアントにおいては、ゼロから変更管理ルールを設定することをお薦めします。
よく見かけるのは、初めての取引であるため継続して受注したいがあまり、仕様追加、変更をルール無視で受け入れてしまうことで、プロジェクトの目的を達成できないことがあります。
これでは、継続受注などはありえないことであり、企業としての信頼を損なうかもしてません。
また、誤解してはならないのが『変更管理ルール』は、ITベンダがクライアントの無理な要望を阻止するために準備するのではありません。
ITベンダは、クライアントの仕様追加、変更には耳を傾けるべきであり、リスク分析を行なった上で、『やる』or『やらない』をクライアントを含めて協議してください。
その時、リスク分析の大概テーマは、以下の通りとなります。
①プロジェクト目的の逸脱の可能性
②プロジェクト計画の変更の可能性（品質、コスト、スケジュール、スコープ）
これらがネガティブな結果の時に、クライアントに利益が出るのか？不利益になるのか？これらを協議し合意することが重要です。
今回のプロマネ初心者の佐藤くんは、ここまで考えていなかったため焦ってしまいました。
クライアントから仕様追加や変更の依頼があっても焦ることなく、一旦冷静になってプロジェクト全体とクライアントの利益を検討できる余裕を持ってください。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
★今回の感想や同じような思い出があればコメントしてください。
★他にもリスクをお知りになりたい人はコメントしてください。
明日からのPMOとしての活力になります！
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
