法とITの話

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

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

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



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

 システム開発工程に関する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でも作られていたような場合を除いて、上記のレベルで明らかにするのは困難です。
 なお、本件は検収後本稼働まで行った事案であるため、一応完成の認定もかなりあっさり行われており、上記のような点がどのように扱われているか、別途の基準が必要かどうかなど、特に参考になる判断はなされていません。検収と完成との関係も、弁護士として実務でしばしば見聞するところですが、これは別稿に譲ります。

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

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

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

 事案  司法試験予備校である被告は、その校舎において、多数のコンピュータに正規のライセンスを得ていないパッケージ・プログラムがインストールされていたとして、その開発・販売元である原告(アドビ、マイクロソフト、アップル)からプログラムの使用差止、消去及び9500万円余(弁護士費用分を除く)の損害賠償の請求を受けた。
 提訴前の証拠保全手続により、対象とされた校舎にある219台のコンピュータのうち、検証が実施された136台については、無許諾のプログラム複製の事実が確認されている。この状況で、主に損害賠償額の算定につき、原告は、違法複製者に対する事後的な許諾料(相当の損害賠償額)は正規品の販売価格の2倍以上である、被告はプログラムの無断複製が発覚した後に、これらをすべて抹消し、新たに正規品を購入したから損害はない、として争った。

 判旨  原告の請求のうち、差止については、既に適法なプログラムに置き換えられたことから、理由なしとされた。
 損害賠償については、原告の主張を「本件全証拠によるも、そのような事実を認めることはできない。」と否定する一方で、被告の主張についても、「被告の原告らに対する著作権侵害行為(不法行為)は、被告が本件プログラムをインストールして複製したことによって成立し、これにより、被告は、本件プログラムの複製品の使用を中止すべき不作為義務を負うとともに、上記著作権侵害行為によって、原告らに与えた損害を賠償すべき義務を負う。そして、本件のように、顧客が正規品に示された販売代金を支払い、正規品を購入することによって、プログラムの正規複製品をインストールして複製した上、それを使用することができる地位を獲得する契約態様が採用されている場合においては、原告らの受けた損害額は、著作権法114条1項又は2項により、正規品小売価格と同額と解するのが最も妥当であることは前記のとおりである。その意味で、本件においては、原告らの受けた損害額は、被告が本件プログラムを違法に複製した時点において、既に確定しているとみるのが相当である。」として、事後的な損害の消滅を否定し、結局、「無許諾複製したプログラムの数に正規品1個当たりの小売価格を乗じた額」に136分の219を乗じた額である7700万円余(弁護士費用分を除く)を損害賠償額として認めた。

 コメント  日本では米国におけるような(原告は3社とも米国企業ですが)懲罰的損害賠償が認められていないこともあり、原告の主張はあっさり退けられています。原告は、ソフトウェア業界では正規の場合と違法な場合とでは価格格差があるというニュアンスの主張をしていますが、実際にそのような価格体系があるわけではなく、仮に倍額とする例があったとしても懲罰的賠償が裁判外で実現されただけ、と言えます。倍額賠償は、現行著作権法の草案にあったものの実現はしておらず、仮に一定の合理性があるとしても将来の立法課題でしょう。
 興味深いのは、被告の主張です。判決では、結果的に二重払いのようになり、遵法精神に目覚めて(?)正規品を購入した被告に酷なようにも見えるからです。しかし、判旨にもあるとおり、違法行為を起こした時点で損害賠償義務は確定し、事後に正規品を購入したからといって、遡って過去の損害賠償義務に影響を及ぼすわけではありません。損害賠償は過去分、正規品の購入は将来分、法的にはこの結論はやむを得ないと思われます。この点、被告は「ペイド・アップ方式によるシュリンク・ラップ使用許諾契約においては、同一プログラムの使用対価は一回払えば、永久且つ無制限に使用できるのであるから、その過去の使用分も遡及してカバーすると解すべき」との主張もしていますが、論理としては逆でしょう。結果的に二重払いになってしまったのは、むしろ「永久且つ無制限に使用」が途中で分断された結果です。もし、ASPのような期間課金であれば、過去分はその期間分の損害賠償、将来分はその期間分の利用料となって、二重払いにはならなかったはずです。うっかり購入したパッケージを紛失してしまって(事実として手元になくなったパッケージを回復するために)二回目を払うのと同様、違法行為が発覚して(法的に利用継続が許されないパッケージを適法に回復するために)二回目を支払うだけ、ということです。結果論ですが、このような二重払いは、賠償単価が卸売価格でも市場実勢価格でもなく定価と認められたことと相俟って、原告が求めた実質的なペナルティの意味を持ったと言えるかも知れません。
 なお、判決では、問題の校舎以外での無断複製は「使用目的、使用状況が異なると考えられる」として推認を否定しましたが、問題の校舎については、「西校校舎内における各コンピュータの使用態様は、本件検証の対象とされた136台と対象とされなかった83台との間で相違がないものと解するのが合理的」として推認を認めました。著作権侵害による損害においては、いわゆる”暗数”の存在(懲罰的賠償の根拠の一つとして挙げられることもあります)をどのように評価するかが問題となりますが、一つの参考になると思われます。

 事案  貨物運送業を営む原告は、輸出入・販売を行う商社である被告との間で、運送システム等の開発委託契約を締結した。開発そのものは、被告から別のシステムベンダ(訴訟で補助参加人となっている。)に再委託され、システムは原告の検収(どの程度の確認が行われたのかは不明であるが)も終えてテスト稼働に入っていたが、本稼働には至っていなかった。その後、原告はシステムに月次更新の処理遅延や運賃修正の計上漏れなど、大小合わせて60項目を超える不具合があるとして契約を解除し、支払済みの代金等2億7000万円余を損害賠償請求した。
 主な争点は、原告が主張する不具合の存否と、それがプログラムの欠陥(瑕疵)と評価できるか否かである。

 判旨  訴訟では、原告と補助参加人が中心となり、本件システムの検証実験が二年余にわたって行われ、稼働上の問題点とその解決方法についての認識の一致を見た(このような経緯自体、非常に特異であるが)。
 それを前提として、原告が主張する不具合はそもそも存在しないか、存在するとしても、「コンピューターソフトのプログラムには右のとおりバグが存在することがありうるものであるから、コンピューターシステムの構築後検収を終え、本稼働態勢となった後に、プログラムにいわゆるバグがあることが発見された場合においても、プログラム納入者が不具合発生の指摘を受けた後、遅滞なく補修を終え、又はユーザーと協議の上相当と認める代替措置を講じたときは、右バグの存在をもってプログラムの欠陥(瑕疵)と評価することはできないものというべきである。これに対して、バグといえども、システムの機能に軽微とはいえない支障を生じさせる上、遅滞なく補修することができないものであり、又はその数が著しく多く、しかも順次発現してシステムの稼働に支障が生じるような場合には、プログラムに欠陥(瑕疵)があるものといわなければならない。」という観点からすれば、プログラムの欠陥とは評価できないとして、原告の請求は棄却された。

 コメント  プログラムのバグの法的扱いについて言及した、良く引き合いに出される裁判例です。一言で言ってしまえば、「プログラムにバグはつきものであるから、バグであっても法律上免責される場合がある」というもので、そのこと自体に余り異論はないものと思われます。
 ただ、判旨だけ見ると、バグを債務不履行の問題として捉えているのか、瑕疵の問題として捉えているのか、いま一つ判然としないところがあります。原告は「本件システムのプログラムの完成不能」と履行不能を主張しているようですし、裁判所も併合されている別事件についての結論部分では「前記二のとおり、本件システムに不具合が存在することは被告の債務不履行とはいえず」と債務不履行に言及しています。にもかかわらず、良く引用される上記の判旨部分では「欠陥(瑕疵)」という言い方をしています。考えられるのは、本件での解除事由は債務不履行であるが、(一般論としての)規範定立の部分では債務不履行を導く「欠陥」と「瑕疵」を(法律上の責任原因という意味で)特に区別しなかったということですが、(瑕疵は債務不履行の一場合であるとはいえ)両者は要件も効果もはっきりと別物ですから、同じ切り分け基準が妥当するというのも変です。
 実際、「構築後検収を終え、本稼働態勢となった」ことは通常、システムの完成(債務の履行)を窺わせる有力な事情ですから、むしろ瑕疵について判断しているようでもあります。また、「不具合発生の指摘を受けた後」との限定は、ベンダの側に積極的なバグの探知義務はないことを意味していますが、この義務は要するに「テストの義務」ですから、システム完成後の瑕疵の問題でないと話が合いません。完成前であれば、指摘を受けないバグについても当然に潰す義務があると言うべきです。
 さらに言えば、前段の既に対応済みである状況と、後段の稼働に支障がある状況との間には、随分と開きがあります。「遅滞なく補修を終え、又はユーザーと協議の上相当と認める代替措置を講じたとき」とは、要するにバグは既に適切に対応済みということですから、瑕疵を問題にすべき場合でもありません。これに対して、「バグといえども、システムの機能に軽微とはいえない支障を生じさせる上、遅滞なく補修することができないものであり、又はその数が著しく多く、しかも順次発現してシステムの稼働に支障が生じるような場合」という状況は、多数の潜在バグの存在とテスト工程での何らかの「欠缺」を窺わせるもので、こちらは未完成レベルと言えそうです。特に、判決に至るまでには、検収後にトラブルが生じ、その対応があり、これが紛争化して交渉があり、訴訟提起して延々と争う、とこの間で最低でも2~3年は経過しているわけですから、もし、これだけの時間が経過してもなお、後段のような状況にあるのであれば、そのシステムは完成不能と言うほかありません。前段と後段の狭間に落ちるようなケース、例えば重大な支障を生じさせるほどではないが、遅滞なく補修されなかったり数が多かったりするような場合は、ひとまず瑕疵と評価し、しかし解除や損害賠償の効果は限定するくらいが妥当でしょうか。
 各当事者の主張も見ればもう少し明確になるのでしょうが、やや消化不良の感が残ります。

 東証対みずほ証券の判決で、結論への影響は必ずしも大きくありませんが、IT紛争の観点からは興味深い情報システム関係の論点を拾ってみました。

1.本稼働の判定について
 判決では、直近の総合テストでの障害数が1回最大5件で、ゼロの日もあったことに基づいて本稼働日を決定したことについて、「上記の判断は、被告売買システムにおいて検出される不具合件数が収束に近づいたとの判断に基づくものであって、これが一切の瑕疵(バグ)を内包しない完全無欠なものであることの判断を前提としたものではなかった。」としています。判決がこれ自体を(重)過失と見ているのか、必ずしも判然としないところはありますが、このような判定方法はシステム開発における通常の実務ではないか、という批判もあるようです。
 この点、情報システムが「一切の瑕疵(バグ)を内包しない完全無欠なもの」でないことはもとより当然で、「検出される不具合件数が収束に近づいた」ことに基づく判断もそれ自体は妥当と言うべきですが、不具合件数の具体的な収束状況が本稼働移行に相応しいレベルであったのか、また、判断要素として不具合件数の収束状況だけで足りるかどうかは別問題です(この辺りは、判決はどう考えたのか、そもそも事実関係はどうなのか、判旨からは良く分かりません。)。特に、本件売買システムは、重要な社会インフラを構成するものですから、本稼働の判定も、より慎重なものが求められると言うべきです。

2.回帰テストについて
 東証が回帰テストの確認を怠ったことは、重過失は一応否定されながらも、東証の過失と認定されています。これはあくまでみずほ証券との関係で、売買システムの提供者として(開発段階で)なすべきことをなしたか、という意味の責任です。システム開発委託契約のベンダ対ユーザの責任関係で言えば、「一次的に回帰テストを行うべきなのは(ベンダである)富士通」であるのは当然で、主たる責任もベンダにあると言うべきですが。
 ところで、東証にこのような責任が認められたのは、「業務について精通する立場にある」という能力を前提に、ベンダとの間で発注者としてここまでは作業を分担すると取り決めた以上(ベンダが当該作業を「補完」してくれることはなくなる)、適正な売買システムを第三者に提供するためには当該分担を全うしなければならず、それを怠れば第三者との関係でも義務違反を構成する、という理屈です。しかし、仮にそのような義務違反がなかった場合を考えると、不具合のあるシステムを提供しておきながら、(他の義務違反もないとした場合に、免責約款が無くても)免責が認められることになり、いかにも座りが悪いところです。判決は、東証の義務を「市場システムの提供」と広く捉えているため、富士通を履行補助者とは考えていませんから、みずほ証券としては、東証を飛び越えて富士通の不法行為責任を追及するしかなくなってしまいます。ASP事業者は、開発を他ベンダに任せると(そして、任せれば任せるほど)、リスクヘッジができるという帰結にもなりますが、情報システムは「土地の工作物」(みずほ証券は過失相殺の文脈ですが、このような主張もしています。)ではないので、仕方がないということでしょうか。
 なお、回帰テストについての東証の義務違反を問題にするとした場合、「本件不具合の発見の容易性」以前に、富士通が(いかにもデグレードをおこしそうな修正に際し)そもそも回帰テストを行っていなかったことを見逃したのだとしたら、重過失認定もあり得るところです。ただ、本件の不具合は「一部約定対象注文(みなし処理がなされる注文で、かつ、特別気配表示時に逆転気配を生じさせる注文)を被取消注文とする取消注文が、逆転気配の付合せが終了した後に入力された場合」という特殊な条件の際にのみ起こることから、そのようなケースは回帰テストにも通常含まれず、従って、結果回避可能性がなかった、という逆の可能性もあります。富士通との関係であれば、たとえそのような場合でも無過失の瑕疵担保責任を問うことができますが、過失責任であれば否定せざるを得ません。とすると、やはり(みずほ証券は、良くも悪くもまったく与り知らぬ)東証の発注者としての落ち度(のみ)を問題とすることで良いのか、疑問は消えません。

3.取消注文の要件定義について
 判決は、「要件定義の目的の一つとして、業務上の要求を明確に伝えることがある」とこれをユーザの責任としており、それはまったくそのとおりですが、売買システムにおける取消機能、それも、どのようなタイミングや条件でどのような範囲の取消が可能か、といったことではなく、「約定するまでの間は原則として注文の取り消せるものとする」といったまったくの常識に属するレベルのことまでそうなのかは、一考を要します。
 ベンダ対ユーザの仕様を巡る争いの場面では、ユーザの不満の多くは、ベンダが「業務の常識さえも理解しない」(もっとも、自社の方式しか知らないユーザが、自社の方式を世間一般の常識であると誤解しているケースもありますが)ことに起因するのです。要件定義であっても、ベンダとユーザの間には、(それがいかにユーザ寄りであるとしても)一応の責任分界点があると理解すべきです。
 もっとも、結論として東証に義務違反はないというのですから、「一応検討はしました」というだけで、本件ではさほど重視すべきところではないかも知れません。そもそも、仮に東証が取消機能について要求を伝えていなかったとしても、それが故に今回起こったような形での取消機能の一部不全(明らかにバグ類型です。)に至った、とは到底言えるものではありません。