【野村HDと日本IBMの訴訟事例から考える】なぜITプロジェクトは“信頼関係の崩壊”で終わるのか？──ユーザー企業が見落としがちな3つの落とし穴信頼は壊れるのではない。削られていく。

大手企業同士のシステム開発を巡る訴訟では、「信頼関係の崩壊」を理由とした契約解除の妥当性が争点となりました。ITプロジェクトの現場でも、「信頼が壊れた」という言葉が使われる場面は少なくありません。しかし、信頼は突然失われるものではなく、日々の意思決定や対応の積み重ねによって揺らいでいきます。

本コラムでは、ITプロジェクトが“信頼関係の崩壊”という結末に至る背景を整理し、ユーザー企業が見落としがちな3つの落とし穴を、設計判断の観点から読み解きます。

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

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

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

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

信頼関係は突然壊れない

ITプロジェクトが途中で停止したとき、「信頼関係が崩れた」と説明されることがあります。しかし実際には、信頼は一夜にして消えるものではありません。小さな不一致、説明不足、認識のずれが重なり、気づいたときには修復が難しくなっているのです。

システム開発会社が示したスケジュールに対して、「本当に間に合うのか」と疑念を抱く。進捗報告が曖昧に感じられる。変更要求に対する見積もりが予想より高い。こうした一つ一つは致命的ではありませんが、積み重なると「この会社に任せ続けてよいのか」という疑問に変わります。

重要なのは、信頼は感情の問題ではなく、情報の透明性と合意の積み重ねによって支えられているという点です。つまり、信頼関係の崩壊は設計や運営のあり方と密接に関係しています。

【関連記事】
システム開発の期間の目安は？ 作業工程から短縮方法までわかりやすく解説

落とし穴：変更要求を“その場対応”で済ませる

ITプロジェクトでは変更要求は避けられません。業務の実態が見えてくるにつれて、「やはりこうしたい」「この機能も必要だ」という要望が出るのは自然なことです。

問題は、変更要求を都度の交渉で処理してしまうことです。影響範囲の整理や優先順位の再評価を行わず、その場の合意だけで進めると、全体のバランスが崩れます。結果として工数が膨らみ、スケジュールが遅延し、「最初に聞いていた話と違う」という不満が生まれます。

変更は悪ではありません。しかし、変更を受け止める基準とプロセスが共有されていないと、判断が場当たり的になり、双方に不信感が残ります。信頼を守るには、「何を変え、何を変えないか」を合意する枠組みが必要です。

落とし穴：情報提供の責任を軽視する

ユーザー企業は「発注側」であるがゆえに、情報提供の責任を見落としがちです。しかし、業務の詳細や暗黙のルールを最も理解しているのはユーザー企業側です。

業務フローの説明が十分でないまま設計が進めば、後工程で修正が発生します。担当者の回答が遅れれば、判断が先送りされ、スケジュールに影響します。それでも社内では「システム開発会社の進行管理が悪い」と評価されることがあります。

情報提供は単なる協力ではなく、プロジェクト成功の前提条件です。自社の業務を正確に伝え、判断を迅速に行うことが、信頼を維持するための重要な役割となります。

落とし穴：社内報告の歪みが判断を誤らせる

プロジェクトが難航すると、社内での説明が課題になります。担当者は上司や経営層に進捗を報告しなければなりません。その際、自社側の課題よりも、システム開発会社の問題点を強調してしまうことがあります。

こうした報告が積み重なると、経営層の認識は現場と乖離します。結果として、「信頼関係が崩れた」という結論が先に立ち、冷静な検証が行われないまま契約解除が検討される場合もあります。

報告は事実の共有であり、責任転嫁の手段ではありません。自社側の課題も含めて共有することが、適切な意思決定につながります。

信頼を守るための設計視点

では、どうすれば信頼関係の崩壊を防げるのでしょうか。鍵となるのは、プロジェクトを「伴走型」で設計する視点です。

変更管理の基準を明確にすること。情報提供の役割分担を定義すること。進捗やリスクを可視化し、経営層とも共有すること。こうした取り組みは、単なる管理強化ではありません。互いの立場を理解し、合意を重ねるための土台です。

フルスクラッチ開発では、業務に合わせた柔軟な設計が可能です。その分、対話と合意の重要性は高まります。最初から完璧な仕様を求めるのではなく、変化を前提にした進め方を選ぶことが、信頼を長期的に維持する道となります。

まとめ

ITプロジェクトが“信頼関係の崩壊”で終わる背景には、変更要求の扱い、情報提供の責任、社内報告の歪みという3つの落とし穴があります。いずれも技術の問題ではなく、設計と意思決定の問題です。

システム投資とは、機能を手に入れることではなく、変化に対応し続けるための基盤を整えることです。信頼を守るためには、透明性のある運営と合意の積み重ねが欠かせません。プロジェクトの成否は、技術力だけでなく、こうした設計判断に大きく左右されるのです。

信頼関係は、契約書で守られるものではなく、日々の対話と合意の積み重ねによって育まれるものです。変更要求の扱い方、情報共有の精度、社内外への説明の仕方。これらを丁寧に設計しなければ、どれほど優れた技術を用いても、プロジェクトは不安定になります。

当社フレシット株式会社は、単に仕様通りに開発を進めるのではなく、要件整理の段階から伴走し、判断基準を明確にしながらプロジェクトを進めることを大切にしています。変更が発生することを前提に影響範囲を可視化し、双方が納得できる合意を積み重ねることで、信頼を損なわない進め方を実践しています。

業務に合わせてゼロから設計できるフルスクラッチ開発は自由度が高い分、進め方次第で結果が大きく変わります。だからこそ、開発力だけでなく、合意形成と運営設計まで含めて支援できるパートナーが重要です。

もし、単なる受託開発ではなく、長期的に信頼できる伴走型の開発体制を求めているのであれば、当社フレシット株式会社という選択肢をご検討ください。貴社の事業に真に適合するシステムを、対話を重ねながら共に築いてまいります。

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