Skip to content
Tiatra, LLCTiatra, LLC
Tiatra, LLC
Information Technology Solutions for Washington, DC Government Agencies
  • Home
  • About Us
  • Services
    • IT Engineering and Support
    • Software Development
    • Information Assurance and Testing
    • Project and Program Management
  • Clients & Partners
  • Careers
  • News
  • Contact
 
  • Home
  • About Us
  • Services
    • IT Engineering and Support
    • Software Development
    • Information Assurance and Testing
    • Project and Program Management
  • Clients & Partners
  • Careers
  • News
  • Contact

判例から読み解く巨大ITプロジェクトの分割契約で注意すべき点

本稿は、Z会対日立ソリューションズ事件と、野村HD対日本IBM事件という、対照的な結論に至った二つの判例を取り上げます。分割された契約群のどこまでを“一つの運命共同体”として解除できるのか、そして「責任限定条項」という名の防波堤が、その結論をいかに左右するのか。裁判所が描く緻密な判断の地図を、実務の羅針盤として読み解いていきましょう。結論を先に示せば、司法は「密接関連性」という事実の網の目をもって解除の範囲を慎重に選別し、当事者が契約を分けた意思を尊重しながら、解除も損害も個別に判断していくのです。

二つの巨大プロジェクト、二つの異なる運命

現代のシステム開発紛争を象徴する二つの事件があります。一つはZ会事件、もう一つは野村vsIBM事件。どちらも巨大プロジェクトを複数の契約に分割して進めるという、今日ではごく当たり前の手法が採られました。しかし、プロジェクトが暗礁に乗り上げたとき、その運命は契約のあり方によって大きく分かれたのです。

Z会事件の舞台は、通信教育大手の基幹システム刷新プロジェクトでした。計38本の個別契約で進められ、2017年1月11日に本番稼働を迎えたものの、その二日後の1月13日に深刻なシステム障害が発生し、事業に甚大な打撃を与えました。この事態を受け、Z会はベンダである日立ソリューションズを提訴。東京地裁(2022年2月24日判決)はベンダの責任を広く認め、既払契約代金の返還(原状回復)として約11億円及び遅延損害金の支払を命じました。続く東京高裁(2022年10月5日判決)もこの判断を支持し、判決は確定しました。この事件では、プロジェクトの中核における失敗が、密接に関連する契約群にまで影響を及ぼすことが示されました。

一方、野村HD・野村證券と日本IBMが17本の個別契約で進めた大規模プロジェクトに対しては、全く異なる判決となります。プロジェクトの頓挫をめぐる訴訟で、東京地裁(2019年3月20日判決)は最終段階の3契約に限りIBMの不履行を認め、約16.2億円の支払いを命じました。しかし、その後の東京高裁(2021年4月21日判決)で地裁判決は覆され、野村側の本訴請求は全部棄却。逆にIBMの反訴請求が約1.12億円認容されるという逆転判決が下されたのです。この高裁判決は、2021年12月に野村側が上告を取り下げたことで確定しています。

なぜ、これほどまでに結論が分かれたのか。その謎を解く鍵は、裁判所が用いた「密接関連性」という物差しと、契約書に仕組まれた「責任限定」、そして「全体の完成義務」の有無という名の防衛線にあります。

解除の網はどこまで広がるか?——Z会事件が示した「密接関連性」という物差し

Z会事件の論点の一つは、「一つの契約の失敗が、どこまでの契約の命運を絶つのか?」という点にありました。この論点に対し、裁判所は「すべて連帯責任」か「個別の責任」かという単純な二元論では答えませんでした。Z会事件で裁判所は“密接関連性”を基準に、総合試験や最終修正など“完成に直結する工程”に密接な契約について解除・原状回復の射程を広めに認めました。一方、周辺的・独立価値のある契約は一律には巻き込まないという“選別的”アプローチを採っているのです。

この物差しの基準は、極めてシンプルです。解除の原因となった契約と、他の契約は、目的や内容においてどれほど強く結びついているかー裁判所は38本の契約群を一つの塊として見るのではなく、一つひとつの契約がプロジェクトという大きな物語の中でどのような役割を担っていたかを、丁寧に読み解いていきました。

例えば、プロジェクトの初期段階である要件定義や、本体システムとは独立して機能するサブシステムの移行に関する契約は、それ単体でも一定の価値があり、本体の完成と必ずしも運命を共にするわけではないと評価されました。そのため、本体開発の契約が失敗したからといって、これらの契約まで自動的に解除することは認められませんでした。

しかし、システムの品質を最終的に担保する「総合試験」や、そこで見つかった不具合を修正する作業など、システムの完成に不可欠なクライマックスを担う契約群には、全く異なる判断が下されました。裁判所は、これらの工程を「実質的にシステムを完成させるための契約」と位置づけ、開発本体の契約とは切っても切れない運命共同体であると認定。したがって、本体契約が解除されるならば、この最終工程に関する契約もまた、その運命を共にすべきだと判断したのです。

このアプローチは、当事者がなぜ契約を分けたのか、その意思を深く尊重する姿勢の表れです。Z会事件は、分割された契約群の中からプロジェクトの「核」となる部分を見出し、そこを選択的に解除の網にかけるという判断モデルを私たちに示しています。

契約という名の防波堤——野村vsIBMが教える「分割契約×責任限定」の防御術

Z会事件が「事実上の結びつき」を重視したのに対し、野村vsIBM事件は「契約上の設計」がいかに強力な防波堤となり得るかを教えてくれます。この事件では、ユーザーが期待したであろう「システムが完成しなかった」という事態に対する包括的な責任追及が、契約書の構造そのものによって、最終的に阻まれました。

まず地裁段階では、各個別契約ごとの責任限定条項の適用が認められ、裁判所が算定した損害額約19.1億円が、「個別契約13〜15に対応する代金・代金相当額の合計」を上限として、認容額約16.2億円へと圧縮されました。この時点では、責任限定条項が有効に機能したと言えます。

しかし、高裁はIBMの契約上の完成義務自体を否定して野村側請求を棄却したため、そもそも賠償責任が発生せず、責任限定条項の射程に実質的に踏み込む必要がありませんでした。高裁の判断の核心は、「個々の契約は、それぞれの段階的な目的を達成するためのものであり、プロジェクト全体の最終的な成功までを法的に約束したものではない」という点にあります。ユーザー側から見れば、17本の契約はすべて、一つの壮大なシステムを完成させるための部品だったかもしれません。しかし、高裁は契約書の文言を厳格に解釈し、そこに「全体の完成義務」までは書かれていないと判断したのです。

この高裁の判断は、極めて実践的な教訓を示しています。プロジェクトを段階ごとに分割し、その都度の対価と責任を個別の契約単位で「個別完結」させる設計は、紛争時にリスクの延焼を防ぐ強力な防火壁となり得ます。野村事件は、そもそも「全体の完成義務」という概念を契約設計の段階で法的に発生させないことで、責任追及の根幹を揺るがすことに成功したのです。これは、契約設計がいかに強力なリスク管理ツールであるかを示す、見事な事例と言えるでしょう。

矛を研ぐユーザー、盾を固めるベンダ——実務に活かす二つの教訓

二つの事件が描く裁判所の見取り図は、今や明らかです。それは、「事実」の積み重ねと「条項」の設計という二つの軸で成り立っています。この地図を手にすれば、ユーザーは解除という鋭い「矛」を研ぎ、ベンダは責任限定という堅い「盾」を固めることができます。

まず、ユーザーが「全体解除」という矛を手にしたい場合、焦点を当てるべきは事実の側面です。Z会事件が示すように、プロジェクトの中核、すなわち「これがなければシステムは完成しない」と言える工程は何かを見極め、その重要性を客観的な証拠で固めていく必要があります。総合試験や最終的な欠陥修正といった工程が、まさにその「核」にあたります。これらの工程がプロジェクト全体の運命を握っていることを、議事録、課題管理票、テスト計画書といった日々の記録を通じて立証していくのです。この事実の積み重ねが、「密接関連性」を強め、解除の網を広げる力となります。

条項面では、基本契約の段階で布石を打つことが不可欠です。第一に、プロジェクト全体の最終目的を明確にうたうこと。第二に、各個別契約がその全体目的を達成するために相互に依存している関係にあることを条文で宣言すること。そして第三に、一つの契約で重大な不履行があれば、関連する他の契約も解除できるという「クロスデフォルト条項」を設けることです。

一方で、ベンダがリスクの防波堤という「盾」を固めたいのであれば、野村vsIBM事件の高裁判決に倣い、条項の設計に全力を注ぐべきです。戦略の核は、各契約の「個別完結性」を徹底し、「全体の完成義務」を負わないことを明確にすることです。契約ごとに明確な成果物、独立した検収手続き、そして個別の支払条件を定め、一つの契約が終われば、その範囲では完全に責任関係が清算される構造を作り上げます。そして、その盾を補強するのが、責任限定条項です。これにより、万が一責任が認められた場合でも、損害を限定することができます。

転ばぬ先の杖——解除後の「後始末のルール」を設計する

契約解除の議論で、見落とされがちながら極めて重要なのが、解除が認められた“後”の世界、すなわち「原状回復」のルールです。壊れた契約関係をどう清算し、後始末をするのか。このルールを事前に設計しておくことは、まさに転ばぬ先の杖となります。

Z会事件でも、支払った代金の返還を求める原状回復請求は、大きな争点となりました。分割契約では、この後始末がさらに複雑になります。すでに検収・支払いが終わった多数の契約について、どこまで遡って代金を返還させるのか。納品済みのソースコードやライセンスの扱いはどうするのか。この設計を怠れば、紛争は出口のない迷路に迷い込みます。

ユーザーとしては、プロジェクト全体の目的が達成されなかった場合には、たとえ一部の工程で検収を済ませていたとしても、それらを含めて代金返還や成果物の使用停止が認められるよう、クロスデフォルト条項と連動した設計を目指すべきです。

逆にベンダは、リスクを限定するため、後始末の範囲を明確に区切る必要があります。検収が完了した部分については、法的に「完成した部分」として原状回復の対象外となることを明記します。また、ハードウェアや第三者のライセンスなど、物理的に返還が不可能なものについては、あらかじめ例外として定めておくべきです。どちらの立場であっても、これらのルールを支えるのは日々の運用記録であり、客観的なドキュメントが最終的な判断の拠り所となるのです。

結論:“分けたなら、繋ぎ方も決めよ”——分割契約時代の鉄則

プロジェクトを分割して契約することは、複雑な航海を安全に進めるための優れた航海術です。しかし、いざ嵐に見舞われたとき、その船がバラバラになるか、一つの船として乗り切れるかの運命を分けるのは、「分割された部品をどう結合させるか」という、あらかじめ定められた“結合ルール”に他なりません。

Z会事件は、契約書という形式を超えて、プロジェクトの「実質」を見抜き、「密接関連性」という網目で解除の範囲を選別する司法の姿勢を示しています。一方、野村vsIBM事件は、緻密な契約設計がいかに強力な防波堤となり、リスクの連鎖、ひいては責任追及そのものを断ち切るかを教えてくれます。

分けて契約するのならば、それらがどう繋がり、どう切れるのか、そのルールも同じだけの熱意をもって設計する。これこそが、多段階契約が当たり前となった現代において、巨大プロジェクトを成功に導き、万一の紛争を乗り切るための、唯一にして最短の設計思想と言えるでしょう。


Read More from This Article: 判例から読み解く巨大ITプロジェクトの分割契約で注意すべき点
Source: News

Category: NewsSeptember 22, 2025
Tags: art

Post navigation

PreviousPrevious post:Oracle appoints two CEOs, but the power still rests with Larry EllisonNextNext post:Supply chain chaos in 2025: How geopolitics are rewriting the rules

Related posts

Work-from-office mandate? Expect top talent turnover, culture rot
January 22, 2026
How learning enterprises compete
January 22, 2026
How to get your enterprise architecture ready for agentic AI
January 22, 2026
Rethinking IT leadership to unlock the agility of ‘teamship’
January 22, 2026
La agenda del CIO en 2026: de la exploración a la responsabilidad
January 22, 2026
GreenlandMX acelera su transformación digital para asegurar la escalabilidad del comercio electrónico
January 22, 2026
Recent Posts
  • Work-from-office mandate? Expect top talent turnover, culture rot
  • How to get your enterprise architecture ready for agentic AI
  • How learning enterprises compete
  • Rethinking IT leadership to unlock the agility of ‘teamship’
  • La agenda del CIO en 2026: de la exploración a la responsabilidad
Recent Comments
    Archives
    • January 2026
    • December 2025
    • November 2025
    • October 2025
    • September 2025
    • August 2025
    • July 2025
    • June 2025
    • May 2025
    • April 2025
    • March 2025
    • February 2025
    • January 2025
    • December 2024
    • November 2024
    • October 2024
    • September 2024
    • August 2024
    • July 2024
    • June 2024
    • May 2024
    • April 2024
    • March 2024
    • February 2024
    • January 2024
    • December 2023
    • November 2023
    • October 2023
    • September 2023
    • August 2023
    • July 2023
    • June 2023
    • May 2023
    • April 2023
    • March 2023
    • February 2023
    • January 2023
    • December 2022
    • November 2022
    • October 2022
    • September 2022
    • August 2022
    • July 2022
    • June 2022
    • May 2022
    • April 2022
    • March 2022
    • February 2022
    • January 2022
    • December 2021
    • November 2021
    • October 2021
    • September 2021
    • August 2021
    • July 2021
    • June 2021
    • May 2021
    • April 2021
    • March 2021
    • February 2021
    • January 2021
    • December 2020
    • November 2020
    • October 2020
    • September 2020
    • August 2020
    • July 2020
    • June 2020
    • May 2020
    • April 2020
    • January 2020
    • December 2019
    • November 2019
    • October 2019
    • September 2019
    • August 2019
    • July 2019
    • June 2019
    • May 2019
    • April 2019
    • March 2019
    • February 2019
    • January 2019
    • December 2018
    • November 2018
    • October 2018
    • September 2018
    • August 2018
    • July 2018
    • June 2018
    • May 2018
    • April 2018
    • March 2018
    • February 2018
    • January 2018
    • December 2017
    • November 2017
    • October 2017
    • September 2017
    • August 2017
    • July 2017
    • June 2017
    • May 2017
    • April 2017
    • March 2017
    • February 2017
    • January 2017
    Categories
    • News
    Meta
    • Log in
    • Entries feed
    • Comments feed
    • WordPress.org
    Tiatra LLC.

    Tiatra, LLC, based in the Washington, DC metropolitan area, proudly serves federal government agencies, organizations that work with the government and other commercial businesses and organizations. Tiatra specializes in a broad range of information technology (IT) development and management services incorporating solid engineering, attention to client needs, and meeting or exceeding any security parameters required. Our small yet innovative company is structured with a full complement of the necessary technical experts, working with hands-on management, to provide a high level of service and competitive pricing for your systems and engineering requirements.

    Find us on:

    FacebookTwitterLinkedin

    Submitclear

    Tiatra, LLC
    Copyright 2016. All rights reserved.