「発注したのに、思っていたものと全然違う」「追加費用が次々と発生する」「納期が守られない」──システム開発の発注経験がある方なら、一度はこうした経験があるのではないでしょうか。
日経コンピュータの調査によると、システム開発プロジェクトの失敗率は47.2%。約2件に1件のプロジェクトが、コスト・納期・品質のいずれかで期待を下回っているというデータがあります。なぜこれほど多くのプロジェクトが失敗するのか、発注者として何ができるのか。本記事では、失敗の5つの根本原因と具体的な対策を解説します。
発注の失敗率を下げるために、発注者側で何を確認すべきかが具体的にわかります。
この数字は、大手から中堅・中小企業に至る約12,000社を対象に実施した調査結果です。「失敗」の定義は、開発で守るべき3条件であるQCD（Quality：品質 / Cost：コスト / Delivery：納期）のいずれかを達成できなかったプロジェクトです。別の調査では「成功率はわずか27%」「70%が何らかの失敗に陥っている」という報告もあり、失敗率が極めて高い業界であることは間違いありません。
失敗のパターンは大きく3つ
| 失敗パターン | 具体的な状況 | 発注者への影響 |
|---|---|---|
| コスト超過 | 見積もりより30〜50%以上の費用が発生 | 予算超過・社内承認の取り直しが必要になる |
| 納期遅延 | リリースが数ヶ月〜1年以上遅れる | 事業計画・キャンペーン・他システムとの連携に影響が出る |
| 品質不満足 | 完成したが現場が使いにくい、バグが多い | 現場の信頼を失い、修正費用と工数が追加発生する |
✅ 重要：これらの失敗の多くは「発注者側でも防げた」失敗です。開発会社の問題だけでなく、発注の仕方・確認の仕方に原因があるケースが半数以上を占めます。
「最初の見積もりどおりに進んだためしがない。開発が進むにつれて追加費用が次々と発生し、最終的に当初予算の1.5倍近くになった。」
何が問題なのか
見積もりが甘くなる根本的な原因は、「言われた範囲だけを見積もる」姿勢にあります。発注者がヒアリングで伝えた内容だけを積み上げた見積もりは、一見すると安く見えますが、実際の開発では必ず「言われていなかったが必要な機能や作業」が出てきます。本来、開発会社はシステム開発の専門家として、発注者が明言していなくても当然必要になる機能・非機能要件・作業を加味した上で見積もりを提示すべきです。
見積もりから除外されやすい項目の例
発注者として確認すべきこと
| 確認ポイント | NG回答（要注意） | OK回答（信頼できる） |
|---|---|---|
| 見積もりの対象範囲と除外範囲を明示してもらえますか？ | 「含まれていないものはありません」 | 対象・除外範囲を書面で明示できる |
| 見積もりに含まれない項目で増減する可能性はありますか？ | 「追加が出たらその都度ご相談します」 | 想定されるリスクを事前に説明できる |
また、ヒアリングや商談の中で以下のような姿勢が見えるかどうかを確認しましょう。
「完成したけど思っていたものと全然違う。修正するたびに追加費用が発生する。」
何が問題なのか
複数の調査で「失敗の最大原因は要件定義の不備」という結果が出ています。要件定義とは「何を作るか」を具体化する作業ですが、ここが曖昧なままプロジェクトが進むと、完成してから「イメージと違う」という事態が起きます。
① 要件定義では見えていなかったものが後から発覚する
帳票の出力形式、外部システムとの連携仕様、例外処理の扱いなど、ヒアリングの段階では話題に上がらなかった要件が後から次々と出てきます。ただし、開発会社には注意管理義務の観点から、要件定義の段階で「このシステムであれば当然考慮すべき事項」を発注者に確認・指摘する責任があります。
② ウォーターフォール開発で、詳細を後回しにして進める
「詳細は開発しながら決めましょう」という合意のまま進めると、製造フェーズに入ってから仕様変更が続発します。後になればなるほど変更コストが膨らみます。
③ エンドユーザーの利用シーンを確認せずに進める
システム部門と開発会社の間だけで要件を固めてしまい、実際にシステムを使う現場のユーザーが関与しないまま開発が進むパターンです。完成後に「入力の手順が現場の業務フローと合わない」「承認ルートが実態と違う」といった問題が発覚します。
発注者として確認すべきこと
✅ ポイント：要件定義の失敗は、開発会社・発注者の双方に原因があります。「お互いに任せた」という状態が、最も危険です。
「オンスケという報告を受け続けていたが、突然納期2週間前に遅延を告げられた。」
何が問題なのか
製造フェーズに入ると開発会社内での作業が中心になり、発注者の関与が自然と減っていきます。この「見えなくなる」タイミングこそが、ブラックボックス化の始まりです。開発会社側には「まだ挽回できる」「報告するほどではない」という判断が積み重なって問題の報告が遅れやすい心理があります。特に危険なのが「オンスケです」という報告です。
| 確認ポイント | NG回答（要注意） | OK回答（信頼できる） |
|---|---|---|
| 工程ごとの進捗を発注者が確認できる仕組みがありますか？ | 「定期的に報告書を送ります」 | 「Backlog等のツールで発注者もリアルタイムで確認できます」 |
| 完了タスク・残タスク・懸念事項を具体的に報告してもらえますか？ | 「オンスケで進んでいます」 | 「完了・残・懸念事項をセットで報告します」 |
| 問題が発覚したときの報告・対応オペレーションは確立していますか？ | 「その都度ご連絡します」 | 「エスカレーションと対応フローをルールとして定義しています」 |
✅ ポイント：「オンスケです」という報告を鵜呑みにしないことが重要です。問題が起きたときに隠さず・先送りせず報告できる体制とオペレーションが確立しているか、事前に確認しましょう。
「テスト済みです」と言われてリリースしたら、バグだらけで現場が大混乱した。
何が問題なのか
品質はテストで担保するものではなく、設計で決まります。設計の段階で品質の基準や方針が定まっていなければ、テストをいくら行っても根本的な問題は解決しません。「テスト済みです」という言葉だけを確認していた発注者が、リリース後に大量のバグや使い勝手の問題に直面するのは、設計フェーズでの品質基準が曖昧なまま進んでいたことが原因であるケースがほとんどです。
| 確認ポイント | NG回答（要注意） | OK回答（信頼できる） |
|---|---|---|
| 品質基準はどのように設計に組み込んでいますか？ | 「テストをしっかりやります」 | 「機能面・非機能面・ユーザビリティの観点で品質基準を設計書に明記し、発注者と合意してから開発に入ります」 |
| エンドユーザーの利用シーンはどう設計に反映しますか？ | 「仕様書に基づいて開発します」 | 「エンドユーザーへのヒアリングや業務フロー確認を設計に組み込みます」 |
| 設計書は共有してもらえますか？ | 「完成後にお渡しします」 | 「計画段階でレビューの予定・順序をお伝えし、発注者と一緒に作り上げます」 |
| テスト仕様書は共有してもらえますか？ | 「社内で管理しています」 | 「業務観点での抜け漏れがないか発注者と一緒に確認しながら進めます」 |
| バグが出た場合の対応は？ | 「その都度ご相談します」 | 「バグ発生時のオペレーションを定義しており、対応フローに沿って進めます」 |
✅ ポイント：「テスト済みです」は品質の根拠にはなりません。品質は設計で決まります。機能面・非機能面・エンドユーザーの利用シーンが設計に反映されているかどうかを、早い段階で確認しましょう。
「担当者が変わったとたん品質が落ちた。この会社しかわからない状態になってしまっている。」
何が問題なのか
特定の開発会社に依存しすぎると、「この会社しかわからない」という状態（ベンダーロックイン）が生まれます。一度この状態になると、問題が起きても乗り換えが難しくなり、発注者側の交渉力が失われます。
| 確認ポイント | NG回答（要注意） | OK回答（信頼できる） |
|---|---|---|
| 要件定義書・設計書はいつ最新化されますか？ | 「納品時にまとめてお渡しします」 | 「変更が発生した際に速やかに更新し、都度共有します」 |
| 担当者が変わっても品質は担保されますか？ | 「チームでしっかりサポートします」 | 「属人化しないプロセスが標準化されています」 |
| 他社や内製に切り替えることはできますか？ | 「長期的なパートナーとしてお任せください」 | 「他社や内製化に移行しても継続できるよう、ドキュメントと開発プロセスを整備しています」 |
✅ ポイント：良い開発会社は、自社への依存を高めるのではなく、発注者が自立できる状態を目指します。他社や内製化に切り替えられる状態を維持することが、発注者にとって最大の交渉力になります。
以上5つの原因を踏まえ、開発会社を選ぶ前に必ず確認すべきチェックリストをまとめました。商談の場でそのまま使えます。
| No. | 確認する質問 | 要確認（NG） | OK |
|---|---|---|---|
| 1 | 見積もりの対象範囲と除外範囲を明示してもらえますか？ | 「含まれていないものはありません」 | 明示できる |
| 2 | 見積もりに含まれない項目で増減する可能性はありますか？ | 「追加が出たらその都度ご相談します」 | リスクを事前に説明できる |
| 3 | 要件定義書・画面一覧はどのタイミングで共有・確認してもらえますか？現場ユーザーも含めたレビューは可能ですか？ | 「完成後にお渡しします」 | 段階的に共有しながら現場ユーザーも含めて確認できる |
| 4 | 想定外の要件が後から発覚した場合の対応ルールはありますか？ | 「その都度相談」 | 変更管理ルールが明文化されている |
| 5 | 製造フェーズ以降の進捗を具体的に確認できる仕組みがありますか？ | 「報告書を送ります」 | 仕組みがある |
| 6 | 問題が発覚したときの報告・対応オペレーションは確立していますか？ | 「その都度ご連絡します」 | オペレーションが定義されている |
| 7 | 機能面・非機能面・ユーザビリティの観点で品質基準を設計書に明記してもらえますか？ | 「テストをしっかりやります」 | 発注者と合意の上で明記 |
| 8 | 要件定義書・設計書は変更時に速やかに最新化されますか？ | 「納品時にまとめてお渡し」 | 変更時に速やかに更新・共有 |
| 9 | 他社や内製化に切り替えても継続できる状態を維持してもらえますか？ | 「弊社にお任せください」 | ドキュメントとプロセスを整備 |
✅ 目安：OKが7個以上であれば信頼できるパートナーの可能性が高い。4個以下であれば別の会社との比較を強くお勧めします。
本記事では、システム開発の失敗率が47%に上る現状を踏まえ、5つの主要な失敗原因と発注者として取るべき対策を解説しました。
| 失敗の原因 | 発注者として取るべき対策 |
|---|---|
| ① 見積もりが甘い | 対象範囲・除外範囲・増減リスクの明示を要求する |
| ② 要件定義が曖昧なまま進む | 変更管理ルールの明文化・現場ユーザーを含めた確認プロセスを確立する |
| ③ 製造工程以降の進捗がブラックボックスになる | 進捗確認の仕組みと問題発覚時のオペレーションが確立しているか確認する |
| ④ 品質の判断基準が見えない | 機能面・非機能面・ユーザビリティの品質基準を設計段階で発注者と合意する |
| ⑤ 開発会社への過度な依存 | 他社・内製化に切り替えられる状態を維持できるか確認する |
発注の失敗を防ぐために最も重要なのは、「開発会社に任せきりにしない」ことです。発注者としての知識とチェックリストを持つことで、適切なパートナーを見極め、失敗の確率を大幅に下げることができます。
【参考・出典】
・日経コンピュータ「ITプロジェクト実態調査 2018」（日経XTECH）
・Standish Group「CHAOS Report 2020」
※本記事に記載の数値は各種公開調査データに基づきます。プロジェクトの状況により結果は異なります。