炎上プロジェクトの立て直し方｜発注者が最初にやる火消しの4つと、外に頼むときの判断

納期のたびに「あと少しです」と言われ、追加の見積もりが届き、テストに入っても不具合の数が減らない。開発を頼んでいる側から見ると、何がどこまでできているのかは開発会社の説明でしか分からず、燃えていると気づいたときには、どこから手を付ければよいのかが見えなくなっています。

ネットで「炎上プロジェクト」を調べても、出てくるのは開発の現場にいるプロジェクトマネージャーが火を消す話がほとんどです。けれども、お金を出し、完成したシステムを使うのは発注者であり、発注者にしか打てない手もあります。

火消しの最初の一手は、人を足すことでも作り直すことでもなく、新しい追加を止めて、残っているコードと資料から事実を集めることです。この記事では、炎上とデスマーチの意味から、システム開発が燃える原因、発注者が最初にやる4つのこと、外の会社に立て直しを頼むときの判断までを、発注する側の目線で順に説明します。

炎上プロジェクトとは

炎上プロジェクトとは、予定・費用・品質のどれかが大きく崩れ、今のやり方を続けても元に戻らなくなったプロジェクトを指す言葉です。納期に間に合わない、完成が見えない、頼んだものと違うものが出てくる、といった形で表に出ます。

「炎上」と「デスマーチ」の違い

よく似た言葉にデスマーチがあります。デスマーチは、無理な日程や人数のまま、長い残業や休日の作業で走り続けるプロジェクトを指す俗語で、IT の現場で広く使われてきました。炎上がプロジェクトの「状態」を指すのに対して、デスマーチはその状態のまま無理に進める「走り方」を指すと考えると分かりやすく、デスマーチを続けるほど作る人が疲れて不具合が増え、炎上はかえって広がりやすくなります。

発注者から見える炎上のサイン

発注者は開発の中を毎日見ているわけではないので、気づくのが遅れがちです。次のような様子が2つ以上重なったら、炎上を疑って事実を確かめ始める時期だといえます。

システム開発が炎上する主な原因

システム開発の炎上には、いくつかの原因が重なっていることがほとんどです。発注者の側から見て確かめやすいものを4つ挙げます。

1つ目は、何を作るかが決まりきらないまま作り始め、途中で要件の追加や変更が止まらなくなることです。決める人が社内でそろっていないと、開発会社は決まった所から作るしかなく、あとから作り直す所が増えていきます。

2つ目は、見積もりと計画に最初から無理があることです。作る量に対して日程や人数が足りないと、遅れを取り戻そうとして残業と人の追加が続き、先に書いたデスマーチの形になりやすくなります。

3つ目は、進み具合が見えていないことです。作業の一覧や課題の一覧が無い、あっても更新されていないと、どこまでできていて何が残っているのかを、発注者も開発会社も同じ物差しで話せません。

4つ目は、窓口と作る人の間で話が伝わりきらないことです。お客さまの質問を窓口が持ち帰り、作る人に伝え、作る人が調べて窓口に戻す、という往復のたびに日数がかかり、細かい所が抜け落ちて食い違いが生まれます。追加や変更を窓口が正しくつかめないと後から追加が増え、予定の組み直しが続くことになります。

炎上プロジェクトの火消し｜発注者が最初にやる4つ

燃えているときほど「とにかく急いで」と言いたくなりますが、先に足元を固めた方が結果として早く収まります。発注者が自分で始められる火消しは、次の4つです。

1. 新しい追加と変更をいったん止める

まず、これから頼もうとしていた追加や変更を止めます。燃えている最中に新しい要望を足すと、今ある遅れの上に作業が積み重なり、何が原因で遅れているのかも分からなくなるからです。どうしても外せないものだけを残し、ほかは「立て直してから」と決めて一覧にしておきます。

2. 残っているコードと資料から事実を集める

次に、開発会社の説明ではなく、手元に残っているものから事実を集めます。最新のソースコード、設計書や仕様書、課題や不具合の一覧、打合せの議事録、見積書と契約書がそろっているかを確かめ、無いものは無いと分かるように書き出しておきます。作った人の説明と、コードや記録に残っている中身が食い違うことは珍しくないので、事実は記録の側に寄せて集めるのがこつです。

3. 「残っている作業」と「止まった原因」を分ける

集めた事実をもとに、できている所と残っている作業、それから止まった原因を分けて整理します。残りの作業が多いのか、作業は少ないのに仕様が決まらずに止まっているのか、作ったものの出来が悪くて直しが終わらないのかで、打つ手はまったく変わるからです。このとき、確かめた事実と、まだ推測でしかないことと、確かめられていないことを混ぜないようにすると、後の判断がぶれにくくなります。

4. 続け方をいくつか比べて決める

最後に、続け方を1つに決めつけず、いくつか並べて比べます。今の開発会社と範囲を絞って続ける、残りの一部だけを別の会社に頼む、全体を別の会社に引き継ぐ、といった形があり、どれを選ぶかは3つ目で分けた原因と、使える予算・日程によって決まります。選んだあとは、残りの作業と進め方を組み直し、計画を引き直してから再開します。

立て直しで避けたいこと

火消しを急ぐあまり、かえって火を広げてしまう打ち手もあります。よく見かけるものを4つ挙げます。

• 人を足すだけで乗り切ろうとする: 新しく入った人が中身をつかむまでには時間がかかり、その間は教える人の手も止まるので、遅れがかえって広がりやすい
• 作り直しを急いで決める: 残っているコードや資料、決まっている仕様の中には使えるものが多く、中身を確かめずに捨てると、同じ所でまた迷うことになる
• 責任の追及から始める: 原因を確かめる前に誰のせいかを決めにいくと、事実が出てこなくなり、立て直しに必要な材料が集まらない
• 残りの見積もりをそのまま別の会社に渡す: 前の会社の見積もりは前の会社の見立てでつくられているので、引き継ぐ側は中身を確かめてから見積もり直す必要がある

外の会社に立て直しを頼むとき

社内に開発の分かる人がいない、今の開発会社との話がかみ合わない、という場合は、外の会社に現状を確かめてもらうのも1つの手です。遅れが主な悩みなら「頓挫・遅延したシステム開発を、再開します」で、遅れの確かめ方と再開の進め方を紹介しています。

開発会社と連絡そのものが取れなくなっている場合は、確かめる順番が変わります。「開発会社・制作会社と連絡が取れないときに最初の1週間でやること」を先に読んでください。また、作った人がいないシステムを丸ごと引き継ぐときに手元にそろえるものは、「他社が作ったシステムの引き継ぎ」で詳しく書いています。

デイワンの進め方

デイワンでは、炎上した開発を途中から引き受けて立て直すご相談をお受けしています。進め方は次の4つの段です。

作った人がいなくても、仕様書が無くても、残っているソースコードがあれば、AI で読み解いてどこまでできていて何が残っているかを確かめます。窓口に立つ担当者がエンジニアなので、ご質問を持ち帰って伝言するやり取りが無く、その場で判断して話を進められます。作り直しを前提にはせず、残っているコードや資料、決まっている仕様を活かして進め方を組み直します。

一方で、前の開発会社との法的な争いへの対応、ソースコードが手に入らない立て直し、他社の残りの見積もりをそのままお引き受けすること、常駐での作業はお受けしていません。調査は完成をお約束するものではなく、完成までの開発は、調査の結果をもとに別のご契約でお受けします。

頼む前にそろえておくもの

外の会社に相談するときは、火消しの2つ目で集めたものがそのまま材料になります。全部がそろっていなくても構わないので、あるものと無いものが分かる形にしておくと、最初の相談で話が早く進みます。

• 最新のソースコード（どこに置いてあるか、誰が出し入れできるか）
• 設計書・仕様書・画面の一覧など、残っている資料
• 課題や不具合の一覧、打合せの議事録
• 見積書・契約書と、ここまでの支払いの記録
• いつまでに何を動かしたいか（いちばん困っていること）

AI の試作（PoC）が先に進まずに止まっている場合は、確かめる所が少し違います。「PoC止まりのAIを立て直すには」も参考にしてください。

炎上している開発の立て直しを相談する

想定の例｜受発注のシステムがテストで止まった

ここからは想定の例です。実際のご相談をもとにしたものではなく、よくある形を組み合わせて書いています。

ある会社が、受発注の業務システムの作り替えを開発会社に頼み、予定では半年前にテストを終えているはずでした。テストに入ってから不具合の報告と追加の見積もりが毎月届き、担当者も2度替わり、社内では「作り直した方が早いのでは」という声が出始めています。

この場合、まず追加の要望を止め、最新のソースコードと課題の一覧、議事録を手元に集めます。コードを読んでみると、画面と計算の大部分はできていて、止まっている原因は、旧システムからのデータの移し方が決まらないまま、移したデータでテストをしていたことにある、と分かるかもしれません。そうであれば、作り直すのではなく、データの移し方を先に決め、残りの作業をそこから組み直すのが近道になります。

もちろん、中身を読んだ結果、作りそのものに大きな問題が見つかることもあります。どちらに転ぶかは中身を確かめてみるまで分からないので、作り直すかどうかは、事実を集めてから決めることをおすすめします。

炎上プロジェクトの立て直しでよくある質問

今の開発会社との契約が続いていても相談できますか？

ご相談いただけます。いまの状況と、ご契約がどうなっているかをうかがったうえで、お引き受けできるかどうかをご回答します。契約の終え方など法的な判断が要る所は、弁護士にご相談ください。

立て直しを頼むと、作り直しになりますか？

作り直しを前提にはしません。残っているコードや資料、決まっている仕様を確かめ、活かせるものを活かして進め方を組み直します。

ソースコードが手元に無いときはどうなりますか？

ソースコードが手に入らない立て直しは、お受けしていません。まずは、今の開発会社から最新のソースコードを受け取れるか、契約で納品物に入っているかを確かめてください。

相談に費用はかかりますか？

お引き受けできるかどうかのご回答までは無料です。ソースコードと資料を読む現状の調査は有償で、ご了承をいただいてから実施します。

まとめ｜炎上したら、追加を止めて事実から立て直す

炎上プロジェクトは、人を足したり作り直したりする前に、新しい追加を止めて、残っているコードと資料から事実を集めることで、立て直しの道筋が見えてきます。発注者が事実を手にしていれば、開発会社の説明だけに頼らずに続け方を選べます。

• 「あと少し」が続く、追加の見積もりが届く、不具合が減らない、といったサインが重なったら事実を確かめ始める
• 火消しは、追加を止める → 事実を集める → 残りの作業と原因を分ける → 続け方を比べて決める、の順に進める
• 人を足すだけ、作り直しを急ぐ、責任の追及から始める、の3つは火を広げやすい
• 社内で判断できないときは、外の会社に現状の調査を頼む

デイワンでは、納期に間に合わない、完成が見えない、開発会社と話がかみ合わない、というプロジェクトを途中から引き継ぎ、AI でコードと資料を読み解いて立て直しています。お引き受けできるかどうかのご回答までは無料ですので、事実を集めている途中でも、お気軽にご相談ください。

炎上した開発の立て直しを相談する

---

FAQ 案（microCMS の FAQ の欄に入れる）

1. Q: 炎上プロジェクトとは何ですか？

A: 予定・費用・品質のどれかが大きく崩れ、今のやり方を続けても元に戻らなくなったプロジェクトのことです。納期に間に合わない、完成が見えない、頼んだものと違う、といった形で表に出ます。

2. Q: 炎上とデスマーチは何が違いますか？

A: 炎上はプロジェクトの状態を、デスマーチは無理な日程や人数のまま長い残業で走り続ける進め方を指す俗語です。デスマーチを続けると、炎上はかえって広がりやすくなります。

3. Q: 炎上したプロジェクトの火消しで、発注者が最初にやることは何ですか？

A: 新しい追加と変更をいったん止め、最新のソースコード、資料、課題の一覧、議事録などから事実を集めます。そのうえで、残っている作業と止まった原因を分け、続け方を比べて決めます。

4. Q: 立て直しを外の会社に頼むと、作り直しになりますか？

A: デイワンでは作り直しを前提にしません。残っているコードや資料、決まっている仕様を確かめ、活かせるものを活かして進め方を組み直します。

5. Q: 立て直しの相談に費用はかかりますか？

A: デイワンでは、お引き受けできるかどうかのご回答までは無料です。コードと資料を読む現状の調査は有償で、ご了承をいただいてから実施します。