開発した機能が要件を満たしていない！〜炎プロ#1

こんな気持ちを持っているあなたはこれを読んでください。
⚫︎PMOやPMで参画しているプロジェクトを炎上させたくない
⚫︎炎上プロジェクトの実例からリスク管理表を作りたい
⚫︎今すぐトラブルを解決する"きっかけ"が欲しい

あなたもプロジェクトで、こんな空気を感じたことがあったんじゃないでしょうか？
①RFPに記載されている業務要件・システム要件を精査せず鵜呑みにして進めている。
②要件定義工程の所要期間が極端に短いと疑いを持つ。
③要件定義工程で、開発チームのスキル不足によりヒアリングが間違っている疑いを持つ。
④開発チームが要件定義の意図を理解していないのではと半信半疑。
⑤PMが顧客の言いなりで全く調整をしないままプロジェクトを進めている。

どのプロジェクトでも、このような空気はあります。
何か胡散臭いことが起こりそうな気配を持っています。
しかし、トラブルが多いPMは『こんな些細なことを気にしたらプロジェクトが進まない』と自分自身に言い聞かせ、放置していることが多いものです。
（本来は、このような空気感があれば直ちに対処ですが）

こんにちは！
フリーランスPMO商工会議所の林です。
『PMOなら知っておきたい炎上プロジェクトの火消し方法』の第1回目となります。
このシリーズでは、フリーランスPMOのあなたへ炎上プロジェクトの実例から得られた教訓をスキルシェアリングします。
また、5分で理解できて、即日現場で使えるように心掛けています。

今回は『開発した機能が要件を満たしていない！』というトラブルをテーマに取り上げます。
このトラブルは、冒頭で紹介したプロジェクトの空気がトリガーになることが多いものです。

☑︎取り上げる炎上プロジェクトの概要
ユーザテスト工程で開発した機能に、顧客要件が盛り込まれていないことによる炎上プロジェクト
☑︎もしこんなプロジェクトにあなたがいたら要注意
①RFPに記載されている業務要件・システム要件を精査せず鵜呑みにして
　進めている。
②要件定義工程の所要期間が極端に短いと疑いを持つ。
③要件定義工程で、開発チームのスキル不足によりヒアリングが間違ってい
　る疑いを持つ。
④開発チームが要件定義の意図を理解していないのではと半信半疑。
⑤PMが顧客の言いなりで全く調整をしないままプロジェクトを進めてい
　る。

さて、今回のテーマを告知通り、『問題解決マップ』で炎上プロジェクトを整理して『リスク管理表』に落とし込んでいきたいと思います。

👍この記事の信頼性
私自身が直接携わった炎上プロジェクト、クライアントの依頼で検証した炎上プロジェクト、これら総数2,000以上のプロジェクトから、リスク頻度が高いであろう事象を選んで紹介しています。

---

■PROLOGUE

プロジェクトで一番怖いのは開発チームが顧客の要件を理解しないでシステムを作ってしまうことです。
開発チームと顧客がプロジェクトを遂行していく中で、要件定義工程以降にPMが『要件の確認ポイント』を設けていなかれば、ユーザテスト工程（最終工程の受入テスト）で発覚します。
この時点で、要件違いのシステムが出来上がっていればプロジェクトは失敗となります。
PMOは、プロジェクトの歪みやリスクを回避するための指南役・支援役です。
リスク事象として頭の中にインプットしておき、プロジェクト工程の中で何かしらの工夫が必要となります。

【工夫の一例】

☑︎要件定義工程の終盤で、開発チームが顧客へ要件理解の説明を行い、
　お互いの齟齬を解消する。
☑︎結合テスト工程でクリティカル要件のみ顧客が動作テストを行い、
　お互いの齟齬を解消する。

意外にも、このようなことを知らないPMや実施しない開発チームが多いってご存知でしょうか？
今回の炎上プロジェクトが、まさにこの実例となります。
それでは炎上プロジェクトの火消し方法を解説するので、じっくり読んでください。

※この記事は1週間限定で公開しています。

---

■炎上プロジェクトの火消し方法

取り上げる炎上プロジェクトの概要
ユーザテスト工程で開発した機能に、顧客要件が盛り込まれていないことによる炎上プロジェクト

今回の炎上プロジェクトの実例から得られた教訓をリスク管理表へ落とし込んでいきます。
この記事では以下を解説していきます。
(1)どのようなプロジェクトの事だったのか
(2)根本的な問題は何だったのか
(3)たどり着いた根本的な原因は何だったのか
(4)どのような解決策を講じたのか
(5)リスク管理表へはどのように取り込んだのか

★時間時間が足りない▶︎あなたには”倍速読み”
忙しくて全文を読む時間が足りない！
そんな、あなたへ今回のテーマで解説する内容をイメージでインプットできるようにを『倍速読み』を用意しました。

※倍速読みは概略解説です。以降の本編を読むことで炎上プロジェクトの具体的な火消し方法が分かります。

(1)プロジェクトの事象

■どのマネジメントエリアで起こった事象なのか
品質マネジメントエリア
■炎上の内容
プロジェクトはユーザテスト工程に入り、顧客は業務フローに従って本番業務を意識しながらテストを行なっていました。
しかし、顧客が想定していた結果が得られず、要件を満たしていないシステム機能が多数あることが判明したことから、システムのリリースが出来ない状態になっていました。
また、今回の実例は、PMが『要件定義工程で、開発チームのスキル不足によりヒアリングが間違っていそうだという空気感』を放置したことで炎上しました。

プロジェクトの事象

(2)根本的な問題

顧客、PM、開発メンバのヒアリングから今回の根本的な問題は『開発した機能が要件を満たしていない』と定義しました。

根本的な問題

(3)根本的な原因

要件定義工程で、開発チームのスキル不足によりヒアリングが間違っていそうだという空気感から、このような問題に発展した場合は、以下のようなことに焦点を当てて根本的な原因を探ることが重要です。
・要件定義工程のアウトプットの精度
・テスト工程におけるテスト内容の網羅性
・開発メンバのスキルレベル
これらの観点から原因の仮説を立てました。
■原因の仮説
①業務・システム要件の抜け漏れ
②不十分なテストと不具合の残存
③要件に対する開発メンバーの理解不足

---

公開から1週間が経ちましたので、以降は有料になります。
【有料の範囲】
①根本的な原因の特定
３つの原因の仮説をレビューを通じて検証した結果から根本的な原因に絞り込みました。
②解決策
3つの解決策案を考え出し状況に応じた解決策を選びました。
③リスク管理表
今回の炎上プロジェクトの教訓をリスク管理表に整理しました。
④全体のまとめ
今回の炎上プロジェクトについてPDFをダウンロード出来ます。