生命保険のシステム統合

日経金融新聞(平成14125日号)です。24日に正式発表された明治生命、安田生命の合併計画に関して、システム統合が合併効果を減損させるのではないかとの見方が掲載されています。私の所にも、マスコミからいろいろな問い合わせがきます。(最近の記者は金融マンよりもeメールを上手に使うので、こちらも手間が省けて助かります。)その内容は「システム統合にどの位の費用と時間が必要なのか?」「やはりIBMが採用されるのだろうか?」「どの位のITコスト削減が可能になるのか?」といった質問です。

,4年ほど前に大手銀行の統合がブームだった頃、私は次のような理由を上げてシステムを一本化することに反対しました。(銀行からもIT企業からも完全に無視され、一部の企業経営を知る全国紙記者やコンサルタントだけが賛同してくれましたが。)

  • 経営環境が急速に激変している時に、3年もかけてシステムを一本化していたのでは、新しい商品やサービスへの対応が遅れる。  
  • 単純に一本化するだけでは、顧客にも行員にも何らメリットはなく、単に移行の負担がかかるだけである。
  • システム統合の検討方法が関連銀行間の利害調整中心となり、最大公約数的機能を最小公倍数的費用で実現するという全く経済合理性に欠けるプロジェクトになる危険が大。

等々です。

私の提案は、両システムの並存か一方のシステムへの全面片寄せ(つまり、一方の廃棄)でした。一次から三次オンラインまでのような全面書き換えは、体力的制約(資金と人材)と変化対応スピードという条件下ではあり得ないと思ったからです。地震の真っ最中に結婚・新築・引越しをまとめてやるようなものです。拒否された最大の理由は、顧客に同一のサービスを提供することと、システムの保守コストを削減するというものでした。その結果、利益を得たのはIT業界だけのような気がします。そもそも、合併目的の一つが米銀に対抗するためのIT投資負担に耐えられる資金を確保するためなどという発表は、全くの間違いと考えていました。そもそも先進米銀とのIT格差は資金力が原因ではありません。技術力とIT戦略立案力とベンダー管理力の違いでしょう。

さて、生保が合併する時のシステム対応はどうすべきでしょうか?
はり顧客メリットと合理化効果が見合わなければ、両システム並存のままにしておく方がコストが安いでしょう。一本化するとすれば、過去の契約分のプログラムを全て新しいインフラに乗せ直す作業となります。そのコストとインフラ重複分の費用削減効果との単純比較です。生保や信託独特の超長寿命アプリは、満期か解約になるまで残さざるを得ないのですから、インフラだけ変えることにメリットはありません。しかし、顧客情報と営業一線の端末だけは統一する必要があります。それと新商品用の業務系システムを新規開発しなくてはなりません。
コード体系や蓄積データの項目・様式が異なるので、顧客DBの統合は大変な作業となります。名寄せしながら、上位の顧客コードを採番してMCIFを作り、その下に二つのDBを連結させれば対応可能でしょう。HWの性能が上がっていますので、昔のようにパフオーマンスを気にする必要はありません。
新業務系は、合併後の新商品専用システムとします。クラサバやWebを使って、ハードだけでなくソフトもダウンサイジングします。旧の業務系二つとDB系とあわせて、全体をハブアンドスポーク体系のインフラに乗せます。Webサービス体系を応用するのです。
営業端末もWeb化し、両業務系、新業務と連携するようにします。営業端末からMCIFで起動すべきアプリケーションを選択して、Web経由で当該業務系にデータを飛ばします。つまり、処理もDBも分散させる訳です。分散DB技術とXMLにより技術的には充分可能でしょう。回線ネックも無い時代ですし。

この考え方ですと、時間が節約できるだけでなく、経済効果のない統合コストを最小化できます。新規開発するものは将来的にも使えます。合併には関係なく、いずれ必要な機能です。システム統合プロジェクトは通常のIT化よりも政治的要素が強く、技術的要素と絡まって検討・決定を複雑にします。大規模投資に群がるベンダーも複雑さを増幅します。いわゆる合併の100日ルールに従って、3か月程度で結論を出し、具体的作業に入りませんと、3年たっても何も変わらない。場合によっては経営統合も出来ないことになります。結局は経営トップの決断とリーダーシップ次第です。その双方が最低必要条件です。銀行の事例を見れば歴然としています。明治、安田両社が時局の厳しさを反映して、的確なIT戦略を打ち立てることを期待しています。