仕様変更にも減額にも応じたのに、契約しないってどういうことですか!:「訴えてやる!」の前に読む IT訴訟 徹底解説(56)(1/3 ページ)
多段階契約にしたがために後方フェーズの契約を取れなかった下請け企業がブチ切れた! 契約内容は都度検討するけれど、契約自体は一気通貫ですよね――IT訴訟事例を例にとり、システム開発にまつわるトラブルの予防と対策法を解説する人気連載。今回は「多段階契約における基本契約の効力」を考える。
IT訴訟事例を例にとり、システム開発にまつわるトラブルの予防と対策法を解説する本連載、今回は「多段階契約にまつわる紛争」を解説する。
多段階契約の危険
ソフトウェア開発では昨今、「多段階契約」が結ばれることが増えてきた。
ウオーターフォール開発は、システムの要件定義から納入までの作業や成果物を一括で契約すると、途中で要件が変更になったり開発の進捗(しんちょく)が遅れたりした場合、全体の契約を変更しなければならなくなる。その交渉がうまくいかずに、プロジェクトが頓挫してしまうこともよくある。
そこで登場したのが、多段階契約だ。
多段階契約はIPAも推奨する、安全度の高い契約方式だ。プロジェクトを「要件定義」「開発」「テスト」などのフェーズに分けて契約するので、変更に柔軟に対応できる。要件定義中に実装する機能が増えたとしても、開発の金額や納期はそこから交渉して契約すればよい。
アジャイル開発は、そもそもが多段階で作業を実施する仕組みだ。最初から細部まで決めてから作業を始めるのではなく、小さな単位で実装とテストを繰り返すアジャイルでは、システムの最終形を想定して全体の見積もりを行うのが困難なため、契約も第1フェーズ、第2フェーズと分けられる。
固定金額の範囲内で優先順位の高いものから実装する「定額制」では、多段階の「契約」ではない場合もあるが、「多段階の機能実装」であり、「多段階の作業」であり、「作業の内容や納期を順次決定していく」という点で、多段階契約と同じだ。
最近、多段階契約が災いして契約トラブルになるケースを散見する。「最初のフェーズを契約、実施した受注者が、その後のフェーズの契約をもらえない」というケースだ。
一括契約同様、最後のフェーズまで契約できるものと算段していた受注者が、人員を確保し、場合によっては外注先まで頼んで作業の実施に備えていたのに、契約できなければさまざまな損失が出る。小さな企業の場合、資金繰りに困って経営が立ち行かなくなることさえあり得る。
受注者は「約束が違う」と後方フェーズの契約や損害賠償を求め、発注者は「そもそも契約がないのだから払ういわれはない」と突き返す――こんな紛争が幾つもある。
多段階契約が増え、それ以上の勢いでアジャイル開発が増えている昨今、受注側にも発注側にも多段階契約の危険性を知ってもらいたいと考え、解説することにした。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- 要件定義も設計もしてもらいましたが、他社に発注します。もちろんお金は払いません!
東京高等裁判所 IT専門委員として数々のIT訴訟に携わってきた細川義洋氏が、IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回も正式契約なしに着手した開発の支払いをめぐる裁判を紹介する。ユーザーの要請でエンジニアを常駐して設計まで進めた開発案件、「他社に発注することにした」はアリ? ナシ? - 契約もしていないし働いてもいませんが、お金は払ってください。売り上げ期待していたんですから
東京高等裁判所 IT専門委員の細川義洋氏が、IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回は多段階契約の落とし穴を解説する - 納期が遅れているので契約解除します。既払い金も返してください
東京高等裁判所 IT専門委員の細川義洋氏が、IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回は頓挫した開発プロジェクトの既払い金をめぐる裁判例を解説する - このシステム、使えないんでお金返してください
今回も多段階契約に関連する裁判例を解説する。中断したプロジェクトの既払い金を、ベンダーは返却しなければならないのか?