システム開発が頓挫したとして、野村ホールディングス（HD）と野村証券が日本IBMを相手取り計約36億円の損害賠償を求めた裁判。2019年3月の一審判決では日本IBMに約16億円の支払いを命じたが、東京高裁は2021年4月21日の控訴審判決で野村側の請求を棄却した。逆に野村側に未払いの業務委託料など約1億円の支払いを命じた。なぜ一審判決が覆され、野村2社の逆転敗訴となったのか。裁判記録を基に、控訴審判決の経緯を読み解く。
名門企業同士による泥沼の裁判に発展したシステム開発プロジェクトの始まりは2010年に遡る。判決文の事実認定によると、野村証券は当時、老朽化した基幹システムを2013年までに全面刷新する計画を進めていた。併せてシステム開発を野村総合研究所（NRI）に依存する体制からの脱却を狙っていた。野村証券のオフィスに常駐していた日本IBMの社員はこの動きを察知。野村証券に食い込むチャンスと捉えた。
ただ、ノウハウがない状態で大規模な基幹システムの開発を一から手掛けるのは容易ではない。そこで日本IBMは、基幹システムの刷新と同時に再構築が予定されていた「ラップ口座」向けフロントシステムの受注に狙いを定めた。ラップ口座とは、個人が資産運用を証券会社に一任する金融サービスである。現行システムはNRIが手掛けたもので、ランニングコストが高く新システムの導入が検討されていた。
日本IBMは野村証券に営業攻勢をかけ、NRIとのコンペを経て2010年11月に新システムの開発に関する契約を結んだ。スイスの金融系ソフト大手テメノスが開発したパッケージソフト「Wealth Manager」をカスタマイズして導入し、2013年1月に本稼働を迎える計画だった。同開発プロジェクトが後々、波乱を巻き起こすことになる。
要件定義書にない追加要件が続々
野村証券と日本IBMは要件定義に入る前にPoC（概念実証）のフェーズを設け、システムの利用者である投資顧問部の担当者らを交えて実機を使った検証を実施した。同フェーズを受け、日本IBMは検討の継続が必要な項目は残ったものの、パッケージソフトを使った開発と、2013年1月の稼働は可能と判断。後に要件追加を多発する投資顧問部の担当者X氏も検証には参加していたが、この時点では同氏が担当する業務の複雑さや、大幅なカスタマイズが必要になることまでは共有されていなかった。
その後、野村証券側による要件定義の作成を経て、2011年4月から概要設計に入った。この時点でのスケジュールは同年6月までを概要設計とし、2012年3月までを設計・開発と連結テスト、同年4月以降を総合テストと運用テストなどとした。
だが、概要設計フェーズの開始直後から暗雲が漂い始める。要件定義書にない追加要件が野村証券から多発したのだ。
