バグがあっても大丈夫!? 〜損害賠償請求ってできるの ?

今回は、私どもの様に、ITに関わる人間にとっては、死活問題となる「ソフトウェアへの損害賠償請求」に関する、現在の状況を紹介したいと思います。

「ウチはIT企業じゃないから関係無い !」と思われる方が多いと思いますが、それでも、何らかのソフトウェアは使っていますよね ?

そのソフトウェアにバグがあり、バグの影響で、業務に支障をきたした場合、「ソフトウェア開発/販売元に、損害賠償の請求が出来るのか ? 」と言うのは、結構重要な問題だと思います。

また、ソフトウェアに対する損害賠償は、使用中のソフトウェアに対するものばかりではありません。

例えば、あるIT企業に、システム開発を依頼したとします。ところが、この会社からは、何時まで経ってもシステムが納品されません。

何度も催促した所、ようやくシステムが納品されましたが・・・いざ社内で納品されたシステムの動作確認試験を行ってみると、バグばかりで全く動きません。

このような場合、システムが当初の要求通りに動かないので、納品物の受け取りを拒否し、かつ費用の支払も拒否出来るのでしょうか ?

また、システム開発に付随して、御社の担当者は、該当IT企業のために、数々の作業を行って来たと思いますが、全てが徒労に終わってしまいました。

そこで、この担当者の無駄に終わってしまった作業に関して、システムの開発元企業に、損害賠償を行いたいと考えますが、果たして損害賠償請求は行えるのでしょうか？

今回のブログでは、「バグがあっても大丈夫!? 〜損害賠償請求ってできるの ? 」と題して、ソフトウェア(プログラム)にバグがあった場合、開発元/販売元に損害賠償請求が出来るのか、と言う点について、少し検証してみたいと思います。

●ソフトウェア(プログラム)のバグとは
●瑕疵と債務不履行の違い
●免責条項と重過失の立証
●訴訟事例の紹介
●最後に

それでは今回も宜しくお願いします。

- - - - -

■ソフトウェア(プログラム)のバグとは

ソフトウェア(プログラム)とは、プログラミング言語と呼ばれる、コンピュータに理解できる人工言語で記述されており、コンピュータは、このプログラミング言語で指示された内容に従って動作するものとなっています。

従って、プログラミング言語に間違いが無ければ、プログラムは、常に正しい動作をする決まりになっています。

しかし !! このプログラミング言語を記述するのは人間です。映画の様に、コンピュータが、自らプログラムを作成するのは、まだまだ何十年も先の話です。

そして、プログラムは、非常に繊細です。プログラミング言語を、1箇所間違えただけで、想定外の処理を行ってしまいます。

例えば、本来、計算結果に「10を加算」すべき処理で、間違えて「10を乗算」してしまったとします。この加算/乗算と言うプログラミングは、たった1行の処理になりますが、これだけで処理結果は、大幅に狂ってしまいます。

本当は、プログラミング言語によって、加算/乗算の指示方法は異なるのですが、ここでは便宜上、普通の計算式を記載しますが、下記の様に「＋」と「×」の1箇所を間違えただけで、とんでも無いことが起こります。

●正しい記述：計算結果「A」＋ 10
●間違った記述：計算結果「A」 × 10

一方、人間は、必ず間違いを犯します。このため、人間が作成したプログラムにも、必ず、絶対、間違いなく記述ミスが存在します。

そして、このプログラミングの記述ミスの事を「バグ(Bug)」と呼ぶのが、IT業界では、昔からの決まりとなっています。

しかし、これはIT業界に限った話ではなく、コンピュータが、この世に現れる以前から、「バグ」と言う言葉は使われていたようです。

例えば・・・

●シェイクスピアは、戯曲「ヘンリー四世」で、忌まわしい物を「バグ」と呼んでいた
●エジソンは、機械の不具合を「バグ」と呼んでいた
●第二次世界大戦中のレーダー技師の間では、レーダー故障を「バグ」と呼んでいた

このように、コンピュータが現れる前から「バグ」と言う言葉が使われていたようですが、コンピュータが世の中に出回り始めてからは、プログラミングのミスを「バグ」と呼ぶように固定化されてしまったようです。

また、このミスは、1箇所だけと言うことはなく、通常、何箇所も存在します。特に、規模が大きいプログラムには、何十、何百と言うバグが潜んでいます。

皆さん、このブログを見ていると言うことは、「Windows OS」を使っていると思いますが、毎月第二水曜日に「Windows Update」なる物が実行されていることはご存知ですか ?

この「Windows Update」こそが、プログラムの塊である「Windows OS」のバグを修正するためツールになります。

そして、そのバグの数たるや・・・凄いことになってしまっています。

昔、「Windows XP」の時代は、1ヶ月位「Windows Update」を実行しなくても、それほどバグは溜りませんでしたが、現在では、1ヶ月も「Windows Update」を実行しないと、とんでも無いことになってしまいます。

平気で20〜30個のバグ対応が溜まってしまいます。

そして、このバグ修正関しても、作業が終わり、Windowsを終了しようとすると、「コンピュータの電源を切らないで下さい。」と言うメッセージが表示され、勝手に「Windows Update」が始まってしまいます。

どうしてMicrosoftは相手の事など考えずに・・・・

この話は、また別の機会に紹介したいと思いますが、このように、Microsoftの様に、全世界で、何十億と言う人間が使用しているプログラムにさえ、何百、何千と言うバグが存在しています。

Windowsの他にも、コンピュータのOSと呼ばれているものIBM z/OS、Unix、Linux、そしてiOS・・・全てのプログラムにもバグは存在します。

もちろん、本当は有ってはいけないのですが、弊社が作成したシステムにもバグは存在します。

いかがでしょうか ? ここまで説明してきた様に、ソフトウェア(プログラム)とバグとは、恐らく、永遠に切っても切れない仲になってしまっていると思います。

しかし、私達、プログラム開発に携わる者も、漫然とバグを作っているだけではありません。作成したシステムに対しては試験を行い、軽微なバグに関しては、全て潰してから納品するようにしています。

このバグを探しだして無くす行為を「Debug(デバッグ)」と言うのですが、日々、バグを無くすよう努力は続けております。

ちなみに、「Bug(バグ)」は、英語で『虫』を意味しています。

私が、新入社員の時の研修では、「バグ」に関しては、次のように習いました。

『プログラムには、バグと呼ばれる不具合が存在する。何故【バグ】と呼ばれるのかといえば、この不具合の存在状況が、虫が葉っぱを喰い荒らしている状態の様だから【バグ】と呼ばれている。』

しかし、実際には、前述の様に、コンピュータ出現以前から使われていた言葉のようです。

- - - - -

■瑕疵と債務不履行

さて次は、少し難解な話ですが、ソフトウェア(プログラム)における「瑕疵」と「債務不履行」について説明したいと思います。

と言っても、私は法律家ではありませんし、加えて、「瑕疵」と「債務不履行」は、その違いを簡単に説明できないほど難しいものとなっているようです。

ですが、便宜上、本ブログでは「瑕疵」と「債務不履行」とは、次のように定義します。

瑕疵：瑕疵担保責任(民法570条)とは、納品物に、瑕疵(本来の備えるべき品質を備えていない)があれば売主は一定の責任を負う。時効は瑕疵発見後1年間。
債務不履行：債務不履行責任とは、約束を守ることができなかったこと。履行不能(仕様未達成)、履行遅滞(納期遅延）等。時効は10年間。

さて、前述のソフトウェア(プログラム)の「バグ」ですが、これを法的な文章で取り扱う場合、「瑕疵」と「債務不履行」のどちらになると思いますか ?

本来備えているべき品質を備えていないのが「バグ」のような気がしますので、「バグ」は瑕疵のような気がしますし、仕様を満足させることが出来ない事が債務不履行であるなら、「バグ」は債務不履行の様な・・・

全く、法律用語と言うのは、物事の定義を、わざと難しくして、自分達の存在価値を世間に認めさせようとしているとしか思えません。

と言うことですが、「バグ」は法的文書では、「瑕疵」になるそうです。

それで、「バグ」が、「瑕疵」になるのか「債務不履行」に成るのかで、何が違うのかと言うと・・・損害賠償の適用方法、および適用範囲が大きく異なるからです。

また、「瑕疵」の場合、契約書に記載が無い場合、「バグ」発見から1年を過ぎると損害賠償の時効になってしまいますが、「債務不履行」の場合、時効までは10年間もあります。

基本的に、「バグ」が「瑕疵」となった場合、「バグ」の修正が優先されるので、損害賠償は認められませんし、万が一、損害賠償が認められた場合でも、その範囲は、信頼利益(瑕疵がないと信じて契約したがために被った損失)分の損害賠償請求しか出来ません。

そして、この信頼利益分への損害賠償ですが・・・ほとんど何もありません。契約に関わる費用で、本来は支払う必要が無いにも関わらず、支払ってしまった費用を弁済するだけになると思います。

また、「バグ」は修正可能とされるので、契約解除も出来ません。

一方、「バグ」が「債務不履行」と認定された場合でも、(現行の裁判では、バグが債務不履行と認定された事例は余り見受けられないようですが)、契約解除については、開発業者に対して相当の期間を定めて催告し、これに対して開発業者が、その期間内にプログラムの修補、もしくは代物提供をした場合には、契約解除は出来ないとされています。

さらに損害賠償についても、ソフトウェア(プログラム)は、前述のように修正プログラム等で修正することが容易であるという特徴があるので、この状態において開発業者の修補対策を拒んで損害賠償請求を行うことは信義則上も認められないことになっています。

さらに、民法第415条の規定から、修補請求、もしくは代物請求が可能となっていますので、「バグ」の債務不履行責任については、開発業者への修補請求、もしくは代物請求が優先されることになります。

ここまでの説明を読むと、ソフトウェア(プログラム)は、その特徴から、法律上、かなり保護されているように見受けられますが、まさに、その通りだと思います。

つまり、「バグがあるプログラムを作って納品しても開発業者は大丈夫」と言う、何とも納得が行かない結論になってしまったようです。

しかし、法律上保護された形になっている、とは言っても、それだけでは企業は永続できません。通常、このような企業に、開発を依頼するとは思えません。

大手IT企業は別ですが・・・私どものような中小零細のIT企業では、そもそも裁判になった時点で、経営が立ち行かなくなります。

いくら、法律で保護されていると言っても、私どもには全然関係ありません。いつもと変わらず、バグの少ないソフトウェア(プログラム)を作るだけです。

しかし、それでは、どのようなケースで、ソフトウェア(プログラム)が債務不履行になるのでしょうか ?

次に、ソフトウェア(プログラム)が債務不履行になる可能性のある項目について説明したいと思います。

- - - - -

■免責条項と重過失の立証

前章にて、ソフトウェア(プログラム)の「バグ」は、ほとんどの場合において「瑕疵」扱いになると説明しましたが、これは、あくまでも「企業対企業」の場合です。

これが「対個人」、一般消費者相手となると話は全く異なりますので、その点は注意が必要です。

ちなみに、「対個人」の場合、例えば、家電に内蔵されたソフトウェアのバグが原因で、利用者が怪我や火災等の被害を被った場合、この場合には「製造物責任法(PL法)」に基づき、メーカーが損害賠償責任を負うことになります。

ところが、「企業対企業」の場合、通常は、契約に「免責条項」を含めますし、ソフトウェア(プログラム)やITサービス単体での損害に関しては、PL法は適用されませんので、損害賠償を行うのは難しい物があります。

「企業対企業」の契約の場合、契約当事者である企業は、その契約に伴うリスク等を、十分に把握した上で契約を行っているとみなされるために、この「免責条項」が、法律上も有効とみなされるからです。

そして、本章で問題とするのが、この「免責条項」です。

通常、「免責条項」には、「故意、または重過失がある場合を除き、損害賠償は行わない。」と言う一文が加えられます。

私どもソフトウェア開発会社は、悪意のあるハッカーではありませんので、ソフトウェア(プログラム)に、故意に「バグ」を組み込もうとは思いません。

まあ、中国資本のソフトウェア会社や某PCメーカー(※1)では、自身が開発/販売するソフトウェアに、悪意のあるソフトウェア(プログラム)を仕込んでいることが明らかになった例もありますが・・・一般常識のある日本企業では、そのような行為を行うことは無いと思います。

それでは、何をもって「重過失」となるのでしょうか？

ソフトウェア(プログラム)の「バグ」が原因で発生した損害に対して、何らかの損害賠償を行おうとした場合には、損害賠償を訴える側が、ソフトウェア開発元に、「重過失」があることを立証しなければなりません。

しかし、「バグ」を「重過失」と立証するためのハードルは非常に高いそうです。

「バグ」を「重過失」と認定したケースは、これまでの判例によると、「ほとんど故意に近く、著しい義務違反があった」場合のみが、「重過失」に認定されているそうです。

例えば、「試験を1回も行わずに納品した」と言う様な、極端な事例以外、一般的な開発プロセスを踏んで納品したソフトウェア(プログラム)を、「重過失」とするのは、非常に難しいのだそうです。

しかし、過去の判例でも、次のようなケースでは、ソフトウェア(プログラム)開発側の「重過失」を認めた例もあるようです。

例1：東京証券取引所/みずほ証券の「ジェイコム株誤発注事件」事例(2006年提訴)
例2：日本IBM/スルガ銀行のシステム開発失敗事例(2008年提訴)

例1の『東京証券取引所/みずほ証券』の裁判では、東京証券取引所は、直接のソフトウェア開発者/提供者と言う立場ではなく、証券取引所と言う社会インフラの提供者としての公共性を重視した結果、東京証券取引所側に「債務不履行」があると言う判決が下されました。(※2)

また、例2の『 IBM/スルガ銀行』の裁判では、IBMと言う、大手ITベンダーと言う看板、および専門性があるにも関わらず、開発プロジェクトの管理が不的確だった点を問題視され、「プロジェクト・マネジメント義務違反(注意義務違反)」を問われ、「免責条項」があったにも関わらず、IBM側の「債務不履行」を認め、IBMが、スルガ銀行側に74億円の損害賠償を行うよう判決が下っています。(※3)

このように、近頃では、ソフトウェア開発側の「旗色が悪く」なって来ていますが、上記2例は、特殊な例ですので、やはりソフトウェア(プログラム)開発側の「重過失」を立証するのは難しそうです。

ちなみに、『東京証券取引所/みずほ証券』の裁判においては、みずほ証券側が、独自に「ソースコード(※4)」を解析した上で「バグ」の原因まで追求し、正しい試験を行っていれば今回の障害は回避できたので、東京証券取引所に重過失があると訴えていたそうです。

「ソースコード」の開示は、裁判官に認められなかったようですが、それ他にも、みずほ証券側は、開発手法も不適切だと訴えています。

例えば、通常、プログラムを修正する場合、次のような手法をとります。

(1)既存の基本設計書の修正
(2)既存の詳細設計書の修正
(3)既存のソースコードの修正
(4)試験設計書の作成(あるいは既存の試験設計書の修正)
(5)試験実施

ところが、東京証券取引所(実際は開発元の富士通)は、(2)の作業を行わず、直接、ソースコードを修正していた点を、みずほ証券側から、開発ドキュメント管理が不適切であると訴えられてしまったようです。

これに対して東京証券取引所側は、(2)の作業を行わなかった事は認めたものの、「最終的なドキュメントは、ソースコードになる」として、開発手法の誤りは認めなかったそうです。

まあ、どっちの言い分も、それなりに正しいのですが・・・裁判官が、何を根拠に、どのような判決を下すのかが、興味深い点となります。

さらに、前述の『東京証券取引所/みずほ証券』の裁判では、では、みずほ証券側が、ソースコードの解析、および障害原因に基づき、試験不足があったと言う意見書を提出しています。

今回の「バグ」を発見するためには、次の2種類の試験の内、どちらか一方だけでも行っていれば、「バグ」を発見できたと言っています。

修正箇所の直接試験
修正が他に影響を及ぼさないことを確認する回帰試験

一方、東京証券取引所側は、システムの本番稼働後、5年間も、このような障害が発生していないことを考慮すれば、今回の件は、非常に特異なケースであり、試験での「バグ」発見は難しいとしています。

『東京証券取引所/みずほ証券』の控訴審裁判において、開発手法や試験方法にまで踏み込んだ判決が出るか否かについては、私ども、ソフトウェア開発者にとっては、今後の仕事の仕方にまで影響を及ぼす重要事項なので、非常に注視しています。

また、今後、「IoT」を始めとして、社会インフラに、どんどんソフトウェア(プログラム)が組み込まれて行きますから、ソフトウェア(プログラム)の責任は重大になります。

その点でも、『東京証券取引所/みずほ証券』の裁判の行方は重要だと思っています。

ちなみに、東京証券取引所の現行の株式売買システムは「アローヘッド(Arrowhead)」と言いますが、「ジェイコム株誤発注事件」の時には、まだ「アローヘッド」は稼働しておらず、「統合ネット」と呼ばれるシステムが稼働していました。

そして、このシステムを開発したのは「富士通株式会社」ですが、現在、「ジェイコム株誤発注事件」は係争中のため、富士通が裁判の表に出ることはないようです。

障害発生時、東京証券取引所は、「システム納入業者への損害賠償を検討する」と語っていますので、今後の裁判の結果次第では、今度は「富士通対東京証券取引所」の損害賠償裁判が起こるかもしれません。

※1：2015年2月、Lenovoが発売しているノートパソコンに、凶悪なアドウェア(Superfish)が仕込まれていることが発覚しており、Lenovo自身もソフトウェアの組み込みを認めています。
※2：『東京証券取引所/みずほ証券』の裁判は、現在も控訴審で係争中です。
※3：『 IBM/スルガ銀行』の裁判は、控訴審で損害賠償額が減額され42億円になっています。
※4：「ソースコード」とは、プログラミング言語で記述したコンピュータに対する命令の事。

- - - - -

■訴訟事例の紹介

今回、ソフトウェア(プログラム)の「バグ」を理由に損害賠償請求が行えるのか否かを説明して来ました。

前章では、次の2件の訴訟を紹介しました。

例1：東京証券取引所/みずほ証券の「ジェイコム株誤発注事件」事例(2006年提訴)
例2：日本IBM/スルガ銀行のシステム開発失敗事例(2008年提訴)

上記訴訟の内、例1は、「バグ」が障害原因とは認定されましたが、元々双方とも「バグ」の有無を争うことを目的とはしていなかったので、「バグ」と言うよりは、東京証券取引所が提供するサービスに対する債務不履行を争う裁判になってしまったようです。

例2に関しては、説明すると長くなってしまうのですが、「バグ」ではなく、IBMが提案した外国製パッケージ・ソフトウェアに対するシステム設計が、スケジュール通りに進まなかった点に関して、IBMの「プロジェクト・マネジメント義務違反(注意義務違反)」が、重過失とされた裁判になります。

上記の他にも、何点かIT系の訴訟事例がありますので、何点か紹介したいと思います。

●システム完成基準に関する判決
●プログラムのバグの法的取扱い
●保管データの消失

- - - - -

【システム完成基準に関する判決】

●当事者
被告：A(システム開発発注者)
原告：X(システム開発受注者/ソフトウェア開発会社)

●内容
・被告Aは、社内システムの刷新を目的に、原告Xにシステム開発を依頼した
・原告Xは、被告Aから提出された要件を元に開発を進めたが、当初の予定より工数が増加することが判明
・原告Xは、被告Aと相談の上、納期の見直しを行った
・原告Xからの納品物には機能の見直し等が必要であったが、何度かの修正等を行い、どうにか納品された
・被告Aは、原告Xからの納品物の検収、既存システムとの並行稼働を経て、何とか本番稼働にこぎつけた
・しかし、本番稼働後も、不具合が続発し、かつ処理速度も遅く、使い物にならないことが判明した
・被告Aは、原告Xにシステムの改修を依頼したが、対応してもらえず最終的にシステム利用を断念した
・被告Aは、上記を理由に、原告Xとの契約を解除した
・原告Xは、被告Aに対して、未払い費用の支払いを求めて提訴した

●判決概要
・当初の契約内容の変更に関しては、書面の不備があるため、認定されなかった
・システム完成の定義を下記の通りとした
『請負人が仕事を完成させたか否かについては、仕事が当初の請負契約で予定していた最後の工程まで終えているか否かを基準として判断すべきであり、注文者は、請負人が仕事の最後の工程まで終え目的物を引き渡したときには、単に、仕事の目的物に瑕疵があるというだけの理由で請負代金の支払を拒むことはできない。』
・上記を理由とし、当初予定されていた、要件設計からデータ移行までの全ての工程を終了し、各工程が終了する都度順次納品を行い、最終的に本番稼働を行い、かつ本番稼働後も1年間もシステムを稼働している点を踏まえ、システムは、既に完成しているものと認定された
・他方、納品したシステムには、処理速度が異常に遅く、通常業務に耐えられないため、システムの瑕疵は認定された
・しかし、原告Xは、被告Aからの度重なる補修要求に答えていないので、契約解除は有効である
・契約の解除は有効であることから、原告Xからの未払い費用の支払請求は棄却された

【プログラムのバグの法的取扱い】
●当事者
原告：X(システム開発発注者)
被告：A(システム開発受注者/ソフトウェア開発会社)
補助参加者：B(被告Aより開発を請けた二次業者/実際のシステム開発担当)

●内容
・被告Aは、原告Xからのシステム開発案件を受注
・被告Aは、受注案件を、二次請けである補助参加者Bに再発注
・原告Xは、被告Aからの納品を受け、システム検収作業を終え、テスト稼働を行っていた
・原告Xにおける、システムの本番稼働は未実施
・原告Xにおけるテスト稼働で、納品物に60項目にも及ぶ不具合が発見された
・そこで原告Xは、契約を解除した上、支払い済みの費用に関して、被告Aに対して損害賠償請求を行った

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

【保管データの消失】
●当事者
被告：A(インターネット・プロバイダー)
原告：X(プロバイダー利用者)

●内容
・原告Xは、IP接続サービス解約に付随するレンタル・サーバー契約を被告Aと締結
・原告Xは、被告Aから提供されたレンタル・サーバー上に、ホームページを開設した
・ホームページのデータは、被告Aのサーバー上に保管されていた
・被告Aが、ホームページのデータを、別の場所に移し替える際、誤ってデータを削除してしまった
・ホームページのデータは、元々原告XのローカルPCに存在し、このPCからレンタル・サーバーにアップロードしたものであったが、ローカルPCの故障に伴い、PC上からも削除されてしまっていた
・その上、原告Xも、被告Aもバックアップを取っていなかった
・その後、原告Xは、被告Aに対して、ホームページの再構築費用、並びに逸失利益(いっしつりえき)を求める損害賠償請求を行った

●判決概要
・本件の争点は、次の2点となる
(1)被告Aは、契約上、自己のサーバーにおいて、原告Xのデータを消滅させないように注意する義務はあるのか ?
(2)原告Xには、過失相殺事由があるのか ?
・(1)に関する判決は、以下の通りとなった
『一般に、物の保管を依頼された者は、その依頼者に対し、保管対象物に関する注意義務として、それを損壊又は消滅させないように注意すべき義務を負う。この理は、保管の対象が有体物ではなく電子情報から成るファイルである場合であっても、特段の事情のない限り、異ならない。』
・このため、争点(1)に関しては、被告Aの注意義務違反が認められた
・次に争点(2)関する判決は、以下の通りとなった
『原告Xは、本件ファイルの内容につき、容易にバックアップ等の措置をとることができ、それによって損害の発生を防止し、又は損害の発生を極めて軽微なものにとどめることができたにもかかわらず、本件消滅事故当時、原告側で本件ファイルのデータ内容を何ら残していなかったものと認められる。そして、本件においては、被告の損害賠償責任の負担額を決するに当たり、この点を斟酌して過失相殺の規定を適用することが、損害賠償法上の衡平の理念に適うというべきである。』
・原告Xの過失相殺事由があるとされ、5割の過失相殺となった
・最終的に、原告Xの訴えは全て認められたが、上記の通り、5割の過失相殺となったため、請求金額がは大幅に減額されてしまった

- - - - -

■最後に

今回のブログでは、ソフトウェア(プログラム)の「バグ」を理由に、損害賠償請求が行えるのか否かを説明して来ましたが、如何でしたか ?

今回紹介した案件にだけ限れば、私共のように、ソフトウェア(プログラム)を作って提供する側からすれば、「ソフトウェア(プログラム)にはバグがあるのは当然」と言う判断/判決は、極めて常識的だと思っております。

現在のように、人間がソフトウェア(プログラム)を作っている状況においては、どうしてもソフトウェア(プログラム)内にバグを残してしまいます。

私達も、好き好んでソフトウェア(プログラム)内にバグを残している訳ではありません。

弊社が提供するソフトウェア(プログラム)に関しては、最低1ヶ月から最長1年間の瑕疵担保期間を設けています。

このため、ソフトウェア(プログラム)納品後、何かバグがあれば、現在手がけている作業を一時中断し、直ちにデバックしなければなりませんが・・・このデバック作業に時間が掛かると、プロジェクトは、直ぐに「赤字」になってしまいます。

故に、私達も、慎重に試験を行い、お客様にソフトウェア(プログラム)を納品する時には、バグが起きない状態で納品しています。と言うか、納品しているつもりです。

その点は、ご理解頂ければと存じます。

しかし、「ジェイコム株誤発注事件」において、どのような司法判断が下されるのかは、IT業界のみならず、製造業界にとっても重要な問題となります。

現在は、本ブログ、過去ブログでも簡単に紹介した「IoT(Internet of Things)」の時代となっており、車のみならず、工場で稼働するロボットや部品などにもICチップが埋め込まれ、作業内容や各種部品の在庫情報等がコンピュータで管理される仕組みになっています。

例えば、ドイツでは、工場のラインと作業員にICタグを付けており、ラインに配置された社員が新人の場合、ライン上の画面に、新人用の作業手順が表示される仕組みが導入されています。

このドイツにおける新しい生産革命は、「Industry(インダストリー)4.0」と呼ばれていますが、部品にもチップが埋め込まれ、在庫が不足すると、自動的に発注する仕組みも取り入れられています。

このような状況で、ソフトウェア(プログラム)にバグがあり、例えば、部品数を間違えて発注してしまえば、金額の桁数は大きく異なりますが、さまに「ジェイコム株誤発注事件」と同じような事象になってしまう可能性もあります。

今後の動きを引き続き注視し、何かあれば、またブログ等で報告させて頂きます。

それでは、次回も宜しくお願い申し上げます。

以上

【画像・情報提供先】
・Wikipedia(http://ja.wikipedia.org/)
・アイティーエス法律事務所(http://www.its-law.jp/)
・IT Pro(http://itpro.nikkeibp.co.jp/)

【株式会社 エム・システム】
本      社　 ：〒124-0023 東京都葛飾区東新小岩8-5-5 5F
 　 　 　 　 　 TEL : 03-5671-2360 / FAX : 03-5671-2361
盛岡事業所　 ：〒020-0022 岩手県盛岡市大通3-2-8 3F
 　 　 　 　 　 TEL : 019-656-1530 / FAX : 019-656-1531
E-mail　 　　： info@msystm.co.jp 
URL　　　　　： http://msystm.co.jp/
   　　　　　： http://msystm.co.jp/excel_top.html
ブログ       ： http://d.hatena.ne.jp/msystem/ 
Facebook　 　： http://www.facebook.com/msysteminc