「ピラミッド建設以来」とまで称された十数万人月の大規模開発プロジェクトが昨年末に終結し、数年間続いてきた「メガバンクの経営再編に伴うシステム統合」が一巡した。昨今の金融経済情勢下では何が起きるか分からない…、と物騒なヘッジをかけなければ、ようやく大手金融グループのIT基盤が整い、前向きな国際競争のスタートラインに立つことができたことになる。

　毎年度末になると、システム統合時に発生した大規模障害を思い出す。年初に大震災を想起し、夏の終わりにテロの痛みが胸をよぎるのと同じである。確かに7年前の春の衝撃は大きかった。当事者の報告を含め公表済の通り、経営のリスク認識不足をはじめ、数多くの問題点と教訓があった。三つの銀行を二つに再編し、合併と同じ期初日に動かすプロジェクト設計自体、難度が高過ぎた側面も指摘できよう。

　しかし、「課題は過去よりも未来にある」。あの事故以降、システム稼働基準が急に切り上がり、「いかなる障害も許さないスタンス」に至った過剰反応感は否めない。今後のシステム開発は、プロジェクトを輪切りにして段階稼働させるなど、できれば1年単位のスピード感を目指したい。そうしないと、開発途上で状況が変化し、経営戦略を阻害するだろう。

　テスト期間短縮のアイデアとしては、正月やGWを利用した「業界一斉点検日」の設置が有効であろう。これを利用して対外接続テスト等を相互一斉にこなせば効率的だ。24時間365日営業が流行し、IT部署が保守時間確保に四苦八苦の現状は、適正バランスを欠いている。また「トライアル的稼働開始」も検討に値する。顧客を待たせながら、最後のバグ発見に多大な時間とコストを費やすよりも、「何か起きるかもしれない。余裕をもって利用してほしい」旨を情宣したうえで、実際に動かして発生する障害の迅速復旧に努めるほうが経済合理性に優るであろう。

　「恋愛相手は横一列に並んで来ないから、選択判断が難しい」と言う。一度、複数の選択肢を顧客に示して意向調査しては如何か。

　A＝障害の許容水準を高めれば1年前倒しで統合できる、B＝その分金利を高くできる。AおよびBの支持派に比べて、C＝「お金をかけ、長引いてもよいから絶対に障害を起こすな」派は少数にとどまると思う。

　固定観念を脱し、様々なアイデアが自由に溢れ出る環境を創り出したいものだ。