top of page

開発した機能が要件を満たしていない -リファイン-

開発した機能が要件を満たしていないことに憤慨する顧客の画像

このブログがリファインされました!


より分かりやすく、実践で活用しやすい情報に更新しました。


リファインのポイントは以下のとおりです。


・『初心者PMが陥りやすい「開発した機能が要件を満たしていない」問題』という新しいセクションを追加して、詳しく解説しました。


・現在のITプロジェクトのトレンドや現場のニーズに合わせた情報を追加しました。


・リスク管理の重要性を更に明確にし、実践での学びを提供しています。


リファインされた内容を確認したい方は、無料会員登録をしてください!



会員になると、他のリファインブログや追加コンテンツも閲覧可能です!

 

writing by Yuichiro Hayashi


ITプロジェクトの終盤に実施されるユーザーテスト(所謂、受入テスト)で、顧客から『開発した機能が要件を満たしていないだよね〜』なんて、言われたらプロジェクトは大失敗ですよね? これって、初心者PMに限らず、ベテランでもやっちゃう問題なんです。 あなたの周りにこのようなことで困っているPMはいませんか? あなたが、このような炎上プロジェクトの主役にならないように『開発した機能が要件を満たしていない』をリスクと捉えPJ計画の段階でリスク管理表に書き込んでおいてくださいね。


 

最初に見てもらったのが、プロジェクトマネージャであれば、押さえておきたいリスク事象の一つなんですね。 このようなリスクが起こりやすいプロジェクトには特徴があるんです。 特徴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】 マイルイストーンとして開発チームの要件理解の確認を設ける。 あなたのプロジェクトマネジメントにお役に立てば幸いです。


 

(無料)iPM naviの無料会員になると!こんな特典があります!

WBS作成やリスク管理を学ぶブログ、実務相談ができるコミュニティ、リハーサルシミュレータで実践力を身につけよう!

初心者PM向けの実践ノウハウを今すぐチェック!プロジェクト成功のコツが詰まっています。




プロジェクトリハーサルシミュレータのお知らせ

プロジェクト管理を学びたいけれど、どこから始めればいいか迷っていませんか?初心者PM向けに特化した『プロジェクトリハーサルシミュレーター』をぜひお試しください!


- 詳細説明:  

このシミュレーターでは、プロジェクト運営で直面しがちな『予算オーバー』『遅延』『仕様変更』等といった課題を疑似体験しながら、実務に役立つスキルを楽しく学べます。 




Commentaires

Noté 0 étoile sur 5.
Pas encore de note

Ajouter une note
bottom of page