InsureTech
White Paper[著者]株式会社 justInCase / justInCaseTechnologies
CEO

畑加寿也

[執筆協力]
OneDegree Global (SG) Pte. Ltd.
Co-founder

2021/09

Alex Leung目次

1. はじめに3

2. 保険と保険商品の未来

4

5. 規制環境17

5.1 データセキュリティ対策

17

5.2 各国における新商品・サービス開発の状況

182.1 外部環境の変化による保険のあり方の変化

4

2.1.1 少子高齢化と低金利環境の継続

4

2.1.2「顧客中心主義」の重要性

4

6.1 SaaS

19

2.1.3 新しいリスクへの対応

46.2 スタートアップ22

2.2「デジタルプレーヤー」
の先進事例

5

2.3 保険の未来に向けて動くために必要なことは何か

5

6. SaaSとスタートアップ

7. ケーススタディ

19

23

7.1 保険会社のAPIを活用したプラットフォーマーとの接続

2477.2 疎結合な接続によるフロントミドルサービスとの接続

25

3.1 既存保険会社のIT基盤の現状

7

7.3 フロント・ミドルシステム導入によるデジタル完結型の新商品リリースを迅速化

26

3.1.1 保守・維持の投資にリソースが割かれ、新しい投資ができない

7

3.1.2 レガシーシステムの「ブラックボックス化」

7

3.2 なぜDX人材が雇えないのか

8

3.2.1 エンジニアが不足している理由（需要・供給のミスマッチ）

8

3. 現状把握

4. ITインフラの進化の方向性

参考文献

27

10

4.1 基幹システムをどのように変革していくのか

12

4.2 基幹システムとサービスとの連携はどのようになされるのか

13

4.3 ノーコードツールについて

162

1. はじめに本ホワイトペーパーは、
日本を含む保険大国における保険の発展、特にITを中心とした発展の方向性を指し示すロードマップである※。社会が変化する中で、保険の価値は今後10年で大きく変容することが予測される。
その変化に対し、保険事業者が対応するためにはどのような準備を行う必要があるのかを指し示すことが、主たる目的である。

第2章（保険と保険商品の未来）
では、次の10年で保険を取り巻く世界に何が起こると言われているのかを記述した。
これらの多

くはほとんどの識者やリーダーが確実に起こると考えていることである。実際にはこれ以外の変化が発生する可能性もあり、これらの変化がよりスピードアップし別の変化が発生することもあり得る。
そしてこれらの環境変化により、保険商品はどのように変化

第5章（規制環境）
では、これらの今後の変化について必要不可欠となる規制環境について述べる。

第6章（SaaSとスタートアップ）及び第7章（ケーススタディ）
では、
既存保険業界が変化していく際の一つの選択肢であるSaaSやス

タートアップとの協業における考え方と実例を述べる。

していくのか（変化していく必要があるのか）についても述べる。

第3章（現状把握）では、現在の保険会社における特にITを取り巻く体制が、第2章で述べられたような未来の変化に対応できるのかについて考察し、どこに問題があるのかを述べる。

第4章（ITインフラの進化の方向性）
では、第3章で述べられた問

題を今後5~10年のスパンでどのように解決すべきか、どのような選択肢があるのかについて述べる。

※本ペーパー内で、特に国や地域に対する言及がない場合は日本についてのことを述べる

3

2. 保険と保険商品の未来

2.1 外部環境の変化による保険のあり方の変化しており、保険会社がいかに顧客のニーズに応えるため、データを用いた個別化・差別化（パーソナライズ）の実現ができるかが重要にな

2.1.1 少子高齢化と低金利環境の継続ってくる。
また、SNSやEコマース等は利用者同士をつなげて情報共急速な少子高齢化や人口減少により、医療保険制度や年金制度を有する場としての機能を果たすだけではなく、保険料の公平性や透現行のまま維持することが難しくなってきている。医療費の多くまた明性を担保するための「保険リスクの分担・共有の場」にも進化しては全てが公的医療保険でカバーできなくなり、将来的に公的年金給きている。

付の水準の抑制と縮小が予測される。そのような状況において、民間の医療保険会社や年金保険会社が果たす役割はより多様になり

2.1.3 新しいリスクへの対応、医者、病院や薬局等の医療関係者と連携し、より低コストの医療サ

新型コロナ禍による「ニューノーマル」時代の到来は、「デジタル化」

ービスを提供することが求められている。

による変化への適応力とリスクへの対応力の重要性を明らかにした。
また「デジタル化」に加え、先進的なテクノロジーを活用したスマー

2.1.2「顧客中心主義」の重要性

トシティ全般（モビリティ、環境の持続可能性、公共の安全、福祉、ラ

従来の保険商品は、契約内容が一定程度標準化されているため、他

イフスタイルの改善等）への変革をより強化・加速させるものとなっ社へ乗り換える顧客は非常に少ないと考えられてきた。
これは、

た3。
その結果、
「リスク」
そのものの定義や認識も大幅に変化するこ

OECDの統計データにも顕著に表れており、2019年のOECD諸国とが予想され、保険会社が既存リスクと考えるものは重要性を失うの保険契約の継続率は85％であった1。
しかし、昨今のスマートデバ

一方、
これから新しく出現するリスクに対応するための保険ソリュー

イスの普及により、今後の保険の在り方が変わってくることが予想さションが重要になってくる。例えば、モビリティ向上を目的とした自れる。顧客は端末から一元的に情報を入手し、他社商品との比較、動運転により、人間の運転に関連するリスクが低減し、反対に、
ロボ

そして個人のニーズに合った商品を選定することが簡単にできるよットによる運転や自律システムの障害が新たなリスクと捉えらえるよ

うになってくる。J.D.パワーの調査によると、77%程度の自動車保険

うになってくる。

2の顧客が「他社の提供する保険に乗り換えを検討している」と回答

4

2.2「デジタルプレーヤー」の先進事例
各業界においてテクノロジーの導入が加速する中、テクノロジーを進んで方法も個人を対象の一単位とした形がないものから、P2P保険等グルー

活用する「デジタルプレーヤー」と呼ばれる保険会社の台頭により、保険

プ内で保険をシェアする「つながりが見える」
ものへ、と移行していく可能

業界にも劇的な変革が起こっている。例えば、Lemonade Insuranceや性が高い。
また、保険が保障の対象とするであろうリスクの定義も、時代とHippo等の新興保険会社が提供するオンライン保険商品は、柔軟な価格

ともに常に変化している。
そのため、今後の保険サービスは新たな技術を設定と保険契約の管理・請求の自動化を可能にしている。民間医療保険

駆使し、あるいは、既存のビジネスモデル・仕組みを変えることで、これらのOscar Healthでは、ユーザーがオンライン診療を無料で受けられるよのトレンドに合わせて進化し続ける必要がある。
このように、外部環境のうにすることで医療費抑制を図る。
また、Root InsuranceやMetromile

目まぐるしい変化や顧客ニーズに対応する新しい保険サービスが 生まれ

は、利用ベース型（Usage-based Insurance）の自動車保険に特化しててくる中で、既存の保険業界プレイヤー、特に保険会社はどのような対応おり、運転状況、場所、走行距離や時間等のデータに基づいて保険料ををしていく必要があるのだろうか。著者はこの答えはシンプルであると考設定している。
そして、P2P保険はひとつの保険をグループ購入するようえている。 変化の方向性を予測をすることでは決してなく、体制の整備をな仕組みを持ち、同じ保険の加入者同士の保険料を抑え・リスクを分担ししていくことではないだろうか。
つまり、

あうビジネスモデルであるが、日本、ドイツ、米国等で既に実証がされており今後の拡大も期待できる。

2.3 保険の未来に向けて動くために必要なことは何か

ユーザー本位な体験を重視し、保険API等、
デジタル化された社会で必須とされるようなインフラを提供できる環境を整備するリスク
や環境の変化が発生した時、それが予期されたものであろうと無か
ろうと、柔軟かつ迅速に対応できる体制を構築しておく

上述のように、社会経済情勢や新型コロナ禍で加速したデジタル化等の動きにより、保険業界には大きな変化が起こりつつある。保険のあり方は、標準されたものから顧客ニーズに合わせた「パーソナライズ型」
へ、販売
チャネルも従来の代理店の対面販売から「オンライン化」
へ、
そして提供

5

さらに、保険会社には、他のディスラプトされてきつつある業界と比べると金銭的にも時間的にも猶予が残されている。生活基盤に余裕のない人が、他者を助けたり、社会環境を変化させる主導権を握ることは一般的には困難である。SDGsに代表されるような社会的課題は、金銭的、時間的余裕がある者によりリーダーシップが発揮されなければ解決されない。今後10年のスパンでは、保険商品自体が変革され、保険機能の中に社会的課
題が解決されるようなことも実装されていかなければならない。
第3章ではこのような将来に、現状どの程度準備できているのかを考察していく。

6

3. 現状把握第2章で述べたような急速な業界の変化に適応するために、デジタル化に向けたロードマップを策定した保険会社もあるが、変化に追いつけていない保険会社の方が大多数であるのが現状である。多くの保険会社は従来の運用モデルとレガシーシステムから離脱できず、新ビジネスの導入や規模の拡大が遅れたり、急速な市場の変化に追いつくことができないでいる。本章では、現状の保険会社の主な問題点を提起する。
3.1 既存保険会社のIT基盤の現状
3.1.1 保守・維持の投資にリソースが割かれ、新しい投資ができない

3.1.2 レガシーシステムの「ブラックボックス化」

IT予算の多くは既存のレガシーシステムの維持管理に使われている。

既存のレガシーシステムの全容を理解している人材が保険会社のIT部門

例えば年間1000億円の総額予算がある場合、そのうち700〜800億に少ない、もしくは存在しない。
つまり、複雑化した巨大なシステムの全貌

円程度が維持管理に使われており、資金的に新規取り組みができる余や機能が分からない「ブラックボックス化」状態では、一部の仕様や機能

裕がない。
さらに、
システムがレガシー化すると、膨大な開発時間を要を変更することによる影響範囲を把握することが困難である。社内で全容することになり、ある統計によると新製品の開発に18ヶ月かかることもを理解している人材がいないため、結果的にベンダー企業に経験・知見をあるといわれている。

含めて頼らざるを得ないというのが現状である。

また、上記の金銭的なコストに加え、レガシー化したシステムの保守・

レガシーシステムを保守・維持するベンダー企業のビジネスモデルによる維持のためには多くのIT人員確保が必要になる。IT人材が不足する中依存関係も問題である。
ベンダーは人月の工数が膨れ上がることで増収、
レガシーシステムの維持・運用にIT人材が割かれており、根本的なデするビジネスモデルとなることが多く、工数を巡った利益相反が生じるこ

ジタル改革等にシフトできない状況であることから、貴重な「IT人材資とが多い。

源」の浪費につながっていると言われている4。

7

3.2 なぜDX人材が雇えないのか
最先端で柔軟性の高いシステムの開発には、最新の技術と枯れた良い技術の双方をよく理解し、スキルアップを続けている優秀なエンジニア等のIT人材が必須である。

3.2.1 エンジニアが不足している理由（需要・供給のミスマッチ）

ライフスタイルを変革するサービスを、
スピード感を持って企画者と世界中でエンジニア不足が深刻化している。各国の有効求人倍率を一緒に創り、育てていく体制が必要である。一方、一般の保険会社

比べると、日本は約9.17倍5、米国は約7倍6とIT人材が著しく不足しには「自分が作ったもので世の中にインパクトを与える」
ようなイメていることが明らかである。

ージを感じることは残念ながら少ない。金融商品が主力であり、IT

エンジニアの給料は、一般的な職業と比べて高水準（2017年時点での活用はデジタル端末で既存のオペレーションを効率する手段にと平均年収600万円）
であり、2025年には年収1200万円程度まで上どまる。

昇すると推測されている7 。
ユーザー企業が独自でDX化を進める場

また、「スピード感を持って企画者と一緒に創り、育てていく体制」の合は、資金的・人事的な投資が長期的に必要になる。

イメージもない。大企業・金融機関としての重厚なプロセス・セキュ

エンジニアは開発環境がレガシーではなく、最新の技術を使いたがる

リティ規定では世に製品を出すのも時間がかかり、企画・開発・保守傾向にあるが、一般に金融機関のシステムはレガシー化しており、
そと工程を分断したウォーターフォールのイメージが強いの対局にあること。例えば、COBOL言語は最後の構文アップデート
は1985年で止まっており、より良い開発環境との相性はよくない。

保険会社の多くは「守り」に入っており、新たな挑戦や学習の機会が限られている

コラム：保険会社でDX人材の定着率が悪い理由

世の中にインパクトを与えるような新たな変革・差別化を生み出す
ためには、挑戦・学習が必要であり、それを加速させる迅速・柔軟な保険会社は従来のウォーターフォール型のイメージが強いプロセスが重要である。
良い機能の実現や生産性の向上には、新たエンジニアの多くは「自分で作ったモノを世の中に出し、利用者に喜な手法やツールの導入、そのための学習・調査・検証が必要である。

んで使ってもらいたい」と考える。
そのために、
デジタルを基盤として継続的な改善、こまめな作り直し（リファクタリング）も必要である。

8一方、保険会社のような金融機関・大企業では、挑戦や学習の機会

時代に即したスキルアップをしつづけられることが、クリエイティブ

が得られることは少ない。金融機関・大企業のプロセス・セキュリテ

人材にとっての安定である。

ィ規定が変わりづらいのが一因である。工程を分断したウォーター
フォール、
オンプレミス・社内インフラを前提としたプロセス・セキュ
リティ規定に対して、積極的に改善する機会は少ないのではないか。
その結果、アジャイル開発・DevOps・Infrastructure as Codeといった手法や、XaaSや各種ツールなど、
より生産性の高い技術導入が進みづらい。
より効率的な機能、業務プロセスを提案しても、現場の業務を変えることを拒まれる。大企業のプロセス・規定を変えるに
は、組織横断的に工数・リスクをとる必要がある。現場も調査・調整・変えることへの責任に疲弊し、既存のプロセス・規定に対する提案も少なくなる。
その結果、情報子会社・ベンダーに依存し、レガシーを積み重ねてい大手企業では、年功序列・職位の報酬体系が主流であり、
クリエイ
ティブ人材は妥当な報酬が支払われていない
DXの流れは、当然保険業界だけでない。
クリエイティブ人材は、業界を関わらず活躍できるので需要が高い。会社に依存することなく転職率も高いため、定着してもらうための組織の構築、人事・採用の改革も必要になる。
自社の年功序列・職位の報酬体系に縛られず、
エンジニアやデザイナーなどスキルに対して妥当な報酬を支払うのは必至である。
また、創ったものがすぐに売上やコスト減につながることはないので、クリエイティブスキルを称賛し、挑戦や学習を推奨する評価や文化まで落とし込むことが重要である。

るのも課題である。本来クリエイティブで、挑戦や学習、継続的な改善が必要なシステムを、重厚なプロセス・セキュリティ規定に従い、事業の要望・リリーススケジュールありきで対応してもらうためには、人月商売のSIer・受託ビシネスに依存することになる。
人月商売に依存してしまうと、工数を巡った利益相反とレガシーを積み重ねることになり、本質的な改善・改革にはならない。
その結果、産み出される時代遅れなレガシーシステムの保守は、クリエイティ
ブ人材が最も避けたい業務・離職理由の一つである。逆に、長年レガシーシステムに関わっていた人では、DXの変革は難しい。金融業
界は安定というが、挑戦して学習の機会が継続的に得られることで、

9

4. ITインフラの進化の方向性

4.1基幹システムをどのように変革していくのか
第3章の問題点を踏まえた上で、どのように基幹システムを改善・構築していくかは大きく分けて３つの方法がある。
A) 完全リプレースB) リファクタリングC) 外部パッケージA) 完全リプレースとは、既存レガシーシステムを破棄し、自社で別のシステムに全面的に開発・切を行うためには非常に多くのエンジニアリソースやDX人材が必要となる。

り替えることでシステムを刷新することである。一方で、B)リファクタリン

例えば、Goldman Sachsではデジタル商業銀行を新たに立ち上げていグは、既存レガシーシステムをベースに言語体系や構造を修正することでるが、全従業員に占めるDX人材もしくはエンジニア比率は25%にものぼある。C)外部パッケージでは、外部ベンダーが提供する既存システムを新る8。米国の一部の銀行では既に30％がエンジニアであるとの統計もある

たに導入し、既存システムと入れ替えることを指している。
カテゴリA)、B)

9、C)はいずれも既存のレガシーシステムの改善もしくは刷新を指しているにとっては現状極めて困難であると思われる。
また機能要件をゼロベース

が、
カスタマイズの自由度、開発や維持に必要となるDX人材など、メリッで構築するため、must-haveな要件に注力され、イノベーティブな機能がト・デメリットがそれぞれ異なりどの方法が最適か一概には言えない。

後回しにされることはあり得る。

。第3章でも述べたように、
このような人材を揃えることは既存保険会社

例えば、大手保険会社で資金的な余裕がある場合は、A)完全リプレースを志向することが多いと思われ、またそうであるべきだと考えられる。
つまり、
このケースが最も自由にカスタマイズを行うことができ、データ基盤も揃えられ、変化に対応できると考えられるからである。
ただし一方で、
これ10B) リファクタリングは、的ではない。第2章で見たような新しい環境やリスク、
およびそれに対応

既存システムをベースに外部のマイクロサービスと接続できるように「アした保険商品の容姿はまだ見えていないことの方が多いし、マーケットフダプター」を構築したり、同一機能を維持しながら言語・開発体系をアッィットするかどうかもわからない。例えば日本を含む国の大手損害保険会

プデートすることである。既存をベースとするため、開発のリスクは低く抑社においては、完全リプレース（もしくは全面的リファクタリング）には5年えられることができる一方で、その場凌ぎな対応が取られることもあり、スパンでの時間がかかることが通常である。今要件を定義しづらいものに抜本的な解決にならないこともあり得る。

ついて、5年の準備期間を取ることは不可能に近い。

C) 外部パッケージには、明確に区別ができるものではないが、大きく分けて２種類が存在する。
１
つはパッケージソフトウェアの購入であり、もう一つはクラウドベースとしたSaaS（Software as a Service）の利用である。特にSaaSの場合において顕著であるが、利用料は多くの利用保険会社においてシェアされるた
め、導入費用はカスタマイズを伴う費用を加味したとしても廉価になることが多い。財務基盤が弱かったりスピードを重視する場合においては重要な選択肢になると思われる。
ただしパッケージ導入においてカスタマイズを大きくしてしまうとパッケージのメリットが低下してしまう。
これまでの開発のようにシステム要件を業務要件に合わせるのではなく、業務要件を変更してシステム要件に合わせることを検討する必要がある。
なお留意すべきこととして、これらの方法論は保険会社ごとに異なるもの
であるものの、一つの保険会社の中でも異なる手法が導入されるべきものである。
つまり、例えば財務基盤も強く百貨店的な商品ラインナップの保険会社において、全ての基幹システムを完全リプレースすることは現実

11

4.1基幹システムをどのように変革していくのか

12

4.2基幹システムとサービスとの連携はどのようになされるのかでは、上記のいずれかの方法で基幹システムを変革した後、それをどのように活用する、
すなわちフロント（ミドル）のサービスと接続することができるのだろうか。
これには、いくつかの方法が存在し、実は一部のケースでは基幹システムに変革を行わなくても最新のテクノロジーの活用ができる事例が存在する。

フロント
（ミドル）
の
（マイクロサービスとの）接続方法は大きく分けて以下の３つがあり得る。
API接続
アダプター接続（密結合）
疎結合接続
4.2.1 図表：フロント（ミドル）の接続方法（イメージ）

13

API接続とは

理機能は接続先サービスのミドルウェアサービスに委ねられる。
よ基幹システムから参照系や更新系のAPIが出ており、接続先サービって本接続を行う際には、既存業務オペレーションに柔軟性がある

スがそのようなAPIを利用することである。
このような状態において必要性がある。
このような接続は通常、
日次・週次・月次等のバッチは例えばエンドユーザーを多く抱えるプラットフォーマーのアプリ等連携により行われる。
むやみなバッチ処理の積み重ねはシステムトラのサービス上から直接APIを叩くことにより、保険に必要な情報を直ブルを起こしうる。
しかし、もしこの接続の目的が月次決算のための接的に基幹システムにインプットしたり基幹システムから情報を参

データ連携程度であれば、バッチ処理による悪影響の発生確率は極照することができる。
このような状態は上述のA)完全リプレースや、めて限定的と考えられる。なおこの接続方法であれば、前述の基幹

C)パッケージ利用により達成できることが多い

システム変革A~Cのいずれも行われなくても接続ができる可能性がアダプター接続とは、
B)リファクタリングで全面的に手を加えることができなかった際や、もしくは暫定的な措置として取られる接続方法と考えられる。
このよある。個社システム事情・保険商品特性・チャネル特性の全てを検討し、まずはこのような接続により外部サービス連携を行うことは極めて現実的であると思われる。

うなケースでは、契約管理機能は既存基幹システム側に持つことも接続先のフロント（ミドル）
サービスに持つこともいずれもあり得る。
その決定要因としては、既存の業務オペレーションの柔軟性（新しい契約管理機能を特定の商品やチャネルのみに適用可能か）や、どこまでのタイムリーな接続ができるかなどの要因が考えられる。著者の経験では、既存基幹システム側で契約管理を行うことの方が多いのではないかという印象を持っている。
疎結合接続は、
最もライトな接続方法と考えられる。接続というより非同期な情報連携と言った方が正しいかもしれない。本接続においては、契約管

14

4.2.2 図表：基幹システムとサービスとの連携はどのようになされるのか

15

4.3ノーコードツールについて
接続先のフロント（ミドル）
サービスの一例としてノーコード（ローコード）ツールが考えられる。
日本にもそのようなツールは一部海外スタートアップにより紹介されつつあり、例えばUnqork10やProtosure11などのサービスが存在する。
ノーコードツールは、貴重なエンジニア・デザイナー工数を消費せずにユーザー反応を見ることができたり、状況変化に対応できたりすることが可能なため極めて有用なツールである。
ただし万能ではな

く、例えば接続先の販売提携会社が巨大なB2Cプラットフォーマー企業である際などには、極めて繊細なカスタマイズや個別対応が必要となるであろうし、大量のユーザーフローがあればそれに応じた様々な顧客接点が要求されることが多い。著者の考えでは、特に顧客接点のノーコードツ
ールがフィットするのは、中小規模団体などへの接続など多大な個別カス

タマイズが必要とされないケースが多いと思われる。

どのような接続方法を取ったとしても、顧客価値の観点で重要なのはどのようなサービスと接続しそれをいかに顧客に提供するかである。新しいサービスはスタートアップ企業やそのSaaSサービスにより提供されることも多い。第6章では、スタートアップとの協業やSaaS利用の際の注意点について述べる。
また、第7章では具体的な国内外の事例紹介を行う。

16

5. 規制環境

5.1データセキュリティ対策
SaaSを含むクラウドサービス活用が進んでいる中で、金融機関の個人情報保護やサイバーセキュリティ対策は日々進化するべきであり、ある一時点でのルールや慣習にとらわれるべきではない。金融機関は常に合理的かつ妥当な方法をとれるようにしておく必要がある。規制当局も、そのような金融機関の動きを後押しするような規制やガイドラインを制定すべきである。
IT業界は変化が速いため、過去に正しいとされたもしくはベストプラクティスとされたものが現在もそうであるとは限らない。例えば、パスワード管理において定期的にパスワードを変更することは、以前はベストプラクティスであると信じられてきたが現在では明確に否定されている12。
2015年6月に日本の金融情報システムセンター（FISC）
が発表した「金融機関等コンピュータシステムの安全対策基準・解説書（第 8 版追補改訂）」
では、
クラウド利用とサイバー攻撃対応に関する安全対策の基準が設けられた。
その後、リスクに応じた安全対策基準といった改訂が行われた。海外では、欧州連合（EU） が一般データ保護規則（GDPR）
を施行しており、
中国、
インドネシア、
ベトナムといった国でも、SaaSプロバイダーに国内のデータ常駐要件を満たすことを要求している。
なお、一般にセキュリティレベルを高めるとユーザービリティが低下することが多い。
このトレードオフを理解しつつ、適切なセキュリティ対策を講じることがビ
ジネス上重要と考えられる。

17

5.2 各国における新商品・サービス開発の状況
日本、香港、
シンガポール等のアジア諸国では、新たな技術活用による金韓国においても、
日本の少額短期保険業制度を参考にした形で、2021年

融商品・サービス実証を行うための規制のサンドボックス制度が活用さ

6月より少額短期保険制度が導入されている。最低資本金は10億ウォンれている。
また、台湾でも規制緩和の推進により、多くの保険商品とサー（約1億円）、保険料収入上限は500億ウォン（約50億円）と、
日本の制度

ビスをオンライン上で提供可能になってきていると類似する点が大きい。
ただし著者の理解では、日本のように生損保兼営

例えば香港においては、規制のサンドボックス制度として、新たにデジタはできないようである。

ルを活用した保険会社を迅速に創業することを助けるためのファストトラ

多くの国の保険業法において生損保兼営は禁止されている。
これはック制度があり、2018年12月にInsurtech StartupであるBowtie社に

著者は時代遅れであると考えている。
リスクや慣習、そしてシステム初めての保険（生保）ライセンスを付与している。
ファストトラックであるこの違いはあるものの、ユーザーにとっては「保険」
であり、今後保険業との制限として、販売チャネルはデジタルに限定されている。
また、同時期の定義が変化するに際して、生損保の垣根は無くなってくるものと予にAviva lifeをリブランディングする形でTencentがDigital ﬁrstの保険想している。

会社であるBlue社を開業させている。
日本においては、少額短期保険業によりデジタルかつサンドボックス的な商品開発が可能となってきており、事業会社や保険会社の設立が大きく増えてきている。著者の見立てでは、
日本の規制当局も少額短期保険業
をこのような実験的な位置付けとしているように考えられる。一方で、実験的な位置付けであることが金融機関としてガバナンスを疎かにしてもよいことを意味するものではないことには留意が必要である。

18

6. SaaSとスタートアップ

6.1 SaaS
第4章で述べた通り、SaaSは、
これまでパッケージ製品として提供されてきたソフトウェアを、サービスとしてインターネット経由で提供・利用する形態のことを指している。SaaS市場は現在急速に拡大しており、2020年のグローバルのクラウド市場規模のうち、SaaSは約11兆2400億円（全体の約38%）を占めている1 3 。また、SaaS市場全体は、2020年から2022年の間で17％の年平均成長率が予測されている13。
保険業界においても、同様にSaaSの使用が増えてきている。2020年に米国に上場した損害保険ソフトウェアプロバイダーである Duck Creek
Technologies においては、
サブスクリプション収益が2020年度において前年比で50％増加し、収益全体の40％を占めた14。Guidewire Softwareについても同様に、収益を占める割合として、2019年度の21％から2021年度の34％に増加した15。
また後者の場合は、現在既存のオンプレ
ミスの顧客をクラウドに移行している段階であり、今後の保険業界におけるSaaS利用が期待できる。

19

20

従来の社内システム構築・開発と比べると、SaaSは導入費用を抑えられ、導入期間の短縮やインフラ等の運用と管理負担を軽減できるほか、
ビジネス環境の変化に対応する柔軟性を持ち合わせている等の特徴があり、ユーザー企業は導入することで社内リソースを新規事業開発や事業拡大等に割けるというメリットがある。導入後も、利用料を払い続けている限り共通コア部分がアップデートされるため、時代に取り残されレガシー化しにくいという特徴がある。
また、
リソー
スが限られている小規模な保険会社にとっては、
インフラや規制要件を満たすための実装コストが軽減されるため、SaaSの導入は向いていると考える。
また大手保険会社でも、チャネルや保険商品によって部分的にSaaSを利用することは十分に考えられる。
保険会社の保険バリューチェーン（販売・保全・保険金請求）の中で導入するようなSaaSの特徴としては、以下が挙げられる。

共通コア部分によるコスト削減効果深い業務要件理解の必要性

保険バリューチェーンには共通した機能が多く存在し、これがコア

SaaSの提供業者が、複雑な業務要件や保険商品の特性を理解して部分として他のユーザー保険会社とコストシェアがなされる。
またこ

いることは最大の必要条件である。
また、
せっかく良いものが提供での部分の存在があるためレガシー化しにくいとも言うことができる

きても、それがエンドユーザーに受け入れられなければ意味がないと考えられ、
デジタル販売に関するコンサルティングなどのサービス

カスタマイズ部分の存在

がSaaS提供業者から提供されることも多く、SaaS利用料は保険料

一方で保険商品の複雑性や各社の業務要件の差異などは共通コア

比例の従量課金部分が存在することも多い。

部分のみでは吸収できないことも多く、
カスタマイズが必要となることも多い。
カスタマイズはSaaS提供業者により行われることもあれ
ば、別の業者が行うこともあり得る。
いずれにせよ、既存業務要件に固執するあまりカスタマイズが増えることは、SaaSの良さを損なうため避けるべきである。

21

6.2 スタートアップ
SaaSはスタートアップ企業が提供することが多い。
「作ったら作りっぱなし」とはならず、SaaS利用料を課金され続けるために常に改善されるものである。
このようなサービス提供方針は、多くのスタートアップ企業で採用されるようなアジャイルな開発体制と非常に相性がよい。結果として、保険会社が自社で行うよりも圧倒的に速いスピードと最終的な質を達成することができる。
しかしながら、保険会社の経営者や実務担当者として、財務基盤や実績が安定していないスタートアップ企業と協業することはリスクが非常に高いと考えるのが通常である。
リスクが高いから通常よりも慎重なデューデ
リジェンスを行う、ということでは多くの場合プロジェクトは円滑に進まない。
当該プロジェクトが失敗したケースを想定したり、最悪なケースと成功するケースを天秤にかけたり、また協業の領域を明確に定義しつつプ
ロジェクトを進行させることが必要である。
そのためには保険会社の経営陣の力強いコミットメントが必要であることは言うまでもない。
他方、保険業界でSaaSを展開するスタートアップとしても、保険領域は保険種目やトランザクション種類の多さにより金融領域の中でも複雑性が高い領域であることから、業界風習や実務、既存のIT基盤に至るまでの深い知識と経験が必要になることを理解する必要がある。

22

7. ケーススタディ
本章では、一つの選択肢であるSaaSやスタートアップとの協業における3つの実例を述べる。

23

7.1 保険会社のAPIを活用したプラットフォーマーとの接続
東京海上日動火災保険は、 justInCaseTechが提供する「joinsure 保険募集システム」
により、ロイヤリティーマーケティングや関西電力といった協業プ
ラットフォーマーの顧客に対して、保険商品をオンラインで優れたUXで販売することが可能となった
保険会社の基幹システムとフロントサービスとはAPIで接続され、迅速にUXの改善を可能にする体制が構築される

24

7.2 疎結合接続によるフロント（ミドル）サービスとの接続
joinsureの募集・契約管理・保険金請求システムを導入し、デジタル完結のEコマース保険を提供
商流に合致した保険を優れたUXで提供することで高い成約率を達成
保険会社の基幹システムと疎結合で接続することにより、UXを犠牲にせずかつ低コストでの実装を実現

25

7.3 フロント・ミドルシステム導入によるデジタル完結型の新商品リリースを迅速化
台湾のFirst Insuranceは、OneDegreeの提供するIXTパッケージを導入することで、新商品のリリースにかかる時間が1年からたったの21日へと大幅短縮された保険会社の既存システムとアダプターにより接続されているIXTからはAPIを活用することも可能。
プラットフォーマーやエコシステムとの接続も容易に可能となり、新規ビジネスを逃さない

26

参考文献

1. OECD. Insurance Indicator: retention ratio
https://stats.oecd.org/index.aspx?queryid=25441
2. J.D. Power. (2020, April 30). Direct-to-Consumer auto insurers take top honors in Shopping study as New Normal arrives for P&C
Industry, J.D Power Finds [Press Release],https://www.jdpower.com/business/press-releases/2020-us-insurance-shopping-study
3. SMA Research. (2017, August).Smart Cities and insurance: Exploring the implication
https://cdn2.hubspot.net/hubfs/732222/SMA-RR-2017-Smart-Cities-and-Insurance-082917-V115-Synerscope.pdf?t=1505751589866
4. 一般社団法人 情報サービス産業協会（2018)「JISA-DI調査」情報サービス業雇用DI（H27年度以降）
5. Doda転職サイト（2021）転職求人倍率レポート
https://doda.jp/guide/kyujin̲bairitsu/
6. CNBC. (2021, June 10). Facing shortage of high skilled workers, employers are seeking more immigrant talent, study ﬁnds
https://www.cnbc.com/2021/06/10/study-employers-seek-immigrants-amid-shortage-of-high-skilled-workers.html
7. 経済産業省（2018）「 DXレポート〜ITシステム「2025年の崖」の克服とDXの本格的な展開〜」
https://www.meti.go.jp/press/2018/09/20180907010/20180907010-1.pdf
8. CNBC. (2018, April 30).Computer engineers now make up a quarter of goldman sachs workforce
https://www.cnbc.com/2018/04/30/computer-engineers-now-make-up-a-quarter-of-goldman-sachs-workforce.html
9. 金融庁総務企画局（2017）第38回金融審議会総会・第26回金融分科会合同会合「フィンテックや決済高度化を巡る動向と今後の課題」
https://www.fsa.go.jp/singi/singi̲kinyu/soukai/siryou/20170303.html

27

10. Unqork Website
https://www.unqork.com/
11. Protosure Website
https://protosure.io/
12. 総務省「国民のための情報セキュリティサイト」
https://www.soumu.go.jp/main̲sosiki/joho̲tsusin/security/business/staﬀ/01.html
13. Gartner. (2020, November 17). Gartner Forecasts Worldwide Public Cloud End-User Spending to Grow 18% in 2021. [Press
Release]https://www.gartner.com/en/newsroom/press-releases/2020-11-17-gartner-forecasts-worldwide-public-cloud-end-user-spending-to-grow-18percent-in-2021
14. Duck Creek Technologies Quarterly and annual ﬁnancial results
15. Guidewire Software Quarterly and annual ﬁnancial results

28

Contact
info@justincase.jp

2021/09