1.「失敗率70%」は本当か——数字の出どころを整理する

まず、数字の話から。

日経コンピュータが実施した「プロジェクト実態調査」では、コスト・納期・品質（QCD）のすべてで計画を守れたプロジェクトの割合が示されています。


  • 2003年調査：成功率 26.7%（＝約73%が失敗）
  • 2008年調査：成功率 31.1%（＝約69%が失敗）

「4分の3が失敗」という結果は、当時業界に衝撃を与えました。

その後、2018年の「ITプロジェクト実態調査」では、1,745件のプロジェクトのうち47.2%が「失敗」。成功率は52.8%まで改善しています。

……これで良くなった、と読むのは早計です。

日本情報システム・ユーザー協会（JUAS）の「企業IT動向調査2025」（2024年度調査／回答981社）は、こう報告しています。

15年度から24年度までの10年間の推移では、すべてのプロジェクト規模において「予定どおり完了」の割合が低下傾向にあり、24年度においても改善の兆候は見られない

実際の数字がこちらです（2024年度・工期の遵守状況）。

プロジェクト規模


「予定どおり完了」の割合

100人月未満：31.0%

100〜500人月未満：16.0%

500人月以上：11.0%


品質面ではさらに厳しく、「満足」と答えた割合は100人月未満で23.9%、500人月以上ではわずか8.2%です。

つまり、規模が大きくなるほど、予定どおりには終わらない。500人月以上の案件では、約9割が計画どおりに完了していません。

「失敗率70%」は、決して誇張ではありません。定義によっては、もっと厳しい数字が出ます。


2. 原因は、ほぼ「上流工程」に集中している

では何が原因なのか。ここも、調査結果はきれいに一致しています。

2018年の日経コンピュータ調査では、

  • 満足を得られなかった理由の筆頭 → 「要件定義が不十分」
  • スケジュールを守れなかったプロジェクトで最も苦労した工程 → 「要件定義」

JUASの2024年度調査でも、QCDを悪化させているトレンドの上位はこうなっています。


要件定義の難易度向上

  • 工期：51.0%
  • 予算：49.4%
  • 品質：47.2%

システム影響範囲の拡大

  • 工期：44.6%
  • 予算：46.1%
  • 品質：44.9%

要件定義の時間不足

工期：35.6%

予算：28.8%

品質：31.3%


Q・C・Dの3軸すべてで、筆頭要因が「要件定義」です。

技術の問題ではありません。作り始める前に、勝負がついている。


3. では、なぜ要件定義は失敗するのか——4つの断層

ここからが本題です。「要件定義が甘い」で片づけると何も改善しないので、実務で何が起きているのかを分解します。


① 要件が曖昧なまま「握った」ことになっている


「在庫を見やすくしたい」「承認をスムーズにしたい」——このレベルの言葉が、要件定義書に残ってしまう。

発注側は「伝えた」と思い、ベンダーは「聞いた」と思っている。ただし、両者の頭の中にある画面はまったく別物です。曖昧な要件は、必ず後工程で解釈違いとして表面化します。

JUASの調査でも、品質が予定どおりにならなかった要因のトップ層に「計画時の考慮不足」（39.1%）と「仕様変更の多発」（27.2%）が並びます。仕様変更は原因ではなく、曖昧さの結果です。


② そもそも、要件を整理できる人がいない


これはもっと構造的な問題です。

JUASが調べた「システム開発の内製化を阻害している要因」（n=959）を見ると、発注側企業の自己認識が生々しく出ています。

  • 現行業務への理解不足 … 38.7%
  • システム企画力不足（ビジネス要件をシステム仕様に落とせない）… 30.2%

現行システムの仕様がわからない … 24.6%

つまり、発注側の4割近くが「自社の業務を説明できない」と自覚している。

要件定義とは、業務を仕様に翻訳する作業です。その翻訳者が社内にいない状態で発注すれば、ベンダーは推測で作るしかありません。


③ 大前提が、そもそも共有されていない


これが実務上いちばん多い落とし穴だと感じています。

  • 業務フロー（誰が、いつ、何をトリガーに動くか）
  • 既存システムとの連携仕様（UL/DL、連携タイミング、キー項目）
  • データの持ち方、コード体系
  • 例外処理と、それを回している「暗黙のルール」

これらは要件以前の大前提です。ところが、この情報が誰からも出てこない。

理由はシンプルで、ベンダーは「何を聞くべきか」を知らず、発注側は「何を言うべきか」を知らないからです。この非対称を埋める役割が、多くのプロジェクトで空席になっています。

JUASの調査で「想定以上の現行業務・システムの複雑さ」が品質未達要因の39.6%を占めるのは、これが理由です。複雑だったのではありません。複雑さが可視化されないまま契約されたのです。


④ 現場で使える構想になっていない


そして、最も痛い失敗がこれです。動くけれど、使われないシステム。

この失敗が20億円の裁判になった実例があります。文化シヤッター vs 日本IBMです。

  • 2015年、文化シヤッターが販売管理システムの刷新を日本IBMに委託。2017年に開発が頓挫
  • 現場が旧システムと同じ画面の見た目にこだわった結果、カスタム開発の割合は95%まで膨張
  • 結合テストの進捗50%時点で欠陥770件。開発規模から予想される標準的な欠陥数467件を大きく上回った
  • 2025年1月、最高裁が双方の上告を棄却し、日本IBMに約20億564万円の賠償を命じる判決が確定（過失割合は二審でIBM側90%）

高裁は、文化シヤッター側の仕様確定の遅れと度重なる仕様変更要求がプロジェクトマネジメントを困難にした側面を認めつつ、その一因はIBM側が「動く画面」で仕様を具体的に示す機会が想定よりかなり少なく、仕様の詳細がイメージしづらかったことにあると判断しました。

ここから読み取るべき教訓は2つあります。

ひとつ。現場を要件定義の場に呼ばなければ、要求は必ず後から出てくる。 そして後から出た要求ほど、断れず、高くつきます。

ふたつ。「仕様を文書で確認した」は、確認したことにならない。 動く画面を見るまで、人は自分が何を欲しかったのかを言語化できません。

なお、この案件の発注先は日本を代表するベンダーです。これはベンダー選定の問題ではない、ということも申し添えておきます。


4. 失敗確率を下げるために、発注側ができること

調査結果と実務から、効果が大きい順に挙げます。

① 要件定義を「ベンダーに任せる工程」にしない 要件定義をベンダー任せにした時点で、翻訳の精度は相手の理解力に依存します。少なくともレビューする力は、発注側に必要です。

② 業務フローを先に描く システムの話をする前に、現状（As-Is）の業務フローを描く。部門をまたぐ流れ、システム間連携、例外処理まで。ここが可視化されていないプロジェクトは、ほぼ確実に「想定以上の複雑さ」に遭遇します。

③ 現場を、要件定義の場に呼ぶ 承認フローの都合で情シスと経営層だけで要件を決めると、④の失敗を踏みます。使う人を、決める場に入れる。

④「決められる人」を1人立てる 仕様凍結を宣言でき、それを守らせられる権限を持った人。ここが曖昧だと、仕様変更が止まりません。

⑤ 受入テスト仕様書を、要件定義と同時に書く 「どうなったら受け入れるのか」を先に書くと、要件の曖昧さが強制的に炙り出されます。受入テスト仕様書はどのみち必要なので、総工数は変わりません。

⑥ 大きく作らない 500人月以上の「予定どおり完了」は11.0%。一方100人月未満は31.0%。規模を分割するだけで、成功確率は約3倍になります。


5. 私たちが考えていること

私たちは、システム開発を請け負う立場であると同時に、業務改革（BPR）の支援も行っています。

その両方をやっていて強く思うのは、「開発を受注する前に、業務を整理するフェーズを分けるべきだ」ということです。

要件定義を開発契約の一部に含めてしまうと、ベンダー側には「早く仕様を固めて開発に入りたい」という力学が働きます。発注側にも「要件定義でお金と時間をかけたくない」という心理が働く。両者の利害が、いちばん時間をかけるべき工程を圧縮する方向に一致してしまう。

ここを分けて、業務の可視化と要件の整理そのものを独立した仕事として扱う。地味ですが、失敗率70%の世界で成功確率を上げる方法は、結局そこにしかないと考えています。


出典

日経コンピュータ「プロジェクト実態調査」（2003年／2008年）

日経コンピュータ「ITプロジェクト実態調査 2018」

一般社団法人日本情報システム・ユーザー協会（JUAS）「企業IT動向調査2025」（2024年度調査）

日経クロステック／ビジネスジャーナル ほか（文化シヤッター vs 日本IBM 訴訟報道、2022年・2024年・2025年）