ここから本文です

仕様変更にも減額にも応じたのに、契約しないってどういうことですか!:IT訴訟解説

6/13(水) 7:00配信

@IT

 IT訴訟事例を例にとり、システム開発にまつわるトラブルの予防と対策法を解説する本連載、今回は「多段階契約にまつわる紛争」を解説する。

【イメージ画像:一度契約したぐらいで、その後も関係が続くなんて思わないで】

●多段階契約の危険

 ソフトウェア開発では昨今、「多段階契約」が結ばれることが増えてきた。

 ウオーターフォール開発は、システムの要件定義から納入までの作業や成果物を一括で契約すると、途中で要件が変更になったり開発の進捗(しんちょく)が遅れたりした場合、全体の契約を変更しなければならなくなる。その交渉がうまくいかずに、プロジェクトが頓挫してしまうこともよくある。

 そこで登場したのが、多段階契約だ。

 多段階契約はIPAも推奨する、安全度の高い契約方式だ。プロジェクトを「要件定義」「開発」「テスト」などのフェーズに分けて契約するので、変更に柔軟に対応できる。要件定義中に実装する機能が増えたとしても、開発の金額や納期はそこから交渉して契約すればよい。

 アジャイル開発は、そもそもが多段階で作業を実施する仕組みだ。最初から細部まで決めてから作業を始めるのではなく、小さな単位で実装とテストを繰り返すアジャイルでは、システムの最終形を想定して全体の見積もりを行うのが困難なため、契約も第1フェーズ、第2フェーズと分けられる。

 固定金額の範囲内で優先順位の高いものから実装する「定額制」では、多段階の「契約」ではない場合もあるが、「多段階の機能実装」であり、「多段階の作業」であり、「作業の内容や納期を順次決定していく」という点で、多段階契約と同じだ。

 最近、多段階契約が災いして契約トラブルになるケースを散見する。「最初のフェーズを契約、実施した受注者が、その後のフェーズの契約をもらえない」というケースだ。

 一括契約同様、最後のフェーズまで契約できるものと算段していた受注者が、人員を確保し、場合によっては外注先まで頼んで作業の実施に備えていたのに、契約できなければさまざまな損失が出る。小さな企業の場合、資金繰りに困って経営が立ち行かなくなることさえあり得る。

 受注者は「約束が違う」と後方フェーズの契約や損害賠償を求め、発注者は「そもそも契約がないのだから払ういわれはない」と突き返す――こんな紛争が幾つもある。

 多段階契約が増え、それ以上の勢いでアジャイル開発が増えている昨今、受注側にも発注側にも多段階契約の危険性を知ってもらいたいと考え、解説することにした。

●幻の「新フェーズ3」

 事件の概要を見ていこう。

---
東京高等裁判所 平27年5月21日判決から

ある製造業の企業から、Webで製品マニュアルのダウンロードや商品の注文ができるシステムの構築を請け負った元請け企業が、その作業を下請け企業に二次発注した。開発は以下の3フェーズに分割された。

フェーズ1 要件定義、および基本設計
フェーズ2 詳細設計、および開発
フェーズ3 導入、操作指導、および最終確認

元請け企業と下請け企業は、「全体を通しての基本契約」と「フェーズ1についての個別契約」を締結して作業を実施し、作業が無事に完了して支払いもなされた。

両者は、続いて「フェーズ2の個別契約」を結んだが、その後、エンドユーザーである製造業側から追加機能が要望されたため、フェーズ2以降の開発計画を以下のように変更した。

新フェーズ2 (追加の要件定義、追加の基本設計、詳細設計、モックの開発)
新フェーズ3 (詳細設計、および開発)
新フェーズ4 (総合テスト、受け入れテスト、導入支援)

さらに「新フェーズ2の作業の一部を新フェーズ3に移す」ことなどが協議され、それに伴い「フェーズ2の代金が約20%減額」されることになった。元請け企業は下請け企業にその金額を支払った。

ところがその後、元請け企業は下請け企業と「新フェーズ3の個別契約」を締結しなかった。当然に次のフェーズについての契約もなされるものと考えていた下請け企業は混乱した。

特に、「新フェーズ2の減額は新フェーズ3の発注の約束があったからであり、減額をさせながらフェーズ3の契約をしないことは、債務不履行又は不法行為である」として、下請け企業が元請け企業に損害賠償請求を行った。
---

●“予定”は“約束”なのか?

 両者の間には、個別契約の上位に位置する「基本契約」が存在した。

 期限や費用、具体的な成果物は記されていないが、「この開発を一緒に協力してやりましょう」という意味合いの基本契約がある以上、そう簡単に個別契約締結を拒むことはできないと下請け企業が考えるのも無理はない。

 一方の元請け企業は、「新第3フェーズはあくまで『予定』であって、事情によって発注しなくても、法的には何の問題もない」と主張する。基本契約は「最終フェーズまで下請け企業に発注する」という約束ではないし、「最初の段階から全ての工程の発注や金額、コストを確定するようなら、多段階契約の意味がない」という考えだ。

 実際の開発現場を見たわけではないが、訴えの内容を見る限りでは、下請け企業に作業や成果物に関する品質不良があったとは確認できない。

 裏の事情を記すと、下請け企業は、もともとエンドユーザーと一定の信頼関係を築いており、本来は直接発注を受けるところを、事情により元請け企業を間に挟んだという経緯がある。下請け企業からすると、「外されるべきはむしろ元請け企業の方だ」という考えすらあっただろう。

 しかし現実には下請け企業の方が外されてしまった。

●記録はあるのか? 行為はあったのか?

 判決文の続きを見ていこう。裁判所はどのように判断したのだろうか?

---
東京高等裁判所 平27年5月21日判決から(つづき)

そもそも下請け企業と元請け企業との間で締結された本件基本契約においては、本件システム再構築の請負業務は多段階契約方式で行われるものであり、フェーズごとの個別契約の締結をもって、業務の範囲、納期、納入物の明細、代金支払条件などが定まるものとされていたのであるから、本件基本契約の締結によって、本件システム再構築の全工程の個別契約の締結までもが当然に約束されたものではなかったものである。
---

 裁判所は、下請け企業の訴えを全て退けた。

 理由は、「元請け企業が下請け企業に対して次も発注することを約束した『記録』がどこにもなく、また、発注を期待させるような『行為』も一切なかった」ことである。

 以前、本連載で解説した別の事件では、受注者が契約前に作業を勝手に始め、発注者がそれを知りながら「黙認」したことが、事実上の発注と見なされた。しかし今回の事件では、そうした行為はなかった。エンドユーザーの製造業者が元請け企業に対して新第3フェーズで実現したい機能の要望について送ったメールのccに下請け企業が入っていたことが、次フェーズの発注をにおわせるものではあったが、裁判所には受け入れられなかった。

 実は、第一審の東京地裁では、一部ではあるが下請け企業の請求が認められている。それくらいに微妙な問題ではあった。

 しかし今回の判決を見るに、下請け企業側は、基本契約の存在とそれまでの経緯にあぐらをかいて、「次の発注も当然に自分たちにあるはず」などと考えてはいられないことが分かった。

 表面的には、第2フェーズ着手後なるべく早い段階で見積もりを出して交渉を始めること、水面下では、プロジェクト開始前から各フェーズに関する交渉を継続的に実施して、契約の確度を上げること、これらのアクションが必要だったのだ。そうすれば、最悪でも「発注の可能性が低い」という情報を早期に入手し、多大な損害を回避することができたはずだ。

 酷なようだが、そうした活動を怠り、ただただ次の発注を口を開けて待っていたことが、本件の下請け企業の甘いところだった。お行儀よく正論を述べているだけではやっていけないのが、ITベンダーという商売だ。

●細川義洋
政府CIO補佐官。ITプロセスコンサルタント。元・東京地方裁判所民事調停委員・IT専門委員、東京高等裁判所IT専門委員NECソフト(現NECソリューションイノベータ)にて金融機関の勘定系システム開発など多くのITプロジェクトに携わる。その後、日本アイ・ビー・エムにて、システム開発・運用の品質向上を中心に、多くのITベンダーと発注者企業に対するプロセス改善とプロジェクトマネジメントのコンサルティング業務を担当。独立後は、プロセス改善やIT紛争の防止に向けたコンサルティングを行う一方、ITトラブルが法的紛争となった事件の和解調停や裁判の補助を担当する。これまで関わったプロジェクトは70以上。調停委員時代、トラブルを裁判に発展させず解決に導いた確率は9割を超える。システム開発に潜む地雷を知り尽くした「トラブル解決請負人」。2016年より政府CIO補佐官に抜てきされ、政府系機関システムのアドバイザー業務に携わる

最終更新:6/13(水) 7:00
@IT