日本IBMとスルガ銀行が2008年から2015年まで争った勘定系システムの開発案件の裁判について振り返ってみましょう。
この訴訟はSI (システムインテグレーション)の発注者が、受注ベンダーを訴えた少し珍しいというか有名な訴訟です。
システム開発を行う発注者、受注者共に過去に学んで新しい発見があるかもしれませんよ。
日本IBMとスルガ銀行のプロジェクトの経緯
日本IBMがスルガ銀行から受注した勘定系システムの開発の経緯は次の通りです。
| 年 | 月 | 概要 |
|---|---|---|
| 2004年 | 9月 | 日本IBMがスルガ銀行から、新システムを95億円で開発するとした基本合意書を交わす。 要件定義の開始。 |
| 2004年 | 12月 | 基本合意書②を交わす。 |
| 2005年 | 9月 | 日本IBMとスルガ銀行、新システムを89億7080万円で開発し、2008年1月に稼働させるとした最終合意書を交わす。 |
| 2006年 | 2月 | 1回目の要件定義を開始 (これは、1回目ではなく、おそらく2004年9月からの要件定義のやり直しで2回目) |
| 2006年 | 5月 | 1回目の要件定義がうまくいかず、 2回目の要件定義 (Requirement Definition) を開始 (これは実質、3回目の要件定義) |
| 8月～9月 | 要件定義が難航する。 日本IBMは、稼働の延期を提案するも、スルガ銀行は提案を拒否。 |
|
| 11月 | 日本IBMとスルガ銀行でスケジュールについて協議を重ねる。 日本IBMは、全面稼働を2008年12月に延期することを提案し、スルガ銀行は了承する。 |
|
| 2007年 | 4月 | 日本IBMが、採用するパッケージを変更したいと提案するも、スルガ銀行は提案を拒否。 |
| 5月～7月 | スルガ銀行が、日本IBMに開発の中止と個別契約の解除を通知する。 |
プロジェクトの進行が混とんとしていますね。
訴訟で判明しますが、上記の通り要件定義を3回繰り返したとか。
要件定義を3回も繰り返したのは、スルガ銀行が何度も過度の要求をしたのでしょうか？
それにしても、IBMから当初提案したパッケージの変更提案したというのは少しありえないかと。
よほどスルガ銀行から想定外の要求があったのか、それとも単なるIBM側の見積もりミスだったのか？
当初提案したパッケージはIBMのNEFSS/Corebankと思われます。
日本IBMとスルガ銀行の訴訟の経緯
スルガ銀行が日本IBMに対して起こした訴訟の経緯は次の通りです。
日本IBMも当然ながら、スルガ銀行に対して反訴します。
| 年 | 月 | 概要 |
|---|---|---|
| 2008年 | 3月 | スルガ銀行が基幹システムの開発に失敗したとして日本IBMに111億700万円の損害賠償を求める訴訟を東京地方裁判所に提起。 |
| 4月 | 日本IBMはシステム開発の難航はスルガ銀行に原因があったと反論する答弁書を提出する。 第1回の口頭弁論が行われる。 |
|
| 6月～7月 | 第1回～第2回弁論準備手続き。 | |
| 8月 | 日本IBMがスルガ銀行に対して反訴する。システムインテグレーションに関する未払い代金など、13億7400万円を請求。 | |
| 9月～11月 | 第3回～第4回弁論準備手続き。 | |
| 2009年 | 1月～4月 | 第5回～第7回弁論準備手続き。 両社ともシステム開発に詳しい複数の専門家の意見書を提出する。 |
| 3月 | 日本IBMが反訴の趣旨などを変更する。 開発中止でパッケージを横展開できなくなったとしてスルガ銀行に125億円を請求。 |
|
| 6月～12月 | 第8回～第11回弁論準備手続き。 | |
| 2010年 | 2月～3月 | 証人尋問 (合計3回) |
| 2011年 | 7月4日 | 口頭弁論。 要件定義の成果物を再利用できるかが争点になる。 |
| 10月31日 | 結審 |
この辺りを調べてみて印象的だったのが、2010年3月、日本IBMの金田治副会長の証人尋問での発言です。
「議事録や提出資料の内容を、スルガ銀行にとって都合がいいように変更するよう求められた。『日本IBMが悪かった』という表現を議事録などに織り込むようにも迫られた」
議事録の改変は実際に行われたのかもしれないけれど、議事録そのものは証拠になるので、日本IBMにとっては不利。
あとでいくら改変要求されたと主張しても、要求を認めて議事録になっているので、改変されたことを主張するのは無理があるかなぁと。
「スルガ銀行は最終合意書に記した金額を既得権として考えているようだった」
これは、見積もり時、あるいは注文時によくある間違い。
90億円もの見積もりなら、全体の正確な工数がわかっている人は誰もいないのだから、金額の妥当性なんてわかるはずがない。
要件定義してみて全体の金額がぶれるのは当然。
契約書には、90億円に対してなんらかの前提事項が書いてあるんじゃないかなぁ。
要するには、要件定義を行ってみて開発要件が当初の想定の範囲内かどうか。
この判定は難しいね。
スルガ銀行は想定の範囲内と言うだろうし、IBMは想定の範囲外と言うだろう。
また、次の発言も興味深い。
「スルガ銀行は日本IBMを常に業者として扱い、両社は主従関係にあった。システム開発プロジェクトを成功させるには、お客様とITベンダーが対等な関係を構築することが欠かせないし、そうした関係を目指したが、そうはなれなかった」。
これについては、全くその通り。
ここにも、書きました。
実際の所、多くのお客様はITベンダーを業者として扱っていますね。
ベンダー側が単なる工数提供(SES)のプロジェクトならそれでいいんですが、請負契約なら、対等になれないとなかなかプロジェクトは成功しないです。
SESと請負契約については以下の通りです。
ちなみに、日本IBMの反訴資料によれば、スルガ銀行と日本IBMのプロジェクトは邦銀標準の金融パッケージを開発するというIBMの「NEFSSプロジェクト」(次世代金融サービス・システム(Next Evolution in Financial Services Systems) の一環だったそうです。
このプロジェクト、中核部分に米フィデリティ・インフォメーション・サービス（FIS）のソフトウエア「Corebank」(コアバンク)を活用したことから、邦銀標準パッケージは「NEFSS/Corebank」と呼ばれたそうです。
フィデリティ・ナショナル・インフォメーション・サービス（Fidelity National Information Services, Inc.）は、米国フロリダ州ジャクソンビルに本社を置く、銀行・決済技術の供給事業を行う企業です。
聞いたこともないですね。
スルガ銀行の勘定系システム刷新は、NEFSS/Corebank の第1号案件で、日本IBMはスルガ銀行のプロジェクトを通じてNEFSS/Corebankに邦銀の標準的な業務プロセスを組み込み、広く邦銀に販売する計画だったようです。
この話が本当なら、怖いと思いますけどね。
スルガ銀行は、なんで実績のないパッケージの第1号の客になったんだろう？
私なら1号案件の客にはなりたくないです。。
何が起こるか怖いので、私が客なら、ベンダーにもっと実績のあるパッケージをお願いしますね。
ちなみに、スルガ銀行ですが、IBMとの契約を破棄した後、日本ユニシスと契約してBankVisionという勘定系のシステムを導入しました。
このシステムは、2014年1月6日に無事にリリースしています。
日本IBMとスルガ銀行の訴訟の判決の経緯
それでは、日本IBMとスルガ銀行の訴訟の結果を見てみましょう。
| 年 | 月 | 概要 |
|---|---|---|
| 2012年 | 3月29日 | 東京地裁は日本IBMがシステム開発の「契約上の付随義務」に違反したとみなし、民法第709条の「不法行為」に当たると認定した。 日本IBMに約74億円の支払いを命じる判決。 日本IBMは控訴。 |
| 2013年 | 9月26日 | 東京高裁、日本IBMの賠償を41億に減額する判決。 両社が上告。 |
| 2015年 | 7月9日 | 最高裁第2小法廷は双方の上告を退ける決定をし、日本IBMに約41億7千万円の支払いを命じた二審の東京高裁判決が確定した。 |
うーん、減額はあったものの、スルガ銀行側の勝ちと見るのが一般的な見方でしょうかね。
東京地裁は、合計3回実施したシステムの要件定義が迷走したことを判断根拠としたそうです。
日本IBMは1回目の要件定義では、現行システムを解析して機能を洗い出す現行踏襲型の手法を採りました。ただ、IBMがFISの社員などCorebankを熟知する人材を参加させなかったことから、「フィット＆ギャップ」(いわゆる要件定義)と呼ぶ分析を実施できませんでした。
このため2回目、3回目に改めてフィット＆ギャップ分析を行う羽目になったとしたそうです。
Corebankは海外製パッケージのため、邦銀業務に合わせる場合、システムの要件が大きく膨れ上がるリスクがあります。それにもかかわらず、Corebankを熟知した人材を投入せず、現行踏襲型の手法を採ったなどの事実から、東京地裁は「日本IBMがCorebankの機能や充足度、その適切な開発方法等についてあらかじめ十分に検証又は検討したものとはいえない」と判断し、システム開発を受託したITベンダーの責務であるPM (プロジェクトマネジメント) 義務に違反したと認定しました。
PMの義務違反で損害賠償とか聞いたことはないけれど、初めて使うパッケージで、初めてのシステム開発なら、「開発元の中身の分かる人間を連れてこい！」っていう意見も分かるような。
それにしても、スルガ銀行、最初の要件定義で「こりゃうまくいかない」って思わなかったのでしょうか？
IBMのPMがダメ！って分かればもっと早く次の手が打てたと思うんですけどね。
以下は判決文の引用です。
IBMは，スルガと本件最終合意を締結し，本件システム開発を推進する方針を選択する以上，スルガに対し，ベンダとしての知識・経験，本件システムに関する状況の分析等に基づき，開発費用，開発スコープ及び開発期間のいずれか，あるいはその全部を抜本的に見直す必要があることについて説明し，適切な見直しを行わなければ，本件システム開発を進めることができないこと，その結果，従来の投入費用，更には今後の費用が無駄になることがあることを具体的に説明し，ユーザーであるスルガの適切な判断を促す義務があったというべきである。また，本件最終合意は，前記のような局面において締結されたものであるから，IBMは，ベンダとして，この段階以降の本件システム開発の推進を図り，開発進行上の危機を回避するための適時適切な説明と提言をし，仮に回避し得ない場合には本件システム開発の中止をも提言する義務があったというべきである。
このPMの注意義務違反っていうのは、SI事業の現場をよくわかっていない裁判官の意見。
はっきり言って、受注したベンダー側が途中でシステム開発の中止を提言できるわけがない。
まぁ、IBMから2007年4月に採用するパッケージの変更を依頼していたわけですから、実質、これはシステム開発のやり直し提案と言ってよいでしょう。
パッケージ変更の提案の際に、IBMから追加費用を要求したのは明らか。
一方、スルガ銀行も、ここまでかなりのお金は払ってきたでしょうから、簡単には引き下がれない。
そこで、訴訟になったという訳でしょう。
本訴訟の判決は一審ではIBMが74億円の支払いを命じられました。
これはほぼ一方的にIBMが悪いという趣旨の判決と言ってよいでしょう。
ただ、二審、三審では42億円に減額されています。
この点の理由は「最終合意締結直前までに支出した費用については、IBMには、スルガに対し、不法行為（あるいは債務不履行）に基づいて損害賠償する義務は認められない」とのことです。
つまり、一部分ではありますが、IBMの主張が通った点はベンダー側としては意味のあることです。
要は、最終合意まではIBMも落ち度はなくプロジェクトを進めていた。
最終合意以降はIBMに落ち度があるというのが判決の判断。
ちなみにIBMがスルガ銀行に別パッケージを提案したことに対して以下の判断が出ています。
本件システム開発の経緯に照らすと、極めて唐突なものである上、その内容も本件システム開発進行の打開方策としては粗雑なものといわざるを得ず、重要プロジェクトを担うベンダとして不見識、無責任とのそしりを受けてもやむを得ない。
この判決文は、IBMのPMに「本件システム開発の中止をも提言する義務」があったという裁判所の判断と一見矛盾するようではありますが、もし、ベンダーから唐突にパッケージを変えてやりなおしましょうって、言われたとしたら、怒るわな。
まとめ：日本IBMとスルガ銀行の訴訟に思うこと
今回、IBMが提案したNEFSSは、SAPのようなバリバリのパッケージではないようで、カスタマイズありきでJava EEで出来たフレームワークのようです。
サービス指向アーキテクチャ (SOA) に基づくシステム構築が可能であり、顧客単位で複数の金融商品の口座をまとめて管理するなどの特徴を備え、当時の邦銀の勘定系システムと比べて新規性があったようです。
しかし、柔軟性はかなりあったはずですが、IBMが要件定義に3回失敗したあとで、スルガ銀行に対してパッケージ変更を提案したぐらいなので、スルガ銀行から相当な無理難題があったのか、あるいは、NEFSSパッケージそのものに難があったのか。。。？
ところで、NEFSSの国内実績としては、スルガ銀行以外に、東京スター銀行も開発を途中でストップしています。
一方、住信SBIネット銀行が、NEFSSを使って2007年9月にサービスを開始しています。
これよく稼働しましたね。
というか、住信SBIネット銀行、よく採用したなぁ。
多くの銀行側の担当者の本音としては、IBMのNEFSSは怖くて採用できないっていうのが本音だと思うけど。
以下は開発ベンダー側でPMをやったことのある私が思うシステム開発に対する感想。
多くのお客さんは、契約すれば丸投げしたがります。
また、お客さんはお金を払う側であることを強調したがります。
まるで自分は神様であると言いたがりますね。
お客が丸投げするのはわかるし、ありがたく契約しているならできる限りの対応するのは当然だろう。
ただ、契約形態はよく見ておかなければならないです。
請負契約なら、成果物保証をしなければならない。
一方、工数提供なら、最大限の努力でよい。
ちなみに、私が会ったお客さんの中には、工数提供プロジェクトなのに、何でもかんでもお願いしたり、ベンダー側の責任にするお客さんもいます。
自身が休日に働いていたり、プロジェクトが遅れているので、工数提供するベンダー側が土日に出てきて当然とか考えているやつは結構多い。
特に大企業の偉い人の中には、ベンダーを足で使おうと無茶な言いがかりをするやつもいますね。
これには困ったものである。
二度と会わない客なら、契約をたてに頑として拒むのもよいけれど、今後も付き合いたい客ならなんだかんだと引き受けざるを得ないね。。
それでは請負契約ならどうでしょうか？
請負契約でも、実際の開発作業が見積もり時の想定の範囲内か範囲外かの判断は難しい。
IBMとスルガ銀行で90億円の合意がどの範囲であったかは知る由もないが、スルガ銀行はプロジェクトが延期しようと、それ以上払う気はサラサラなかったんだろう。
客の立場ならわからなくものない。
両者、喧嘩別れする前に、なんとか歩み寄る努力をすべきだったんだろうけど、おそらく両者の体質が相容れなかったんだろうね。
さて、請負契約で火の粉が降りかからないためにはどうすればよいか？ですが。。。
それには相手の社風や担当者の性格をよく見極めておかないといけない。
社風は結構大事。
偉い人が偉そうな態度をとる人なら、だいたい、担当者レベルでも偉そうな態度をとる人が多い。
こんな会社とは付き合わない方がよい。
それでも契約する必要があるなら、なるべく開発の局面ごとに契約すべきだ。
例えば要件定義のみを3人月で契約して、その後、うまくいったら基本設計に進んで契約するという具合だ。
これなら大きく失敗することもないだろう。
さて、IBMとスルガ銀行、はたして両者は訴訟からそれぞれ学ぶものがあったんでしょうか。
たぶん、スルガ銀行は、IBMとの契約破棄後に契約した日本ユニシスには、ベンダーにきつく当たったり、無茶な要求をしないように譲歩したんだろうなと想像できます。
要件定義は難しい。下記も参考にしてください。
コメント
[…] […]
[…] ・https://urashita.com/archives/19270 […]