re:Invent 2024: F1とAWSが実現する運用効率化とAI活用
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Driving operational excellence: F1’s AI-fueled race-day transformation (SPT206)
この動画では、Formula 1とAWSのパートナーシップを通じて、組織における継続的なイノベーションと実験の基盤構築について解説しています。Formula 1が直面する180以上のアプリケーション管理や、3つの異なる場所での運用という複雑な課題に対し、Working BackwardsやTwo-Pizza Teamsなどの手法を用いて解決していった過程を紹介。特に、データベーストラブルの解決時間を86%削減したRoot Cause Analysisチャットボットの開発事例を通じて、実験文化の重要性と具体的な成果を示しています。また、Track Pulseシステムの導入により、レース中の複雑なデータ分析とストーリー生成を自動化し、視聴者体験を向上させた取り組みについても言及しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
イノベーションの障壁：官僚主義
こんにちは、ようこそ。まず、こんな状況を想像してみてください。素晴らしいアイデアが浮かびました。 あなたはそのアイデアにワクワクしています。このアイデアは、チーム全体、そして組織全体の働き方を変える可能性を秘めています。これはあなたのキャリアを変えるチャンスです。すぐにでも実行に移したい。モメンタムもあり、計画も立て、ステークホルダーのリストも用意しました。
リーダーシップチームとのミーティングを設定します。アイデアを発表すると、会議室は期待感で満ちあふれ、あなたは準備万端です。そこで質問が始まります。 「予算はどうするの？今年度の予算はもう使い切っているよ」とか、「以前も試したけど、うちの会社では上手くいかなかったよ」とか、「いいアイデアだけど、今後12ヶ月のロードマップはもう確定してるんだ」といった具合です。どこか心当たりがある方はいらっしゃいますか？手を挙げてみてください。真のイノベーションは時として障害物競走のように感じることがありますが、最大の障壁は実は官僚主義なのです。
Formula 1とAWSの革新的パートナーシップ
本日は、組織における継続的なイノベーションと実験の基盤をどのように構築するかについてお話しします。Formula 1のイノベーションの取り組みと最新の技術的ブレークスルーについて、直接お話を伺います。そして、長年言いたかったフレーズを使わせていただきます：「ライツアウト、そして未来が猛スピードでやってくる」。 Formula 1はAWSを活用してデータを分析し、 統計的なインサイトを生成し、新しいファン体験を創造しています。
シンプルですが重要な質問から始めたいと思います：イノベーションを一回限りのイベントではなく、継続的なプロセスにするために必要なものは何でしょうか？ Formula 1とAWSが2018年にパートナーシップを結んだ際、私たちの主な目標はFormula 1のクラウドへの移行を加速することでした。次なるイノベーションの波に向けた基盤を築きたかったのです。2022年、私たちは2つの大胆で野心的な目標を掲げてパートナーシップを更新しました。第一に、スポーツ全体に新しいイノベーションと変革の時代をもたらすこと。第二に、大小を問わず他の組織が模倣できる継続的イノベーションのブループリントを作ることでした。
この24ヶ月間、私たちのチームはFormula 1の高性能オペレーションを支え、ファンがスポーツと関わる方法を再発明してきました。本日は、私たちが共同で開発したソリューションの一部をご紹介します。このような大胆なビジョンを実現するには、実際の作業が始まる前にかなりの準備が必要だということはお分かりいただけると思います。Formula 1とAWSは作業を開始する前に、3つの核となる優先事項について合意しました。
まず私たちは、失敗の可能性を受け入れることを目指しました。失敗は必ず起こるものだと理解しています。間違いを犯すこともありますが、一つひとつの失敗が新しいデータポイントや洞察となり、それがブレークスルーへの近道となるのです。ここで重要なのは、この実験と学習のサイクルを偶然に任せないことです。私たちは、スケールアップして繰り返し実行できる仕組みを作りたいと考えました。 次に、両チームが独自に決断を下し、行動できるようにすることを目指しました。チームのスピードと創造性を解き放ちたかったのです。 そして最後に、実験のベロシティを生み出すことを目指しました。より速いイテレーションを通じて、より早く洞察を得て、それを取り組みにフィードバックし、より早く正しいソリューションに近づけたいと考えました。すべてのチーム、パートナーシップ、組織は、これら3つの優先事項の適切なバランスを見つける必要があります。これはレシピのようなものです。リスク許容度、チームの規模、解決しようとしている問題に応じて、適切な材料の配合とバランスが決まってきます。
実験とイノベーションの文化構築
しかし、私たちが注目したのは実験のスピードだけではありません。発明力を2倍にするために実験数を2倍にするという話をする時、私たちは単なる量だけでなく、意図と実行についても考えています。このような大量の実験を避ける組織もありますが、ビジネスやテクノロジーのリーダーたちと話すと、通常2つの主な懸念事項を耳にします。1つ目は、コアプロダクトから注目が逸れることへの懸念で、2つ目は実験のコストが制御不能になることへの懸念です。
私たちが発見したのは、 以下の通りです：実験自体のコストは通常小さく、本当にコストがかかるのは、それらの実験が成功した時なのです。 しかし、これは言ってみれば良い問題です。ビジネスとして、私たちはそれを望んでいるのです。そのため、実験は迅速で実行可能なものになるよう設計し、同時に実験チームが断固として行動できるよう権限を与えたいと考えています。 一貫したイノベーションは、優れた個人だけに頼ることはできません。彼らは必要ですが、個人の影響力を超えてスケールアップできる仕組みも必要なのです。
Formula 1との協働において、すべての取り組みが適切な注目を集められるよう、私たちはイノベーションフレームワークを作成しました。このフレームワークによって、アイデアを生み出し、キャプチャーし、優先順位を合わせ、良いアイデアだけを前に進めることができます。このイノベーションフレームワークとこれらの仕組みが私たちにもたらしたもう一つの効果は、悪いアイデアを廃棄する別の方法を作り出したことです。はい、私たちにも多くの悪いアイデアがありました。これは組織でよく見られることではありません。皆さんのチームや組織で、悪いアイデアが先に進むのを防ぐ良い仕組みがある方は手を挙げてください。予想通りですね。個人として、私たちは自分のアイデアに対して慎重になりがちです。自分のアイデアがベストフィットではない、良くない、あるいはタイミングが合っていないことを認めるのは難しいものです。そのため、これに対処する仕組みがあることで、そのプロセスから個人的な要素を取り除くことができます。
私たちのイノベーションフレームワークの中核にあったのは、Amazonのワーキングバックワーズアプローチです。 これは、Amazonで顧客向けの取り組みをすべて開発・ローンチする際に使用するアプローチと方法論です。これは文章による説明、架空のプレスリリース、よくある質問を作成するプロセスです。このプレスリリースでは、将来製品をローンチした時点を想像し、そこから現在の私たちに向けて、このローンチをどのように発表するか、顧客の反応、顧客体験はどうなるかを説明します。この文章による説明があることで、プロセスの早い段階でフィードバックを集め、取り組みを改善し、スピーディーな実行の準備ができます。準備が整えば、悪いアイデアが先に進むのを防ぐために、まさに同じ仕組みを使用します。
次に私が強調したいのは、素晴らしいアイデアを持っているだけでは不十分だということです。ここにいらっしゃる方々の会社で、アイデアが全くないという会社はないでしょう。アイデアは誰にでもたくさんありますが、私たちに必要なのは、チームがそれらのアイデアを効果的かつ効率的に実行できる組織構造です。万能な解決策は存在しませんが、Amazonでは「Two-Pizza Teams」と呼ばれる方式を採用しています。私たちは、自律的な意思決定ができる小規模で機動力のあるチームで組織されています。これにより、 チーム間のコミュニケーションに費やす時間を削減することができます。チームが大きく考え、イノベーションを起こすための時間を確保できるのです。 そして重要な点として、実験を行うための余力がより多く生まれます。
Formula 1の複雑なITインフラと課題
Formula 1とのコラボレーションでは、8〜10人程度のクロス組織チームを中心に取り組みを組織しました。このコアチームのメンバー全員が、明確に定義された役割、責任、そして説明責任を持っています。さらに重要なことに、このコアチームは外部の承認に頼ることなく、日々の運営上の決定を行う権限を与えられていました。
さらに、Formula 1は、既存の資金調達サイクルとは別に、プロトタイプやプルーフオブコンセプトのための小規模な年間予算をそのコアチーム専用に確保しました。このような構造的な選択により、組織の慣性や遅延を軽減することができました。すべての遅延をなくそうとしているわけではありませんが、私たちに適したスピードになるまで削減しようとしているのです。
構造的な自律性だけでは十分ではありません。イノベーションには、意思決定に対する規律ある取り組みも必要です。私たちは「Single-threaded Ownership」に依存しており、これにより解決しようとしている問題について常にフルタイムで考える1人のビジネスリーダーが存在することを保証しています。この人物は、進捗を推進し、リソースを調整し、障害を取り除く責任を負っています。このアプローチにより、より迅速に行動でき、共有所有モデルがもたらす非効率性を排除することができます。Formula 1とのパートナーシップでは、当初はガバナンスモデルとしてステアリングコミティーを採用していましたが、日々の運営上の意思決定には遅すぎることにすぐ気づきました。その結果、Single-threaded Ownershipに移行し、より高速な意思決定、より少ない依存関係、そして各イニシアチブをパイプラインを通じてより迅速に進められる構造を実現しました。
Amazonでは、 意思決定のスピードと品質のバランスを取るために、「One-way Door」と「Two-way Door」という意思決定の概念があります。One-way Door型の意思決定は、状況に応じて結果が重大またはコストが高い決定であり、このタイプの決定には多くの時間をかけて調整や議論を行います。一方、Two-way Door型の決定は、私たちが職業生活で行う決定の大半を占めます。これらは、結果を覆すことができ、そのコストもそれほど高くない決定です。つまり、ドアを開けて向こう側を見て - 良ければ進み、気に入らなければ戻って別のドアを選ぶことができます。また、素早く行動することも学びました。私たちは、欲しい情報の70%を得た時点で進めるという経験則を持っています。80%や90%の情報を待つのは良いことですが、遅すぎます。遅れを取りながらイノベーティブであることはできないということを私たちは知っているのです。
とはいえ、実験のための実験であってはなりません。目的もなく突き進むのは避けたいところです。イノベーション自体が目的なのではなく、そのイノベーションがもたらすインパクトこそが私たちの求めるものなのです。Formula Oneにおいて、私たちが行うすべての判断、仕組み、実験には、ただ一つの目的がありました。それは、最も重要な場面でインパクトを与えることです。Formula Oneは、そのインパクトを与えるべき場所について、非常に明確な vision を持っていました。それは、コース上でより速く、よりスマートな判断を下すこと、そしてファンにとってより深く、より意味のある体験を提供することでした。つまり、イノベーションをインパクトに変えることが全てだったのです。
ここで、Formula OneのHead of Digital Technologyを務めるDavid Kingさんをお招きし、彼らのイノベーションの journey と最近のブレークスルーについてお話しいただきたいと思います。David、よろしくお願いします。隅にホイールガンがあるので、まるでFormula Oneのパドックにいるような気分ですね。ヘッドフォンを着けていただいて良かったです。AWSと共に取り組んできた過去数年間のイノベーションについてお話しする前に、Pete Samaraさんを偲び、敬意を表したいと思います。Peteは愛する夫であり、父であり、兄弟であり、同僚でした。彼は私たちとAWSとの関係、そしてイノベーションに取り組む方法に不可欠な存在でした。Pete、Formula Oneに情熱を吹き込んでくれてありがとう。
さて、Formula 1とは何でしょうか？皆さんもご存知かと思います。コンテンツをご覧になった方もいれば、実際にレースに行かれた方もいるかもしれません。2週間前のLas Vegasに行かれた方はいらっしゃいますか？いや、Las Vegasで2週間は無理でしたね（笑）。でも、私たちが直面している課題をご理解いただけている方はどれくらいいらっしゃいますか？Formula 1は、FIA Formula One World Championshipの商業権保持者です。つまり、私たちは組織として、シーズン中に24のイベントを開催し、それを世界中に届ける機会を得ているのです。私たちのオーディエンスは世界中に広がっており、特にヨーロッパに集中しています。2024年には15億人がFormula 1を視聴する見込みで、アメリカ市場も成長しており、現在レースの4分の1がアメリカ大陸で開催されています。また、今年は600万人がFormula 1のイベントに足を運んでいます。
私たちは何をしているのか？私たちのミッションは何か？私たちは真のグローバルスペクタクルを作り出すことを目指しており、今シーズンはそれを達成できたと思います。今週末のAbu Dhabiで今シーズンの最後のチェッカーフラッグが振られると、過去最多となる24のイベント、5大陸、21カ国、5回のダブルヘッダー、3回のトリプルヘッダーを完了することになります。かなりハードなスケジュールですが、私たちのチームはそれに立ち向かってきました。私たちは、組織内だけでなく、モータースポーツ全般においても、ポジティブで包括的な環境作りを目指しています。来週末には、F1 Academyシリーズの2シーズン目が終了しますが、これは女性ドライバーやチーム内のスタッフがより高いレベルの競技に進出できるよう育成を目的としています。
サステナビリティも私たちの活動の中核です。2026年からは、サーキットを走るFormula 1マシンは完全に持続可能な燃料を使用します。組織としても、可能な限り航空輸送の代わりに海上輸送を活用しています。海上輸送が使えない場合は、現在では持続可能な航空燃料を使用しているDHLを利用しています。サステナビリティに関する他の重要な取り組みとしては、リモートオペレーションモデルがあります。これについては、プレゼンテーションの中で何度か触れることになりますが、このモデルによって私たちの運営は3つに分かれました。サステナビリティの面では非常にポジティブな効果がありましたが、技術的には大きな課題も生まれました。私たちはチームではありませんが、75年の歴史を持つスポーツとして、最先端の技術を駆使していると言えます。各セッション中に数百万のデータポイントを収集するオンボードシステムから、リモートオペレーションのセットアップ、プロダクションにおけるAugmented Realityグラフィックス、そしてデジタルプラットフォームまで、本当に興味深い取り組みを行っています。
Root Cause Analysisチャットボットの開発と実演
私たちのビジネス上の課題とは何でしょうか？最も重要なのは、この会話に関連する点です。私たちはとてもリーンな組織です。多くの人はFormula 1というブランドを見て、何千人もの従業員がいると思うかもしれませんが、実際には600〜700人程度です。法務、商業、HR、デジタルプロダクション、リグチーム など、イベントを開催し、世界に発信するために必要なすべての部門に人材が配置されています。私たちのスポーツは、かつてないほどデータドリブンになっています。ドライバーたちは1周ごとの0.1秒を争っており、組織としても同じように努力を重ねなければなりません。私たちは非常に複雑なシステムとリモートオペレーションの体制を持っています。そして、多様な作業環境という最後の点について - 私たちは年間を通じてほぼ2週間ごとにイベントを開催しています。シーズンは約11ヶ月で、ダブルヘッダーやトリプルヘッダーもあります。チームは信じられないほど懸命に働いています。状況を説明すると、Formula 1のイベントのために、サーキットでインフラを構築し、ハードウェアを配置し、Biggin Hillの本部に接続するまでに約7〜10日かかります。2019年、私たちは日本の鈴鹿でレース週末の最中でした。台風が接近していました。
インフラは固定されていましたが、それだけでは十分ではないと感じました。そこで24時間以内に、チームは完全にインフラを解体し、ピットビルの中に移動して再構成し、日曜日のレースに備えました。レースは予定通り行われ、世界中に放送されました。
私たちのBig Betsは、イノベーションを考える際に触れる目標であり、悪いアイデアを捨てる基準となります。結局のところ、アイデアがこれら3つの領域のいずれかを推進するものでなければ、それは悪いアイデアではないかもしれませんが、そのアイデアにとって適切なタイミングではないかもしれません。高性能なオペレーションについて言えば、今シーズンは機材を世界中24カ所に移動させています。私たちはリモートオペレーションモデルに移行し、サーキットに派遣する人員を減らし、サーキットでのインフラ展開を縮小しました。イギリスに固定拠点を設け、クラウドサービスを利用しています。これは、様々な場所に配置された多くの機材とソフトウェアを監視し、保守し、常に進化させる必要があるということです。
チームがミッドシーズンブレイクから新しいエアロパッケージを持って戻ってくるのと同じように、このスポーツでは立ち止まることはできません。私たちは常に前進し、ファンに最高の体験を提供し続けなければなりません。ワールドクラスのレースについて - 私たちはチームではありませんが、ある程度レースに影響を与えることができます。5〜10年前、私たちはレースが必ずしも競争的ではないことを認識しました。AWSと協力して、Computational Fluid DynamicsとHigh-Performance Computingを使用し、より接近したレース、より多くの追い越し、そして究極的にはより魅力的なスポーツファン体験を可能にする新しいコンセプトカーと新しい規則を生み出しました。
ファン体験は、魅力的なコンテンツと魅力的なレースを包含するすべてです。社内では「すべてはファンのため」と言っています。ファンがいなければ、このスポーツは存在しえません。これはかなり複雑なスポーツです。今日早くOlga Miloserdovaと話していたように、参入障壁は高く見えることがあります。Drive to Surviveや自国でのレース増加により、多くの新しいファンが加わってきました。私たちは彼らに訴求し、このスポーツを理解しやすくし、DRSとは何か、Undercutの脅威とは何かを説明する必要があります。
私たちはAWSと協力して、保有する膨大なデータを活用してF1インサイトを生み出してきました。放送をご覧になると、画面上にグラフィックが表示され、例えば「Max Verstappenが今ピットに入れば、Landoがピットインした際にアンダーカットの脅威となり、前に出られる」といった情報が表示されます。これらの3つの分野で私が言及したイニシアチブは、どれも既製品として存在していませんでした。これはAWSとの相性が非常に良く、補完し合える関係です。AWSは製品ではなくツールボックスですが、私たちはAWSと協力して、私たちの目的に合った製品を作り上げてきました。皆さんもAWSで同じようなことをされていると思いますが、これらすべてにはビジョン、実験、改善の繰り返し、そして十分だと判断して停止するタイミングを知ることが必要です。
Track Pulseと呼ばれるものについて少しお話ししたいと思います。実は私たちは幸運なことに、このプロジェクトに関わったAWS ProServeのメンバーの一人が外にいらっしゃいます。Formula 1は、先ほど申し上げたように非常に複雑なスポーツです。また、オーストリアの丘陵地帯に広がる7キロのサーキットを20台のマシンとドライバーが走り回るスポーツでもあります。スタジアム競技ではなく、ボール1つを追うわけでもないため、展開を追うのが難しい場合があります。
私たちのプロダクションチームは、プラクティス、予選、レースなど、すべてのトラックセッションのストーリーを伝えるために懸命に働いていますが、すべてを把握することはできません。彼らには限られた目と、見られる画面やデータポイントの数にも限りがあります。Track Pulseは、私たちが持つすべてのテレメトリーとポジショニングデータを活用します。そのデータをシステムに取り込み、ECSクラスターで正規化します。これを過去のデータと組み合わせて、ストーリーマシンに送ります。このストーリーマシンは、トップ争い、ミッドフィールドの戦い、コンストラクターズチャンピオンシップを争うFerrariとMcLarenの戦いなど（順位は下位であっても）、あらゆるストーリーを生成しようとしています。私たちはこれらのストーリーに命を吹き込み、プロダクションチームに提供することに注力しています。
私たちはSQSとDynamoDBを使用してこれらのストーリーを保存し、プロダクションチーム、放送パートナー、解説者が利用できるようにしています。例えば、「シンガポールでセーフティカーが出動したのは12年ぶり」といった興味深い情報を共有し、番組を盛り上げることができます。
Track Pulseの簡単なビデオをお見せしましょう。 21カ国に広がる24のサーキット、20人のドライバーが全員トラックに出て 一つの夢を追いかけています。Formula 1は何百万人もの 熱心なファンにアクションを届け、サーキットで展開される本物の魅力的なストーリーをグローバルなプロダクションを通じて伝えています。AWSはFormula Oneと提携し、プレシーズンテストから最終戦のAbu Dhabiまで、技術革新を推進しています。
F1のドライバーとチームと同様に、F1の放送制作チームも、世界中のファンがアクションの瞬間を見逃すことがないよう、様々なデータソースを基に瞬時の判断を下しています。各マシンには最大300個のセンサーが搭載され、リアルタイムのデータアクセスが全てを左右します。毎秒110万以上のテレメトリーデータポイントが生成されています。AWSとF1は共同でTrack Pulseを開発し、ライブ制作チームが展開するすべてのストーリーを簡単に把握できる統合ビューを実現しました。Track Pulseは、リアルタイムのアクションと過去のデータを組み合わせることで、レースのペースに合わせてファンに魅力的なインサイトを届けています。Track PulseはAWSによって支えられています。
イノベーションフレームワークの実践と成果
ありがとうございます。このビデオの功績は、素晴らしいコンテンツ制作チームのおかげです。では、Gauravを壇上にお呼びしたいと思います。彼は実験の文化について話してくれる予定です。ありがとう、David。
皆さん、こんにちは。私が皆さんとビールの間に立っているのは分かっていますので、もう少しお付き合いください。あと20分でビールの時間です。私はGaurav Kailaと申します。私のチームは、Formula 1のようなお客様がAWS上でイノベーションを起こし、Track Pulseのようなソリューションを構築するお手伝いをしています。皆さんは組織内でイノベーションを展開するためのメカニズムについて既にお聞きになっていますが、私は実験の文化と呼ばれる別のメカニズムについてお話ししたいと思います。Formula 1がどのように自社組織内でこの文化を育み、Track Pulseのようなソリューションを構築してきたかについて、Davidからお話を伺います。Track Pulseのような、この文化を活用して実際のビジネスインパクトを生み出したソリューションの実例についてもお話しします。そして最後に、一番良い部分として、皆さんの組織内でも同じことを実践するためのメカニズムについて学んでいただきます。
実験の文化について話す前に、実験とは何を意味するのか、なぜ私がこれをすべての組織で育むことが重要だと考えているのかを理解しましょう。イノベーションは産業を変革する要となってきましたし、これからもそうあり続けるでしょう。イノベーションは玉ねぎのように複数の層を持っています。イノベーションの真の意味の背後には、最大のブレークスルーを支えているテクノロジーがあります。そしてテクノロジーの背後には、小さなステップを踏み、仮説検証を行い、試行錯誤を重ねる実験という、しばしば見過ごされがちな実践があります。
しかし、実験とは何を意味するのか、と疑問に思われるかもしれません。今や誰もがGenerative AIについて話していますので、私は3つの一般的な言語モデルに「実験とは何か」という質問を投げかけてみました。それぞれが生成した定義を読むと、実験が本当に意味するものが理解できてきます。それは事実を証明し、何らかの証拠を示すために行われる取り組み、プロセスです。しかし、これらの定義には、産業環境における実験を語る上で非常に重要な属性が1つ欠けています。それは時間枠です。アカデミックな環境では仮説を証明するのに5年以上かかることもありますが、産業環境では同じような時間をかけることはできないでしょう。時間枠が実験主導のイノベーションにおいてどのように機能するのか、詳しく見ていきましょう。ほとんどの企業はイノベーションを直線的にアプローチします - 目的を定め、目標を設定し、それに向かって進んでいきます。
このアプローチには明らかな問題があります。目標が大きすぎたり複雑すぎたりすると、時間とともに熱意が薄れて取り組みが失敗してしまいます。さらに大きな問題は、新しいステークホルダーがプロジェクトに参加したり、優先順位が変更されたりした場合に、再び失敗してしまうことです。
ほとんどのイノベーションは単純ではなく、ベースライン（つまり、達成しようとしている現状）を理解するのに時間がかかります。これには、そのベースラインを確立するための小さなステップを踏み、その後も目標に向かって小さなステップを重ねていく必要があります。先ほど実験について触れましたが、失敗は全く問題ありません。最も重要なのは、なぜ失敗したのかを理解し、その教訓を次の実験に活かして前進することです。実験が目標を達成できなかったとしても、それは全く問題ありません。大切なのは、私たちにとって何が最適かを見極めながら、理解を深め、方向転換していくことなのです。
これはAWSやFormula 1だけの考え方ではなく、データによっても裏付けられています。McKenzieの調査によると、企業の70%がイノベーションの欠如や、イノベーションを実装するためのフレームワークの不足により、変革に失敗しているとされています。だからこそ、実験の文化とすべてのイノベーションメカニズムを持つことが、イノベーションを実現する上で極めて重要になるのです。
ここで、Formula 1における実験がどのようなものかについて、Davidに話を戻したいと思います。この引用は特に適切です - 2025年にFormula 1は75周年を迎えますが、これまでの実験とイノベーションがなければ、今日の姿はなかったでしょう。多くの人々は、Formula 1から生まれたイノベーションを、それと気付かずに使用しているかもしれません。このスポーツは、ディスクブレーキ、ハイブリッドエンジン、持続可能な燃料、アクティブサスペンション、回生ブレーキなど、現実世界で価値を生み出しているイノベーションを生み出してきました。
実験を通じた私たちの注目すべきイノベーションの1つが、オンボードカメラの導入でした。現在では、マシンからの視点でFormula 1を観戦するのが当たり前になっていますが、1985年にサーキットを走行中の車からライブ映像を配信した時は、画期的な出来事でした。時速230マイルで走行する車から動画を撮影するのは非常に難しい課題ですが、私たちは毎週それを実現しています。その後の数十年で、後方向き、ドライバー正面、バンクコーナーでのローアングルなど、様々なカメラポジションを探求してきました。2021年には、ヘルメットカムという次の大きなステップを踏み、視聴者にドライバー目線のアクションを提供することに成功しました。
しかし、Olgaがシングルスレッドリーダーについて言及したように、私たちは必ずしも常に正しい判断ができていたわけではありません。このモデルが制約となり、イノベーションのスピードが十分でなかったため、私たちはこのモデルから脱却する決断を積極的に行う必要がありました。PR FAQとWorking Backwardsを用いたシングルスレッドモデルは、私にとっては目新しいものでしたがAmazonianにとっては馴染みのあるものでした。これにより、何が良くて何が良くないのか、そして私たちのビジネス目標に関連するものは何かについて、徹底的に見極めることができました。 これで、Formula 1のような組織で実験とイノベーションの文化がどのように展開され、実際のビジネス価値を生み出しているかが、より具体的にご理解いただけたのではないでしょうか。
さらに具体的な例として、私たちが全員で協力してFormula 1のために構築した実際のユースケースをご紹介したいと思います。これは、特に時間が非常に重要なレース日において、F1エンジニアが定期的に直面する問題です。この例を通じて、Working Backwards、実験、そして実験のスケーリングといったメカニズムについて振り返ってみましょう。Davidに再び話に加わってもらいますが、 このユースケースの詳細に入る前に、Formula 1の大規模で複雑なITインフラについて理解しておくことが重要です。
数年前は、この状況は全く異なっていました。Olgaが私たちのAWSとの変革の旅の始まりで述べたように、アプリケーションの一部をクラウドに移行し始めた頃からCOVIDの影響で状況は複雑になりました。私たちには約180の独自開発アプリケーションがあります。これはMicrosoft WordやPowerPointではなく、レースのサポート、データの取得、フィードの収集、スポーツに関するグラフィックスやインサイトの生成のために、20年以上かけて開発されてきたアプリケーションのことです。そして、3つの場所に分散しているという複雑さが加わりました。
サーキットには、ビデオフィードと毎秒100万ポイントのテレメトリーデータを取得するためのインフラが全て配置されています。そのデータを低レイテンシーで取得する必要があるため、物理的なインフラを備えたEvent Technical Centerという大規模な施設にフィードバックしています。私たちは本当にフットプリントを削減しました。ライブプロダクション、データ処理、グラフィックス制作、コンテンツ制作を行うMTC（Media and Technology Center）を独自に構築しました。3番目の場所はAWSで、レイテンシーへの依存度が低いアプリケーションをより多く実行しています。
これにより、3つの異なる場所でアプリケーションやサービスを実行し、少なくとも3つの異なる場所でそれらをサポートし使用する人々がいるという技術的な課題が生じています。自宅にいる人もいれば、サーキットにいる人も、MTCにいる人もいます。タイムキーパー、グラフィックスプロデューサー、ITエンジニアなど、これらのシステムに関わる人々は実に多岐にわたります。このインフラ全体がレースごとに約5日間しか存在しないという状況で、3つのサイトにまたがるこれらのシステムの管理に苦心しています。チェッカーフラッグが振られ、表彰台でのセレモニーが終わるとすぐに、全てのインフラの解体を開始するのです。
私のような Formula 1 ファンにとって、これらは普段気づかないような問題です。 Formula 1 の華やかな部分は目に入りますが、これらはファン体験を良いものにするために F1 が裏で対処している実際の課題なのです。David が話したように、Formula 1 のグローバルな展開には複雑な課題があります。Formula 1 は S3 上に約 18 ペタバイトのデータを保持し、約 375 の EC2 インスタンス、100 以上の AWS 環境に分散する 180 ほどのインスタンスを持っています。クラウドとオンプレミスに 180 のアプリケーションを持ち、それらは異なるチームや異なるシステムで管理されているため、システム間の依存関係はより複雑になっています。
レース当日、F1 エンジニアがデータベースからリアルタイムデータにアクセスできない理由を突き止めようとする場合、それは困難を極めます。 何が起きているのかを理解するために、複数のシステムと複数のチームを確認する必要があります。Formula 1 の見積もりでは、データベースドライバーがサポートされているかどうかの確認に 15〜30 分、関連するログの検索に約 2 時間かかるとのことです。レース自体が 1 時間半から 2 時間程度しかない中で、これは非常に重要な時間が失われていることになります。エンジニアが関連するログを 2 時間かけて探している間にレースが終わってしまうことは想像に難くありません。 Formula 1 の見積もりによると、レース日ごとに 1 回は発生する重大な問題に対して、開発、運用、インフラストラクチャー、ネットワーキングなど複数のチームの連携が必要なため、何が起きたのかを特定して解決するまでに 3 週間もの工数がかかっているとのことです。
AWS と Formula 1 は、この課題をイノベーションの機会として認識し、複数のチームで協力してソリューションを開発しました。 私たちは、F1 エンジニアがこれらの問題をデバッグする際の作業を支援する Root Cause Analysis チャットボットを構築しました。このソリューションについては次のスライドでデモンストレーションをお見せします。
まず、私たちが何を構築しようとしているのかを理解することが重要でした。Working Backwards などの手法を活用することで、Formula 1 のために解決すべき具体的な問題を特定しようとしました。問題が発生した際の F1 エンジニアの行動を模倣するチャットボットを構築することを決定しました。これを実現するために、F1 エンジニアと一緒に座り、彼らのワークフローを理解し、そのプロセスを文書化して、それを私たちのベースラインとしました。そこから、5 週間の実験期間中、小規模な実験を重ねて開発を続けました。予想以上に失敗も多かったのですが、それぞれの失敗が目標の理解と最終目標への進歩につながりました。
レース週末に実際に起きた事例に基づいて、データベースのトラブルシューティングのデモンストレーションで、このソリューションの動作を見てみましょう。 最初に接続性について質問します：「SQL データベースに接続できません。ドライバーの問題だと思うのですが、この特定のドライバーがサポートされているか教えてもらえますか？」チャットボットは応答して、 持っている情報によるとそのドライバーはサポートされていることを確認します。次の質問はネットワーキングについてです：「ネットワーキングを確認してもらえますか？このIP範囲から US-WEST-2 AWS リージョンに接続し、このEC2インスタンスIDのポート1433に接続しようとしています。」
チャットボットはシステムに問い合わせを行い、その範囲内で接続性があるはずであり、インスタンスが稼働中で私のネットワークからアクセス可能であることを確認します。次に、「データベースの健全性状態を教えてください」と尋ねると、 チャットボットは、CPU使用率が低く、空きメモリが利用可能で、データベースのロックは発生しておらず、重いSQLや上位のSQL消費者も報告されていないと応答します。これらのメトリクスを総合的に判断して、データベースは健全な状態にあると判断しています。
これらのステップをすべて実行し、問題がないように見えるにもかかわらず、まだ問題が発生している場合、他の担当者にエスカレーションしたいと考えるかもしれません。 チャットボットに、これまでの確認内容をまとめたJiraチケットを作成するよう依頼します。チャットボットは、Jiraチケットが正常に作成されたことを確認し、概要を提供して、さらなる調査のためにチケットを記録します。Jiraボード上で、「SQL Serverデータベースに接続できない」というタイトルの新しいチケットが作成されているのが確認できます。そこには概要と試行した手順が含まれており、さらなるエスカレーションのための情報も記載されています。
これは、エンジニアがまずデータベースにアクセスできない理由を特定する必要がある実際の問題を表しています。エンジニアが通常2時間程度かけて調査する内容を、このAgentは数秒で実行します。即座に解決策が見つからない場合、Agentは実施したすべての手順を文書化したJiraチケットを作成し、エスカレーションチームに提供します。これにより、Formula 1のエンジニアとエスカレーションチームの両方の時間が節約されます。エスカレーションチームは、すでに完了したトラブルシューティングの手順をベースラインとして作業を進めることができるからです。この解決時間の短縮は、F1エンジニアだけでなく、エスカレーションチームにも影響を与えます。
ここで注目すべき点は、システムに質問する際に経験は必要ないということです。ジュニアのリファンドエンジニアでも、同じ質問をして必要な回答を得ることができます。Davidのビジネスインパクトについての話の先回りはしませんが、これこそがFormula 1が求めている技術的ソリューションがどのように結果をもたらすかということです。
スライドにうまくまとめられていますが、補足させていただきます。解決時間はFAQの一部として捉えており、目標値を設定していました。FAQで設定した数値とは断言できませんが、私たちのチームが日々対処している定期的な問題の解決時間が印象的なほど短縮されています。デモでは技術的な知識のある人がチャットボットと対話している様子を見ましたが、実際には問題解決を民主化することに成功しています。なぜなら、レース終了後に順位を確定しようとしているタイムキーパーが問題に直面した場合でも、より技術的でない方法で質問することができるからです。
このプロセスに従う副産物として、それらのアプリケーションからのすべてのデータを一箇所に集約することができます。そのため、Root Cause Analysisがその場で問題を解決できない、あるいは問題の原因を特定できない場合でも、これまでの作業内容と、その時間枠に関連するすべてのログファイルへのアクセス情報を含めて、きれいにパッケージ化してJiraチケットにまとめることができます。また、コンテキストを把握できるため、適切なチームへのエスカレーションも容易になります。例えば、ネットワークの問題らしいと判断された場合、レースから戻ってきたばかりのスタッフに誰に割り当てるべきか、その人が対応可能かを確認する手間なく、直接ネットワークチームに振ることができます。
この解決策を拡張するのに十分な自信が得られました。これらは実験的な取り組みです。デモでお見せしたような段階に到達するまでに、小さなステップを重ねてきましたが、これによって私たちの環境全体にさらに展開し、異なるテクノロジーや異なるレイヤーを取り入れていく十分な確信が得られました。ネットワークチームは特に、彼らのデータもすべてこのシステムに取り込むことに熱心です。私たちは依然として人間の介在が必要だと考えています。実際、先ほどのプレゼンテーションの1つでAIがどのように私たちを支援しているかについての話がありましたが、私たちが扱っているシステムの多くがミッションクリティカルな性質を持っているため、十分な知識を持たないユーザーに、壊滅的な影響を及ぼす可能性のあるステップを実行させたくはありません。
組織におけるイノベーション文化の展開方法
ありがとう、David。そしてが気に入りました。私たちは技術ソリューションを作るために技術ソリューションを構築しているわけではありません。ビジネスへのインパクト - 解決時間の86%削減や、組織全体への文化の浸透 - これこそが、私たちが技術ソリューションを構築する本当の理由なのです。さて、約束通り、皆さんの組織でも、規模の大小に関わらず、同じような取り組みを始められる方法をまとめたスライドをご紹介します。
ここに1枚のスライドにまとめました。まずは後ろから始めます。Working backwardsは重要です - 技術的な問題からではなく、ビジネスの問題から逆算して考えることです。Formula 1の場合、レース日にFormula 1のエンジニアの貴重な時間を節約するために、いかに迅速に問題を解決できるかを理解することが課題でした。これが私たちが解決しようとしている問題です。そこから逆算して、そのテクノロジーソリューションを構築するために必要な実験を考え出します。次は実験です。解決すべき課題が明確になったら、小さなステップに分解し、それらの小さなステップを実行できる時間枠に分け、繰り返し実行します。失敗は全く問題ありません。失敗を受け入れ、そこから学び、次のステップに確実に活かすべきです。
そして最後に、実験がうまくいったら、祝福し、その実験を複数のユーザーや関係者に展開し、フィードバックを得て、再度改善を重ねます。そしてうまくいっているなら、その文化を他のチームにも広げていきます。なぜなら、自分のチーム内だけでなく、チームを横断して協力し、これらのソリューションを構築しているからです。これは実験とイノベーションの旅の始まりに過ぎません。60分のセッションですべてを網羅することはできませんが、他にもリソースがあります。ここで2つのリソースを紹介しましたので、メモを取れるよう、このスライドを少し表示したままにしておきます。最初のリソースは、すでに言及したイノベーションのメカニズムについて詳しく説明し、同様のメカニズムを自社に取り入れている他の顧客の事例についても説明しています。
次のリソースでは、AWSとFormula 1が共に取り組んでいるさらなるイノベーションについて詳しく掘り下げています。Track PulseやRCAについてお話ししましたが、Formula 1との間には他のイノベーションも進行中ですので、私たちの協力関係についてより良く理解していただけると思います。
本日のお話に興味を持たれた方は、明日と明後日にも関連セッションがございます。個人的におすすめなのは、Duolingoのセッションです。彼らの実験文化と、組織内でイノベーションを推進する方法について語られます。これで本日のプレゼンテーションは終了となります。皆様が何か学びを得られたことを心から願っています。これは学びのカンファレンスですので、ぜひ皆様の組織でも取り入れられる実践的な知識を得ていただけたと思います。
他のセッションも開催されている中、この60分間を私たちのために割いていただき、誠にありがとうございます。先ほど申し上げた通り、私は皆様の休憩時間の前に立っておりますので、もう席を立たれている方もいらっしゃいますね。ですが、その前に最後にお願いがございます。私たちは定期的にこのようなプレゼンテーションを行っており、実験と同様に改善を重ねていきたいと考えています。アプリ内にフィードバック機能がありますので、良いフィードバック、改善点、建設的なご意見など、いただければ幸いです。これは今後のプレゼンテーションの改善に大変役立ちます。重ねて御礼申し上げます。この後15-20分ほどこの部屋におりますので、ご質問などございましたら、お気軽にお声がけください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion