- 作者: 北城恪太郎,大歳卓麻
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2006/02
- メディア: 単行本
- 購入: 3人 クリック: 66回
- この商品を含むブログ (12件) を見る
既に、第一審判決（東京地判平成２４年３月２９日）の評釈として
ＩＢＭ対スルガ銀行事件判決評釈（東京地判平成２４年３月２９日第一法規判例体系） - アニメキャラが行列を作る法律相談所withアホヲタ元法学部生の日常
を書いた。ところが、平成２５年９月２６日に第二審判決が下された（東京高判平成２５年９月２６日）。これは、１０月８日に第一法規のデータベースに登録された*1。そこで、簡単に解説したい。
１．損害賠償が約半額に！
まず、目を引くのが、損害賠償が約半額になったということである。第一審判決はIBM側に約７４億円の賠償を命じていたのが、控訴審では、わずか約４２億円である。約４５％のディスカウントである。
それはいったいなぜか。本エントリは、専門書ではなく、あくまでも、IT業界の方の便宜のためのものであるから、枝葉末節は無視し、直裁に、この理由にだけ迫りたい*2。
2．各段階を分けて考察
目を引くのは、控訴審判決が、時期を分けている部分である。
１つ目は、企画・提案段階、２つ目が計画・要件定義段階の前半、３つ目が、計画・要件定義段階の後半（最終合意書締結まで）、４つ目が最終合意書締結後である。
まず、１つ目の企画・提案段階において、ベンダーに、プロジェクト．マネジメント義務として、「自ら提案するシステムの機能、ユーザーのニーズに対する充足度、システムの開発手法、受注後の開発体制等を検討・検証し、そこから想定されるリスクについて、ユーザーに説明する義務」を認めた。しかし、「ベンダは、システム開発技術等に精通しているとしても、システム開発の対象となるユーザーの業務内容等に必ずしも精通しているものではない」ことからで、「企画・提案段階の計画どおりシステム開発が進行しないこと等をもって、直ちに企画・提案段階におけるベンダのプロジェクト・マネジメントに関する義務違反があったということはできない」とした。そして、「Ｃｏｒｅｂａｎｋ自体が邦銀の勘定系システムに導入するソフトとしての性能をおよそ備えていなかったとは認めることはできないというべきである。」とした上で、プロジェクト・マネジメント義務違反を否定している。
結局、スルガの主張した「基本ソフトであるコアバンク自体が日本のソフトとしては全く使えないものであり、そんなものを提案した事自体がプロジェクト・マネジメント義務違反」等との主張が否定されており、リスクはあるものの、当時としては、ベンダの提案としてあり得るものと判断されたのだろう。
この判断において、控訴審判決は、「システム開発技術等とシステム開発対象の業務内容等について、情報の非対称性、能力の非対称性が双方に在する」と指摘している。ともすると、「ベンダーが専門家でユーザーが素人」と考えがちだが、本判決は、「ベンダーはユーザ業務については素人なんですから、システム開発前段階に分からないこともありますよ」というのを裁判所が認めたということであり、これは非常に重要な指摘であろう。
３．不法行為を最終段階（最終合意書締結段階）で認定
次に、計画・要件定義段階以降では、IBMは、「ベンダとして、スルガに対し、本件システム開発過程において、適宜得られた情報を集約・分析して、ベンダとして通常求められる専門的知見を用いてシステム構築を進め、ユーザーであるスルガに必要な説明を行い、その了解を得ながら、適宜必要とされる修正、調整等を行いつつ、本件システム完成に向けた作業を行うこと（プロジェクト・マネジメント）を適切に行うべき義務を負う」とした。
その上で、本件システム開発についてみると、現行システムの分析を通じて現行システムのボリューム及び特質と、Ｃｏｒｅｂａｎｋの持つ機能との間でギャップがあることが判明してきた。そして、最終合意締結のころには、当初予定していた開発費用、開発スコープ及び開発期間内に収めて本件システムを開発することが不可能であることが明らかとなっていた。そこで、費用を増やすか、スコープを狭めるか、開発期間を増大させるという形での抜本的な見直しが必要となっていた。IBMは、少なくとも最終合意書締結段階ではそれを知っていたとされている。
その上で、IBMとスルガ銀行は、約９０億円でシステムを完成させ２０００８年に稼働させるという最終合意書締結に至った。
この点につき、裁判所は、
IBMは、スルガと本件最終合意を締結し、本件システム開発を推進する方針を選択する以上、スルガに対し、ベンダとしての知識・経験、本件システムに関する状況の分析等に基づき、開発費用、開発スコープ及び開発期間のいずれか、あるいはその全部を抜本的に見直す必要があることについて説明し、適切な見直しを行わなければ、本件システム開発を進めることができないこと、その結果、従来の投入費用、更には今後の費用が無駄になることがあることを具体的に説明し、ユーザーであるスルガの適切な判断を促す義務があったというべきである。また、本件最終合意は、前記のような局面において締結されたものであるから、IBMは、ベンダとして、この段階以降の本件システム開発の推進を図り、開発進行上の危機を回避するための適時適切な説明と提言をし、仮に回避し得ない場合には本件システム開発の中止をも提言する義務があったというべきである。
こう述べた上で、この点を怠り最終合意書を結んだIBMに不法行為が認められるとしたのである。
重要なのは、最終合意書前の段階で、既にIBMが、プロジェクトが大きく傾いていることを知っていたと認定されていたことであろう。もはや、費用、納期、スコープを変えなければ、プロジェクトは失敗に終わることが見えていた。それにも関わらず、従前とほぼ同様の費用、納期、スコープでやるという最終合意書を締結したところにおいて、IBMの落ち度が認められたものであろう*3。
契約違反ではなく、不法行為を認めた点については、「契約関係当事者において、簡単に不法行為を認めていいのか」という意外性もあるだろう。裁判所は、以下のように述べて不法行為でいいと行っている。
契約当事者間においても、損害賠償責任の根拠として、実体法上、契約責任と不法行為責任が競合し得るものであり、この場合に、IBMが主張するような違法性があるときに限って不法行為責任が成立するとの実体法上の根拠はなく、また、そのように不法行為責任の成立が限定されると解することはできない。
要するに、契約を結んでいる会社同士でも不法行為は成立し得るものであり、契約を結んでいるからといって、通常の不法行為より成立が困難になるものではないということである。
４．最終合意書締結以前の報酬は損害にならない！
さて、本事案をウォッチしている読者の皆さんからは、「IBMの不法行為が認められたのは一審判決と同じではないか。なぜ、損害賠償額がそんなに違うのか？」という声が聞こえてくる頃であろう。
重要なのは、以下の一節である。
以上検討したところによれば、本件最終合意締結の段階において不法行為が成立すると認められ、�ないし�の段階（注：それ以前の計画から要件定義までの段階）で締結した各契約に基づき本件最終合意締結直前までに支出した費用については、IBMには、スルガに対し、不法行為（あるいは債務不履行）に基づいて損害賠償する義務は認められないというべきである。他方、本件最終合意締結後に支出した費用については、IBMの義務違反により、必要としない費用の支出を強いられたものと認められるから、IBMは、スルガに対し、不法行為に基づき、その費用相当額の損害賠償をする義務を負うというべきである。
要するに、IBMがどこで不法行為をしたのかといえば、それは、最終合意書を締結する段階であり、それまでは、（理想的にはいかなかったが）過失という程の落ち度はなくプロジェクトを進めて来た。それならば、それまでの作業について、スルガがIBMに払った対価については、返還をさせなくていいだろう。ただし、その後の作業の対価等計約４３億円は払うべきだ。これが、控訴審判決の発想である。
なお、IBMは、その後の作業も含め、最終的に作成した成果物に価値があるとか、スルガにも落ち度があり、それを汲むべきだ等と主張した。しかし、「損害の公平な分担の見地からスルガに斟酌すべき落ち度があったとは認めがたく、本件最終合意締結後の支払額に限ったIBMの損害賠償額から過失相殺をすべき事情があるということはできない。」とか「前記スルガの負担額を超えて、スルガの損害賠償額から控除されるべき利益を得たとは認めることはでき」ないとして、これを否定している。
これに対しては、ユーザーとしては「最終的な合意書締結の段階のミスにより、それまでの作業の成果は無意味になったのであり、代金を返して欲しい！」と思うところであろう。このような点については、過去に東京地判平成１６年９月１６日が、後の契約に基づく作業の債務不履行を理由に、前の契約の代金を損害としてユーザーに返還させていることが気になるが、１つの整理としては、当事者の公平の観点から、スルガの落ち度や、成果物の評価といった観点を織り込んだものとして、「最終合意書作成前後」で損害の範囲を画したといえるのではないか。つまり、確かに、スルガに落ち度がない訳ではないし、相当頑張ってIBMが作業したことも分かる、しかし、IBMのミスのせいで、スルガも大変な損害を被った。そこで、「あんなやり方で最終合意書を作らせ、その後に報酬等を払わせた分は返せ。でも、それ以前はまあ頑張っていたのだから報酬を得てもいいだろう。」という、本件の「落としどころ（筋、すわり）」が先にあり、そこからこのような結論が導かれたのだ、と考えれば、成果物の価値や過失相殺における「奥歯に物の挟まったような」言及について説明がつくのではなかろうか。個人的にいえば、控訴審は、理論的な説明という意味では更なる検討を要するが、少なくとも、一審判決の「１００％IBMが悪い」とでもいうような認定から感じた違和感はなくなっていると感じる。
なお、このように判決は損害額をかなり削減したが、控訴審判決は一方的にIBM に甘いものではない．例えば、最終段階で、別の基本システムを採用することを提案したことについては、
本件システム開発の経緯に照らすと、極めて唐突なものである上、その内容も本件システム開発進行の打開方策としては粗雑なものといわざるを得ず、重要プロジェクトを担うベンダとして不見識、無責任とのそしりを受けてもやむを得ない。
と、かなり強い語気でIBMを批判していることは留意が必要であろう。
5．議事録の重要性
この点は、前の評釈でも論じたとおりであるが、裁判所は、書証、特に、両当事者が確認して作成した書面による証拠を重視する。例えば、ステアリング・コミッティーの議事録について、以下のような記載がある。
以下の認定事実中には、ステアリング・コミッティの議事録に基づいて作業、交渉等の経緯を認定した部分が存する。IBMは、ステアリング・コミッティの議事録に基づいて本件システム開発の経過を認定することについて、同議事録の記載内容はスルガから修正を加えられたものであるとして、作業等の実態を必ずしも反映していない旨指摘している。（略）事録を確定するに当たっては、IBM及びスルガは、議事録によって作業を記録化することの意義を十分に認識しつつ、その内容と表現を検討して、会議の実態を反映したものとして、記載内容を確定させたものと推認することができる。特にIBMはシステム開発を業とする者であり、このような議事録作成の意義と方法を当然熟知していたものといえる。したがって、確定した議事録は、ステアリング・コミッティの作業実態を反映するものとして取り扱うのが相当であるといえ、特段の事情が認められない限り、前記作業の経過内容等については、そこに記載された内容が当該期日におけるステアリング・コミッティにおいて総括されたものと認定するのが相当である。
安易な議事録の記載はダメ、絶対！
まとめ
スルガ銀行事件控訴審判決は、賠償額を約半額へと大幅減額した。
その理屈は、IBMのミスを後の方で認め、「ミス発生前の作業の代金はIBMがもらってもいい」というものである。
法理論的には更なる検討が必要だが、実務としてこのような「落としどころ」になるのは、理解できる。
なお、控訴審判決も、議事録の記載にかなり依拠している。安易に議事録の記載をすると、後で大変なことになるので、慎重に議事録等の書面を作ることが大事である。
