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

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

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

システム開発の失敗、実はパターンがある

システム開発の失敗は、一見バラバラに見えても、実はいくつかの典型的なパターンに分類できます。

「思っていたものと違う」パターン

完成したシステムを見て、発注した側が「これじゃない」と感じるケースです。機能は一通り揃っているのに使い勝手が悪い、現場の業務フローに合っていない、といった状況がこれにあたります。

「追加・追加で予算が膨らむ」パターン

開発が進むにつれて「やっぱりこの機能も欲しい」「この仕様は変えてほしい」という変更要求が積み重なり、当初の見積もりから大幅に予算が膨らむケースです。追加費用の請求が届くたびに頭を抱える、という状況になります。

「納期が延び続ける」パターン

「来月には」「もう少しで」と言われ続け、リリース予定日が何度も後ろ倒しになるケースです。現場はリリースを待ちわびているのに、いつまでも稼働できない。

「稼働したけど誰も使わない」パターン

システムは完成してリリースもされたのに、現場のスタッフが使いこなせず、気づけば以前のExcel管理に戻ってしまっていた――というケースです。

たいていの原因は、最初の「要件定義」にある

納期遅延は「開発が遅かった」から起きるのでしょうか。追加費用は「見積もりが甘かった」から発生するのでしょうか。

もちろんそういうケースもあります。しかし私たちが実際に現場を見てきた経験では、多くの場合、最初の要件定義の段階で「何を作るか」が曖昧なまま動き出していたことが原因です。

作るものがはっきりしないまま開発が始まると、途中で「やっぱりこうしたい」という変更が頻発します。変更が発生するたびに設計を見直し、コードを書き直し、テストをやり直す。これが追加費用と納期遅延の正体です。「思っていたものと違う」も「誰も使わない」も、すべて最初のボタンの掛け違いから来ています。後工程の問題に見えて、根っこはすべて上流にあります。

そもそも「要件定義」とは何か

ITに馴染みのない方にとって、「要件定義」という言葉は少し難しく聞こえるかもしれません。ただ、内容はシンプルです。

「何を作るかを、開発前に明確に決めるプロセス」

それだけです。

何を決めるのか

要件定義で整理する内容は、大きく3つに分けられます。

業務要件：そもそもどんな業務課題を解決したいのか。どの業務をシステム化したいのか。誰が使うのか。現在の業務フローはどうなっているのか。これが出発点です。

機能要件：必要な機能は何か。反対に、不要な機能は何か。どんな画面が必要で、どんなデータを扱うのか。「欲しいもの」の具体的なリストです。

非機能要件：セキュリティはどの程度必要か。どれくらいの速度で動く必要があるか。将来的に機能を追加する可能性はあるか。「欲しいもの」以外の条件です。

これらを開発会社と発注側が一緒に整理し、文書化します。この文書が後工程すべての設計の基準になります。

なぜ難しいのか

「自分が何をしたいかくらいわかっている」と思う方も多いでしょう。しかし実際にやってみると、意外に難しい。

業務の全体像を言語化しようとすると、「あの作業はどうなっているんだっけ」「現場によってやり方が違う」「例外的なケースが意外と多い」という現実が次々と出てきます。日常的にやっている業務でも、言葉にしようとすると抜け漏れが出るものです。

だからこそ要件定義は時間がかかります。そしてだからこそ、発注側と開発側が密に対話しながら進めることが不可欠なのです。建築に例えるなら、設計図を描く前に「どんな家にしたいか」「部屋数は」「予算は」「ライフスタイルは」を建築士とじっくり話し合う工程です。ここをすっ飛ばして「とにかく家を建ててください」と言う人はいない。でもシステム開発ではこれが起きます。

システム会社ならみんなできると思ったら大間違い

ここで多くの発注担当者が見落としていることがあります。要件定義をきちんとできるシステム会社は、思ったより多くないという現実です。

パターン1：「お客様でやってください」型

「要件定義はお客様側でまとめてください。仕様書ができたらお知らせください」というスタンスの開発会社が存在します。技術力はあっても、要件を引き出すヒアリング力がない。あるいはそこに工数をかけることを嫌がる。

このタイプの会社に発注すると、発注側が自力で要件を整理しなければなりません。ITの専門知識がない状態で仕様書を書くことになり、抜け漏れや認識のズレが生まれやすくなります。

パターン2：「何でもYES」型

発注側の要望を何でも「わかりました」と受け入れ、要件定義をスムーズに終わらせる会社です。一見、話が早くて良さそうに見えます。

しかしこれが一番危険です。発注側の要望には、矛盾していたり、技術的に実装が難しかったり、後から考えると不要だったりするものが必ず含まれます。それを整理・指摘せずに「YES」と言い続けると、設計・実装の段階で必ず破綻します。「言った通りに作ったのに、なぜ追加費用が発生するのか」というトラブルの多くは、このパターンから生まれます。

EFGが引き継いだ炎上案件の実態

EFGはこれまで、こうした会社が関わったプロジェクトの炎上案件をリカバリーした経験が複数あります。現場に入ってみると、状況はほぼ共通しています。

要件定義書は存在するのに内容が曖昧で、読んでも何を作るべきかわからない。仕様に矛盾があるのに誰も指摘していない。発注側と開発側で「合意したはずの内容」の理解が食い違っている。こうした状態で開発が進み、後から取り返しのつかない状態になっていました。

開発会社を選ぶとき、技術力や実績だけでなく「要件定義にどう向き合うか」を必ず確認してください。「要件定義の進め方を教えてください」と質問したときの答えに、その会社の姿勢が出ます。

発注側がやるべきことはシンプル

「では発注する側は何をすればいいのか」と思われるかもしれません。難しいことはありません。ただ、一定の負荷がかかることは正直にお伝えします。要件定義は開発会社に丸投げできるものではなく、発注側も積極的に関わることが必要です。

業務の流れを言葉にする

現在どんな業務をどんな手順でやっているか、どこが非効率でどこを改善したいのかを言語化することが最初の仕事です。「なんとなく不便」「なんとなくこうしたい」ではなく、具体的な言葉にする。「月末に請求書を手作業でExcelに入力していて2時間かかっている」「担当者によってやり方がバラバラで引き継ぎのたびにミスが起きる」といった具合です。現状の業務フローを図や箇条書きで書き出してみるだけで、開発会社との対話が格段にスムーズになります。

現場の声を集める

実際にシステムを使う現場のスタッフの意見を事前に集めておくことも重要です。経営者・担当者の視点と、現場の視点は必ずしも一致しません。「上は効率化したいと言うけど、現場としてはこの機能がないと困る」「実はこの作業が一番時間がかかっている」――こうした現場の声が要件定義に反映されないと、完成したシステムが現場に合わないという事態になります。少なくとも、実際に使う現場のキーパーソンを打ち合わせに参加させることをお勧めします。

決める権限を持った人が関わる

要件定義の打ち合わせで「持ち帰って上に確認します」が繰り返されると、プロジェクトの進行が止まります。その場で判断できる人が関わることが、プロジェクト全体のスピードに直結します。現場担当者だけでなく、予算や方針を決められる立場の人間が早い段階で関与することが理想です。後から「やっぱり方針が変わった」という事態を防ぐためにも、意思決定者が要件定義に関わることが重要です。

要件定義への投資が最大のコスト削減になる

システム開発の失敗を防ぐ最も効果的な手段は、要件定義に時間とコストをかけることです。最初が曖昧なまま進めると、後から修正するたびにコストが膨らみます。設計後の変更は要件定義段階の数倍、実装後の変更はさらにその数倍のコストがかかると言われています。最初に丁寧にやることが、トータルでは最も安い選択です。

EFGでは、この要件定義のプロセスを最も重要な工程と位置づけています。お客様の業務をお客様と同じ解像度で理解できるまで、徹底的に対話します。時間はかかります。でもここで時間をかけることが、後工程のすべてをスムーズにします。

初めてシステム開発を検討している方は、まずこの一点を覚えておいてください。「いい開発会社は、要件定義を大切にする」。要件定義に真剣に向き合ってくれる会社は、それだけプロジェクトの成功に本気だということです。

よくある質問

さいごに

システム開発の失敗は、多くの場合、最初の要件定義の段階で起きています。後工程の問題に見えても、根っこは上流にある。この認識を持つだけで、開発会社の選び方も、プロジェクトへの関わり方も変わってくるはずです。

EFGは要件定義から一緒に考えます。「何を作ればいいかよくわからない」という段階からでも、ぜひお気軽にご相談ください。