“人知を超える”システム規模

 後回しにした開発項目は、融資など貯金システムにおける新機能の開発だ。銀行間の為替処理をこなす「全銀システム」やATM(現金自動預け払い機)提携システム「統合ATM」との接続も民営・分社後に先送りした。

 郵政公社や同社の継承計画を詰める新会社「日本郵政」の経営層は、民営・分社化と同時に民間銀行並みのサービスを提供することを要望していた。貯金システムを全銀システムに接続し、民間銀行の口座と郵便貯金口座の間で資金をスムーズに移動できるようにしたいとの考えもあった。民間との競争には欠くことがきない基本サービスだったからだ。

 だが、経営層は、民営・分社化対応のシステム開発が抱えるリスクの大きさを把握しきれているわけではなかった。貯金システムだけでも、富士通や日本 IBM、日立製作所、NECのメインフレームを95台使う日本最大級の規模。ステップ数は5130万と、メガバンクの勘定系システムの2倍以上だ。もはや、“人知を超えた”システム規模といっても過言ではない。

 これだけの規模を誇る貯金システムを修整するとなると、システム全体の整合性を確認する動作テストだけで1年以上かかる。万が一、テスト漏れがあって、システムが全面ダウンすると、全国に8万台以上ある郵便局のATM(現金自動預け払い機)と貯金用端末がストップしてしまう。

 貯金システムの暫定対応では、民営化に伴い適用される銀行法対応など、最低限の修整だけでも2万3000人月に及ぶ。細かな修整をこなすだけでもシステム部員には全く余裕がない状況だ。

 さらに、「融資など経験がない新サービスを始めるには、これまでとはまったく別な業務知識やシステム開発のノウハウが必要」(間瀬理事)。いくら経営層が望んでも、システム開発の現場では、民営・分社化と同時に民間銀行並みのサービスを提供するのは不可能な状況だったのである。

開発メンバーの上限は4000人

 暫定対応では、システム部員の人数がボトルネックになった。郵政公社のシステム部員は200人弱。これに対し、システム部員1人がマネジメントできるプロジェクト・メンバーの人数、つまりITベンダーの技術者の数は「20人が限界」(間瀬理事)。単純に計算すると、プロジェクト・メンバーの上限はピーク時で4000人になる。

 ただし、現実には200人の部員全員が20人を管理できるわけではない。プロジェクトの参加人数が膨らみ、関係者が増えれば増えるほど、1人のプロジェクト・マネジャが管理できる範囲は狭くなる。こうしたことから、4万3000人月というのが精一杯の開発規模なのである。

 間瀬理事は、「ベンダーのエンジニアを大量増員すればいくらでも開発規模を拡大できるわけではない」とも述べる。要件定義やベンダーへの要件の説明、システムの受け取りテストなどは、ユーザーである郵政公社のシステム部員でなければできないからだ。

 郵政公社のシステム部門は、郵政民営化法案が国会で議論されているころから、銀行法や生命保険法などを参考に、現行システムとのギャップ分析を続けてきた。2005年10月に法案が通ってから、暫定対応のプロジェクトを本格スタート。2月までにシステム設計をほぼ終わらせた。一部のシステムでは先行して今年1月から実装を開始。8月からシステム単位で総合テストに入る。2007年1月にはシステム全体を接続した状態で最終テストに入り、10月の切り替えを迎える。

無理を強いれば大トラブルも

 2007年10月に暫定対応を終えた後には、5万9000人月に及ぶ本格対応が控えている。暫定対応が進めば進むほど、皮肉にもシステムはさらに肥大化する。

 また、郵政公社の経営層でシステム全体を見わたせる人材は、システム部門で38年を過ごした間瀬理事だけ。間瀬理事ただ一人に、9170万ステップの巨大システムのリスク管理を委ねるのは、あまりにも危険である。

 郵政公社は、一刻も早くシステム全体の棚卸しや構造解析などに取り組むべきである。先進のITを使って再構築を進めれば、保守性も改善する。

 その一方で、経営層はシステム部員の増強や予算確保、無理な新サービスの開発要請を控えるなどの手を打たなければならない。そういった抜本的な対応を先延ばしにすれば、取り返しのつかない大トラブルを招くリスクが高まるだけである。