システム開発の失敗事例と原因｜発注者側でできる予防策

システム開発の失敗事例を調べると、技術の問題よりも、発注前の準備や発注後の関わり方に原因があるものが目立ちます。この記事では、これから開発を外注する発注担当者に向けて、よくある失敗のパターンとその原因、裁判になった事例から学べる教訓、発注者側でできる予防策をチェックリストの形でまとめます。

システム開発の失敗事例に共通する3つの原因

失敗のパターンは案件ごとに違って見えますが、発注者側から見ると原因はおおむね次の3つに集約できます。

要件が抽象的なまま発注する

「顧客管理を楽にしたい」という目的だけでは、開発会社は何を作ればよいか決められません。誰が、どの画面で、何をできればよいのかが決まっていないと、開発会社は自社の解釈で作るしかありません。要件定義で発注者が決めるべきことは要件定義で発注者がやることで説明しています。

発注者と開発会社の認識がズレる

同じ「承認」という言葉でも、発注者は「上長がボタンを押す」と考え、開発会社は「メールで通知する」と考えている、といったズレはよく起きます。画面のイメージや動く試作品（モック）で早めに確認すると、ズレを小さくできます。

発注したあとに任せきりにする

発注後に打合せへ出なくなったり、質問への回答が遅れたりすると、開発はそこで止まります。丸投げのリスクは丸投げ発注のリスクでも扱っています。

作った後に起きる失敗もある

予定どおり完成しても、事業として失敗することがあります。発注者が見落としやすいのは次のようなケースです。

• 時間をかけすぎて商機を逃す: 企画から要件定義・開発・テストまでに4〜6か月かかり、リリースした頃には状況が変わっている。
• 使われない: 利用者のニーズを捉えていないため、リリースしても利用が増えない。
• 利用者の実態に合わない: たとえば屋外で作業する高齢の利用者に、スマートフォンの通知だけで知らせる設計にしてしまう。
• データが散らばる: 新しいアプリを追加した結果、顧客情報が複数のシステムに分散し、かえって管理が難しくなる。

これらは要件を満たしていても起きる失敗です。システムを作ること自体ではなく、「誰の何が良くなるか」を発注の出発点にする必要があります。

裁判になった事例から学ぶ教訓

失敗が裁判に発展した事例からは、発注者と開発会社それぞれの責任の考え方が見えてきます。ここでは公開情報で確認できる3つの事例を紹介します。

追加要望が止まらず、発注者の責任が問われた例

国立大学の病院情報管理システムの開発をめぐる裁判では、2017年8月31日の札幌高裁判決が注目されました。プロジェクト開始後に現場の医師から追加要望が相次ぎ、仕様を凍結したあとも追加が続いたことで開発が遅れた事案です。第一審は失敗の責任の多くを開発会社側に認めましたが、高裁は発注者側に全面的な責任があるとして逆転させました（ダイヤモンド・オンラインの解説）。

教訓は、発注者にも「協力する義務」があるということです。仕様を凍結したら追加要望を抑えること、開発会社から「このままでは無理だ」と警告されたら一緒に対策を考えることが求められます。

開発会社のプロジェクト管理の責任が問われた例

銀行の勘定系システムの開発が中止になった事案では、2013年9月26日の東京高裁判決が、開発会社の責任を認めて損害賠償を命じました。判決は、開発会社には開発状況を分析し、計画の変更や中止の要否まで発注者に説明する義務があると示しています。一方で、賠償額は第一審から大きく減額され、発注者にも一定のリスク負担を認めました（Westlaw Japan の判例コラム）。

専門家である開発会社には、リスクを説明し、進め方を管理する責任があります。ただし、発注者も任せきりにはできません。開発会社がその役割を果たしているかを、定例会議などで確認することが大切です。

度重なる仕様変更が遅延の原因とされた例

大手証券会社の社内システムの開発が中止になった事案では、第一審で開発会社に賠償が命じられましたが、2021年4月の東京高裁判決はこれを変更し、発注者側の請求を退けました。高裁は、遅延の原因を発注者による度重なる仕様変更の要求と、開発会社からの工程削減の提案に応じなかったことにあると認定しています（ビジネスジャーナルの報道）。

3つの事例に共通するのは、仕様変更の扱いと、警告を受けたときの発注者の対応が判断を分けている点です。契約で責任をどう分けるかは契約不適合責任もあわせて確認してください。

失敗の振り返りで「やっておくべきだった」と挙がる準備

上の事例や受託開発の現場で見られる失敗から、事後に「先にやっておくべきだった」と振り返られることが多い準備をまとめます（特定のアンケート調査の結果ではありません）。

• 目的と、成功したかどうかを測る指標を、発注前に決めておく
• 最初から大きく作らず、試作や小さな検証で需要を確かめる
• 仕様変更のルール（誰が決め、費用と納期をどう見直すか）を契約前に決める
• 決定事項と警告を議事録に残す
• 開発会社が作ったものを、社内で引き継げる形（設計書、ソースコード）で受け取る

受託開発の現場から

うまくいかなかった案件の振り返りから得られた、次のような教訓を紹介します。

• 事業の数字を早くから見る: システムが完成しても、事業として成り立つとは限りません。リリース後の利用状況や成約数などの数字を早い段階から開発会社と一緒に追い、計画とずれたら早めに手を打つことが有効です。開発会社を「作るだけの相手」ではなく、事業の数字まで話せる相手として選ぶことも大切です。
• 「作れる」と「保守できる」は別: ある大企業では、委託先がAIを使って書いた数千行のスクリプトを社内で保守できず、担当者の退任をきっかけに作り直しが必要になりました。AIで速く作れる時代こそ、保守できる形で納品してもらうことが大切です。
• 検証の証跡を残す: ある開発会社では、開発メンバーが手元の環境での確認だけで済ませ、テストの証跡を残していなかったことを反省し、レビューと納品の手順を明文化しました。発注者も「テストしました」という言葉ではなく、証跡を確認することをおすすめします。
• いきなり大きく作らない: 受託開発の商談では、試作、検証、小さな本番、拡大と、検証の結果に合わせて段階的に投資する進め方がよく提案されます。失敗の規模を小さく抑えるためです。

発注者が使えるチェックリスト

最後に、発注前と発注後に確認したい項目をまとめます。

まとめ

• 失敗の主な原因は、抽象的な要件、認識のズレ、発注後の放置です。
• 完成しても使われない、商機を逃すといった事業面の失敗もあります。
• 裁判例では、仕様変更の扱いと警告への対応が責任の判断を分けています。
• 目的と指標を先に決め、小さく作って確かめ、記録を残すことが予防策になります。

本記事は一般的な情報提供を目的としたもので、個別の契約や法的判断については弁護士などの専門家にご相談ください。

失敗を防ぐ第一歩は、発注前に案件の中身を整理することです。FastProposal の無料AI相談なら、目的や必要な機能を整理し、費用の目安を数分で確認できます。