1．生命保険業界におけるレガシーシステムの現状課題

デジタル技術の急速な進化と市場環境の変化が進む現代において，生命保険業界は重大な転換点に立っている．長年にわたり業界の基幹業務を支えてきたメインフレームはレガシーシステムと呼ばれるようになり，今や企業の競争力維持と事業継続性の観点から深刻な課題となっている．

1980年代から構築・運用されてきたレガシーシステムは，高度に複雑化した商品設計や，多様化する顧客ニーズへの迅速な対応を困難にし，「2025年の崖」として経済産業省が警鐘を鳴らす状況へと企業を追い込んでいる．

経済産業省の「2025年の崖」レポートで指摘された主要な課題は，以下の3点である．

• 老朽化したシステムの維持管理コストの増大
• レガシーシステムがデジタル化の足枷となることによる競争力低下
• 旧式システムに精通したエンジニアの高齢化と後継者不足

アクチュアリー会法人会員へのアンケート調査結果からも多くの保険会社がレガシーシステムの課題を認識しながら，具体的な移行戦略の策定と実行に苦慮している実態があきらかとなった．本研究では，日本の生命保険業界が直面するシステム刷新の課題とその対応策について，具体的な実態調査と戦略的展望の両面から検討する．

＜本稿における各種用語の解説＞

1.1　メインフレームの利用実態

メインフレームの利用実態を把握するため日本アクチュアリー会法人会員の生命保険，損害保険会社44社のアンケートを行った．まず，生命保険業界におけるメインフレームの利用状況は図1のとおりとなった．外資系生命保険会社に比べて国内生命保険会社のメインフレームの利用率が高いことが分かる．

システム別に集計した図2では新契約，数理，契約管理系システムのモダナイゼーションが進んでおらず，メインフレームの利用割合が多いことが分かる．一方，新契約，数理，契約管理系システム以外では，クラウドの利用が進んでいる実態が把握できた．

クラウド移行の検討状況に関する調査結果（図3）では，方針検討中の割合が全体的に大きいことが分かった．

1.2　「2025年の崖」が保険事業に与える影響

前述のアンケート結果のとおり，メインフレームのクラウド移行を検討している企業が多いにもかかわらず，クラウド移行が思うように進まないのはなぜか．生命保険業界にかかわらず，クラウド移行には対応が困難な事情がある．一般的な課題として大きく4点を挙げる．

（1）人材の課題

経済産業省の「2025年の崖」レポートにおいても，IT人材の枯渇が叫ばれる中，現業のシステム開発だけで手いっぱいの現場が多くあり，クラウド移行に投下できる人材は不足している．また現行仕様を熟知するベテランも減少しており，クラウド移行を実施する前段階として現行仕様の分析をする人材がいない．さらにクラウド移行には専門知識が必須となるが，クラウド開発を熟知した人材が不在なため，クラウドベンダーの有識者など外部要員に頼らざるを得ないといった現状がある．この現状は，当研究班が実施したアンケート結果（図4）にも表れており，クラウド移行検討時の課題・将来的な懸念事項として約75％が知識・ノウハウ面や人的資源の不足を挙げている．

（2）組織の課題

クラウド移行は業務改革を伴うため，事務部門の業務の整理・再構築が必要である．システム部門の一存で移行を進めることはできず，関係部門・関係者は多岐にわたり，プロジェクトは大規模なものになる．さらに業務の整理・再構築を進める中で，社内の合意形成に苦慮する可能性が考えられる．たとえば，事務部門の業務内容が大きく変化し，業務自体が変わることによる運営上の負担を意識して，事務部門が業務の整理・再構築に非協力的となることが想定される．

（3）移行の課題

クラウド移行には，移行対象のシステムや周辺システムの影響調査や，移行に伴う意図しない変更を避けるために大規模な回帰テスト^☆1が必要となる．また移行対応中は，抜け漏れのない機能移行のために，現行システムの改修に制約が生じる．さらに周辺システムの並行開発を考慮する必要がある．移行中の有事の際のシステム環境を，新環境とは別に並行で用意しなければならないケースもある．

（4）クラウドの特性による課題

パブリッククラウドサービス^☆2を利用する場合は，定期的なメンテナンスやサービス障害など，自社のコントロールが及ばない領域で問題が生じる可能性がある．またメインフレームと比較した際に，レイテンシー^☆3などの問題から応答速度が低下するなどの性能劣化の懸念があり，各社のSLA^☆4に耐え得るための対応が必要になる．

以上の課題から，クラウド移行は一般的にコスト・リスクが高く，多くの企業においてクラウド移行へ踏み切る経営判断ができない状況が続いている．

1.3　生命保険業界固有のシステム要件と技術的負債

一般的なクラウド移行の課題に加えて，生命保険業界にはクラウド移行を困難とする特有の課題がある．生命保険業界が所有するシステムには4つの特徴があり，生命保険業界において，システムのモダナイゼーションの難易度を高めている．

（1）販売チャネルの多様さ・複雑なインターフェイス

生命保険業界においては，保険商品の顧客への訴求力が売上に直結するため，顧客への積極的なアプローチを実現すべく販売チャネルを多様に用意しているケースが多い．営業職員が使用する営業活動支援システム，問合せを受け付けるコールセンターシステム，顧客から直接申し込みを受け付けるインターネットシステムなどが例として挙げられる．メインフレームを移行する場合は，この販売チャネルシステムそれぞれのデータ形式，データ連動の方式などのインターフェイスを考慮した上での方針決定が必要である．

（2）ブラックボックス化した仕様（複雑な商品性・長期に亘る商品処理の維持）

生命保険システムは各生命保険会社の考案した複雑な商品性を実現するため，たとえば保険料計算，責任準備金計算を担う数理システムなど，前提として生命保険知識なしでは理解ができない非常に複雑なロジックを含んでいることがしばしばある．保険種類ごとにシステムを分岐させて構築しているケースも多く，仕様のブラックボックス化に陥りやすい．

また生命保険においては，基本的に加入した被保険者が全員脱退（死亡脱退を含む）するまで商品を維持する責任を負っているため，各商品処理の維持保守期間が長期化する．保険商品の販売停止後にすぐ当該システムの機能を止めて廃止対応することはできない一方で，新商品開発当初の開発メンバーは定年により引退し，設計書等のドキュメント整備が追い付かないケースが散見される．このことはブラックボックス化を加速させていると考察できる．

（3）個人情報を含む大量データの長期保管

生命保険システムにおいては，契約期間が長期間となるため数十年に渡る大量の契約データおよび保有期間における全異動データを保管することが必須要件となる．加えて，機微情報を含む顧客データの保管も必要である．このデータ保管には，金融機関としての強固なセキュリティ対策が必要であり，安易な外部サーバーへのデータ移行を阻害する要因となり得る．

（4）金融機関として遵守すべき要件（業務継続・法令）

生命保険システムは保険料の収納，保険金の給付など顧客との金銭のやり取りを含む金融システムのため高精度の処理を求められる．人の命に係わる商品を扱っているからこそ，堅牢なBCP対策^☆5によっていかなる状況でも業務継続性を維持する必要がある．メインフレームにおいては，複雑なバッチ処理^☆6によって，各生命保険会社のシステム要件に合わせたシステム稼働を実現しているが，このような処理をクラウド環境でそのまま実現することが難易度を高めていると考えられる．また各法制度の改正にも速やかに対応する必要がある．移行によって安全性やシステム精度を担保できないことは避けなければならない．

以上のような生命保険システムの特性（図5）がクラウド移行，システムのモダナイゼーションをより一層難しいものとしている，という現状課題が確認できた．

2．レガシーシステム継続による将来リスク

2.1　COBOLエンジニア不足と知識継承の断絶

前章ではレガシーシステムの現状課題によりシステムのモダナイゼーションおよびクラウド移行が困難な状況を確認してきた．続けて本章ではレガシーシステムをこのまま継続することが現実的に可能であるかについて考察していく．まず人材の課題から取り上げていくと，COBOLエンジニア不足の問題が挙げられる．メインフレームを維持する場合，そのシステムを開発・保守運用するシステムエンジニアの確保が不可欠となる．このシステムエンジニア確保の困難さについて，2つの面から考察する．

（1）新規COBOLエンジニアの調達の困難さ

図6は，プログラミング言語の人気度を毎月測定する指標を提供する，TIOBEインデックスのデータを参考に作成した，2024年12月時点の人気TOP3のプログラミング言語，およびCOBOL言語のトレンド推移である．PythonやC++，Javaなどのオープン系言語がTOP3にランクインしている一方で，COBOL言語は19位と比較的低い順位で横ばいであることが確認できる．このことから，新規にCOBOL言語を学ぼうと考えているシステムエンジニアは少ないことが示唆され，メインフレームを維持するために新たなCOBOLエンジニアを確保することは今後難しくなることが考えられる．

（2）既存COBOLエンジニアの高齢化

図7は，ロイターが2017年に調査した，米国の金融業界のCOBOLエンジニアの平均年齢を示したグラフである．このグラフから45歳以上の層が全体の60%以上を占めており，COBOLエンジニアの高齢化が進んでいることが分かる．また，本調査が7年以上前のデータであることを加味すると，該当層の多くはすでに退職年齢になっていることも考えられ，COBOLエンジニアの不足はより一層進むことが示唆されている．

2.2　保険システムの技術的負債

次に，ビジネス機会の損失の課題について取り上げていきたい．生命保険会社として市場競争力のある新しい商品やサービスを展開するにはVUCA^☆7時代の顧客が求める保険機能および保障内容に対応するため，新しいサービスや新規技術を導入・利用したい場面が生じると考えられる．その際，自社システムのデータ活用，外部システムへのデータ連携が求められる．レガシーシステムのままこれらの対応をしようとすると，次に挙げるようなさまざまな技術的負債が課題として生じる．

（1）データ

メインフレーム上で長期間保管され更新を繰り返されたデータは，複雑化している傾向が高い．複雑化の要因の一例を挙げるとすれば，メインフレーム上のレガシーシステムで多く使用されているCOBOL言語においては，テーブル上のデータ項目を再定義^☆8する手法がしばしば利用されており，1つのデータ項目を複数の名称で再定義しながら使用する，入れ子式のデータ管理を生み出している．

特に生命保険業界においては保険商品ごとに管理すべき情報が異なるため，固定長ではなく可変長でデータを管理し，商品ごとにデータ項目を再定義することで，レコード単位の使用領域を少なくし，できるだけリソースを節約する努力を重ねている．そのような生命保険システム上には，独自のデータ構成をもち，同じデータが別の名称で重複して点在し，正規化が適切に行われないまま運用されているデータベースも多くある．

また特に国内企業のシステムにおいては，個々のデータ名称に英語ではなく日本語名称または日本語＋英語名称〔例：HIHOKENSHA-BANGO（被保険者番号），KIGO-SHOKENNO（記号証券番号）〕が使用されているケースも散見される．このようなデータ名称では海外企業・ソフトウェアやシステムエンジニアによるデータ解析は不可能に近く，せっかく長年蓄積した生命保険会社の財産ともなり得るデータは，再整理をせずに利活用することが難しい．

（2）ロジック

現在国内企業で利用されているメインフレーム上のレガシーシステムは，1980年代から1990年代に初期開発されたものが主流で，約40年以上前の古い設計思想がロジック上残存している．また言語としても大半がCOBOL言語を使用していることから，Java言語に代表されるオブジェクト指向^☆9とは異なり，構造型プログラミング^☆10でコード設計されている．このことが処理を冗長的に記述する性質を有しており，レガシーシステムはJava言語などモダン言語からネイティブに設計・開発されたシステムよりも膨大なステップ数となる傾向が高い．

また長期利用される中で，過去のシステム不備に対して行った臨時的なパッチ対応が残存し，プログラム上に点在しているケースも考えられる．当時対応したシステムエンジニアが現場を離脱し，紙ベースの保守ドキュメント管理が不十分だと，システム解析が不能となって抜本的な改修に踏み出せないようなケースは多い．

このようなロジックの複雑性・重複性がシステム開発に向けた現行分析，その後の保守の難易度を高めている．

（3）システム環境

国内大企業については自社のデータセンターを設立し，自社内でメインフレーム・サーバーを含めた運用・保守を行っているケースが多くある．また特に金融業界においては，システムの可用性を高める目的やユーザーから要求される高いセキュリティ対策のために，パブリックな環境ではなく自社専用のシステム基盤を構築しているケースが多い．このようなクローズドなシステム環境では，外部サービスと連携するハードルが高い．

たとえばメインフレームとパブリッククラウド上の外部システムを直接接続することは，インターフェイスの違いから難しいため，いったんオンプレミスシステムを介在して外部接続するような冗長なシステム構成をとることとなる．この場合，それぞれの接続部分でのインターフェイスのすり合わせや影響調査，テストが必要になる．日本企業においては組織や業務を縦割りとする傾向から各システムがサイロ化^☆11しており，部門ごとに管理していることも想定される．接続システムが増えるほどに各担当間での調整事項は増え，開発の難易度が高くなる．

このように，新規サービスや新規技術は，メインフレーム上に実装したシステムレガシーシステムと相性が悪く，社会的ニーズに合致した機動的かつ斬新な保険ビジネスを展開しようとしても，レガシーシステムが足枷となる．

2.3　商品開発サイクルの長期化

次に，生命保険システムにおける新商品開発を例に挙げて，保険商品の開発サイクル長期化について検討する．

（1）顧客のニーズ分析

新商品開発には事前の顧客ニーズ分析を必要とする．しかしレガシーなシステムにおいては，前述のとおりデータ仕様やデータ構成の問題で，本来であれば潤沢な情報元となり得る既契約データに保険業法以外の情報（マーケティングやニーズ分析のための顧客特性情報）を含めることができず，長年蓄積したデータを十分に活用することができないという課題を抱えている．そのため新規にデータの収集や外部情報機関からのデータ買い取りが必要となり，調査や分析費用においてコスト増加を招くこととなる．

（2）新商品開発

レガシーなシステムにおいては，複雑化した大規模なロジックの特性により小規模な開発においても多大な影響調査やテストを要するケースが散見される．既存商品向けのロジックやシステムが密接につながっているため，新商品において同じ計算処理を実装する場合でも既存商品への影響が懸念される．そのため実装には細心の注意を要する上に品質担保には膨大なテストケースが必要である．このことから開発期間は長期間化することが常態化し，市場投入前に開発初期の想定していた市場環境が変動して，時代遅れな新商品をリリースするリスクが高まる．また競合他社によって類似商品が先に販売されてしまうリスクも高くなる．

（3）営業力強化

新商品の実装が無事に完了できたと仮定して，営業支援システムを追加開発しようとする場合を考える．前述のように新規に外部サービスを利用しようとしても連携が困難であることが想定される．また独自システムを新規構築するとしても，メインフレーム側の制約による障壁が想定される．たとえばツールへの最新情報のデータ反映に数日かかるなど営業職員の機動力を損なってしまうケースが想定され，商品販売の機会損失リスクが懸念される．

以上の検討事例から，レガシーシステムを維持したまま商品開発サイクルの長期化を改善するのはシステムの仕組みとして困難であると考えられる．

2.4　システム維持コストの高止まりと収益性への圧迫

システムの自社保有（オンプレミス）は，商品開発コストの損失，商品開発期間の長期化，要員調達の困難さ・調達コストの増加，基盤運用コストの増加，基盤調達費の高騰などにより運用・保守コストが高止まりする要因になる．その結果，初期投資も高く，運用保守コストも高い状況が続いてしまう．JUASの2024年企業IT動向調査では，日本企業のIT予算の内，約80%は運用・保守コストとなっている．攻めのIT投資を行いたいとしても原資を確保できず，ビジネス展開において大きな制約を抱えることになっている．

最後にレガシーシステムにおける各保険会社の課題意識についてアンケート結果（図8）を確認する．一番課題視されている事項として「新商品開発ニーズに対するシステム開発スピードの遅さ」が挙げられている．また，「技術者（システムエンジニア）不足による人件費高騰，採用・育成」も上位に挙がっており，今までに挙げた課題が各保険会社においても意識されていることが確認された．

3．クラウドネイティブ化による保険システムの価値向上

3.1　商品開発・提供サイクルの迅速化と顧客ニーズへの対応力強化

前章で確認したとおり生命保険業界においては，商品の設計・開発・提供までに長い期間を要することが一般的であった．しかし，市場環境の変化や顧客ニーズの多様化に対応するためには，これまでのような長期的な開発サイクルでは競争力を維持することが難しくなっていくことが想定される．本章からクラウドネイティブ技術を活用することで，保険商品の開発スピードを向上させ，より柔軟な提供が可能となる点を示していく．

（1）クラウドネイティブ化による商品開発の迅速化

クラウドネイティブアーキテクチャ^☆12では，従来のモノリシック^☆13な開発手法から脱却し，マイクロサービス^☆14を活用した柔軟なシステム開発が可能となる．これにより，以下のようなメリットが得られる．

• 開発の並行実施が可能：サービスを細分化し，個別の開発チームが独立して作業できるため，開発期間の短縮が実現．
• CI/CDによる迅速なデプロイ：継続的インテグレーション・デリバリー（CI/CD）^☆15の活用により，新機能や改善を迅速に市場投入．
• コンテナ^☆16技術の活用：アプリケーションをコンテナ化することで，環境依存の影響を排除し，開発スピードを向上．

（2）顧客ニーズへの迅速な対応

デジタル化の進展により，顧客の期待値は高まり，多様なサービスをリアルタイムで提供する必要がある．クラウドネイティブ技術を活用することで，以下のような対応が可能となる．

• 短期・小規模開発の繰り返しが可能：小規模な単位で開発を行い，事業環境の変化を即座に反映しながら段階的に改良を進めることが可能．
• データドリブンな商品設計：クラウド環境でビッグデータやAIを活用し，契約者の行動分析や市場動向を即座に反映した商品設計が可能．
• パーソナライズドサービスの提供：APIを活用した外部サービスとの連携により，個別顧客のニーズに応じた商品やプランの提供が容易．
• オムニチャネル対応の強化：Web，モバイル，コールセンターなど，あらゆるチャネルを統合し，一貫した顧客体験を提供．

3.2　システム基盤コスト構造の最適化と投資効率の向上

少子化社会における持続可能性の向上も欠かすことのできない論点である．保険業界においてもIT人材の高齢化や採用難が進む中，システム基盤のコスト構造を最適化し限られた人材で効率的な運用を実現することが求められている．クラウドネイティブ化の主要な利点の1つが自動化・省力化であり，従来と同等以上のサービス品質を，より少ない人員で維持することが可能となる．

具体的には，DevOpsの導入により，開発から運用までの一貫した自動化が実現し，人的作業を最小限に抑えることが可能となる．また，クラウドネイティブアーキテクチャによる柔軟な資源配分により，システム運用の効率化が図れることが挙げられる．これらの取り組みはコスト削減だけでなく，貴重な人的リソースをより価値創造的な業務に再配分することを可能とし，結果として投資効率の向上にも寄与するものである．

3.3　デジタル人材の確保・育成と組織活性化

クラウドネイティブ化によって，デジタル人材の確保・育成と組織活性化の面においてもメリットが得られる．レガシーシステムのクラウドネイティブ化を進めていくにつれ，採用する技術や考え方には大きな変化が生じてくる．その過程が，業務刷新・改革に必要なデジタル人材の獲得につながり，事業環境の変化に即応できるような組織の活性化を図ることができる．以下に主な変化とその影響について述べる．

（1）担当・責任範囲の変化

従来のメインフレーム上のモノリシックなアプリケーションにおいては，アプリケーションエンジニアは業務ロジックのみを，インフラエンジニアはシステム基盤部分のみを担当すればシステムの開発運用保守は事足りた．しかしクラウドリフト^☆17，クラウドネイティブ化が進むにつれて，業務ロジックのみ留意していたアプリケーションエンジニアが，責任を持つべき領域は次第に拡大する．下記に担当領域の変化を図にして整理した（図9）．

セキュリティを例に挙げる．メインフレーム上に実装されたシステムにおいては，アクセス制御や外部との通信については，インフラエンジニアの領分であり，アプリケーションエンジニアが留意するべき領域は少ない．一方で，クラウドに移行し，システムをオープン化すると，外部からの攻撃に備えた実装を検討する必要が生じる．さらにクラウドネイティブ化すると，サービスがマイクロサービス化しAPI^☆18でサービスを提供するようになるためネットワーク面でのセキュリティの考慮が求められるようになる．

続けてキャパシティプランニングについて考察する．従来であればインフラ側で事前に用意されたCPUやメモリ・ストレージを前提にアプリケーションを実装すれば十分であった．一方で，クラウド環境では，計算リソースは柔軟に確保できるため，業務の観点から見たリソースの事前設計・検討が必要となる．業務処理量が通常どのくらいあるのか，処理のピークは発生し得るのか，あるいは予測不可能であるか，そういった観点はインフラエンジニアではなく，アプリケーションエンジニアの領分である．クラウドリフトをした直後の状態においては，アプリケーションは依然としてモノリシック（もしくはそれに近い状態）であると想定され，その時点ではインフラエンジニアの担う領域が大きいが，クラウドネイティブ化が進み，サービスの分割が進むと，アプリケーションエンジニア側主体で，キャパシティを検討・チューニングする必要が次第に生じる．

完全にインフラから切り離してアプリケーションの領域に変換されるべきか否かは，対象のシステムの特徴や，そのシステムを保有する企業の組織体制に依存するところがあり，一概に言えることではない．しかし，担当領域に変化が生じ，徐々にアプリケーションエンジニアが留意するべきことが増えてくる，という点に違いはないであろう．このような保険システムのモダナイゼーション過程が，次世代のシステムに対応できる人材育成につながる．

（2）開発思想の変化

クラウドリフト・クラウドネイティブ化は，担当領域の変化のみならず，システムを開発・保守・運用する思想にも変化を与える．

 a．計算リソースは従量課金される

クラウドにおいて計算資源は柔軟に確保することができるが，一方でそれらの計算資源は従量課金される．オンプレミスでシステムリソースを利用する場合は，その性能の範疇でコスト面を気にせずリソースを利用できたが，クラウドにおいてはリソースの使用量がコストにそのまま反映される．予想外のコスト増を防ぐためにも，無駄なリソース消費がないか，開発・保守・運用の観点から常に気を配る必要がある．

 b．言語特性の違い

COBOLからJavaに変換する場合，両言語は言語特性に違いがある．一方は手続型言語^☆19，他方はオブジェクト指向型言語^☆20である．実装の前提となる考え方が異なるため，継続的リファクタリング^☆21を進めていく上では，留意が必要となる．開発規約やコーディング規約を再整理し，一貫した方針のもと開発・運用・保守を進める必要がある．

 c．開発プロセス・運用プロセスの違い

従来のレガシーシステムでは，ウォーターフォール型開発^☆22が採用されることが多かった．一方で，クラウドネイティブなシステムの開発においては，アジャイル型開発^☆23が基本となる．システムの特性によってはアジャイル型開発が適さない場合も存在するが，事業環境の変化に迅速に対応するには，アジャイル型開発が望ましい．

またシステム構成の面においても大きな違いがある．クラウドの特性の1つである，柔軟な計算資源の確保は，クラウドネイティブに対応するならば，IaC^☆24やコンテナを活用して自動的にスケールアウト・スケールイン（コンピュータリソースの量的追加・削減）することとなる．この方法を採用する場合，事前にコンテナイメージを作成する，インフラ構成をコードにする，スケールアウト・スケールイン時の接続維持のためにステートレスな通信^☆25を前提にアプリケーションを構築するなどが必要になる．前提として，こういった知識・技術の獲得が必要となる．

（3）ベテランエンジニアの役割の変化

ここまでアプリケーションエンジニアとインフラエンジニアの担当領域の変化と，前提となる開発思想の変化について述べた．こうした前提の変化にあたっては，担当するエンジニアの再学習が必要になる．組織の観点では，エンジニアの再学習を後押しするような施策が必要である．クラウド知識の習得の推奨や，クラウドネイティブ化を前提としたプロジェクト全体のルール・規約作りが求められる．

新しい技術や思想の導入にあたり，それらの知識を保有するエンジニアの外部採用も十分に選択肢に入るが，一方でクラウドリフト・クラウドネイティブ化にあたっては，既存のシステムの仕様を熟知したベテランエンジニアの参画も必要不可欠である．クラウドリフトにおいては，自動変換できない個所のコードの解析や仕様面から見たバグの解析，クラウドネイティブ化においては，適切なアプリ分割，モジュール化を進める上でその知見を最大限活用することができる．

以上，クラウドネイティブ化により，エンジニアにおける，担当・責任範囲の変化，開発思想の変化，ベテランエンジニアの再学習について述べた．これらの変化に適切に対処することが，クラウドネイティブ化には求められる．一方で，その過程が，次世代のシステムやビジネスを担うデジタル人材の確保・育成やITを真の意味で活用した組織活性化につながることとなる．

4．事業目標を踏まえた段階的移行アプローチ

前章では保険システムの価値向上のためにクラウドの活用は有力な選択肢となることを示した．一方で，レガシーシステムのクラウド移行は，一般的に高難易度・高コスト・高リスクである．特に生命保険業界においては，複雑なインターフェイス・バッチ処理，ブラックボックス化した業務，超長期のデータ保全などの固有課題が難易度を高めているが本章では生命保険業界におけるクラウド移行の新たなアプローチを提案していく．

4.1　事業目標と移行目的の整合性確保

高難易度な生命保険会社におけるクラウド移行は，まず移行目的を明確にすることが重要となる．クラウド移行自体も長期に渡るプロジェクトとなるが，システムのモダナイゼーションのためには，クラウド移行が完了したのちにも継続的な改善が欠かせないため，短期的なメリットを追求することは適切でないと考えられる．短期的なメリットが得られず，かつ移行目的を明確にしない場合，移行の軸が定まらず，移行に伴う部門間の調整や一貫性を持った移行計画の策定や遂行が困難になることが想定される．結果，クラウド移行を完遂してもクラウドプラットフォームの利点を十分に活用できず，クラウドによって得られるメリットが限定されるばかりでなく，かえって運用コストの増大を招く結果となりかねない．

移行目的の設定は，システムのモダナイゼーションにとどまらず業務の改善，デジタルトランスフォーメーションにも直結する内容となる．つまり，経営戦略・事業目標に直接関係する．その観点から，クラウド移行においては，経営層の強固なコミットが求められる．単純にメインフレームを廃止することを目的とするのではなく，クラウドへと移行することによってどのような自社の課題を解決するのか，どのような事業を展開して社会に付加価値を提供するのか，自社が使える経営資源は何か等を踏まえて，移行目的を明確に定め，全社的に展開・周知する必要がある．

計画実施の段階においても，クラウド移行を進めるプロジェクトが，社内調整をスムーズに進めるためにも体制や組織，人員，資源の面でサポートを行う必要がある．また，クラウド環境への移行が完了し，クラウドネイティブ化を進めるにあたっても，継続的な改善活動の推進を可能とするような体制を構築することは欠かせない．なお，具体的にどのような観点で検討が必要か，自組織がクラウドネイティブ化を進めるにあたってどの程度備えられているかを判断・確認するために，「保険会社向けクラウド移行成熟度評価フレームワーク」を作成し文末に付録した．クラウドネイティブ化を進めるにあたり自社の状況を分析し，次ステップとして何を目指すかの参考としてお役立ていただければ幸いである．

また，移行目的によって，どの程度クラウドを利活用するべきかは変化する．事業目標によっては必ずしもクラウド移行が適切でない場合がある．各目的に応じて，どのような移行方針をとるべきかは，表2に整理した．

4.2　保険会社の事業特性に応じた最適移行戦略

次に，段階的移行について触れる．高難易度・高コスト・高リスクである生命保険業界のクラウド移行においては，集中して対応するべき課題を切り分けて，リスク分散を図ることが求められる．移行目的や経営戦略に基づき，適切な進め方は各社ごとに検討が必要となるが，一番難易度が高いことが想定される，大企業・大規模システムの基幹システムのクラウドネイティブ化を目指す場合，大きく2つのフェーズに分けて段階的に進める必要がある．

（1）第1フェーズ：メインフレーム上のシステムのクラウドリフト

段階的移行の第1フェーズとして，メインフレーム上のシステムをクラウド環境に移行する．ここでは，業務ロジックの改修を極力抑えつつ，環境の移行に伴う改変に集中する．具体的には，外部システムとのインターフェイス部分や，セキュリティ，データベースやOSといったシステム構成の変更に伴う改修に注力する．いわゆるクラウドリフトを進める（図10）．

ブラックボックス化した仕様の問題や手続き型プログラミングに特化した冗長なシステム構造の問題は残存するが，それらを一挙に解決することは難しい．まずはインフラ面での改修に集中することで，困難を切り分け，クラウド移行に係るコストと難易度を抑える．

クラウド移行にあたっては，ツールの利用が不可欠である．なぜならば，クラウド移行においては，ソースコードの変換や移行など，業務要件が直接に関与しない領域が多く，いかに作業を自動化・効率化するかが，成功の可否に大いに影響するからである．また，大規模な回帰テストを実施して現行機能保証を図るためにも，テストの効率化は欠かせない．表3に挙げるようなツールを移行計画策定時に検討し，活用していくことが求められる．

なお，ツールの利用による作業の自動化・効率化はほぼ必須ではあるが，すべてを自動化することは現実的ではない．自動化の困難な部分に関しては，現行仕様の理解に基づいた手作業での改修が発生し得る．その際は，既存のシステム仕様を熟知したベテランエンジニアの活用が強く求められる．

コード変換ツールについて補足する．コード変換においては，言語変換方式も検討が必要となる．大きく分けて，Javaに変換する方式，COBOLライクな文法のJavaに変換する方式（Jobol方式），移行先でもCOBOLを利用する方式のそれぞれがある．メリット・デメリットを表4に整理した．いずれを選ぶかにおいても，移行目的や事業目標に基づく判断が各社において必要になる．

（2）第2フェーズ：クラウドネイティブ化と継続的リファクタリング

第1フェーズのクラウドリフトが完了し，その後の運用も安定した段階で，第2フェーズを検討する．クラウドリフトの段階では，システム基盤がクラウド環境に単純に移管した状態であり，クラウドのメリットを最大限に発揮している状況とは言えない．この状況では，依然としてレガシーなシステムからは脱却しきれておらず，柔軟な事業展開の観点では制約が大きい．ここから，クラウドネイティブ化を図っていくことになる．

クラウドネイティブなアプリケーションにおいては，サービスを細かく分割するマイクロサービス化を検討していく．ただし，大きなシステムであればあるほど，その作業は困難を極める．また，生命保険業界における最適なサービスの粒度については一般解がなく，模索が必要となる．生命保険業界におけるレガシーシステムのクラウドネイティブ化は先行事例が少なく，また各社のレガシーシステムはフルスクラッチ^☆26されている点からも試行錯誤の域を出ないが，生命保険システムの実例に即して，1つの例を検討した（図11）．

クラウドリフトしたモノリシックなシステムを，独立して稼働することのできる大まかなドメインに分割する．たとえば，新契約や契約管理，契約内容照会等を1つにして契約管理ドメインに，保険料，責任準備金，配当金等を最適な計算リソースを使用して処理する数理計算ドメインに，請求受付，保険金支払の査定と実行を監督する支払管理ドメインに分割する．

こうして大まかなドメインに分割した後は，各ドメイン内においてリファクタリングを行う．改修頻度の高いロジックからモジュール化，アプリケーションの最適化を進め，徐々にサービス分割を進めていく．以上のプロセスを継続的に行い，リファクタリングを繰り返していくことで，最終的にクラウドネイティブ化を目指していく．

この開発プロセスは広義のウォーターフォール開発からアジャイル開発への変更も表している．次世代のモダンなシステムにおいては，システムの最終系が計画段階で示されるのではなく，その時々の事業環境に応じた最適な姿に有機的に作り替えていくことが求められる．事業環境の変化だけでなく，クラウドプラットフォームの進化によっても都度最適な状態を目指すことがクラウドネイティブ化の思想的転換と考えられる．

（3）企業規模別システム規模別の移行パターン

ここまで大規模システムにおいてクラウドネイティブ化を進めることを前提として述べてきた．しかし現実には企業の規模やシステムの複雑性に応じて最適な移行戦略は異なることが想定される．このため本稿では，企業環境を考慮した実践的な移行パターンを提案したい．

移行戦略を企業規模とシステム規模という2つの軸に分類することで，それぞれの状況に適した移行パターンが作成できる．図12はこの2軸によって分類された4つの移行パターンを示している．

大企業においては，人的リソースや資金等の経営資源が比較的豊富であるため，長期的な視点での段階的移行が可能である．一方，中小企業では限られた経営資源の中で効率的な移行を実現する必要があると考えられる．またシステム規模の観点では，大規模システムは複雑性が高く影響範囲が広いためリスク分散が必要となる．中小規模システムは影響範囲が一定程度限定的であり，より迅速なアプローチが可能となることからリビルド^☆27による複雑性の解消が期待される．

• ①大規模システム・大企業　　　基盤移行からの段階的な移行戦略

  COBOLのままクラウド環境にシステムを移行．その後クラウドネイティブ化を進める．超長期間のプロジェクトとなるが企業体力的に可能．リスク分散と有識者の活用に重きを置く．

• ②大規模システム・中小企業　　リホストからの段階的な移行戦略

  Javaに変換しつつクラウド環境にシステムを移行．その後クラウドネイティブ化を推進する．人材調達面での課題解決に重きを置き，オープン化も併せて行う．

• ③中小規模システム・大企業　　サブシステム単位でのリビルド戦略

  業務ロジックの最適化も併せて，サブシステムごとにクラウド移行を行う．
   リスク分散を図りつつ，早期のクラウドネイティブ化を目指す．

• ④中小規模システム・中小企業　リビルド移行戦略

  業務ロジックの最適化も併せて，クラウド移行を行う．
   リスク分散を図りつつ，迅速なクラウドネイティブ化を目指す．

上記で提案した企業規模とシステム規模による移行パターン分類は1つの目安であるが，実際のクラウド移行戦略を検討する際は移行体制の準備状況や移行計画の作成状況も重要な判断材料となる．自組織の現状を正確に評価，診断するため，本稿では付録として「保険会社向けクラウド移行成熟度評価フレームワーク」を作成した．このフレームワークを活用することで，自組織のクラウド移行に関する準備状況を客観的に評価し，次に取り組むべき重点領域を特定することが可能となる．移行戦略を具体的に推進していく際は，ぜひ付録のフレームワークも併せて参照されたい．

5．結論

5.1　本研究の主要な発見と知見の総括

レガシーシステムを保持し続けることには，人材確保の面，柔軟なサービス展開，運用保守コストの高止まりの観点で大きな課題がある．これらの解決のためにも，システムのモダナイゼーション，その前提となるクラウド環境への移行は必要になる．一方で，クラウド移行は一般的に難易度が高い．とりわけ生命保険業界においては，業界固有のシステムの特徴（複雑なインターフェイス・バッチ処理，ブラックボックス化した業務，超長期のデータ保全）があり，その難易度をさらに高めている．こうした背景が，クラウド移行の判断や移行計画の策定が難航する要因となっている．

しかし，企業の競争力を高め，持続可能な事業を展開するためには，システムのモダナイゼーションが求められており，その推進のためにはクラウドの利用が必要不可欠である．特に商品開発・新規ビジネスの展開の迅速化を目的とするならば，クラウドネイティブを推進する必要がある．ただし，クラウド移行に唯一絶対の方式は存在しない．各社ごとの経営戦略や経営資源，置かれた事業環境などの前提によって，無数の選択肢が存在する．そのような困難な状況下において成功させるための要素としては，移行目的の明確化と経営層のコミット，段階的移行と継続的リファクタリングの2要素がある，と当研究班では結論づけた．

5.2　デジタル時代における保険事業の将来展望と課題

最後に，今後の展望について触れる．少子高齢化社会の進展により，今までシステムの開発・保守・運用を担ってきた人材は退職年齢となる一方で，人口の減少により若い人材の確保はより一層困難になることが想定される．少ない人材の活用のためにも，業務の生産性・効率性の向上はより一層求められる．このような観点からも，システムのモダナイゼーションとクラウドの活用は急務である．

一方で，前述の社会的背景からクラウド移行のニーズは一層高まることが想定される．市場規模の拡大を受けて，クラウドベンダーがモダナイゼーション向けのソリューションを強化する可能性がある．また，生成AIなど最新技術や最新サービスも同様に動向を注視するべきである．今は高コスト・高リスクなクラウド移行であっても，クラウドベンダーのサービス拡張や，技術革新でブレイクスルーが起きる可能性がある．継続的に動向を注視しつつ，移行判断や移行計画への取り込みを図るべきである．

また，現状見えている課題への対策や，競争力の確保といった観点だけでなく，現時点では見えていないリスクに備えるという点でも，クラウドネイティブ化は求められる．今時点では予測できない科学技術の進展や社会情勢，ビジネストレンドへ備える点でも，柔軟かつ迅速に対応することができるシステム構築は必要不可欠である．

生命保険業界におけるメインフレーム上に構築されたレガシーなシステムのモダナイゼーションは先例が少なく，困難な課題である．すでに2018年に提示された2025年の崖問題が指摘する年は到来しているものの，依然として対応状況は芳しくない．経営層も，業務部門も，システム開発部門も，運用部門も一丸となって取り組まなければならない課題である．しかし，その困難を乗り越えた先に，各個人においても，各社においても，生命保険業界においても，希望の将来がある．社会ニーズに即した新商品・サービスを迅速に展開し，生命保険業界がより社会に貢献できる未来があるのではないだろうか．本研究がその未来の実現のささやかな一助となれば幸いである．

付録：保険会社向けクラウド移行成熟度評価フレームワーク

評価方法と活用ガイド

（1）評価プロセス

• 各項目をレベル1〜5で自己評価
• 部門横断チームによる評価を推奨
• 四半期または半年ごとに再評価

（2）スコアリング

• 全体平均スコア＝全項目の平均値
• 領域別スコア＝各領域の平均値
• ギャップ分析＝レベル5との差分を項目ごとに分析

（3）経営判断への活用

• 平均スコア2.0未満：基礎構築フェーズ（意識改革と教育が優先課題）
• 平均スコア2.0〜3.0：計画策定フェーズ（詳細計画の策定と初期実装が優先課題）
• 平均スコア3.0〜4.0：実行フェーズ（計画的実行と成果測定が優先課題）
• 平均スコア4.0以上：最適化フェーズ（継続的改善と価値最大化が優先課題）

（4）優先課題の特定

• 最もスコアが低い領域を重点的に改善
• 依存関係のある項目をグループ化して対応
• 短期的成果を出せる項目から着手

本稿を執筆するにあたりベンダーレクチャーを実施いただいた，アマゾン ウェブ サービス ジャパン（同）様，（株）日立製作所様，日本アイ・ビー・エム（株）様，ならびにアンケートにご協力いただきました日本アクチュアリー会法人会員各社様には，心よりお礼を申し上げる．