みずほ証券の対東証賠償訴訟とITビジネス慣行  (2/2)


本論考の後半では、債務不履行など不法行為による賠償請求を受けないために日常的に注意すべき点につき整理してみます。大半の注意事項は、新たなものではなく、これまでも当然になすべきとされてきたことばかりです。問題は、これら当然とされる注意義務項目が、実行されない現実が多くあるということです。わが国のソフト技術者は百万人強ですが、内訳はユーザー側に25万人、ベンダー側に77万人とベンダー依存度が極めて高い。米国のユーザー側236万人(比率72%)は例外としても、日本は極めていびつな構成です。中印もベンダー比率は高いのですが、日本とは海外事業のウェイトが余りに違います。ユーザー企業に、プロジェクト管理を含めたガバナンスが確立していれば、まだ問題ないのですが、ベンダー丸投げで、かつ、一方的なパワー関係にあると、悲劇的な事態が起きやすい。最近のベンダーには顧客クォリティを重視する企業が、増えつつありますが、それでも、売上が万病の良薬と考える企業も多く存在します。売上規模と従業員数で企業ランクを判断する重厚長大型評価基準から抜けられない日本経済の後進性と考えられます。特にメディアがひどい。こうした中で堆積したITビジネス慣行が、ベンダー収益性や新興企業成長を阻害して、それが、また、労働集約的な重層的下請け構造を固定化し、新技術や新サービスの育成を止めています。国によるIT産業政策の致命的失敗でもあります。こうした状況は総合的かつ有機的に解決する必要がありますが、本件からは、訴訟リスクをテコとして、ITビジネス慣行とITプロセス管理の見直しを提言します。

本訴訟は、既述のように、ITサービス提供者とその利用者の債権債務に関する責任義務が主題です。発注者と受注者間の訴訟ではないので、その両者間の債権債務関係は論じられていません。しかしながら、東証が裁判所に提出した資料から債務不履行に至った不作為や発注者としての注意義務違反は列挙できます。それが裁判で重過失と認定されるかは別として、少なくとも過失(法的な不法行為)として指摘される危険性のあることは確かです。契約当事者の組合せを区分して、注意点を列挙してみます。

1.IT関連サービス発注者と受託者との関係における教訓

@ 開発を委託する契約の形式が請負であれ、委任であれ、実際の作業内容、提案書を含む両者間で取り交わされた関連文書に基づき、請負か委任かが判断される。委託契約においては、成果物や両者の役割と責任分担、成果物の納期と検収方法等を明確にしておく必要がある。現在でも多くのケースで極めて簡便な契約がなされているが、発注者、受託者双方が自らを守るためにも、より精緻で明確な契約内容が必要である。

A 委託者は、自らの発注者責任につき、受託者とのなれあいを避け、具体的な作業内容と進捗管理、品質管理に関する項目と基準を明確にし、記録にすることにより、注意義務違反のないことの証拠を残すべきである。

B 外部委託で作成したソフトが原因でも、利用者に対する損害賠償の責任を免れないことは、本訴訟の一審判決でも明白になっており、発注者は成果物が自社の負う債務を執行するのに充分な機能と品質であることを充分に確認しなくてはならない。おざなりな受入れテストは絶対に避けるべきである。

C 賠償額の分担をITベンダーに求める可能性があるが、その場合は開発の委託費に反映することに加え、保険などでリスク分散かリスク移転する必要がある。

D 受託者の瑕疵担保責任につき期間は通常1年か2年であるが、期間の延長を求める委託者が増えるかもしれない。対象業務、製品種類、使用方法などにより、より多様な期間設定があって良いと思われる。オプションで発注者が選択することも良いだろう。

E 受託者の損害賠償額は、当該契約金額を上限とする契約が多いが、上限額の拡大を求める委託者が増えることも考えられる。この場合、賠償リスクが契約金額に上乗せされるだろうが、それを単なるコスト増と考えるのではなく、外部委託によるソーシング戦略と合わせてコストとリスクの関係を整理する機会としたい。つまり、人月単価の値付けではなく、品質、リスク・ベースの値付けが必要となる。

F プログラムのバグが原因で巨額な賠償命令が出されると、技術者が委縮してしまい、開発作業に悪い影響を与えるとの見方があるが、むしろ逆であろう。みずほ証券が、注意義務違反として指摘しているのは、開発当時における東証の杜撰な開発管理態勢、品質管理態勢、障害発生時の対応不備などITガバナンスの問題です。作業も責任も丸投げし、何かトラブルがあれば技術者個人の責任にするような慣習を改め、開発現場に携わる技術者の負担とリスクを減少させる契機とすべきであろう。

注記)上記対応は、これまでも当り前のこととされてきた。東証も過去の反省を踏まえて、アローヘッド開発以降は開発手法の基本を守り、高品質なシステムを開発したと評価されている。しかし、本訴訟で東証が裁判所に提出した資料では、多くの学者や実務家で専門家とされる人達が、「現行と同一との業務仕様指示に問題ない。」「設計書などなくても開発できる。」「請負契約なのだから、発注者は業務要件提示と検収だけで良い。」などと断言している。プロジェクト管理や品質管理の基本的経験則に対しても、「そんなことはルールとして決まっていない。」としている。開発プロジェクトが時間とコストの制約下にあることは諸外国も同様であるが、日本では余りに、技術者個人の努力に依存してきた。巨大化、複雑化した大規模システムでは、個人に委ねる限界は越えていることは確かであり、個々の技術者が安心して作業できる開発管理手法と環境整備を進めるべきである。

2.IT関連サービス提供者と利用者の関係における教訓

@ 提供するサービス内容とレベルを明確にする必要がある。特に、結果債務を負うのか、手段債務を負うのかを明示し、それに応じたサービス提供と障害発生時の対応態勢を整備しておく。SLA契約などで提供サービスの品質基準を明らかにすることも重要だが、その実現に対してベストエフォートの認定を得られるように、具体的対応策の整備と実施結果の記録を保存することが重要である。

A 他社のソリューションと組み合わせてサービスを提供するケースが増えている。クラウド利用においても、この傾向は強まるだろう。それでも利用者に対する提供者責任(債務執行責任)に変りない。提携先が自社の債務履行補助者と見なされる可能性もある。その点に関する免責規定を設けたとしても、裁判では限定的に判断されるかもしれない。安易な組合せソリューションの提供は危険である。少なくとも利用者に対し、事前にサービス提供方法を開示して、SLA等に反映しておく必要がある。

B 金融機関では、全銀為替など業界システムを始めとして共同化やアウトソーシング等、他社が提供するITサービスを使って、認可事業(多くは結果債務)を行うことが多い。この場合、金融機関はサービス提供者であり、IT提供ベンダーは、債務履行補助者と認定される可能性が高い。これまでもIT不具合による利用者の損害はサービス提供者である金融機関が負担してきたが、今後は三者間の債権債務関係が複雑化する可能性がある。取引関係が複雑になるほど、顧客は特定のサービス提供者による一元化された保証を求めることになるだろう。それをリスクと見るか、事業機会と見るか。ビジネスモデルが変化する可能性も出てくる。

C 約款における免責規程は、損害賠償法による被害者の救済という立法趣旨に従い、限界的に解釈されることが増えている。現在、法制審で審議されている債権法改正案でも約款による一方的な免責規定を制限する方向にあることに留意すべきである。

利用者にとっての注意事項もある。

D ITサービス利用に伴い損害を被ることはあるだろう。できれば訴訟に至らずに解決したい。何故なら、債務者の過失を証明する義務は原告にある。被告である債務者が必要充分な情報資料を開示することは期待できない。更に、司法に携わる専門家は、ITに関する経験、知識のないことが多く、わが国はIT司法後進国である。訴訟に関する労力、時間、費用は大変な負担となる。訴訟をさける為には、提供者と間で事前に合意明示しておくことが望ましい。個人向けサービスについては、消費者保護を目的として多くの法整備、判例、約款ひな型が公開され、情報共有されているが、法人間の契約関係に関しては、こうした環境は整備されていない。個別企業が対応するには余りに負担が大きすぎる。

E 提訴せざるを得ない場合、債務者の過失を証明する資料、または、強く疑わせる材料を提示して、裁判所から記録等証拠提出命令を出してもらう必要がある。その為には、サービス利用のあらゆる機会を通じて、提供者のサービス提供手順、態勢、規則などやその実行状況、できれば監査報告書などを入手しておきたい。提供者が業界団体や公的機関、大手ベンダーであろうと、利用者の開示要求に正当な理由なく(営業機密と言われても、単純に信じる必要はない。)拒否する提供者とは取引関係を見直すか、性悪説で日常的にチェックしておくことが重要である。

最後に、繰り返しとなりますが、契約に基づく責任範囲の明確化と管理注意義務に基づく債務履行状況の確認と記録保存は、提供者と利用者双方の利益を守り、リスクを減らすことになります。法的紛争は最後の手段ですが、上記のような基本的な注意事項や防止策を実施することで、結果として法的紛争が減らせることになります。                                                         

               以 上