「要件定義をしっかりやらないと失敗する」——システム開発について調べ始めた発注者なら、もう何度もこの言葉を目にしているはずです。落とし穴の一覧、失敗パターンの分類、注意すべきチェックリスト。どの記事もそれなりに正しいことを書いています。
けれど、リストをいくら読んでも、なぜか自分のプロジェクトには落ちてこない。「要件の抜け漏れに注意」と言われても、自分の手元にある要件定義書のどこが抜けているのか分からない。「合意形成が大事」と言われても、自分たちの打ち合わせは和やかに進んでいて、どこに危険が潜んでいるのか実感できない。漠然とした不安だけが残ります。
その理由は、失敗が「リスト」として整理された瞬間に、実際のプロジェクトが持っていた時間の流れと当事者の心理が抜け落ちてしまうからです。本当の失敗は、最初から「これは失敗するぞ」と分かる形ではやってきません。むしろ「順調に見えていた」プロジェクトが、ある一つの判断を境に、誰も気づかないうちに崩れていく。その分岐点こそが、発注者が知りたい肝心な部分です。
そこでこの記事では、Webシステム開発でよく起こる4つの失敗を、類型のリストではなく「時系列の物語」として再現します。それぞれのケースで、プロジェクトがどこから始まり、どの場面で運命が分かれ、発注者がその瞬間にどう動けば結末が変わっていたのかを、追体験できる形で深掘りします。読み終えるころには、「自分のプロジェクトはあのケースに近い」「次の打ち合わせではここを確認しよう」という具体的な一手が見えているはずです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
要件定義の失敗は「リスト」ではなく「物語」で理解する
なぜ「失敗事例リスト」は自分のプロジェクトに活かしにくいのか
失敗事例を「落とし穴5選」「7つのパターン」のように整理した記事は、全体像を素早く把握するにはとても役立ちます。一方で、リスト形式には構造的な弱点があります。それは、失敗を「結論」だけで切り取ってしまうことです。
たとえば「現場の業務を十分にヒアリングしなかった」という落とし穴は、文字にすればたった一行です。けれど実際のプロジェクトでは、発注者は決して手を抜いていたわけではありません。きちんと打ち合わせを設定し、現場の代表者にも話を聞き、開発会社も丁寧に対応してくれていた。それでも結果として要件が抜けた——この「真面目にやっていたのに転んだ」という生々しさは、リストからはこぼれ落ちてしまいます。
発注者が本当に知りたいのは、「何が抜けがちか」というラベルではなく、「自分と同じように順調だと思っていた人が、具体的にどの場面で、どんな判断をして、その結果どうなったのか」という時間の流れです。物語として追体験して初めて、「あ、この場面は自分のプロジェクトにもある」と気づけるのです。
データで見る、要件定義の失敗が後工程に与えるダメージ
要件定義の不備が厄介なのは、それがその場では表面化せず、後工程で増幅しながら表に出てくる点です。ソフトウェア開発の世界では古くから「上流工程の誤りは下流工程で増幅する」と言われてきました。要件定義の段階で見過ごされた認識のズレは、設計・開発を経て、テストや稼働の段階で初めて「思っていたものと違う」という形で噴き出します。そして発見が遅れるほど、すでに作り込んだものを作り直すことになり、修正の手間と費用は雪だるま式に膨らみます（参考: 上流工程のバグは、下流工程で増幅する（@IT））。
プロジェクトの遅延や予算超過の原因をさかのぼると、その多くが要件定義段階の認識のズレや決め切れなかった事項に行き着く——これは、一般社団法人日本情報システム・ユーザー協会（JUAS）の企業IT動向調査をはじめとする各種調査でも繰り返し指摘されてきた傾向です。要件定義は「最初のちょっとした打ち合わせ」ではなく、プロジェクト全体の成否を左右する分岐点が集中する局面だと言えます。
ここで強調しておきたいのは、こうした失敗は発注者や開発会社の能力不足から起きるとは限らない、ということです。むしろ「順調に見える中で、誰も悪意なく、自覚のないまま進んでしまう」ことに本質があります。だからこそ、結果論のリストではなく、進行中の物語として失敗を理解する価値があるのです。
この記事の読み方
これから紹介する4つのケースは、すべて同じ構造で読めるようになっています。
- 何が起きたか（時系列の物語）: プロジェクトの立ち上がりから破綻までを、当事者の視点で時間順に追います。
- 運命の分岐点: その物語のなかで「ここで判断を変えていれば結末が違った」という一点を特定します。
- 発注者が取れた一手: その分岐点で、発注者が実際に何を言い、何を確認すればよかったのかを具体化します。
自分のプロジェクトと照らし合わせながら、「これは似ている」「ここは大丈夫そうだ」と確かめるように読んでみてください。なお、システム開発がフェーズごとにどこで失敗しやすいかを俯瞰したい場合は、システム開発が失敗する原因もあわせて参考になります。
ケース1｜「言わなくても分かるはず」が招いた、現場で使われない業務システム
何が起きたか
ある中堅の卸売企業が、受発注業務の効率化のために専用の業務システムを発注しました。窓口を任されたのは、経営企画を兼務する管理部門の担当者です。これまで紙とExcelで回していた受発注を一元管理し、入力の二度手間をなくすことが目的でした。
要件定義は順調に始まりました。担当者は現場のリーダー1名に同席してもらい、開発会社のヒアリングに対応します。リーダーは「いつもこういう流れで処理しています」と通常の業務フローをよどみなく説明し、開発会社もそれを丁寧に書き留めました。打ち合わせは和やかに終わり、要件定義書には標準的な受発注フローがきれいにまとまりました。誰も不安を感じていませんでした。
開発も滞りなく進みます。受入テストでは、説明された通りの操作が問題なくできることを確認し、担当者は安心して検収しました。ところが稼働して数週間が経つと、現場からぽつぽつと声が上がり始めます。「急な数量変更が入ったときに、システムだと処理できない」「特定の取引先だけ請求の締め日が違うのに、それを登録する場所がない」「結局Excelに戻して手作業でやっている」。
蓋を開けてみれば、現場の実務には説明された「標準フロー」に収まらない例外処理が無数にありました。長年のあいだ担当者の頭の中だけで処理されていた暗黙のルールが、システムには一切反映されていなかったのです。やがて現場はシステムを使わなくなり、高い費用をかけて作った業務システムは、ほとんど使われないまま放置されることになりました。
運命の分岐点——現場の声をどこで取りこぼしたか
このプロジェクトの分岐点は、要件定義のヒアリングを「現場リーダー1名への、一度の打ち合わせ」で完結させてしまった場面にあります。
同席したリーダーに悪気はありません。むしろ優秀だからこそ、例外処理を「いつものこと」として無意識に処理しており、改めて言語化する必要を感じていませんでした。発注側の担当者も、業務の細部までは把握していなかったため、「これで現場の話は聞けた」と判断してしまった。開発会社にとっても、説明された範囲が業務のすべてだと受け取るのは自然なことでした。
つまり、誰も嘘をついておらず、手を抜いてもいません。ただ「言わなくても分かるはず」「これがすべてだろう」という暗黙の前提が三者の間ですれ違ったまま、検証されずに進んでしまった。これが運命の分岐点です。
発注者が取れた一手
この場面で発注者が取れた一手は、ヒアリングを「一度・一人・通常フロー」で終わらせず、業務の棚卸しと例外処理の言語化に踏み込むことでした。
具体的には、立場の異なる複数の現場担当者(ベテラン・新人・繁忙期の応援者など)に話を聞き、「うまくいく通常の流れ」だけでなく「困ったとき・イレギュラーなとき」を意識的に引き出すことです。「急ぎの注文が来たらどうしている?」「例外的に扱う取引先はある?」「Excelで個別に管理しているものは?」といった質問は、暗黙のルールを表に出す呼び水になります。
要件定義はシステムの仕様を決める作業であると同時に、自社の業務そのものを棚卸しする機会でもあります。発注者の側に「現場の実態を言語化して持ち寄る」という意識があるかどうかが、使われるシステムと使われないシステムを分けます。なお、こうした「現場の実態を確認せず開発会社に任せきりにする」構図が招く問題は、発注者の判断ミスでもより広い視点から整理しています。
ケース2｜ユーザー画面ばかり議論し、管理・運用機能が抜け落ちたWebサービス
何が起きたか
あるサービス企業が、自社の顧客向けに新しいWebサービスを立ち上げることになりました。会員登録から各種申し込みまでをオンラインで完結できるようにする、という意欲的な企画です。
要件定義の打ち合わせは、毎回とても盛り上がりました。「トップページはこんな雰囲気にしたい」「申し込みボタンはもっと目立たせよう」「スマホでの見やすさが大事だ」——参加者は皆、利用者が実際に触れる画面のイメージを熱心に語り合いました。デザイン案を見ながら議論する時間は楽しく、要件定義書のユーザー向け画面の項目は、細部まで充実していきました。
開発は予定通り進み、利用者向けの画面は当初のイメージ通りに仕上がります。ところがリリースを目前に控えたある日、運用を担当することになった部署からこんな声が上がりました。「お客様から登録情報の修正を頼まれたとき、誰がどこで直すんですか?」「問い合わせ対応のために、申し込み履歴を確認する画面はどこに?」「月末の集計はどうやって出すんですか?」。
誰も答えられませんでした。利用者が見る画面のことばかり議論していて、それを裏側で運用する人——データを修正し、問い合わせに対応し、帳票を出力する管理者——のための機能が、要件にまったく含まれていなかったのです。慌てて管理画面や運用機能を追加開発することになり、費用は当初の見積もりを大きく超え、リリースも後ろにずれ込みました。
運命の分岐点——「作る機能」ばかり見て「運用する人」を見なかった
このケースの分岐点は、要件定義の場で「このサービスを、誰が、どうやって運用するのか」という問いが一度も立てられなかったことです。
利用者が触れる画面は目に見えるので、発注者にとってイメージしやすく、議論も自然と盛り上がります。一方、管理画面や運用機能は普段ユーザーの目に触れない「裏方」のため、要件定義の議論から抜け落ちやすいのです。Webサービスやアプリの開発で特に起きやすい、典型的な見落としと言えます。
加えて、表示速度や同時アクセスへの耐性といった、目に見えにくいけれど運用を左右する条件(いわゆる非機能要件)も、この段階では誰も話題にしていませんでした。「機能として何を作るか」にばかり目が向き、「実際に運用が回るのか」という視点が抜けていたことが、土壇場の混乱を招いた分岐点です。
発注者が取れた一手
ここで発注者が取れた一手は、要件定義の早い段階で「運用シナリオ」を描いてみることでした。
サービスが公開された後の一日を想像してみます。お客様から「登録したメールアドレスを変えたい」と連絡が来たら、誰が、どの画面で対応するのか。クレームの問い合わせがあったら、担当者は何を見て状況を把握するのか。月次の利用実績は、どうやって集計して経営に報告するのか。こうした運用の場面を一つずつ言葉にしていくと、利用者向け画面とは別に必要になる管理機能や帳票が自然と浮かび上がります。
あわせて、「ピーク時に何人が同時にアクセスする想定か」「どのくらいの表示速度を許容できるか」といった非機能要件も、要件定義の段階で開発会社と確認しておくべきでした。これらは後から足そうとすると設計の根幹に関わり、大きな手戻りになりがちだからです。「作る機能」のリストだけでなく「運用する人の一日」まで要件に含める——この視点の有無が、リリース直前の混乱を防ぎます。
ケース3｜「つながる前提」で進めた外部連携が、土壇場で破綻したプロジェクト
何が起きたか
ある企業が、新しい顧客管理システムを開発することになりました。このシステムは単独で動くものではなく、すでに社内で稼働している基幹システムや、外部の予約サービスとデータをやり取りする必要がありました。既存の顧客データも、新システムへ移し替える計画です。
要件定義では、新システム自体の機能については丁寧に議論されました。一方、外部システムとの連携については、「そこは技術的な話なので、開発会社さんにお任せします」という空気で進みました。発注者は「データは当然つながるものだろう」と楽観しており、開発会社も「連携先の仕様は後で確認すればよい」と先送りにしていました。要件定義書には「基幹システムと連携する」「既存データを移行する」という一行が書かれただけで、具体的にどんな形式のデータを、どの範囲で、どちらが責任を持って受け渡すのかは、誰も詰めていませんでした。
設計・開発フェーズは新システム単体の機能を中心に進み、ここまでは順調でした。問題が噴き出したのは、いよいよ各システムをつなぐ結合のフェーズに入ってからです。いざ連携しようとすると、基幹システムが出力するデータの形式が想定と違い、そのままでは取り込めないことが判明します。外部の予約サービスは、連携のために必要なデータ項目を一部しか提供していませんでした。さらに、移行するつもりだった既存の顧客データには表記の揺れや欠損が大量にあり、そのままでは新システムで使い物にならない状態でした。
「つながる前提」がことごとく崩れた結果、データ整形や連携部分の作り直しに追われ、納期は大幅に遅延。当初の見積もりにない作業が積み上がり、再見積もりへと発展しました。
運命の分岐点——連携の「前提」を誰も確認していなかった
このプロジェクトの分岐点は、要件定義の段階で「連携先の仕様・データの形式・移行する範囲・責任の所在」を誰も確認しなかったことです。
外部連携やデータ移行は、技術的に見えるため発注者が「自分には分からない領域」として開発会社に委ね、開発会社も「発注者が連携先のことを把握しているはず」と考えて、確認の責任が宙に浮きやすい論点です。しかも、つなぐ相手のシステムは自分たちでコントロールできないため、「当然こうなっているだろう」という思い込みが事実と食い違っていても、結合の段階まで気づけません。
「連携する」という一行を、誰も具体的な確認事項に分解しないまま合意してしまった——これが、土壇場の破綻を招いた分岐点です。
発注者が取れた一手
ここで発注者が取れた一手は、「連携する」という言葉を、要件定義の段階で具体的な確認事項に分解することでした。
技術的な詳細をすべて理解する必要はありません。発注者として確認・調整すべきは、たとえば次のような前提です。
- 連携先のシステムは、どんなデータを、どんな形式で出し入れできるのか(連携の仕様を、連携先の管理部署や提供元に確認できているか)
- 移行する既存データは、どの範囲を、いつ時点のもので移すのか。データの整理・クレンジングは誰がやるのか
- 連携や移行で問題が起きたとき、どこまでが開発会社の責任で、どこからが自社や連携先の責任なのか(責任分界点)
これらは技術というより「段取りと役割分担」の問題であり、発注者が主体的に確認・調整すべき領域です。とりわけデータ移行は「既存データが想定よりずっと汚れていた」という事態が頻発するため、早い段階で実物のデータを確認しておく価値があります。なお、こうした連携や仕様の認識ズレがこじれて法的なトラブルにまで発展したケースについては、要件定義の失敗事例(訴訟・判例)で具体的な判例を取り上げています。
ケース4｜要望を盛り込みすぎ、優先順位がつかず迷走した開発
何が起きたか
ある企業が、全社で使う新しい社内ポータルシステムを開発することになりました。せっかく作るのだからと、プロジェクトの窓口担当者は各部門から幅広く要望を集めることにしました。
要望は次々と集まりました。営業部門は顧客情報との連携を望み、人事部門は申請手続きのオンライン化を求め、総務部門は備品管理機能を、広報部門は社内お知らせの掲示機能を——どの要望ももっともで、担当者はそのすべてを要件定義書に書き込んでいきました。「あれも欲しい」「これも入れたい」という声に応えるうちに、機能の一覧はどんどん膨らんでいきます。
ところが、開発会社から概算の見積もりと開発期間が示されると、それは当初想定していた予算と納期を大きく上回るものでした。当然、機能を絞り込む必要が出てきます。しかしここで担当者は立ち往生してしまいました。どの機能を削り、どれを残すべきか、判断する基準がなかったのです。各部門は「うちの機能は必須だ」と主張して譲らず、調整は難航します。
結局、限られた予算と期間のなかで機能を中途半端に詰め込んだ結果、どの部門にとっても使い勝手の悪い、焦点のぼやけたシステムが出来上がりました。「全部入れようとして、どれも満足できないものになった」という、誰も得をしない結末です。
運命の分岐点——目的を決めずに機能から議論を始めた
このケースの分岐点は、「何のためにこのシステムを作るのか」という目的を定めないまま、いきなり「どんな機能を入れるか」の議論から始めてしまったことです。
目的が定まっていないと、集まってきた要望に優先順位をつける基準が存在しません。基準がなければ、どの機能も等しく「必要」に見えてしまい、絞り込みは部門間の力関係や声の大きさで決まる泥仕合になります。「目的(何のために)」と「機能(何を作るか)」は本来きちんと区別すべきものですが、この区別があいまいなまま機能の話に突入したことが、迷走の出発点でした。
加えて、部門ごとに利害が異なるにもかかわらず、その調整を要件定義の場で正面から行わず、要望をただ足し算で積み上げてしまったことも、混乱に拍車をかけました。
発注者が取れた一手
ここで発注者が取れた一手は、機能の議論を始める前に、まず「このシステムで一番達成したいことは何か」という目的を一つに絞って言語化することでした。
たとえば「社内の申請手続きにかかる時間を半分にする」と目的を定めれば、それに直結する機能が「最優先(Must)」、あれば嬉しいが今回でなくてもよい機能が「次点(Want)」と、優先順位の基準が自然に決まります。基準があれば、予算や納期の制約で機能を絞り込むときも、「目的に照らして、これは今回必須」「これは次のフェーズで」と説明でき、部門間の合意も取りやすくなります。
そのうえで、各部門の代表者を集めて「今回のシステムの目的はこれです。だから今回はこの機能を優先します」という合意を、要件定義の段階で正式に取り付けておくことが大切でした。要望の足し算ではなく、目的から逆算して優先順位を引き算する——この順序が、迷走を防ぎます。なお、ここで言う「目的(要求)」と「機能(要件)」の違いをもう少し丁寧に押さえたい場合は、要求定義と要件定義の違いもあわせてご覧ください。
4つのケースに共通する「気づきにくさ」と、発注者が今すぐできる自己点検
4ケースに共通する「気づきにくさ」の正体
ここまで4つの失敗を物語として見てきました。業種もシステムの種類もばらばらですが、4つのケースには共通する「気づきにくさ」が流れています。
一つは、合意が言語化・記録されないまま「分かったつもり」で進むことです。現場の暗黙ルール(ケース1)、運用する人の存在(ケース2)、連携の前提(ケース3)、システムの目的(ケース4)——いずれも、関係者の頭の中にはなんとなくあったはずなのに、誰も明確な言葉にして書き残さなかった。曖昧なまま合意したことが、後で「言った・言わない」「そんなつもりではなかった」というズレになって表面化しています。
もう一つは、検証のないまま完成して、初めてズレが表面化することです。要件定義で決めたこと(あるいは決め損ねたこと)は、その場では正しいかどうか分かりません。実際に現場で使ってみる、運用してみる、連携してみる——その段階になって初めて、認識のズレが目に見える形になります。だからこそ、要件定義の段階で「この内容で本当に大丈夫か」を意識的に検証する姿勢が欠かせないのです。
繰り返しになりますが、これらはどれも、関係者が手を抜いたから起きた失敗ではありません。真面目に、和やかに進んでいたプロジェクトが、誰も悪意なく転んでいった。だからこそ「自分は大丈夫」と思っている人ほど、自分のプロジェクトを一度点検してみる価値があります。
発注者が次の打ち合わせから使える自己点検の視点
最後に、4つのケースから抽出した学びを、明日の打ち合わせから使える自己点検の視点としてまとめます。心構えではなく、具体的に確認できる切り口です。
- 業務の棚卸し(ケース1): 現場の「通常フロー」だけでなく、例外処理や暗黙のルールを言語化できているか。立場の異なる複数の現場担当者に話を聞けているか。
- 運用視点(ケース2): 利用者が見る画面だけでなく、それを運用する人(管理・修正・問い合わせ対応・集計)のための機能と、表示速度や同時アクセスといった非機能要件を要件に含めているか。
- 連携前提(ケース3): 「連携する」「移行する」という言葉を、データの形式・範囲・責任分担という具体的な確認事項に分解できているか。
- 目的と優先順位(ケース4): 機能の議論を始める前に「何のために作るか」を一つに絞り、Must / Want の優先順位と部門間の合意を取れているか。
- 合意の記録: 打ち合わせで決まったことを、口頭の「分かったつもり」で終わらせず、書面に残して関係者で確認しているか。
これらの視点で自分のプロジェクトを見直すと、「ここはまだ曖昧かもしれない」という箇所が一つか二つは見つかるはずです。その気づきこそが、失敗を未然に防ぐ最初の一手になります。
より体系的に確認したい場合は、失敗につながりやすいポイントを一覧で押さえられる要件定義の落とし穴、発注者が前・最中・終わりの各段階で打つべき対策をまとめたシステム開発の失敗は要件定義で決まる、そして完成した要件定義書をどう読めばよいかを解説した要件定義書の読み方が、それぞれ次の一手を具体化する助けになります。物語で自分事として実感したうえで、これらの各論で点検の解像度を上げていけば、あなたのプロジェクトは「順調そうに見えて転ぶ」道から確実に外れていくはずです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 現場の暗黙ルールを引き出すには、打ち合わせでどんな質問をすればよいですか？
「急な変更が来たときはどうしていますか？」「Excelで別に管理しているものはありますか？」のように、例外・イレギュラー・属人的な対応を直接聞く質問が効果的です。通常フローを説明してもらった後に「これ以外のパターンはありますか？」と追加で確認する一言も、暗黙のルールを引き出す呼び水になります。
- 管理機能や非機能要件をどのタイミングで、何を確認すればよいですか？
利用者向け画面の要件を議論する段階で同時に、「誰がデータを修正・集計・問い合わせ対応するか」という運用シナリオと、「ピーク時の同時アクセス数と許容できる表示速度」を開発会社に確認してください。設計後に追加すると大きな手戻りになるため、要件定義の早い段階で一度は必ず議題にあげることが重要です。
- 外部連携やデータ移行の責任分界点は、どうやって決めればよいですか？
「問題が起きたとき、どこまでが開発会社の範囲で、どこからが自社または連携先の範囲か」を要件定義書に明文化することが出発点です。連携先のシステム管理者に直接確認してデータ形式・提供範囲を文書化し、それを開発会社と共有して責任の境目を合意しておくことで、土壇場の「言った・言わない」を防げます。
- 各部門から要望が出て優先順位をつけられない場合、どう進めればよいですか？
機能ではなく「このシステムで最初に解決すべき一つの業務課題」を経営層が先に決め、その目的に照らして各機能を「今回必須（Must）」「次フェーズ（Want）」に分類することが有効です。目的が決まれば部門間の調整も「目的への貢献度」という共通基準で議論でき、感情的な綱引きになりにくくなります。
- 打ち合わせで決まったことを「書面に残す」とは、具体的にどんな形にすればよいですか？
議事録や要件定義書への反映だけでなく、「決定事項・未決定事項・担当者」を箇条書きにしたメールを打ち合わせ後24時間以内に開発会社へ送り、返信で確認を取る形が実務的です。この一往復が「合意の記録」になり、後から認識のズレが生じたときの基準点になります。
- 自分のプロジェクトが4つのケースのどれに近いか分からないとき、まず何を確認すればよいですか？
「現場の全員に話を聞けているか（ケース1）」「運用担当者の一日を言葉にできるか（ケース2）」「連携先のデータ形式を確認済みか（ケース3）」「システムの目的が一文で言えるか（ケース4）」の4点を自問してください。一つでも答えに詰まる項目があれば、そのケースに近いリスクを抱えている可能性が高いと考えて対策を優先するとよいでしょう。
