誰しもが紛争が生じることを望んでいないでしょう。
それなのにそのための準備なんて、という気持ちもわからないわけではありません。
しかし、絶対に紛争が生じないとはいえません。また、ソフトウェア開発に関する紛争は、一般に想像されるより多く生じているのではないか、と思うほどには生じているといえます。
紛争リスクがある以上、これに対する備えは必要です。
リスクマネジメントは、法的リスクに対しても必要とされるのです。
「契約が成立した」とは、「契約当事者間である法的効果を生じさせる旨の合意がなされた」ことをいいます。
契約書によって契約が成立することもあれば、契約書がなくとも契約が成立することもあります。すなわち、口頭でのやりとりでも、契約は成立しうることになります。
しかし、契約が成立したことと、契約が成立したことを立証することは、まったく別の話になります。
いくら契約が成立したと主張しても、それに対応する証拠がないのでは、なかなか裁判では契約の成立は認められません。
当事者の主張(尋問結果)も証拠となりますが、どうしても書面等の客観証拠と比べ、その証拠力は弱くなってしまうことは否めません(記憶は徐々に不正確になっていくこと等がその理由です。)。
契約書の何が重要なのかというと、契約書は契約締結の単なる証拠の1つであるだけでなく、契約締結の証明に強い影響を及ぼす証拠であるという点が重要なのです。
もっとも強い影響を及ぼす証拠であるといっても過言ではないともいえます。
どういうことかというと、契約書は、当事者がその書面によってある契約を締結したことを証する客観証拠ですから、それ自体で直接契約があったことの立証に用いることができます。また、類型的に信用性が高いとされていることから、その証拠力も非常に強いものとされています。
もっとも、押印済契約書がなくとも、他の証拠で契約成立を立証できる可能性もありますし、反対に、契約書があったとしても、必ずしも契約成立が認められるわけではありません。
とはいえ、企業間取引においては、委託料が少額でない場合や規模が小さくない場合の契約で契約書の取り交わしを行わないことは通常考えにくいという意味で、契約書の有無は、契約の成否に直接影響を及ぼす可能性が高いといえます。
契約書が重要であることは上述のとおりであり、実作業着手前に契約書を取り交わすことが望ましいといえます。
しかし、契約書作成に先行して実作業に着手することも少なくないでしょう。
契約成立が認められず、結果的に無償となっても構わないというベンダの経営判断に基づく着手であればよいですが、そうでなければ、契約書作成前に実作業に着手することには、ベンダにとって大きなリスクが伴います。
他方、ユーザにとっても、契約が成立していないためにベンダに対して責任追及をすることができないという、大きなリスクを抱えることにもなりかねません。
そこで、あくまでも契約書の取り交わしを速やかに行うとの前提で、契約不成立のリスクを低めるための措置を講じるべきであると考えられます。
例えば、契約要素となると考えられる、ベンダが行う作業の内容やユーザがこれに支払う対価につき、両者の間で書面による確定的な合意をひとまずしておくことが考えられます。
この合意がなされていれば、契約の成立を否定される可能性は低くなるものと考えられます。
最初に着手する作業が要件定義であれば、「ユーザは、ベンダに対し、報酬月額○○万円で○○に関する要件定義作成支援業務を委託し、ベンダはこれを受託する。」といった程度でもよいでしょう。
ちなみに、仮にこのような合意をしたとしても、契約締結時に契約によって合意を遡及的になかったこととし、締結した契約のみを有効とすることも十分可能です。
そのような合意までには至らないとしても、前記契約要素やその他の条件に関して書面(メール等も含みます。)でやりとりを行い、また、合意できたと考えた条件についても、自らの認識と相手方との認識がずれていないことの確認を書面ですべきです。
書面に残さなければ客観証拠が残らず、紛争になった際に水掛け論になってしまい、結果としてそのことが自らの不利益となる可能性もあります。
相手方とのやりとりは、書面でやりとりを行い、将来の紛争に備えた証拠化を心がけることが重要です。
ユーザは、ベンダから提示された見積を前提に、ベンダを選定し、契約を締結することとなります。
しかし、この見積は、当該時点での予測にすぎないことがほとんどで、法的拘束力を有しない場合が多いと考えられます。システムの本番稼働開始時期についても、これと同様のことがいえます。
そのこともあって、当初の見積や本番稼働開始時期が、開発工程が進むにつれてなされた再見積によって増額又は延期されるのもよくあるケースであり、当初の見積等とのズレが、紛争につながることも多々あるところです。
開発にかかる費用や本番稼働開始時期は、プロジェクト全体に関係する重大事項ですから、ソフトウェア開発の性質上、契約当初には高精度の見積が困難であるということを加味しても、プロジェクトを協力して進めるにあたっての目標を定めておくという点では、基本合意書を作成することにも、十分意味があるものと考えられます。
基本合意書には、費用総額や本番稼働開始時期のほか、これらを算出するために必要な開発スコープを記載しておくことが、事後的な紛争の発生を抑制するという見地から、有用であるものと考えられます。
他方で、費用総額等は、あくまでも法的拘束力を有しない予測段階のものですから、その旨や変更されることがあり得ること等をしっかりと明記しておくことが必要となります。
なお、これらの事項を基本契約書において明記することとしてもよいものと考えられます。
東京高判平成25･9･26金判1428-16は、契約締結前の企画･提案段階においても、ベンダにプロジェクトマネジメント義務が課せられることが明言しています。
そこで、契約締結前から、ベンダは、自らがプロジェクトマネジメント義務を果たしていたことを表す証拠の作成をすべきと考えられます。
東京高判平成25･9･26金判1428-16
「企画･提案段階においては、プロジェクトの目標の設定、開発費用、開発スコープ及び開発期間の組立て･見込みなど、プロジェクト構想と実現可能性に関わる事項の大枠が定められ、また、それに従って、プロジェクトに伴うリスクも決定づけられるから、企画･提案段階においてベンダに求められるプロジェクトの立案･リスク分析は、システム開発を遂行していくために欠かせないものである。そうすると、ベンダとしては、企画･提案段階においても、自ら提案するシステムの機能、ユーザーのニーズに対する充足度、システムの開発手法、受注後の開発体制等を検討･検証し、そこから想定されるリスクについて、ユーザーに説明する義務があるというべきである。このようなベンダの検証、説明等に関する義務は、契約締結に向けた交渉過程における信義則に基づく不法行為法上の義務として位置づけられ、控訴人はベンダとしてかかる義務(この段階におけるプロジェクト･マネジメントに関する義務)を負うものといえる。」
例えば、以上の事項を記載した書面をメールでユーザに送付したり、企画会議の会議資料や会議議事録を残すことが考えられます。
また、パッケージを用いて開発を行う場合には、パッケージの選定経緯についても、書面等の形で証拠化しておくべきと考えられます。
具体的には、当該パッケージのリスクの確認やその対処方法等を十分検討し、これらをユーザに適切に説明した上で、ユーザがパッケージの選定を行ったことを証拠として残しておくのが適当であるといえます。
さらに、ベンダとしては、自らがプロジェクトマネジメント義務を果たしたことの証拠を作成するだけでなく、場合によっては、ユーザが協力義務に違反したことの証拠を作成する必要も生じるものと考えられます。
反対に、ユーザにとっても、ベンダのプロジェクトマネジメント義務が果たされているかどうかを確認するために、ベンダからのプロジェクトマネジメント義務に関する事項の説明を客観証拠に残すことは重要です。
また、ベンダと同様に、自らが協力義務を果たしたことの証拠を作成することも必要と考えられます。
契約締結後も、プロジェクトマネジメント義務や協力義務は問題となります。
そこで、上述したもののほかに進行管理表を作成する等、自らがプロジェクトマネジメント義務や協力義務を果たしていたことを表す証拠の作成を行うべきと考えられます。
また、相手方にプロジェクトマネジメント義務や協力義務の違反があったと考えられる場合には、その証拠をも作成すべきと考えられます。
仕様等に関する事項でも、契約に関する事項でも同様ですが、契約締結後の業務遂行にあたって確定した事項や、当初決定されていた事項から変更された事項については、書面の形で証拠化すべきです。
例えば、ある時点で「本合意の成立をもって、○○の仕様は確定したものとし、以後の仕様変更は受け付けない」といった旨を記載した合意書を取り交わすこと等が考えられます。
最終的な事項を記載することはもちろんのこと、それに至った経緯等も紛争となった場合には価値を有しますから、これも書面に残しておくべきです。
そのためには、会議の議事録を残しておくことや、メールによるやりとりを原則とすることなど、「言った言わない」の水掛け論とならないようにしておくことが重要です。
業務が進んでいくにつれ、最終成果物以外も含めた何らかの成果物が作成され、これがユーザに納品されることとなるでしょう。
その際には、その成果物をユーザが確認したことを証する書面を残すのが適当であると考えられます。
成果物と委託料とが紐付いている場合もあり得ますし、成果物に関する紛争を防止する上でも必要となってくるものと思われます。
なお、いつまで経ってもユーザによる確認がなされない場合もあり得ますから、契約の段階で、みなし確認条項を契約書に盛り込んでおくことが必要不可欠です。
受付: 10:00~18:00 / 土日祝を除く