「シンプルなプロジェクト」を追求し約1年半で新基幹システムを本格稼働【アイリオ生命保険】

生命保険業の免許申請手続きと、基幹業務システムの開発を並行して進め、2008年8月に事業を開始したアイリオ生命保険。プロジェクト発足からシステム本格稼働までIT部門に許された期間は約1年半だったが、シンプルなプロジェクトを追及し、ゼロからのスクラッチ開発を完遂した。
聞き手は本誌副編集長・川上 潤司　Photo：陶山 勉

水町 哲也 氏

エキスパートグループホールディングス　ビジネスディベロップメント IT担当

2007年5月、エキスパートアライアンス株式会社に入社。引き受けや支払い業務のシステム構築を担当。生保システムの開発では支払いや名寄せシステムを担当。2009年2月に親会社GHDへ転籍し、新規事業の立ち上げやグループ全体のシステム投資に対するサポートにあたっている

田中 里枝 氏

アイリオ生命保険　情報システム本部 副本部長 兼IT企画部長

2003年4月、エキスパートアライアンス株式会社に入社。ロードサービスシステムの構築や会員管理システムの保守を手掛ける。生保システム開発では、引き受けサブシステムを担当。2008年8月にアイリオ生命保険株式会社へ転籍し、社内業務の効率化やIT部門のマネジメントを担当している

大岩 政博 氏

アイリオ生命保険　IT運用部長

2006年8月、エキスパートアライアンス株式会社に入社。主にシステム基盤の構築や運用を担当する。生保システムの開発では開発インフラの構築など基盤整備を担当する。2008年8月にアイリオ生命保険に転籍し、現在はシステム全体の運用管理やIT統制管理を担当している

─ 生命保険業への参入に伴い、かなりタイトなスケジュールで新システムを構築したと聞いています。

田中：もう本当にタイト過ぎるスケジュールでした。

大岩：何しろ、普通なら数年かけるような生命保険会社の基幹業務システムを、1年余りで完成させるというのですから。

─ ロードサービス事業を手掛ける前身のエキスパートアライアンスから会員向け生命共済事業を継承し、アイリオ生命保険として事業を開始したのが2008年8月ですね。プロジェクトがスタートしたのはいつですか。

田中：2007年1月です。約3カ月かけて生命保険業務の概要設計をして、7月いっぱいで業務の詳細設計とシステムの基本設計を完了しました。

水町：その後、9月から生命保険の契約管理と代理店管理の2つのアプリケーションを並行して一気に開発し、11月から単体テスト。翌2008年1月からは結合テストに着手して、最終的に生命保険業の免許を得て開業した2008年8月にシステムをカットオーバーさせたというのが大体のスケジュールです。

時間とリスクを考慮し新旧システムを並存

─ おおよそ1年半。エキスパートアライアンスから引き継いだ生命共済の契約者データとアプリケーションも、その期間内でアイリオ生命の新システムに統合したんですよね？

大岩：いえ。生命共済と生命保険の通算金額が一定以上になると保険を引き受けてはならないという規定があるので、両者を通算できるように契約者データは名寄せ/クレンジングをして新システムに移行しました。しかし、生命共済の契約は従来のシステム、生命保険の契約は新システムで管理しています。

─ 運用やメンテナンスの効率を考えたら、新システムに一本化したほうが良さそうですが。

大岩：おっしゃる通りです。事実、ユーザー部門やIT企画部の他のメンバーから新システムに一本化しないのかという声が上がりました。

─ にもかかわらず、生命共済と生命保険のシステムを併存させた？

水町：とにかく短期間でシステムを完成させることを追求した結果です。

─ 一本化するには時間がかかる。

水町：そうなんです。システム統合は口で言うほど簡単ではありません。エキスパートアライアンスには約90万件の生命共済の契約者データがありましたから、データ移行作業を1つとっても膨大な作業量になります。

田中：生命共済のアプリケーションを移行するには、最低でも半年は要するだろうと見積もっていました。でも、最初に申し上げた通り、それだけの時間的な余裕はありません。

水町：付け加えるなら、生命共済のシステムは5〜6年にわたり、新商品の開発に合わせて機能追加を繰り返してきたことがあります。IT部門の中でもアプリケーションのロジックを完璧に把握しているメンバーはそれほどいません。そのような状態で、本当に半年でアプリケーションを完全に統合できるかどうかの保証もなかった。仮に統合に失敗したら、システムが原因で生命保険会社としてのスタートを遅らせるという最悪のケースも考えられる。そうしたリスクは徹底的に排除しなければなりませんでした。

─ 時間の制約で選択肢が限られたわけですね。

水町：ええ。生命共済と生命保険のシステムを並存させる他に、現実的な解がなかったというのが実情です。

欲張らないことがプロジェクト成功の近道

─ 逆に、短期間でプロジェクトを完遂することを考えたら、生命共済の基幹業務システムを機能拡張して生命保険の契約管理などに用いる方法もあったかと思います。

田中：それは考えられませんでした。生命共済のシステムに使っていたソフトのバージョンは古くなっており、サポート期間切れが迫っていたからです。生命保険業向けの機能を追加した後に改めてソフトのアップグレードをするのは非効率なうえ、少なからずリスクもあるので、生命保険の基幹業務システムについては最初から新規で作ることにしました。

水町：そもそもアレコレと欲張って複雑になったプロジェクトは、大抵うまくいかないものなんですよ。

─ 水町さん、どうやら過去に苦い経験がありそうですね。

水町：幸いにして「動かない」ケースはないものの、色々な作業を同時並行で進めようと欲を出したときに限って、プロジェクトが佳境を迎えると性能が出ないなどの問題が出てくる。私はこれまで色々なシステム構築プロジェクトに携わってきましたが、プロジェクトの対象を明確に絞り込んでシンプルにしたほうが失敗しない。これは経験則です。

図1　アイリオ生命保険の新システム開発プロジェクトのスケジュール概要

技術者確保の観点でJavaを採用

─ 新システムの構成を教えてください。

大岩：プラットフォームはWindowsサーバーとOracleデータベース、アプリケーションはJavaで開発しています。

─ Linuxなどオープンソースソフトの採用は考えませんでした？

大岩：プロジェクトの初期に一瞬だけ考えましたが、すぐに立ち消えになりました。生命共済の基幹業務システムもWindowsとOracleの組み合わせで作っているので、同じ技術をベースにしたほうが構築とメンテナンスの両面でメリットが大きいだろうと考えてのことです。

─ Oracleデータベースのバージョンは11gですか？

大岩：いいえ、10gです。プロジェクトをスタートしたタイミングで11gがリリースされるという情報がありました。しかし、初期リリースのものは製品自体の不具合が原因でトラブルが発生しないとも限らない。そこで安全策を取って、あえて枯れているバージョンを選びました。

─ Javaで開発したということですが、Windowsであれば.NETでアプリケーションを作ってもよかった。

大岩：Javaを採用したのは、工数が膨らんだ場合に技術者を集めやすいと見込んだからです。インテグレータに聞いたところ、.NETよりJavaの技術者のほうが圧倒的に集めやすいと言われました。

水町：技術者を集めやすいというのは、一定の品質を保ちながら計画通りに工程を進めるうえで極めて重要な要素なんですよ。プロジェクトを成功に導く大きなポイントの1つと言っても過言ではありません。

─ 実際に、技術者を急きょ増員するようなケースはあったのですか。

田中：10人規模で増やすことはざらにありました。当時は郵政民営化に伴うシステムプロジェクトに多くの技術者が参加しており、開発要員の確保が難しいと言われていた時期ですが、ピーク時120人ほどの体制で開発を進めることができました。技術者の確保という点では、Javaを採用したことが功を奏したと思います。

2交代制/24時間体制でテストを敢行

─ 技術者確保は上手くいった。では、プロジェクトの難所は？生命共済の契約者データの名寄せですか。

水町：それが違うんです。全体を通して見れば、契約者データの名寄せやクレンジングは最もスケジュール通りに進んだ。むしろ楽でした。

─ さまざまなプロジェクトについて取材してきましたが、名寄せが楽だったというケースは珍しい。

水町：もちろん最初はすんなりいくとは考えもしませんでした。今回、アグレックスの「TRILLIUM」というツールを使ったのですが、サンプルデータで検証したところ割と良い結果が出て、本番でもほぼ問題なく契約者データの重複を排除して移行を完了できました。

─ ラッキーと言えばラッキーだった。

水町：そうかもしれません。エキスパートアライアンスの生命共済事業の歴史が比較的短かったことに加え、業務部門が決められたルール通りに正確にデータを入力してくれていたのが大きかったです。

─ 名寄せが楽だったとすると、最も苦労されたのは何でしょう。

水町：その他、諸々です。名寄せ以外は、いばらの道でした（笑）。

大岩：例えば、技術者を確保しやすい反面、次の日までに10人分の開発環境を準備しなければならないということがあります。ヴイエムウェアやマイクロソフトの仮想化ソフトを導入してサーバーのリソースを区切って開発環境を作ったのですが、途中でリソースの容量が足りないという声も出てくる。そうするとリソースの使用効率が低い開発環境の容量を削り、不足している環境に割り当て直す必要がある。

─ 仮想化していたなら、あらかじめ用意しておいた開発環境のイメージを追加したり、リソースを再配分したりするのに手間がかからないのでは？仮想化ソフトベンダーの売り文句の1つにもなっています。

大岩：それはディスクやプロセサのリソースが潤沢な場合に言えることです。予算が限られていましたから、手元にあるリソースを徹底的に使いこなして生産性を高めることに頭を使いました。今、知恵を絞らずにどうするんだという気持ちで…。

水町：苦労した分、技術的な収穫は大きかった（笑）。

─ テストはいかがです？

水町：想定した通り、大変でした。

田中：数百ケースのデータを用意してテストを繰り返したのですが、2〜3カ月は昼チームと夜チームに分かれて24時間体制で検証を続けました。

─ 過酷でしたね。ところで、かつてセキュリティの専門家から、テストに使ったデータから個人情報が漏えいするリスクがあると聞いたことがあります。貴社では何らかの対策を講じましたか。

大岩：もちろん、当然の対策をしています。具体的には、インテグレータが使う開発やテストの環境に、生データはいっさい置きません。原則として開発とテストに使うのは、アグレックスのデータ秘匿システムで人名などをすべて書き換えた開発用データだけ。テストの最終段階で生データを用いなければならない場合は、当社のIT部門のメンバーが必ず立ち会うようにしていました。

ルール管理ソフトを導入しシステムの俊敏性向上へ

─ 最後に、プロジェクトを通じて思わぬ成果があったら教えてください。

水町：1つ挙げるなら、ツールですかね…。

─ ツールというと？

水町：EAIツールです。基幹業務システムから保険証券のデータを抽出したり、生命保険協会に日々の業務報告データを送信したりするのにインフォテリアの「ASTERIA WARP」を使っています。社内外のシステム間のインタフェースを独自に開発してしまうと、開発時の生産性や本稼働後のメンテナンス性が下がってしまう可能性があるので、ここだけはどうしてもツールを導入したかったのです。

─ ツールによって、期待以上に高い生産性を確保できたということですか。

水町：ええ。アグレックスの紹介で導入したのですが、正直なところ、実際に使ってみて少し驚きました。抽出や変換などデータ連携の流れに合わせてアイコンを並べると、コードを自動生成してくれる。ツール特有の癖はありますが、インタフェース開発の生産性は確実に高まりました。

─ カットオーバーから1年以上が経過し、そろそろシステム強化策を考えているのではないかと思います。

水町：現在、ビジネスルール管理ソフトの導入を検討しているところです。

田中：業務ロジックを定義するとJavaのコードを自動生成するツールです。事業の拡大や効率化に伴って業務の流れが変わっても、ルール管理ソフト側でロジックを変更すれば新たなコードを作れる。

─ なるほど、システムの変化対応力を高める狙いですね。

大岩：そうです。適材適所でツールを活用して、システムの俊敏性を高めていきたいと思います。