金融再編残酷物語「システム統合の正攻法」

　Day2の大本営発表。

　Day2とは"Project Day 2"のことで、東京三菱とUFJの勘定系を統合させた、史上最大のプロジェクトだ。本書は、日経コンピュータの記事を元に、Day2のケーススタディとして編纂されている。プロジェクトマネジメントとシステム統合の文字通り「生きた教科書」といえる。ただし鵜呑むのは禁止な、経営層の大本営発表を元に作られているのだから。「涙の数だけ強く慣れるよ」（誤字ではない）とつぶやきながら読むべし。

　Day2がいかにデカいかは、次の数字が物語る。

• 11万人月
  
• 2500億円
  
• 開発に3年
  
• 6000人の技術者
  
• 8万人のシステム利用者
  

　比較のために添えておくと、みずほ銀行のシステム統合（2004.12完了）は9万人月、郵政民営・分社化に伴うシステム対応（2007.10完了）は、4万3000人月になる。Day2がいかにケタ違いであるかがよく分かる。これに加え、チーム数は70超、改修対象システムは200以上、開発拠点は22ヶ所に及ぶ。札幌、仙台、千葉、大手町、日本橋、品川、多摩、富山、名古屋、大阪、海を越えて上海、大連、武漢までに至る。

　この巨大プロジェクトを、真正面から正攻法で取り組んだ「計画の勝利」だと手放しで絶賛するのが本書で、「正攻法」は「成功法」のシャレか。

　しかし、わたしは別の見方で読む。Day2は、プロジェクトとしては最悪の経営判断が下されていたにもかかわらず、成功させてしまった事例なのだ。最悪の判断とは、システム統合の方式だ。どちらかのシステムに合わせる片寄せ方式ではなく、元のシステムを残したまま東京三菱系列のシステムを元に差分開発したという。そして、その差分を載せた新システムに東京三菱系（IBM）とUFJ系（日立）を統合したのだそうな。

　あれ？

　事実上IBMへの片寄せ統合となり、日立は掌中の珠を失ったんじゃなかったっけ（ソースは雑誌「選択」2005年5月号の「UFJを失った日立製作所の衝撃」）。その辺のいきさつは金融再編残酷物語（日立の場合）に書いた。メガシステムの再編・統合の場合、片寄せするのは常道。さもなくばブリッジシステムをはさんで「いつでも離れられる」仕掛けを施すもの。最悪なやりかたは、いわゆる「足して二で割る」やつで、仕様やベンダが社間闘争の具になること必至。

　しかし、本書を見る限り、UFJ系（日立）は残しているようだ。たとえば、p.71を参照すると、営業店サーバをデータセンタに集約し、IBMメインフレーム「IBM System z9」4台、日立ブレードサーバー「BladeSymphony」90台に載せ換えている。その際、「営業店サーバを集約する際、アプリケーションには一切手を入れないことだ。営業店サーバのアプリケーションはPCサーバに搭載していたものをそのまま移植することにした」（p.73）とある。これを見る限り、日立系アプリは生き残ったらしい。

　片寄せをしない（よりカネのかかる）統合方式にした必要性を、p.180で経営層に直接ぶつけている。すなわち、「あえて伺うが、2500億円を投じて完全統合する必要はあったのか」という質問に、「経営統合をするならばシステムも統合しなければならない」という"ありき"的発想で答える。完全統合「しない」方法はいくらでもあったし、よりチープで安全に済ますこともできたのに、こんなに銭金がかかるリスキーな方式を選んだのは、どういう根拠に基づくのか？

能力増強とデータ移行は、いわば必要不可欠な作業である。これに対して、商品・サービスの「差分開発」は必ずしも実施しなければならないというわけではない。開発にかかる負荷を抑えることを最優先に考えれば、差分開発を一切しないという考え方も論理的にはあり得る。だが、三菱東京UFJ銀行は、顧客サービスの向上と銀行としての競争力強化のためには差分開発が必要と経営判断し、あえて実施することに決めた。

　太字化はわたし。p.14 の上述を見る限り、差分開発は「やらなくてもいい」という認識はあったようだ。だが、「あえて実施」した真意は別にある。それは、統合における東京三菱とUFJの力関係、優勝劣敗になる。

　もともと「三和（日立）＋東海（日立）＝UFJ」を練成したとき、アウトソーシングの契約金額は10年間2500億円といわれていた。受託と同時に日立キャピタルがUFJ銀行の勘定系システムを保有資産の名目で500億円で購入、さらに勘定系システムを開発してきた合弁会社をUFJ日立システムズに改組したという（ソースは同「選択」）。日立はそこまでUFJに張っていたのだ。

　ここからわたしの憶測になる。統合が俎上に上ったとき、システムが裏付けるサービスとしての優位性は、UFJのほうが上だったのではないか？ATM24時間化、優遇者の手数料無料化はUFJが先行していた（はず）。したがって、レガシー更改が進んでいたUFJ系に「片寄せ」することがもっとも合理的な判断となっていた（はずだ）。

　にもかかわらず、後続している東京三菱系にわざわざ「差分開発」をさせ、新業務のベースラインも東京三菱系に寄せたのは、社間チカラ関係によるのではないか。東京三菱とUFJの合併比率は、1対0.62だった。システムをあわせるということは、業務をあわせるということ、小さいほうに飲み込まれるのは、東京三菱には耐えがたかったのではないか？

　その結果、「やらなくてもいい」開発を行い、新規＋既存が混交した寄木方式をとることになった。Day2は、最悪の経営判断のもとになされ、最高のパフォーマンスを要求されたプロジェクトだといえる。その努力はプロジェクトX級モノで、まさに「経営陣の無茶難題な要求に、現場の怒りは頂点に達した」やね。ただし、「現場の怒り」は本書に一切書いていないので、巨大掲示板などで推してはかるべし（2ちゃんgoogleるなら、"掲示板に戻る"を混ぜる）。

　本書はPMの向こう側、マネジメント向けで、巨大プロジェクトを「任せる」ためにどうすれば良いかが、経営者の視点から記されている。記述が深浅まだらで、網羅的でもないため、経験のない人がドグマ的な何かを求めて読むと失望するかも。

　たとえば、人材確保。「人」を集めるだけではダメで、人が働ける体制を作ることが最重要だと判断しマネジメントはすばらしい。つまり、人をかき集めてオフィスビルに押し込めるのではなく、そのチームが働ける拠点、対応する部門、サポートする部隊、マネジメント要員を作ったのだ。人づくりではなく、チームづくりを念頭においている。

　そのために、オフィス確保の専用部隊（ファシリティマネジメント）を設けたそうな。どの拠点に机やPCがいくつ必要か、テレビ会議システムやLAN設置はどうするか、レイアウト図と体制図を首っ引きで検討し、準備する。集中しすぎてトイレが確保できなくなったオフィスには、ビル保有者とかけあって、トイレを（後付で）設置している。さらに、「3ザル生活」を回避するために奔走し、おいしいお弁当を確保するために役員が試食までしたという（「3ザル」とは「休まザル」「眠らザル」「帰らザル」を指す、デスマーチの典型症状）。努力のかけ方がちょっと違うような気もするが、それだけ「がんばった」んだね。

　さらに、組織作りのポリシーは炯眼だと思った。「利用部門の責任体制を明確化」したという。アタリマエなことなのだが、分かっているマネジメントはかなり少ないのではないか、さらに社内の風当たりも強かったのではないかと勝手に想像している。

　つまり、システム部門と利用者部門をペアリングした体制を作ったのだ。「作る人…使う人」をシメントリカルにしておくことで、システム部門のグループの担当は、相対する利用部門の責任者が分かる。デカいシステムを作るときによくある、誰に話を持って行っていいのか分からないまま作り始めるアンチパターンを回避することができる。「責任者不在」が仕様抜けの落とし穴になるからね。「組織構造をあいまいにしたプロジェクトは、必ず失敗する」は至言だ。

　その一方、役員の思いつきに振り回される「現場の怒り」というか困惑を透かし見る。最たる例が、本番系システムの本番データを使った「実データ実ボリューム」のテストだろう。本番の勘定系システムが1カ月の間にATMから受け付けたすべてのトランザクション処理データをテスト環境に投入し、古いキャッシュカードによるテストを消化したそうな。これは、某役員の「思い」により実現したという。

　古いキャッシュカードのバリエーションテストは全組み合わせを流すことをやっているだろうし、本番以上の負荷に耐えられるかのストレステストもダミーデータで当然やっているはず。にもかかわらず、顧客情報満載の本番データをわざわざ取っておいて、普段はアクセスできない試験チームにさらされる環境に流すのは、正気の沙汰とは思えないハイリスクな行為だ。フツー顧客情報は厳密に分けるものだが、わたしの「フツー」は普通ではないようだ。この中に、「悪のプログラマ」がいなかったことを切に願う。

　大本営発表から、現場の奮闘を測る一冊。