システム開発デスマーチがもたらすものは泥沼の訴訟合戦という話(2021/06/20)

anonymous female tourist photographing seascape on sandy coast
Photo by Daniel Eliashevsky on Pexels.com

システム開発トラブルの責任の押し付けあいから訴訟に発展

システム開発が頓挫したとして、野村ホールディングス(HD)と野村証券が日本IBMを相手取り計約36億円の損害賠償を求めた裁判がありました。この裁判は、2019年3月の一審判決ではシステム受託者であった日本IBMに約16億円の支払いを命じたのですが、控訴審の東京高裁は2021年4月21日の判決で野村側の請求を棄却するという一転逆の結論となりました。さらに、野村側に未払いの業務委託料など約1億円の支払いを命じるおまけ付きです。一審判決が覆され、野村2社の逆転敗訴となったのか、これは世の中が正当な取引を逸脱したトラブル施主に厳しい目を向けてきていることと無関係ではないと思います。

名門企業同士による泥沼の裁判のようですが、この構図は、何でも言いたい放題の施主(発注側)と、何でも聞かないといけない立場の弱い受託側との力関係によってもたらされた不幸と筆者は見ています。

このシステム開発プロジェクトの始まりから見てみます。2010年に始まったこのシステム開発は、判決文の事実にん手によると、野村証券は当時、老朽化した基幹システムを2013年までに全面刷新する計画を進めていました。併せてシステム開発を野村総合研究所(NRI)に依存する体制からの脱却を狙っていました。内々で開発するとどうしてもなあなあの品質の悪いものが出来上がって、さらに施主側も厳しいことをいいにくいという企業風土があったようです。この点、最近また繰り返されたみずほ銀行のシステムトラブルにも見て取れます。内に甘く外に厳しい、典型的な内弁慶(弁慶に失礼ですね)な企業体質だったのでしょう。

さて、野村証券のオフィスに常駐していた日本IBMの社員はこの動きを察知し、野村証券に食い込むチャンスと捉えました。もちろん、営業担当者としては素晴らしい動きなのですが、まさかこれが毒まんじゅうだったとは知るよしもなかったでしょう。

ノウハウがない状態で大規模な基幹システムの開発を一から手掛けるのは容易ではありません。そこで日本IBMは、基幹システムの刷新と同時に再構築が予定されていた「ラップ口座」向けフロントシステムの受注に狙いを定めました。さすが、ビッグブルーと呼ばれて世界のIT産業の先駆けになった会社です。かつては世界一の名前をほしいままにしていた、インターナショナルビジネスマシンズ。略してIBMのネームバリューに劣らない狡猾かつ実際的な判断です。ラップ口座というのは、個人が資産運用を証券会社に丸投げ、一任する金融サービスのことでありますが、現行システムはNRIが手掛けたもので、ランニングコストが高くありていに言えば不評でした。

日本IBMは野村証券に営業攻勢をかけ、NRIとのコンペを経て2010年11月に新システムの開発に関する契約を締結しました。そして、スイスの金融系ソフト大手テメノスが開発したパッケージソフト「Wealth Manager」をカスタマイズして導入し、2013年1月に本稼働を迎える計画としました。しかしながら、この計画の実行に向けて、これから起こる困難について、両者はこのとき知る由もなかったのです。

要件定義書にない追加要件が続々と野村證券からもたらされる

野村証券と日本IBMは要件定義に入る前にPoC(概念実証)のフェーズを設け、システムの利用者である投資顧問部の担当者らを交えて実機を使った検証を実施しました。同フェーズを受け、日本IBMは検討の継続が必要な項目は残ったものの、パッケージソフトを使った開発と、2013年1月の稼働は可能と判断。後に要件追加を多発する投資顧問部の担当者X氏も検証には参加していたが、この時点では同氏が担当する業務の複雑さや、大幅なカスタマイズが必要になることまではほとんど共有されていなかった。

その後、野村証券側による要件定義の作成を経て、2011年4月から概要設計に入りました。この時点でのスケジュールは同年6月までを概要設計とし、2012年3月までを設計・開発と連結テスト、同年4月以降を総合テストと運用テストなどとしていました。しかしながら、一度決まった要件定義書にまったく存在しない、追加の要件が野村證券側から多発したのです。

これは、熱々のうどんを頼んでおきながら、途中からざるそばに注文変更するようなもので、受け手側としては到底受けいられないものだったはずです。しかしながら、必死に営業して取った新規案件の手前、日本IBM側も営業担当に押し切られる形でずるずると後出しジャンケンの案件追加(仕様変更)を受け入れてしまいます。こうなると、そもそも熱いうどんが食べたかったのか、はたまたざるそばなのか、いやいや冷麺だろ、というように構想は迷走していき、結果、何の料理ともしれない、よくわからないシロモノが出来上がり、さすがにそんなものは受け入れ検証で弾かれるので、その結果何も得られなかったと野村證券側が怒って支払いをしなかった、というようなことのようです。

唯々諾々と受け入れてしまった日本IBM側にも責任はありますが、やはりそもそもうどんを頼んでおきながら、その後いろいろ注文を変えた野村證券側の方が責任が大きいと裁判所は判断したということです。今後は、業者だからといって何でも無理が通るわけではないという意味で、非常に意味がある判決だったと思います。

こちらからの解説は以上です。