ＩＢＭ対スルガ銀行事件判決評釈（東京地判平成２４年３月２９日第一法規判例体系）

作者: ルイス・V・ガースナー,山岡洋一,高遠裕子
出版社/メーカー: 日本経済新聞社
発売日: 2002/12/02
メディア: 単行本
購入: 22人クリック: 313回
この商品を含むブログ (94件) を見る

１．はじめに
ITクラスタに多大な衝撃を与えた、IBM対スルガ銀行事件判決。判決直後の「４月１日」に、その時点で明らかになっていた情報から憶測して、以下のネタ記事を書いたことは記憶に新しい。
判例評釈速報：ＩＢＭ／スルガ銀行システム開発事件〜東京地判平成２４年３月２９日判例集未登載（控訴） - アニメキャラが行列を作る法律相談所withアホヲタ元法学部生の日常

　判決直後には、ＩＢＭ側の申立てにより開示されなかった*1判決本文が、平成２４年５月１６日、第一法規判例体系に掲載された。同業他社のデータベースを確認したところ、現時点の掲載はないとのことであるので、第一法規の「スクープ」として評価できよう。
追記：その後５／２１に日経新聞に「スルガ銀・ＩＢＭ裁判、判決全容が判明〜「他社パッケージソフトの検証不足」が不法行為」という記事が掲載されている。
テクノロジー : 日経電子版

　さて、判決本文を見たところ、従前の「評釈」のうち一部はそのとおりであるが、一部は修正を要するということが判明した。一言で言えば、本判決は、「合意書の意義については、ＩＢＭの主張をほぼ全面的に認めたが、プロジェクト・マネジメント義務違反を書証から認めた」というものである。よって、以下の通り再度評釈する。なお、判例本文を引用する際、分かりやすさを優先し、原告を「スルガ」、被告を「ＩＢＭ」と表記する。

前提となる事実関係については判決文では極めて長い認定がなされているものの、おおむね前評釈で述べたとおりである。前評釈後に日経新聞が「ＩＢＭに７４億円の賠償命令、スルガ銀裁判の深層」と題した記事を書き（テクノロジー : 日経電子版）、その中で、テクノロジー : 日経電子版という形で要領よくまとめているので参考になる。

　要するに、スルガ銀行の基幹システムをリプレースする計画について、IBMは、これまで日本では実績がない外国のパッケージであるCorebankを担いだ。スルガ銀行はこのIBMの提案を採用し、平成１６年９月に要件定義開始後、第一回目の要件定義が終わる間際の翌１７年９月に「最終合意書」（合意書）が交わされて、新システムを８９億７０８０万円で開発することが約されたところ、その後要件定義（ＢＲＤ*2）をさらに２回やり直すことが必要となった。その後平成１８年８月頃にＩＢＭはスルガに対してコストの大幅な増額を申し出、その後スルガとIBMの間で交渉が行われ、平成１９年４月頃に、ＩＢＭがパッケージソフトの変更を提案し、これに対しスルガが拒絶したことにより、訴訟になったといった経緯である。

２．まるでＩＢＭの「詐欺」〜書面主義による１０対０判決
　この判決文を読めばすぐに分かることは、事実認定勝負であるということである。そのキモとなる認定は以下の通りである。

そうすると、本件システム開発が頓挫したことの責任はもっぱらＩＢＭにあるのであり、そのことについて、ＩＢＭはスルガに対してプロジェクト・マネジメント義務違反の責任を負うものというべきである。
（略）
スルガには、本件システム開発について協力義務違反があるとはいえないこと、ＩＢＭとの間で不誠実な交渉をしたということもできないことについては、前記（略）のとおりである。その他、スルガがＩＢＭに対して不法行為をしたことの根拠となる事実を認めるに足りる証拠はない。

　要するに、ＩＢＭはスルガに対してプロジェクト・マネジメント義務違反の責任を負うが、スルガはＩＢＭに対して協力義務違反等の責任を負わないという、いわば「１０対０」の責任分担であることが示されている。

　このような責任割合の判断について疑問を呈する向きもあろうが、実は、裁判所の事実認定を前提とすると、それに基づく法的評価は概ね妥当と解される。

　まず、１つ目の争点である合意書（本件最終合意書）の意義について、東京地裁は、おおむねＩＢＭの主張を認めた。
要件定義段階で結ばれた、「約９０億円でシステムを作りましょう」という合意書の意味について、「ＩＢＭはスルガに対して合意書記載の８９億７０８０万円で最後までシステムを構築する義務がある（スルガの主張）のか、それとも今後の個別契約の締結を前提としており、これ自体に法的拘束力まではない（IBMの主張）のか」が争いになっていた。

　下馬評は、おおむね、ＩＢＭの主張に理があるというものであったが、東京地裁も、

本件最終合意書に記載されたスルガの支払金額の法的拘束力については、スルガとＩＢＭとの間で本件プロジェクトの各局面における義務を定めた個別契約が締結されることを前提条件として生ずるものとされている〔ところ〕業務に関する外部設計・内部設計・開発・テスト局面、並びに制御及び基盤に関する開発・テスト以降の局面に関する個別契約の大半が未締結である〔ため〕上記支払総額が法的拘束力を有するに至る程度に条件が充たされているとはいえない（評釈者注：つまり、まだ９０億円で最後まで作るという合意は法的拘束力を持ったとは言えないということ。）

として、下馬評通り、ＩＢＭの主張を認めた。

ただし、その次の論点への布石として、「本件最終合意書が交わされた平成１７年９月３０日の時点において、ＩＢＭは、本件システム開発のコスト見積りの前提となる基礎数値を確定させてスルガの支払金額を決めたものであることなどからすれば、上記支払総額の規定された本件最終合意書が交わされたとの事情が、ＩＢＭの信義則上ないし不法行為上の義務違反の有無を考慮するに当たり意味を有し得るものであることを否定するものではない」としている。

重要なのは、２番目の論点である、IBMのプロジェクト・マネジメント義務の問題である。ここにおいて、東京地裁は、「システム開発業者として、自らが有する高度の専門的知識と経験に基づき、納入期限までにシステムを完成させるようにユーザに提示し、ユーザとの間で合意された開発手順や開発手法、作業工程等に従って開発作業を進めるとともに、常に進捗状況を管理し、開発作業を阻害する要因の発見に努め、これに適切に対処すべき義務や、ユーザのシステム開発への関わりについても適切に管理するなどの行為をすべき義務」という広い意味でプロジェクト・マネジメント義務という表現を使っていることにまず留意されたい。

　このような前提の下で、東京地裁は、ＩＢＭにプロジェクト・マネジメント義務違反を認めた。以下、東京地裁の認定を要約する。
まず、パッケージとしてＩＢＭが「担いだ」Ｃｏｒｅｂａｎｋがこれまで日本の銀行において導入された経験のないものであり、リスクが高いものであった。
　そして、費用・納期の削減を目的にパッケージが利用される以上、当初よりフィット＆ギャップ分析を行うことが求められた。それにもかかわらず、「合意書」締結以前の段階における第一回目の要件定義では、ユーザの現行システムの機能を基礎にしてそれに新システムで必要な機能を積み上げるという手法がとられており、これでは、ギャップ開発の量が不必要に膨らんでしまう。そのようなアプローチによる要件定義終了後、ＩＢＭは、当初の要件定義の考え方に誤りがあったとして更に２回目及び３回目の要件定義（新旧ＢＲＤ）を実施しているのであって、ＩＢＭは、Ｃｏｒｅｂａｎｋを利用した場合の適切な開発方法についてあらかじめ十分な検証又は検討をしていなかった。
　また、ＩＢＭはＣｏｒｅｂａｎｋによるシステム開発について知識や経験のある技術者等の要員を本件プロジェクトのメンバーとして配置しておらず、３回目の要件定義段階ではじめてＣｏｒｅｂａｎｋの開発業者であるＦＩＳ社の要員を関与させた。しかも、ＩＢＭはＣｏｒｅｂａｎｋの改変権を有しておらず、その改変はＦＩＳ社によって又はＦＩＳ社の承諾に基づいて行わなければならなかった。ところが、ＩＢＭは、本件システム開発において、Ｃｏｒｅｂａｎｋの改変権を有しているＦＩＳ社との間で協議をするなどしてＣｏｒｅｂａｎｋのカスタマイズ作業を適切に実施できる体制を整えていたとはいえず、これが作業の遅延や費用の増大を招いた。
　このような状況にもかかわらず、合意書を交わした平成１７年９月３０日の時点においても、ＩＢＭがＣｏｒｅｂａｎｋの改変権を有していないことが本件システム開発において作業の阻害要因になり得ること、Ｃｏｒｅｂａｎｋを改変するために必要とする役割分担、作業量・作業時間、費用等に関してＩＢＭとＦＩＳ社との間で十分な協議が整っていないことなどの事情について、これをスルガ側に説明してはいなかった。
　合意書の内容は、上記のとおり法的拘束力までを持つものではないとしても、既に要件定義が進んでいる状況において、システム開発コスト見積りの前提となる基礎数値（オンライン取引数、帳票数、リンクデータ数、バッチジョブ数）についてはほぼ確定に近づいたなどという経過報告をして、最終的に同年９月３０日に本件最終合意を締結したというものであって、その後も、大きく費用を増加させる必要がある旨は、平成１８年中は説明されていなかったのであり、スルガとしては、少なくとも、平成１８年８月にＩＢＭからサービスインの時期の修正について提案がされ、追加費用の負担についての申出がされるまで、スルガにおいて追加費用の負担を考慮する必要はないと考えていたのである。そして、そのような認識の下で、約６０億円という膨大な代金を支払った。
　その後、平成１９年４月頃のＩＢＭからスルガへの別のパッケージによる開発の提案についても、代替案を出す以上は、完成時期や費用負担について十分な検証を行って成算がある、ないしはスルガにとっても利益があるという確かな見通しが持てるようなものでなければ、スルガにとって受け入れ難いものであることは明らかである。そうであるにもかかわらず、ＩＢＭは完成時期や費用負担について十分な検証を済ませないまま代替パッケージによることをスルガに提案したのであり、そのこと自体、スルガとの信頼関係を失わせる根拠になるものということができる。
　よって、スルガが、ＩＢＭから別のパッケージソフトの利用の提案を受けた段階で、ＩＢＭに対して本件プロジェクトを白紙に戻したいと伝えて本件プロジェクトを中止する決断をしたことについては、何ら非難に値するものではないし、むしろ、相応の根拠があるものということができる。そうすると、ＩＢＭのプロジェクト・マネジメント義務違反により本件プロジェクトが頓挫したものであり、ＩＢＭはこの点について責任を負わなければならないというべきである。
ＩＢＭは、プロジェクト頓挫の責任はスルガにあるというが、スルガは商品数削減等に協力しており、協力義務への違反はない。

いかがであろうか、ここまで認定されると、要するに、ＩＢＭが使えないパッケージを担いだ挙句、綻びを取り繕えなくなるところまで綻びを隠し続け、その挙句プロジェクトが破綻したというようなものであり、まるで詐欺である。
この事実認定を前提にしてしまうと、「ＩＢＭ側は悪くない」とか、スルガを勝たせた裁判所の「法解釈」がおかしいというのはなかなか難しいのではないか。まさに、本判決は「事実認定」がキモといえよう。

３．不利な「書面」は作ってはならない！
　なぜ、このような事実認定になったのか。もちろん、「本当にＩＢＭが使えないパッケージを担いだ挙句、綻びを取り繕えなくなるところまで綻びを隠し続けた」可能性も否定できない。ただ、ＩＢＭは控訴しており、この点を強く争っている。そこで、違う可能性、具体的には、ＩＢＭに多かれ少なかれミスはあれど、誠実に頑張っていたにもかかわらずこのような認定になった可能性も視野に入れて考えてみよう。

この判決は、争いのある部分は基本的に書証に基づき認定している。例えば、スルガが商品数削減に協力したかについては、ステアリング・コミッティーの議事録から、

こうやって具体的な数値（削減商品数やグループ数）を出すことができた。スルガの担当者の方には負担をかけ、ありがとうございました。

というＩＢＭ事業部長によるスルガに対するお礼の言葉を引いて、スルガが協力義務を尽くしたと認定している。

　また、数少ないＩＢＭに有利な事実も、書面を根拠にその意味が減殺されている。要件定義のやり直しの際にIBMが提出した「ＢＲＤの概要」という書面には、要件定義のやり直しの目的として、

「当初想定投資の再見積りを行う」

という文言が記載されていた。これは、要件定義のやり直しに伴い、当然に予算は変わってくるというIBM側の認識を示す良い資料である。

　ところが、この資料については、

スルガが、後付けで目的を追加することは認められないので、削除されたい、追加する理由も本件最終合意を破棄するためのものなのかと指摘したのに対し、上記の項目はＩＢＭ内部の事項であり当初設定した目的にはなかったことなので、削除する旨回答した

　という事実が議事録らしき書面に基づき認定され、結局、合意書の金額を大きく上回らないことを前提に要件定義のやり直しが行われた旨が認定されている。

　このようなＩＢＭにとって圧倒的に不利なもろもろの書面が作られた経緯については、前評釈で述べたとおり、ＩＢＭ側は「脅迫」「軟禁」等を主張しているようである*3が、裁判所は争いのある事実程書面に基づき認定しており、「ＩＢＭ程の大企業が脅迫されて事実と異なる書面を作るなんて」という裁判所の見方がうかがわれる。

　実は、実務上、弱い立場にあるベンダーが事実と異なる書面を作らされることは現実には少なくない。しかし、裁判では書面がものをいうのであって、仮に事実がＩＢＭのいうとおりであっても、これだけ書面がガチガチ固められれば、裁判所が本判決のように認定することも十分うなずけるところである。

　今後、ベンダーとしては、７０億円の敗訴判決を食らわないためにも、書面を出す際に慎重に慎重を期すべきことを物語る判決と言えよう。

４．訴訟戦略ミス？
　本件について、もし、スルガも相当程度責任があるというのが実態であれば、その可能性として一番高いのは、「スルガ側の当初の合意の前提をぶち壊し、膨大な要件の実現を求め、それによって期間も費用も伸ばさざるを得なくなった」という主張である。
　これは「あり得る」話であって、かつ、これが認められればＩＢＭの責任は僅少になる。

　IBMの代理人も、このような主張をしており、判決文の中でも、

　ＩＢＭは、本件プロジェクトの頓挫原因について、開発フェーズのコストの見積りが１０５億円から２２６億円に増大したことの定量的分析をすると、スルガ側に原因（銀行によって内容が異なる要件及びスルガ独自の要件を開発するための費用の増加）のあるものが９１．９６億円（８２．８５％）、ＩＢＭ側に原因（邦銀標準のパッケージを作るための費用の増加）があるものが１９．０４億円（１７．１５％）であり、圧倒的な割合でスルガ側の原因によって見積りが増加しているし、仮に、本件最終合意締結後に新たに判明した要件のみがスルガ側の原因によるものであるとしても、なお５６．３２％という割合であるから、本件プロジェクトの頓挫原因はスルガにあるなどと主張する。

と認定されている。

　ところが、東京地裁は、以下のとおり判示して、IBMの「一番強い主張」を簡単に排斥した。

開発費用の増加原因を上記のように分類するのが相当であるのか疑問がある上、そもそも、本件プロジェクトの頓挫原因は上記（略）で述べたとおりの事情であると認められるのであるから、ＩＢＭの上記主張は採用することができない。

　要するに、上述のような、IBM側のプロジェクト・マネジメント義務違反がプロジェクト頓挫の原因なのであって、スルガが要件を膨らませたかどうかは関係ないという認定である。

　なぜ、このような認定になってしまったのか。アウトサイダーである筆者にとって真相は分からない。しかし、判決文の不思議な記載を見つけた。

本件プロジェクトが頓挫するに至ったのは、平成１９年５月ないし６月であるということができる。すなわち、ＩＢＭがスルガに対して同年４月１８日にＴＣＢの提案をしたが、スルガがこれを受け入れず、同年５月９日に本件プロジェクトをいったん白紙に戻したいとＩＢＭに通知した上、さらに、ＩＢＭがスルガに対して同年５月３１日付けの書簡により現状の課題の整理とその解決の検討を提案したのに対し、スルガは、同年６月８日、これをも返却して、その提案を受け入れなかったのであり（略）、この時点においては、本件プロジェクトは頓挫したものということができる。
　　この点について、ＩＢＭは、本件プロジェクトが頓挫したのは平成１９年１月であると主張する。しかし、前記１の認定事実によれば、この時点においては、スルガ及びＩＢＭ共に、本件システム開発をいつまでに、どのような範囲で、また、いくらの費用で行うかについての交渉を続けていたのであり、本件プロジェクトが上記時点で頓挫したなどということはできない。
　　なお、ＩＢＭが、本件訴訟の当初、本件プロジェクトはスルガがＴＣＢによる代替案を拒絶して本件プロジェクトを白紙に戻すこととする旨を一方的に宣言したことで頓挫したと主張していたことは当裁判所に顕著である（答弁書１９頁、４２頁）。

この「なお書き」は、なぜ記載されているのかが最初はよく分からなかったが、少なくとも言えるのは、

時期	プロジェクト破たん時点に関するIBMの立場
訴訟開始時点	平成１９年５月
現在	平成１９年１月

　ということである。

　訴訟継続中に立場をコロコロと変えるのは、一般に禁忌とされ、裁判所の心証を悪くするだけなのであるが、なぜ、あの有名事務所はあえてこのようなリスクを犯したのか。

　その理由は、想像するしかないが「代替パッケージ論が無理筋である」ことに、後になって気づいたということではないだろうか。

　つまり、ＩＢＭの代理人が当初ヒアリングした際には、ＩＢＭの担当者は「要件が膨れ上がり、Ｃｏｒｅｂａｎｋでの対応が困難になったことから、代替パッケージまで提案して誠意をもって交渉したのに、スルガがこれを断ったため、平成１９年５月頃プロジェクトが頓挫した」と説明したのだろう。このような説明は、話としてはあり得るが、その前提は、もちろん、代替パッケージの提案が「まともな」提案ということである。

ここで、代替パッケージの提案が弥縫策に過ぎず、合理的な提案でなければ、その点を強調することは得策ではない。むしろ、代替パッケージの提案がどうであれ、平成１９年５月の提案以前の同年１月の段階で、既にスルガが大量の要件を当初の予算でシステム化することに拘泥し、システム開発は頓挫したと言えば、大体パッケージに焦点を当てずにスルガの非を主張することができる。この場合は平成１９年１月破綻説になるだろう。

　本件で、上記のような主張の変遷をせざるを得なくなった経緯を推察するに、当初、IBMの代理人は、「代替パッケージの提案は誠実性の証明」説に従って、平成１９年５月の頓挫説を主張していたが、その後で、代替パッケージがあまり練られた提案ではなことに気づき、その段階で、代替パッケージに焦点を当てない戦略へと方針転換をせざるを得なくなり、だからこそ、平成１９年１月へとプロジェクト頓挫時点を変遷させざるを得なくなったのではないか。上記の通りＩＢＭの「一番強い主張」が排斥されたその理由の重要な１つは、このような「戦略ミス」だったのではないか。

　現場の担当者は「自分の提案は完璧です」といいがちであり、これを外部の弁護士に疑えというのは厳しいのかもしれないが、初期の段階において、例えばインデペンデント・レビューのような形でプロジェクトに利害関係のない有識者（外部が望ましいが、内部の違うラインの人やＯＢ等にお願いせざるを得ないこともあろう）にレビューをしてもらうこと等は検討に値するだろう*4。

まとめ
　判決の事実認定通りＩＢＭがダメダメなプロジェクト運営をしたのであれば、この結論はやむを得ない。
　ただ、もし、ＩＢＭがミスはあれども誠実に頑張ったのであれば、それにもかかわらずこのような判決を食らった大きな理由は、不利な内容の書面を残したことと当初の訴訟戦略の誤りがあったものと推測される。
　なお、上記はすべてインサイダー情報等を得ていない部外者が判決文だけを基に分析したものであり、その結果事実認識等に誤りがある可能性は否定できない、特に控訴審において事実認定が変わればコメントも変わり得ることにご留意いただきたい。
　また、判決文を読んでいると、プロジェクトがおかしくなるにつれどんどんIBMのグローバルの介入が強まるが、結局止血できない様子等がよく分かり、ITクラスタにとってはかなり胃が痛くなるが反面勉強になるので、ITも法律も中途半端な筆者の手による本エントリのみに依拠して検討するのではなく、判決本文を読まれることをお勧めする。