採用通知＝正式契約、ですよね？：「訴えてやる！」の前に読む IT訴訟徹底解説（23）（3/3 ページ）

» 2016年01月18日 05時00分公開

[ITプロセスコンサルタント細川義洋，＠IT]

前のページへ 1|2|3 　　　　　　

ユーザーに都合のよい解釈をさせない

　もう一つこの判決から学ぶべきは「提案書の書き方」だ。

　本件の提案書には、財務会計システムの導入は記載されているが、それと密接に関連する税務システムについては、何も記述されていない。

　人によっては、「財務会計」と「税務」は不可分と捉えるかもしれない。地方自治体の場合、特に記述がなくても、税務は財務会計の一部分であり、当然に提案書に含まれる」とする人もいる。本件のユーザーも、同様に考えていた可能性はないだろうか。

　ユーザーは税務システムにはある程度のカスタマイズが必要であるとは理解していたが、その費用は財務会計システムについての提案に含まれていると考えていた節がある。

　ところがベンダーは、提案内容に税務システムを含んだつもりはなく、カスタマイズ費用を別途見積もり、その総額は新規開発に近いものになった。この認識の差が、ユーザーの追加見積もり不同意と、その後の紛争の原因となった。

　提案書作成時は、ユーザーに提案内容の拡大解釈をさせないように、「具体的」かつ「厳密」で「客観性のある」記述が必要だ。

　ユーザーが「当然、提案に含まれるだろう」と考える危険のあるサブシステムや機能は、別扱いとする書き方が必要だ。業務の全体像を示して赤線で囲んだり、提供する機能の一覧を明示したり、開発しないものは「開発しない」と明確に記したりできるはずだ。

契約時のポイント

　ベンダーの落ち度をさらに挙げれば、ほぼ内容の確定していた財務会計システムと、取り扱いが漠然としている税務システムを一つの契約で対応しようとしたことだ。

　システム全体として金額を記さない基本契約を結び、財務会計システムの分だけ個別契約を結び、税務システムについては別の契約として交渉をする。こうせずに、単純に全てのシステムを一括で行ってしまったために、本来なら問題なく作業を続けていた財務会計システムまで、費用請求できなくなった。

　決まった部分は個別契約を結び、不確定な部分は別途交渉する。

　言葉で言うと簡単だが、実際には複雑な事情が絡まり合って、なかなか難しいことではある。それでも、本件のような争いを避けるためには、こうした段取りを踏むことが安全だ。

　大切なのは「曖昧さを排除」することだ。数多くの人間がさまざまに発言し、形のないソフトウェアやシステムについて検討する中で、客観性を維持しながら、誰もが納得する線を引くのは、簡単なことではない。しかしそうしないと、費用の支払いを受けられない危険にベンダーは晒され続けるだろう。

提案書で防げるトラブルも多い。具体的、かつ厳密で客観性のある記述を心掛けよう（画像はイメージです）

「「訴えてやる！」の前に読む IT訴訟徹底解説」バックナンバー

細川義洋

東京地方裁判所民事調停委員（IT事件担当）兼 IT専門委員　東京高等裁判所 IT専門委員

NECソフトで金融業向け情報システムおよびネットワークシステムの開発・運用に従事した後、日本アイ・ビー・エムでシステム開発・運用の品質向上を中心に、多くのITベンダーおよびITユーザー企業に対するプロセス改善コンサルティング業務を行う。

2007年、世界的にも季少な存在であり、日本国内にも数十名しかいない、IT事件担当の民事調停委員に推薦され着任。現在に至るまで数多くのIT紛争事件の解決に寄与する。

ITmedia オルタナティブブログ「IT紛争のあれこれ」

美人弁護士有栖川塔子のIT事件簿

書籍紹介

「IT専門調停委員」が教えるモメないプロジェクト管理77の鉄則

細川義洋著　日本実業出版社　2160円（税込み）

提案見積り、要件定義、契約、プロジェクト体制、プロジェクト計画と管理、各種開発方式から保守に至るまで、PMが悩み、かつトラブルになりやすい77のトピックを厳選し、現実的なアドバイスを贈る。

なぜ、システム開発は必ずモメるのか？

細川義洋著　日本実業出版社　2160円（税込み）

約7割が失敗するといわれるコンピューターシステムの開発プロジェクト。その最悪の結末であるIT訴訟の事例を参考に、ベンダーvsユーザーのトラブル解決策を、IT案件専門の美人弁護士「塔子」が伝授する。

見積もりに合意してないから、要件追加分のお金は払いません！
京高等裁判所 IT専門委員として数々のIT訴訟に携わってきた細川義洋氏が、IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回は「見積もりの返事を待たずに着手した追加部分」の支払いをユーザーに拒否されたベンダーの裁判例を紹介する。裁判所の判断はいかに？
デフォルトの契約内容は、失敗への招待状
皮肉なことに、プロジェクトと失敗とは相性がよい。納期どおりにできなかった、要求どおりにできないことが多い、機能を削減することが多いなど、もともとの目的、スコープから、後退したプロジェクトの経験を持つITエンジニアは多いに違いない。なぜ目的どおりにいかないのか。どこを改善したらいいかを本連載で明らかにし、処方せんを示していきたい
要件やシステム化の範囲はどうやって決めるのか？
システム化の範囲を定義するときに、業務の目的を実現するための「方針」に着目すると、合目的性の高いシステム作りができます
「契約もアジャイルに」、中堅SIerの新たな挑戦
アジャイルは開発スタイルの実践を指すが、これを受託開発の契約形態に当てはめようという企業が登場して注目を集めている
「契約不履行」と訴えられぬようにベンダーがすべきこと
要件も作業内容も適宜確認し、ユーザーの指示を受けて作業していたのに、納品間近になって「契約を果たしていないから支払いはなしね」と告げられたベンダー。裁判所の判決や如何に？
締結5日前にユーザーが白紙撤回！契約は成立？不成立？
ユーザー窓口が確約した「○月○日に正式契約しましょう」を信じて一部作業に事前に着手したベンダーは、突然の契約白紙撤回に泣き寝入りするしかないのか？
ベンダーが確実に支払いを受けるための3つのポイント
検収書だけでは不十分？――ユーザーから確実に支払いを得るために、ベンダーがやるべきこととは何だろう？