アクチュアリーのアジリティ
アジャイルの活用により、アクチュアリーチームにおける効率性、予測可能性、透明性を向上させる

Al MeleHead of Agile Centre of Excellence

Jennifer Nusbaum

Head of Agile Coaching Americas

SCORはなぜアジャイルを使っているのか？

• SCORが持つリソースでより多くの価値を提供できるようにする。
• 不安定、不確実、複雑な市場において、レジリエンスを創出する。
• イノベーション、サービスの提供、組織のアジリティにおいて、業界内で卓越した評判を確立する。
• 商品設計のプロセスの早い段階から関与し、お客様の目標と目標達成のために直面する問題について、より透明性の高い知見を得ることで、お客様と強い関係を築く。
• すべての従業員が、SCORの目標に貢献するために自分の声を生かすことができると感じ、多様な従業員の潜在能力を最大限に引き出す。
上記を通じて、再保険を増やし、私たちが保障と安心を拡げることに貢献できる
3

Actuarial Agility

沿革X-15 超音速ジェット –
反復・漸進的な開発

Deming
トヨタにおけるPDSA

トヨタ
生産方式

4

Actuarial Agility

新製品開発
ゲーム

沿革

アジャイルマニフェスト

5

Actuarial Agility

沿革：アジャイル価値

個人と相互作用実用的な商品*顧客との協働変化への対応-プロセスやツールよりも包括的なドキュメンテーション書類よりも契約交渉よりも計画に従うよりも右側の項目に価値がある一方で、私たちは左側の項目により大きな価値を見出す。

6

Actuarial Agility* マニフェストには「ソフトウェア」と記載しています。応用性を明確にするために、私たちは「商品」に置き換えました。

沿革：アジャイル原則...そして、アジャイル原則によってマニフェストにされます。
価値ある仕事を早く、継続的に提供することで、お客様に満足していただくことが最優先。

7

プロジェクト終盤であっても、要件の変更を歓迎。アジャイルプロセ
スは、顧客の競争優位のために変化を利用するやる気のある個人を中心にプロジェクトを構築する。彼らが仕事を成し遂げることを信じ、必要な開発チームと外部の間でも開発チームの内部でも、情報を伝達する最も効率的で効果的な環境とサポートを与える。

方法は、対面での会話である。

優れた技術と優れたデザインに継続的に注目することでよりアジャイルになる。

シンプルであること、つまり、「やらない作業を最大化する」ということが必要不可欠。

Actuarial Agility

数週間から数ヶ月の間で、高い頻度で成果物を提供。
より短い期間での提供が望ましい。

使える商品は進捗の主要な指標となる。

ステークホルダーとチームは、プロジェクト期間中、日々協力し合わなければならない。

アジャイルプロセスは持続可能なペースを促進する。チームは一定のペースを無限に維持できるはず。

最高の構築、要件、設計は、自己組織化されたチームから生まれる。

定期的にチームはどうすればより効果的になるかを振り返り、それに応じて行動を調整・修正する。

アジャイルの核心：マインドセット

8

Actuarial Agility

改善

協働

振り返り

納品

アジャイルが有用なのはどこか？

• 解決すべき問題が複雑；• 解決策は当初未知数であり、要件も変わる可能性が高い；• 作業はモジュール化することが可能；• 最終担当者との密接な協働（また、最終担当者からの迅速な回答）が可能の場合ソフトウエア開発だけではありません!

9

Actuarial Agility

https://hbr.org/2016/05/embracing-agileゴールは、「アジャイルを行う」
ではない。

回答はより早くこと様々なチームがアジャイルを選択するのは、アジャイルが目的の達成を手助けするから。。

より効率的に予測可能性を向上

より透明性が高い
持続可能なペースで
10

Actuarial Agility

新事業開発のためのアジャイル
Sidharth Sadani ASA

Senior Data Scientist, SCOR

良いクライアント・エンゲージメントの要素

透明性 ・高い評価・信頼

コミュニケーション

納品（タイムラインごと）

12

Agile for New Business Development応用例：医的引受に予測モデルを活用したい米国の大手生命保険会社

ステークホルダー：
クライアント
新契約部門

商品数理部門スプリントレビュー

多数のメールと会議。
情報連携のため？
フィードバック収集のため？優先順位を決めるため？

（デモ）

優先順位付けマーケティング部門
期待成果の設定

13

Agile for New Business Development

問題の定義

リスク要因

14

Agile for New Business Development

査定ルール＋ モデル・エンジン

引受の決定

状況1: ルールエンジンにさらにリスク要因を追加する
新しい機能を追加すれば、パフォーマンスが向上するはず経緯- クライアントは、モデルに新しい機能を追加することを望んでいた。
対応- アンダーライターの主観的な検証。
- 他の未解決のクライアントリクエストとの比較による影響度の見積もり。
- バックログ- 上記をもとに、優先順位とタイムラインをクライアントに伝える。
- スプリントサイクル- 漸進的な開発（すべての変更を同時に行うのではなく、一つずつ追加していく方法）
結果 / 学び- その価値と優先順位に関するステークホルダーの支持。
- 漸進的な開発により、段階的にテストと検証を行うことができた。
- 期待値を正しく設定することで、クライアントから信頼を獲得した。
- そのため、計画した仕事は期限内に納品することができた。
15Agile for New Business Development

状況2：潜在的なバグを発見!
バグを発見! 今すぐ潰さないと？
経緯- 本番稼働の約2ヶ月前のテスト時に、モデルに潜在的なバグがあることに気づいた。
対応- バグの影響度を客観的に推定- 他の機能強化やバグとの優先順位付け- 進行中の開発作業の自然な優先順位引き下げ- バグを潰した

結果 / 学び- スプリントの途中で要望や優先順位が出てくることがある。
- 切り替えのコストと新しい作業の緊急性・優先度を比較検討することが重要である。
- 新しい状況にアジャイルに対応し、クライアントの信頼を獲得した。
- 明確な優先順位付け、コミュニケーション、実行。

16

Agile for New Business Development

状況3：リサーチスパイク（十分な情報が知られていないこと）
どうしたらいいのかわからない時、どうしたらいいんだろう？
経緯- クライアントはモデルの説明を希望していたが、複雑な非線形予測モデルの判断を説明する最善の方法は何なのか？
対応- 可能な方法を調査し、リストアップ- SMEガイダンスに基づき、方法を優先順位付け- 少さなくくりで、解決方法の有効性を評価- 解決方法を変えながら上記を繰り返す- 学習と結果を収集し、解決方法に関する最終ガイダンスを提供- 次の作業ステップ : モデルの説明を得るために推奨された解決方法を実行
結果 / 学び- 発見はオープンエンドにできる- しかし、発見するためのゴールや質問を定義し、それに答えなければならない。
- ビジネス価値を見失わないためのタイムボックス（時間管理手法）リサーチ。
- 簡単なところから始めて、即興で行う。
- リサーチスパイクの最後には、解決方法について十分な情報を得た上で決定することができたため、クライアントはエンゲージメントを実感した。
17

Agile for New Business Development

アジャイルはできたか？

アジャイルはルールの集合体ではなく、原則の集合体である
迅速な回答と透明性、そして価値の提供
信頼と長期的な関係の構築
納期を守ることと遅延理由についてのコミュニケーション
18

Agile for New Business Developmentプライシングへの応用
Dan Delany – AVP Actuary - Pricing

アジャイル/スクラムを使う前の状況は？
週1時間の営業部門と再保険協約部門との「成果物」会議- 新しい提案依頼について決定, 協約の変更/クライアント要望、案件の勝敗- すべての未着手作業のステータスのレビュー- 優先順位をつける (たいていは提案依頼)

欠点:-

リソースのキャパシティーが明確ではない
会議と会議の間に情報連携がない
注意がほかのことに向いてしまう（今日一番大事なこと）
特定のタスクがを ”溜まっていく”ことを容認している

約束のしすぎ &納品が間に合わない?

20

Application on Pricing私たちのスクラムプロセスの概要••••

タスクのステータスを確定
すでに納品された項目の確認
未完成の項目について議論
未完成のタスクをバックログに戻す

スプリントレビュー

バックログ・レビュー••••

明確な新興プロセス
新しい項目の確認不要になった項目を確認
優先順位付け•••••スプリント期間の特定マネージャーの事前プランニング
リソースの決定
スプリントアイテムを確定
リソースと締切ビを決定

営業-プライシング
スクラムプロセス•••

21

毎日のスクラムミーティング（15分）
完了したタスクと進行中のタスクの確認
阻害要因の特定と解決

Application on Pricing

スプリントの実行

スプリントの計画

メリット・デメリット
スクラムの 短所（と認識された点）- プランニングの作業が重い（2〜4時間？）- マイクロマネジメント？
- 毎日の定例ミーティング

スクラムの 長所-22

時間をかけて作業キャパシティーについての理解がすすむ
期待値をコントロール
明確な目標、臨時のリクエストの制限、一貫したバックログ削減を実現
頻繁な会話により、「遅れるリスクのある」成果物を早期に発見できる
主要なステークホルダーとの透明性、チーム内の透明性
すべての主要な成果物の進捗状況- 提案依頼- クライアント要望 / 協約の変更- プライシングのプロジェクト(前提条件の分析／プライシングツールのアップデート)

Application on Pricing

結果はどうだったか?
スタート時から、完璧なプロセスはありえないことは分かっていたら... 皆がそれでよいことを受容！
あまりよくなかったところ:• インテークプロセスに課題があった
o 明確な定義がないため、バックログ項目が混乱した。
• スプリントプランニング、スプリントレビュー、バックログレビューの各ミーティングはやりにくかった。
o 最初の数回のステークホルダーとのミーティングでは、定義／目的／流れが不明確だった。
o プランニング会議での時間の使い方は効率的ではなかった。
o 最初はスプリントの60％以上を達成するのは難しかった。

良かったところ：• 自分たちのプロセスを常に評価確認し、新しいことに挑戦し続けた。
o 新しいバッグログアイテム用にグループメールボックスとインテークフォームを作成
o マネージャーの事前プランニングミーティングにより、チームレビューのためのスプリントドラフトを作成できた。
o ステークホルダーセレモニーの流れが良くなり、目的が理解できた。
o 「では2スプリントをやってみよう」ということが簡単にできるようになった。
• 毎日の定例スクラム／スタンドアップは、チームにとって負担にならなかった。
• 干渉しないことについて、プライシングチームからポジティブなフィードバックを得た。
• ステークホルダーが変化を理解し、忍耐強く受け入れてくれた。
23

Application on Pricing

そして、何が起こったの？
2021年8月、プライシングチームは再編され、最終的にスクラムプロセスは脇に置かれることになった
あまりよくなかったところ:• 受け身なチームに逆戻りしてしまった。
• 経営陣とステークホルダーに対する透明性の欠如した。
o バックログやインテークプロセスを一元化することができなくなった。
• 干渉しないことに関するコミュニケーションが少なくなった。

良かったところ:• スクラムのプロセスを懐かしく思うとともに、スクラムが提供してくれたものへの感謝の念が湧いてきた！
• ステークホルダーからも、「スクラムのプロセスが懐かしい」と言われた！
• 現在、以前のプロセスを現在のチーム体制に適合させる方法を検討中。

24

Application on Pricing

ご不明な点、詳細をお知りになりたい方
は、こちらまでご連絡ください:
Al MeleHead of Agile Centre of Excellence, amele@scor.com

Jennifer Nusbaum

Head of Agile Coaching Americas, jenusbaum@scor.com

Sidharth Sadani

Senior Data Scientist, ssadani@scor.com

Dan Delany

AVP Actuary – Pricing, ddelany@scor.com

ご清聴ありがとうございました