ITプロジェクトの失敗または赤字プロジェクトの話題が多い昨今です。その要因を調べてみると明らかに「要求定義」フェーズでの問題が浮かび上がってきます。

日経コンピュータ（2003, 11, 17）のデータです。すでにご存知の方も多いと思います。それだけ有名な資料です。

プロジェクトにおいての問題です。

・       品質問題　　53.6%

・       納期遅延　　45.1%

・       コスト超過　23.8%

　3種のいずれか、もしくはその複合したものもあります。

　3種の各失敗の中でも因果関係があるようです。

そして、成功しているプロジェクトはなんと、わずか26.7%だそうです。

では、品質問題と納期遅延の原因はどのようなものでしょうか。これも同じ日経コンピュータです。

システムの品質問題の原因

　　　　　　　　　　　　　（有効回答数：498件）

なんと「要件定義」が35.9%と圧倒的にナンバー1です。

それでは、納期遅延はどうでしょうか。

プロジェクトの遅れを招いた原因

　　　　　　　　　　　　　　（有効回答数：621件）

こちらも「要件定義」がナンバー1です。

もうひとつ重要なことがあります。それは手戻りのコストです。

かねてから、東西の有識者から指摘されていますが、その代表的なものは以下のとおりです。

・     手戻りは、全開発費の30〜50%を消費する（Boehm and Papaccio, 1988）

・     要求の誤りは手戻りコストの70〜85%を占めている（Leffingwell ,1997）

・     プロジェクトが進んでからわかった欠陥を修正する費用は、早期に修正する費用よりはるかに多額である（Grady,1999）

手戻りの中でも、特に要求定義フェーズでの欠陥の、後工程における修正コストの大きさが指摘されています。

どうしてこんなに、「要求定義」に問題があるのでしょうか。

もう少しデータをご覧ください。

日経IT Proのデータをご紹介します。

ユーザ側の要求そのものが確定しづらいことも大きな要因です。

開発側とのコミュニケーションに問題があります。

そもそも、ユーザは自分の要求を明確に認識しているのか、と疑いたくなります。

かなり怪しいユーザが多いのも事実のようです。

しかも、開発側がコミュニケーションをあまり得意としないエンジニアだったとしたら、どんなことが起きるのでしょうか。

ではどんなドキュメントを作成しているのでしょうか。

これも日経IT Proのデータです。

意外とテキスト文書が多いことに気がつきます。

「機能要求（文書による）」、

「システムの目的をまとめた文書」、

「業務ルールを定義した文書」、

「性能や運用面、信頼性などの非機能要求を記した文書」

どちらかと言うと、エンジニアの苦手な分野ではないでしょうか。

（「理科系の作文技術」（木下是雄著：中公文庫）という名著を思い出すのは筆者だけでしょうか。これだけで解決できるほど問題は単純ではありませんが。）

だいぶ、問題が見えてきたような気がします。

・     ユーザ自身が自分たちの要求を把握できていない。

・     開発側が要求を聞きだせるほどのコミュニケーション能力を持っていない

・     要求定義フェーズで必要とするドキュメント作成能力（作文技術）があまり得意でない

これでは、要求定義フェーズで問題が発生するのも無理ないことです。

顧客のベンダーへの要望はどうでしょうか。

これも日経IT Pro（）ですが。

「プロジェクト遂行能力」が最も重みが高く（30）、次に「要求への対応度」（25）が続きます。「RFPへの理解」（10）もかなり高いですね。いくらプロジェクト遂行能力が高くても「要求への対応」ができていなければ意味がありませんね。その意味では、要求への対応、すなわち「要求定義」が最も重要とみてさしつかえなさそうです。

「RFPへの理解」では顧客のビジネスへの理解も重要です。

ぜひ続きをお読みください。
［続く］


「失敗しない要求定義」コース