買収のペースにおいてデータプロダクトモデルが破綻する理由と、それに代わるエージェント対応データレイヤーのあり方について、HowdenのグループCDOが解説します。
によって アリー・マギュー による投稿
従来のエンタープライズデータのプレイブックは、一定のペースを前提としています。戦略を設計し、プラットフォームを構築し、データソースを体系的に取り込み、主要なユースケースごとにプロダクトを立ち上げます。計画こそが成果物であり、その成果物は長く使い続けられるように作られます。
そのプレイブックは、想定外の方法でストレステストにさらされています。買収によって成長し、エージェントベースのワークフローを構築し、新しいデータソースを迅速に吸収している企業は、より緩やかな時代に向けて構築された戦略が、ビジネス自体の制約になっていることに気づき始めています。あるペースで機能していたアーキテクチャ、タクソノミ、運用モデルが、次のペースにおいてはむしろ障害になり始めるのです。
Barry Panayi氏 は、50カ国以上で25,000人の従業員を擁し、グローバルに保険仲介、引き受け、再保険事業を展開するHowdenのグループCDO（最高データ責任者）です。5年前、同社の従業員数は10,000人でした。昨年は、週に1社以上のペースで企業買収を行いました。Howdenは、エンタープライズデータプラットフォームをDatabricks上で運用しており、100以上の記録ソースを統合アーキテクチャに集約しています。これにより、規制報告からDatabricks Genieによる対話型分析に至るまで、あらゆる業務をサポートしています。
本ブログでは、AIの活用が向かう未来において、従来の設計の選択肢がなぜ機能しなくなるのかについて、Barry氏が解説します。プロダクトモデルは使いにくくなり、データの照合サイクルはコストがかさみ、ダッシュボードのバックログがボトルネックになります。以下では、Barry氏がその代わりに何を構築すべきかを提案します。
Aly McGue：ユースケースごとに1つのプロダクトを作るモデルは、ある時点で破綻し始めるとおっしゃいました。それはどういう意味でしょうか。また、何がそれに代わるのでしょうか。
Barry Panayi：このモデルは使いにくくなると感じ始めています。データレイヤーを、ガバナンスの効いたオープンなサービスの集まりとして捉えれば、今後どのようなAIの需要が生じても、はるかに 柔軟に対応できるようになります。
私たちは、社内でデータをやり取りするエージェントにデータを提供することになりますが、これには異なる設計思想が必要です。利用者がもはやダッシュボードやアナリストだけではない場合、すべてのユースケースを事前に定義することはできません。エージェントは、想定外の方法でデータを構成します。サービスレイヤーはそれを前提としていますが、プロダクトカタログはそうではありません。
だからこそ私は、組織内でプロセスやエージェント関連の取り組みを主導している人物を、早い段階で巻き込むように伝えています。プラットフォームが構築された後では遅いのです。
Aly：Howdenは昨年、週に1社以上のペースで企業を買収しました。そのスピードはデータ組織にどのような影響を与え、アーキテクチャ面で何を変える必要があったのでしょうか。
Barry：私が着任した当時、取り込まれていたデータソースは約80個で、買収後のデータ統合には約6ヶ月かかっていました。私たちが買収を進めるペースを考えると、それでは現場がすぐに結果を必要とするため、サイロを作ったり、別の場所からデータを引っ張ってきたりすることになります。カバー範囲が不十分だったため、部門間での活用も進んでいませんでした。
これは単なる技術的な近代化ではありませんでした。分断、統合の遅れ、重複作業によるコストを排除することが目的でした。アーキテクチャの面では、異なる方向にシフトしました。以前の構成では、データのマスタリング や品質チェックを、レポートレイヤーに近い下流で行っていました。私たちは、データをより早く利用できるようにするために、これらを取り込み（インジェスチョン）にできるだけ近い場所で行う必要がありました。このシフトが、タイムライン全体を劇的に変えました。
Howdenの最大の強みの1つは、異なる事業部門間のコラボレーションです。そして、それを支えるのがデータです。同僚が自分を助けてくれるどのようなデータを持っているか、また自分がどのように同僚を助けられるかを知る必要があります。データを完全に統合してマスタリングするまでもなく、単にデータを可視化するだけで、非常に多くのビジネスチャンスを切り拓くことができました。
Aly：それほど多くのソースがあると、同じメトリクスに対して、それぞれ正しいとされる複数のバージョンが存在することになります。手作業によるデータの照合にチームの時間を費やすのを、どのようにしてやめたのでしょうか。
Barry：同じデータポイントに対して最大4つのバージョンが存在することがあり、それらはすべてそれぞれの文脈において正しかったのです。共通のデータモデルやタクソノミがなかったため、私のチームは特定の回答に対してどのバージョンが正しいかを判断するために、多大な労力を費やしていました。
経営陣は常に必要な情報を得ていました。私たちは数値が一致していることを保証していました。しかし、手作業による照合には時間とリソースがかかり、より価値の高い業務に充てることができた はずでした。その後、私たちはプラットフォームと並行して、標準データモデルである「Accordデータモデル」を構築しました。これによりロジックがコード化され、毎回人がチェックするのではなく、照合プロセスがシステムに組み込まれるようになりました。
これがより本質的なポイントです。タクソノミがコード化されていなければ、チーム自体が照合エンジンになってしまいます。それはレポートサイクルごとに支払う「税金」のようなものであり、ビジネスの成長に伴って、まさに望ましくない方向に膨らんでいきます。
Aly：多くの企業がAIのパイロットプロジェクトを数多く抱えながらも、スケールさせられずにいます。Howdenでは何が変わったのでしょうか。
Barry：多くの組織と同様に、私たちの初期段階は探索がすべてであり、独自のユースケースをゼロから構築していました。何が可能かを見極めるためには必要なフェーズでしたが、真にスケールさせるためには、部門ごとに再構築するやり方から脱却する必要がありました。現在では、Databricksプラットフォームの活用により、パイプラインの標準化、コードの共有、データ資産の再利用が可能になっています。クライアントデータ、リスクデータ、市場データを組み合わせたクロスドメイン分析を、部門ごとに再構築するのではなく、一度構築すれば済むようになりました。
現在、グループ全体でAIユースケースのパイプラインを構築しています。モデルを本番環境に適用し、一貫したサービスとして利用できるようにする作業はまだ途上であり 、そこには課題があることを率直に認めています。しかし、孤立した実験からスケーラブルなケイパビリティへの移行は現実のものとなっています。統一されたビューがなければ、これらは何一つ実現できなかったでしょう。
Aly：小売業のようなトランザクションのスピードでは動かない業界において、データの高速化は実際にどのような成果をもたらすのでしょうか。
Barry：非常に重要なのは、私が「インサイトラグ（インサイトの遅延）」と呼んでいるもの、つまり、社内のどこかにデータが存在してから、誰かがそれを実際に利用できるようになるまでのギャップを縮めることです。
当社の主なビジネスはブローキング（仲介）です。つまり、ブローカーがクライアントと対面する前に、可能な限り最新のインサイトを提供することです。以前のレポート作成は遅く、バッチ処理に依存していました。データが間違っていたわけではありませんが、目にする頃には古くなっていました。これは信頼性の問題ではなく、有用性の問題を引き起こします。バックミラーを見ながら運転しているようなものです。
現在、ブローカーがクライアントのもとを訪れる際、「これが現在、当社のポートフォリオ全体で見られている傾向です。これがベンチマークであり、当社の公式見解です」と伝えることができます。私たちのデータは私たちのIP（知的財産）です。当社のように保険のバリューチェーン全体をカバーしている企業は多くありません。これらのインサイトを迅速に提供しない手 はありません。以前のような分断された状態では、到底不可能なことでした。
Aly：Genieを導入したきっかけは何ですか。また、人々が回答を得る方法はどう変わりましたか。
Barry：入社前の面接の時だったかもしれませんが、「なぜ自分たちのデータとチャットできないのか？」と聞かれたことがあります。論理はいたってシンプルでした。人々はChatGPTを通じてインターネット全体とチャットしているのに、なぜ自社のデータに質問してすぐに回答を得られないのか、ということです。
これには2つの側面があります。1つは文字通りのスピードです。誰かが質問し、その回答がいくつかの数値や簡単なチャートである場合、Genieがそれを即座に作成します。もう1つは、それによって解放されるリソースです。これがなければ、誰かが特定の指標で上位10社のクライアントを求めた場合、アナリストがそれを受け取り、質問内容を確認し、クエリを書き、必要以上に複雑なダッシュボードを構築することになります。そのサイクルは遅いものです。私が着任した当時、新規事業だった当社のUS小売部門では、初日からターゲットアーキテクチャを立ち上げました。彼らは最初からGenieを使用しており、おそらく、一度使っただけで忘れ去られてしまうようなダッシュボードの構築にかかる何百時間もの時間を節約できました。
私の同僚は、これを「Howden Intelligence Layer」と呼んでいます。これは、質問を適切なサービスに振り分ける薄い層のようなものです。調査やメール作成のための質問は 一般的なモデルに送られます。回答がガバナンスの効いたデータ内にある場合は、Genieへの質問となります。ユーザーは、データがどこから来ているかを気にする必要はありません。
Aly：データとAIの取り組みをスケールさせようとしているC-levelのリーダーにアドバイスを1つ送るとしたら、何でしょうか。
Barry：「急がば回れ」です。遅すぎてもいけませんが、最初から適切に設計することです。プラットフォームパートナーにアーキテクチャの設計を支援してもらいましょう。多くのアーキテクトが、過去のやり方の「遺物」を持ち込んでしまうのを何度も見てきたからです。
組織内でプロセスやエージェント関連の取り組みを主導している人物を、早い段階で巻き込んでください。私たちは、社内でデータをやり取りするエージェントにデータを提供することになりますが、これには異なる設計思想が必要です。そして、単なるデータプロダクトではなく、データサービスについて考え始めてください。
バリーの主張はHowdenに関するものではありません。それは、ほとんどの企業が直面しようとしている設計上の選択肢に関するものです。ダッシュボードの時代に適合していたプロダクトモデルは、エージェント（自律型AI）の時代に適合するモデルとは異なります。アップストリームで分類体系（タキソノミー）が定義されない限り、ダウンストリームで行われる整合性確保の作業は恒久的なコストとなってしまいます。ほとんどのチームが最適化の対象としている「データの新しさ」の指標は、ビジネスに とって本当に重要な指標ではありません。本当に重要なのは「インサイトの遅延（インサイトラグ）」です。
Howdenが買収を進めるペースの速さは、こうしたトレードオフを他社よりも早く顕在化させています。しかし、このトレードオフはHowdenに限ったことではありません。これは、エージェントへのデータ提供を目指すすべての企業に訪れる課題であり、今この利用パターンを想定して設計を行うリーダーは、将来的にアーキテクチャを再構築する必要がなくなります。
現在のペースではなく、目指すべき未来のペースに合わせて設計しましょう。
25人以上の業界エキスパートがAI導入を成功に導くための道筋をどのように描いているかについては、Databricksの協賛により作成されたEconomist Enterpriseのレポート「Making AI Deliver」をご覧ください。
(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事
ブログを購読して、最新の投稿を受信トレイにお届けします。