システム開発を発注するとき、多くの担当者は「要件定義」を、自分たちが要望を伝えて、システム会社がそれを形にする作業だとイメージしています。つまり、発注側が指示を出し、受注側がそれを受け取って進める、一方通行のやり取りです。

しかし、この認識のまま要件定義を進めると、高い確率でプロジェクトはうまくいきません。私たちEFGが要件定義で最も大切にしているのは、「二人三脚」であるという姿勢です。発注側から要望を受け取って終わりではなく、こちらから何度も質問し、時には発注側も気づいていなかった業務の実態を一緒に掘り起こしていく。そういう共同作業として要件定義を捉えています。

この記事では、EFGが実際にどのように要件定義を進めているのか、なぜそこまで徹底的に対話するのかを、正直にお伝えします。良いことばかりではありません。お客様側にも一定の負荷がかかる、という事実も含めてお話しします。

「思っていたものと全然違う」「追加費用が膨らんで収拾がつかない」「納期が何度も延びて、結局リリースできなかった」――システム開発の失敗談は、業種を問わずよく耳にします。

しかし不思議なことに、失敗の原因として「要件定義」が挙がることは少ない。多くの場合、「開発会社の技術力が低かった」「プロジェクトマネジメントが甘かった」という話に落ち着きます。本当にそうでしょうか。

私たちEFGはこれまで多くのシステム開発に携わり、他社が炎上させた案件のリカバリーも経験してきました。その経験から言えること――失敗の根っこのほとんどは、プロジェクトの最初、要件定義の段階にあります。この記事では、その実態と、発注側が知っておくべきことを解説します。