注文者（発注者）敗訴の現実｜契約事例から学ぶべき使用者責任と協力義務の落とし穴

システム開発が頓挫した際、責任はすべてベンダー（開発会社）にあると思っていませんか？実は、発注者側の「協力不足」が原因で敗訴する事例がいくつも発生しています。

10億円規模のプロジェクトがなぜ崩壊し、裁判所はなぜ発注者の非を認めたのか。実例を元にしたストーリーから学ぶ「注文者が果たすべき義務」と成功への分岐点を解説します。

IT構築工事で事業者が押さえるべき知識と相談のポイント

—— 発注者は、なぜ敗訴したのか ——

ある雨の日、ハルヤとアリサは、社内でも屈指の経験を持つCTO のオフィスに呼ばれていた。 窓の外ではしとしとと雨が降り、部屋には重い空気が漂っている。

二人の前に、厚い紙束が置かれた。

「これが、現実の発注者が経験したことなんだ。」

そう言ってCTO は、判決文の一番上を指差した。そこには大きく**「発注者敗訴」**の文字が印字されていた。

ハルヤ：「……え？ システムが間に合わなかったんですよね？ なんで発注者が負けるんですか？」

アリサ：「ベンダーの責任じゃないんですか？ 普通そう思いますけど」

CTO は静かにうなずき、深くため息をついた。

「君たちの反応は自然だ。でも、この判決には発注者側の“見落とし”がすべて詰まっている。」

10億円プロジェクトの崩壊｜目的の食い違いと要件定義の失敗

CTO が語り始めたのは、10 億円規模のシステム統合プロジェクトの顛末だった。

 複数の事業所でバラバラに稼働していたシステムを一本化し、保守費用を削減しようとした——はずだった。

しかし、出発点から方向が食い違っていた。

情報システム部門は「システムを統一してその維持費を削減する」ことを目的にしていたが、業務部門は「業務は大きく変わらずに便利になる」と誤解していた。

このすれ違いは要件定義で深刻化する。 ベンダー任せで業務部門の意見を聞かずに進めた結果、現場実態を知らないまま設計が進行。画面設計が出た途端、現場の反発が爆発した。

「こんなの業務にならない！」 

「こんなフローじゃ仕事できません！」

現場不在の代償｜現行業務の棚卸し不足

必要不可欠だった現行Excelツールすら要件に含まれていなかった。

現行Excelツールの棚卸しもなく、ベンダーは「そもそも何を作ればいいのか分からない」と嘆く始末だった。

やがて、発注者は納期遅れや品質不安を理由に、ベンダーとの契約を解除した。その後、システムは完成せず、発注者は**「プロジェクトが頓挫したことで多額の損害を被った」**として、ベンダーに損害賠償を求めて訴訟を起こした。

裁判所の判断｜認められなかったベンダーの責任

しかし判決は発注者に不利だった。裁判所は**「発注者側の協力不足と情報提供義務違反がプロジェクト失敗の主要因である」**と認定し、ベンダーの責任を否定したのである。

ハルヤとアリサは絶句した。

 「発注者が……自分で自分の首を絞めることがあるんですね……」

CTO は頷き、厚いファイルを二人に手渡した。

「だから、“任せる”だけではなく、“関わる”ことが必要なんだ。君たちには、発注者の真の力を身につけてもらう」