Q1. 貴社がこれまで取り組まれてきたIT戦略推進の背景・経緯について、
特に「商品管理」や「ITアーキテクチャ」に関する考え方や課題意識をお聞かせください。
藤巻幸和様
商品の販売サイクルを早めることで会社としての競争力向上を目指しています。
商品開発は生命保険会社としては収益に影響しますので、毎年度計画を決めて、それに沿って開発されており、途切れるということはありません。そのため、毎年立てられた計画に基づいた市場調査を行っています。
佐藤風也様
基本的には、既存システムを大きく変えずに開発する方針になっています。
新規システム構築時にはオンプレなのか、クラウドなのかを評価しながら行っています。
クラウドの方がスピード感をもって構築出来ますので、そちらの方が優先される傾向はあります。
基本的には、既存システムを大きく変えずに開発する方針になっています。
新規システム構築時にはオンプレなのか、クラウドなのかを評価しながら行っています。
クラウドの方がスピード感をもって構築出来ますので、そちらの方が優先される傾向はあります。
江部庸介様
Q2. そのような背景の中で、弊社の製品をご採用いただいた理由についてお聞かせください。
導入に際して重視されたポイント（例：柔軟なアーキテクチャ、内製化支援など）を中心にお話しいただけますでしょうか。
他社ではルールエンジンのロジックを業務側がメンテナンスすることもありますので、それも考慮して選定したところInnoRulesがあっていると判断しました。
特に決め手となったのはメンテナンスのしやすさではありましたが、それ以外では他社の生命保険会社での実績があったこと、経験者の支援が受けられそうだったことによる安心感も決め手となりました。また、PaaS形態での提供やAWSでも構築可能という柔軟なアーキテクチャであったことも決め手になりました。近い業界での知見があるというのは大きいと考えています。
佐藤風也様
江部庸介様
現行システムでの給付査定のロジックが膨大であり、当初自動査定を検討するにあたり現行システムにこれ以上の判断ロジックを入れることは得策ではないと考えていました。その中で、どういうシステム構成をとると業務要件が満たせるかを考えたときに、ルールエンジンで実装する案が出ました。
佐藤さんがコメントしてくれているように、PaaSでの構築が可能であること、また、コスト面などからInnoRulesを選定しました。
Q3. 弊社の製品を活用したシステムについて、以下のような観点で紹介いただけますでしょうか。
① 導入前に抱えていた課題
近年は会社の成長に伴う保有契約の増加もあり、担当部門の業務量が増大していました。一方で、査定者を育成し、自立できるまでにするには大体2、3年はかかります。
そうした中で、自動化率を上げることが今後の目標です。「自動化率を上げること」は、人で担う部分とシステムで担う部分のどこで線引きすることになりますので、何がベストなのか今も悩み続けながら対応しています。
1つの線引きとしては、「ルールに判定させるデータがあるか」、「データは整備されたものか」があると思います。査定における一定の基準はもちろんありますが、「特定の情報をかけ合わせればいくつかの結果が出る」という単純な話ではなく、その結果の中でどう最終判断するかは、査定者自身の経験や思考が影響してきます。そのため、査定者の思考をルール化することよりは、査定者の思考が必要かどうかを判定するという使い方をしています。
他社と同様、当社も新契約における申し込みの自動化や途中の契約保全の自動化も行っていますが、保険金の支払領域は最後になりました。それはお客様から入手した情報・データの範囲が定まっておらず、ルール化が難しかったためです。これは当社に限らず他社でも同じだと思いますが、この発展途上の部分にチャレンジする価値はあったと感じています。
② 導入による効果や改善点
InnoRulesを使用して、この案件は「自動か人が対応するかを仕分ける」という仕組みにしました。
ただ、要件定義の段階では自動化対象をしても問題ないと考えていても、本当に自動化の対象としていいものだったのかは、実際に査定された請求情報を見ないとわかりません。そのため、いきなり自動化してしまうのではなく、リリース後から一定期間は、自動化対象としても問題ないものであるかを査定者が最終検証を行い、チューニングをしています。
当社の自動化率の目標は20％ですが、現時点では12-3％程度です。とはいえ、他社では一桁台が普通だと聞いていますので、順調なスタートを踏めたと考えています。線引きの難しさはやはりありますが、今後、お客様のためにもできるだけ早い段階で目標に届くようにしたいですね。
③ 業務やシステム面での工夫やユニークな取り組み
定型的なデータを使用して一貫した判断は基本的にInnoRules任せですが、かといって、一部の非定型的なデータにより自動化できないというのはもったいないと考えています。そのため、特定の部分だけが非定型データにより自動化対象外だったのであれば、その部分だけを査定者がチェックし、補正した上でInnoRulesに再度データを戻すように工夫しています。そうすればInnoRulesがあらためて自動で判断をしてくれるようになります。
藤巻幸和様
Q4. 今後の貴社のIT戦略について、方向性や重点的なテーマ、特に「業務の高度化」や「内製化推進」などの観点から、アピールポイントがあればご共有ください。
商品を出せるまでのスピード感をITに求められています。ただ、これは商品に限ったことではなく、業務での改修案件に対しても、スピード感が必要です。
当社には数十以上のシステムがあり、商品開発したいときには、商品の特性にもよりますが数多くのシステムに手を入れなくてはなりません。今後、内部の判定ロジックなどはできるだけまとめられるものはまとめていきたいと考えており、InnoRulesはその一端を担えるようになると考えています。
このようなシステム開発の効率化により会社全体の競争力アップを目指しています。
新しい商品だけ対応すればいいというのではなく、実際にはすでに契約されているものがありますので、保有契約すべての商品に対応する必要があります。
もちろん、契約がすべて終了した商品であればシステムから除外することが可能になりますが、生命保険は長期契約でもあり、どうしてもこれまで販売した商品・契約が積みあがっていくため、保守性も重要なテーマです。
江部庸介様
藤巻幸和様
Q5. 今回のシステム導入プロジェクト全体を振り返って、印象的なエピソードや、苦労された点、やりがいを感じた場面などをご共有いただけますか？
Q6. 弊社製品に関して、今後期待する機能や改善点、または連携の可能性などがございましたらぜひお聞かせください。
商品開発は常に動いています。それ以外のところでも並行でいくつかの自動化率を上げるための施策が動いている状態で、全ての開発がひとつの開発環境で進められています。そうした中で、InnoRulesの仕様で本番環境に開発中のバージョンもリリースされてしまうことがあります。
実害がない仕組みになっているのはわかっていますが、場合によっては品質が担保できていないものが動いてしまうリスクがありますので、多少の不安があります。リリースするバージョンを上手くコントロールできるようになれば、より安心して使えるようになるかと思います。
また、本番リリース後の切り戻しも改善の余地があると考えています。切り戻しを行う場合、開発環境で一度不備があったバージョンを削除し、開発環境からリリースし直さなければなりません。不備があったルールは切り戻し後に再実装する必要があります。万が一の場合に複雑な手順を踏むのは更なる作業ミスのリスクがあるため、より簡易になるといいなと考えています。
PaaSに関しては基盤の管理が不要になり、当社側の運用負荷が軽減できています。当社側で基盤構築した場合、運用にあたり製品特性の理解が必要になりますが、製品を理解されているイノルールズ社で管理されているので安心して利用できています。
コスト面で見れば、ライセンス費に加えて運用費が必要になりますが、当社が人員をアサインするよりコストを抑えられていると考えています。
佐藤風也様
Q7.どういった企業にイノルールズ社の製品をおすすめしますか。
佐藤風也様
イノルールズ社の製品は、判断基準が明確な業務であれば比較的簡易にルール化できますので、導入効果が出やすいと思います。
定期的にルールが変わるようなものに関してもルール上のパラメータ変更だけで済みますので、毎回プログラムを修正する手間と比べ、メリットが大きいのではと思います。
藤巻幸和様
何か問題が出てきたときには仕様書を確認することになりますが、ルール構築時の仕様書は判定条件が明確に記載されることなり、そこを読むだけで完結できるような内容になっています。
ユーザーにとってもわかりやすく、IT側には「仕様書のこの部分を直してください」と伝えれば、齟齬が出にくいという部分はメリットだと思います。
江部庸介様
業務要件がしっかり書ければかなり使えるものだと思います。コストや導入までのスピード感を含めて考えると、初期導入時は大変だとは思いますが、保守していく観点で見ればメリットを感じます。
逆に業務要件がかけず、ルールに落とせない部分があるのであれば、難しいと思います。まずは社内での仕様を見直しながら、小さく使うところから始め、徐々に広げていくのが良いのかなと思います。
佐藤風也様
査定者による支払査定の場合、既存システムのロジックから出力される結果をもとに査定者が支払可否を判断し、査定を進める流れになっています。査定者側からするとシステムのロジックは関係なく、システムの出力結果を「そういうものだ」と捉え査定業務を進めていますが、InnoRulesのロジックを組むためには「なぜその結果になるのか」がポイントになります。ロジックを組むための情報を業務側から見るとブラックボックスになっていたため、新しくロジックを組み立てる必要がありましたが、この組み立て直す部分に非常に難航しました。
実際、要件定義だけで1年ほどかかりましたね。このプロジェクトでは関係者が多く拠点も分かれていたため、チャットやオンライン会議、ドキュメントベースでのやり取りでは認識のすり合わせに時間がかかると判断し、毎週半日ほど使用して、業務側・IT側計20名ほどで実際に集まって内容を詰めていくという取り組みを約半年実施していました。
今回のInnoRules導入に関しては、業務要件の内容（お客様からの書類・申出内容、契約内容、これまでの支払履歴など広範囲なデータを基に支払可否を判断するロジック）に対するIT側の解釈が違うということや、IT内でも認識合わせが必要な部分はありましたので、膝を突き合わせてやった価値はかなりあったと思います。ここで大きなずれがなかったからこそ、後の工程で大きな手戻りが起きなかったのだと感じています。
自動査定のロジックは業務側の観点で勝手にいじってしまうと影響確認が不十分になる可能性がありますので、業務側に任せず、IT側で直していくことになるとは思います。
ただ今後、他の業務でもこのルールエンジンを使う場合、状況によっては業務側でルールを直すことも可能になると考えています。
当社の給付査定と支払処理はレガシーシステム上で稼働しており、さらにイメージワークフローの別システムを組み合わせることで給付全体の事務を行っています。イメージワークフローは、お客様からいただいた請求書や診断書などの書類をスキャナでイメージ化し、受付から査定までの業務をタスクとして流す仕組みで、この過程の中でも様々なチェックが行われています。また、レガシーシステム内にも多様なチェックが実装されています。
InnoRulesを導入するにあたり、どのシステムがどのようなチェック結果を返しているのかを正確に整理しながらルールを設計する必要があり、このプロセスは大変苦労した部分です。
江部庸介様
Q8. 貴社におけるBRMSと連携したAIの活用について、現在の考え方や今後の活用方針などをご教示いただけますか？
（可能であれば、実際の活用例や期待している技術領域についてもお伺いできればと思います）
佐藤風也様
以前は「AIが発展するとルールエンジンが不要になるのでは」と考えていましたが、今は不要にはならないと感じています。というのも、AIが作ったプログラムは人が解釈しにくいため、実装内容の確認が難しくなります。もちろんテストで品質は担保しますが、人が実装を見て仕様を理解できないという部分は大きな差です。
また、少し直す程度であれば人がルールエンジンを改修する方がプログラム改修より速いというのもあります。やりたいことに合わせ、適材適所でAIに任せる部分と人がやる部分を分け、その中でルールエンジンを活用していくことになると考えています。
AIとInnoRulesがコラボすること自体は、使えるものなのであればニーズとしてはあるかとは思います。ただ、コーディングにAIを使用するというのは、現状はまだ使用していません。というのも、当社が正確性を何よりも大切としている業態のためです。
とはいえ、人が時間をかけて対応している部分をAIがまかない、そのあとの工程を人が確認するというような、役割を少しずつ変えていくこと自体は大切だと思いますので、今後の活用としては必要なことであるという見解です。
ユーザーとしてはAIがとって代わることは今のところなさそうだとは考えています。
保険金支払いという業務は、支払われた金額の理由が説明できないといけません。誤った金額で支払ってしまった場合、その原因がルールにあったのであれば直せばいいのですが、AIに任せてしまった場合は、なぜAIがその金額にしたのかという理由を明確にすることが難しくなります。
保険金支払いに限らず、お客様に対して正しいご案内をすることは必須のため、人からAIに取って代わるということ自体はないと思いますが、ひとつのパーツとして、InnoRulesの仕組みをAI機能が補完するということはあってもいいと思います。
江部庸介様
藤巻幸和様