連載
要件定義も設計もしてもらいましたが、他社に発注します。もちろんお金は払いません!:「訴えてやる!」の前に読む IT訴訟 徹底解説(24)(1/3 ページ)
東京高等裁判所 IT専門委員として数々のIT訴訟に携わってきた細川義洋氏が、IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回も正式契約なしに着手した開発の支払いをめぐる裁判を紹介する。ユーザーの要請でエンジニアを常駐して設計まで進めた開発案件、「他社に発注することにした」はアリ? ナシ?
IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。前回は、ユーザーとベンダーの間で、見積もり合意も正式な契約もないまま作業を開始したプロジェクトが中断した判例を取り上げた。
今回も、ベンダーが正式な契約書のないまま作業した例を紹介する。同じような事例で恐縮だが、それだけこういった紛争が多いということだ。
見切り発車で開発に着手しても、最終的にユーザーから発注をしてもらえれば問題はない。しかし、ベンダーが作業着手していることを知りながら(あるいは容認しながら)、ユーザーが別のベンダーに発注してしまう事例もある。
自社に発注があるものと信じて、人を投入し、時間もお金も掛けて作業をしてきたベンダーからすれば「ユーザーの裏切り」とも思える行為だが、ユーザーは「正式な契約を結んでいないのだから、自分たちに責任はない」と開き直る。
こういう場合、ベンダーは泣き寝入りするしかないのだろうか?
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- PMBOK流:業務委託先の選び方
外部に委託する作業が決まったら、委託先の業者を決定するための準備に移ります。このプロセスの主要なアウトプットは、「調達文書」と「評価基準」です - 「契約もアジャイルに」、中堅SIerの新たな挑戦
アジャイルは開発スタイルの実践を指すが、これを受託開発の契約形態に当てはめようという企業が登場して注目を集めている - 締結5日前にユーザーが白紙撤回! 契約は成立? 不成立?
ユーザー窓口が確約した「○月○日に正式契約しましょう」を信じて一部作業に事前に着手したベンダーは、突然の契約白紙撤回に泣き寝入りするしかないのか? - システム化範囲がぶれていれば失敗する
プロジェクトの失敗で、一番多いのはシステム化範囲(スコープ)がいつのまにか大きく膨らんでしまい、納期も遅れ、コストも膨らんでしまうケースである - IT業界の下請け構造を知る
皆さんが下請けという言葉に悪いイメージを持っていることは認識していますが、下請けがすべてダメなわけではありません