法とＩＴの話

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

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

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

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

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

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

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

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

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

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

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

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

「仕様書」はシステム開発委託での「売り物」そのものを規定する。極端な話、「仕様書」と委託料さえ決まっていれば、細かな契約条項がなくても、残りは民商法の原則で埋めて、それなりの契約として通用する。世の中の契約書の議論のほとんどは、ひな形を中心とした原則論であるが、契約実務で本当に重要なのは、原則で埋めることができない「仕様書」なのである。（解説）

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

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

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

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

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

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

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

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

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

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

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

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

判旨では、契約した「当時の技術水準に沿ったセキュリティ対策」が必要とされ、ハッキング等のリスク状況の高まりに応じて必要レベルが変わっていくことが示されている。セキュリティ対策としては当然のことながら、法的な評価としても、構築当時には「適格」であったものが、数年間のうちに「不適格」となり得るわけである。（解説）