システム開発を外部に発注したのに、納期が延びる、追加費用を求められる、完成したものが現場で使われない。こうした失敗は珍しい話ではありません。日経コンピュータが2018年に1,745件のプロジェクトを調べた調査では、納期・費用・満足度のすべてを満たして「成功」と言えたのは52.8%でした。残りの約半数は、どこかでつまずいています。

失敗の原因は、開発会社の技術力だけではありません。目的の決め方、見積もりの比べ方、要件の詰め方、仕様変更の扱い方など、発注側の進め方で防げるものが多くあります。本記事では、システム開発の失敗事例を工程別に7つのパターンで整理し、原因と防ぎ方を解説します。裁判になった3件の教訓、失敗の予兆チェックリスト、失敗しかけた案件の立て直し方まで、システム開発会社の立場からまとめました。

想定読者

本記事は、次のような方を想定しています。

• これから業務システムの開発を外部に発注する予定の情報システム部門・DX推進の担当者
• 進行中の開発プロジェクトで、遅れや追加費用が出はじめて不安を感じている方
• 過去にシステム開発で失敗した経験があり、次は同じことを繰り返したくない方
• 開発会社の乗り換えや、プロジェクトの仕切り直しを検討している経営者・事業部門の責任者

---

システム開発の「失敗」とは何か

まず、何をもって失敗とするかを揃えておきます。前述の日経コンピュータの調査は、スケジュール・コスト・満足度の3つを満たしたものを成功と定義しています。裏返すと、失敗には大きく3つの形があります。

頓挫は目立ちますが、件数として多いのは後の2つです。特に「使われない」は、納品の時点では成功に見えるため、問題が表に出るまで時間がかかります。

調査の成功率は、2003年・2008年の31.1%から2018年には52.8%まで上がっています。プロジェクト管理の手法は進歩していますが、それでも約半数は何かを満たせていません。失敗はどの会社にも起こりうるものと考えて、始める前から備えておきます。

---

工程別に見るシステム開発の失敗事例7パターン

システム開発の失敗は、ある日突然起きるわけではありません。多くの場合、上流の工程で生まれた小さなずれが、下流の工程で大きな問題として表に出ます。ここでは、私たちが相談を受ける中でよく見るパターンを、工程の順に7つ紹介します。いずれも、複数の相談に共通する点をまとめた典型例です。

企画：目的があいまいなまま走り出す

「古くなったから作り直したい」「他社も入れているから」という理由だけで始まり、何を良くするためのシステムなのかが決まっていないケースです。目的がないと、要件の優先順位が付けられません。各部署の要望をすべて盛り込んだ結果、規模が膨らみ、誰のためのシステムかわからなくなります。

防ぐには、企画の段階で「受注処理の時間を半分にする」「月末の集計作業をなくす」のように、効果を測れる目的を1〜3個に絞って文書にしておきます。後工程で要望が出たときに、目的に照らして採否を判断できます。

発注・見積：金額だけで開発会社を選ぶ

複数社から見積もりを取り、一番安い会社に決めたところ、開発が進むにつれて「それは見積もりの範囲外です」と追加費用が積み上がるケースです。見積もりの金額は、前提とする作業範囲によって大きく変わります。安い見積もりは、作業範囲が狭いだけということがよくあります。

比べるべきは総額ではなく、内訳です。要件定義・設計・開発・テスト・移行・教育のどこまでが含まれているか、前提条件と除外事項は何か、仕様変更の扱いはどうなっているかを、各社で横並びにして確認します。

要件定義：「言わなくてもわかるはず」が残る

発注側は「当然入っていると思っていた」、開発側は「聞いていない」。完成間際にこのずれが見つかり、作り直しになるケースです。業務の例外処理（返品、分納、締め日の変更など）や、帳票の細かいレイアウトは、口頭のやり取りだけでは抜け落ちやすい部分です。

要件定義は開発会社に任せきりにせず、現場の業務を知っている担当者を必ず参加させます。業務フロー図と画面イメージを開発会社に描いてもらい、現場の担当者がそれを見て「この場合はどうなるか」を一つずつ確認していくと、抜けが減ります。

設計・開発：仕様変更が止まらない

要件定義で決めたはずの内容に、開発が始まってから変更や追加が次々と入るケースです。変更が入るたびに設計と開発の手戻りが発生し、納期と費用が膨らみます。後で紹介する裁判例でも、仕様を確定した後の変更要求の多さが、発注側の責任を重くする理由になっています。

仕様変更は、どのプロジェクトでも必ず起きます。そこで、変更の受け付け方を先に決めておきます。変更は書面で依頼する、影響（費用・納期）を見積もってから採否を決める、今回のリリースに入れるか次期に回すかを判断する、という流れを、契約の時点で開発会社と合意しておきます。

テスト：本番に近いデータで試していない

テストでは問題がなかったのに、本番稼働の初日に処理が止まる、計算結果が合わないといったケースです。原因の多くは、テストで使ったデータが本番と違うことです。件数が少ない、過去の例外的なデータが含まれていない、といった差が、本番で一気に表に出ます。

発注側が受け入れテストの計画に関わり、本番に近い件数と、実際にあった例外データでテストすることが有効です。現場の担当者に、普段の業務の流れどおりに操作してもらう期間も設けます。

移行・リリース：旧システムからのデータ移行を軽く見る

新システムは完成したものの、旧システムのデータを移す段階で、コードの体系が違う、入力ルールが徹底されていなかった、といった問題が見つかり、稼働が延期になるケースです。データ移行は開発の付け足しとして扱われがちですが、実際には独立した一つのプロジェクトとして計画すべき作業です。

移行の対象データ、変換ルール、移行リハーサルの回数、切り替え当日の手順と戻し方を、開発の初期から計画に入れておきます。

運用・保守：作った人しかわからないシステムになる

稼働後しばらくは問題なく動いていたものの、担当していた開発会社の技術者が抜け、設計書も更新されていなかったため、小さな改修にも時間と費用がかかるようになるケースです。こうなると、開発会社を変えたくても引き継げる相手が見つかりません。

納品物として、ソースコード・設計書・運用手順書を受け取ることを契約に明記しておきます。改修のたびに設計書を更新することも、保守契約の範囲に含めておくと安心です。

---

裁判になったシステム開発の失敗事例3件

システム開発の失敗が訴訟に発展した例は、公開されているものだけでも少なくありません。ここでは、発注側にとって教訓の大きい3件を紹介します。

ベンダーにも、発注側にも責任がある

スルガ銀行の事件では、勘定系システムの開発が頓挫し、裁判所はベンダーである日本IBMの責任を認めました。判決で示されたのが、ベンダーは開発を中止すべきかどうかも含めて、発注者に適時適切に説明する義務を負うという考え方です。

一方で、旭川医大と野村HDの2件では、発注側の責任が重く判断されました。どちらも、仕様を固めると合意した後に、発注側から変更や追加の要望が出続けたことが問題視されています。旭川医大の事件では、一審で2割とされた医大の責任が、高裁では全面的なものに変わりました。

3件から読み取れること

3件に共通するのは、システム開発が発注側と開発会社の共同作業だということです。どちらか一方に任せきりでは進みません。開発会社には進行管理と説明の責任があり、発注側には要件を決め、決めたことを守る責任があります。

訴訟まで進む例は多くありませんが、どこで判断を誤ったかを知るには参考になります。特に「仕様を決めた後の変更」は、発注側が自分たちでコントロールできる部分です。

---

失敗の根本原因は4つに集約される

工程別の事例と裁判例を並べると、失敗の原因は大きく4つにまとまります。

1. 目的が共有されていない：何のためのシステムかが決まっておらず、要件の優先順位が付けられない
2. 役割分担があいまい：発注側が決めること、開発会社が決めることの線引きがなく、「任せたつもり」「聞いていない」が起きる
3. 変更の扱い方が決まっていない：仕様変更の手続きがなく、変更が無秩序に入って手戻りが積み上がる
4. 進み具合が見えていない：遅れや課題が報告されず、発注側が気づいたときには手遅れになっている

このうち1〜3は、プロジェクトの開始前に決めておけるものです。4は、定例会議で進捗と課題を見える形で報告してもらう仕組みを作ることで防げます。開発会社を選ぶときも、この4点を一緒に整理してくれるかどうかを確かめると、相性がわかります。

---

進行中のプロジェクトに不安がある、これから発注するにあたって進め方を相談したい、という場合は、c3indexにお気軽にご相談ください。現状のお話を伺い、何から手を付けるべきかを一緒に整理します。

---

失敗の予兆を見つけるチェックリスト

失敗しかけているプロジェクトには、早い段階から兆しが出ます。次の項目のうち3つ以上が当てはまる場合は、一度立ち止まって状況を確認することをおすすめします。

特に7と10は、問題が後ろの工程に先送りされているサインです。テスト期間を削って納期を守っても、本番稼働後にトラブルとして返ってきます。

---

失敗しかけたプロジェクトの立て直し方

予兆に気づいたら、早めに手を打つほど選択肢が残ります。立て直しは、次の順番で進めます。

1. 現状を把握する：完成している機能、残っている作業、未解決の課題、ここまでに支払った費用を一覧にする
2. 原因を特定する：遅れの原因が要件の不足なのか、開発会社の体制なのか、発注側の意思決定の遅さなのかを切り分ける
3. 選択肢を比べる：現在の開発会社と続行する、範囲を絞って最初のリリースを小さくする、いったん止めて計画を作り直す、開発会社を変える、の4つを比べる
4. 決めたことを文書にする：新しいスケジュール、範囲、費用、役割分担を開発会社と書面で合意する

多くの場合、最初に検討すべきは範囲を絞ることです。必須の機能だけで先に稼働させ、残りを次期に回せば、プロジェクト全体が止まる事態は避けられます。

開発会社を変えるのは最後の手段です。途中から別の会社が引き継ぐには、ソースコードと設計書の状態を調べる必要があり、時間も費用もかかります。それでも、現在の会社と信頼関係が保てない、体制が改善されない、という状況なら、早めに判断したほうが損失は小さく済みます。

---

失敗しないための開発会社の選び方

ここまでの内容を踏まえると、開発会社を選ぶときに確かめたいのは、技術力や金額だけではありません。

• 目的から一緒に考えてくれるか：言われたものを作るだけでなく、「それは何のためですか」と聞き返してくれる会社は、企画段階のずれを防いでくれます
• 見積もりの前提と除外事項が明確か：何が含まれ、何が含まれないのかを説明できる会社は、追加費用のトラブルが起きにくくなります
• 仕様変更の手続きを提案してくれるか：変更の受け付け方を契約前に決めようとする会社は、進行管理に慣れています
• 進捗と課題を見える形で報告してくれるか：報告の形式（課題一覧、進捗率、次の判断事項）を事前に確認しておきます
• 納品物にソースコードと設計書が含まれるか：保守を別の会社に頼む可能性も考えて、必ず確認します

初回の打ち合わせで、過去に失敗しかけた案件をどう立て直したかを聞いてみるのも有効です。うまくいった話より、困難にどう対応したかの話から、その会社の進め方が見えてきます。

---

よくある質問

Q. システム開発の失敗は、どの工程で起きることが多いですか？

問題が表に出るのはテストや本番稼働の段階が多いですが、原因の多くは企画と要件定義にあります。目的があいまいなまま進めたり、業務の例外処理を確認しないまま要件を確定したりすると、そのずれが後の工程で手戻りとして表に出ます。

Q. 開発が失敗した場合、費用は返ってきますか？

契約の内容と、失敗の原因がどちらにあるかによります。請負契約で完成義務を果たせなかった場合はベンダー側の責任が問われますが、裁判例のように、発注側の変更要求や協力不足が原因と判断されると、逆に発注側が支払いを命じられることもあります。トラブルになった場合は、議事録や変更依頼の記録が判断材料になるため、日頃から書面で残しておくことが大切です。

Q. 途中で開発会社を変えることはできますか？

可能です。ただし、引き継ぐ会社はソースコードと設計書を調べたうえで、続きを作れるかどうかを判断します。資料が揃っていない場合、作り直しのほうが早いと判断されることもあります。契約の解除条件と、成果物の権利がどちらにあるかを、先に確認しておきましょう。

Q. 失敗を防ぐために、発注側がまずやるべきことは何ですか？

システムの目的を1〜3個に絞って文書にすることと、社内でプロジェクトの責任者と現場の担当者を決めることです。この2つが決まっていれば、要件の優先順位付けも、仕様変更の判断も、発注側が主体的に行えます。

---

まとめ

• 日経コンピュータの2018年の調査では、納期・費用・満足度をすべて満たして成功したシステム開発は52.8%で、約半数がどこかでつまずいている
• 失敗の形は「頓挫」「遅延・予算超過」「使われない」の3つ。件数が多いのは後の2つ
• 工程別には、企画の目的不在、金額だけの発注先選び、要件の抜け、仕様変更の多発、テストデータの不足、データ移行の軽視、保守のブラックボックス化が典型的なパターン
• 裁判例では、ベンダーのプロジェクトマネジメント義務と、発注側の協力義務の両方が問われている
• 失敗しかけたら、現状把握・原因特定・選択肢の比較・書面での合意の順に立て直す。最初に検討すべきは範囲を絞ること

システム開発の失敗の多くは、始める前の準備と、進め方の決めごとで防げます。これから発注する方も、進行中のプロジェクトに不安がある方も、まずは自社の状況をチェックリストで確かめてみてください。

---

システム開発・プロジェクト立て直しのご相談はc3indexへ

c3indexは、名古屋・東京・福岡を拠点に、業務システムの受託開発を手がけるシステム開発会社です。企画と要件定義の段階から、開発、データ移行、稼働後の保守まで一貫してご支援します。他社で進めていたプロジェクトの引き継ぎや、進め方の見直しのご相談もお受けしています。これまでに手がけた開発は、導入事例のページで紹介しています。まずはお気軽にご相談ください。