【野村HDと日本IBMの訴訟事例に学ぶ】変更要求はなぜ炎上を生むのか？フルスクラッチ開発で失敗しないための合意設計とは

大手金融グループとシステム開発会社の間で争われた訴訟では、度重なる変更要求がプロジェクトの混乱を招いた一因と認定されました。ITプロジェクトの現場では、「変更要求（CR）」が日常的に発生します。しかし、それが適切に扱われないと、要件定義の遅延、工数の膨張、責任の押し付け合いへと発展し、最終的には炎上や契約解除に至ることもあります。

本コラムでは、「変更＝悪」という単純な図式ではなく、「変更をどう管理するか」という設計思想の観点から、フルスクラッチ開発で失敗しないための考え方を整理します。

＞＞フルスクラッチ（オーダーメイド）のシステム開発について詳細はこちら

【記事要約】野村HD対日本IBM訴訟に学ぶ、ITプロジェクトにおけるユーザー責任と信頼関係の限界

野村HDがIBMに発注したシステム更改は、度重なる変更要求や情報提供の遅れなどにより混乱し、最終的に契約解除と損害賠償訴訟へ発展した。裁判所は、問題の原因は双方にあるとしつつも、変更要求の反復などユーザー側により大きな責任があると判断し、「信頼関係の崩壊」は認めなかった。判決は、社内事情から一方的にベンダーを悪者扱いする姿勢を否定し、状況の可視化と早期共有の重要性を示唆している。ITプロジェクトでは、責任の所在を冷静に見極め、相互の信頼を維持する姿勢が不可欠である。

出典：細川義洋「『ユーザー側の態度』が破綻したITプロジェクトの予後を左右する──“野村HD vs 日本IBM”裁判の教訓」2026年1月29日付

変更要求が炎上を招く本当の理由

システム開発において変更要求は避けられません。要件定義の段階で想定しきれなかった業務パターンが見つかることもあれば、市場環境や経営判断の変化によって仕様の見直しが必要になることもあります。

問題は変更そのものではありません。炎上を招くのは、変更が「無制限」「無記録」「無合意」のまま積み重なることです。

変更要求が正式な合意プロセスを経ずに進行すると、次のような事態が起こります。

・下流工程での手戻りが増加する
・テスト工程で不整合が発覚する
・工数が膨張し予算が圧迫される
・責任の所在が曖昧になる

結果として、システム開発会社は「管理能力不足」と指摘され、ユーザー企業側は「期待通りに進んでいない」と不満を抱きます。こうした認識のズレが拡大すると、信頼関係の悪化につながります。

要件定義と変更要求の関係

変更要求の多発は、要件定義の精度と深く関係しています。

要件定義は単なる機能一覧の作成ではありません。本来は、業務の流れを分解し、例外ケースや将来の拡張性まで見据えて整理する工程です。しかし、スケジュールや予算の制約から十分な議論が行われないまま開発に進むケースも少なくありません。

その結果、基本設計や詳細設計の段階で「やはりこうしたい」「この業務も追加したい」といった変更要求が発生します。

ここで重要なのは、変更が発生することを前提に設計しているかどうかです。変更を想定していないプロジェクトでは、追加対応のたびに調整が必要になり、関係者の負担が急増します。一方、変更を前提とした合意設計がなされていれば、影響範囲の分析、工数見積もり、スケジュール調整が冷静に行えます。

【関連記事】
要件定義が失敗する原因は？6つの失敗事例から学ぶ対策を解説

変更要求がエスカレートするメカニズム

炎上案件では、変更要求が連鎖的に増加する傾向があります。

たとえば、ある機能の追加によりデータ項目が増えると、それに伴う帳票修正や連携機能の調整が必要になります。さらに、関連部門から別の要望が出ると、仕様は当初の想定から大きく離れていきます。

この過程で問題となるのが「影響範囲の見える化」が十分でないことです。変更の影響が明確に共有されないまま実装が進むと、後工程で想定外の修正が発生し、プロジェクトは混乱します。変更要求を単発のタスクとして扱うのではなく、全体への影響を分析し、関係者全員で合意することが不可欠です。

合意設計という考え方

フルスクラッチ開発において重要なのは、「変更をどう処理するか」まで含めて設計することです。
具体的には、以下のような仕組みが求められます。

・変更要求の受付方法を明確にする
・影響範囲と工数を可視化する
・スケジュールと費用への影響を説明する
・書面やツールで正式に合意する

このプロセスが整っていれば、変更はリスクではなく、品質向上のための改善活動として機能します。逆に、合意が曖昧なまま進行すると、「言った・言わない」の議論が発生し、信頼関係が損なわれます。

フルスクラッチ開発における優位性

パッケージ製品に業務を合わせる場合、変更の自由度は限定的です。しかし、業務が独自性を持つ企業にとっては、仕様の調整が不可避です。

フルスクラッチ開発では、業務特性に合わせた柔軟な設計が可能です。ただし、柔軟であるがゆえに、変更管理のルールが曖昧だと混乱しやすくなります。

そのため、初期段階で「どこまでを基本要件とするか」「変更の判断基準は何か」を定義しておくことが重要です。変更を拒否するのではなく、合理的に判断するための基準を共有することが、炎上防止につながります。

経営層と担当者の役割

変更要求の背景には、社内事情も影響します。

現場担当者は、自部門の要望を優先しがちです。一方で、経営層は全体最適を重視します。こうした視点の違いが調整されないまま開発が進むと、後から大きな変更が発生します。

経営層がプロジェクトの進捗やリスクを定期的に把握し、変更の妥当性を判断する体制を整えることが、炎上回避には不可欠です。変更を抑制するのではなく、合理的に選別する意思決定が求められます。

変更を前提としたプロジェクト運営

システム開発は計画通りに進むことのほうが少ないものです。重要なのは、変更が発生したときに慌てない体制を整えているかどうかです。

変更管理を明文化し、プロジェクト管理ツールで共有し、影響を可視化する。この基本を徹底することで、変更は炎上の火種ではなく、改善の機会になります。変更要求を敵視するのではなく、設計で受け止める姿勢が求められます。

まとめ

変更要求が炎上を招くのは、変更そのものではなく、合意なき変更の積み重ねです。要件定義の精度向上、影響範囲の可視化、正式な合意プロセスの整備が、プロジェクトの安定運営には欠かせません。

フルスクラッチ開発では柔軟性が高い分、変更管理の設計がより重要になります。変更を前提にした合意設計を行い、責任の所在と判断基準を明確にすることが、炎上を防ぎ、長期的な信頼関係を築く鍵となります。

変更要求は、適切に扱えばプロジェクトをより良い方向へ導く材料になります。しかし、その前提となるのは「変更を前提にした設計」と「合意を積み重ねる運営体制」です。ここが曖昧なままでは、どれほど優れた技術を用いても、炎上リスクを根本から防ぐことはできません。

当社フレシット株式会社では、単に機能を実装するのではなく、要件整理の段階から「将来起こり得る変更」まで見据えた進め方を重視しています。業務の本質を丁寧に分解し、影響範囲を可視化し、判断基準を共有しながら進行することで、変更を混乱ではなく進化の機会へと転換していきます。

また、フルスクラッチ開発だからこそ可能な柔軟性を活かしつつ、変更管理のルールや合意プロセスを明確に設計することで、責任の所在や判断の根拠を曖昧にしません。結果として、プロジェクトの途中で想定外の要望が生じた場合でも、冷静に影響を整理し、最適な選択を行える体制を築くことができます。

「変更が怖い」のではなく、「変更を扱えないこと」が怖い。もしそのような課題意識をお持ちでしたら、一度、当社フレシット株式会社のフルスクラッチ開発という選択肢をご検討ください。貴社の業務特性や成長戦略に合わせ、長期的に機能し続けるシステムを、対話を重ねながら共に形にしてまいります。

＞＞フルスクラッチ（オーダーメイド）のシステム開発について詳細はこちら