要件定義が失敗する原因と防ぎ方｜よくある失敗事例6パターンと「危ない兆候」チェックリストARTICLE

「開発会社に任せたのに、できあがったシステムが現場で使われない」「要件定義が終わったはずなのに、開発が始まってから仕様変更が止まらない」「見積もりの倍の費用がかかった」——システム開発の失敗談をたどると、原因の多くは開発の手前、要件定義にあります。

IPA（情報処理推進機構）が発注者向けに公開している「ユーザのための要件定義ガイド 第2版」でも、「システム開発の遅延の過半は要件定義の失敗にある」と言われる、という課題認識から解説が始まっています。

ただし、要件定義の失敗は担当者の力量不足だけで起きるわけではありません。失敗には典型的なパターンがあり、事前に兆候が出ます。本記事では、要件定義の進め方の関連記事として「失敗する側」から掘り下げ、よくある失敗の型、こうなっていたら危ないという兆候、防ぎ方、そして失敗してしまったときの立て直し方を整理します。

この記事の要点

• 要件定義の失敗は、①役割が置かれていない、②利用者を調べていない、③合意ができていない、④外注先に丸投げ、⑤作ること自体が目的、⑥粗い要件で金額を確定、の6パターンにほぼ集約できます
• 防ぐ鍵は発注側にあります。業務の目的・利用者・やらないことを決めるのは発注側の役割で、開発会社に任せきりにしないことが最大の予防策です
• 失敗しても立て直せます。いったん止めて現状を棚卸しし、目的と利用者に立ち返り、優先順位を決め直し、合意と進め方の型をつくる、の4ステップで進めます

要件定義の失敗とは ―― 「作ったのに使われない」「いつまでも終わらない」

要件定義の失敗とは、作るべきものについて関係者の合意がないまま開発に進み、後工程で大きな手戻りや「使われないシステム」を生むことです。要件定義書が完成していても、中身が現場の実態とずれていれば失敗です。

失敗は、たいてい次のような形で表面化します。

症状は開発やリリースの段階で出ますが、原因はその手前にあります。だからこそ、症状が出てから開発会社を責めても解決しません。

要件定義が失敗する6つの典型パターン（よくある失敗事例）

K.S.Rogers が要件定義の相談を受ける中で見てきた失敗は、おおむね次の6パターンに分けられます。複数が同時に起きていることも珍しくありません。

パターン1：要件定義の役割が置かれていない

最も根本的な失敗です。発注側には「ビジネスは分かるがシステムは分からない」人しかおらず、開発側には「作れるが業務は分からない」人しかいない。その間で、要求を要件に翻訳し、決める人がいない状態です。

すると要望は整理されないまま開発に流れ込み、エンジニアが「たぶんこういうことだろう」と都度判断して作ることになります。K.S.Rogers が支援したオンライン診療プロダクトの事例でも、参画時には要件定義を担うPdM（プロダクトマネージャー）が不在で、CS・医療従事者・経営それぞれの要求が同じ土俵で整理されないまま開発に流れ込んでいました。その結果、優先順位が「説明できる基準」ではなく、その場の状況や声の大きさに引っ張られていたといいます。

パターン2：利用者を調べていない

経営層や企画担当が頭の中で描いた業務を前提に機能を決め、実際に使う人の業務を確かめていないパターンです。現場には、会議室では見えない例外処理や、別部署が裏で抱えている手作業があります。

ここを見落とすと、システムは完成しても「今のやり方のほうが早い」と使われなくなります。要件定義の段階で利用予定者に話を聞き、現状の業務フローを一度描いてみるだけでも、ずれの多くは事前に見つかります。

パターン3：合意ができていない（やらないことが決まっていない）

関係者が多いプロジェクトほど起きやすいのが、合意形成の不足です。会議で話したことが「決まったこと」として扱われていても、影響を受ける部署が呼ばれていなかったり、決裁者が内容を理解していなかったりすると、開発が進んでから「聞いていない」「思っていたのと違う」が出てきます。

特に抜けやすいのが「今回はやらないこと」の合意です。やることだけを並べた要件定義書は、読む人によって範囲の解釈が変わります。対象外にしたものと、その理由を残しておかないと、開発中に要望が膨らみ続けます。

パターン4：システム開発を外注先に丸投げする

「餅は餅屋」と開発会社にすべてを任せ、発注側は完成を待つだけ、というパターンです。後の章で詳しく扱いますが、開発会社は発注側の業務の優先順位や社内事情を知りません。決めるべきことを決めないまま任せると、開発会社は仕様書に書かれた範囲で作るしかなく、結果として「言われた通りに作ったのに使われない」システムになります。

パターン5：作ること自体が目的になる

「AIで何かしたい」「アプリを作りたい」という手段が先に立ち、なぜ作るのか、誰の何が良くなるのかが言葉になっていないパターンです。K.S.Rogers のメンバーへのインタビューでも、よくある苦労として「作ること自体が目的化」するケースが挙がっています。そうしたときは、既存のツールで足りないかを例に出して「なぜ今あえて作るのか」を問い直すといいます（要件定義インタビュー一覧）。

目的が1文で言えないまま進むと、機能の優先順位を判断する基準がないため、要件はいつまでも固まりません。

パターン6：粗い要件の段階で金額を確定させる

構想段階でもらった概算見積もりが、そのまま社内の予算として固定されてしまうパターンです。要件が決まっていない段階の見積もりは、どうしても幅が大きくなります。それを確定額として扱うと、要件が具体化するにつれて「予算に収めるために必要な機能を削る」「追加費用で揉める」のどちらかに陥ります。

このパターンは要件定義そのものの失敗というより、要件定義と見積もり・発注の順番の失敗です。防ぎ方は後の章で整理します。

こうなっていたら危ない ―― 要件定義の失敗の兆候チェックリスト

失敗は、開発が終わってから突然明らかになるわけではありません。途中で兆候が出ています。プロジェクトの段階ごとに、次の項目を確認してみてください。2つ以上当てはまる場合は、開発に進む前に（または開発を続ける前に）要件定義を見直すことをおすすめします。

見積もり・発注の前

• 「なぜこのシステムが必要か」を、関係者の誰もが同じ1文で言えない
• 発注側で、要件を決める担当者と最終判断する人が決まっていない
• 実際に使う人に、まだ一度も話を聞いていない
• 構想段階の概算見積もりが、すでに確定予算として社内で通っている

要件定義の最中

• 会議のたびに前提や優先順位が変わる
• 要件定義書に「今回やらないこと」が書かれていない
• 開発会社からの質問に、発注側の誰も即答できず、回答が1週間以上止まる
• 画面イメージやモックアップを、利用者の代表が見ていない
• 「とりあえず全部入れておいて」という発言が出る

開発が始まってから

• 「それは聞いていない」「前に話したはず」のやりとりが続く
• 新しい要望と不具合対応が区別されず、開発の優先順位が毎週変わる
• リリースが遅れているが、何がボトルネックか誰も説明できない
• エンジニアが仕様を推測しながら実装している

兆候の多くは「決める人がいない」「決めたことが共有されていない」の2つに行き着きます。逆に言えば、この2つを押さえるだけで、失敗の確率は大きく下げられます。

システム開発を外注に丸投げすると失敗する理由

システム開発を外部に頼むこと自体は、まったく悪いことではありません。問題は「外注」と「丸投げ」を混同することです。

発注側にしか決められないことがある

IPA の要件定義ガイドでは、システムの要件を定義する責任は、構築されたシステムを使ってビジネスに貢献する役目を負うユーザ（発注側）にあると言われている、と述べられています。そのうえで、ITベンダやシステム部門が中心になって要件定義を進めるスタイルから、業務部門のユーザが主体的に関与するスタイルへの変革の必要性が増している、としています（IPA「ユーザのための要件定義ガイド 第2版」）。

発注側と開発側の役割を分けると、次のようになります。

左の列を開発会社に任せることはできません。開発会社が善意で推測して作っても、それは発注側の意図と一致する保証がないからです。

発注側と開発側がそれぞれ何を担うかは、要件定義シリーズ 第1回：システム開発の発注側と開発側の役割分担で、工程ごとに詳しく整理しています。

「丸投げ」と「伴走」の違い

社内に要件定義の経験者がいない場合、要件定義そのものを外部の専門家に頼むのは有効な選択肢です。ただし、それは丸投げではなく伴走でなければいけません。

• 丸投げ：決める作業も判断も外部に任せ、発注側は完成物を受け取るだけ
• 伴走：ヒアリング・整理・ドキュメント化は外部が担い、発注側はレビュー・承認・意思決定を担う

K.S.Rogers が支援したHRスカウト業務のAI効率化の事例でも、ヒアリングとアウトプットの取りまとめは支援側が担い、クライアントは提示案のレビュー・承認・意思決定を行う、という役割分担で進めています。作業を外に出しても、決める権限は発注側に残す。これが丸投げとの違いです。

外部に頼む前に整理しておく3つのこと

音声ライブ配信アプリの開発体制を整えた事例では、初めて外部支援者を使う発注者に向けて、事前に次の3つを整理しておくとよい、とアドバイスしています。

1. 自社の課題を、できるだけ明確に言葉にしておく
2. それをいつまでに、どう解決したいか、ざっくりしたイメージを持っておく
3. 自社にどの程度の知見があるかを把握しておく

完璧に整理できていなくても構いません。この3点が共有されているほど、外部の支援者は的確に入り込めます。

見積もり時点の要件の粒度 ―― 金額はいつ確定させるべきか

パターン6の「粗い要件で金額を確定」を防ぐには、要件がどこまで決まっているかによって、見積もりの確かさが変わることを発注側が理解しておく必要があります。

ポイントは、要件定義と開発を分けて考えることです。構想段階でいきなり「開発一式」の見積もりを取るのではなく、まず要件定義を進め、決まった要件をもとに開発を見積もる。IPA が公開している「情報システム・モデル取引・契約書」でも、システム開発における複数契約の関係が見直しのポイントとして整理されており、工程ごとの契約の考え方を確認する資料として参考になります。

社内稟議の都合でどうしても早い段階に金額が必要な場合は、「この金額は構想段階の概算で、要件定義後に見直す」ことを稟議書に明記しておくだけでも、後の揉めごとを減らせます。

要件定義の失敗を防ぐ方法

6つのパターンそれぞれに、打ち手があります。

表の中でも特に効果が大きいのが、パターン1への打ち手です。K.S.Rogers のメンバーは、要件定義で悩む企業へのアドバイスをこう話します。

まずは、ビジネスとテクノロジーの両方が分かる人を一人置くことです。やりたいことが曖昧なままPMを採用しても、会話がかみ合いません。

その人がいれば、利用者の調査も合意形成も「誰かがやるだろう」ではなく、担当として進みます。要件定義の具体的な進め方（5ステップ、ヒアリングの質問例、チェックリスト）は、要件定義の進め方で詳しく解説しています。

失敗した要件定義の立て直し方（4ステップ）

すでに開発が始まっていて、上の兆候がいくつも出ている。そんな場合でも、プロジェクトは立て直せます。K.S.Rogers の支援では、次の4ステップで進めることが多くあります。

1. いったん止めて、現状を棚卸しする

走りながら直そうとすると、手戻りが手戻りを呼びます。新しい機能の追加をいったん止め、主要な関係者に一通り話を聞いて、それぞれが何に困っているかを集めます。

オンライン診療プロダクトの事例では、最初に主要ポジションの人たちへのヒアリングで課題を集め、レポートとして示して共通認識をつくりました。いきなり「要件定義プロセスを入れます」と言うと、「今まで回っていたのになぜ？」と反発されやすいため、みんなが困っている点を先に言葉にすることから入っています。

2. 目的と利用者に立ち返る

次に「そもそも誰の、どんな課題を解決するシステムか」に戻ります。現状の業務フロー（As-Is）を描き、利用者のどこで時間がかかっているか、どの判断が重いかを確かめます。

HRスカウト業務の事例では、「AIで効率化したい」というアイデアが先行し、目的や利用者の困りごとがはっきりしない状態から、まず利用者と現状の業務フローの整理に着手しました。現状が明確でなければ、あるべき姿は設計できないという考え方です。

3. 優先順位とやらないことを決め直す

目的と利用者が見えたら、優先順位を決め直します。このとき、感覚ではなく効果の試算を材料にすると、議論が前に進みます。HRスカウト業務の事例では、作業にかかっている時間や月の件数をヒアリングして投資対効果を試算し、予算と期間の中で効果の高い範囲に絞り込みました。その結果、2か月でプロトタイプと、開発に引き渡せる定義ドキュメント一式まで仕上げています。数字を厳密に当てることよりも、「投資対効果を議論できる土俵」をつくることが重要だったといいます。

4. 合意と進め方の型をつくる

最後に、同じ失敗を繰り返さない仕組みを残します。

• 要件を決める人・確認する人・実装する人の流れを決める
• 要件定義書の承認の流れをつくり、誰がいつ合意したかを記録する
• 半年〜1年のロードマップや WBS（作業と期限の一覧）で、何をいつまでに決めるかを見えるようにする

音声ライブ配信アプリの事例では、WBS で開発工程を見えるようにし、要望をそのまま開発に流さず開発要件に変換する流れをつくったことで、緊急対応に追われる状態から、1〜2か月に一度リリースを回せる体制へ変わりました。オンライン診療プロダクトの事例でも、ロードマップと要求定義書をセットで出すことで「思っていたのと違う」が減り、3〜6か月ほどで変化が見え始めたといいます。

立て直しのときに避けたいこと

立て直しの場面では、焦りから次のような動きが出がちです。どれも問題を先送りにするだけなので注意します。

• 開発会社を替えて、同じ要件で作り直す：原因が要件定義にある場合、作り手を替えても同じずれが再現します
• 全機能を作り切ってから見直す：作り込むほど手戻りの費用は大きくなります。止める判断は早いほど安く済みます
• 担当者を責めて終わる：多くの失敗は個人ではなく、役割と進め方の構造から起きています。仕組みを変えなければ、担当者が替わっても繰り返します
• プロセスを一気に増やす：会議や書類を急に増やすと、現場は「仕事が増えただけ」と受け止めます。困りごとの共有から入り、効果が見える小さな型から始めます

立て直しで生まれた成果

要件定義を立て直すと、成果は数字にも表れます。K.S.Rogers の支援では、目的や要件が曖昧なまま開発され使われなくなっていたシステムを、利用予定者への調査とモックアップでの合意形成によって立て直し、利用率を20%から65%に改善した例があります。そのほか、要求をエンジニアがすぐ実装できる粒度まで整えて開発ベロシティ（一定期間に開発を進められる量）を43%向上させた例、進捗の可視化と要件定義の承認フロー化で遅延ゼロの開発体制に整えた例もあります。

参考になる公的資料

• IPA「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」（2019年12月公開）：発注側の企業向けに、ビジネス要求定義、システム化要求定義、要件定義マネジメント、主要ドキュメントの作成で起きる問題と、その対応方法を対にして整理しています。失敗の兆候に気づいたとき、該当する問題を引く辞書として使えます
• IPA「情報システム・モデル取引・契約書（第二版）」（2020年12月公開）：ユーザ企業とITベンダの役割の変化を踏まえたモデル契約です。開発を外注する際の契約の考え方を確認できます

要件定義の失敗を繰り返さないために ―― K.S.Rogers の要件定義支援

K.S.Rogers では「決まっていないところから一緒に考える」をコンセプトに、要件定義支援サービスを提供しています。これから始めるプロジェクトの予防にも、すでに兆候が出ているプロジェクトの立て直しにも対応します。

本記事のチェックリストで気になる項目があった段階なら、まずは相談・壁打ちから始めるのがおすすめです。決める権限は御社に残したまま、整理と言語化を伴走します。

まとめ

• 要件定義の失敗は、役割不在・利用者の調査不足・合意不足・丸投げ・目的化・粗い要件での金額確定の6パターンにほぼ集約できます
• 失敗には兆候があります。「決める人がいない」「決めたことが共有されていない」サインが2つ以上出ていたら、開発を進める前に見直します
• 外注は悪くありませんが、目的・利用者・優先順位・やらないことを決めるのは発注側です。見積もりは要件の粒度に合わせて扱い、要件定義と開発を分けて発注します
• 失敗しても、現状の棚卸し → 目的と利用者への立ち返り → 優先順位の決め直し → 合意と進め方の型づくり、の4ステップで立て直せます

要件定義の進め方そのものを知りたい方は要件定義の進め方を、プロジェクトの状況について相談したい方はお問い合わせからお気軽にご連絡ください。