委託先への仕様丸投げで招いた失敗
~事例から「他山の石」としていただきたいこと~
システムの更改はどこの業界でも発生していることであるが、お金を出すことでシステム仕様の決定権まで委託してしまった結果、利用者が使えないシステムとなり作り直しとなってしまった。
野村証券「ラップ口座の刷新」
DX戦略…「ラップ口座」の開発委託
野村証券と野村ホールディングスは、資産運用を証券会社などに一任する「ラップ口座」の開発を日本IBMに委託した。
日経コンピュータの記事「海外製パッケージ導入に失敗 33億円のIT訴訟に発展」によると野村証券は2008年頃から基幹系システムの刷新計画を進めており、ラップ口座のフロントエンドシステムの開発については「SaaS(ソフトウエア・アズ・ア・サービス)やパッケージソフトを活用してIT費用を抑える方針を打ち出した」(内部関係者)。
日本IBMはスイスの金融系ソフト大手のテメノス社が開発した「WealthManager」というラップ口座向けパッケージソフトの導入を提案し、野村はその提案で契約を結んだ。
失敗事象…9年におよぶ法廷闘争
野村證券と野村ホールディングスは2013年11月に日本IBMを提訴した。訴状によると「日本IBMは開発の過程でスケジュールの遅延が繰り返したうえ、要員を十分な引き継ぎなしに頻繁に交代させた。その結果、テスト工程で問題が顕在化。十分な品質のシステムを完成できる見通しが立たなくなり、野村はプロジェクトの中止を日本IBMに伝えた」という。
これに対して日本IBMは、システムは完成間近であって、野村側が一方的にプロジェクトを打ち切ったと反論し、真っ向から争う姿勢を見せた。
裁判では東京地裁は日本IBM側に原因があった可能性が高いと、野村の勝訴としたが、東京高裁では一転して野村側に責任があるという判決になった。最終的には2021年末までに野村側が上告を取り下げ、日本IBMの勝訴が確定した。足かけ9年の争いであった。
以下では日経クロステックの記事「野村HDが日本IBMに逆転敗訴のワケ、『工数削減に応じず変更要求を多発』と指摘」から、判決の経緯の要点を記す。
2019年の一審判決で、東京地裁は開発遅延の主因を「テメノスの要件・カスタマイズ量の把握不足による可能性が極めて大きい」 とした。把握不足に陥ったのは日本IBMとテメノスとの連携に問題があった可能性が高いとし、日本IBMは「ベンダーとしての通常の注意を欠いたものと言わざるを得ない」とした。野村側の一部の請求を認め、日本IBMに約16億円の支払いを命じた。
一方、控訴審判決では、プロジェクト遅延の原因は「野村証券が仕様の変更要求を繰り返したことだ」とした。仕様変更によって作業の手戻りなどが増え、日本IBMの工数削減提案にも十分に応じなかった。「要件定義書に記載のない新業務要件として四半期リバ ランスを要求」「概要設計フェーズ(2011年6月まで)のヒアリングの機会にIBMに説明しておくことができた要件を、この段階(2011年7月下旬)で新たに持ち出し」、など野村側から変更要求が繰り返されたことが判決文にも記されている。
仕様変更はいったんシステムを完成させてサブシステム間の連結テストを開始する時期になっても続いた。「時機に後れた多数のCR(変更要求)は、プログラム製作作業時間確保の不十分と、これに伴う納品の遅れや品質確保の不十分、ひいてはテスト開始の遅れやテスト結果不良の主要な原因の一つとなった」(判決文)。
日本IBMはある時期に仕様の凍結を提案したが、新たな機能追加の要求はプロジェクトの中止が決まるまで続いたという。
要件定義書を策定したときと比べて2011年7月には新たな開発が必要な数が倍以上に膨れ上がっていた。日本IBMは「概要最適化 フェーズ」を設けて工数を削減することを野村側に提案したが、業 務部門の担当者の猛反対にあって実現しなかった。
東京高裁は、プロジェクトの途中段階では日本IBMが契約上の債務を完了していたと判断した。最終段階で作業の中止を判断したのは野村証券であり、日本IBMには債務不履行はないと結論づけた。
《最新のDX動向・人気記事・セミナー情報をお届け!》
≫≫≫DXナビ メルマガ登録はこちら