企業が合併、経営統合したときにやるべきことは新しい経営方針や戦略の策定、経営幹部の人事、組織の再編、営業拠点や工場の統廃合、商品やサービスの統廃合、事務処理の統一、給与を含む人事体系の一本化、そして情報システムの統合がある。
この中で最も面倒なのが、情報システムの統合。なぜなら、それ以外の業務の統合や一本化が終わってはじめて、情報システムの統合ができるからだ。企業の情報システムは、その企業の業務のやり方と表裏一体の関係にあり、業務の一本化が終わらないと情報システムを統合できない。
日本の勘定系システムは世界を見わたしても例がないほど複雑かつ巨大なものである。その多くは1980年代後半に完成し、その後、営々とシステムを構成するコンピューター・プログラムを改修してきた。勘定系システムは業務と表裏一体であるので、業務の変化に合わせて修正し続けなければならない。
「本稼働から15年あまりが経過した勘定系システムは都市銀行の場合、利用しているコンピューター・プログラムを見ると、全体で1億行に迫るまで膨らんでいる。一人のエンジニアが1か月仕事をしたとして開発できるプログラムは500~800行とすると、単純計算で千人が10年間開発し続ける量。
勘定系システムは大まかに二つの仕組みが並行して動いている。一つは「オンライン」と呼ばれるもの、データをその都度処理する仕組み。リアルタイム処理とも言われる。もう一つはデータを一括して扱う「センターカット」と呼ばれる処理。これがみずほのトラブルを起こした口座振替の仕組み。
やっかいなのは、ATMや窓口端末などオンラインの仕組みを止めずに、センターカットの処理をしなければならないことだ。都市銀行の場合、日中のオンラインはピーク時に毎秒千件ものデータ処理をし、さらにセンターカットで多い日は一千万件を超える振替処理をしている。
これだけの量を処理する情報システムは世界を見わたしてもそう多くはない。しかも、銀行間にまで広がったオンライン・リアルタイム・ネットワーク、膨大な口座振替の仕組み、そして通帳発行まで実現しているのは日本の銀行だけである。
なかなか統合方針は固まらなかった。小委員会には、第一勧銀、富士銀、興銀から代表が出席したが、意見の集約はむつかしかった。それどころか、第一勧銀は各委員会に、旧第一銀行と旧勧業銀行の出身者を組みにして送り込むことが多く、興銀と富士銀の出席者を驚かせた。みずほフィナンシャルグループの経営統合が、三行統合ではなく、「四行統合」と揶揄される所似である。（ここで笑ってしまいました）
三行に食い込もうとした、ある外資系戦略コンサル会社のこんさるたんとはこう漏らした。「米国でいくつも銀行合併を手伝ったが、今回は初めてのケースだ。なぜ統合するかという戦略が決まっていないからだ」。
最大の問題は、三頭取がシステム統合の落とし所を事前に相談していた節があるにもかかわらず、表面上は、三行の情報システム部門に統合計画を策定させたことである。これが諸悪の根源となった。
大手企業向けのみずほコーポレート銀行の勘定系は、興銀のものを使うという暗黙の了解がなぜかあった。この了解が大きな禍根を残した。第一勧銀の杉田頭取は、「当行の勘定系を必ず残すように」と現場に指示したとされる。
第一勧銀が富士通のコンピューターを残したかったのは当然で、同行は富士通のメインバンクであり、古河グループからも「勘定系は富士通で」という強い要請があった。第一勧銀の勘定系がなくなった場合、第一勧銀情報システムの二千人のエンジニアは仕事がなくなってしまう。第一勧銀はそれを恐れた。
富士通の危機感も強かった。都市銀行の相次ぐ合併で富士通は都市銀行の勘定系システムを次々に失っていた。第一勧銀の勘定系まで失うと、都銀の勘定系市場から撤退を余儀なくされてしまう。
今さらの結論を言えば、経営統合を発表した段階で、第一勧銀の勘定系システムに一本化することを三頭取が即決し、発表してしまえばよかった。ところが、三頭取は、小委員会で情報システムの統合方針を検討させた。現場は自分たちが開発してきたシステムへの愛着があり、自分の居場所を確保したいから、何とか事項のシステムを残そうと必死になる。案の定、富士通を推す第一勧銀とIBMを推す富士銀の泥仕合となった。関係者によると、実際には富士銀の勘定系システムの方が第一勧銀より1年半は進んでいたらしい（両行は否定）。富士銀のシステムはPL/Iと呼ぶ開発言語を使っていた。第一勧銀はCOBOLを使っていた。
行司役となった興銀とA.T.カーニーは妥協案をひねり出す。2002年4月に新銀行を作るまでに第一勧銀の勘定系システムを強化して富士銀と同等の機能を盛り込めば「第一勧銀と富士通のシステムに有意差はない」。三行はこの報告書作成料として四千万円を予定していたが、割り勘にできないという理由で、三千九百万円に値切った」 （ここで、再び笑ってしまいました。しかし、延々と展開された議論をまとめて、「さしたる有意差なし」と書いただけで三千九百万円とは...）
銀行の営業店システムは勘定系システムをはるかに上回る利益源。富士銀は沖電気、第一勧銀は富士通、興銀は日立を使っていた。いったんは富士銀が推す沖のシステムを継続することにし、第一勧銀の勘定系システムと接続するためにIBMで「ゲートウエイ・システム」というものを用意することに決めた。
（しかし、この案はあっさり破棄されていますね。ここらあたりから問題が複雑化してきますが省略）
第4章は北洋銀行が拓銀の事業継承の際に日立製だった自行システムを捨て、拓銀のIBM製の勘定系システムを採用してシステム統合を成功させた例ですね。高向頭取は「情報システムを現場の利用部門とシステム部門に任せきりにしては絶対にいけない。経営トップ自らが判断しないと統合は失敗する」と。
旧拓銀システムの採用は、北洋銀行の顧客や営業店に強烈な変化を強いた。北洋銀行にあって旧拓銀になかった商品を撤廃したほか、北洋銀行が発行していた通帳を変更した。北洋銀行の営業店の業務手順や端末操作もすべて変わった。
多くのリスクを抱えながらも、投資額にして約150億円、開発工数にして約3500人月規模の大プロジェクトを、計画通り15か月で完了した。統合システムはトラブルなしで稼働し、初日の夕方に当日勘定が合うという偉業を成し遂げた。
通常の企業合併とは異なり、旧拓銀の経営陣は一人も北洋銀行に来ていない。高向副頭取は当初北洋の日立のシステムを継続し旧拓銀システムを捨てるつもりだった。しかし、北洋の口座数が約二百万に対して旧拓銀は約四百万口座。旧拓銀システムは本州の顧客も含めれば7百万口座を処理できる使用になっていた。機能面でも旧拓銀の勘定系は内容的に優れていた。
理屈では望ましくても心情的には難しい決断を後押ししたのは意外にも北洋のシステム担当者だった。冷静に考え抜いた末、拓銀のシステムへの一本化を進言してきた。「自分の仕事がなくなっても、北洋銀行にとってはベストの選択だと言ってきた。経営陣としても辛いがその方向で行こうと腹をくくった」（いや、どこかとは大違いですねえ）
高向副頭取は、三菱と東京のシステム統合の実績があった東京三菱銀行システム部を訪問して直接教えを請うた。東京三菱銀行の助言は「経営トップが積極的にプロジェクトに関与すること」、「統合メリットを早く出すためにプロジェクトはスピードを最優先すること」だった。「プロジェクトが進めば進むほど、このアドバイスの重さが分かった」と、高向副頭取は振り返る。
第5章は東京三菱銀行の統合成功例。プログラムの開発や修正作業に当たっては、三次オンライン・システムの時から継続して管理していた情報システムの仕様を明記した書類が強力な武器となった。
旧三菱銀は三次オンライン・システムで構築したプログラムを他行に販売していたこともあって、仕様書を継続して更新してきた。仕様書の保守は一見当たり前に見えるが実際には難しい作業だ。手を抜かず、きっちり保守をしてきたことが、システム統合で役立った
システム統合を締めくくる最後の作業は本番環境への移行作業で「百十一時間作戦」と呼ばれた。五月二日金曜日、午後5時にスタート。まず旧東銀の顧客データを日本IBM機に移行する作業から入った。プロジェクトのメンバー千五百人は四日間臨戦体制に入るので、六千人分の弁当を発注した。
（東京三菱銀行のプロジェクトマネジメントはスキのないしっかりした印象ですね）
「システムを構築する仕事は本当に重要だ。これからはすべての産業でシステム部の人間が本流になる。システム統合プロジェクトでは、時には土日、休日を返上して仕事を続けることもあったけれど、一つのことに打ち込んで何かをやり遂げたという達成感は人生で必要なことだと思う」畔柳常
務はこう話す。
畔柳常務は、「システム部門の人間が経営的な感覚を身につけていかなければならない。業務部門から上がってくるさまざまな要求をきちんと理解し、どんな技術を利用すればシステムとして構築できるかを考え、開発に優先順位をつけていく能力が必要になる」と付け加えた。
（畔柳信雄氏は後に、東京三菱銀行頭取、三菱東京UFJフィナンシャル・グループ社長、三菱東京UFJ銀行頭取などを経て、現在、三菱東京UFJ銀行取締役相談役ですね）
6章は旧三和と旧東海銀行のUFJ銀行の統合での勘定系システムの口座振替プログラムの誤りについてですね。「両行の協力会社のエンジニアを結集し、総力を挙げたものの、トラブルは起こった。「システム統合に完全はない」という厳しい現実が浮き彫りになった。」（みずほもそうだったけど、この口座振替プログラムは相当やっかいぽいですね）
UFJ銀行が口座振替システムで処理結果を照合しようとしたところ、できなくなった。口座振替処理をUFJに委託しているクレジットカード会社や電力会社に対し、照合結果を返せなくなった。統合による店番号変更に合わせた口座振替プログラムに誤りがあった。テストを実施したが確認漏れが出た。
UFJ銀行は合併発表時には、開業時期を2002年4月1日としていたのに、2001年四月になって開業時期を3か月前倒しして2002年1月15日に設定したんですね。どうやら3月末決算を二行別々でなくUFJとして発表したかったようですが「ここまで来るとはっきり言って無謀と言えた」
（みずほにしろUFJにしろ、システムの不具合で口座振替処理に遅延が生じた場合、他に手段がないこともあって24時間体制の人海戦術で処理するわけですが、駆り出された方はお疲れ様でした。銀行のシステムの場合、ある程度はシステムを止めずに行わなければならないのが厄介ですね。）
企業の情報システムは数年、あるいは10年ごとに全面的に作り直すのが通例だったが、90年代に入りバブル経済崩壊に伴って全面的なシステム再構築をする体力がなくなった。しかもシステムを開発・運用・保守してきた人材が第一線を退きつつある。
もう一つの日本の情報システムの問題は「プロジェクトマネジメント」の導入の遅れである。納期やコスト、成果物の品質、プロジェクトの範囲、投入する人的資源、メンバー間のコミュニケーション、リスク、各種リソースの調達といった諸要素まで、総合的にマネジメントしていくやり方を指す。
世界的にプロジェクトマネジメントの汎用的な知識体系を整理・共有していく方向にある。米国のPMBOKが知識体系の代表例である。PMBOKは建設、防衛、情報システムなど、様々な分野のプロジェクトに共通する汎用的な知識を体系として整理したものである。
PMBOK （Project Management Body Of Knowledge）
日本の情報システムの世界は、プロジェクトマネジメントの導入に関して驚くほど世界諸国から遅れている。欧米の手法や考え方を巧みに取り入れる日本でこれだけ世界と格差が出た領域は珍しい。その理由は逆説的だがプロジェクトマネジメントに適した国民性を持っていたからである。
目標が決まると達成に邁進する国民性。必要があれば自分の持ち場を越え、他人の仕事を肩代わりしてでもプロジェクトを遂行する。日本人は自分を殺してでもプロジェクトを優先できるが欧米ではこうはいかない。ただ、日本のやり方は集団的無責任体制、玉砕の可能性もある。
日本は汎用的な知識体系やノウハウを共有しなくても自己流でプロジェクトをこなしてきた。だが現場のプロジェクトが減り徒弟制度が維持できなくなるとノウハウの伝承が難しくなる。日本は、自己流だが世界有数のプロジェクトマネジメント能力を持つ国から、自己流で実力すらない国に転落しつつある。
最後にこれがまとめてあります。『提言：システム障害を撲滅するための10カ条』
http://business.nikkeibp.co.jp/article/manage/20110720/221562/
1. 経営トップが先頭に立ってシステム導入の指揮を執り、全社の理解を得ながら社員をプロジェクトに巻き込む
2. 複数のシステム開発会社を比較し、最も自社の業務に精通している業者を選ぶ
3. システム開発会社を下請け扱いしたり、開発費をむやみに値切ったりしない
4. 自社のシステム構築に関する力を見極め、無理のない計画を立てる
5. 社内の責任体制を明確に決める
6. 要件定義や設計など上流工程に時間をかけ、要件の確定後はみだりに変更しない
7. 進捗は自社で把握、テストと検収に時間をかける
8. システムが稼働するまであきらめず、あらゆる手段を講じる
9. システム開発会社と有償のアフター・サービス契約を結び、保守体制を整える
10. 「うっかり」ミスを軽視せず、抜本的な対策を取る
.jpg)
