スルガ銀の対IBM損害賠償訴訟


日経コンピュータのサイトITPro平成20年4月14日付け記事です。本訴訟の第1回弁論が4月14日に東京地裁で行われました。多くの記者が傍聴したそうですが、あっという間に終了してしまい、殆どの記者には何が行われたのか、さっぱりわからなかったそうです。スルガ銀が東京地裁に提訴したのは3月6日です。訴状は通常閲覧できますので、少なくとも原告側の主張は事前に把握できるのですが、IBMが非閲覧申請をして、これも珍しいことだそうですが、全く閲覧できないまま第1回弁論となりました。双方の弁論書等は事前に裁判所に提出されて、裁判官はそれを読んで弁論に臨みます。弁論では裁判官から、提出済み書類の他に主張があるか、提出書類に誤り変更はないかが確認され、次回日程が通告されて閉廷です。記者を始め、傍聴人には何が争点なのかさっぱりわからないのは当然です。

こうなると記者諸氏は、情報を得ようと各方面に取材をかけます。筆者にも多くの記者から質問電話がきます。しかし、ここ2年ほどスルガ銀次期シス関連の情報は全く持ち合わせていません。何故かというと、筆者はIBMの後輩達にNEFSS販売をやめるべきで、ましてやスルガ銀を一号ユーザーにするのは危険すぎると忠告していたので、NEFSS関係者から煙たがれていたのでしょう。まして、訴訟ともなれば完全に緘口令がひかれます。こうなると外部どころか、社内の友人にすら話さないのがIBM社員です。(少なくとも昔はそうでした。) その点は、スルガ銀の関係者も同じでしょう。銀行員の口は堅いですし、三島は取材に不便です。

それにしてもプロ・ジャーナリストの取材力はたいしたものです。こんな覚書があるそうだが、それはどんな権利責任関係になるのか? 他のベンダーの地銀との示談では、こんな賠償金額で、その理由はこうだそうだが、本訴訟とはどう違うのか? などの質問がきます。よくまー、いろいろな角度から調べてくるものだと感心します。ただ、皆さん、製品のPL責任に拘っているようです。IBMが、NEFSSを完成製品として販売契約したとは思えません。あくまでも業務委託による開発のコア・ソリューションという位置づけのはずです。少なくとも契約書の上では。となると、スルガ銀の次期シス開発における発注者と受託者の債務関係の問題となります。IBMの契約書は緻密を極めます。筆者は、この分厚く、かつ、緻密な契約に30年も浸っていましたが、独立してIBM以外のベンダーの契約書を見た時は唖然としたものです。XX一式、XX億円。納期XXX月予定・・といったメモ書きのようなものです。中には契約締結が引き渡し時だとか、全くないとかいう例もあります。素晴らしい信頼関係というか、無責任関係というか? 重層的下請け構造、総額範囲内での人月(単価か工数の調整)価格などと並んで、IT業界の後進性を象徴しています。旧式業界の代表とされる建設土木業も、全く顔負けの業界慣習です。これでは、顧客企業もベンダーも進歩しないはずだと得心したものです。

金融関連では、みずほ証券による対東証の損害賠償訴訟が続いています。一昨年の12月第一回弁論以来1年半になります。メディアの関心は薄れたようで、ほとんど報道されません。ところが、裁判で東証は、「株式売買システムは会員同士の取引の場として提供しているだけであって、取引の成立を保証するものではない。よって、みずほ証券の取消注文を処理できなかったことに、何ら責任はない。また、当該システムは富士通が開発したので東証にはシステムの瑕疵に関する責任もない。」というものです。この主張が裁判で認められれば、日本において、システム経由での取引は全く安心できないものとなります。また、ITベンダーは、顧客の顧客からの訴訟リスクにさらされることにもなります。その他にも、東証は開発、検証における発注者責任に関して、唖然とするような主張を繰り出しています。富士通は、とんでもない顧客を抱えたものだと思いますが、次期シスも受注して、ますます蜜月関係を強めています。本当に面白い業界です。

筆者はメディアの皆さんに、みずほ証券とスルガ銀の訴訟は、日本のIT慣習を変える契機になると言っています。みずほ証券の訴訟は、ITによるサービス提供者と利用者の権利義務関係。スルガ銀の訴訟は、発注者とベンダーの権利義務関係です。前者においては、ベンダー選定、契約、開発、テスト、稼動における記録が殆どありませんので、裁判が長引いています。後者は十分過ぎるほどの記録が残っているはずなので、短期間で結論が出るでしょう。どちらが勝訴しても、その結果は、ベンダーや発注者に大きな影響を与えます。提案の方法も、契約書の内容も、開発作業の責任分界や記録保存など、透明性とガバナンスが要求されることになります。開発費用(売上)の進行基準化、J-SOXの一環としてのITガバナンスなどとも関係します。

日本の大手Serが共同で、業務要件定義の手法をとりまとめています。彼らは、これまでも、さまざまな場所で、ソフトウェア・エンジニアリングの必要性を強調してきました。革新的な手法やツールを誇らしげに公表してきました。ところが、販売現場や開発現場では、全く使われていないようです。現場とすれば、余計なお作法を作っていないで、われわれの仕事を手伝えというのが本音なのでしょう。トラブルを繰り返すのは、偶然ではなく仕組みの問題であることは周知です。仕組みを作りかえるのは、経営の仕事そのものです。この2件の裁判結果からの教訓を、自社の仕組みに反映して、全社的に実行させるのは経営の責任であることは間違いありません。メディアも三面記事扱いしてはいけません。わが国IT産業のカルチャの問題であり、国際競争力の問題です。