野村が日本IBMに逆転敗訴
2012年11月、１つのプロジェクトがシステムの完成を見ずに中止された。野村證券がラップ口座向けに日本IBMと進めていたシステム開発プロジェクトである。この事例に、デジャブ（既視感）を覚えた方も多いのではないだろうか。パッケージソフトのカスタマイズによるシステム開発プロジェクトが頓挫した、その原因が
- ベンダー側のプロジェクトマネジメント不足
- 発注者の協力不足（カスタマイズに関する要件、要望が固まらず延々と仕様変更が続く）
のどちらにあるのかが争われる典型的なパターンである。
似たような裁判には旭川医科大学vs NTT東日本（ベンダーのNTT東日本勝訴）、スルガ銀行vs日本IBM（発注側のスルガ銀行勝訴）があるが、いずれも、パッケージソフトのカスタマイズ、という点が共通している。
本件（野村証券＊vs日本IBM）では、一審と控訴審で判決が逆転し、控訴審では野村證券に1億円の未払い報酬の支払いが命じられている。どちらに責任があるのか、因果関係に関する判断は一筋縄ではいかないことがわかる。
＊裁判では野村ホールディングスと野村証券が訴えを起こしているが、ここではわかりやすくするため野村證券で統一する。
このニュースに関連してSNS等にあがっている多数のコメントを「感情分析AI」を使って分析を行うと、怒りや悲しみの感情が強く、顧客の仕様変更要求に苦慮するベンダーに共感するコメントが多いことがうかがえる。ただ、判決を見る限り、ことは一方的にどちらが悪いと判断できるほどシンプルではないかもしれない。
発注側とベンダーのイシューは同じだったのか
そもそもラップ口座とは何か。野村證券のホームページによれば、顧客にかわって野村證券が資産運用をする「投資一任サービス」である。口座は数種類あるが、契約金額が500万円、3,000万円と、ある程度まとまった資金を持っている顧客がターゲットとなるサービスだ。
ことの発端はこうだ。野村證券はバックオフィス業務（事務や会計管理などの業務）の情報システムをNRI（野村総合研究所）のSTARシステムへ更新するにあたり、老朽化していたラップ口座向けのフロントエンド業務（顧客対応などの対外業務）のシステムも更新することになった。
野村グループのNRIとのコンペの結果、スイスTemenos社のパッケージ”Wealth Manager”(WM)のカスタマイズ導入提案をした日本IBMの提案が採用された。
新聞記事、および一審の判決文によれば、その後の展開は以下の通りである。
これを見ると、発注者側の野村が要件をなかなか確定できず、当初想定のスケジュールより、要件定義が大幅にずれ込んでいることがわかる。一方、ベンダー側のキーパーソンが相次いで離脱する状況にあり、プロジェクトマネジメントも大変であったろう、ということが想像できる。
以下は、報道、判決文などから鈴木の推論であり、関係者からはいろいろと反論もあると思う。その点はご容赦いただきたい。
そもそも何がプロジェクトの破綻に効いていたのか、裁判所の判断も分かれるように、主因を特定することは難しい。ただ、そもそもの問題の発端はイシュー（答えるべき問い）の設定が同床異夢だったことにつきるのではないだろうか。両者のイシュー設定を思いっきり単純化すると…
例えば、現行業務をそのままシステム化、という野村證券サイドの意識は、報道にあるように、対象となる５万口座以上のうち、たった14口座を対象とした処理の手作業化（システム化から除外）による工数削減についても担当者の猛反発があり実現できなかった、という話に象徴的だ。
多くの場合、業務は過去の経緯などで必ずしも最適化されておらず、いわば、獣（けもの）道のようになっていることが多い、例えて言うと、獣道をそのまま舗装するか、いや、そもそも獣道ではなく、新たに高速道路をひくか、的な問いの違いと言っていいかもしれない。
現実的な解は獣道と高速道路のスペクトラムの間のどこかにあるのだろう。
この同床異夢をうまくマネジメントできなかった、となればベンダーのプロジェクトマネジメントに原因があった、という判断になる一方、この同床異夢のもと、無理な仕様変更要求を繰り返してベンダーに十分に協力しなかった、となれば発注者側の協力義務違反、となると考えられる。
本件でも一審判決ではプロジェクトマネジメントに主因を指摘し、日本IBMに対して約16億円の支払いを命じたが、控訴審ではむしろ野村側の協力が十分ではなかったとして、野村側に約1億円の支払いを命じている。
イシュー設定の難しさ
■同床異夢なイシュー 実に多様な人の思考
グロービス経営大学院では問題解決に関する思考法として、「クリティカルシンキング」「テクノベートシンキング」「デザイン思考」という3つの科目を提供しているが、どのアプローチでも最初に重要とされているのが「イシュー（問い）の設定」である。ただ、このイシュー設定は言うは易く行うは難し、で特にチームで行動する際にイシューを共有することは意外と難しい。
実際、クラスでも学生に「そもそもこのケースのイシューって何だと思う？」と問うて、書き出してもらうことがよくある。そして書き出された内容がバラバラであることにみんなが驚く、ということが繰り返されている。授業では同じケース教材を読んで、シラバスに問いが記述されているにもかかわらずだ。
ハイコンテキストな日本社会では、言葉にしなくても他の人も同じ考えだろう、と勝手に思いがちであるが、クラスでの経験から見る限り、人の思考は思いのほか多様だ。目の前にある情報だけでははく、それまでの経験や持っている知識が思考に大きく影響するからだろう。イシューについてもしっかり言語化して共有しないと実は同床異夢ということになりかねない。
■手段のイシュー化
イシュー設定に関してよくあるもう一つの落とし穴は、手段のイシュー化（あるいは手段の目的化）である。パッケージソフトのカスタマイズ、ということで思い出されるのは、1990年代後半に巻き起こったERP（統合基幹業務システム）パッケージソフト導入狂騒曲だ。
当時、ERPが競争力の鍵だ、という言説がビジネスメディア上にもあふれ、多くの企業がとりつかれたようにERP導入を志すもプロジェクトの苦戦や失敗が相次いだ。このあたりの経緯は楠木健さんと杉浦奏さんの『逆・タイムマシン経営論』（日経BP社）に詳しい。楠木さんたちは文脈や目的、本来のイシューを無視して目をひくテクノロジーや経営トレンドの導入に飛びつく、ありがちな落とし穴を象徴的に「飛び道具トラップ」と呼んでいる。
ERPという言葉を、AI、DXと置き換えればいまでもそのまま通用するストーリーだ。
「とにかくAIを入れろ」「DXするんだ」といったメッセージは、まさに手段の目的化であり、ERPがそうであったように、その行く末が見えている、といってもいいかもしれない。AIもDXも手段に過ぎず、何が本当のイシューなのかを見極めることが重要になる。
実は（手段である）思考法についても同じような手段の目的化のリスクがある。書店には○○思考、といった新しい（？）思考法の本が毎年並ぶ。
「この思考法を知らないと時代遅れ」的なキャッチコピーをみると、新しく出た思考法の方がいいのではないか、新しい思考法を使えば問題解決できるのではないかと考えがちだ。
既述の通り、グロービスでもクリティカルシンキング、テクノベートシンキング、デザイン思考などいくつかの思考法を教えているが、これはイシューの種類によって適切な問題解決手法、思考法があるということに他ならない。
例えば、
クリティカルシンキング：人間の脳の認知能力に合うよう、枠組み等を活用して情報を絞り込んで問題解決を行う。 論理思考をベースにした考え方で多くのイシューに適用可能で汎用性が高い思考法。
テクノベートシンキング：大量のデータとAIを駆使することで、脳の限界を超えて個別化して問題解決する思考法。例えばネット上の個別化したレコメンデーションによる売上向上など。
デザイン思考：顧客起点でイシュー設定し、五感や感性を最大限活用することで問題解決を行う思考法。例えば、新サービス／製品開発などに向いている
思考法も解くべきイシューの内容、文脈によって使い分ける必要があり、これを無視して新しい思考法に飛びついても問題解決はおぼつかない。手段のイシュー化、目的化にならぬよう、何がイシューかを見極め、適切な思考法で考えたい。
“野村、日本IBMに逆転敗訴”というニュースをもとに思考法でもっとも大事かつ難しい“イシュー”についてみてきた。訴訟にみるように、スタート地点でのイシュー設定のかけ違い、同床異夢は、うまくマネジメントできなければ致命的なダメージを与えてしまう。しっかり関係者でイシューを言語化して共有することが不可欠だ。
（執筆者：鈴木 健一）GLOBIS知見録はこちら
