『メンバが要件を正確に理解しているのか』確認方法を知らず大惨事！

マネジメントが健全でも完成したシステムが要件を満たせなければ失敗プロジェクトです。

✅要件の理解度を確認する方法を模索している方

✅PJリスクを集めているPMやPMO

✅プロマネ初心者を抱える管理者

 

 にお伝えしたいプロジェクトリスクの情報です。

  

プロジェクトにおいて、一番怖いのは『クライアント要件の理解不足』です。
これは、最後の工程である『ユーザーテスト（受入）』で発覚することが多いようです。

この時点で、要件違いのシステムが作られていたとしたらプロジェクトは失敗に終わるでしょう。
このようなことを回避するには、要件定義の段階で工夫が必要です。

例えば、『要件定義工程の終盤で要件理解の説明を実施し合否判定する』、『結合テスト工程でクリティカル要件のみ動作テストを実施し合否判定する』といったことが効果的です。
意外にも、これを知らないPMが多いって、ご存知でしょうか？

■今回のテーマ

プロジェクト計画における『品質マネジメント計画の作成』の検討の中で、『正確に要件を理解しているかの確認方法を決めなかった』ことにより、『開発した機能が要件を満たしていない』という問題が起こりました。
この問題を取り上げて、原因の追求、解決策、リスク対策を解説していきます。
※プロジェクト検証の結果をお伝えするにあたり、架空の企業である「株式会社XYZ」での出来事として紹介します。

 prologue

株式会社XYZは、市場シェアの拡大と業務コストの削減のために、新規プロジェクトを立ち上げることになりました。プロジェクトの目的として、売上の10%増加と業務コストの20%削減を掲げています。
目的を達成させるためには、個々の目標の設定が必要です。
品質目標は、レスポンスタイム、受け入れ合格に数値目標を設定しました。
コスト目標は、開発費用を1800万円以内として、スケジュール目標は、リリース日を10月1日、主要なマイルストーンをユーザーテストによる品質判断としています。
また、プロジェクトの開始は、4月1日。開発期間を6ヶ月としました。

【プロジェクトの登場人物】
▷山田
株式会社XYZの事業部長であり、プロジェクトオーナー。
▷木村
株式会社XYZの社内調整役。クライアント窓口であり、ITベンダーとコミュニケーションを取る。
▷佐藤
このプロジェクトの開発を担当する株式会社ABCのプロジェクトマネージャーであり、今回初めてプロジェクトマネージメントを行うプロマネ初心者。
▷PMアドバイザー
The manager's Barに所属。プロマネ初心者の佐藤のマネジメントアドバイザー。

【プロジェクト状況】
現在のプロジェクトは、ユーザーテスト（受入）工程である。ユーザーテストが進むにつれ、テスト担当者からクライアント窓口の木村の元へ「想定していた動作と違っている」とのネガティブな報告が上がってきた。
プロマネの佐藤は、状況の把握をしていますが、具体的な問題が分かっていない。
そのため、PMOの私へサポートを求めてきた。
（以降のSTEP1-STEP4はPMOが実施した）

 

  目次

STEP1：問題の設定

今回の問題は、プロジェクトで起きた事象を、様々なプロジェクト情報を元に考えたところ、『品質マネジメントエリア』で起こっている問題として取り扱うことにした。
そして、『開発した機能が要件を満たしていない』、このように問題を設定した。

STEP2：原因の究明

この問題は、品質目標である要望達成率100%を逸脱している。

そこでPMOの私は、原因の仮説を立て検証を行った。

 

【原因の仮説】

(1)クライアント要件の抜け漏れ

(2)不十分なテストと不具合の残存

(3)クライアント要件に対する開発メンバーの理解不足

 

結果は、以下の通りとなった。

【仮説の検証】

(仮説1)クライアント要件の抜け漏れ

▷要件定義、基本設計書、詳細設計書からクライアント要件が漏れていなかったか？

➡︎YES

 

(仮説2)不十分なテストと不具合の残存

▷結合テスト、総合テストは100%消化して、不具合修正率は100%であったか？

➡︎YES

 

(仮説3)クライアント要件に対する開発メンバーの理解不足

▷作成したユースケースを使って、正しい業務運用ができるか？

➡︎NO

 

問題の根本的な原因は、『仮説3』と判明した。

また、正確に要件を理解していない範囲を調査したところ、一部のクリティカルな要件であることが分かった。

STEP3：解決策

この問題を放置することは、デスマーチプロジェクトの危険があるため、PMOの私は解決策を３つ考え、プロジェクトオーナーの山田と協議した。

 

【解決策の候補】

解決策A：

全てのクライアント要件を確認するために、再度要件定義を実施してリリース日を延期する。

 

解決策B：

一部のクリティカルな要件に対して、再度要件定義を実施する。

 

解決策C：

一部のクリティカルな要件に対して、再度要件定義を実施しリリース日を延期する。

 

調査の結果から、正確に要件を理解していない範囲を調査したところ、一部のクリティカルな要件であることが分かっている。

その状況をプロジェクトオーナーの山田へ説明し、山田の意向を踏まえ解決策を決定した。

 

【採用した解決策と採用の根拠】

山田の意向は、 一部のクリティカルな要件に対して、再度要件定義を実施することに問題はないとの見解であった。

しかし、リリース日の延期は避けて欲しいとの要望があり、『解決策B』を採用した。

 

 【解決策の実行に伴うダメージ】

また、今回の解決策を実施したことで、クライアントに再要件定義レビューに対する工数が30%超過した。

また、ITベンダーに要件定義の設計、レビューに対する工数が30%超過した。

今回の問題における原因は、クライアント要件に対する開発メンバーの理解不足ということである。

今後、このような事態を避けるために、以下を教訓とした。

(1)要件定義工程の終盤で要件理解の説明を実施し合否判定する。

(2)結合テストでクリティカル要件のみ動作テストを実施し合否判定する。

(3)マイルストーンにITベンダーの要件理解を設定する。 

STEP4：リスク管理表の作成

最後に、今回プロジェクトで起こった問題を課題問題整理表に記述し、今後のプロジェクトの教訓として役立てるためにリスク管理表に記述した。

このリスク管理表は、ITベンダーのプロジェクト情報として保管され、他チームへの情報共有として利用することになった。

 

最後まで、読んで頂き有難うございました。

今後の貴方のプロジェクト活動の参考になれば幸いです。

このトラブルプロジェクトは私が対応しました！

www.abmtraining.net