損保最大手、ミレアホールディングス傘下の東京海上火災保険と日動火災海上保険は今年6月、基幹系システムの統合を完了した。両社はシステム統合を経営の最優先課題と位置付け、28回に及ぶ段階稼働や300回を超えるレビューなど、統合リスクを回避するあらゆる手を講じた。要件が決まらない危機に瀕しても、リスク管理重視の姿勢を堅持。こうした取り組みが実を結び、プロジェクトは計画通り完遂した。

(大和田 尚孝)

読者限定 【本特集の“予習”】を読む

対策1(2002年1月~4月)2大ルールで開発規模を抑える
対策2(2002年5月~7月)役員を交えて徹底的にレビュー
対策3(2002年8月~10月)稼働直前にリスクを総点検
対策4(2002年10月~2003年6月)トラブル原因を厳しく追及


【無料】サンプル版を差し上げます本記事は日経コンピュータ2003年6月16日号からの抜粋です。そのため図や表が一部割愛されていることをあらかじめご了承ください。本「特集」の全文をお読みいただける【無料】サンプル版を差し上げます。お申込みはこちらでお受けしています。なお本号のご購入はバックナンバー、または日経コンピュータの定期ご購読をご利用ください。

 東京都多摩市にある東京海上火災保険のシステム・センターで今年6月、28回目となるシステムの切り替え作業が完了した。この瞬間、東京海上と日動火災海上保険の基幹系システムがついに統合を果たした。統合完了の知らせは、東京・丸の内の東京海上本社や銀座の日動火災本社にもすぐに届いた。「2年間の苦労が報われた」。関係者は胸をなでおろした。

 東京海上と日動火災は昨年4月に持ち株会社のミレアホールディングスを設立。来年10月には合併を予定している。両社が合併効果を最大限に発揮するには、商品や事務を支える基幹系システムの統合が不可欠だった。

 両社は経営統合に合意した2000年9月から、「システム統合なくして、業務の統合はあり得ない」という共通の認識のもと作業を進めた。2001年7月には、「統合システムは東京海上のシステムを基に、日動火災の独自機能を追加開発する形で構築する」といった基本計画を固めた。いわゆる“片寄せ”型のシステム統合である。

 片寄せの形を採れば、統合システムを新規に開発するよりも手間は大幅に軽くなる。とはいえ、ミレアは日本最大の損害保険会社である。中核を担う2社の基幹システム統合は決して生やさしくない。保有契約件数を見ても東京海上は約2500万、日動火災は約800万。業界シェアは合わせて26.8%に達する。

 両社は基本計画の策定から2年間、工数にして1万1300人月をシステム統合に投じた()。システム・インテグレータの手はほとんど借りず、両社のシステム部門に加えて、東京海上のシステム子会社である東京海上システム開発(TSK)、日動火災のシステム子会社である日動火災システム開発(NSD)がプロジェクトを取り仕切った。さらに両社の経営層や現場が一丸となって、プロジェクトに臨んだ。参加人数はピーク時で1600人に上る。

システムの概要保険商品の契約管理や計上、事故処理の支援など、保険業務全般を支援する基幹系システム
プロジェクトの期間2年(2001年7月~2003年6月)
稼働開始日2002年10月15日~2003年6月16日(28回の段階稼働)
開発費用145億円 *1
開発工数1万1300人月
主なシステム開発ベンダー東京海上システム開発、日動火災システム開発
システム統合方針東京海上のシステムに片寄せ。日動火災固有の機能を追加開発
移行方針更改切替方式*2で日動火災の保険契約を東京海上のシステムに移行
*1 会計システムの統合や合併対応、センター移転など、今後発生する開発費用を含む
*2 旧システムで満期を迎えた保険契約を、新システムで更改する移行方式。損保が取り扱う保険商品は1年契約が中心なので、1年で移行がほぼ完了する
表●東京海上火災保険と日動火災海上保険が2003年6月に稼働させた統合システムの概要

 東京海上と日動火災は統合システムの安定稼働を最優先し、「システム統合の失敗要因(リスク)を事前に見極め、できる限りその芽を摘み取る」というリスク・マネジメントを重視(図1[拡大表示])。システムの段階稼働やレビューの徹底に加えて、開発の進捗や事務研修の習熟度を数値で表すなど、リスクの分散と透明化を可能な限り推し進めた。「統合のリスクを経営のリスクと位置付け、全社レベルのリスク・マネジメントを徹底した」。東京海上とミレアホールディングスの社長を兼務する石原邦夫は、こう説明する。

図1●統合プロジェクトでは、リスク・マネジメントに徹底してこだわったリスクの洗い出しから達成基準の設定、リスク削減の取り組みまでを全社一丸で実施した

 それでも危機は訪れた。要件定義で両社の意見がまとまらず、スケジュールが2カ月遅れた。東京海上 執行役員IT企画部長の岩田雅之は、「この時期が最大の難関だった」と振り返る。ここで両社は、「システム統合のリスクは経営全体のリスクである」ことを現場の役員に改めて訴え、要件の調整を一気に進める。

 設計・開発段階では、両社のシステム関連会社が奮闘、28回に及ぶ統合システムの段階切り替えも着実にこなした。一連のリスク・マネジメントが奏功し、システム統合は無事完了した。

対策1 2002年1月~4月
2大ルールで開発規模を抑える

 「オーバー分が減らない。まいったな」。東京海上 IT企画部部長の澁谷裕以は天を仰いだ。昨年4月のことだ。

 プロジェクトは、今回最大のヤマ場である第2期(自動車保険システムの統合)での要件定義の最終段階を迎えていた。ここで大きな問題が生じた。詳細要件を詰めるにつれて、開発規模が膨らんでしまったのだ。2001年11月の時点で基本要件に基づいて規模を見積もったところ、72万ステップだった。それが昨年1月の段階で20万ステップ増の92万ステップに達していた。

 リスク・マネジメントを最優先する両社はこの事態を重く見た。東京海上の澁谷は「規模の増加は開発の遅れにつながり、ひいては品質の低下や稼働延期に直結する。世の中のシステム・トラブルは、元をたどれば開発規模の増加にあることが少なくない」と話す。

 そこで東京海上と日動火災は昨年1月から、開発規模の見直しを進めた。しかし4月になっても詳細な要件は決まらず、開発規模は減らなかった。最大の理由は、東京海上が日動火災の要求を思い切って切り捨てられなかったことだ。東京海上社長の石原は、「“完ぺき主義”という東京海上の社風が度を超えて、逆に弊害となった」と振り返る。

現場の役員に直訴

 「これ以上開発が遅れると、システム・リスクが限界を超える」。こう判断した両社のシステム部門は昨年4月、大胆な二つのルールを決定した。それは、「4月末までに決まらない要件は開発しない」、「想定規模を上回る要件は開発しない」というものだ。


続きは日経コンピュータ2003年6月16日号をお読み下さい。この号のご購入はバックナンバー、または日経コンピュータの定期ご購読をご利用ください。