システム開発はなぜ失敗するのか？原因の4類型と予防策【失敗率データ・判例つき】

「システム開発の失敗は、実際どれくらいの確率で起きるのか」
「アプリ開発で失敗する原因と、発注前にできる対策を知りたい」
「プロジェクトが崩れ始めたとき、どう立て直せばいいのか」

システム開発の失敗については、「7割が失敗する」といった数字を目にすることがあります。しかし、出典をさかのぼって確認できる数字は意外なほど少ないのが実情です。

本記事では、一般社団法人日本情報システム・ユーザー協会（JUAS）が2026年4月に発行した『企業IT動向調査報告書2026』（2025年度実施・有効回答957社。QCDの規模区分ごとの回答数は異なります）の一次データと、判決内容が公知となっている裁判例だけを根拠に、次の4点を整理します。

• システム開発の失敗は、規模別にどれくらいの割合で起きているか
• 失敗の原因を「要件定義・ベンダー選定・プロジェクト管理・契約」の4類型で理解する
• 失敗の予兆チェックリストと、崩れ始めたプロジェクトの立て直し方
• 発注前にできる最大の予防策

出典が確認できない数字は使っていません。これからシステム開発・アプリ開発を発注する方も、いままさにプロジェクトの雲行きが怪しい方も、判断材料としてご活用ください。

執筆：Swooo編集部／監修：諸藤 哲耀（株式会社アイビス Swooo事業責任者）

システム開発の失敗はどれくらい起きているか【JUAS 2025年度調査】

まず、「失敗」がどれくらいの頻度で起きているのかを、出典つきのデータで確認します。

「失敗」の基準はQCD（品質・コスト・納期）

システム開発の失敗に法律上の定義はありませんが、実務では次の3つの達成度、いわゆるQCDで評価するのが一般的です。

• 品質（Quality）：完成したシステムが要求水準を満たしているか
• コスト（Cost）：当初予算の範囲に収まったか
• 納期（Delivery）：予定した時期にリリースできたか

契約解除や訴訟に至るような全面的な破綻だけが失敗ではありません。「動いてはいるが品質に不満が残る」「予算を大きく超過した」「リリースが半年遅れた」という部分的な未達も、事業計画への影響という意味では立派な失敗です。

プロジェクト規模が大きいほど失敗率は上がる（規模別データ）

JUAS『企業IT動向調査報告書2026』（2025年度調査）では、システム開発プロジェクトのQCD達成状況を規模別に集計しています。2025年度の結果は次のとおりです。

「人月」は1人のエンジニアが1ヶ月働く作業量を表す単位です。100人月未満には中小規模のWebシステムや業務アプリの多くが含まれ、500人月以上は基幹システム刷新のような大型案件が該当します。

この表から読み取れるポイントは2つあります。

第一に、プロジェクト規模が大きくなるほど、品質・予算・工期のすべてが悪化するという明確な傾向です。500人月以上の大型案件では、工期遅延が47.8%とほぼ半数に達しています。

第二に、100人月未満の中小規模でも、工期遅延15.7%・予算超過10.8%と、決して無視できない割合で未達が起きていることです。「小さい案件だから大丈夫」とは言えません。

なお、同調査の過去10年（2016〜2025年度）の推移を見ると、品質・予算・工期はいずれも悪化〜横ばい傾向が続いてきましたが、2025年度調査では一部で改善の兆しも見られています（ただし2025年度から回答選択肢が細分化された影響も指摘されており、単純な前年比較には留保が必要です）。それでも大型案件の半数近くが工期どおりに終わらないという事実は、発注側が前提として知っておくべき数字です。

大型案件の典型である基幹システムの刷新では、この規模リスクをどう抑えるかが最大の論点になります。基幹システムリプレイスの進め方の記事で、段階移行によるリスク低減策を解説しています。

計画どおりにいかなかった要因の1位は「ベンダーのスキル不足」

同じJUAS調査では、品質・予算・工期が計画どおりにならなかったプロジェクトについて、その要因も尋ねています（複数回答）。2025年度の結果を整理すると次のようになります。

注目すべきは、品質未達の要因として「ベンダーのスキル不足」が59.9%で最大となっている点です。前年度調査の56.8%からさらに3.1ポイント上昇しており、発注先選びの巧拙が品質を直接左右している実態が数字に表れています。

一方で、品質・予算・工期に共通する要因として「計画時の考慮不足」「想定以上の複雑さ」「仕様変更の多発」の3つが根強く上位を占めます。つまり失敗の責任はベンダー側だけにあるのではなく、発注側の計画・要件の固め方にも半分の原因があるということです。

失敗の芽は「要件定義」と「設計・実装・テスト」に集中する

同調査では、QCD悪化に影響が大きい工程についても集計しています。品質・予算・工期のいずれに対しても、影響が大きい工程として挙げられたのは次の2つでした。

• 要件定義：57.4〜69.0%
• 設計・実装・テスト：51.7〜74.1%

前年度との比較でも、要件定義が工期に与える悪影響は8.6ポイント増、設計・実装・テストが品質に与える悪影響は11.0ポイント増と、いずれも拡大傾向にあります。

背景として、同調査は「システムの影響範囲の拡大」（43.8〜48.9%）、「要件定義の難易度上昇」（40.4〜46.6%）、「IT人材の新規確保の困難化」（36.8〜44.3%）といった環境変化を挙げています。既存システムとの連携が増え、要件を固めること自体が年々難しくなっているのです。

ここまでのデータを一言でまとめると、こうなります。
失敗の頻度は規模に比例し、原因は「ベンダーの力量」と「発注側の計画・要件」に大きく二分され、勝負は要件定義で半分決まる。

システム開発が失敗する4つの類型

JUASの要因データと、争点が判決文で公になっている裁判例を突き合わせると、システム開発の失敗は次の4類型に整理できます。

それぞれの類型を、公知の裁判例とあわせて見ていきます。なお、以下で紹介する裁判例はいずれも判決や報道で公知となっている事実であり、特定の企業・組織の巧拙を論評する趣旨ではありません。どの類型の失敗も、規模や知名度に関係なく起こりうることを示す事例として参照します。

類型1：要件定義起因——仕様が固まらない・追加要望が止まらない

もっとも頻度が高いのがこの類型です。症状としては次のような形で現れます。

• システム導入の目的が言語化されておらず、機能の取捨選択の基準がない
• 要件定義が終わったはずなのに、開発中に追加・変更要望が続出する
• 完成したシステムが、現場が想定していた業務の流れと合わない

要件定義で決めた内容をもとに設計・実装・テストが進むため、この工程の曖昧さは後工程のすべてに波及します。JUAS調査で要件定義がQCD悪化への影響工程の筆頭（57.4〜69.0%）に挙がるのは、この構造によるものです。

この類型に関する著名な裁判例として、旭川医科大学とNTT東日本の病院情報システム開発をめぐる訴訟があります。2008年の受注後、発注者側から625項目に及ぶ追加開発要望が出されるなどして開発が難航し、契約解除と損害賠償をめぐる訴訟に発展しました。札幌高等裁判所は2017年8月31日、発注者側の協力義務違反を認定し、大学側にベンダーへ約14億1,500万円を支払うよう命じる判決を言い渡しています。

この判決が実務に示した論点は明確です。仕様を凍結した後の大量の追加要望は、発注者側の義務違反と評価されうるということです。システム開発は「お金を払えば要望を聞いてもらえる買い物」ではなく、発注側にも要件を固めて協力する法的な義務がある共同作業だと司法が明示した事例といえます。

類型2：ベンダー選定起因——発注先の技術力・管理能力の不足

JUAS調査で品質未達の要因1位となった「ベンダーのスキル不足」（59.9%）に対応する類型です。症状は次のような形で現れます。

• 提案時の説明と、実際の開発チームの技術力に差がある
• 設計品質が低く、後から改修しようとするとコストが跳ね上がる
• 実装の難易度をベンダー自身が見誤り、途中で「できません」となる

この類型の代表的な裁判例が、スルガ銀行と日本IBMの勘定系システム開発をめぐる訴訟です。開発は完成に至らないまま中止され、銀行側がベンダーに損害賠償を求めて2008年に提訴しました。東京高等裁判所は2013年9月26日にベンダー側へ約41億7,210万円の支払いを命じ、2015年7月に最高裁判所が上告を退けたことで、この判決が確定しています。

この裁判で示された重要な考え方が「プロジェクトマネジメント義務」です。判決では、ベンダーには開発規模や実現可能性を検証してリスクを発注者に説明し、困難であれば開発中止の提言も含めて適切な判断を促す義務があると認定されました。

発注側の視点でこの事例から学べるのは、「大手だから安心」という選定基準は成立しないということです。ベンダー選定では会社の規模や知名度ではなく、発注する案件と同種のシステムを、実際に完成させた実績があるかを確認する必要があります。

類型3：プロジェクト管理起因——計画の甘さと複雑さの過小評価

JUAS調査で工期遅延の要因1位となった「計画時の考慮不足」（52.5%）、2位の「想定以上の現行業務・システムの複雑さ」（48.8%）に対応する類型です。

• スケジュールにリスクバッファがなく、一つの遅れが全体に連鎖する
• 既存システムとの連携仕様の調査が浅く、開発中に想定外が続出する
• 進捗が「90%完了」のまま何週間も動かない（残り10%に本当の難所が隠れている）

この類型のやっかいな点は、要件定義もベンダー選定も間違っていないのに起きることです。原因は「未知のものを計画する」というシステム開発の本質的な難しさにあります。既存業務の例外処理、レガシーシステムの仕様不明部分、関係部署間の調整。これらは着手前には全容が見えず、進めるほどに複雑さが明らかになります。

JUAS調査が環境変化として挙げる「システム影響範囲の拡大」（43.8〜48.9%）は、この構造が年々深刻化していることを示しています。単独で完結するシステムは減り、社内外の複数システムと連携するのが当たり前になった結果、計画時に考慮すべき変数が増え続けているのです。

類型4：契約・体制起因——責任分界と異常時の設計不備

4つ目は、開発そのものではなく、契約内容や運用体制の設計に原因がある類型です。

• 請負か準委任か、契約形態と実態が合っておらず、責任の所在が曖昧
• 検収基準が契約書に定義されておらず、「完成」の解釈が食い違う
• 障害発生時に誰が何を判断するかが決まっておらず、被害が拡大する

前提として、システム開発の契約には大きく2つの形態があります。請負契約は「完成した成果物」に対して報酬を支払う契約で、完成責任はベンダーが負います。準委任契約は「作業の提供」に対して報酬を支払う契約で、ベンダーは専門家として誠実に作業する義務（善管注意義務）を負いますが、完成そのものは約束しません。要件が固まっていない段階の作業を請負で契約すると「何をもって完成か」が定義できず、逆にすべてを準委任にすると成果への責任が曖昧になります。工程ごとに適した契約形態を選び分けることが、責任分界を明確にする第一歩です。

異常時の体制設計の重要性を示す著名な事例が、みずほ証券と東京証券取引所の誤発注をめぐる訴訟です。2005年12月、みずほ証券による株式の誤発注が発生した際、東証の売買システムでは注文の取消処理が機能せず、損失は400億円を超える規模に拡大しました。損害賠償訴訟では過失割合が東証7対みずほ証券3とされ、東証側に約107億円の賠償を命じる判決が2015年9月に最高裁判所で確定しています。

この事例が示すのは、システムの失敗はリリース後にも起こるということです。正常系（想定どおりの操作）だけでなく、異常時に「止める」「取り消す」ための設計と、その判断体制まで含めてシステムの品質だという教訓は、規模を問わずすべての開発に当てはまります。

4類型それぞれの予防策

4つの類型は、それぞれ予防のポイントが異なります。順に整理します。

要件定義起因への予防策：目的の文書化と変更管理ルール

• 「なぜ作るのか」を1枚に文書化する：解決したい業務課題と、達成を測る指標（KPI）を先に決める。機能の取捨選択で迷ったとき、この1枚が判断基準になる
• 機能に優先順位をつける：「必須」「あった方がよい」「今回は見送る」の3段階に分け、必須機能だけで最初のリリースを設計する
• 変更管理のルールを最初に決める：仕様凍結後の変更は「影響調査→見積→両者合意」の手続きを踏むことを、開発開始前に文書で合意しておく。旭川医科大学の裁判例が示すとおり、凍結後の大量変更は発注側の義務違反にもなりうる
• 動くもので確認する：画面イメージやプロトタイプを要件定義段階で作り、「文章では合意したが、動かしたら違った」を前倒しで潰す

ベンダー選定起因への予防策：実績の「現物」を確認する

• 同種システムの実績を、実際に動く状態で見せてもらう：実績一覧の社名ロゴではなく、画面・管理機能・データ構造の考え方まで説明を求める
• 担当チームの体制を確認する：提案者と開発者が別なのは普通のこと。実際にプロジェクトを管理するPMの経験と、エンジニアの構成（自社/協力会社の比率）を聞く
• 第三者の認定・評価を参照する：開発プラットフォームの公式パートナー制度や認定資格は、ベンダーの技術力を外部の基準で確認できる数少ない手段
• 見積の内訳を工程別に出してもらう：要件定義・設計・実装・テストの配分が説明できないベンダーは、計画の解像度が低い可能性が高い

品質未達要因の1位が「ベンダーのスキル不足」59.9%である以上、ここに時間をかける価値は数字が裏づけています。複数社の比較検討にはシステム開発会社の比較記事（23社の特徴を整理）も参考にしてください。

プロジェクト管理起因への予防策：バッファと見える化

• スケジュールにバッファを明示的に積む：JUASのデータが示すとおり、大型案件の半数近くは工期どおりに終わらない。遅延を前提に、事業計画側の締切とシステムの完成予定の間に余裕を持たせる
• 既存システムとの連携部分を最初に調査する：「想定以上の複雑さ」の多くは連携部分に潜む。外部接続がある場合は、接続先の仕様確認を最優先タスクにする
• 進捗は「完成した機能の数」で測る：「進捗率90%」という報告は当てにならない。実際に動作確認できた機能単位で進捗を把握する
• 週次で課題リストを共有する：未解決の課題・決めるべき事項・決定期限を一覧化し、発注側とベンダーが同じリストを見る状態を維持する

契約・体制起因への予防策：検収基準と異常時設計

• 検収基準を契約書に書く：「何ができたら完成か」をテスト項目のレベルで合意しておく。曖昧なままだと、納品後の「これは仕様どおりか」論争の火種になる
• 契約形態と実態を合わせる：成果物の完成に責任を持つ請負か、作業の提供に責任を持つ準委任か。要件が固まらない段階の作業を請負で契約すると、双方にとってリスクが大きい
• 異常時の対応を設計に含める：障害発生時の連絡体制、システムを停止する判断基準と権限者を、リリース前に文書化する
• 保守・運用の条件を発注前に確認する：月額費用・対応範囲・対応時間。リリース後に「保守は別料金で月額が想定の3倍」と判明するケースは珍しくない

失敗の予兆チェックリスト——崩れる前に気づく

失敗するプロジェクトには、破綻が表面化する前の予兆があります。フェーズ別のチェックリストとして整理しました。

契約前の予兆

• システム導入の目的を、社内の誰も1分で説明できない
• ベンダーの見積が1枚もので、工程別の内訳がない
• 「なんでもできます」と言うだけで、できないこと・リスクの説明がない
• 同種システムの実績を、動く状態で見せてもらっていない
• 検収基準・変更管理・保守条件が契約書に書かれていない

要件定義〜開発前半の予兆

• 要件定義の成果物が「議事録の束」で、仕様として整理された文書がない
• 要望を伝えると全部「できます」と返ってくる（影響調査の形跡がない）
• 画面イメージやプロトタイプを一度も見ないまま実装が始まった
• 発注側の担当者が多忙で、ベンダーからの質問への回答が1週間以上滞留している

開発後半〜リリース前の予兆

• 進捗報告が「90%完了」のまま2週間以上変わらない
• デモを依頼すると「まだお見せできる状態ではない」と先送りされる
• PMや主要エンジニアが途中で交代し、経緯を知る人がいなくなった
• テスト工程の期間が、遅延を吸収するために当初計画から削られている
• 「リリース後に直します」という項目のリストが増え続けている

3つ以上当てはまる場合、そのプロジェクトは既に黄信号です。重要なのは、予兆の段階で手を打てば立て直しの選択肢が多く残っているということです。破綻が表面化してからでは、選べる手が限られます。

プロジェクトが崩れ始めたときの立て直し方

すでに雲行きが怪しい場合の対処を、手順として整理します。

手順1：責任追及より先に、事実の棚卸しをする

プロジェクトが崩れ始めると、発注側とベンダーの関係は「どちらの責任か」の議論に流れがちです。しかし、まずやるべきは感情を排した事実確認です。

• 成果物の現状：何が完成し、何が未完成か。完成分は実際に動作するか
• 合意の記録：契約書・要件定義書・変更依頼の履歴・議事録を時系列に並べる
• 残作業の見積：残りを完成させるのに必要な工数と費用の再見積
• 資産の再利用可能性：いまある設計・コードは、立て直しに使える品質か

あわせて、状況が整理できるまで追加の発注や仕様変更を一旦止めます。傷口が開いたまま作業を積み増すと、後の選択肢がさらに狭まります。

手順2：実際のレスキュー相談に多い2つのパターンを知る

Swoooにも、他社で開発されたシステムの改修や立て直しの相談が寄せられます。実際にご相談いただく中で多いのは、次の2つのパターンです。

パターン1：データベース設計が破綻していて、パフォーマンスが極端に悪い
画面や機能は一通り動くのに、データ量が増えると表示に何十秒もかかる。原因を調査すると、データベースの構造設計に無理があり、その上に機能が積み上がってしまっているケースです。表面的な機能は検収で確認できても、データ構造の品質は納品時に見えにくいため、運用が始まってから発覚します。

パターン2：外部サービスとのAPI連携が実装できていない
決済・地図・認証など外部サービスとの連携（API連携）は現代のシステムに不可欠ですが、この実装力がないまま案件を受けてしまう開発会社が実在します。連携部分だけが未完成のまま納品間際を迎え、そこで初めて実装できないことが判明するケースです。

共通するのは、どちらも機能一覧の確認だけでは発注前に見抜けないという点です。だからこそ、ベンダー選定の段階で「同種の連携実績があるか」「データ設計の考え方を説明できるか」を確認しておく意味があります。

手順3：立て直しの3つの選択肢から選ぶ

事実の棚卸しができたら、立て直しの進路は大きく3つです。

判断軸は「いまある資産は使える品質か」「残っている予算と時間はどれだけか」の2つです。第三者のエンジニアに現状のコードと設計を査定してもらうと、この判断の精度が上がります。

立て直しの具体的な進め方や、引き継ぎで確認すべき項目の詳細は、開発が頓挫したときのレスキューガイドで解説しています。

なお、契約解除や損害賠償を視野に入れる段階になった場合は、請負・準委任の別や既履行部分の扱いなど法的な論点が絡むため、IT分野に詳しい弁護士への相談をおすすめします。本記事で紹介した裁判例のとおり、ベンダー側にはプロジェクトマネジメント義務、発注側には協力義務があり、責任は一方だけに認定されるとは限りません。

発注前にできる最大の予防——要件定義とベンダー選定

ここまでのデータを振り返ると、打ち手の優先順位は明確です。QCD悪化への影響が最大の工程は「要件定義」であり、品質未達の要因1位は「ベンダーのスキル不足」でした。つまり、失敗リスクの大半は、開発が始まる前の2つの意思決定で決まります。

要件定義に予算と時間を配分する

要件定義の費用は、市場の一般的な目安として開発費全体の10〜15%程度、スクラッチ開発で単独の工程として発注する場合は50万〜200万円程度です。この投資を惜しんで実装を急ぐと、後工程での手戻りコストがこれを大きく上回ります。

発注側が要件定義までにやっておくべきことは、突き詰めると次の3点です。

• 目的の言語化：どの業務課題を解決するのか。成功をどの数字で測るのか
• 現行業務の整理：いまの業務フローと、例外的な処理がどこにあるか
• 優先順位の合意：社内の関係者間で「必須」と「見送り」の線引きを済ませておく

契約形態（請負・準委任）の選び方と、契約書で確認すべき条項については、システム開発の契約・発注ガイドで詳しく解説しています。

ベンダー選定で最低限確認する5項目

本記事の予防策から、選定時の確認事項を5つに絞ると次のとおりです。

1. 発注する案件と同種のシステムを完成させた実績があり、動く状態で確認できるか
2. 実際に担当するPM・エンジニアの体制と経験を説明できるか
3. 外部の認定・パートナー制度など、第三者基準の技術評価があるか
4. 見積の工程別内訳と、その根拠を説明できるか
5. リスクや「できないこと」を、契約前に自分から説明するか

1社の話だけで決めず、複数社に同じ条件で提案を依頼して比較することも重要です。候補探しにはシステム開発会社23選の比較記事をあわせてご覧ください。

内製化を検討する場合も「失敗パターン」は同じ構造

外部委託の失敗を受けて「それなら自社で作ろう」と内製化に舵を切る企業もあります。IPA『DX白書2023』（2022年度調査）によれば、コア事業（競争領域）のシステム内製化率は米国53.1%に対して日本は24.8%にとどまっており、内製化の余地が大きいのは事実です。

ただし、内製化にも要件の曖昧さ・スキル不足・計画の甘さという同じ構造の失敗パターンがあり、体制づくりを誤ると外注以上に高くつきます。内製化特有のつまずきどころは内製化の失敗パターン解説で整理しているので、検討中の方は参考にしてください。

あわせて、体制づくりから技術移管までの全体像は開発内製化の進め方の記事で整理しています。

システム開発の失敗に関するよくある質問

Q1. システム開発は何割が失敗するのですか？

「7割が失敗」といった数字が流通していますが、出典を確認できないものが多く、鵜呑みにはできません。出典が明確な国内データとしては、JUAS『企業IT動向調査報告書2026』（2025年度調査・957社回答）があり、500人月以上の大型案件では工期遅延47.8%・予算超過42.2%・品質不満29.6%、100人月未満の中小案件では工期遅延15.7%・予算超過10.8%・品質不満8.8%です。「何をもって失敗とするか」と「プロジェクトの規模」によって、数字は大きく変わります。

Q2. 失敗のいちばんの原因は何ですか？

同調査では、品質未達の要因1位が「ベンダーのスキル不足」（59.9%）です。一方、品質・予算・工期に共通する要因として「計画時の考慮不足」「想定以上の現行業務・システムの複雑さ」「仕様変更の多発」が上位に並びます。ベンダーの力量と発注側の準備、その両方が原因になるというのがデータの示す答えです。

Q3. 開発が失敗した場合、支払った費用は取り戻せますか？

契約形態（請負か準委任か）と、失敗の原因がどちらにあるかによって結論が変わります。本記事で紹介したとおり、ベンダー側に賠償が命じられた判決（スルガ銀行の事例）もあれば、発注者側の協力義務違反が認定された判決（旭川医科大学の事例）もあります。責任は一方に決まっているわけではないため、契約書・議事録・変更履歴などの記録を整理したうえで、IT分野に詳しい弁護士に相談してください。

Q4. 開発の途中でベンダーを変更することはできますか？

可能です。ただし、ソースコード・設計書・各種アカウントの引き渡し条件を確認したうえで、既存の成果物が再利用できる品質かを第三者に査定してもらうことをおすすめします。データベース設計のレベルで問題がある場合、引き継ぐより作り直した方が結果的に安く済むこともあります。判断の手順は本記事の「立て直しの3つの選択肢」を参照してください。

Q5. 小規模なアプリ開発なら失敗の心配はいりませんか？

規模が小さいほどリスクは下がりますが、ゼロにはなりません。100人月未満のプロジェクトでも工期遅延15.7%・予算超過10.8%が発生しています（JUAS 2025年度調査）。また、小規模案件は発注側のチェック体制も簡素になりがちで、データ設計や外部連携のような「見えない品質」の問題が納品後に発覚するケースがあります。規模にかかわらず、目的の言語化と実績確認という基本は同じです。

Q6. アジャイル開発を採用すれば失敗は防げますか？

アジャイル開発は、短い期間で動くものを作って確認を繰り返す進め方で、「完成してから初めて動かしたら想定と違った」という要件定義起因の失敗を減らす効果が期待できます。一方で、全体予算やスコープの上限管理を怠ると「作り続けているのに終わらない」状態に陥りやすく、進め方を変えただけでは計画・体制起因の失敗は防げません。ウォーターフォールかアジャイルかという手法の選択より、目的の言語化・変更管理のルール・進捗の見える化という本記事の基本を押さえることが先決です。

Q7. 発注側にシステムの知識がなくても大丈夫ですか？

プログラミングの知識は不要ですが、「丸投げ」は裁判例が示すとおりリスクです。発注側には要件を固めて協力する義務があり、業務の内容と目的を説明できるのは発注側だけです。最低限、（1）解決したい業務課題の言語化、（2）ベンダーからの質問に週次で回答できる担当者の確保、（3）本記事の予兆チェックリストでの定期的なセルフチェック、の3つは発注側の仕事として確保してください。社内に知見がない場合は、ベンダーから独立した立場で要件定義を支援する会社に入ってもらう方法もあります。

まとめ：失敗は「発注前」にもっとも減らせる

本記事の要点を整理します。

• JUAS 2025年度調査では、500人月以上の大型案件で工期遅延47.8%・予算超過42.2%。規模が大きいほどQCDは悪化する
• 品質未達の要因1位は「ベンダーのスキル不足」59.9%。同時に「計画時の考慮不足」「複雑さの過小評価」「仕様変更の多発」という発注側も関わる要因が根強い
• 失敗は「要件定義・ベンダー選定・プロジェクト管理・契約体制」の4類型で整理でき、裁判例はベンダーのプロジェクトマネジメント義務と発注側の協力義務の両方を認めている
• 予兆の段階で気づけば選択肢は多い。崩れ始めたら、責任追及より先に事実の棚卸しと「止血」を行う
• リスクの大半は開発開始前の2つの意思決定——要件定義への投資とベンダー選定——で決まる

Swoooは、新規事業のシステム・アプリ開発を要件定義の段階から支援しています。運営は東証グロース上場の株式会社アイビス（証券コード9343）。累計50件以上の開発支援実績をもとに、他社で開発したシステムの立て直しに関する相談もお受けしています。

「この計画で進めて大丈夫か」という発注前の壁打ちからで構いません。無料相談はこちらからどうぞ。