システム開発契約

 以下に例を挙げるのは、ライセンサーと代理店との代理店契約にある、勧誘行為の優先権に関する非常に複雑な条項です。内容はあまり関係ありませんので、条項の長さと複雑さを見て頂ければ十分です。
 「ライセンサーが代理店からの顧客勧誘の通知を受ける以前に、顧客に対して本製品販売についての勧誘行為を開始した場合、当該顧客に対してはライセンサーの勧誘行為が優先するものとし、別途ライセンサーの書面による事前の承諾がない限り、代理店は当該顧客に対して本サービスの勧誘行為を行うことはできないものとする。これに対し、代理店がライセンサーによる勧誘行為の開始以前に顧客勧誘の通知を行った場合は、ライセンサーは合理的理由のない限り当該通知を承認するものとし、当該顧客に対しては代理店が優先して勧誘行為を行うことができるものとする。ただし、顧客勧誘の通知の日から1年間を経過しても代理店と当該顧客との間に販売契約が成立しない場合は、ライセンサーは自己の選択により、別途規定される紹介料Aを代理店に支払うことにより、定められた期間内に限り、ライセンサーが優先して勧誘行為を行うことができるものとする。また、代理店が優先して勧誘行為を行うことができる場合であっても、顧客が自己の判断でライセンサーとの直接の販売契約を希望する場合、以降はライセンサーが優先して勧誘行為を行うことができるものとし、この場合にライセンサーと当該顧客との販売契約が成立したときは、ライセンサーは代理店に対して別途規定される紹介料Bを支払うものとする。」
 この代理店契約では、ライセンサーと代理店がしばしば同じマーケットで競合関係に立つ、1回の取引額が(したがって、勧誘行為にかけられるコストも)大きい、という事情があったことから、取引のルール自体が複雑となり、それが条項に反映されたわけです。条項を作成し、交渉すること自体に相当な時間、労力、コストをかけていますが、それだけのことはあるという例です。実際の契約では、更に複雑なコミッションの取決めもありますが、ビジネスの内容そのもの、金銭に直結する問題ですから、相当なコストをかけても引き合うわけです。

 これに対して、かけるコストに引き合わない条項もあるわけですが、あまり議論されることはありません。その理由は、コストとの天秤にかけることが、「契約書をきちんと取り交わす」というあるべき姿から離れるようで、後ろめたさを感じさせるからでしょうか。しかし、契約書はあくまでビジネス上の取引に付随する手段であって、それ自体が目的ではありませんから、費用対効果を無視するわけにはいきません。条項作成のコスト、リーガルチェックのコスト、交渉のコストは言うまでもありませんが、それらの負担のために、契約締結自体が遅延するコスト、更には結局のところ契約を締結できなくなるコストも考えなければなりません。
 契約書を取引の(法的)リスクのヘッジの手段と考えれば、ヘッジできるリスクの大きさがコストを上回らなければ、目的を達しないことになります。ここで、「リスクの大きさ=発生頻度×影響度」ですが、注意したいのは「発生頻度」の方です。契約書の中の多くの条項は、ある種のリスク状況を前提とするものですから、必ずそれなりの「影響度」がある場面を想定しています。しかし、多くの場合、それだけのリスク状況が顕在化する可能性は実はそれほど高くはありません。ここでいう「発生頻度」とは、有事の際にその条項の有無によって法的帰結が変わってくる頻度、を意味するからです。
 例えば、損害賠償額の上限を契約額とする責任限定条項における「発生頻度」とは、自己の責任で債務不履行を来たし、それに起因する損害が相手方に発生し、かつ賠償すべき金額が契約額を超える頻度、ということになります。この場合の「影響度」は、本来の損害賠償額が契約額を超える差額ですが、これが大きくなるにつれ「発生頻度」は急激に低下していきます。この両者の掛け算が、責任限定条項でヘッジできるリスク、すなわち同条項がもたらす(そしてコストと比較されるべき)効果ということになるわけです。このように、比較的効果が高いと考えられる責任限定条項ですら、それほどのリスクヘッジ効果があるわけではないのです。むしろ、その効果の大部分は、青天井になりかねない賠償額を有限の枠内にとどめる保険的効果という、責任限定条項に特有の機能にあるというべきでしょう。
 実際のところ、一般条項の多くは「発生頻度」が非常に低いのが通常です。権利義務譲渡の禁止、合意管轄、誠実協議などは、契約書には必ず入っているが訴訟でも訴訟外でも一度も使ったことがない、というのが多くの企業における実情でしょう。これらは、定型的でコストが低いために契約書に入れておく意味はありますが、「第三者からの権利侵害の申立ての場合の取扱い」などになると、本当に(有効に)機能する場面があるのか疑問に思えてきます。契約実務に余裕のない中小企業の通常の取引であれば、「契約書をきちんと取り交わす」ことの重点は、契約書がないまま取引関係に入るのを避けること、取引対象や金額のような取引固有の条件を明確にすること、にあると言うべきです。

 明治29年に制定された民法(のうち契約等に関わる債権法の部分)が、約120年ぶりの大改正となります。実際に施行されるのは2020年4月からとなりますが、早くから準備するに越したことはありません。また、施行後も相当の期間にわたり、解釈や運用の状況をウオッチしていく必要があります。
 もっとも、改正議論の当初には3000項目にも及んでいた論点は、次第に現実的(保守的?)になってゆく議論の過程で縮小され、一般企業の、特に日常の契約法務に与える影響は、比較的緩やかなものとなりました。その中で、IT法務への影響が大きいと思われる注意すべき改正点を挙げるとすれば、以下の三点でしょうか。

 一点目。相手方の債務不履行により契約を解除する際に、旧法では要求されていた相手方の帰責事由が不要となります(新法541条)。要は、責任原因はひとまず措いて、ともかく履行の遅滞や不能があれば契約関係は解消できてしまうということです。この点は、実は今回の改正で最も違和感のあったところです。システム開発契約が頓挫した際、訴訟の中心的な争点とされていたのがこの帰責事由ですし、契約が解除されてしまえばベンダの報酬はゼロ(前払の報酬も返還)が原則となるからです。もっとも、新法も解除しようとする側に帰責事由があった場合は、解除できないとしています(新法543条)。開発頓挫でベンダに責任原因がないということは、ユーザに責任原因があるというのと表裏一体ですから、結局のところ、新法に変わって影響が出るのは「誰の責任でもないのに頓挫した」という稀有のケースだけということになりそうです。それでも、法文の違いが何かしらの違いを生むかも知れませんが。
 二点目。旧法での瑕疵担保責任は、新法では契約不適合責任という形で再整理されます。用語の変更に表れているように、責任の性質として契約との結び付きがより前面に打ち出されます。ただ、システム開発契約等で問題となる請負契約、特に固有性の強い受託開発での責任に限れば、もともと契約をベースに責任の有無が判断されていましたので、特に変わりはありません。むしろ気になるのは、責任の期間制限の起算点が「目的物を引き渡した時」(旧法637条1項)から「不適合の事実を知った時」(新法637条1項)に変わることでしょう。ベンダにとっては、「稼動から数年経って初めて踏まれた特殊条件下でのバグ」のようなものに対応しなければならないことになります。その時には開発当時の事情を知る担当者もいなくなっているかも知れません。この規定は契約で上書くことはできますから、メインの交渉ポイントの一つになりそうです。
 三点目。新法で導入される「定型約款」(新法548条の2)に該当する場合、相手方の利益を一方的に害する条項が無効とされるといった制約がある反面で、一定限度の変更は準備した側が単独で行うことができるようになります。ただ、「定型約款」は、日常的に使われている「約款」とは似て非なるものです。もちろん、事前の具体的な合意なしに通用力が認められる点ではまさに「約款」なのですが、「定型」すなわち、不特定多数者を相手方とする取引で、内容が画一的であることが当事者双方にとって合理的であることが要件とされています。そこで、実務対応としては、まず「約款」らしきものが「定型約款」に該当するかどうかの判断から始めることになります。IT関連では、開発契約書が該当することはまず考えられませんが、ウェブやクラウド関係の規約類が該当する可能性は高いでしょう。相手方の保護という点で消費者法制と共通するところがありますが、相手方が事業者であっても適用があるため注意が必要です。

 その他では、消滅時効の期間が原則5年に統一されますが(新法166条1項)、商法の適用を受けていた企業間の取引ではもともと5年でしたので、大きな違いはありません。また、請負契約が仕事の完成前に終わった場合でも利益の割合に応じた報酬が認められるようになりますが(新法634条)、これは従来から最高裁判例で認められていたもので、(にもかかわらず)もともとシステム開発契約では殆ど適用されたことはありません。さらに、準委任の中に請負に近い「成果完成型」の類型が認められるようになりますが(新法648条の2)、これも従来から実務上あったものですし、新法でも「成果の引渡し」が必要となるだけで「完成」が求められるわけではありません。
 ただ、従来からあった判例や有力な学説、実務慣行が明文化されただけでも、交渉でより使いやすくなり、訴訟でより主張しやすくなり、その結果、解釈や運用に微妙な影響が及ぶことはあり得ます。とはいえ、こうした点は、施行後に訴訟を中心とした実務運用が安定化して、初めて明らかになるものです。新法が現実に適用されるのは、(条文によって異なりますが)概ね施行後に締結された契約です。それらについて解釈問題が表面化し、裁判例等の形で積み重なるのは相当に先のことになります。まずは、重要な影響を生じさせるポイントを押さえることが先決です。近年では個人情報保護法が施行された際が典型ですが、大きな法改正がある場合は、変化に対する過剰反応的な解釈や誤解に基づく誤った解釈が実務に横行することがあります。疑心暗鬼的な現場の不安が、世間の「改正熱」で煽られて増幅されるのでしょう。冷静に対処したいものです。

 システム開発工程に関するV字モデルは、ある設計工程(以下、いわゆる超上流工程はひとまず除きます。)の内容を、これと対応関係にあるテスト工程で確認しなければならない、とするものです。実務でも概ね常識と言えるものとなっており、各種のモデル契約でも工程の定義・考え方はこれが前提とされています。例えば、IPAが出しているガイドブックでは、プログラム設計と単体テスト、詳細設計と統合テスト、基本設計とシステムテストが、それぞれ対応づけて紹介されています。
 もっとも、テスト工程は通常、前工程でテスト済みとなったコンポーネントをより大きいコンポーネントに結合していくという考え方で組まれています。例えば、単体テストではジョブやUI単位、結合テストではサブシステム単位、システムテストではシステム全体(他システムを含む)といった具合です。すると、ここで疑問が生じます。詳細設計は内部仕様を対象にしていて必ずしもサブシステムへのコンポーネント結合を設計事項とするものではなく、基本設計は外部仕様を対象としていて必ずしもシステム全体へのコンポーネント結合を設計事項とするわけではないからです。設計工程とテスト工程は対応づけられているにも関わらず、その視点にはズレがあるのです。これは矛盾なのでしょうか。
 結論を言えば、若干の矛盾はあります。その理由は、V字モデルの原型を見ると分かります。もともと、V字モデルは、ISOやJISで規格化されたSLCP(Software Life Cycle Process)に由来します。同規格に基づく共通フレーム2013の工程を見ると、以下のように、設計工程は、○○要件定義と○○方式設計が、テスト工程は、○○適格性確認テストと○○結合がセットになる形で、細かく工程分けがなされています。

・2.3.2 システム要件定義 - 2.3.6 システム適格性確認テスト
・2.3.3 システム方式設計 - 2.3.5 システム結合
・2.4.2 ソフトウェア要件定義 - 2.4.7 ソフトウェア適格性確認テスト
・2.4.3 ソフトウェア方式設計 - 2.4.6 ソフトウェア結合

 V字モデルとは、要件に関する○○要件定義と○○適格性確認テストを、コンポーネント化とその結合に関する○○方式設計と○○結合を、それぞれ対応づけた(と言うよりそのような対応を前提に工程分けした)ものなのです。しかし、実務では、SLCPのここまで厳密な工程分けには付いて行けるものではありません。そのため、これが基本設計や詳細設計、あるいは結合テストやシステムテストに単純化されると、この2つの視点が混在してしまい、矛盾が生じるわけです。
 既に述べたとおり、実務でのテスト工程の設定では、開発チーム分けとの兼ね合いもあり、コンポーネント結合の視点が先行することが多いと思われます。その際に、それだけに留まらず、テストの時点時点において、設計時の要件が漏れなくテストされていることを確認すべきである、V字モデルの実務上の意義はこのようなことになるでしょう。また、契約問題を議論する際に、対になる工程間には必ずしも一義的な対応関係があるわけではない、ということも確認されるべきでしょう。

 「中間成果と報酬支払」で言及した「システム開発の中間成果に独立した完成物としての価値があるか」ということをより一般化すると、契約ないし取引の単位の問題となります。つまり、契約の成立や履行、解除などは、まとまりのある「一単位」毎に考えるべきということです。
 このような「一単位」は、通常は契約の単位に一致しますが、複数の契約で「一単位」とされる場合(例えば、最判平成8年11月12日は、「同一当事者間の債権債務関係がその形式は甲契約及び乙契約といった二個以上の契約から成る場合であっても、それらの目的とするところが相互に密接に関連付けられていて、社会通念上、甲契約又は乙契約のいずれかが履行されるだけでは契約を締結した目的が全体としては達成されないと認められる場合には、甲契約上の債務の不履行を理由に、その債権者が法定解除権の行使として甲契約と併せて乙契約をも解除することができる。」としています。)や、1個の契約の部分が「一単位」とされる場合(例えば、最判昭和56年2月17日は、「建物その他土地の工作物の工事請負契約につき、工事全体が未完成の間に注文者が請負人の債務不履行を理由に右契約を解除する場合において、工事内容が可分であり、しかも当事者が既施工部分の給付に関し利益を有するときは、特段の事情のない限り、既施工部分については契約を解除することができず、ただ未施工部分について契約の一部解除をすることができるにすぎない。」としています。)もあり、契約の切分けにとらわれない「実質」的な単位が問われます。他方で、契約書等の「形式」も、当事者意思を通して契約の「実質」を推認する有力な材料となりますから、契約の際に十分な注意が必要なことは言うまでもありません。
 このような「一単位」を判断する要素として重要なのは、契約上の給付の内容です。システム開発の例で、このような「一単位」となり得るものを、小さいものから順に挙げると、①あるシステムの工程(例えば、「販売管理基幹システム」の設計工程や製造工程のそれぞれ)、②あるシステムの各フェーズ(例えば、「販売管理システム」の「第1フェーズ=基幹系」と「第2フェーズ=情報系」のそれぞれ、③あるシステム(例えば、「販売管理システム」の全体)、④別個のシステム(例えば、A社の「販売管理システム」と「会計システム」を併せたもの)、システム開発と運用・保守、あるいはシステム開発とハードウェア、となるでしょう。このうち、②や③は実際の「一単位」となり易く、①は「一単位」の一部分とされ易く、④は複数の「一単位」を含んだものとされ易いと言えます。もっとも、判断は具体的な状況にもよります。①の類型でも、一括請負の場合に開発が途中頓挫しながら、引継利用が可能な要件定義の成果物に対する報酬が認められる場合は考えられなくはありません。逆に、④の類型でも、システム開発委託契約が解除されて対象となるシステムが消滅すれば、当該システムを対象とする保守・運用契約もまとめて解除(あるいは「原始的不能」でしょうか)が認められると思われます。
 他方、契約書等での扱いについて、前と同様に列挙すれば、a.単純な成果の単位(例えば、契約書上で作業や納品物として別記されているだけ)、b.支払の単位(検収を伴わない支払)、c.検収の単位(検収を伴う支払)、d.契約書の単位、e.複数の契約書を束ねた単位、となるでしょう。概ね、c.やd.の大きさが「一単位」とされ易いでしょうが、そのような単位を構成する給付内容の組合せや、そのような単位となった意図・経緯が問われます。
 システム開発の事例では、開発請負契約とこれに付随したサーバの売買契約(上記④の類型)を一体のものと見て、開発請負契約の解除事由が当然に売買契約の解除事由になるとしたものがあります(東京地判平成18年6月30日)。しかし、その理由は「本件契約は...、ウインドウズサーバーによるデータベースの開発を前提にしており、そのことからこれまでの使用していたマッキントッシュサーバーからウインドウズサーバーに変更することを前提として、原告はウインドウズ用のサーバーを購入したのであって、本件データベースの開発がなければ本件サーバーを購入していない関係にあるといえる。」というものに過ぎません。対応するOSの変更があるとは言え、ウィンドウズサーバも流用可能な汎用サーバで、実際にも流用していたというのですから、あっさりと認め過ぎです。また、判旨のように条件関係を理由にするのであれば、仮に開発請負契約と売買契約の相手方が異なっていても解除が認められる理屈となり、この点でも疑問が残ります。

 情報システムの保守は、パッケージ等を用いていればなおさら、そうでなくも、これを開発したベンダでなければ困難なのが通常です。そのため、開発委託契約とその後の保守契約は、切っても切れない関係になります。以下は、そうした関係の一例です。
 保守契約の範囲として、しばしば「障害の(一次)切り分け」という作業項目が現れます。ユーザの下でシステムに何らかの障害(と思われる)事象が発生した場合、本当に障害なのか、運用上のミスなのか、単なる要望なのか、障害だとすれば、その原因がハードにあるのか、ミドルウェアにあるのか、アプリケーションにあるのか、などを調査して判断するというものです。
 問題なのは、このような切り分けを行った結果、保守契約の当事者であるベンダ自身が瑕疵担保責任を負うアプリケーションの障害であった場合、有償保守の対象になるかどうか、ということです(保守時間に制限のない場合は別ですが)。少なくとも、システムが完成した後はベンダに瑕疵の積極的な調査義務(これは再テストを意味する)がないことは明かですが、逆に、ユーザとしては調査を尽くさなければ瑕疵修補を請求できないのでしょうか。訴訟上の請求であれば、原則として、ユーザ側で障害の原因がアプリケーションにあることまで立証しなければ、そもそも修補の対象たる「瑕疵」と認められません。しかし、保守契約が継続している場合、専門的知見の程度や証拠(対象システム)への距離の違いも考慮すれば、切り分け前の障害と一応の原因をユーザが指摘した限度で、修補すべき「瑕疵」が特定されたと見て、結果それが実際に瑕疵であった場合は、遡って切り分け作業から修補のプロセスに入っていたという見方もできそうです。あるいは、修補自体は切り分けが終わってからと見るとしても、仮に瑕疵がなければ切り分けは必要なかった作業である以上、これが有償であっても、瑕疵の修補と共にする損害賠償請求権と相殺されると考えることができます。
 もちろん、このような切り分けを有償とする契約もあり得ますが(むしろその方が多いですが)、それは本来、保守契約の内容としてではなく、開発契約の瑕疵担保責任の制限として合意されている必要がある理屈ではあります。

 システム開発委託のモデル契約書で良く利用されているのは、経産省の研究会による「情報システム・モデル取引・契約書」で、伝統的な受託開発中心の第一版の後、中小企業でのパッケージ利用等を意識した追補版も出ています。超上流工程やマネジメントの重視、変更管理の徹底、重要事項説明書の導入など、システム開発に固有の論点に様々な知見を盛り込んでいます。従来からあったJISAやJEITAのモデル契約書も、経産省のものをベースに改訂されています。
 しかし、これらは多数の条項からなる、いかにも「重い」契約書です。残念ながら、中小企業には(ベンダであっても)、とても使いこなせないというのが実情です。しかも、条項がある以上、契約リスクの配分に影響しますから、言いなりに判を押すのでない限り、その一々が締結前の交渉のテーブルに載せられます。場合によっては、どのような場面を想定しているのかも分からない条項について、その理解から始まって、細かな文言修正まで何度も契約書案が行き来します。同じ経産省が委託事業の成果として出している「情報システム・ソフトウェア取引トラブル事例集」では、契約締結の遅れが正式契約前の作業着手を招いている面があるとして、迅速な契約締結のためのツールとしてモデル契約書を位置づけています。しかし、実際のところ、「重い」契約書が反って迅速な締結を阻んで、正式契約前の着手を生んでしまい兼ねません。
 細かな条項も、それ自体はあるに越したことはありません。しかし、当事者の能力や契約の規模にもよりますが、重要な契約条件をそれらの条項に埋もらせてしまうよりは、システム開発委託での典型論点である、再委託の可否・条件、作業やマネジメントの責任分担、、変更管理、著作権等の権利帰属、損害賠償責任の範囲・限度額・期間、などに絞った契約書とする方が遥かに実務的ではないかと思われます。
 そして何より、開発対象のシステムの範囲・内容と代金の支払条件を明確にすることです。開発委託におけるトラブルが、そもそも何を請け負った契約なのかが不明確であることに起因するケースが非常に多いためです。未だに、「○○システム一式」などという場合も後を絶ちません。これと表裏一体で、代金(特に中間金)の趣旨がはっきりしないケースも、極めて多く見られます。極論すれば、一般条項など何もなくても(その場合は判例等で補充された民法の一般原則が適用されます)、これだけ決まっていれば関連紛争は半減するのではないかとすら思われます。ところが、世の契約実務では、IT法務的な意識が高いほど、却って経産省式の弊に陥っているのです。

 システム開発委託契約の殆どは、法律上、請負契約になると解されています。これは、受託者であるベンダはシステムを完成させる義務を負い、委託者であるユーザはその完成に対して報酬を支払う、ということを意味します。つまり、報酬の点で言えば「後払い」となるのです。問題は、契約書でこれと異なる支払条件を規定した場合です。
 例えば、要件定義の終了時に3分の1、設計の終了時に3分の1、製造とテストまで終了してシステムが完成したときに3分の1、と定めたような場合です。このような場合、テストの途中で品質不良が発覚して結局システムが完成しなかったら、既に支払われた3分の2はどうなるのでしょうか。最初の2回の支払はあくまで中間金の仮払だと考えれば、システムが完成していない以上、3分の2はユーザに返還されなければなりません。これに対して、最初の2回もそれぞれ要件定義の成果、設計の成果に対する確定的な報酬だと考えれば、3分の2は返還の必要はありません。ユーザの意識では前者(欲しいのは完成したシステムであり、中間成果だけに報酬を支払ったりはしない。)で、ベンダの意識では後者(必要な労務を投入して、中間成果を納入した以上は報酬をもらって当然。)となることは、容易に分かるでしょう。
 ところが、そうした「意識」と契約書での記載には多くの場合ズレがあり、紛争に争点を一つ付け加えることになります。記載の上では、単に分割支払が規定されているだけでは、原則に戻って前者の判断になり易いですし、各回で中間成果に対する検収が予定されていれば、原則を修正して後者の判断になり易いですが、当事者の意思(これが契約内容を規定します。)は契約書の文言だけで決まるわけではありませんから、事は厄介です。
 この問題は、「システム開発の中間成果に独立した完成物としての価値があるか」ということと表裏の関係にあります。ユーザはこれを否定に解し、ベンダはこれを肯定に解するわけです。抽象的に言えば、「価値あらしめることは必ずしも容易ではないが、不可能ではない」というところでしょうが、この程度では解釈上の役には立ちません。何れにしても、契約書には、この成果と支払の関係が(当事者の意識と合致する形で)明確に規定されている必要があります。もっとも、ユーザが「中間金であっても成果について何らの確認もしないまま支払いたくない(最終的な完成が危ぶまれる場合には支払を留保したい)」と考えて確認の手続を入れたのが、却ってやぶへびとなった事例もあるくらいですから、一筋縄では行きません。

 プロジェクトマネジメントは、一定規模以上のシステム開発にとって、不可欠のものです。システム開発は、単なる設計・開発業務の集積ではなく、プロジェクト、すなわち「一定の期間内に、新たな成果物を創り出すことを目的として実施される一連の活動」なのです。このような創造性が高く、人的にも物的にも管理が難しい活動のコントロールには、それ相応の方法論が必要となります。

 ところが、プロジェクトマネジメントの問題は、契約書上、ひどく軽視されているのが実状です。少なくとも私は、プロジェクトマネジメントに関する条項が契約書の本体に入っているのを見たことがありません。スケジュールや成果物などと共に添付書類で言及されていれば良い方で、それすら欠けた契約書も珍しくはありません。モデル契約書も例外ではなく、第13条にマルチベンダの際のマネジメント責任という、やや特殊な条項があるほか、プロジェクトマネジメントに対する考慮は見当たりません。
 さすがにこのような契約であっても、実際にプロジェクトが始まり、プロジェクトの実行計画が作られるくらいの段階になると、プロジェクトマネジメントが意識され、計画、実施されるのが通常です。では、そうもならなかったら、どうなるか。実際、失敗プロジェクトの殆どはプロジェクトマネジメントの誤りに起因しますから、紛争化したプロジェクトではプロジェクトマネジメント責任の所在が激しく争われます。
 契約は当事者の合意ですから、原則論を言えば、契約書に書かれていないものは契約上の給付の対象とならない、ということになるのでしょう。いわば、「それは売り物ではない。」という理屈です。モデル契約書も、そのような前提に立っているものと思われます。しかし、十年に一度しかシステム開発プロジェクトを経験しないユーザが「責任をもってプロジェクトマネジメントをやります。」などという契約は極めて不自然ですし、実働部隊の大半を抱えるベンダは、事実上、内部管理の延長としてプロジェクトマネジメントを考えざるを得なくなるはずのものです。結局のところ、プロジェクトマネジメントについてベンダが完全な免責を得ることは、まずあり得ないのではないかと思います。
 ベンダが、もし、設計・開発はできるがプロジェクトマネジメントには自信がない、ということであれば、プロジェクトの統括責任は持たないとか、ユーザ分担の業務には責任を持たないとか、プロジェクトマネジメント責任を限定した条項を入れておくべきでしょう。そのような場合、開発代金は割安になるのでしょうが(むしろ割安にするためにそのようにするのでしょうが)、他方でユーザとしては、欠けたプロジェクトマネジメントをどのように補充するのか、十分に考えておかなければなりません。体制を手厚くするにせよ、コンサルなどの第三者の支援を受けるにせよ、結局は、コストとプロジェクト成否のトレードオフになってしまうわけですが。

 納入物の著作権(第45条)は、ベンダ帰属、ユーザとベンダの共有、ユーザ帰属の三論鼎立となり、JISAのモデル契約書よりは柔軟になりました。しかし、「汎用的に利用が可能なプログラム」(これも範囲が良く分かりませんが)はともかく、システム本体の著作権をベンダに留保させることには、少々違和感があります。もちろん、これは単にベンダの利益を図ったものではなく、ソフトウェアの再利用を促進するという大義名分があります。そして、この再利用は一つの政策提言でもあるわけですが、どこまで実情に即したものか疑問が残ります。

 その1。第41条の規定や、「ベンダに著作権を帰属させたとしても、秘密保持義務を課すことで、ユーザのノウハウ流出防止を図ることが可能である。」との解説からも分かるように、必ずしも再利用がユーザの利益を害することにはならい、という前提が置かれています。しかし、本来、情報システムに化体されたユーザの業務ノウハウを利用するだけで、秘密保持義務違反になり兼ねないのです。それなのに、表現そのものを丸々再利用しながら秘密保持義務に違反しない場合が本当にあるのでしょうか。ユーザが多大の時間とお金をかけてカスタムメイドの情報システムを開発するのは、それによって事業の差別化を図りたいからです。ところが、それが容易に同業他社に再利用されるとすれば、ユーザは何のためにシステム開発したのか分かりません。
 その2。ユーザは、当該システムを保守を繰り返しながら使用するのですから、著作権があるに越したことはありません。他方、ベンダは、どこまで著作権が必要なのでしょうか。開発された情報システムは、ベンダにとっても「資産」です。そこには、業務プロセスや情報システムの専門家としてのベンダのノウハウが詰まっています。ですから、将来、類似の開発を行うに際しては、それを参考にすることは大いにあり得ることですし、また、そうすべきでもあります。しかし、それはせいぜいドキュメントして「参照」するだけで、設計書にせよソースコードにせよ(著作権が必要になるような)切り貼りをすることは考えられません。「カスタム」色が強すぎて、たとえ一部であっても、そのまま使えるようなものではないのです。著作権があれば、権利侵害を憂うことなく、安心して「参照」することができますが、防御策としてはあまりに高くつきます。逆に、ベンダが自己のノウハウの再利用のための許諾を受ける、ということも考えられるかも知れません。
 もっとも、ならばユーザが著作権を持つべき、というほど事は単純ではありません。このあたりは、別稿に譲ります。

 法律とITの接点というと、掲示板での名誉毀損のようなものがまず思い浮かぶところですが、「企業の情報システム」の領域で言えば、システム開発委託の契約書が横綱級です。この分野では、以前はJISAのモデル契約書がポピュラーでしたが、2007年4月に経産省から「情報システムの信頼性向上のための取引慣行・契約に関する研究会」の報告書として、新しいモデル契約書が出されました。実務に少なからぬ影響を与えることになるでしょう。ここでは、このモデル契約書から題材をとって、情報システムの開発委託契約について考えてみたいと思います。

 「多段階契約と再見積」とは、要するに、要件定義・設計・開発...というシステム開発の各工程毎を別契約とし、したがって、契約の前提となる見積もその都度行うというものです。システム開発は、工事や建築などと違って、開発過程に流動的な部分が残らざるを得ないものですから、この方式自体は十分な合理性があるものとして、モデル契約ではJISA以来採用され、実務にも浸透しています。
 ベンダの立場からすると、特に大規模開発では、システム化計画をやっているような先が読めない時期に開発全体の期間と金額を合意してしまうのは、すべての変動リスクを背負うことにほかなりませんから、必須あるいは当然と言いたいところです。他方で、ユーザの側からすれば、2年・10億のつもりで始めた開発が実は5年・30億だった、などということになったら、投資計画も何もありません。これを採用するとしても、基本契約上、再見積には合理的抑制をかけておくことが必要になります。
 もっとも、まともなベンダであれば、そのような見積提示をすることはないはずです。そもそも、ユーザは、中長期の経営計画と一定の予算的枠組みの中でシステム開発を計画するわけですから、「これだけの機能を開発するのには、5年・30億かかります。」という教科書的見積は、実はナンセンスなのです。「2年・10億で開発できるのは、この範囲の機能です。」というところからスタートして、合理的な開発範囲を探りながら、期間と金額について互いに歩み寄る、というのが普通の見積であり、契約交渉です。私が過去に見てきた見積もそのようなものでしたし、ベンダ側に立つ人間として、「そうでなければ通用しない」と思っていました。
 ところが、昨今では平気で「5年・30億」と言うベンダもあるようです。技術部門がひとまずそのような見積を作るのはともかく、これが営業部門を素通りしてユーザに提示されるというのでは、営業が営業の役割を果たしていない気がします。このようなやり方では、本来合理的であったはずの段階的契約と再見積が、反ってユーザとベンダの衝突の種になってしまいます。この裏には、見積自体の精度の問題もあって、そうだとすると、せっかくの多段階契約もその合理的基礎を欠いた、「紛争の先送り」でしかないことになります。
 他方、ユーザもシステム開発の難しさを十分に理解してないケースが目立ちます。「10億円もの予算を組んだのだから、もうこれ以上は出せない。」と言わんばかりに、追加予算のための手当が全然なされていないケースがあるのです。システム開発は未知への挑戦です。10億が30億になるというのはともかく、10%や20%程度の膨らみは、ベンダの見積誤りがなくとも、現場部門からの過大要求がなくとも、十分あり得ることです。ベンダにムリな「吸収」を迫ることは、決してユーザのためになることではありません。
 この多段階契約の対極にあるのが、一括請負です。これは、早期に開発予算を確定させたいユーザの側が希望するものですが、仮に10億円の一括請負で契約したとしても、10億円の開発予算が確定できるわけではありません。「○○システム一式」のような契約があるわけもなく、契約範囲には、10億円なら10億円と見積もられた「ある範囲」のシステムが含まれるだけだからです。少なくとも、「ある範囲」を超えれば、そう考えているベンダから追加費用の請求を受け、プロジェクトは紛争状態に向けて動き出すでしょう。