re:Invent 2024: AWSが語るイノベーションのスケーリング戦略
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Building core capabilities: The secret to innovation at scale (SEG206)
この動画では、AWSのWorldwide Digital Native Business Product Managementのリーダーを務めるAnne Jude Huntが、イノベーションのスケーリングについて解説します。共有されたCustomer Obsession、最高水準へのこだわり、小規模で自律的なチーム、組織のあらゆる場所からアイデアを促進するメカニズムという4つの原則を軸に、Customer Data Platform(CDP)の活用やTechnical Debtの管理、Working Backwardsなどの具体的な手法を紹介します。特に、McKinseyの調査で71%の消費者がパーソナライズされた体験を期待しているという事実を踏まえ、CDPを活用した顧客理解の重要性や、Amazon Q BusinessなどのAWSサービスを用いたGenerative AIの実装方法について、実践的な知見が共有されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
イノベーションのスケーリング：4つの重要原則
みなさん、こんにちは。re:inventの1日目へようこそ。私たちはテクノロジーのスケーリングについてよく考えます。私が話をする企業のほとんどが、自社のテクノロジーがどのようにスケールするかを気にしています。時には組織のスケーリングについても話し合います。しかし、イノベーション自体をどうスケールするかについては、あまり話題に上りません。考えてみると、これは少し奇妙なことです。なぜなら、企業が成長し、時が経ち、消費者が新しいものを求めるようになる中で、イノベーションを続けていかなければ、それこそが企業の成否を分ける要因となり得るからです。そこで今日は、スケールするイノベーションに焦点を当てていきたいと思います。
もし皆さんが、私たちが「Digitally assertiveな企業」と呼ぶ組織のリーダーであれば、この講演はまさにぴったりです。ここでいうリーダーとは、戦略、組織、製品開発などについて、ある程度の権限を持っている方々のことです。Digitally assertiveな企業は、必ずしもクラウドネイティブである必要はありませんが、顧客のニーズや目的を支援するためにテクノロジーを活用している点が特徴です。これらの企業は新しいテクノロジーを素早く採用し、急速にスケールすることが多いのです。つまり、規模が大きくなり、顧客が増え、より多くのものが必要になり、顧客の期待も高まっていきます。このような企業は、成長とともにイノベーションのスケーリングに真剣に取り組む必要があります。もし小規模なスタートアップや小さなチームにいる方、あるいはキャリアの初期段階でイノベーションのスケーリングについて考える立場にない方は、すぐには多くを得られないかもしれませんが、それでも参加していただき嬉しく思います。
私はAnne Jude Huntと申します。AWSのWorldwide Digital Native Business Product Managementのリーダーを務めています。これは、世界中のDigitally assertiveな企業、特にそのプロダクトリーダーたちと対話を重ねる立場にあるということです。AWSに入社する前は、テクノロジー業界で20年以上の経験を積んできました。その大半はSilicon ValleyやSeattleのWest Coastで過ごしました。90年代後半、今日のAIとは全く異なる時代に、AIの開発者としてキャリアをスタートさせました。その後、エンジニアリングとエンジニアリングマネジメントを経て、最終的にProduct Managementの道に進みました。右側の巨大な熊は、San Franciscoのフェリービル前に設置された像で、私がその前で撮影した写真です。気候変動の影響を人々に意識させるために設置されたものです。私にとってはAmazonのLeadership Principleのお気に入りを思い出させてくれるものです。Amazonに入社して3年になりますが、多くのAmazonianと同様、私にも好きなPrincipleがあります。それは「成功とスケールは大きな責任をもたらす」というものです。このスライドを見ると、私の頭の中が表現されているように見えます。半分がエンジニアリング、半分がProduct Management、そして100%が自分が携わる製品が顧客と世界にとって良いものになることに注力しているということです。
チームとイノベーションのスケーリングについて話し合っていた際、非常に大きなトピックだったため、何らかのフレームワークに分解する必要があると気づきました。そこで私が決めたのは、イノベーションのスケーリングに関する4つのルール、いわば私個人のテネットについて話すことです。これらは主に文化的な性質を持っていますが、Platform capabilitiesにも対応しています。これから、文化的な側面とPlatform capabilities、そしてPlatformを活用したイノベーションのロードマップについて話していきます。これらは皆さんとチームにとって実践的で役立つものになるはずです。Platform capabilityというのは、チームが社内で活用できる機能を構築し、より迅速な開発とイノベーションを推進するための機能のことを指します。
では、ルールを見ていきましょう。まず、共有されたCustomer obsession、より高い基準へのこだわり、小規模で自律的なチーム、そして組織のあらゆる場所からアイデアを促進するメカニズムです。
Customer Obsessionと共有された顧客知識の重要性
これらの役割の間には時として緊張関係が生じることがあります。リーダーとして、こんなことを考えるかもしれません：成長する組織の中でイノベーションをどこからでも生み出せるようにすると、最高水準の基準をどうやって維持できるだろうか？また、小規模な自律的チームが本当に自律的である場合、ビジネス目標の達成をどうやって確実にできるだろうか？これらについては後ほど触れていきますが、このような役割間の緊張関係は、実は重要な意味を持っています。なぜなら、それによって社内で難しい議論ができるようになり、長期的にはビジネスの成果向上につながるからです。
では、共有されたCustomer Obsessionから始めましょう。 当然のことながら、Customer ObsessionはAmazonのLeadership Principlesの一つです。このスライドにAmazonのLeadership Principlesが表示されています。 Amazonでは、組織のどの位置にいても全員がリーダーです。これは、それぞれの担当範囲内でリーダーシップを発揮することを期待されているという意味です。これらのLeadership Principlesは私たち全員に適用されます。Customer Obsessionは左上に記載されており、私にとっては最も重要な原則の一つですが、もちろん、すべての原則が重要です。
Customer Obsessionが共有されているということは、すべてのチームが顧客について共有できる理解と知識を持っているべきということです。これは実践的に考えることができます。誰かに対して「obsessed（夢中）」になるということは、 その人のことを知るということです。誰かに夢中になった経験がある人なら、これが真実だとわかるでしょう - その人についてすべてを知りたくなりますよね。Amazonで私たちがCustomer ObsessionやShared Customer Obsessionについて話すとき、それは実際に顧客を知る方法について話しているのです。皆さんも自問してみてください。自分は顧客のことを知っているだろうか？そして、自分のチームは顧客について自分と同じことを知っているだろうか？
顧客のためのイノベーションを推進する重要なプラットフォーム機能の一つが、共有された顧客知識です。Customer Data Platform（CDPとも呼ばれる）はこれに非常に重要です。もし会社の全員が、共有された顧客インサイトと知識を提供するCDPを基に開発できたらどうでしょう？そうすれば、より迅速に動き、ブランドとの接点全体で一貫した顧客体験を作り出すことができるはずです。
今日の消費者にとって、 パーソナライゼーションや、さらにはハイパーパーソナライゼーションは、もはや大したことではありません。重要で必要なものですが、今では当たり前のことなのです。数年前なら、パーソナライズされた体験を作り出すことは素晴らしいことで、誰もが驚いていました。しかし今では、誰もが自分のことを知っていて、それを示す体験を提供してくれることを期待しています。あるブランドで何かを購入したら、そのことを認識してほしいし、同じものを何度も売り込まれたり、自分のニーズと全く関係のないメッセージを送られたりしたくはありません。McKinseyによると、71%の消費者が企業にパーソナライズされた体験を期待しており、76%がパーソナライズされた体験を提供された場合、コンバージョンする可能性が高くなるとのことです。
消費者やお客様が広告であなたのブランドを目にしてから始まる、エンドツーエンドの旅全体について考えてみましょう。広告をクリックしてウェブページに訪れ、ブランドについて探索を始める時点で、すでにパーソナライズされた体験を提供することができます。製品を探し、レコメンドを受け、配送され、カスタマーサポートに連絡し、知人に製品を推薦するといった、このライフサイクル全体を通じて、よりパーソナライズされた体験を作り出すことができます。これを実現するカギは、カスタマージャーニーの異なる部分に携わる社内の全てのチームが、同じデータにアクセスできるようにすることです。AWS入社前、私が他の企業で働いていた時は、この点で本当に苦労しました。というのも、マーケティングチームは顧客の行動を把握していても、フロントエンドチームはそれを知らなかったり、あるいはフロントエンドチームが把握している情報が他のチームと共有されていなかったりしたからです。
社内のチーム間で、タイムリーで最新の顧客情報が共有されていない場合、消費者が期待し始めている魅力的な機能を実現することは本当に難しくなります。おそらく皆さんは、顧客との自然言語によるインタラクションを実現するために、Generative AIを活用したいと考えているでしょう。その場合も、同じ顧客情報を基盤として構築する必要があります。しかし、もし各チームが顧客について一から情報を集めなければならないとすれば、それは顧客にとって良くない体験になる可能性があるだけでなく、より多くの時間がかかり、イノベーションの大きな障害となってしまいます。
これは旅行業界におけるハイパーパーソナライズされたChatbotの例です。このChatbotは、顧客のロイヤリティステータスを認識し、その嗜好に基づいて商品をレコメンドし、その顧客について把握している情報に基づいてディールや割引を提供します。このようなハイパーパーソナライゼーションは、Chatbotやその他の製品、マーケティングで活用することで、優れた体験を創出し、サポートケースを販売機会に転換し、顧客の長期的な価値を高めることができます。
これは非常にハイレベルな機能アーキテクチャ図です。元々のより複雑な図からアイコンや技術的な詳細を全て取り除き、基本的な部分だけを示しています。この例では、左側から消費者がウェブやソーシャルメディアを通じてインタラクションを行います。その過程で、Customer Data Platformが顧客について学習し、AIシステムが活用できるように情報を保存・処理します。先ほど見たライフサイクル全体を通じて、同じ顧客データを使用してAIを活用したマーケティングキャンペーンを実施し、オムニチャネルでのコミュニケーションを実現することができます。
複数のプロダクトチームが同じ基本機能を使用する状況を想像してみてください。これこそが、プロダクトチームやマーケティングチームのイノベーションを推進するプラットフォーム機能と言えます。活用を検討すべきAWSサービスとしては、Amazon Personalize、AWS Entity Resolution、Amazon Neptune、Amazon SageMaker、Amazon Bedrock、AWS Lake Formation、Amazon S3などがあります。プレゼン後に私に連絡していただくか、担当のAWSアカウントチームに連絡していただければ、より詳細な図をお渡しできます。もちろん、それぞれの状況に合わせてカスタマイズする必要があります。
最高水準へのこだわりとTechnical Debtの管理
お客様への徹底的なこだわりというのは、オンライン上での安全性とセキュリティに配慮することなしには完結しません。社内チームのために、不正検知に関するサービスを構築することで、チームごとに一からその仕組みを作り直す必要がなくなるということもお伝えしたいと思います。その例として、Amazon Fraud Detectorという便利なサービスがあります。ここで重要なのは、フロントエンドチームや新機能・新製品を開発するプロダクトチームが、これらの課題について心配する必要がないということです。なぜなら、それらが社内サービスとして提供されているため、チームは顧客体験の向上と成果の達成に専念できるからです。
次にお話ししたい2つ目の原則は、「最高水準へのこだわり」です。これもAmazonのリーダーシップ原則の1つです。「当然のことです」と申し上げたのは、Amazonが長年にわたって、様々な分野や事業において大規模なイノベーションを実現してきた実績があり、このリーダーシップ原則がその実現を支援してきたと考えているからです。「最高水準へのこだわり」は面白い原則です。なぜなら、一見するとこの原則が大規模なイノベーションを促進するとは思えないかもしれませんが、実際にはそうなのです。
AWSに入社する前の経験から具体例をお話ししたいと思います。私はあるハイパースケールなStartupで働いていました。
そのStartupは、消費者とプロフェッショナルをつなぐマーケットプレイスを提供していたため、独自のCustomer Relationship Management（CRM）システムを構築していました。彼らは収益化につながる取引を促進するため、AIを活用して適切な消費者と適切なプロフェッショナルのマッチングを行っていました。これは非常に成功し、革新的で、Startupは急速に成長しました。その後、同じ分野でデジタル化に積極的な大手企業に買収されましたが、その企業は海外チームが保守・拡張を行う標準的な既製のCRMシステムを使用していました。
自社開発のCRMは全く異なるシステムで、AIがロジックに組み込まれていたため、特別なメンテナンスが必要でした。結果として、フロントエンドチームやAIチームが、モデルや新製品のために特定の顧客情報やデータを取得しようとする際、常にこの2つの異なるシステムのデータを結合する必要が生じ、これが継続的なボトルネックとなりました。さらに、自社開発システムは非常に特殊でモノリシックだったため、複数のチームに分割して作業することができませんでした。1つの小さなチームが1つのシステムを担当し、事実上、会社全体のイノベーションのペースがそのチーム1つの速度に制限されてしまったのです。
これは今後絶対に避けたいことです。この話題について素晴らしい取り組みをしている企業の一つがThoughtworksです。彼らはTechnical Debtについてよく発信しており、素晴らしいブログ記事を書いています。小規模なスタートアップから中規模企業へ、そして急成長期を経て大企業になっていく過程で、Technical Debtの管理がどのように変化していくかについて、彼らの記事を強くお勧めします。企業の成長段階によって、適切なTechnical Debtのレベルは異なります。Technical Debtは必ずしも悪いものではありません。実際、何かを構築して素早く前進する必要がある時には、ある程度のTechnical Debtを抱えることは有益な場合もあります。ただし、ある時点で、異なるタイプのTechnical Debtは返済され、管理される必要があります。そうすることで、革新的な企業であり続けることができるのです。
私はよくビジネスリーダーと話をしますが、彼らはTechnical Debtという話題にとても退屈そうな反応を示します。私の頭脳は半分がエンジニアリング、半分がプロダクトなので、この話題に興奮を覚えます。なぜなら、適切に管理すれば、ビジネスの差別化要因を生み出すことができるからです。ビジネスコストを理解することが重要です。ビジネスコストには、顧客がバグや問題を報告する際の顧客体験の低下から、マネージドサービスを使用できたはずの古いシステムや自社開発システムの維持にかかるコストによる利益の低下まで、すべてが含まれます。CDPやその他のデータシステムでデータを統合できない場合、そのデータを収益化して新しい製品を作る機会を逃してしまいます。さらに重要なのは、優秀なエンジニアやプロダクトマネージャーが、常にTechnical Debtに対処しなければならず、それを修正する機会がないことにフラストレーションを感じ、人材の定着率が低下することです。そして当然ながら、バグの多いソフトウェアを作る企業として知られるようになれば、ブランドの評判にも影響します。
この問題を解決する大きな部分は文化的なものです。ビジネスリーダーと技術リーダーとして、Technical Debtを継続的に管理するための戦略について一緒に考える必要があります。私はよくエンジニアが「このシステム全体を書き直したい、6ヶ月かかります」と言ってくるのを見かけます。
そしてその間、新機能の開発はできないと。その衝動は理解できますが、ビジネスの観点からも顧客の観点からも、それは非常に悪い選択になる可能性があります。状況が本当に深刻な場合は、そうせざるを得ないこともありますが、そうでない場合は、プロダクトチームが異なるタイプのTechnical Debtの影響を理解し、顧客に悪影響を与えているシステムの側面を優先順位付けして、徐々に返済していく継続的なリファクタリングの取り組みを実施すべきです。開発の必要がなくなったシステムのTechnical Debtは、永遠に対処しないかもしれません。
この取り組みの重要な部分は、各チームを顧客成果に合わせることです。そうすることで、Technical Debtの優先順位付けを行う際に、実際に顧客成果に基づいて優先順位付けを行うことができます。 ここで言及すべき重要な側面がいくつかあります。例えば、管理されたロールアウトのためのFeature Flaggingやバージョン管理、冗長なコードやその他の問題を特定するためのGenerative AIツールの使用、そして技術とビジネスの優先順位に関するコラボレーションなどです。Amazon CodeGuru、Amazon CodeWhisperer、AWS Database Migration Serviceなど、いくつかのAmazon AWSサービスを挙げることができます。あまり知られていない事実ですが、AWSのアカウントチームは実際にTechnical Debtを返済するためのロードマップ作成を支援することができます。これはAmazon自身が有名に行ってきたことです。少しGoogle検索をすれば、Amazonが急速な開発を可能にするためにモノリシックなコードベースを持たないようにした方法についてのブログ記事が見つかるでしょう。私たちはこれについて多くの情報を持っており、お客様の会社内での実装をお手伝いすることができます。
小規模な自律型チームによるイノベーションの促進
次に、小規模な自律型チームについてお話しします。皆さんもご存知のConwayの法則では、システム設計は組織設計を反映すると言われています。これは冗談のように言われることもありますが、実際の現象です。組織の在り方がシステム設計に影響を与え、システムの設計が組織に影響を与えるのです。複数のチームが同じソフトウェアシステムに関わっていると、お互いの作業を妨げ合い、不満が生まれ、Technical Debtが増え、最終的にはシステムは組織構造を反映することになります。リーダーとして、組織構造に手を付けずにTechnical Debtの解消やモノリシックなコードベースからの脱却を決めても、うまくいきません。両方を同時に行う必要があります。イノベーションを最適化するには、疎結合なチームと疎結合なソフトウェアシステムを整合させることが重要なのです。
Amazonでは、チームは必ずしも階層的ではありません。つまり、チーム同士が相互に作用し、あるチームが他のチームのAPIを使用する際に、追加の開発を依頼したり、相手のバックログに入れてもらったりする必要がないようにしています。意思決定のボトルネックを生む、トップダウンでのチーム管理は行いません。依存関係を管理するのではなく、減らすことを重視しています。対照的なアプローチとしては、Scaled Agileフレームワークがあります。これは依存関係を管理し、四半期ごとの計画を確実に立てるための大規模なフレームワークです。私の経験では、このアプローチによってチームは特定の成果物に向けて開発を計画するようになり、顧客の成果を追求するのではなく、イノベーションを妨げることになってしまいます。各チームには特定の顧客成果について考える責任があり、後ほど例を挙げますが、チームはその成果を達成するために必要なイノベーションや手段を自由に選択できます。必要な成果を達成するために、必要な技術を自由に使用できるのです。
理想的には、他のチームに許可を求める必要がなければ、素早く実験を行い、顧客について学び、顧客との距離を保ち、階層組織では思いつかなかったようなものを生み出すことができます。つまり、イノベーションは本社ではなく、現場で起こるのです。
チームが顧客に近い存在であるための重要な要素は、チームが開発するシステムのライフサイクル全体を所有していることです。私たちは常に顧客から始め、顧客のニーズから逆算して開発するものを決定します。これは、顧客のビジョンとニーズから始まり、チームが製品の計画と開発を行い、製品ポートフォリオを管理し、他の関連製品や機能との潜在的な競合を処理し、ローンチし、運用し、時間をかけて製品を観察して改善していくということです。何かを試してうまくいくかいかないかを通じて、顧客について学び、顧客との距離を保ち続けます。
Amazonのエンジニアとプロダクトマネージャーのチームと話すと、プロダクトチームだけでなく、エンジニアリングチームも顧客が誰で、どんなニーズがあるかを理解しています。チーム全体が顧客の目標達成に責任を持っており、それはプロダクトチームやマネージャーだけの責任ではありません。このアプローチにより、顧客を支援するための情熱的なイノベーションが生まれるのです。
Customer Data Platformに話を戻して、組織設計についてお話しします。消費者データを管理する1つまたは複数のチームがあり、私たちはそれらのチームをプロダクトチームとして考えています。彼らは他のチームが使用するためのプロダクトとしてデータを作成しているのです。彼らの顧客は社内チームであり、社内チームがそのデータを使いやすくするというプロダクトの成果を目指しています。例えば、社内チームが不適切な方法でデータを公開することなく、安全に実験できるようにすることなどです。これは消費者データチームの責任となります。
フロントエンドチームは、顧客がスムーズにオンボーディングできる、製品使用開始から1時間以内に価値を実感できるといった顧客成果を持つかもしれません。マーケティングチームは、顧客がジャーニー全体を通じて関連性の高いマーケティング情報を受け取るという目標を持つかもしれません。そして、同じ消費者データを扱うAIチームは、他のチームが使用できる正確でリアルタイムなインサイトを生み出すことを目指すでしょう。このように、これらのチームは同じ顧客データに対してほぼ独立して作業することができ、組織設計はシステム設計に従って、小規模なチームが小規模なシステムで作業を行うことができます。
こちらは、サービスとしての会話型チャットボットを示す、もう1つの高レベルな機能アーキテクチャ図です。多くの企業が顧客に会話型チャットボットとの対話を望んでおり、これは現在非常に人気があります。これは、検索アプリケーションの体験の中でRAG（Retrieval Augmented Generation）を使用した生成AIパワードのチャットボットを実装するためのパターンです。フロントエンドチームの1つが、消費者が対話する検索アプリを作成し、チャットボットを実装することができます。チャットボットはIdentity Centerにアクセスして、顧客が誰であり、どのようなデータを閲覧する権限を持っているかを知ることができます。
プラグインは、チャットボットに異なるタイプのデータや異なるデータソースを提供することができます。このように実装することで、より多くのフロントエンドチームを立ち上げることができ、それらは全て同じチャットボットを異なる方法で使用することができます。製品の異なる部分で顧客に一貫した体験を提供するために、チャットボットを公開している全てのプロダクトチームがどのように確実に対応できるかについて、多くのチームから質問を受けてきましたが、それはこのようなアプローチになります。いつものように、RAGで使用できるLLMベースのチャットボットを提供するAmazon Q Businessのような、ローコードソリューションのAWSサービスをリストアップしています。これは、AMI、AWS IAM Identity Center、Amazon API Gateway、Amazon CloudFrontなどと共に確認する価値があります。これらのサービスは、次の例で見るように実際のシナリオで適用できます。
あらゆる場所からアイデアを促進するメカニズム
こちらが実例です。 これは私が関わっているAWSのお客様であるBoldinというスタートアップです。彼らは、消費者が直接自分の退職プランを設定できる形か、企業向けにホワイトラベル化できる形で退職プランニングを提供しています。彼らは、チャットボットの例と非常によく似た方法で、AIを活用した財務予測エンジンを作成し、フロントエンドのプロダクトチームがそれと対話できるようにすることで、一貫した体験と正確な体験を提供しています。
Chief Data Architectから印象的な言葉をいただきました。「フロントエンドチームは、財務予測エンジンに新しい開発を依頼することなく、新機能を作成できる」と。これは各チームが独立して動けるようにするための重要なポイントです。 AWSで3年間、世界中のお客様と仕事をしてきましたが、誰もが Generative AIのパワーを認識しており、ほとんどの企業が何らかの形で Generative AIを活用した顧客体験の構築・展開に取り組んでいると言えます。
多くの人がLLM自体に注目しがちですが、それは氷山の一角に過ぎません。 まず重要な基盤として、データを適切に整備する必要があります。すでにCDP、Data as a Product、ガバナンス、そして様々なタイプのコンプライアンス保護についてお話ししましたが、これらは内部チームが迅速にイノベーションを起こすためのプロダクトとして機能します。 このようなデータ基盤とGenerative AI機能をプラットフォーム機能として各チームが活用できるようにすることで、小規模な自律チームがエッジでイノベーションを起こすことが可能になります。チームとアーキテクチャの一貫性、API-driven設計、Data as a Product、そしてAIを活用した機能もプロダクトとして考えることが重要です。
イノベーションに関する最後の原則として、あらゆる場所からアイデアを促進するメカニズムについてお話ししたいと思います。 メカニズムとは、Amazonで使用している特別な言葉で、完全に再現可能なプロセスを指します。科学的手法をメカニズムの一例として考えることができます - これは再現可能なプロセスです。ある科学者が実験を行えば、他の科学者も同じ実験を行って同じ結果を得ることができます。メカニズムには、明確に定義された入力と出力、ツール、オンボーディング資料を通じてチームが採用できる方法、そして全員がプロセスを確認してフィードバックを提供し、時間とともに改善できる方法が含まれています。
数千人、数十万人以上の従業員を抱える企業では、新しく採用された従業員や新しく立ち上げられたチームが毎回一からやり直す必要がないことが非常に重要です。全員が行わなければならない特定のタスクに対してメカニズムを持っている方がはるかに効率的です。そのため、私たちは多くの時間をかけてメカニズムを設計し、他のチームが使えるようにしています。 イノベーションのためのメカニズムの1つ - 私たちはエッジでのイノベーションを本当に重視しています - それがWorking Backwardsです。これは顧客を中心に置くところから始まります。顧客が誰で、何を必要としているのか、そしてその需要に対する潜在的な解決策をプレスリリースの形で記述します。プレスリリースの形式を採用している理由は、実装やシステムの内部的な詳細について一切触れないようにするためです。プレスリリースには、顧客は誰か、どのように使用できるのか、どのようなメリットが得られるのかといった内容だけが記載されます。プレスリリースを作成した後、FAQセクションを追加して、具体的な動作方法や視覚的な要素を含めることで、新しいソリューションをより明確にイメージできるようにします。これは生きた文書なのです。このメカニズムの仕組みは、
Amazonに新しく入社して本社から遠く離れた場所に住んでいる人でも、特定の顧客グループを助けるための素晴らしいアイデアがあれば、プレスリリースを書き、FAQや視覚資料を作成することができます。そのアイデアを自分のマネージャーや上位のマネージャー、世界中の関係者やチームメンバーに共有してフィードバックを得ることができます。また、モックアップを顧客に見せたり、顧客と対話したりしながら顧客調査を行い、このファクトを発展させていく必要があります。
最終的に、パイロットプロジェクトや小規模な投資を通じて指標が得られるようになると、リーダーシップからスケールアップのための投資を受けられるようになります。私は実際に自分のチームのメンバーが、約2年半前にFAQ形式のPR FAQドキュメントとして始めたアイデアを、パイロット実施して投資を受け、最終的にCEOにまで話を通して、今では世界規模のプログラムにまで成長させた例を見てきました。もちろん、すべてのアイデアがこのような道をたどれるわけではありませんが、社員なら誰でも自分のソリューションのアイデアを提案し、テストし、実現可能性を確認できる具体的な方法があるのです。このような仕組みがあることで、時間とともに忘れ去られてしまうかもしれない素晴らしいアイデアを多く発掘することができます。
Working Backwardsのプロセスについては誰もが知っています - Amazonのworking backwardsについてオンラインで検索すれば、たくさんの情報が見つかるはずです。しかし社内では、これらの実験を加速するためのスタートアップのような資金調達の方法があります。これは非常に重要なポイントです。なぜなら、まずアイデアを書き出してテストしますが、その後、適切なものに投資して成長させる仕組みが必要だからです。これにより、世界中の人々に良い影響を与えるような大きな発想のアイデアを生み出すことができるのです。
AWSに入社する前、私が働いていた会社では、チームをより革新的にするにはどうすればいいか、ハックデーやハッカソンを開催すべきかといった議論が絶えませんでした。最大の問題は、仕組みがなかったことです。アイデアはたくさんあり、ハッカソンも開催していましたが、ハッカソン後にアイデアへの投資を確保し、実際の製品に作り上げる仕組みがありませんでした。すべてがその場限りでした。 Jeff Bezosが言うように、これらすべての結果は不確実なものですが、実験の方法さえ見つかれば、より多くの賭けができるのです。重要なのは実験のコストを下げることです。 彼は、Web Labという常に実験を行っているグループについて言及しました。
これは2007年のHarvard Business Reviewのインタビューからの引用です。それ以来、Web Labはもはや単なるグループではなく、プラットフォーム機能と呼ぶべきものになっています。なぜなら、何千人もの人々が、お互いの邪魔をしたり、顧客体験を損なったりすることなく、毎年何千もの実験を実行でき、スケールで意思決定に必要な適切な情報を得ることができるからです。 カスタマーディスカバリーと実験について考えるとき、私は常にチームに2つの重要な側面があると伝えています。1つは定性的または逸話的なもので、実際の顧客と話をして彼らが何を言っているのかを知ることです。もう1つは大規模なA/Bテストまたは多変量テストです。これら2つを組み合わせることで、顧客のニーズと、どのようなソリューションが彼らにとって効果的かを理解する強力な方法が得られます。
下部に、Split、LaunchDarkly、UserTestingといった私たちのパートナー企業をいくつか挙げていますが、これらは社内チームが利用できるプラットフォーム機能として追加すると非常に有用な異なる機能を提供しています。革新的なアイデアを促進するメカニズムを考えて、その場限りにならないようにしましょう。チームが顧客と対話し、定性的な発見のための会話ができる仕組みを作り、可能であればセルフサービス機能を作成してください。
イノベーションのスケーリングを実践するための具体的アプローチ
プラットフォームにおいて、大規模なセルフサービス実験の機能を構築してください。 今、私が話してきたすべてのルールと、説明したすべての機能をマッピングして1枚のスライドにまとめました。共有された Customer Obsession、CDPのデータをプロダクトとして考える、最高水準へのこだわり。システムにおける継続的なリファクタリング、モジュール化された拡張可能な設計を考え、ビジネス面と技術面が一体となってその重要性を理解する継続的なリファクタリングを行います。自律的なチームは、API駆動の設計、モジュール化された一貫性のあるアーキテクチャ、最新のデータアーキテクチャガバナンス、そしてあらゆる場所からアイデアを促進するメカニズム、カスタマーディスカバリーのメカニズムによってサポートされます。これらの一部は実際にプラットフォームの機能としても活用できます。そして、セルフサービスの実験です。
残り数分で、皆さんがチームに戻って、これらを実際にどのように実装・実行するかを決める際に私ならどうするかについてお話しします。 私はいつもデータから始めます。Customer Data Platformはありますか？そして、社内チームに向けてデータをプロダクトとして扱っていますか？最高水準という観点では、問題のあるシステムを探します。以前、私がProduct Leaderを務めていた企業で実際にやったことですが、カスタマーサポートと一緒に座って（これは複数の企業で行いました）、カスタマーサポートの通話を聞き、顧客が何を訴えているのか、報告されたバグを確認してパターンを探しました。プラットフォームのどの部分が問題を抱えていて、誰にとっても課題となっているのかを示す、驚くべきパターンを見つけることができます。
問題のあるシステムを見つけ、チームが継続的なリファクタリングを優先できるよう支援し、顧客の成果につながるような方向でリファクタリングを行います。つまり、他の作業と同様にこの作業も優先順位付けを行い、マネージドサービスなどを使用するCloud Nativeアーキテクチャも導入して、運用作業に時間を取られないようにします。これらの取り組みを始め、問題のあるシステムを見つけてリファクタリングが必要だと考え始めたら、システム構造に合わせて組織構造を変更することを検討してください。これは難しいことは分かっていますが、小規模な自律的なチームを作り、チームとアーキテクチャの一貫性を確保できれば、スケールに応じてより多くのイノベーションを推進でき、特定の規模でボトルネックが発生することもなくなります。最後に、Experimentationプラットフォームと、それに付随するメカニズムが本当に重要です。
皆さん一人一人が、このトークの後に私に連絡を取っていただけたら嬉しいです。LinkedInでつながるでも、メールを送っていただくでも、どちらでも構いません。チームが取り組んでいることについて話し合うのが大好きですし、皆さんのご意見や、より良くするためのフィードバック、異なる見解なども、ぜひお聞かせいただければと思います。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion