書籍① ディベートで学ぶシステム開発委託契約
この電子書籍「ディベートで学ぶシステム開発委託契約」は、システム開発契約の主要トピックについて、ユーザとベンダの仮想ディベートで「解説」したものです。システム開発契約で押さえておくべき重要事項や、ユーザとベンダとの間で生じがちなトラブルを踏まえた契約書での対応について学びたい方に向いています。平成２９年債権法改正に対応済みです。
|
|
英語に Battle of Forms という言葉がある。自己に有利なひな型（Forms）を用意しておいて、それを相手方に呑ませよういう交渉スタイルを揶揄したものである。実際、「交渉力」を背景にだだリスクを押し付け合うだけでは、交渉とは名ばかりである。もちろん、相手方との契約交渉で訳もなく譲歩を強いられたり、気づかないうちにリスクを背負わされたりすることは、何としても避けなければならない。しかし、その逆もまた好ましいことではない。契約交渉は、一面で Battle であるが、ただの Battle ではない。契約によって拓かれる取引の、公平で合理的な「私的ルール」を創り上げるためのものである。
もっとも、何が公平で合理的かということになると、ユーザとベンダの見方は１８０度違ってくる。これは、契約のゼロサム面の現れである以上に、利用者と開発者という「文化」の違いの反映である。少なくとも相手方から見る限り、ユーザは開発者の「文化」に無理解であるし、ベンダは利用者の「文化」に無関心である。互いの「文化」を良く知ることは、ゼロサム関係を超えたパートナーとして、開発を成功させるための土台でもある。相手方からの少々耳の痛い主張には、真摯に耳を傾けなければならない。とても認め難いと思える主張にも、一分の理があるかもしれない。その意味で、むしろ相手方の主張にこそ、多くの「学ぶ」べきことがある。
多段階契約の特徴は、①見積りの精度が向上すること、②履行や責任の単位が小さく区切られること、③開発の途中で契約が終了する可能性のあることである。これらには一定の合理性はあるものの、単純に考えればユーザに不利に働く。（解説）
概算見積りでは１億円だったものが、要件定義を終えたら３億円になっていたりする。もうこの時点で、要件定義にかかった費用を捨て去ってプロジェクトを中止するか、予算を３倍増して続行するかの選択肢しかない。進むのも戻るのも、茨の道である。（ユーザ）
Ｕ：ベンダは、何かあるとすぐ「絞り込み」と言い出す。（ユーザ）
Ｖ：あれもこれもと欲張るのはかえってよくない。開発対象が肥大化すれば、品質リスクは高まるし、保守コストが増大してＴＣＯの観点からも望ましくない。（ベンダ）
ＲＦＰに記載されることによって、契約条件の交渉が早期化、実質化することも期待される。反面、自力でＲＦＰを作成できるユーザは限られているため、選定候補のうちの懇意にしているベンダ（ユーザの担当者が選びたいベンダ）に作成させるなど、意味の乏しい文書になり下がることもある。（解説）
委託料が固定であると、ベンダは上ブレ分を丸々（対価なしに）負担することになる。他方で、再見積りの結果を委託料に反映させても、ユーザは当初計画より「高い買い物」をすることになる（だけである）。これだけを考えれば、上ブレ分はなるべく委託料に反映させる方が公平ということになりそうである。ただ、……（解説）
スケジュール遅れの状態は、請負であれば納期遅延であって、報酬請求どころか契約解除や損害賠償の事由になりかねないのに対し、準委任であれば業務の提供期間が延びるだけの話であって、かえって報酬が増えさえする。端的に言えば、請負はユーザにとって大変に有利であり、準委任はベンダにとって大変に有利である。（解説）
Ｕ：テストの結果、想定外のバグが出たらどうするのか。（ユーザ）
Ｖ：もちろん、検出されたバグは全て潰す。そこまでやって完成である。（ベンダ）
Ｕ：そういうことを聞いているのではない。質・量とも想定外のバグが出て、潜在バグの残存が強く疑われる場合に、顕在化したバグを潰すだけでは不十分なのではないか、ということである。（ユーザ）
「分界点」といっても、その境界には相当の幅があるし、分界点の内側での原因が分界点の外側で問題を発生させる場合や、分界点の内外の原因が競合して問題を発生させることもある。したがって、分界点を明確にしたからといって、直ちに問題が解消するわけではない。いずれにしても、「分界点の内側について責任を持つ」でなく、「分界点の外側については責任を持たない」という思考に陥ると、責任の空白が生じる。（解説）
金銭が現にベンダ側にあることが、交渉力に大きな影響を与える。ベンダは現状維持を図ればよいだけであるが、ユーザは積極的に金銭を取り戻さなければならない。そして、ベンダが交渉に応じない限り、ユーザとしては面倒な訴訟に訴えるしか方策がないからである。（解説）
外部設計の終わりまでに、外部仕様を凍結したのがベースになる。そこから変更しようとするのが仕様変更であり、原則として追加費用となる。当然、一度決めたものをプロジェクトとして変更するかどうか、費用やスケジュールへの影響をどう処理するか、慎重に判断しなければならないから、ここから厳格な変更管理が始まることになる。（ベンダ）
開発スコープを画面や帳票の単位で画定させてもなお、開発スコープを巡って大きなトラブルに陥ることがある。例えば、Ａ取引について登録画面だけが開発スコープに明示されている場合、変更画面や取消画面が開発スコープに入るのかどうは明らかでない。ベンダは開発スコープに明示されていない変更画面や取消画面はスコープ外であると主張し、ユーザはＡ取引の処理がスコープ内である以上、それなしでは業務が回らない変更画面や取消画面は当然にスコープ内であると主張する。（解説）
このような未確定事項があると、確定しない（つまりユーザの要求を反映しない）暫定仕様のまま、内部設計や製造の工程に入ることになるため、後の確定時にベンダ作業に手戻りが生じたり、暫定仕様がユーザに押し付けられたりする。しばしば、多忙から仕様検討を先送りしたいユーザと、作業の先を急ぎたいベンダの「利害」が一致して、大量の未確定事項を生ずることがある。（解説）
「仕様書」はシステム開発委託での「売り物」そのものを規定する。極端な話、「仕様書」と委託料さえ決まっていれば、細かな契約条項がなくても、残りは民商法の原則で埋めて、それなりの契約として通用する。世の中の契約書の議論のほとんどは、ひな形を中心とした原則論であるが、契約実務で本当に重要なのは、原則で埋めることができない「仕様書」なのである。（解説）