このシリーズの記事一覧:
国内の損害保険会社は、自然災害の多発・激甚化や国内市場の成熟化等の事業環境の変化に対応するため、デジタルトランスフォーメーション（DX）や海外市場の開拓等の取り組みを各社進めている。
顧客ニーズの変化や新たなリスクの発現に即した商品・サービスの提供を踏まえて、これからビジネスモデルの変革と創造を進めていく必要がある。
本稿ではビジネスモデルの変革に迅速に対応するために、システム開発態勢の観点からシステム基盤、アジャイル開発、デジタル人材育成について考察したい。
損保業界を取り巻く環境の変化
顧客体験の価値を訴求していった結果、従来の保険商品の提供だけでなく、ワンストップで金融サービスを提供する保険会社や代理店も現れてきている。欧州大手保険グループのAllianzは、資産管理・資産運用・年金といった個々の金融ニーズに特化したサービスで顧客にリーチし、サービス利用の中でアドバイザーとして保険商品を提案する形を取っている。
また、Web3.0等のテクノロジーが保険にも進展してきており、米国損保会社のLemonadeでは、ブロックチェーンを活用して、アフリカの小規模農家向けに洪水・干ばつをイベントとしたパラメトリック保険の提供を一部で開始している。
このようなビジネスモデルの変革や最新テクノロジーの活用に向けて、機会を損なわずいち早く対応していくために、システム開発態勢としてどのように構えておくべきか考えていきたい。
目指すべきシステム基盤の考え方
ビジネスモデルの変革に適応していくためには、単なる既存ビジネスの効率化ではなく、継続的な変更を加え競争力を維持することを重視したシステム基盤を目指すべきである。
そのために、ビジネス将来像から求められるシステム基盤要件、最新のテクノロジー動向、足元のシステム課題を踏まえて、エンタープライズアーキテクチャ（EA）を策定する必要がある。ここでは改革テーマの例として2つ述べたい。
契約中心から顧客中心へのデータモデルの見直し
前述のとおり、ワンストップで金融サービスを提供する場合、必ずしも保険契約があるわけではない。保険契約がない段階から”顧客”として認識し、保険サービス・保険以外のサービスを横断的かつ顧客中心に統合することで、さらなる顧客理解を進め、顧客体験の改善、サービス品質の向上を実現する (図表1)。
既存システムのスリム化
足元のシステム課題としては、商品改定のようなサイクリックな開発案件に対して、関連するシステム数やOS・ブラウザのバリエーション起因の無影響確認の負荷が高いことが多いため、低頻度のシステムやロジックの廃止に加え、開発運用の効率化・高速化を実現する。
EAを策定していくなかで、いくつもの改革テーマが出てくるが、システム開発の方向性や優先度付けで迷う場合は、EAで何を実現したいのか、常にゴールに立ち戻ることが重要である。
アジャイル開発態勢の確立
各社DXを推進しているが、投資も多額にわたり、高いROI創出が求められる。取組みのリターンは如何にユーザーをエンゲージし浸透率を高められるかに依存する。すなわち、システム開発の在り方においても、如何にインベストメントを最小化しつつリターンを高められるかを主眼としたアジャイル開発の手法が必須となる。
ここではアジャイル開発態勢の確立に向けた要諦について述べたい。
1. 自社のカルチャーを踏まえたアジャイル戦略・ガバナンスの確立
いざ取り組みを始めたものの、ビジネス部門とIT部門間の利害が一致せず、合意形成に時間がかかりアジャイルのメリットを活かせていないことはないだろうか。また、案件特性の見極めやアジャイル開発のメリット・デメリットを理解せずに、現場の判断でアジャイル開発を選択し、想定した投資効果が得られないケースも耳にする。
スムーズなアジャイル開発の推進には、経営層による取り組みの目的・意義の継続的な発信とコミットメントに加えて、ビジネス・IT一体型の体制組成、関係者間での目線合わせが重要である。
2. ビジネス・ITの垣根を超えた“顧客が主語”のアジャイル組織体制
プロジェクトの開始前にメンバーの役割を定義するが、アジャイル開発が進んでいくなかで、従来のウォーターフォール開発から脱却できずに、ビジネス部門とIT部門が縦割りになるケースが多い。アジャイルCoE（Center of Excellence）を設置し、スクラムチームに伴走しながら是正する必要があるが、アジャイルCoEの位置づけがトレーニングなどの一時的な支援に陥りがちである。
アジャイルCoEには、プロジェクト推進やチーム育成を担う有識者を配置し、推進上の問題が発生した際には、スクラムチームと一緒に考え解決まで導くことが必要である。
3. 周辺システムとの協業を加味したエンタープライズアジャイルのプロセス・手法の構築
プロジェクト特性に応じて、アジャイル開発とウォーターフォール開発が並走するエンタープライズアジャイルを選択するケースもあるだろう。本番リリースに伴う承認プロセスや、必要なドキュメント等の見直しを行い、アジャイル開発とウォーターフォール開発側双方の認識を合わせなければ、従来の重厚な承認プロセス・ドキュメント作成が必要となり、スクラムチームにかかる負荷が大きくなる。
アジャイル開発の「迅速さ」「柔軟さ」を損なわないように、予算確保の考え方や各種承認プロセスを自社のルールを踏まえ策定し、継続的なプロセスの磨き上げを行うことが重要である。
4. 取組みやすいツール・基盤整備
テストやデプロイ自動化環境の構築を劣後した結果、リリース機能やチームの拡大に伴い生産性が大幅に劣化してしまう。さらに、生産性だけでなく、スプリントのたびにデグレードが多発し、品質低下のリスクが増大する。
アジャイル開発のハイスピードのリリースを実現するためには、柔軟性・迅速性を可能とする、一連のDevOpsパイプライン整備が必須となる。
5. コーチング＋実案件で取り組みながら学ぶ人材育成
スクラムチームのマインドセット、スキル不足により、アジャイル開発が頓挫してしまった経験はないだろうか。アジャイルワークを支える人材の育成においては、マインドセットやスタンスの変革がきわめて重要である。
そのためには、アジャイル有識者が開発者に伴走しながら、個々の課題に向き合い継続的に改善を進めることで、一人ひとりの意識改革や組織文化の醸成を促していくことが成功事例から見て効果的である。
アジャイルカルチャーをもつイノベーション企業の実現とDXの高いリターンを実現するためには、実案件を通じてアジャイル態勢を構築していくことが求められる。座学トレーニングだけでなく、見て・聞いて・学ぶという多方面からの知識習得を行い、スクラムを立ち上げつつ、有識者が伴走することで初期スクラムの安定稼働を目指すことが望ましい。
また、アジャイル開発をスケールさせていくタイミングにおいては、小さく始めて大きく育て、安定してスケールさせる工夫がポイントとなる。
IT子会社のデジタル人材育成
テクノロジーが多様化し、NFT、AI、アナリティクス等がビジネス変革における重要技術の位置づけになっている。このような状況のなかで、IT子会社は親会社の企画・構想段階から、社内システムの現状やテクノロジートレンドを踏まえたシステム実現方式の提案とその実行が求められる。だが、これまで既存システムの運用・保守が主要業務であったため、DXに必要なケイパビリティが十分に習得できていない。
各社、デジタル人材育成の取り組みを進めているが、IT子会社としての目指す姿が明確ではないなかで、現場での個別最適が図られてしまい、最終的に大きな成果が得られない懸念がある。
まずは将来のビジネス構想およびシステム基盤をインプットに、5年後、10年後のIT子会社の在り方を示し、その将来像と照らし合わせながら”計画的に”かつ”長い目線で”対応していく必要がある。
採用による社員数増加やレガシーシステムに対するクラウド活用等から捻出したキャパシティ・コストを人材育成に投資し、リスキルされた人材を変革案件等の成長分野に再配置するスキームを継続的に実施することが重要である (図表2) 。
最後に
ビジネスモデルの変革や創造を支えるシステム開発態勢について考えてきたが、「システム基盤」、「アジャイル開発」、「人材育成」に対して、検討の主体となる部署がそれぞれ異なるため、個別最適に陥りやすい。弊社はパートナー会社として、システム開発態勢の強化に向けて、全社横断で支援していく所存である。
※FSアーキテクトは、金融業界のトレンド、最新のIT情報、コンサルティングおよび貴重なユーザー事例を紹介するアクセンチュア日本発のビジネス季刊誌です。過去のFSアーキテクトはこちらをご覧ください。
