「契約不履行」と訴えられぬようにベンダーがすべきこと：「訴えてやる！」の前に読む IT訴訟徹底解説（6）（2/2 ページ）

要件も作業内容も適宜確認し、ユーザーの指示を受けて作業していたのに、納品間近になって「契約を果たしていないから支払いはなしね」と告げられたベンダー。裁判所の判決や如何に？

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

LINE

Hatena

前のページへ | 　　　　　　

　私は、一概にそうとも言えないと考えている。ベンダーにはベンダーで、やるべきことがあったはずだ。

　復習になるがもう一度。本件の契約書は、詳細な作業や役割分担を「別途定める」としている。そして、ユーザーとベンダーは作業実施中の必要時点において、それらを都度都度決めていった。見積もり金額も、それに応じて決められていったことだろう。

　しかし、そのようにして散文的に決められる事柄が、当初の契約に照らして必要十分であることを誰がどのようにして保証するのであろうか。

　「都度都度」とは、言って見れば場当たり的な議題提起である。その場にいた人間が思いつかなければ、プロジェクト推進に関わる重要事項を決め損ねたまま進むことになりかねない。

　通信回線の暗号化が必要なシステムを作る場合を例に考えてみよう。契約書や見積書に「セキュリティ対策については別途」とだけ記されていれば、ユーザー認証についてだけ決めて安心してしまうような話はよくある。運よく決めるべきことを全て想起できたとしても、その検討が五月雨式に時間を置いて決められていたら、決定事項同士に矛盾や不整合が生じる場合もある。

　文章にすると稚拙なミスに思う読者もいるかもしれないが、実際こうした問題は数多くのプロジェクトで発生している。読者とて、そして私とて人ごとではない。

未決事項管理と確認の重要性

　よく管理されたITプロジェクトでは、こうしたことに対応するため、「未決事項確認書」を作って管理する。契約時点で「詳細は別途」とした項目を、できる限り具体的に未決事項として書き出しておく。1つ書けば、連想してあれもこれもと頭に浮かぶが、それらも全て書き出す。

　そして、一通り出きったところで、まず「書き出した未決事項が全て解決すれば、プロジェクトが確実に成功するか」をベンダーとユーザーのメンバーをできる限り集めて検証する（必要メンバーを全て集めるのは、なかなかに困難だが、ことは契約に直結する。相当な無理をしてでも集まってもらうべきである）。

　検証する際には、単に必要十分であるかだけでなく、「未決事項同士の依存関係」も明らかにする。「これが決まらなければ、これも決まらない」といったことを明確にするのだ。「データベース管理システムの選定が終わらないと、担当メンバーのアサインができない」といった具合に。

　矛盾する未決事項やトレードオフのものがあれば、それも明らかにしておく。「もし、本稼働時期が来年の春だとすれば、この実施可否を検討しているこの機能の実装はできない」といったようにだ。

　そして、おのおのの未決事項について「決定者」「検討メンバー」「検討時期」「決定方針」を決めて文書化して管理する。未決事項が必要な時期までに解決されなければ、「リスク・課題」となり、より優先度の高い問題とする。

　今回取り上げた紛争プロジェクトでは、こうしたことが行われず、場当たり的な作業を行ったがために、「望んだ作業をベンダーが行わなかった」とユーザーは判断した。結果はともかく、このことが、ユーザーが支払いを拒否し、裁判の控訴までした不満の真因である。

担当者こそ契約書を確認すべき

　私も技術者時代そうであったので、他人のことをとやかく言える立場ではないが、一般にベンダーの技術者やユーザーのシステム担当者は、あまり契約書を見ないし、関心も薄い。契約書は大抵、どちらかの会社で用意したひな形をベンダーの営業担当がアレンジして作成し、ユーザーの購買担当に渡される。検証は双方の法務部門が行うことが多いので、契約書に基づいて作業を行う担当者は、内容を理解していない場合も多い。

　しかし、今回のように「詳細は別途」とだけ書いてある契約書を見て、「これは何のことだろう」「いつまでに決めるのだろう」と疑問を抱くのは、大抵ベンダーの技術者とユーザーの担当者である。そして、その疑問に網羅的に答えていくことが、実は、プロジェクト成功のカギになる。自分のやることを正式に定義している契約書（別紙も含む）をよく吟味する。ベンダーの技術者とユーザーの担当者には、ぜひそんな癖を付けてほしい。

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