--- title: "炎上プロジェクトとは：システム開発が炎上する兆候と原因、発注者側の立て直し手順" url: "https://www.issoh.co.jp/column/details/19782/" published: 2026-11-14 updated: 2026-11-15 categories: ["DX"] publisher: "株式会社一創" --- # 炎上プロジェクトとは：システム開発が炎上する兆候と原因、発注者側の立て直し手順 炎上プロジェクトとは、遅延・予算超過・品質の崩れが重なり、当初の計画のままでは約束した納期や品質を守れなくなったプロジェクトのことです。2026年に公表された調査では、IT系のプロジェクト経験者の44.3%が「炎上した、または炎上しかけた」経験を持っていました。この記事では、システム開発が炎上する原因の内訳と、発注者が定例会や成果物から読み取れる兆候を整理したうえで、発注者側が主導する立て直しの手順（現状の棚卸し、スコープの再定義、体制増強、PMOの投入、変更契約）を順に解説します。立て直しを諦めて中止に切り替える条件も、契約の条文と合わせて示します。 ## まとめ：炎上プロジェクトは兆候の早期検知と発注者主導のスコープ再定義で収める 炎上の原因で多いのは、見積の甘さと要件の追加・変更の繰り返しです。どちらも受託側だけでは止められず、発注者が「何を、いつまでに、どこまで作るか」を決め直さない限り、残業と要員追加を重ねても火は消えません。 立て直しは、①作業を止めずに現状を棚卸しする、②残作業を見積り直す、③必須機能と後回しにできる機能を分けてスコープを絞る、④足りない役割だけを補う、⑤変更管理書と変更契約で新しい計画を確定する、の順で進めます。発注者側で進捗を見張るPMOは、①の棚卸しを始める時点から置く目的は、再見積の数字を検証することです。人を足すのは最後の手段で、遅れている工程にそのまま要員を追加すると立ち上がりの負荷でさらに遅れます。 再見積の結果、残り費用が当初予算の倍を超える、または業務上の期限にどう組み替えても間に合わない場合は、立て直しではなく中止か作り直しを選びます。モデル契約では発注者に中途解約の権利がありますが、そこまでに受託側が行った作業の対価と損害の負担が伴います。 ## 炎上プロジェクトとは：遅延・予算超過・品質の崩れが重なった状態と発生頻度 ### デスマーチ・単なる遅延と炎上プロジェクトを分ける2つの判定基準 スケジュールが数日遅れているだけの案件は、炎上とは呼びません。炎上プロジェクトと判断する目安は2つあります。1つは、遅延・予算超過・品質不良のうち2つ以上が同時に起きていること。もう1つは、現在の体制と計画のままでは挽回の見込みが立たず、計画そのものを作り直す必要があることです。 似た言葉に「デスマーチ」があります。デスマーチは、無理な納期と長時間労働が続く現場の状態を指す言葉で、主語は作業者です。炎上プロジェクトはそれより範囲が広く、発注者・受託側の双方を含むプロジェクト全体の破綻状態を指します。[デスマーチ](https://www.issoh.co.jp/column/details/19804/)は炎上の結果として現場に現れる症状の1つ、と整理すると混同しません。 平時の進捗遅れの見つけ方と会議運用は[プロジェクト進捗管理とは？遅延を防ぐ見える化の方法と会議運用の実務](https://www.issoh.co.jp/column/details/15672/)で扱っています。本記事は、そこから外れて計画の作り直しが必要になった後の対応に絞ります。 ### フラッグスの2026年調査で炎上経験44.3%、成功の定義が曖昧69.8% 炎上がどの程度ありふれているかは、フラッグス株式会社が2026年4月30日に公表した[「プロジェクトマネジメントの実態調査」](https://prtimes.jp/main/html/rd/p/000000022.000103733.html)で確かめられます。2026年1月21日〜2月3日にインターネットで235名に聞いたもので、過去3年に「炎上した、または炎上しかけた」プロジェクトを経験した人は44.3%でした。 同じ調査で、プロジェクト開始時に成功の定義が明確だったと答えた人は30.2%にとどまり、69.8%は不明確・曖昧だったと回答しています。誰が何を意思決定するかが明確だったという回答も31.1%でした。炎上を経験した104名では、PMと現場で目標の認識がずれていたと答えた割合が89.4%で、炎上していない層（63.4%）より26ポイント高くなっています。 回答者は受託側のPMやエンジニアが中心で、発注者だけを対象にした数字ではありません。それでも「何をもって成功とするか」と「誰が決めるか」の2つが、炎上した案件で欠けやすいことは読み取れます。どちらも発注者が決める事柄です。 ## システム開発が炎上する原因：見積・要件変更・意思決定の不足が連鎖する構造 ### 見積の甘さ49.0%と要件の追加・変更45.2%が上位に並ぶ炎上要因の内訳 前述の調査で炎上経験者104名に要因を聞いた結果（複数回答）は、次の順でした。 | 炎上の要因 | 回答割合 | 主に決める側 | | ------------------ | ----- | ------------- | | スケジュールやタスクの見積が甘かった | 49.0% | 受託側（前提条件は発注者） | | 要件の追加・変更が頻発した | 45.2% | 発注者 | | 成功の定義が曖昧だった | 36.5% | 発注者 | | 進捗や課題の情報が共有されなかった | 27.9% | 双方 | 上位2つは、一方が他方を引き起こす連鎖関係です。見積は要件の前提の上に立っているので、要件が動けば見積は自動的に外れます。追加のたびに費用と日程を見積り直していれば炎上にはなりませんが、「小さな変更だから」と同じ予算と納期のまま積み増すと、ある時点で計画が持たなくなります。見積の予実差の測り方と予備の積み方は[見積もり精度とは？予実差の測り方と段階別の目安・予備の決め方](https://www.issoh.co.jp/column/details/11003/)を参照してください。 ### 発注者側が作る炎上の原因：意思決定者の不在と未確定事項の先送り デジタル庁の[DS-100 デジタル・ガバメント推進標準ガイドライン（2026年6月12日決定）](https://www.digital.go.jp/assets/contents/node/basic%5Fpage/field%5Fref%5Fresources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/54d8725e/20260715%5Fresources%5Fstandard%5Fguidelines%5Fguideline%5F01.pdf)は、第3編第5章で「要件定義が不十分なときには、計画の遅延又は情報システムの機能・性能が要求水準に満たないものとなる事態等が発生する可能性が高まる」と書いています。政府の情報システム向けの規程ですが、民間の受託開発でも事情は同じです。 発注者側で炎上の種になりやすいのは、次の3つです。 - 業務部門ごとに要望を出す人はいるが、最終的に採否を決める人がいない - 決めきれない仕様を「後で決める」としたまま、確定期限も費用の扱いも決めていない - 受託側から確認を求められた資料のレビューが1〜2週間止まる 2つ目について、IPAのモデル契約は「未確定事項」として扱う手順を用意しています（第36条）。未確定の内容、確定予定時期、確定後の修正で費用や納期が変わる場合に発注者が受け入れることを書面にしておく方式です。要件定義の段階で何を決めておくべきかは[要件定義とは？目的・進め方・成果物と失敗を防ぐポイント](https://www.issoh.co.jp/column/details/12848/)で整理しています。 ## 炎上の兆候：発注者が定例会の報告と成果物から読み取れる早期警報 ### 進捗報告で見抜く兆候：完了率90%の停滞と残作業の見積り直し拒否 炎上は、ある日突然起きるわけではありません。多くの場合、定例会の報告に数週間前から兆候が出ています。発注者が見るべきは、完了率そのものより数字の動き方です。 | 兆候 | 報告での見え方 | 確認する質問 | | ---------- | ---------------- | -------------- | | 完了率の停滞 | 90%前後のまま2週以上動かない | 残り10%の作業一覧と工数は | | 遅延理由の繰り返し | 同じ理由で3回以上遅延報告 | 原因への対策は何を変えたか | | 残作業の未再見積 | 当初の計画値で残りを報告 | 今わかっている情報で見積ると | | テスト開始の後ろ倒し | 開発完了とテスト開始日が近づく | 結合テストの開始判定基準は | | 報告の粒度の後退 | 担当別から「全体で順調」に変わる | 担当ごとの予実を出してほしい | 実務では、まず「完了率の停滞」と「残作業の未再見積」の2つだけを見れば足ります。90%で止まる案件は、残りの10%に未確定の仕様や難しい結合部分が溜まっていることが多く、そこから実際の作業量が当初の数倍に膨らみます。 ### 成果物と会議で見抜く兆候：継続検討事項の滞留と主要メンバーの交代 報告以外の兆候は、議事録と体制に出ます。IPAのモデル契約の第12条は、連絡協議会の議事録に「決定された事項」「継続検討とされた事項」と、継続検討事項の検討スケジュール・担当者を書くよう定めています。この「継続検討」の件数が定例のたびに増えていく状態は、決めるべきことが決まらないまま開発が進んでいる証拠です。 体制面では、受託側のPMや設計の中心人物が予告なく交代する、夜間・休日の作業報告が増える、障害票の起票件数が週を追って増えるのに解決件数が横ばい、といった変化が続きます。1つだけなら偶然でも、2つ以上重なったら受託側の責任者に会議の場で状況説明を求めてください。 ## 発注者側の立て直し手順：現状の棚卸しからスコープ再定義・変更契約まで ### 手順1〜2：作業を止めずに現状を棚卸しし、残作業を見積り直す 炎上を認めた直後にやることは、犯人探しではなく事実の確定です。開発を全面停止すると要員が散り、再開時の立ち上げにかえって時間がかかるため、作業は続けたまま次の順で棚卸しします。 1. 機能一覧を出し、機能ごとに「完了・作業中・未着手・仕様未確定」の4区分で状態を付ける 2. 未解決の課題と障害を1つの表に集め、重大度と担当者を付ける 3. 「仕様未確定」の項目について、発注者側で決める期限を1つずつ置く 4. 受託側に、残作業を当初計画ではなく現時点の情報で見積り直してもらう 5. 再見積の結果を、当初の予算・納期と並べて差分を出す 期間の目安は1〜2週間です。4番目の再見積は受託側にとって不利な数字が出る作業なので、発注者が「数字が増えても責めない、正確さを求める」と先に伝えておくと、楽観的な数字で取り繕われることを防げます。課題を集める表の列設計は兄弟記事の[課題管理表の作り方](https://www.issoh.co.jp/column/details/19764/)が参考になります。 ### スコープ再定義：稼働日に必須の機能と第2期へ送る機能を分ける判断基準 再見積の差分が出たら、予算と納期を動かすか、作る範囲を削るかを決めます。多くの案件では納期を動かせない理由（法改正の施行日、既存システムの保守切れ、決算期）があるので、範囲を削る判断が中心になります。 機能を残すか送るかは、「その機能がないと稼働日に業務が止まるか」で判断します。止まらないが手間が増えるだけの機能、帳票の体裁、管理画面の便利機能、まだ使う部門が決まっていない機能は、第2期に送る候補です。送った機能は捨てたわけではないので、第2期の範囲として一覧に残し、関係部門に送った理由を説明します。 炎上の原因が要件追加の積み重ねなら、範囲を戻したあとも同じことが再発します。追加要望を変更管理と追加見積で受ける仕組みは[スコープクリープとは：原因と防ぎ方、要件追加を変更管理と追加見積で扱う契約の要点](https://www.issoh.co.jp/column/details/19768/)で詳しく扱っています。 ### 体制増強の落とし穴：遅れている工程への要員追加が逆効果になる条件 遅れたら人を足す、という発想は直感的ですが、ソフトウェア開発では逆効果になる場面があります。フレデリック・ブルックスが1975年の著書『人月の神話』で示した「遅れているソフトウェアプロジェクトへの要員追加は、さらに遅らせる」という経験則（ブルックスの法則）です。新しい要員が仕様と既存のコードを理解するまでの教育を既存メンバーが担い、連絡経路も人数とともに増えるためです。 要員を追加して効くのは、次の条件を満たす場合に限られます。作業が独立した単位に切り分けられている（画面単位のテスト、データ移行の検証など）、追加要員がその技術と業務にすでに詳しい、追加から納期まで少なくとも2〜3か月ある。この3つが揃わないなら、人数ではなく、決定が遅い役割（仕様を決める人、レビューする人）を補うほうが早く効きます。 ### PMOを発注者側に置く：棚卸し時に投入するタイミングと渡しておく権限 炎上中の発注者の担当者は、本来の業務と社内調整と受託側への対応を同時に抱え、進捗の数字を検証する余力がなくなります。ここで発注者側に進捗と課題を横断して見張るPMO（プロジェクトマネジメントオフィス）を置くと、報告の数字が実態と合っているかを第三者の目で確かめることが可能です。DS-100も第2編第2章で、PMOの機能を「作業の不作為や遅延を防止する」ためのものとして位置付けています。 投入のタイミングは、手順1の棚卸しを始める時点が理想です。棚卸しと再見積の妥当性をPMOが確かめることで、その後の再計画の土台がぶれにくくなります。権限としては、受託側に資料の提出を求めること、定例会の議題を決めること、発注者側の決裁者に直接報告することの3つを渡しておかないと、単なる議事録係で終わります。PMOの役割の定義を整理した記事が、[PMOとは？役割・種類とPMとの違い](https://www.issoh.co.jp/column/details/19156/)です。一創では、炎上した案件の棚卸し・再見積の検証から再計画づくりまでを発注者側で支える[要件定義・RFP作成・PMO支援](https://www.issoh.co.jp/service/system/pmo/)を提供しています。 ### 変更契約で新計画を確定する：IPAモデル契約の変更管理書の8項目 スコープと体制を決め直しても、口頭の合意だけでは次の争いの種になります。[IPAの情報システム・モデル取引・契約書（第二版）](https://www.ipa.go.jp/digital/model/model20201222.html)のひな型は、第37条で変更管理の手順を定めています。変更提案を受けた側が「変更管理書」を交付し、連絡協議会で可否を協議する流れです。変更管理書に書く事項は8つあります。 1. 変更の名称 2. 提案の責任者 3. 年月日 4. 変更の理由 5. 変更に係る仕様を含む変更の詳細事項 6. 変更のために費用を要する場合はその額 7. 検討期間を含めた変更作業のスケジュール 8. その他変更が契約の条件（作業期間又は納期、委託料、契約条項等）に与える影響 双方の責任者が記名押印すると変更は確定し、納期や委託料が変わる場合は第33条にもとづく変更契約の締結で確定します。炎上の立て直しでは、削った範囲・延ばした納期・追加費用をこの形式で1枚にまとめ、変更契約まで済ませてから新計画で走り出してください。請負から準委任へ切り替えるかどうかもこの場で決めます。契約形態の違いは[準委任契約とは？請負・派遣との違い](https://www.issoh.co.jp/column/details/13187/)で確認できます。 ## 立て直しか中止かの判断：続行を見送る条件とモデル契約の中途解約 ### 立て直しを選ぶ条件と、中止・作り直しに切り替える条件の比較表 すでに投じた費用を惜しんで続行を選ぶと、損失がさらに膨らむことがあります。判断はこれまでに払った金額ではなく、これから払う金額と得られる結果で行います。 | 判断材料 | 立て直しを選ぶ | 中止・作り直しを選ぶ | | ------- | ------------- | -------------- | | 残作業の再見積 | 当初予算の残額の2倍以内 | 2倍を超える、または出せない | | 業務上の期限 | 範囲を削れば間に合う | どう削っても間に合わない | | 設計の状態 | 部分的な手直しで済む | データ構造など根本に誤り | | 受託側の体制 | 責任者が残り説明できる | 中心人物が離脱し説明不能 | | 代替手段 | パッケージ等で代替できない | 既製品で業務を回せる | 1行でも右の列に当てはまる場合は、続行を前提にせず、中止・作り直し・既製品への切り替えを同じ表で比べてください。特に「設計の状態」で根本に誤りがある案件は、範囲を削っても稼働後の改修費が膨らむので、立て直しは選びません。 ### IPAモデル契約第38条が定める協議不調時の解約と発注者が負う支払い 中止を選ぶ場合も、契約上の手順を踏みます。IPAのモデル契約ひな型の第38条は、変更の協議の結果、納期や委託料などの条件に影響することを理由に発注者が続行を中止しようとするとき、発注者は個別契約の未了部分を解約できると定めています。そのうえで、中止時点までに受託側が遂行した業務の委託料を支払い、解約によって受託側に生じた費用その他の損害を賠償しなければなりません。 ひな型には、受託側から中止を提言できるB案も用意されています。条件に重大な影響があり続行が客観的に困難な場合、受託側が理由を示して書面で中止を提言でき、発注者が合理的な期間内に合理的な理由なく応じなければ、受託側から解約できる内容です。自社の契約がどちらの案を採っているか、そもそも同種の条項があるかを、中止を口にする前に確認してください。条項がない契約では、民法の規定と個別の交渉に委ねられ、決着までの時間が読めなくなります。 ## 再炎上を防ぐ発注者の準備：成功の定義と意思決定者を最初に文書化する ### キックオフ前に発注者が文書化する成功の定義と意思決定者の一覧 立て直した案件が再び炎上する典型は、範囲を削った後も「何をもって成功とするか」が書かれていないケースです。新計画の開始前に、稼働日、稼働時に必須の業務、受入の合否基準、予算の上限の4つを1枚にまとめ、発注者側の決裁者の承認を取ります。 あわせて、仕様の採否を決める人、追加費用を承認する人、受入の合否を決める人を名前で書き出します。冒頭の調査で、意思決定者が明確だった案件は31.1%しかありませんでした。名前が1人ずつ入るだけで、継続検討事項の滞留はかなり減ります。プロジェクト計画書のどこにこれらを書くかは[プロジェクト計画書の書き方](https://www.issoh.co.jp/column/details/19762/)で項目ごとに示しています。キックオフの議題と決める運営ルールは[キックオフミーティングの記事](https://www.issoh.co.jp/column/details/19786/)で扱います。 ### 再開後の週次定例で発注者が見る4つの指標と外部に任せる範囲の線引き 再開後の週次定例では、発注者は次の4つだけを毎週同じ形式で受け取ります。機能ごとの完了数（予定と実績）、残作業の見積の推移、未解決の課題と障害の件数、継続検討事項の件数と最古の起票日です。前の週より悪化した指標があれば、その場で理由と対策を聞きます。 この4指標の検証や受託側との交渉まで社内で抱えきれない場合は、指標の集計と妥当性の確認を外部のPMOに任せ、範囲の採否と追加費用の承認は発注者側に残します。決める権限まで外部に渡すと、発注者が判断の経緯を把握できなくなり、次の炎上のときに同じ説明をやり直すことになります。 ## 炎上プロジェクトの原因・兆候・発注者の立て直しに関するよくある質問 炎上プロジェクトについて、発注者の担当者からよく出る質問をまとめました。 ### 炎上プロジェクトとはどういう意味ですか？ 遅延・予算超過・品質の崩れが重なり、現在の計画と体制のままでは約束した納期や品質を守れなくなったプロジェクトを指す業界の俗語です。SNSで批判が集中する「炎上」とは意味が異なります。数日の遅れや一時的な障害だけでは炎上とは呼ばず、計画そのものを作り直す必要が出た段階で使われます。現場の長時間労働を指す「デスマーチ」は、炎上の結果として現れる症状の1つです。 ### プロジェクトが炎上する一番多い原因は何ですか？ フラッグス株式会社の2026年の調査では、炎上経験者104名の49.0%が見積の甘さ、45.2%が要件の追加・変更の頻発を挙げています。2つが連鎖する理由は、要件が動くたびに見積の前提が崩れるためです。追加要望を受けるたびに費用と日程を見積り直す変更管理の仕組みがあれば、炎上に至る前に止められます。 ### 炎上したプロジェクトに人を追加すれば間に合いますか？ 多くの場合、間に合いません。遅れている工程に新しい要員を入れると、既存メンバーが教育と調整に時間を取られ、短期的にはさらに遅れます。ブルックスの法則として知られる経験則です。作業を独立した単位に切り分けられ、追加要員がその技術と業務に詳しく、納期まで2〜3か月以上ある場合に限って効果が出ます。 ### 炎上したらベンダーを変えるべきですか？ 途中でベンダーを変えると、新しいベンダーが仕様と既存のコードを読み解く期間が必要になり、その間はほぼ進みません。受託側の責任者が残っていて状況を説明でき、再見積に応じるなら、まず同じベンダーで立て直しを試みるほうが早く収まります。中心人物が離脱して説明できない、再見積を拒むといった場合は、中止と作り直しを比較する段階です。 ### 発注者は炎上の責任を問われることがありますか？ あります。システム開発の契約では、要件の決定や資料の提供、受入検査など、発注者の協力がないと進まない作業があり、IPAのモデル契約も発注者と受託側双方の分担作業と協力を定めています。発注者が仕様の決定を遅らせたことが遅延の原因であれば、受託側だけに責任を負わせることはできません。個別の責任の判断は契約内容によるため、弁護士への相談が必要です。 ## 関連記事 - [ベンダーコントロールとは？発注者が進捗・品質・変更を握る方法と偽装請負にならない線引き](https://www.issoh.co.jp/column/details/19770/)：炎上する前の平時に、発注者が受託側の進捗と品質を管理する方法 - [リスク管理表の作り方：発生確率・影響度の項目と課題管理表との違い、更新の運用](https://www.issoh.co.jp/column/details/19780/)：炎上の兆候を予兆として事前に見張るための表 - [システム開発のプロジェクト管理とは？進め方・QCDと工程/品質/リスク管理と発注側の役割](https://www.issoh.co.jp/column/details/15670/)：立て直し後の工程・品質管理の全体像 --- 出典: [炎上プロジェクトとは：システム開発が炎上する兆候と原因、発注者側の立て直し手順]()（株式会社一創）