開発ベンダーとの行き違いは要件定義で回避する【第4回】

　RFP（Request for Proposal:提案依頼書）に対する、いくつかの魅力的な提案の中から最適な開発パートナーを選び契約を結べば、いよいよ自社サービスの開発プロジェクトがスタートします。そのプロジェクト成功の鍵を握るのが「要件定義」です。

要件定義でゴールのイメージを共有する

　要件定義とは「発注者と開発会社が一体となり『誰のために』『何を目的として』『どのような機能が必要か』を徹底的に話し合い合意するプロセスです。単に必要な機能のリストを作る作業でなく、プロジェクトゴールのイメージを正確に共有するための作業です。

　要件定義で合意された内容は「要件定義書」として文書化します。これは、いわばシステムの“設計図”の元になる最も重要なドキュメントになります。「何ができるか」を定めた機能要件だけでなく、必要な性能やセキュリティ、使いやすさといった非機能要件までを明確に定義します。

　この工程が最も重要なのは、ここでの認識のズレが以後の工程での手戻りやトラブルの最大の原因になるからです。「こんなはずではなかった」という行き違いのほとんどは、要件定義のあいまいさが引き起こします。

　プロジェクトが始まったばかりの段階では、難しい問題や決め切れないことを「後工程で決めればいいか」と先送りにしがちです。ですが、これが命取りになります。特に、前工程が完了しないと次の工程に進めないウォーターフォール型の開発では、この“先送り”が後で発覚した場合、プロジェクト全体を停滞させる“致命傷”になりかねません（図1）。

図1：あいまいな要件定義は、それ以後の工程に、さまざまな問題を引き起こす

　現時点で、どうしても決められない事柄がある場合は「こういう条件の場合はA案、そうでなければB案」といった形で条件を設けて、次工程への申し送り事項として文書に残します。全く議論しない状態だけは絶対に避けねばなりません。

　最重要工程である要件定義だけに、ベンダー任せにせず、発注者自身が「自分たちは何を達成したいのか」を徹底的に議論し細部まで合意する必要があります。この土台固めこそがプロジェクトの運命を左右するのです。