大企業ですら「爆死」している
IT化、DX化が叫ばれる昨今、システム開発のプロジェクトにおいて大幅な予算超過やスケジュールの遅延を起こしてしまうことを「爆死」と呼ぶことがある。この爆死がいま、多くの企業で起こっている。
楽天では生損保一体型の基幹システムが頓挫し、滋賀銀行は開発を中止してベンダーを変更した。ニトリホールディングスも、事業モデルと整合しないという理由でシステム関連の損失を計上している。2020年以降の5年あまりで、基幹系などのシステム開発を巡り決算で1億円以上の損失を計上した企業は70社を超え、その単純合計額は1200億円をはるかに超える（引用・システム開発で1億円超の損失、5年で70社以上 累計1200億円に 日経クロステック 2026/01/05）。
物流大手のNIPPON EXPRESSホールディングスに至っては、傘下の日本通運が進めていた国際航空貨物基幹システムの開発を断念し、154億円の減損損失を計上した。その後、開発を委託していたベンダーに対して124億円の損害賠償を求めて提訴する事態にまで発展している（引用・日本通運が基幹システムの開発失敗を巡ってアクセンチュアを提訴、124億円の賠償請求 日経クロステック 2024/09/26）。
大企業は資金力があるから、多少の失敗は織り込み済み——そう思うかもしれないが、本当に恐ろしいのは、この「爆死」を引き起こしている構造が、資金力のない中小企業でも全く同じ形で日常的に起きているということだ。中小企業の場合、失敗の一撃が会社の存続そのものを揺るがす。
なぜ、プロが関わっていながら企業規模にかかわらず爆死が起きてしまうのか？ その原因は技術力不足といった表面的なものではなく、根深い構造にある。システム開発が爆死を繰り返す真因と発注者が取るべき3つの対策について、30年にわたり開発現場を見てきたエンジニア、そして業務改善・システム開発を行う経営者の視点から考えてみたい。
gorodenkoff/iStock
「無責任な仕組み」というカラクリ
システム開発が失敗する原因は、技術力不足でも人材不足でもない。要件定義に最後まで責任を持つ主体が存在しないという、なんとも無責任な業界特有の構造にある。
要件定義とは、開発するシステムに求める機能や仕様を文書にまとめる工程のことだ。要件定義を担う会社の多くは、自社に実装部隊を持っていない。つまり要件定義書は、彼らにとって単なる納品物にすぎない。内容が正しかろうと誤っていようと、発注者が「これでいきましょう」と言った瞬間、仕事は完了してしまう。
プロジェクトの工程を川の上流、下流にたとえて要件定義を上流工程と呼んだりするが、これは開発会社にとってリスクなく確実に儲かるビジネスになりやすい。実装の結果がどうなろうと、要件定義の対価はすでに支払われているからだ（図1）。
（図1：プロジェクト開発における責任の切れ目）
たとえば、家を建てる際、設計士が「この図面通りに建てば、あとは工務店の責任です」と言って去っていくようなものだと考えれば、その不自然さが分かるはずだ。
とはいえ、開発会社だけを一方的に責められない。発注する側にも「専門知識がないから、とりあえず全部お任せします」という丸投げ体質がある。分からないなりに質問し、内容を確認する努力を怠れば、どれほど優れた開発会社であっても、認識のズレを埋めきれない。
普通では考えられないような無責任の構造は、発注側の丸投げ体質と、受注側のリスク回避が噛み合って初めて成立しているのだ。
「発注側がもっと勉強すればいいだけではないか」という反論があるかもしれない。だが、経理や法務の専門知識がない経営者が、税理士や弁護士に業務を依頼するのと同じ理屈で考えれば、発注者がシステム開発の専門知識を持てないのは当然のことだ。
問題は知識の有無ではなく、知識がない側が、知識がある側の言うことを鵜呑みにするしかないという力関係そのものにある。この非対称な関係を放置したまま契約を結ぶ限り、無責任の構造はなくならない。
つまり、開発会社と発注者のどちらか一方を責めても意味がない。両者の間にある「責任の切れ目」そのものを、契約の設計段階で埋めておく以外に解決策はないのだ。
紙に出して、また入力する
ある会社で、実際にあった出来事だ。現場の日報をスマホで入力できるようにする、というシステムを導入した。紙で書いていた日報が電子化され、一見すると業務改善が進んだように見える。
ところが事務所での処理を尋ねると、返ってきた答えは「一度プリントアウトしています」だった。現場はスマホで入力する。ところが事務所ではそれを一度紙に印刷し、その紙を見ながら請求書システムへ再入力している。 日報のデータと請求処理のデータが、まったく連携していなかったのだ。
このシステムには数百万円規模の投資が行われている。それにもかかわらず、現場の提出率は確かに上がったものの、会社全体で見れば事務担当者の手間は減るどころか、「印刷して転記する」という新たな工程が増えただけだった。 要件定義の段階で「請求処理まで一気通貫で設計する」という視点が抜け落ちていたことが原因だ。この投資でかかった費用の大半は、事実上失われたと言っていい。
金銭的な損失以上に見過ごせないのが、現場の士気への影響だ。「デジタル化したのに、なぜ紙の作業が増えるのか」という徒労感は、次の改善提案への協力を得にくくする。無駄なシステムは、一度きりの損失では終わらない。
発注の常識を変える
「うちには専門家がいないから、完璧な要件定義なんて無理だ」と感じるかもしれない。その感覚は正しい。だからこそ発注者に求められるのは、要件定義を丸ごと正しく書くことではなく、「誰が最後まで責任を取るのか」を契約前に確認することだ。
要件定義から実装、そして成果まで、一つの主体が一気通貫で責任を負う。成果が出なければ対価を得られない成功報酬型の仕組みは、この責任の所在を強制的に一本化する手段の一つである。
契約を結ぶ前に、発注者が確認すべき視点は次の三つに整理できる。
- 要件定義を作った担当者と、実装を担当する担当者は同一か
- 要件定義の内容に誤りがあった場合、誰がどこまで責任を負うのかが契約書に明記されているか
- 過去の失敗実績を、担当者本人の言葉で具体的に語れるか
これらの問いに即答できない開発会社は、要件定義の段階ですでに「無責任の構造」を抱えている可能性が高い。
システム開発のゴールは、システムを完成させることではない。業務を実際に変えることだ。この「新しい常識」を発注者側が持てるかどうかが、次の「爆死」を防げるかどうかの分かれ目になる。
■
久保田 一 株式会社VERVE代表取締役
エンジニア歴約30年。GMOメディア株式会社で開発部長を務めた後、独立して約20年。成功報酬のみで業務改善・システム開発を行う株式会社VERVEを経営し、中小企業・スタートアップ向けに要件定義から実装・運用まで一気通貫で支援している。2026年6月に「中小企業はなぜDXできないのか？」を出版。
【関連記事】
■「国家資格だから安泰」は幻想。士業の仕事が無くなるこれだけの理由と生き残る条件とは？ （横須賀輝尚 経営コンサルタント）
■AIエージェントの「ひとり事務所」が何十社の顧問業務を回す衝撃。士業の未来はどうなる？ （横須賀輝尚 経営コンサルタント）
■5％賃上げでも生活が楽にならないのはなぜ？給料以外の「もう一つの財布」という視点 （藤村哲也 投資顧問助言業）
■ 110万円の家賃を払う板野友美さんとヤクルト高橋奎二さんの判断が正しい理由。(中嶋よしふみ ファイナンシャルプランナー)
■ 世帯年収1560万円の共働き夫婦は、9540万円の湾岸タワーマンションを買えるのか？ その1・生活費は800万？（中嶋よしふみ ファイナンシャルプランナー）
編集部より：この記事は「シェアーズカフェ・オンライン」2026年7月14日のエントリーより転載させていただきました。オリジナル原稿を読みたい方はシェアーズカフェ・オンラインをご覧ください。
コメント