writing by Yuichiro Hayashi
ITプロジェクトの終盤に実施されるユーザーテスト（所謂、受入テスト）で、顧客から『開発した機能が要件を満たしていないだよね〜』なんて、言われたらプロジェクトは大失敗ですよね？ これって、初心者PMに限らず、ベテランでもやっちゃう問題なんです。 あなたの周りにこのようなことで困っているPMはいませんか？ あなたが、このような炎上プロジェクトの主役にならないように『開発した機能が要件を満たしていない』をリスクと捉えPJ計画の段階でリスク管理表に書き込んでおいてくださいね。
監修：プロコンサル Osamu 2001年に大手コンサルファームBにジョイン。 ITコンサルタントとして複数のシステム開発プロジェクトのPM・PMOに従事。 2016年よりSIerの取締役として、BtoC向けスマートフォンアプリ開発サービスのビジネススケールに貢献。 2019年にITコンサルファームを設立。大手金融会社の新規事業のIT担当として、脳機能を定期的に測定することにより、認知機能の変化を把握するシステムの開発を担当し自社ビジネスを拡大。
最初に見てもらったのが、プロジェクトマネージャであれば、押さえておきたいリスク事象の一つなんですね。 このようなリスクが起こりやすいプロジェクトには特徴があるんです。 特徴1： 顧客が提示したRFPに必要な内容が漏れている（記載されているが根拠無し）。 特徴2： 要件定義工程の所要期間が極端に短い。 特徴3： 要件定義工程で、開発チームのスキル不足によりヒアリングが間違っている。 特徴4： 開発チームが要件定義の意図を理解していない。 特徴5： PMが顧客の言いなりで全く調整をしないままプロジェクトを推進している。 あなたが、参加しているプロジェクトが特徴1〜特徴5に当て放っていたら、炎上プロジェクトの予感がしますので、細心の注意を払ってマネジメントしてくださいね。
このコラムでは、炎上プロジェクトの実例をあなたに紹介することで、プロジェクトのリスクをINPUTしてもらいマネジメントに役立ててもらえればと思ってます。
また、炎上プロジェクトの火消しまでのアプローチをたどれるように、このような順番で解説していきます。
approach1：根本的な問題
approach2：根本的な原因
approach3：解決策
今回は、『開発した機能が要件を満たしていない』というテーマで、話しをスタートしますね！
**守秘義務により企業名・団体名・個人名等は架空名称となります。
炎上プロジェクトの概要
ユーザテスト工程で開発した機能に、クライアントの要件が盛り込まれていないことによる炎上プロジェクト 1.プロジェクトのスコープと体制 ・顧客は大手水産物加工会社である。 ・顧客の情報システム部で新規構開発を実施。 ・システム化スコープは製造管理、物流管理、倉庫管理が対象である。 ・中堅SierのA社が開発ベンダーとして参画。 ・A社は全開発工程の成果物の納品、システムリリースの責任を請け負う。 ・A社の開発体制は業務チーム・基盤チーム・テストチーム・管理チームで構成。 2.プロジェクトの状況 ・現在、プロジェクトはユーザーテスト（受け入れ）工程を行なっている。 ・顧客は業務フローに従って本番業務を意識しながらテストを行なっていた。 ・しかし、顧客が想定していた結果が得られず、要件を満たしていないシステム機能が多数あることが判明した。 ・これはITチームの要件定義の進め方が間違っていた訳ではなく、業務やシステムの理解が不足していた。 ・そのため、システムのリリースが出来ない状態となっている。 *今回の実例は、炎上プロジェクトの特徴として『特徴3：要件定義工程で、開発チームのスキル不足によりヒアリングが間違っているケース』である。
炎上プロジェクトの火消しまでのアプローチ
approach1：根本的な問題の定義
顧客、PM、開発メンバのヒアリングから今回の根本的な問題を『開発した機能が要件を満たしていない』と定義しました。 approach2：根本的な原因の追求 このようなケースでは、『要件定義工程のアウトプットの精度』、『テスト工程におけるテスト内容の網羅性』、『開発メンバのスキルレベル』に焦点を当てて根本的な原因を探ることが重要です。 そのため、以下のように原因の仮説を立てました。 (1)原因の仮説 ①業務・システム要件の抜け漏れがある。 ②不十分なテストと不具合の残存している。 ③要件に対する開発メンバーの理解不足である。 (2)仮説の検証 仮説の検証として、関係者へレビューをしました。
(3)根本的な原因
レビューを通じて根本的な原因を探った結果、『要件に対する開発メンバーの理解不足である』ということが判明しました。
approach3：解決策 (1)解決策の案 根本的な原因から3つの解決策（案）を準備しました。 【解決策A】 全ての要件（業務・システム）を確認するために、再度要件定義を実施してリリース日を延期する。 【解決策B】 一部のクリティカルな要件に対して、再度要件定義を実施する。 【解決策C】 一部のクリティカルな要件に対して、再度要件定義を実施しリリース日を延期する。 (2)実行した解決策 プロジェクトに問題が起こった場合は、問題の大きさは関係ありません。 プロジェクトの管理要素である『品質』、『コスト』、『スケジュール』、『スコープ』のいずれかを調整することになります。 *プロジェクトの成功のためのトレードオフを仕掛ける。 結末は以下の通りとなりました。 【解決策】 解決策B： 一部のクリティカルな要件に対して、再度要件定義を実施する。 【解決策を選んだ理由】 ・開発チームが正しく要件を理解していない範囲は一部のクリティカルな要件であった。 ・顧客と協議したところ、一部のクリティカルな要件の再度要件定義を行うことに問題はないという見解であった。 ・顧客から『リリース日の延期は避けてほしい』との要望があった。
教訓の整理
このような炎上プロジェクトは、リスク対策として、あなたのプロジェクトマネジメントに活かしてくださいね。 プロジェクトで一番怖いのは、開発チームが顧客の要件を理解しないでシステムを作ってしまうことではないでしょうか？ 開発チームと顧客が、プロジェクトを遂行していく中で、要件定義工程以降にPMが『要件の確認ポイント』を設けていなかれば、ユーザテスト工程（最終工程の受け入れテスト）で発覚するのは当然ですよね！ この時点で、要件違いのシステムが出来上がっていれば、プロジェクトは失敗なんです。 今回の教訓からリスク対策を以下のように整理しました。 【リスク対策1】 要件定義工程の終盤で要件理解の説明を実施し合否判定する。 【リスク対策2】 結合テストでクリティカル要件のみ動作テストを実施し合否判定する。 【リスク対策3】 マイルイストーンとして開発チームの要件理解の確認を設ける。 あなたのプロジェクトマネジメントにお役に立てば幸いです。
QAセッション
失敗プロジェクトの原因に関する質問に答えるQ&Aセッションを設けています。 皆さんの疑問や質問に対応することができます。 失敗プロジェクトに対する理解を深め、同じような失敗を回避するためのアドバイスをします。 iPM naviのサイトにアクセスしてコミュニティーに登録してください。 大手コンサルファームの社員や出身者が無料でアドバイスします。 ファームの人材とコミュニケーションが取れるイイ機会です。 是非、ご利用ください。 またコミュニティでは今回の失敗プロジェクトをプロジェクトの教訓としてリスク管理表にまとめました。 こちらも併せてチェックしてください!!
*メンバー登録（無料）する前にiPM naviでどんなことができるのか？を確認する。
最後まで読んでくれて有難う御座いました。
プロジェクトマネージャーを目指すなら必見！計画書の作り方を解説
プロジェクトマネージャーになるために欠かせないスキルの一つが、プロジェクト計画書の作成です。 しかし、初めて計画書を作成する人にとっては、何から手を付けていいか分からず苦戦することもあります。 そこで、プロジェクト計画書の作成手順を分かりやすく解説します。
