1. Homepage
  2. -
  3. インサイト
  4. -
  5. Guidewire Cloudへの移行へ向けた効果的なアプローチ
Guidewire Cloudへの移行へ向けた効果的なアプローチ
2月 08, 2024 クラウド, 基幹システム導入 , 記事 , DX, Guidewire導入, クラウド

※本記事はソラーズコンサルティング、LinkedIn公式アカウントに掲載の月次ニュースレター「Sollers Insights」を翻訳、転載したものです。

Guidewire Cloudアップデートの影響

 2023年12月、Guidewire社はクラウド型保険基幹システムの最新版をリリースしました。これは2023年における3回目のアップデートとなり、スキーリゾートの名前にちなんで「Innsbruck」と名付けられています。本稿では、こうしたソリューションのアップデートにユーザー側はどのように対処すればよいか、いくつかの方法を提示したいと思います。

Guidewire Cloudのアップデートは、最新の機能を追加することでユーザー企業に多くの価値を提供することを目的としています。最新版(2024年3月現在)「Innsbruck」では、引受査定ルールや保険契約管理、保険料収納のためのAPIが強化され、料率算定や保険金支払などの分野でより多くの分析機能が利用できるようになりました。以前のバージョンでは、データ管理やデータ可視化(2023年夏「Hakuba」)、保険契約管理と保険金支払のためのAPI(2023年春「Garmisch」)など、さまざまな改良が加えられています。

リリースのロードマップには柔軟な対応を

Guidewireのユーザー企業は通常、定期的なシステムアップグレードを推奨されています。実際に、ユーザー側での更新頻度が高ければ高いほど都度の更新のリスクは低減します。とは言え、より広い視野で業務全体の効率性を考慮しなければなりません。Guidewire社が提供する3つの製品リリース・ロードマップに備えるのが理想的ではありますが、それに執着する必要はありません。

更新版リリースのたびにアップデートを行えば、その分の業務負担が発生します。保険DXがもたらす多くのチャンスと変化を鑑み、常にコストvsメリットのバランスを考慮しつつ、アップデートに着手するのが賢明です。では、どのような条件下でアップデートが効果的なのでしょうか。

主に3つのポイントにまとめることができます:

  1. すでに2バージョン以上未更新の場合。既存機能の修正と改善を行う必要性がある。
  2. 自社のビジネスケースに有効な特定の新機能が新たに搭載されている場合。
    例)「Innsbruck」ではこれまで注目されていた「Claims Autopilot」がリリースされました。
  3. 自社内のリソースが十分に備わっている場合。

他の多くのソリューションの実装時と同様、アップデートの実行前には慎重な検討が必要です。アップデートの担当部門により、更新版の比較や機能検証を行うことが必須です。もし社内のリソースが整っている状態であれば、アップデートの実務経験・技術を積む良い機会として投資する時かもしれません。

更新版で有効な新機能の活用法 

これら3つの要件を全て満たさない場合は、アップデートを次の更新版まで待つ方が良いと思われます。Guidewire Cloud Platformは、保険DXを容易に実現できるように設計されているため、最大限活用しましょう。アップデートにはフルセットの環境は不要で、本番環境のダウンタイムは、アップグレード中よりも大幅に短縮されます。また、外部システムの開発変更も不要です。ただし、アップグレードが原因で社内で進んでいる他のプロジェクト進行の遅延を招くなどの影響が想定される場合には、無理に実行する必要はありません。

アップデートのタイミングは重要な要素の1つです。更新版のリリース後は早期にアップデートすることが最も望ましいと言えます。ただし、またその次のバージョンリリースが1~2カ月後に控えている場合は注意が必要です。更新版のリリース直前やその直後にアップデートが完了するような状況は避けたほうが賢明です。

各更新版はユニークな新機能を提供しており、ユーザー側の保険会社が過去にカスタマイズの一環として構築した機能が、新リリースに搭載されている場合もあります。まずはそうした機能を検証し、既存のソリューションとの比較を試みると良いでしょう。そして更新版の機能の成熟度に納得し、自社で必要な機能が全てもしくはそれ以上に備わっていると確信した上で、アップデート実行の是非を決定することを強くお勧めします。 OOTB(標準機能)から離れカスタマイズを選択する際は、その分メンテナンスや将来のアップデートが複雑になることを念頭に置いておく必要があります。

環境次第では自社によるアップデートも可能

アップデートに伴う作業の複雑性や労力と時間は、対象となるシステムの状態により大きく異なります。
特に、次のような要素が影響を与えます。

  • Out-of-the-Box(OOTB)=標準機能の活用度
  • カスタマイズの程度
  • 現行バージョンと最新バージョンとのギャップ
  • 現行バージョンの安定性の度合い
  • 既に実行されている自動化の程度

当社が推奨するのは、ユーザー側にとって困難で手間のかかる部分はソリューションプロバイダーであるGuidewireに任せることです。Guidewire側で新しいリリースを本番コードにマージし、テスト用の環境を準備することが可能だからです。もしチームに十分な能力があり、必要な準備を整えるだけの十分なキャパシティがあれば、自社でアップデートを行うことも良いでしょう。適切にプロセスを遂行できれば、次のアップデート時には時間も手間も省けるはずです。

ここでいう適切にとは、将来に再利用可能な、各チームの責任分掌も含めたアップデート手順やプロセスの内訳を作成することを含みます。また、自動化された回帰テストパックの用意や、テストカバレッジマトリックスとテストケースを、実行計画とテストデータも併せて更新しておく必要があります。

photo of article author

北米事業統括マネージャー
Tomasz Turowski(トマシュ・トゥロフスキー)