Other parts of this series:
損害保険会社は、世の中で起きる災害やリスクに対しての補償を商品として販売をし、いざというときに保険金を支払うことで多くの事業企業および契約者の支えとなっている。その反面、システムは年々重厚化しており、特に基幹業務システムは、メインフレームを中心としたレガシーシステムから抜け出しにくい性質である。
一方、テクノロジーは言うまでもなく、大きく急速に変化を続けており、今後も現在にはないものが登場してくるであろう。いかにして、作り上げていく世界から、作られたものを活用する世界へ変革していけるのかを、損害保険の基幹業務に目を向けて論じたい。
台は基幹業務の改革へ
損害保険会社の基幹システムの多くは、198 0 年代のオンラインシステムであり、当時主流であった紙ベースのオペレーションが前提となっている。そこから約30年を超える期間に渡って、脈々と改修され続けてきた基幹システムは、全貌を把握できないほどに肥大化しており、迅速な商品開発ができない状態になっている。
一方、業務パッケージはかなりの進化を遂げている。ルールベースやコーディングレスによる開発、データモデル、基本的なユーザーインタフェース、業務プロセスの導入等、こだわりがなければ、そのまま使うことができる状態にまで達しているパッケージがローンチされており、プレーヤーが増える事で競争原理も生じている。また、ここ数年での変化として、クラウド化・API化・デジタル対応が挙げられ、クラウドソリューションベンダー間の連携も密になってきている。
保険会社は、未曾有の災害・リスクに対しスピーディーに把握・対応し、保険契約者が路頭に迷うことなく、事業および生活を続けていくための支えとなり続けていくことが求められるが、現在のレガシーシステムを改修していくことは限界に達しており、ITコスト削減やビジネスの変化、デジタル化の波に対応するため、各社で実現できる領域（代理店領域、契約管理領域、コールセンター、保険金支払、等）のデジタルトランスフォーメーションを進めていく必要がある。
そもそも基幹業務は競争領域でなくて良い
基幹業務は、契約者・代理店からの保険申込を引き受け、契約を管理するという重要な機能であることに間違いはないが、主に代理店と保険会社が実施する業務自体は、保険会社間での差を競うものではなく、むしろ類似している方が利用するエンドユーザーにとっては分かりやすい。
業務を個別にシステムとして作りあげていくのではなく、定型化した業務の上で災害・リスクに対して各保険会社の補償する保険商品を作れる（扱える）ことが基幹業務に求める要件であり、必ずしも各社の競争領域でなくても良い。
基幹業務は保険版ベルトコンベアになれないのか
他社よりもいち早く補償を提供するには、新たなリスクや社会的課題となる事象を早期に察知し、事象に対する保険商品を企画・設計し、そのシステムを構築していくことが必要だが、手作りで重厚なシステムを改修しているようでは、他社との競争力に欠けてしまう。では、どのようにしたらよいのか。
解決のカギは、業務と商品の分離にある。業務と商品が密結合である場合、商品を作るたびに業務の見直しが入り、商品設計だけでなく事務オペレーションの設計も同時に行う必要があり、システム開発における検討範囲が広くなる。
業務と商品が疎結合である場合、業務自体は変わらず扱う商品が増やせるため、商品・業務だけを分けて考えていくことができる。
つまり、様々な商品が流れることができる業務を標準化することで、いわば保険版ベルトコンベアが実現し、保険会社として販売する補償内容で勝負することが可能となる。
異なる業種からの参入
昨今では、保険ビジネスがメインではない業態からの参入も珍しくない。自社で扱う商品と顧客に、損害保険を連結することで、エンドユーザーに対して一体化したサービスを提供できる。
異なる業種からの参入を見据えると、画面の柔軟性・多様化に耐えられること及びマイクロインシュランスや組み込み型保険等の多様な商品を低コストで迅速に開発できる仕組みを構築しておくことが必要条件であり、保険会社の収入に大きく影響する。基幹業務でのシステム対応に時間を要している場合ではない。
競合との競争力を維持するためには、基幹業務システムの立ち上がりが早いことが求められ、これまでの手作りの世界から、製品の設定で迅速に対応する世界へシフトすることが重要となる。
では、既にあるベルトコンベアを買えば良いのかというと、それだけでは到底、成し遂げられない。
必要なのは業務を変えるという確固たる意志
冒頭に書いたとおり、日本の保険会社には100 年を超える歴史を持つ企業もあり、企業の歴史が長くビジネス規模が大きくなればなるほど、顧客へのサービスレベルや信頼関係が積み重なっており、そう簡単に下げることはできない。どうしてもこれまでの実現していたことは失えない状態となり、導入をあきらめることも想像できる。
結局のところ、現状の要件を全て叶えることに注力してしまい、レガシーシステムを作り直すプロジェクトを生み出してしまうことは良くある話である。だからこそ、改革を進めるための目的と確固たる意志を形成していることが重要であり、変わるんだという意思が現場まで浸透する必要がある。
パートナーと協業・共存したエコシステムの確立へ
これまでは損害保険会社のIT部門が中心となり、自社システムを構築してきたが、現在では様々なテクノロジーとソリューションが存在し、この瞬間にも新たなものが研究開発され、利用可能になってきている。
また、「2025年の崖」によるレガシーの技術者の退職やDX 対応など、パッケージ導入を検討する必要性はさらに増しており、損害保険は国内外で導入の実績があるソリューションを活用し、社内で構築する機能と、パッケージに任せる機能とを見極めることが肝要となる。
すなわち、今後のテクノロジーのさらなる変化やデジタルトランスフォーメーションの取組のたびに右往左往しプロジェクトを立ち上げるのではなく、テクノロジーへ追随しやすいパートナーと協業・共存していくことが将来の更なるビジネス拡大の可能性と、新たなリスクや社会的課題に対応できる柔軟性を生む。パッケージ製品が進化する機会を与えることにもつながり、日本の損害保険のビジネスマーケットにより適用させていくことが可能となる。
一方で、パッケージを導入する上での注意点もある。特に日本へ導入する場合は、パッケージベンダーの日本市場に対する知見・投資意欲も十分に考慮する必要がある。損害保険商品規定への適合や保険会社・代理店・契約者等の関係者の理解等、日本市場に馴染むには時間を要する可能性はある。適切なパッケージベンダーの選定は必要であるが、パッケージの活用は5 年後、10 年後にはニューノーマルとして定着しているであろう。
おわりに
従来は、要件を積み上げて、スコープ調整を経て、設計・開発・検証を行い、システムリリースに至るというシステム開発のやり方が主流であったが、そのようなやり方では、要件を積み上げていく中で真に必要なもの以外の要件もどんどん組み込まれていく傾向にある。また、システムリリース後も追加要件が積み重なり、重厚長大となる。
パッケージ導入を経ることで、改めてシステム要件をパッケージで実現できる機能と照らし合わせ、保険会社として必要なものを選別することが可能となり、製品には無い機能に対して①製品として組み込むべき機能か、②製品外にアドオンしてでも作る価値のある機能か、もしくは③組み込みをやめるかの選択に迫られることとなる。
これこそ、これまで幾度となく肥大を繰り返してきた損害保険の基幹業務システムにとっては、何よりのダイエット方法であると言える。
※FSアーキテクトは、金融業界のトレンド、最新のIT情報、コンサルティングおよび貴重なユーザー事例を紹介するアクセンチュア日本発のビジネス季刊誌です。過去のFSアーキテクトはこちらをご覧ください。
