LASSIC Media らしくメディア
基幹システム刷新が失敗する4つの原因と防ぎ方｜裁判例をもとに解説
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- 基幹システム刷新の失敗は、技術力よりも発注者と開発会社の取り決めと準備から起きることが多いです。
- 公表された判決では、仕様を確定した後も変更の要望が続いた発注者側に支払いが命じられています。
- 現行システムの調査、変更の手順、発注者の作業、契約の形の4つを開発の前に決めておくことが大切です。
※ 本記事は2026年10月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
要件定義がいつまでも終わらない。稼働日が近づくほど、現場から追加の要望が増えていく——。基幹システムの刷新では、こうした行き詰まりが起こりがちです。基幹システムの刷新とは、販売・会計・生産など業務の中心で使うシステムを、新しい仕組みに作り直すことです。
刷新がうまくいかなかった事例の中には、裁判所の判決として公開されているものがあります。判決を読むと、失敗の原因は発注する側の準備や決め方にもあることが分かります。ただし万能の教訓ではなく、判決は個別の事情を前提にしています。本記事では、基幹システムの刷新を任された情報システムの担当者に向けて、公表された裁判例とモデル契約の解説をもとに、失敗の4つの原因、防ぐための進め方、そして外部に頼むときに確認したい点を整理します。
目次
基幹システム刷新の失敗とは
刷新の失敗と言っても、起きることは一つではありません。稼働日に間に合わない段階から、発注者と開発会社が争う段階まで、重さに差があります。
- 稼働の延期：予定の稼働日に間に合わず、古いシステムを使い続ける
- 機能や品質の不足：稼働はしたが、業務で使えない画面や不具合が残る
- 開発の中止：完成の見込みが立たず、途中で開発をやめる
- 紛争：契約の解除や損害賠償をめぐって、発注者と開発会社が争う
紛争まで進んだ事例の一部は、裁判所のWebサイトの裁判例情報で判決の全文が公開されています。経済産業省とIPA（情報処理推進機構）がまとめたモデル契約の見直しでも、システム開発の裁判例では、開発会社のプロジェクトマネジメント義務（計画どおり進むよう管理する義務）と、発注者の協力義務がよく問題になっていると整理しています。*3
公表された2つの裁判例
ここでは、全文を読める高等裁判所の判決を2つ取り上げます。どちらも、いま動いているシステムを新しい仕組みに置き換える開発で、稼働に至らなかった事例です。会社名ではなく、何が起き、裁判所が何を認めたかに絞って比べます。
| 項目 | 病院情報管理システムの事例 | 証券会社の業務システムの事例 |
|---|---|---|
| 判決 | 札幌高等裁判所 平成29年8月31日 | 東京高等裁判所 令和3年4月21日 |
| 作り直したもの | 電子カルテを含む病院情報管理システム | パッケージソフトを使った業務システム |
| 何が起きたか | 納期までに引き渡されず、病院側が契約を解除した | 稼働目標の時期が危ぶまれて開発が中断され、その後に断念した |
| 裁判所が認めたこと | 仕様を確定した後も追加の要望が続き、発注者に協力義務の違反があった | 稼働は契約上の約束ではなく、変更要求の繰り返しで計画が崩れた |
2つの判決はどちらも、開発会社に損害賠償を求めた発注者の請求を認めず、反対に発注者側へ支払いを命じています。*1*2 開発を頼む側も、進め方しだいで責任を問われることを示した判決です。自社の契約にどう当てはまるかは、契約書と専門家の意見で確かめてください。
刷新が失敗する4つの原因
2つの判決とモデル契約の解説を読み合わせると、刷新が行き詰まる原因は次の4つに整理できます。どれも技術力ではなく、取り決めや準備の問題です。
| 原因 | 起きること | 根拠にした資料 |
|---|---|---|
| 1. 現行システムの仕様が分からない | 設計書と実際の動きが食い違ったまま進み、後の工程でトラブルになる | モデル契約の見直しの解説 |
| 2. 仕様の確定後も変更が続く | 作業のやり直しが重なり、計画が崩れる | 2つの判決 |
| 3. 発注者の作業が進まない | データの準備が遅れ、開発会社が代わりに作業する | 病院情報管理システムの判決 |
| 4. 稼働目標と契約の中身がずれる | 誰が完成を約束していたのかで争いになる | 証券会社の業務システムの判決 |
1つ目について、モデル契約の解説は、長く使ってきたシステムでは仕様を知る人が退職や異動でいなくなり、設計書とプログラムが食い違うことが少なくないと指摘し、「現行システム調査を十分に行わずにシステム再構築に着手し、後のシステム開発段階でトラブルに陥った事例が多数報告されている」としています。*3
2つ目と3つ目は、病院の事例がよく表しています。開発会社は625項目の追加の要望を受け入れる代わりに、以後は追加の要望を出さないという仕様凍結（仕様をこれ以上変えない約束）の合意を取り付けました。それでも発注者は、その後に161項目の要望を出し、うち124項目は開発の対象外だったと認定されています。*1 薬品や検査項目などの基本データ（マスタ）を取り出す作業も、発注者が受け持つものでしたが進みませんでした。
4つ目は、証券会社の事例の判決が示した点です。契約書では段階ごとの支援やプログラムの製作を頼んだだけで、完成と稼働の期日は開発会社の債務として合意されていませんでした。判決は「ビジネス上の目標がそのまま契約上の債務として合意されるとは限らない」と述べています。*2
失敗を防ぐ進め方
4つの原因は、どれも開発を始める前の取り決めで手当てできます。要件定義（作るシステムの中身を決める工程）に入る前から、次の4つのステップを順に進めます。
- ステップ1：要件定義の前に現行システムを調べる。設計書とプログラムの食い違いや、知る人がいない機能を洗い出す
- ステップ2：仕様を確定する日と、その後の変更の手順を決める。費用と納期への影響を誰が判断するかも決めておく
- ステップ3：発注者が受け持つ作業と担当者を書き出す。データの準備、受け入れテスト、現場への周知を含める
- ステップ4：契約の形と稼働目標の関係を確かめる。どの段階で何を約束する契約なのかを読み合わせる
ステップ1について、モデル契約の解説は、現行システムの調査には専門の技術とコスト、時間がかかるため、必要に応じて準委任契約（作業を行うこと自体を頼む契約）のコンサルティングとして頼むことを挙げています。*3 ステップ2と3は、病院の判決で、仕様凍結の考え方が現場の医師に浸透していなかったことが紛争の根本的な原因の一つとされた点につながります。*1
モデル契約の見直しの議論では、役割分担の条項や連絡協議会（進み具合を確かめ合う会議体）の定めを適切に運用すれば、義務違反が問題になる事案は一定程度防げるという意見が出ています。*3 刷新の方式の選び方はリホスト・リライト・リビルドの違いで扱っています。
外部に頼むときに確認しておきたい点
基幹システムの刷新を外部に頼むときは、見積もりの金額より先に、失敗の原因になりやすい取り決めを確かめます。提案の段階で次の点を質問し、答えを文書で残しておきます。
- 現行システムの調査：要件定義の前に調査の工程があるか。調べる対象と、結果をどの文書にまとめるか
- 変更の手順：仕様を確定する時期と、その後に変更を受けるときの判断の流れ。費用と納期の見直し方
- 発注者の作業：データの準備やテストなど、自社が受け持つ作業の一覧と期限が提案書に書かれているか
- 契約の形：段階ごとの契約か、一括の契約か。準委任と請負（完成した成果物に対して支払う契約）のどちらで、何を約束するのか
- 進み具合の共有：定例の会議の頻度と出席者。遅れや課題を誰がどの場で判断するか
刷新にかかる費用の考え方はレガシーシステム刷新の費用相場にまとめています。
まとめ：基幹システム刷新で確かめておきたい3つの点
基幹システムの刷新で失敗を避けるうえで、確かめておきたい点は3つです。第一に、要件定義の前に現行システムを調べ、知る人がいない機能を洗い出すこと。第二に、仕様を確定する日とその後の変更の手順を決め、使う部門まで伝えること。第三に、契約がどの段階で何を約束しているのかを、稼働目標と読み合わせておくことです。この3点を踏まえておけば、「稼働日が近づいても要望が止まらず、誰も完成を約束していなかった」という事態を避けやすくなります。進め方や契約の組み立てに迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
刷新を途中でやめる判断は誰がするのですか
最終的に決めるのは、システムを使う発注者です。ただし、やめたときの費用の精算や責任の分け方は契約の定めで変わるため、契約書の解除や中止の条項を確かめ、弁護士などの専門家に相談してください。
仕様を確定した後は、一切の変更ができなくなりますか
できなくなるわけではありません。費用と納期への影響を見積もり、双方が合意してから作業に入る手順を踏むということです。法改正への対応のように避けられない変更もあるため、手順を最初に決めておきます。
現行システムの調査だけを先に頼むことはできますか
できます。モデル契約の解説も、現行システムの調査や再構築の方法の検討を、準委任契約のコンサルティングとして頼む方法を挙げています。*3 調査の結果を見てから開発の範囲と見積もりを固めると、手戻りを減らせます。
基幹システム刷新の進め方のご相談
現行システムの調査から要件定義、データ移行、稼働後の運用まで、元請（プライムベンダー）として基幹システムの刷新をご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：裁判所 裁判例情報「平成28(ネ)189 損害賠償請求控訴事件」札幌高等裁判所 平成29年8月31日判決（https://www.courts.go.jp/hanrei/87065/detail4/index.html）。出典：判決全文（PDF）のうち、仕様凍結の合意と625項目の追加開発、合意後の161項目の要望と開発対象外124項目の認定、マスタの抽出義務、協力義務違反、現場の医師への認識の浸透についての判断を参照（2026年10月確認）
- *2 参考：裁判所 裁判例情報「平成31(ネ)1616 損害賠償，報酬等反訴請求控訴事件」東京高等裁判所 令和3年4月21日判決（https://www.courts.go.jp/hanrei/90584/detail4/index.html）。出典：判決全文（PDF）のうち、段階ごとの個別契約の内容、ビジネス上の目標と契約上の債務の関係、基本設計フェーズ以降の変更要求の繰り返しについての判断を参照（2026年10月確認）
- *3 参考：独立行政法人情報処理推進機構（IPA）・経済産業省「～情報システム・モデル取引・契約書～ 第二版の公表にあたって」（2020年12月22日）（https://www.ipa.go.jp/digital/model/ug65p90000001ljh-att/000087450.pdf）。出典：第3章「プロジェクトマネジメント義務及び協力義務」と第6章「再構築を念頭においた解説の追加」の記述を参照（2026年10月確認）
