要件定義も設計もしてもらいましたが、他社に発注します。もちろんお金は払いません!:「訴えてやる!」の前に読む IT訴訟 徹底解説(24)(3/3 ページ)
東京高等裁判所 IT専門委員として数々のIT訴訟に携わってきた細川義洋氏が、IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回も正式契約なしに着手した開発の支払いをめぐる裁判を紹介する。ユーザーの要請でエンジニアを常駐して設計まで進めた開発案件、「他社に発注することにした」はアリ? ナシ?
ユーザー企業にも非はあるが……
東京地方裁判所 平成20年7月29日判決より抜粋して要約(続き)
ユーザー企業はベンダーに「短期間でシステムを完成させたい」と告げ、ベンダーはエンジニアを常駐させた。また、ユーザー企業は、納期を守るために要件定義作業と並行して設計業務を進めるよう、強く要請している。さらにユーザー企業の担当者は、他社と接触していたことを秘匿し、入札の段階に至っても形式的なものにすぎないと説明していた。
これらの事実に照らすと、ベンダーが本件システムの委託契約締結に強い期待を抱いていたことは相当の理由がある。
正式な契約書がなくても、「作業を要請」され、しかも「他社への接触を隠されていた」のでは、事実上の発注があったと考えてよい、との判断だ。
裁判所の言葉をそのまま借りれば、ユーザー企業の「契約準備段階における信義則上の注意義務違反」というわけだ。ベンダーの心情を考えると、妥当な判断だろう。
しかし裁判所は、ユーザー企業の非のみを一方的に認めたわけではなかった。
ベンダーが要求したのは「3800万円」だったが、判決でユーザー企業に命じられた支払い額は「1350万円」だった。開発総額「1億2000万円」の約9分の1だ。ベンダーが要件定義〜基本設計〜詳細設計の一部までを行い、成果物をまとめて提出していることを考えると、かなり少ない。結局、ベンダーは大きな損失を出したことになる。
正式契約がない場合は「文書化」と「複数ルートの確認」を
このような不幸を防ぐために、ベンダーはどのようなことをしておくべきだったのだろうか。
まずは、合意事項を書面に残すことだ。
正式な契約書がなくても、仮の注文書でも、議事録でも、とにかく「双方の合意内容」と「未決事項」が分かる文書を作って、取り交わすことが必要だ。もしも、これらの作成をユーザー企業が拒むようなら、その時点でプロジェクトは中断すべきだ。
文書に記述する際は、未決事項とその決定時期を書くことが必要だ。
「○○機能を対象とするかは未確定。これについてはXX月末までに、ユーザー企業が判断して通知し、ベンダーはそれに基づくプロジェクト計画と見積もり書を別途提出する」などと決めておく。正式な契約を結べない「原因」を、その「決定時期」「責任者」「決定方針」と共に書き、その結果によって計画と見積もりが変わり得ることを書いておくのだ。
ベンダーが作業着手をする際の「前提事項」を書くことも大切だ。
「仮にベンダーに発注することになっても、そこまでの成果物に対する対価は、成果物の権利をユーザー企業に移譲した上で支払う」と書いてあれば、本件のようなもめ事にはならなかっただろう。
文書化と同様に大切なのは、ユーザー企業の発注意思の確認だ。
多額の費用が発生する発注意思確認が、ユーザー企業担当者からの口約束やメールだけではいかにも心もとない。発注しない可能性もあると知りながら、発注の意思があるように話すユーザー企業担当者もいれば、誤認や勘違いの可能性もある。
そのためにも、契約意思の確認は、複数ルートでするべきだ。
ベンダーのプロジェクトマネジャーとユーザー企業担当者間、ベンダーの営業担当者とユーザー企業の発注担当者、双方の経営層(あるいはトップ同士)など、複数のルートでユーザー企業の発注意思を確認し、その理解に齟齬(そご)や相違点がないことを確認することが必要だ。
IT紛争の例を見ると、これらが原因でトラブルに陥る例が実に多い。担当者間ではスケジュールと金額に合意したはずなのに、営業が確認してみるとユーザー企業内でまだ承認されていない、あるいは経営層がまったく知らないといったことは珍しくない。
当然ながら、そうしたプロジェクトは多くの場合、契約から検収までのどこかで問題が明らかになり、混乱が発生する。
ITプロジェクトは、ユーザー企業の経営層から担当者まで、そしてベンダーの全メンバーが、同じ目的の下、作業内容や期間などについて合意した状態で着手しなければうまくいかない。
裁判に勝つことも大切だが、裁判以前に「健全なプロジェクト運営のため」にこそ、「確認」と「文書化」が必要なのだ。
細川義洋
東京地方裁判所 民事調停委員(IT事件担当) 兼 IT専門委員 東京高等裁判所 IT専門委員
NECソフトで金融業向け情報システムおよびネットワークシステムの開発・運用に従事した後、日本アイ・ビー・エムでシステム開発・運用の品質向上を中心に、多くのITベンダーおよびITユーザー企業に対するプロセス改善コンサルティング業務を行う。
2007年、世界的にも希少な存在であり、日本国内にも数十名しかいない、IT事件担当の民事調停委員に推薦され着任。現在に至るまで数多くのIT紛争事件の解決に寄与する。
書籍紹介
プロジェクトの失敗はだれのせい? 紛争解決特別法務室“トッポ―"中林麻衣の事件簿
細川義洋著 技術評論社 1814円(税込み)
紛争の処理を担う特別法務部、通称「トッポ―」の部員である中林麻衣が数多くの問題に当たる中で目の当たりにするプロジェクト失敗の本質、そして成功の極意とは?
「IT専門調停委員」が教える モメないプロジェクト管理77の鉄則
細川義洋著 日本実業出版社 2160円(税込み)
提案見積り、要件定義、契約、プロジェクト体制、プロジェクト計画と管理、各種開発方式から保守に至るまで、PMが悩み、かつトラブルになりやすい77のトピックを厳選し、現実的なアドバイスを贈る。
細川義洋著 日本実業出版社 2160円(税込み)
約7割が失敗するといわれるコンピューターシステムの開発プロジェクト。その最悪の結末であるIT訴訟の事例を参考に、ベンダーvsユーザーのトラブル解決策を、IT案件専門の美人弁護士「塔子」が伝授する。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- PMBOK流:業務委託先の選び方
外部に委託する作業が決まったら、委託先の業者を決定するための準備に移ります。このプロセスの主要なアウトプットは、「調達文書」と「評価基準」です - 「契約もアジャイルに」、中堅SIerの新たな挑戦
アジャイルは開発スタイルの実践を指すが、これを受託開発の契約形態に当てはめようという企業が登場して注目を集めている - 締結5日前にユーザーが白紙撤回! 契約は成立? 不成立?
ユーザー窓口が確約した「○月○日に正式契約しましょう」を信じて一部作業に事前に着手したベンダーは、突然の契約白紙撤回に泣き寝入りするしかないのか? - システム化範囲がぶれていれば失敗する
プロジェクトの失敗で、一番多いのはシステム化範囲(スコープ)がいつのまにか大きく膨らんでしまい、納期も遅れ、コストも膨らんでしまうケースである - IT業界の下請け構造を知る
皆さんが下請けという言葉に悪いイメージを持っていることは認識していますが、下請けがすべてダメなわけではありません
関連リンク
- ITトレメ ビジネス著作権検定 本試験問題
- 美人弁護士 有栖川塔子のIT事件簿 バックナンバー一覧
要件定義が固まっていない、途中で追加や変更が頻発して大混乱――開発プロジェクトで起こりがちなトラブル事例の対応法を、IT訴訟専門の美人弁護士「塔子」がビシビシと伝授します。