法とITの話

この「法とITの話」では、IT弁護士が、法とITに係わるトピックを提供します。

サイト内の「法とITの話-本館」の方には、IT紛争に関する基本的な「IT判例」についての解説と、IT法務の中で最も頻出する「システム開発契約」についての考察を、不定期に掲載します。
法とITに係わるもう少し雑多な記事は、「法とITの話-別館」のブログでどうぞ。

この「法とITの話-別館」のブログでは、トピックを特に限定せず、法とITに係わる話題を広く扱っています。



【ピックアップ記事】
真意と契約(IT紛争/IT法務一般7)
個人情報の結合(知的財産権5)
装置産業化(IT紛争/IT法務一般6)
情報システムの法的保護(知的財産権4)
プログラムの使用(知的財産権3)

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

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

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


【内容紹介】

 重要な論点を含む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の世界に「銀の弾」はなく、内容的には至らないところも多くあるが、多少なりとも読者の参考になれば幸いである。


【内容紹介】

 事案  原告は、外国為替証拠金取引の取引用ソフトウェア上で動作するストラテジー(投資戦略)を自動実行する、本件プログラムを開発、販売していた。原告の元役員と取引関係にあったプログラマーである被告は、原告から本件プログラムの改修を依頼された際に開示されたソースコードを基に、取引結果を検証するための新プログラムを作成した。ただし、新プログラムは第三者には頒布されていない。
 原告は、被告による新プログラム作成は、原告の本件プログラムについての複製権・翻案権を侵害するものであるとして、不法行為に基づく損害賠償金2500万円(総額1億7000万円余の内金)を求めて提訴した。ここで被告は、「著作権法では、著作物たるプログラムの内容について、その構成とか、盛り込まれた機能を研究する行為については何ら規制されていない。また、コンピュータプログラムは技術の結晶であり、この点において特許法や半導体集積回路の回路配置に関する法律の対象と変わりはなく、研究・分析のためにリバース・エンジニアリングをすることは違法とは評価されない。そこで、複製物・翻案物を外部の第三者に譲渡したり、研究・評価のために必要な限度を超えて多数の複製物を作成するなどした場合を除いて、リバース・エンジニアリングは違法とならないものと解すべきである。」というリバース・エンジニアリングの抗弁を展開した。第一審では被告が勝訴したので、原告が控訴した。

 判旨  控訴審は、第一審と同様、被告による本件プログラムの複製・翻案の事実は認定した。しかし、被告によるリバース・エンジニアリングの抗弁そのものについての判断は控えながらも、原告自身が被告に本件プログラムのソースコードを開示したこと、新プログラムは本件プログラムに被告自身の別プログラムを取り入れることにより作成されたものであること、といった事情のほか、次のように述べて原告の請求を棄却した。すなわち、「被告プログラムは、各トレードごとの成績を個別に検証し、適切なパラメータを設定することによって、より多くの利益を獲得できるプログラムにする目的で作成したものであって、販売目的で作成されたものではなかったことが認められる。これらの事情を総合考慮すると、被告プログラムが本件プログラム1及び2の複製物、翻案物であると評価されたとしても、原告に財産的又は非財産的損害が発生したものということは到底できない。」と損害の発生を否定した。
 なお、実際の訴訟では新プログラムの頒布の点についても、原告の元役員が共同被告として訴えられているが、これは棄却されている(詳細は割愛)。

 コメント  他人の製品を解析するリバース・エンジニアリングは、特許法や半導体集積回路配置法のような技術の積上げが前提にある産業財産権の分野では認められています。これに対し、表現を保護する著作権法においては、もともと解析を要せずに表現を感得できるはずであることから、特にこれを認める規定はありません。ただ、プログラム(オブジェクトコード)については、技術の積上げという点で共通し、解析なしに技術を理解することは困難であることから、一定の(特に互換性確保のための)リバース・エンジニアリングについては、その解析過程に複製・翻案が介在したとしても、権利侵害と見るべきでないという見解が有力です。
 もっとも、本件ではリバース・エンジニアリングの抗弁が出されていたものの、問題となった行為は典型的なリバース・エンジニアリングとはかなり態様を異にするものでした。すなわち、「研究・分析のため」といっても、それは対象製品に化体された技術を理解するのではなく、別途のパラメータ検証のために対象製品を利用したものです。また、解析の過程で複製・翻案が介在したのではなく、検証プログラムを作成するために既に開示されているソースコードの複製・翻案を行ったというものです。
 おそらく、控訴審がリバース・エンジニアリングの抗弁に直接に応答せず、損害の発生がないことを理由にしたのは、以上のような事案の特殊性によるものと思われます。この理由付けからすれば、対象製品のリバース・エンジニアリングによって新製品を開発し、対象製品の市場を奪って損害を発生させたような場合は、侵害と認められる余地があることになります。もともとリバース・エンジニアリングは、その目的や態様に相当の幅があるものです。本件からは、裁判所はそれらに応じた個別的な判断を行う姿勢にあることが見て取れます。

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

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

 事案  レンタルサーバ・サービスを運営していたA社の担当者は、メールシステムの障害対策を行うため、同サービスで使用されていたサーバ群に対してメンテナンスを行うこととした。その際、メンテナンス用のプログラムに残っていた不要なコマンドを消し忘れていたが、そのコマンドが「対象外サーバ群のファイルを削除する」というものであったため、検証環境下での実行結果を対象サーバ群についてチェックしただけでは、不具合を発見することができなかった。その後、所定の手順を経ずに当該プログラムを本番実行したところ、対象外サーバ群のデータが全て消失した(第1事故)。
 A社はその翌日、第1事故によって消失したデータの回復を図るため、オープンソフトウェアである復元プログラムを導入することとした。同プログラムは、復元したデータに不整合を生じさせる可能性もあったが、A社は十分な技術的検証を経ないまま、本番環境で復元作業を実施し、復元されたデータをFTPで顧客に提供した。ところが、復元されたデータには本来はアクセス権限のない他の顧客のデータが含まれる可能性のあることが判明したため、A社は顧客に対し、ダウンロードしたデータを削除するよう依頼するに至った(第2事故)。

 判断内容  第1事故については、A社担当者がシステム変更の際に従うべき社内マニュアルに従わずに独自方式でメンテナンスを(約10年前から)行っていたこと、不具合のあるプログラムを上司の許可を得ないまま本番環境の全サーバーで実行したこと等を前提に、「軽過失の枠内ではあるものの、比較的重度の過失であった」とされた。
 第2事故については、複数の役職員で回復の検討を行ったものの復元したデータに他の顧客のデータが混在する可能性を見逃したこと、データが消失した場合を想定したのマニュアルの作成や従業員に対する教育を行っていなかったこと等を前提に、やはり「軽過失の枠内ではあるものの、その過失の程度は比較的重度のものである」とされた。
 各事件に対してA社が策定した再発防止策については、いずれも「根本原因に対応したいずれも具体的かつ現実的な内容であり、これらの予防策が実施され、機能した場合には、今回発生した第1/第2事故を防ぐことができる内容」であり、「適切なものと評価することができる」とされた。

 コメント  この事件は訴訟になったものではなく、A社自らが事故の原因調査や再発防止策の策定のために第三者調査委員会を設置し、その活動結果として調査報告書が出された、というものです。もちろん、訴訟となれば、A社の過失は免れませんし、軽過失免責の規約があったとしても、IT専門家としての高い注意義務を前提に、調査報告書より踏み込んで重過失認定がなされていたかも知れません。もっとも、最終的にA社に法的責任が発生するかどうかは、契約上のそもそもの義務の内容や範囲にもよるわけですが。
 調査報告書(公開されたのは要約版のみ)では再発防止策にもかなりのスペースが割かれており、その内容は「適切」という評価なのですが、厳しく言えば問題点もあります。この事故自体は数年前のもので、その後に一定の改善等が進められた(はず)という事実は別にあるわけですが、他山の石ということで当時の調査報告書の記載だけから見てみます。
 第1事故の分については、組織や管理が杜撰だったという反省からの抜本対策ということで、「開発・運用プロセスの見直し」、「牽制(開発・運用)を含めた体制の確立」、「システム変更業務の運用移管と分掌管理」と徹底されています。しかし、内部統制(IT統制)でもセキュリティの第三者認証でも、この種の対策が実効性を伴わない「膨大な管理プロセスの山」に終わることは少なくありません。調査報告書が、いみじくも「機能した場合には」としているとおりです。他方で、喫緊の課題であるはずの「2次バックアップの取得」が「順次実現性を検討」と一部が後回しにされています。対象データと同種のリスクに晒されている同一筐体内のコピーでは、データ保全の最後の砦として不十分なのは明らかです。未然防止が重要なのは当然ですが、(考えたくない、目をつぶりたい)「事故が起きてしまった場合の対策」こそ真剣に考えなければならないのは、原発事故対策などと同様です。
 第2事故の分については、今回のデータ消失のような「事前に想定していない事象が発生した」場合の対策の一つとして、「リスクマネジメント委員会」を設置するとあります。おそらく、この委員会も抜本対策の一環なのでしょうが、いざという時に「委員会」という管理組織がどのように役に立つのか、疑問がないわけではありません。第2事故の場面のような、先行する事故への対応が急がれる場合、焦りから被害を更に拡大させたり、別の被害を生じさせたりすることが最も危惧されるリスクです。今回も、検討の際にわずかでも技術面からの注意が働いていれば、データの物理的な復元イコール障害回復、という発想にはならなかったはずです。火事場で役に立つのは、組織でもマニュアルでもなく、機に応じた判断力です。再発防止策の中には、「対策本部」や「社員教育」といった言葉もあるのですが、言うは易く行うは難し、相当の覚悟(時間、コスト、労力)を持って取り組むことが不可欠です。

 明治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字モデルの実務上の意義はこのようなことになるでしょう。また、契約問題を議論する際に、対になる工程間には必ずしも一義的な対応関係があるわけではない、ということも確認されるべきでしょう。

 事案  石材の加工販売業者である被告は、旧システムの老朽化に対応するめ、外部コンサルの作成した概要提案書を基に、販売管理を始めとする全社システムの構築をITベンダである原告に委託した。ところが、システムの開発作業の過程で、開発を要する機能及び工数が増加することが判明し、稼働の期限直前になっても、進捗は全体の4分の1程度にとどまっていた。そこで、稼働時期の見直しのうえ、一部納品された部分につき並行稼働によるテストが行われたが、被告からは機能を見直さないと通常業務で使用できないとの指摘がなされる状態であった。その後、機能の見直しや再度の稼働延期を経て、再納品に対する検収の後、ようやく並行稼働、本稼働へと進んだ。しかし、被告は本稼働後も多数の不具合、特にシステムの処理速度の遅さが著しいとして、原告に補修を求めるなどしていたが、結局、システムの継続使用を断念した。これに対して、原告は残代金1億1千万円余の支払いを求めて提訴した。
 原告の代金請求(その一部は増加した作業に対する追加・変更分)に対して、被告はシステムには実際の使用に耐えられない多くの瑕疵があるから完成していない、仮に完成しているとしても、原告が瑕疵を補修しないことを理由に契約を解除したのだから代金の支払義務はないとして争った(なお、被告は既払金につき反訴提起している)。

 判旨  判決は、変更契約のうち一つを除いて、開発や交渉の経緯、書面の不存在を理由に、追加・変更の各契約の成立は認められないとした。そのうえで、システムの完成について、「請負人が仕事を完成させたか否かについては、仕事が当初の請負契約で予定していた最後の工程まで終えているか否かを基準として判断すべきであり、注文者は、請負人が仕事の最後の工程まで終え目的物を引き渡したときには、単に、仕事の目的物に瑕疵があるというだけの理由で請負代金の支払を拒むことはできない」としてうえで、予定されていた〈1〉要件定義、概要設計から〈9〉データ移行までの各工程を終了し、順次納品を行い、「同9年10月から、本件システムを本格稼働させ、同10年10月ころまで使用を継続していることが認められる。以上によれば、原告は、本件システムを完成させたと認めるのが相当」と判断した。
 他方、このように一応完成したシステムには、「処理速度が被告の通常業務に耐えられないこと及び処理速度が遅いために通信費用が増加しているとの瑕疵」があり、原告がその修補を請求したのに被告はこれを行っておらず、また、これは契約の目的を達成することのできない瑕疵であり、その原因が被告にあるともいえないから、被告のした解除は有効であるとして、原告の代金請求は棄却した。

 コメント  本件はシステム開発に係るIT紛争の典型論点の多くを含んでおり、不具合(瑕疵)の扱いについても言及されていますが、システムの完成如何の点に絞ります。
 判旨は、システム開発が請負契約であることを前提に、仕事の完成如何について、建築請負についてはほぼ確立した「最終工程基準」を適用しています。この基準は、不具合の存するシステムが出来上がってしまったときに、そもそも未完成であって代金支払義務が発生しないのか、それとも一応は完成であって瑕疵担保責任(解除や損害賠償)の問題が残るに過ぎないのかについて、「やっていない」ところが残っている場合には前者で、「全部やったが不十分」なところが残っているに過ぎない場合には後者に当たるとするもので、抽象的な基準としては明快ではあります。しかし、実際には、どこまで有用な基準たり得ているかは、疑問があります。
 まず、何をもって「全部やった」かどうかを判断するかです。この基準が「最後の工程まで終えているか否か」とする意味は、もちろん、設計が抜けても製造が抜けてもテストが抜けてもどこかのドキュメントだけ抜けても未完成となる理屈ですが、特に最後のテスト工程は、どの程度やれば「全部やった」ことになるのか難しいところがあります。およそテストらしいことを何もやっていないことは稀でしょうが、申し訳程度に画面を叩いただけでは足りないことは明らかです。その中間で、テストが粗い場合にどう判断するかは、別の基準が必要でしょう。そして、テストの精粗の度合いは、システムの品質という実質論に直結します。建築の場合、配管や塗装の粗雑さは当該箇所の瑕疵として修補すれば足りるとしても、テストの粗雑さはシステムのどこにどのような問題を発生させるか分からず、形式論のみでは実態にそぐわない虞があるのです。
 また、単体テスト、結合テスト、システムテスト、運用テストとあった場合に、最終工程としてどこまで行えば足りるのか、契約の範囲として明定されていれば良いですが、工程感のはっきりしない一括請負であると判断に迷います。完全な一括請負であれば全テスト完了までなのでしょうが、システムテストや運用テストが請負から外れていた場合、請負人の完成義務をシステムそのものに対するものと捉えるか、各工程毎に限られると捉えるかによって、結論は異なってきます。この関係で、請負範囲から要件定義が外れていたり、準委任となっていたりした場合も、一考を要します。この場合、請負の始まりである外部設計といわゆるV字モデルで対応するシステムテストまでとする見解がありますが、V字モデル上どの設計工程がどのテスト工程に対応するかは、一義的に決まっているものではありません。
 そもそも、この最終工程基準は、「最終工程まで一応完了していれば完成で、そうでなければ未完成」と理解すべきでないようにも思われます。この基準の走りである東京高判昭36.12.20は、「工事が途中で廃せられ予定された最後の工程を終えない場合は工事の未完成に当るものでそれ自体は仕事の目的物のかしには該当せず、工事が予定された最後の工程まで一応終了し、ただそれが不完全なため補修を加えなければ完全なものとはならないという場合には仕事は完成したが仕事の目的物にかしがあるときに該当する」としており、逆に言えば「補修を加えれば完全なものになる」ことを前提としているとも読めます。仕事の完成が求められる請負における瑕疵は、本来的には債務不履行の一種ですから、修補によって仕事が完全化する可能性のない場合に完成を認めることは理論的に困難と思われます。その意味で、工程を欠いていれば未完成ということはできても、工程を踏んでいるから直ちに完成、とは言いにくい基準です。ここは実質的な基準で補充する必要がありそうです。
 もう一つ、高裁判決で問題になっている未完成部分は、「(イ)一階四畳半の部屋の前の檜縁張替部分のラツカー塗装、(ロ)同じ部屋の欄間の硝子のはめ込み、(ハ)一階洋間(応接室)のマントルピースの上の飾板の塗装、(二)同じ洋間の螢光灯箱のすり硝子のはめ込み、(ホ)一階廊下の床板巾一尺一寸長さ一間半のラツカー塗装、(へ)二階廊下のラツカー塗装、(ト)階段のラツカー塗装等」というものであり、これは工程というよりアクティビティに近いものです。そうだとすると、工程論だけで完成が認められるのは、稀有のことになってしまいそうです。そもそも、建築の場合であれば、なすべき工程の全体像は(事後的であっても)明らかにできそうに思われますが、システム開発の場合は、事前に詳細なWBSでも作られていたような場合を除いて、上記のレベルで明らかにするのは困難です。
 なお、本件は検収後本稼働まで行った事案であるため、一応完成の認定もかなりあっさり行われており、上記のような点がどのように扱われているか、別途の基準が必要かどうかなど、特に参考になる判断はなされていません。検収と完成との関係も、弁護士として実務でしばしば見聞するところですが、これは別稿に譲ります。