この「法とITの話」では、法とITについてのブログと書籍を紹介します。

ブログ「法とITの話」は、法とITにかかわる話題を広く扱っているブログです。
書籍「ディベートで学ぶシステム開発委託契約」と「IT判例で学ぶマネジメントと紛争対応」は、もう一歩進んだIT法務を扱った電子書籍です。

 この電子書籍「ディベートで学ぶシステム開発委託契約」は、システム開発契約の主要トピックについて、ユーザとベンダの仮想ディベートで「解説」したものです。システム開発契約で押さえておくべき重要事項や、ユーザとベンダとの間で生じがちなトラブルを踏まえた契約書での対応について学びたい方に向いています。

1.多段階契約
2.請負/準委任
3.支払条件
4.再委託
5.変更管理
6.検収
7.瑕疵担保責任
8.著作権
9.秘密保持
10.損害賠償
11.仕様書
付録.平成29年債権法改正の概要

【あとがき】より

 英語に Battle of Forms という言葉がある。自己に有利なひな型(Forms)を用意しておいて、それを相手方に呑ませよういう交渉スタイルを揶揄したものである。実際、「交渉力」を背景にだだリスクを押し付け合うだけでは、交渉とは名ばかりである。もちろん、相手方との契約交渉で訳もなく譲歩を強いられたり、気づかないうちにリスクを背負わされたりすることは、何としても避けなければならない。しかし、その逆もまた好ましいことではない。契約交渉は、一面で Battle であるが、ただの Battle ではない。契約によって拓かれる取引の、公平で合理的な「私的ルール」を創り上げるためのものである。
 もっとも、何が公平で合理的かということになると、ユーザとベンダの見方は180度違ってくる。これは、契約のゼロサム面の現れである以上に、利用者と開発者という「文化」の違いの反映である。少なくとも相手方から見る限り、ユーザは開発者の「文化」に無理解であるし、ベンダは利用者の「文化」に無関心である。互いの「文化」を良く知ることは、ゼロサム関係を超えたパートナーとして、開発を成功させるための土台でもある。相手方からの少々耳の痛い主張には、真摯に耳を傾けなければならない。とても認め難いと思える主張にも、一分の理があるかもしれない。その意味で、むしろ相手方の主張にこそ、多くの「学ぶ」べきことがある。


【内容紹介】

多段階契約の特徴は、①見積りの精度が向上すること、②履行や責任の単位が小さく区切られること、③開発の途中で契約が終了する可能性のあることである。これらには一定の合理性はあるものの、単純に考えればユーザに不利に働く。(解説)

概算見積りでは1億円だったものが、要件定義を終えたら3億円になっていたりする。もうこの時点で、要件定義にかかった費用を捨て去ってプロジェクトを中止するか、予算を3倍増して続行するかの選択肢しかない。進むのも戻るのも、茨の道である。(ユーザ)

U:ベンダは、何かあるとすぐ「絞り込み」と言い出す。(ユーザ)
V:あれもこれもと欲張るのはかえってよくない。開発対象が肥大化すれば、品質リスクは高まるし、保守コストが増大してTCOの観点からも望ましくない。(ベンダ)

RFPに記載されることによって、契約条件の交渉が早期化、実質化することも期待される。反面、自力でRFPを作成できるユーザは限られているため、選定候補のうちの懇意にしているベンダ(ユーザの担当者が選びたいベンダ)に作成させるなど、意味の乏しい文書になり下がることもある。(解説)

委託料が固定であると、ベンダは上ブレ分を丸々(対価なしに)負担することになる。他方で、再見積りの結果を委託料に反映させても、ユーザは当初計画より「高い買い物」をすることになる(だけである)。これだけを考えれば、上ブレ分はなるべく委託料に反映させる方が公平ということになりそうである。ただ、……(解説)

スケジュール遅れの状態は、請負であれば納期遅延であって、報酬請求どころか契約解除や損害賠償の事由になりかねないのに対し、準委任であれば業務の提供期間が延びるだけの話であって、かえって報酬が増えさえする。端的に言えば、請負はユーザにとって大変に有利であり、準委任はベンダにとって大変に有利である。(解説)

U:テストの結果、想定外のバグが出たらどうするのか。(ユーザ)
V:もちろん、検出されたバグは全て潰す。そこまでやって完成である。(ベンダ)
U:そういうことを聞いているのではない。質・量とも想定外のバグが出て、潜在バグの残存が強く疑われる場合に、顕在化したバグを潰すだけでは不十分なのではないか、ということである。(ユーザ)

「分界点」といっても、その境界には相当の幅があるし、分界点の内側での原因が分界点の外側で問題を発生させる場合や、分界点の内外の原因が競合して問題を発生させることもある。したがって、分界点を明確にしたからといって、直ちに問題が解消するわけではない。いずれにしても、「分界点の内側について責任を持つ」でなく、「分界点の外側については責任を持たない」という思考に陥ると、責任の空白が生じる。(解説)

金銭が現にベンダ側にあることが、交渉力に大きな影響を与える。ベンダは現状維持を図ればよいだけであるが、ユーザは積極的に金銭を取り戻さなければならない。そして、ベンダが交渉に応じない限り、ユーザとしては面倒な訴訟に訴えるしか方策がないからである。(解説)

外部設計の終わりまでに、外部仕様を凍結したのがベースになる。そこから変更しようとするのが仕様変更であり、原則として追加費用となる。当然、一度決めたものをプロジェクトとして変更するかどうか、費用やスケジュールへの影響をどう処理するか、慎重に判断しなければならないから、ここから厳格な変更管理が始まることになる。(ベンダ)

開発スコープを画面や帳票の単位で画定させてもなお、開発スコープを巡って大きなトラブルに陥ることがある。例えば、A取引について登録画面だけが開発スコープに明示されている場合、変更画面や取消画面が開発スコープに入るのかどうは明らかでない。ベンダは開発スコープに明示されていない変更画面や取消画面はスコープ外であると主張し、ユーザはA取引の処理がスコープ内である以上、それなしでは業務が回らない変更画面や取消画面は当然にスコープ内であると主張する。(解説)

このような未確定事項があると、確定しない(つまりユーザの要求を反映しない)暫定仕様のまま、内部設計や製造の工程に入ることになるため、後の確定時にベンダ作業に手戻りが生じたり、暫定仕様がユーザに押し付けられたりする。しばしば、多忙から仕様検討を先送りしたいユーザと、作業の先を急ぎたいベンダの「利害」が一致して、大量の未確定事項を生ずることがある。(解説)

 この電子書籍「IT判例で学ぶマネジメントと紛争対応」は、重要な論点を含むIT判例について、事案全体の流れの中で判旨をかなり詳細に引用したうえ、論点単位である程度完結した説明を試みたものです。判例を素材としてIT法を理解し、マネジメントや紛争対応に役立てたい方に向いています。

判例1.システム開発契約の基本三要素
判例2.システム開発契約の正否と契約準備段階の過失
判例3.コンサルティングにおける旧システムの重要機能の欠落
判例4.開発プロジェクト進行中の追加変更
判例5.ベンダのプロジェクトマネジメント義務とユーザの協力義務
判例6.ベンダが負うプロジェクト中止提言義務
判例7.処理時間や排他制御の瑕疵による契約解除
判例8.検収後に判明したシステムのバグ
判例9.データ移行に必要なデータ構造情報の入手不能
判例10.株式誤発注の取消不能に伴う責任関係
判例11.グループウェアの画面に対する著作権侵害
判例12.エステサロン事業者による個人情報の漏えい
判例13.ネットカフェからの名誉棄損の書込についての発信者情報開示

【あとがき】より

 訴訟には、「平成26年(ワ)第1234号」という形式の事件番号が付けられる。このうち「平成26年」の部分は、訴訟が受け付けられた暦年を表している。他方で、判決が出ると、「東京地判平成28年12月25日」などと呼びならわす。日付の部分は、言うまでもなく判決の言渡し日である。つまり、これらが分かれば、いちいち事件記録に当たらなくても、その訴訟の大体の係属期間を計算することができるわけである。
 試みに、本書で採り上げた裁判例について、提訴から第一審の判決までの訴訟期間をこの方法で計算してみると、(年の半ばに提訴したと仮定して)平均で3年強となる。「裁判の迅速化に関する法律」で2年以内の終局が目標とされていることから考えても、かなり長い部類に入る。世の中の大半のシステム開発プロジェクトよりも、更に長くかかっていることになる。
 筆者が最初に関与したIT訴訟も、3年以上かかった。しかも、その事案は、提訴に至るまでに調査や交渉等に相当な期間を費やしていたから、判決で全てが終わったのは、開発プロジェクトが始まってから実に10年後であった。訴訟は控訴されずに一審だけで終わったのだが、これは両当事者ともその時点で既に「疲弊」していたからかもしれない。そして、この紛争解決のため、ユーザ側では(頓挫した開発プロジェクトで予定していた)新システムの実現が10年間凍結されたままとなってしまった。
 IT訴訟は(これを生業とする筆者にとっては残念なことであるが)、開発頓挫にせよ、情報流出にせよ、既に発生してしまった損害を当事者間でいかに分担するかというだけの問題で、いかにも「後ろ向き」である。もちろん、起きてしまった紛争に透明性のある決着を付けるには訴訟によるのが正攻法であるし、長く苦しい訴訟追行を通して危機管理の視点が身に着くといった余得がないこともない。しかし、少なくとも、新しいものを生み出す「前向き」のビジネスとは、大きく違っていると言わざるを得ない。
 そこで重要になってくるのが、いかに紛争を予防するかという視点である。本書の表題を「マネジメントと紛争対応」としたのは、そうした問題意識からである。残念ながらITの世界に「銀の弾」はなく、内容的には至らないところも多くあるが、多少なりとも読者の参考になれば幸いである。


【内容紹介】

実質的な保証の役割を期待するのであれば別であるが、この事案のように、ただ形式を整えるだけの目的で当事者を増やすのは、多くの場合賢明でない。関与する当事者が増えるだけでも契約関係が複雑になるし、かえって権利義務の連鎖が弱くなる意味もある。筆者の経験では、独立した元従業員に業務委託する際、わざわざ「信用力のある」企業を介在させたところ、その企業の方が倒産してしまい、支払った報酬もろとも消えてしまったことがある。(解説)

残念なことに、ITの現場では裁判所が考えるほど、記録や資料を残す習慣があるわけではない。現に動くシステムを作成することが至上の価値であり、第三者に理解させるためのドキュメントには気が乗らない、という意識もあろう。また、障害等の緊急時であれば、混乱した現場でなすべきことは第一に作業であり、悠長に記録を取っている余裕はない、という現実(あるいは言い訳)もあろう。(解説)

この事案では、請負契約書は作成されずに、納期間近に注文書のみが交付されている。その注文書は、代表者ではなく担当取締役の名義であり、制作物として21本のコンテンツの記載があった。《ベンダ》からすれば、不利なところもある書類だったわけであるが、交付された時期や状況から、請負契約の成立のみならず、コンテンツが制作不足であるにもかかわらずシステム完成が認められる決定打となったのである。(解説)

「判例ではこのようになっている」などと言われると、どうにも逃れられない法的な縛りがあるようにイメージされがちだが、そうではない。場合によっては、「このような判断がなされた実例が少なくとも一つある」というだけのことかもしれず、その先踏襲されるかどうかは、もっぱら(法的あるいはIT的な)判断の妥当性にかかっているのである。(解説)

その意味では、ほとんどの開発は、「旧システムを踏襲」するものと言える。問題は、その踏襲の程度であり、具体的に何を踏襲し何を踏襲しないか、踏襲しないとすればどうするかである。そうである以上、その肝心の部分をぼやかしたまま「旧システムを踏襲」といった包括的な合意をすることは、最も避けなければならないことである。(解説)

上記事案の《ベンダ》は、独自の生産性テーブルを持っていたようであるが、独自の生産性テーブルは一般的な統計資料等によってそれ自体の信用性を争われることがあろう。逆に、独自の生産性テーブルを持っていない中小のベンダであれば一般的な統計資料等を用いるしかない。この場合は、操作されていないという意味の信用性はあるとしても、問題となっている事案への適合性の点では劣ることになる。(解説)

《ベンダ》は、納入期限までに本件電算システムを完成させるように、本件電算システム開発契約の契約書及び本件電算システム提案書において提示した開発手順や開発手法、作業工程等に従って開発作業を進めるとともに、常に進捗状況を管理し、開発作業を阻害する要因の発見に努め、これに適切に対処すべき義務を負うものと解すべきである。そして、システム開発は注文者と打合せを重ねて、その意向を踏まえながら行うものであるから、《ベンダ》は、注文者である《ユーザ》のシステム開発へのかかわりについても、適切に管理し、システム開発について専門的知識を有しない《ユーザ》によって開発作業を阻害する行為がされることのないよう《ユーザ》に働きかける義務(以下、これらの義務を「プロジェクトマネージメント義務」という。)を負っていたというべきである。(判例)

ベンダとしては、契約の範囲を超えていても、自らの利益を多少削るくらいであればプロジェクトの円滑な進行を重視して、あえて追加費用の請求を試みない場合が少なくない。厳密に言えば追加変更であっても、いちいち追加費用を求めることは、いかにも「カネ」ばかりを求めているようで、ユーザから強い反発を受けるからである。しかし、追加費用を求めないでいると、ユーザの追加変更要求にブレーキがかからず、「暴発」への途を辿ってしまう。それを義務違反と言われたのでは、ベンダとしては踏んだり蹴ったりの感もあるが、少なくとも突然の「暴発」を回避することはベンダの責任と言うほかない。(解説)

ベンダとユーザーの間で、システム完成に向けた開発協力体制が構築される以前の企画・提案段階においては、システム開発技術等とシステム開発対象の業務内容等について、情報の非対称性、能力の非対称性が双方に在するものといえ、ベンダにシステム開発技術等に関する説明責任が存するとともに、ユーザーにもシステム開発の対象とされる業務の分析とベンダの説明を踏まえ、システム開発について自らリスク分析をすることが求められるものというべきである。(判例)

本事案で問題になったのは非機能要件の一種であるが、機能要件に注意が集中するあまり、一般に非機能要件は合意漏れを起こしやすい。排他制御などは、それとして取り上げることは、稀であろう。特に中小規模の開発では完全は期しがたいところであるが、性能、運用時間、バックアップ、操作性、セキュリティ、といった重要事項には目配りしておくべきである。(解説)

ベンダとしては、請負となるアプリケーション部分さえ完成させてしまえば、準委任であるデータ移行が完了しなかったためにシステムが稼働しなくても、法的責任を免れることができる。契約全体から見ればごく一部の作業の契約類型が変わるだけで、結果的な責任状況に大きな違いが出るのである。(解説)

市販ソフトウェアの画面については、本事案と同様に「類似性」の一本勝負となりやすい。スクラッチ開発の固有ソフトウェア等と異なり、むしろ「依拠」(少なくとも参考にしているという意味で)しているのが通常であろうから、後発製品の開発では先行製品の創作的特徴がどこにあるのかを十分に検討したうえで、これを注意深く避けることが必要である。(解説)