デスマーチ― ―。ソフトウエア開発などのプロジェクトにおける過酷な労働状態や、納期などが破綻寸前でメンバーの負荷が膨大になったプロジェクトの状況を指す言葉。文字通り「死の行進」とも呼ばれているが、現場はどうやらそんな修羅場に陥っているようだ。
　そのプロジェクトを受注した大手ベンダーに、下請けの中堅ＳＩ企業から派遣されているというシステムエンジニア（ＳＥ）の一人がこう明かす。「徹夜や休日出勤は当たり前。毎月数人がうつ病やノイローゼでプロジェクトから抜けていく。中には突然イスから立ち上がるや、『お前らよくこんな仕事やってられるな！』と叫んでドアを蹴って部屋を出ていき、それっきり出勤してこなかった奴もいた。プロジェクトマネジャーは無論のこと、メンバーは皆、疲弊し切っている」。
　みずほフィナンシャルグループ（ＦＧ）が進めてきた勘定系システムの全面更新・統合プロジェクト。それがいま、重大な岐路に立たされようとしている。関係者によると、開発そのものはほぼ山場を越えているものの、組み上がった新システムの真価が試される肝心のテスト工程に入ったところでトラブルが続発。このままでは今年十二月としてきた完成予定時期が大幅にずれ込むのは最早、避け難い情勢になっているという。
　そればかりではない。下請けＳＩの一部では「凍結」「中止」といった観測さえ飛び交う始末。「空前のＳＥ不足のなか、暗礁に乗り上げてしまう危険性のあるデスマーチプロジェクトにこれ以上、貴重な戦力を張り付けておくわけにはいかない」として、実際に派遣していたＳＥの引き揚げ・縮小に踏み切るところも出はじめているという。
まるでクフ王のピラミッド建設
　みずほが「今後三十年の礎を築く」（ＦＧ幹部）として、日常業務の基幹となる勘定系システムの刷新・統合構想を打ち出したのは二〇一一年六月のことだった。
　きっかけとなったのはほかでもない。〇二年四月と一一年三月の二度にわたって旧みずほ銀行（ＢＫ）が引き起こした大規模なシステム障害だ。とりわけ東日本大震災直後に起こした二度目の障害では、殺到した震災義援金の振り込みにデータ処理が追い付かないといった脆さを露呈。継ぎはぎに継ぎはぎを重ねた末にシステムの全体像がよくわからないまま運用していたことも祟って、復旧にも手間取った。
　こうした教訓の下に企画立案されたのが現行計画だ。これまでのようにどれか一つのシステムに他のシステムを片寄せして統合したり、相互のシステムをリレーコンピューターでつないで一体化したりするのではなく、全く新しい次期システムを一から構築したうえで、それに旧ＢＫ、旧みずほコーポレート銀行（ＣＢ）とみずほ信託銀行（ＴＢ）三行のシステムを移行させる。つまり全面更新と統合を同時に実現しようというもので、ＢＫが旧第一勧業銀行時代の一九八八年から使っている富士通製メーンフレームの「ＳＴＥＰＳ」など、既存システムはＴＢのごく一部を除いてすべて廃棄する。銀行界でも「前例のない取り組み」（ＢＫ関係者）だ。
　システムの設計作業が始まったのは一三年春頃から。導入されたのは「みずほＳＯＡ（サービス指向アーキテクチャー）」と呼ばれる独自の設計手法だ。預金や融資、為替といった機能・業務ごとにアプリケーションを切り分け、これを独立したコンポーネント（部品）としてまとめる。そのうえで各コンポーネントを、ＣＩＦ（顧客情報ファイル）や処理フローの制御などそれぞれのコンポが共通して必要とする機能を実装したプラットフォームを通じて連携させる仕組みだ。
　長年機能の追加を繰り返してきたシステムは、アプリケーション同士が密接に結合していて分離できない。このため新たに商品を追加したり、サービスの内容を変更しようとしたりすれば、影響は多岐に及び、時間と労力もとられる。その点、独立性を確保したコンポ化を実現できれば、新商品を機動的に投入でき、商品開発コストも大幅に削減できるというわけだ。
　何よりアプリケーションの肥大化を抑制できるのもメリットだ。これによりバグの発生が減らせるうえ、仮に障害が起こってもシステム全体に波及するリスクを軽減でき、影響の局所化や復旧の早期化が可能となる。これぞまさに二度のシステム障害の経験から編み出された知恵と工夫といえるだろう。
　だが―。みずほのプロジェクトには三菱東京ＵＦＪ銀行（ＢＴＭＵ）や三井住友銀行（ＳＭＢＣ）といったライバル行ばかりでなく、グループ内でも当初から「無謀」（ＴＢ関係者）として、先行きを危ぶむ声が上がっていた。プロジェクトを的確にマネジメントできる人材やシステムの開発・統合作業に必要となる一定のスキルを身につけたＳＥをどこまで確保できるかなど難題が山積していたからだ。
　ハブシステム同士をつないで旧東京三菱銀行のシステムと旧ＵＦＪ銀行のシステムを併存させてきたＢＴＭＵが〇八年十二月、旧東京三菱に片寄せする形でシステム統合に踏み切ったプロジェクトでは、ピーク時で約六千人のＳＥが動員されたといわれている。要した工数は十一万人／月。約二千五百億円を投じ、設計から稼働まで二年を費やした。
　これに対し、みずほのプロジェクトではＢＫの勘定系システムだけで約五千万ステップ、旧ＣＢやＴＢ分を合わせれば一億ステップにものぼるといわれる国内最大級の巨大システムを一からつくり上げたうえ、統合までをも同時に行うという、技術的にも「極めて難度の高い離れ業」（ＳＭＢＣ関係者）への挑戦を強いられる。総投資額は四千億円に迫るとされ、必要となるＳＥはピーク時でおよそ八千人。工数は「古代エジプトにおけるクフ王のピラミッド建設にも匹敵」（事情通）し、ＢＴＭＵの二倍近い二十万人／月に膨らむともみられていた。これだけの開発要員をどう調達し、どうマネジメントしていくのか。
ＳＥ不足が一段と深刻化
　異例に次ぐ異例のプロジェクトの象徴ともいわれる「マルチベンダー方式」が採用されたのは、何も第一勧銀・富士銀行・日本興業銀行という旧三行間の政治力学が優先されたことだけが理由ではあるまい。旧三行がそれぞれ親密だった富士通、日本ＩＢＭ、日立製作所に、地銀などに強みを持つＮＴＴデータを加えた四社による共同受注としたものだが、一社単独受注では仮に大手ベンダーといえども、下請けＳＩやパートナー企業を総動員したところで限界があると踏んでの「苦肉の策」（ＦＧ関係者）でもあったのだろう。
　しかしそれでも作業は案の定、難航。一四年二月には「設計に手間取っている」として、早くも延期に追い込まれる。スタート時には一六年三月末と設定していた完成時期を「一年程度」先送り（その後一六年十二月に再設定）するというものだったが、富士通関係者によると、アベノミクスによる景気回復を受けた企業のＩＴ投資の増加などもあって、その前後からＳＥ不足は一段と深刻化。一時はシロウト同然のエンジニアまでが駆り出され、玉石混交となった現場は一層混迷を深めていったという。
「実はこの頃、ベンダーの一部からはプロジェクトそのものを一旦、打ち切りにし、仕様策定などを含めて最初からやり直してはどうか、といった提案もあがっていた。しかしウチのシステム部隊などが強硬に反対。結局、どんなに人手を割いても当初計画のまま突き進むということになり、引き返せなくなってしまった」。ＢＫ幹部の一人は当時を振り返ってこう悔やむが、後の祭り。事情通によれば、プロジェクトはここにきて「まったくゴールが見えない」といった有り様にまで陥ってしまっているらしい。
現行システムの障害リスクが増大
　みずほにとって痛手なのは、システム刷新・統合の遅れそのものよりもむしろ、それによって新システム稼働後に予定していた二十四時間振り込みサービスやインターネット取引の時間延長など、様々な新サービス・利便性向上策の投入計画にもまた支障が生じてしまうことだろう。さらに「年間数百億円」（ＦＧ幹部）と見込んでいた物件費をはじめとしたコスト削減効果や経営効率化計画もその目算が大きく狂うことになる。まして「凍結」や「中止」といった事態ともなればなおさらだ。システムの規模からいって、プロジェクトを再起動するにしても「最低二～三年はかかる可能性が高い」（中堅ＳＩ企業幹部）とみられているからだ。
　佐藤康博ＦＧ社長ら首脳陣にとっては、刷新・統合が遅れれば遅れるほど、システム障害のリスクが増大していくことも不気味な要素だろう。新システムが出来上がるまでは、二度も大規模な障害を起こしたうえ、老朽化し、寄せ木細工のようになっている現行システムを使い続けなければならないからだ。「今度やったら金融庁が許すハズがない。ウチは間違いなく、お家お取り潰し」。ＢＫ幹部は言い切る。
　と言って、不完全さを抱えたまま無理やり刷新・統合を急いで障害を起こしても、待ち受けるのは「同じ運命」（金融庁筋）だ。
　一六年三月期決算。ＦＧは六千七百九億円の純利益を計上。インドネシアの出資先に対する多額の株減損処理を強いられて六千四百六十六億円にとどまった三井住友フィナンシャルグループを〇七年三月期以来、九年ぶりに逆転し、メガバンク二位に浮上した。この慶事に「グループの士気は大いに高まっている」（ＦＧ関係者）とされるが、その足元は累卵の危機にさらされているといってもよさそうだ。
 

掲載物の無断転載・複製を禁じます©選択出版