基本設計書は納品前ですが、システム作っちゃいました：「訴えてやる！」の前に読む IT訴訟徹底解説（95）（3/3 ページ）

基本設計がFIXしない状態のまま完成したシステム。基本契約と個別契約、どこまでが支払い対象と認められるのか――？

[ITプロセスコンサルタント細川義洋，＠IT] PC用表示関連情報

LINE

Hatena

前のページへ | 　　　　　　

個別契約を結ぶときの注意

　これを踏まえるなら、ITベンダーはなるべく作業を分割して契約する方が、トラブルを起こしたときにも安全ということになるし、実際そうした目的でこうした契約形態をとる場合も多い。

　ただし、分割契約にはそれなりの条件がある。「契約ごと（工程ごと）の納品物を明示的に定義し、その約束は守る」ことだ。例えば、詳細設計の成果物を単に「詳細設計書」と書くのではなく、その「文書名や内容をできる限り書く」ことだ。

　無論、作業中それらに「変更がある場合には、両者が合意して変更できることも契約条項に書き加えておく」ことも大切だ。とにかく「やった／やらない」を第三者でも判別できるような契約と、それに基づく作業計画、成果物定義が必要である。

　もう1つのポイントは、「次フェーズへの申し送り事項」だ。システム開発では、どうしてもある工程で約束したことを次の工程に回さなければならないことがある。そうした際、ベンダーは勝手に作業内容を後回しにするのではなく、「計画変更として作業を組み立て直し、それを顧客と合意」する。そうしたことも「契約書に記し、プロジェクト内では『変更管理』として実施」すべきだ。

　ここをきちんとやらないで勝手に作業内容を変えていては、それこそドミノ倒しのように、どの契約も債務不履行となってしまう。これはぜひ、注意していただきたいところだ。

　本裁判は結局、全体でもITベンダーの勝利に終わった。正直なところをいえば、判決文を見る限り、ITベンダーの作業品質はかなり低く、下手をすればシステムの未完成と判じられて全く逆のことになっていたかもしれない。

　そうならなかったのは、個別契約ごとの進捗と完成度合のリスクにITベンダー側が対応し、個別契約のことはその契約内でとにかくカタを着けようと一生懸命だったようだ。最終的に納期を守れればいいという考えではなく、一つ一つの契約に真摯（しんし）に向き合っていたことが、結果としてこの裁判の勝利にもつながったと私は考える。

細川義洋

ITプロセスコンサルタント。元・政府CIO補佐官、東京地方裁判所民事調停委員・IT専門委員、東京高等裁判所IT専門委員

NECソフト（現NECソリューションイノベータ）にて金融機関の勘定系システム開発など多くのITプロジェクトに携わる。その後、日本アイ・ビー・エムにて、システム開発・運用の品質向上を中心に、多くのITベンダーと発注者企業に対するプロセス改善とプロジェクトマネジメントのコンサルティング業務を担当。

独立後は、プロセス改善やIT紛争の防止に向けたコンサルティングを行う一方、ITトラブルが法的紛争となった事件の和解調停や裁判の補助を担当する。これまでかかわったプロジェクトは70以上。調停委員時代、トラブルを裁判に発展させず解決に導いた確率は9割を超える。システム開発に潜む地雷を知り尽くした「トラブル解決請負人」。

2016年より政府CIO補佐官に抜てきされ、政府系機関システムのアドバイザー業務に携わった

個人サイト：ITプロセス改善と紛争解決