意外にやってない『システムのリリースにおける前提条件』プロジェクトで注意したいポイント！
前提条件・制約条件を決めないとプロジェクトのボリュームはどんどん膨れていきます。
プロジェクトにおいて、仕様書と実装の差異は致命的です。
所謂、『品質劣化』のレッテルを貼られシステムのリリースができずプロジェクトの失敗を意味します。
仕様の中でも、ビジネスに悪影響を与えない部分（例：画面デザインのフォント種別、微妙なドット単位でのズレ）は、『大目に見てもらえる』場合もあります。
しかし、これは計画段階でクライアントとシステムのリリースにおける前提条件を協議しておかなければ成り立ちません。
意外にも、事前の協議を怠るPMが多いって、ご存知でしょうか？
■今回のテーマ
プロジェクト計画における『前提条件、制約条件の明確化』の検討の中で、『システムのリリースに関する前提条件、制約条件』を取り決めておかなかったことにより、ユーザテスト工程（受入）で、『仕様書と実装の差異による品質劣化』という問題が起こりました。
この問題を取り上げて、原因の追求、解決策、リスク対策を解説していきます。
※プロジェクト検証の結果をお伝えするにあたり、架空の企業である「株式会社XYZ」での出来事として紹介します。
prologue
株式会社XYZは、市場シェアの拡大と業務コストの削減のために、新規プロジェクトを立ち上げることになりました。
プロジェクトの目的として、売上の10%増加と業務コストの20%削減を掲げています。 目的を達成させるためには、個々の目標の設定が必要です。 品質目標は、レスポンスタイム、受け入れ合格に数値目標を設定しました。
コスト目標は、開発費用を1800万円以内として、スケジュール目標は、リリース日を10月1日、主要なマイルストーンをユーザーテストによる品質判断としています。
また、プロジェクトの開始は、4月1日。開発期間を6ヶ月としました。
【プロジェクトの登場人物】
▷山田
株式会社XYZの事業部長であり、プロジェクトオーナー。
▷木村
株式会社XYZの社内調整役。クライアント窓口であり、ITベンダーとコミュニケーションを取る。
▷佐藤
このプロジェクトの開発を担当する株式会社ABCのプロジェクトマネージャーであり、今回初めてプロジェクトマネージメントを行うプロマネ初心者。
▷PMアドバイザー
The manager's Barに所属。プロマネ初心者の佐藤のマネジメントアドバイザー。
【プロジェクト状況】
製造/単体テスト工程であり、所要期間の50%を消化した時点で、複雑な既存機能に対して設計書がないことから必要以上に時間を浪費し、プロマネ初心者の佐藤は『リリースの延期』を依頼したが、クライアント窓口の木村の回答は、『本件はクリティカルタスクとして十分な調査期間を設けていたはずである。当初の計画通り進めて欲しい。』と要望された。
プロマネの佐藤は、状況の把握をしていますが、具体的な問題が分かっていません。
そのため、PMOの私へサポートを求めてきました。
（以降のSTEP1-STEP4はPMOが実施しました）
目次
STEP1：問題の設定
今回の問題は、プロジェクトで起きた事象を、様々なプロジェクト情報を元に考えたところ、『コミュニケーションマネジメントエリア』で起こっている問題として取り扱うことにした。
そして、『仕様書と実装の差異による品質劣化』、このように問題を設定した。
STEP2：原因の究明
この問題は、スケジュール目標であるリリース日を逸脱している。
そこでPMOの私は、原因の仮説を立て検証を行った。
【原因の仮説】
(1)画面設計書の承認以降に仕様追加があった
(2)品質の合格基準が合意されていない
(3)画面設計書はイメージであり、実装は多少の差異が発生することを合意していない
そして、仮説に対して調査を行い検証した。
【仮説の検証】
(仮説1)画面設計書の承認以降に仕様追加があった
▷追加された仕様が議事録、メールなどに記録されていなかったか？
➡︎YES
(仮説2)品質の合格基準が合意されていない
▷プロジェクト計画書に品質基準の記載があり合意されていたか？
➡︎YES
(仮説3)画面設計書はイメージであり、実装は多少の差異が発生することを合意していない
▷調整した結果が議事録、メールなどに記録されていたか？
➡︎NO
問題の根本的な原因は、『仮説3』と判明した。また、プロマネ初心者の佐藤は、画面設計書と実装の多少な差異についてクライアントとの調整が容易であると思い込んでいて、放置していたことが分かった。
STEP3：解決策
この問題を放置することは、デスマーチプロジェクトの危険があるため、PMOの私は解決策を３つ考え、プロジェクトオーナーの山田と協議した。
【解決策の候補】解決策A：
クライアントから指摘のあった範囲を全て修正し、リリース日を延期する。
解決策B：
クライアントが容認できる許容範囲を確認し、メンバーを増やして修正する。
解決策C：
クライアントが容認できる許容範囲を確認して、現状の人数で修正しリリース日を延期する。
調査の結果から、画面設計書と実装の多少な差異についてクライアントとの調整が容易であると思い込んでいたことが分かっている。
その状況をプロジェクトオーナーの山田へ説明し、山田の意向を踏まえ解決策を決定した。
【採用した解決策と採用の根拠】
山田の意向は、仕様不一致でのリリース許容範囲を調整することに問題はないが、リリース日の延期は避けて欲しいとの要望があり、『解決策B』を採用した。
【解決策の実行に伴うダメージ】
また、今回の解決策を実施したことで、ITベンダーに、修正作業のメンバーの増員による工数が30%超過した。
今回の問題における原因は、画面設計書はイメージであり、実装は多少の差異が発生することを合意していなかったということである。
今後、このような事態を避けるために、以下を教訓とした。
【教訓】
(1)プロジェクト計画で、厳密性を要求される画面の承認行為をマイルストーンとして設定する。
(2)詳細設計で、厳密性を要求される画面については、設計書を使ってクライアントと確認する。
STEP4：リスク管理表の作成
最後に、今回プロジェクトで起こった問題を課題問題整理表に記述し、今後のプロジェクトの教訓として役立てるためにリスク管理表に記述した。
このリスク管理表は、ITベンダーのプロジェクト情報として保管され、他チームへの情報共有として利用することになった。
最後まで、読んで頂き有難うございました。
今後の貴方のプロジェクト活動の参考になれば幸いです。
このトラブルプロジェクトは私が対応しました！
