※本記事は、AWS re:Invent 2024で開催されたセッション「Reimagining IT: From cost center to innovative product builder (INO109)」の内容を基に作成されています。登壇者はCeileidh Siegel氏、Fatima Howes氏、Ben Micheel氏です。セッションでは、Amazonのプロダクト管理アプローチや、ITをコストセンターからプロダクトビルダーへと変革する方法について解説されています。本記事では、セッションの内容を要約・構造化しておりますが、原著作者の見解を正確に反映するよう努めています。より詳細な情報については、オリジナルの動画（https://www.youtube.com/watch?v=hVYVcjaFi5M ）をご覧いただくことをお勧めいたします。AWS re:Inventの詳細は https://go.aws/reinvent でご確認いただけます。また、その他のAWSイベント情報は https://go.aws/3kss9CP でご覧いただけます。
1. イントロダクション
1.1. 登壇者紹介（Ceileidh Siegel, Fatima Howes, Ben Micheel）
- Ceileidh Siegel: Head of Americas, Innovation and Transformation Deliveryというタイトルを持っていますが、彼女自身の説明によれば「Amazonのツールボックスを持ったプロフェッショナルなブレインストーマー」という役割を担っています。
- Fatima Howes: Bridgestoneのフリート管理ソリューションにおけるProduct Designの副社長（VP）を務めています。スタートアップのバックグラウンドを持ち、Bridgestoneでの規模拡大とビジョン実現に取り組んでいます。
- Ben Micheel: Ceileidhと同様にイノベーショントランスフォーメーションプログラムに携わっており、冗談交じりに「Ceileidhほど上手くはないが、同じような仕事をしている」と自己紹介しています。自分の声がデザート（ラスベガス）での数日間で枯れていることに触れ、ユーモアを交えながらプレゼンテーションを進行しています。
1.2. セッションの概要と参加者の背景確認
Ben：このセッションでは、「Reimagining IT: From cost center to innovative product build partner（ITの再定義：コストセンターから革新的なプロダクト構築パートナーへ）」というテーマでお話しします。まず始めに、会場の皆さんがどのような立場でいらっしゃるか把握したいと思います。エンジニアリング組織に所属している方は手を挙げていただけますか？
[会場の約半数が手を挙げる]
Ben：素晴らしい、約半数ですね。では、プロダクト関連の機能に携わっている方は？もし両方に当てはまる場合は、二度手を挙げていただいても構いません。
[会場の一部が手を挙げる]
Ben：次に、UXやカスタマーエクスペリエンス関連の方々は？
[会場の一部が手を挙げる]
Ben：最後に、分析、オペレーションなど、その他のサポート機能に関わる方々は？
[会場の一部が手を挙げる]
Ben：皆さんにお越しいただき嬉しく思います。もう一つ質問させてください。今日の内容についてお話しする前に、過去3年間で「トランスフォーメーション」という言葉が入ったプロジェクトに参加された方は手を挙げてください。デジタルトランスフォーメーション、アジャイルトランスフォーメーション、カスタマー何とかなど…
[多くの参加者が手を挙げる]
Ben：手を挙げたままでお願いします。そのトランスフォーメーションから期待していた結果が得られた方は？
[ほとんどの手が下がる]
Ben：これは良いニュースです。Ceileidhと私はまだしばらく雇用が続きそうですね。なぜなら、私たちはこの問題についてお手伝いできると思いますが、それは確かに難しいことです。
Ben：今日のセッションでは、まず最初の5〜10分で私が「何について話しているのか」というレベル設定をします。Amazonの企業全体のプロダクトマネジメントアプローチについてお話しします。これが唯一の方法や最良の方法だと言うつもりはありません。単に私たちのやり方です。プロダクトマネジメントが確立された科学ではなく、物理学のようなものではないという点が好きです。合理的な人々が意見の相違を持つことができますが、アプローチを持つことは重要です。
Ben：次にCeileidhがAmazonのイノベーション方法や、テストと学習のアプローチ、顧客から逆算する作業などについて説明します。最後に、Fatimaが顧客としての立場から実際に行ったことと、そこから得られた素晴らしい結果について説明します。
2. Amazonのプロダクト管理アプローチ
2.1. イノベーション文化と顧客中心主義
Ben：プロダクト管理アプローチについて話す前に、ジェフ・ベゾスの写真を見せるたびに1ドルもらえるので、ご協力ありがとうございます。私も会社の髪型をしているので、二重に勝っていますね。
Ben：Amazonのプロダクト管理アプローチは、それ自体が孤立したサイロにあるわけではありません。それはすべてのAmazonのビジネスユニットに共通するイノベーション文化の上に成り立っています。そして、私たちのアプローチは顧客とそのニーズにアンカーしています。これは2016年の株主レターから来ています。
Ben：その理由は、顧客が常に美しく、素晴らしく不満を持っているからです。これは顧客を喜ばせ、インスピレーションを与え、問題を解決しようとする永続的なモチベーションとなります。イノベーションやプロダクト開発には他の方法もあります。技術を前面に押し出す方法、ビジネスモデルイノベーション、財務エンジニアリング、競合他社を見て真似するなど。これらのことに対して判断を下すつもりはありませんが、私たちのプロダクト管理アプローチは、一貫して、そして唯一、常に顧客から逆算する方法に基づいていることを明言しておきます。
Ben：私たちが行っている2つ目のことは、各ビジネスのための成長フライホイールの構築に多くの焦点を当てていることです。イノベーションやプロダクト管理に携わっているとき、将来について考えるのはとても魅力的です。「15年後、AIがこれらすべてをどのように変えるのか」「何が違ってくるのか」など。それはクールで楽しいことで、私たちもそうしますが、実際にはその逆のことをもっと頻繁に行っています。
Ben：私たちは「永続的なニーズ」と考えるものに焦点を当てています。15年後に何が変わらないか、それが顧客を喜ばせるために重要なことは何かを考えるのです。小売業では、それは価格、選択肢、そして利便性です。顧客が「Amazonが大好きだけど、すべてをもう少し高価にしてくれる？あるいは購入をもっと難しくしてくれる？あるいは品揃えを減らしてくれる？」と言ってくることは決してありません。それは絶対に起こりえないことです。
Ben：だから、私たちがイノベーションやプロダクト管理を行うとき、何もないところに向かって行うわけではありません。様々なことに対してテストや学習を行うわけではなく、意図的にこれらの永続的なニーズにテストと学習を行っているのです。これらは時間が経っても変わらないことを私たちは知っています。
2.2. 成長フライホイールと永続的なニーズへの注力
Ben：私たちのアプローチは大きく分けて3つのバケットに分類できます。これは非常に短いセッションで大きなトピックを扱うため、簡潔に説明します。もしこのトピックに興味があれば、アカウントマネージャーに連絡するか、私に直接連絡してください。このトピックについてより長いセッションを実施することもできます。
Ben：広く言って、3つのバケットとは、まず「製品をどのように考えるか」、つまり製品とは何かという点です。次に「それに対してどのように組織化するか」。最後に「スピードのためにどのようにイノベーションを起こすか」です。
Ben：質問ですが、PRIMEの会員である方は手を挙げてもらえますか？たくさんいらっしゃいますね。ビジネスへのご支援ありがとうございます。通常であれば、なぜPRIMEを利用しているのか聞きたいところですが、この設定では少し難しいので、「迅速な配送」「無料配送」「荷物の追跡機能」「木曜の夜のフットボール視聴」などの理由を想定しています。
Ben：PRIMEをAmazonのプロダクトイノベーションの例として紹介したい理由がいくつかあります。まず、良い意図を持った経営幹部がよく求めるのはロードマップです。ロードマップは確かに有用ですが、将来の詳細を細かく定めすぎると危険です。Amazonでは「ビジョンには固執し、詳細には柔軟であれ」と考えています。逆に「ビジョンには柔軟で、詳細には固執する」状況に陥るのは避けたいのです。
Ben：考えてみてください。2000年にPRIMEのプロダクトマネージャーだったとします。当時は100ドル以上の注文で無料配送（Super Saver Shipping）を提供し始めたばかり。これは当時としては非常に先進的な5〜8日間の配送でした。これは顧客体験と顧客の期待が常に一方向にしか進まないことの例証です。
Ben：2015年に人々がTwitchというサービスで他の人々がビデオゲームをプレイするのを見始め、それが非常に価値あるものになることを2000年の時点で知ることはできなかったでしょう。しかし、顧客の声を聞き、彼らのために発明し続けることで、それらを組み込むほど十分に柔軟性を持ち続ける必要がありました。
Ben：ジェフが言うように、「PRIMEは、あなたがそれを購入しないことが無責任であるほど良い価値を提供する」ことを目指しています。これが、プロジェクト中心の運用モデルではなく、プロダクト運用モデルのパワーの核心です。Ceileidhがこれについてもう少し詳しく話しますので、詳細には立ち入りませんが、「なぜそれがより良いのか」という質問を受けることがあります。繰り返しますが、それを行うには様々な方法がありますので、これが唯一の方法だとは言いません。
2.3. PRIMEの事例：ビジョンへの固執と詳細への柔軟性
Ben：私たちがこのアプローチを重視する理由をお話しします。私たちにとって、プロダクトチームはより迅速な意思決定を意味します。スピードは私たちの文化の非常に重要な要素です。高品質かつ高速度の意思決定が重要なのです。多くの企業は高品質の意思決定は得意ですが、高品質で高速度の意思決定ができる企業は少なく、ビジネスにおいてスピードが重要だと考えています。
Ben：プロダクトチームによって意思決定が速くなります。それらの意思決定によって、より多くの実験と反復が可能になります。それは、私たちが他の誰よりも速く顧客のニーズについて賢くなることを意味します。少なくとも私たちはそれを目指しています。その知識は差別化された製品に反映され、最終的にその差別化がビジネス価値を生み出します。
Ben：PRIMEの例が示すように、私たちは「これがAmazonにとって良い理由は何か」「ROIは何か」「達成しようとしている粗利益は何か」といった質問から始めませんでした。私たちはそれらの質問もしますが、それはプロセスの最初ではなく、ずっと後の段階です。
Ben：PRIMEは2000年の「Super Saver Shipping」から始まり、その後徐々に進化してきました。2000年のプロダクトマネージャーは、2015年に人々がTwitchで他の人々のゲームプレイを視聴し始めることや、それが価値あるものになることを予測できなかったでしょう。しかし、顧客の声を聞き、彼らのために発明し続けることで、これらの新しい価値を柔軟に取り入れることができました。
Ben：このアプローチは、PRIMEをただの配送サービスから、デジタルコンテンツ、ショッピング特典、エンターテイメントなど、多様なサービスを含む包括的な会員プログラムへと進化させました。この進化は事前に詳細な計画があったわけではなく、顧客ニーズに対する継続的な理解と、「PRIMEをとても価値あるものにして、購入しないことが無責任に思えるようにする」というビジョンへの固執があったからこそ可能になりました。
3. プロダクト vs プロジェクト思考
3.1. プロダクトチームがより速い意思決定をもたらす理由
Ben：プロジェクト思考よりプロダクト思考を優先する理由を考えてみましょう。そして、皆さんがこのスペクトルのどこに位置しているか自問してみてください。伝統的には「ビジネス」と呼ばれるものがあり、それが何を意味するのかまだ把握しようとしているところです。テクノロジーにいる人もまた「ビジネス」の一部だからです。特別な「ビジネス部門」はないのです。
Ben：しかし伝統的には、ビジネスはROIなどに焦点を当て、それが意味するところは、5年先の機能を信じられないほど詳細に特定しようとする非常に長いビジネスケースということがあります。それをテクノロジー組織にフェンス越しに投げ、テクノロジー組織はそれからプロジェクトを作り出し、彼らの成功指標は「期限通り、予算内、スコープ通り」になります。
Ben：認めたくはありませんが、これは安全な場所に感じるので告白します。私が見てきたプロジェクトの中で、実際に顧客やビジネスの成果を全く生み出さなかったものが数多くありますが、期限通り、予算内、スコープ通りだったため、そのまま続けられたのです。これはAmazonでのことではなく、以前の職場や他の顧客で見てきたことですが、それがその危険性です。
Ben：本当に大切なのは、アウトプットよりもアウトカムです。だから私たちは右側のモデルに近づくよう努めています。このモデルでは、ビジネスとテクノロジーが共に働き、ビジネスは少しドメインエキスパートまたは顧客にもっと焦点を当てますが、顧客を「所有」しているわけではありません。全員が顧客について考える必要があります。そして、テクノロジーの専門家は少しスピードと俊敏性、実行方法に焦点を当てます。
Ben：これがプロダクトとして一緒になり、私たちが気にかけるのは顧客成果の加速だけです。これが私たちが運営しようとしている基本的なメンタルモデルです。
3.2. ビジネスとテクノロジーの統合について
Ben：伝統的なモデルでは、「ビジネス」と「テクノロジー」が分離されていました。「ビジネス」側は主にROIなどに焦点を当て、何年も先の機能を非常に詳細に特定しようとする長大なビジネスケースを作成します。そして、それをテクノロジー組織に投げ渡すのです。テクノロジー組織はそれをプロジェクトに変換し、「期限通り、予算内、スコープ通り」という指標で成功を測定します。
Ben：私が過去に目撃した最も問題のあるケースは、顧客やビジネスの成果を全く生み出さなかったにもかかわらず、単に「期限通り、予算内、スコープ通り」だったというだけで継続されたプロジェクトでした。これこそが、プロジェクト思考の大きな危険性です。
Ben：私たちが目指すモデルは、ビジネスとテクノロジーが一体となって働くものです。このモデルでは、ビジネス側は顧客やドメインの専門知識に焦点を当てますが、顧客を「所有」しているわけではありません。全員が顧客について考える必要があるのです。一方、テクノロジーの専門家はスピード、俊敏性、実装方法に焦点を当てます。
Ben：これらが一つのプロダクトとして統合され、私たちが唯一気にかけるのは「顧客成果の加速」だけです。つまり、「何を作るか」と「どのように作るか」の分離ではなく、共通の目標に向かって協力する統合されたアプローチなのです。ビジネスとテクノロジーの壁を取り払い、全員が顧客価値の創造という同じ目標に向かって働くことで、より革新的で顧客中心のソリューションが生まれます。
3.3. 「Two Pizza Team」の重要性と通信オーバーヘッドの課題
Ben：Two Pizza Teamについて詳しく説明しすぎることはありませんが、小規模なクロスファンクショナルチームが製品を最初から最後まで所有するというこの考え方は非常に重要です。多くの人々は、スタートアップがそうしているからこれがクールなことだと思っているかもしれませんが、それはそれでいいでしょう。しかし、これが本当に上手く機能する理由はいくつかあります。
Ben：私の好きな理由の一つはコミュニケーションのオーバーヘッドです。大きなチームによって生じるコミュニケーションのオーバーヘッドについて考えてみてください。数学的に傾向のある方なら計算できますが、6人のチームには彼ら自身の間に15の固有のコミュニケーションノードがあります。6人から12人に倍増すると、ノードの数は倍になるのではなく、約6倍になり、66のノードになります。
Ben：そして50人程度の小さなチームになると、1200以上のノードになります。どんなチームもそれを自然にこなすことはできません。結果として、多くのオーバーヘッド、コミュニケーション、ミーティングについてのミーティング、状況アップデートなどが発生してしまいます。
Ben：これが、なぜ私たちが少人数のクロスファンクショナルチームを重視するのかの核心です。小さなチームでは、コミュニケーションが直接的で効率的になり、意思決定が迅速になります。より大きなチームでは、単にコミュニケーションの複雑さが指数関数的に増加し、実際の成果物よりもコミュニケーション自体の管理に多くの時間を費やすことになってしまうのです。
4. チーム構成とクロスファンクショナルな組織
4.1. デジタルウィジェットチームの例
Ben：では、これらのチームが実際にどのような形になるのかをお見せしましょう。これはamazon.comのデジタルウィジェットチームの具体例です。例えば、.comホームページのプロモーションカートリッジを担当する人々です。
Ben：私たちのチームの基本構造は、どのドメインにいても基本的に同じです。この例では、プロダクトマネージャーがいます。ちなみに、私たちにはプロダクトオーナーという役職はありません。多くの企業では、戦略担当のプロダクトマネージャーとJira担当のプロダクトオーナーという区別がありますが、私たちは戦略と運用、開発の間にそのような人為的な区別を信じていません。ですから、私たちにはプロダクトマネージャーという一つの役割だけがあります。
Ben：この例では、UXデザイナーがチームにいます。そして、その環境でエンジニアリングができるために必要なスキルを持つ特定の技術専門家がいます。例えば、フロントエンドデベロッパー、バックエンドデベロッパーなどです。
Ben：このチームは一つの目的に集中し、スピード、品質、そして顧客体験の向上を実現します。各メンバーは明確な責任を持ちながらも、全体のプロダクト成功に向けて密接に協力します。この構造が効果的なのは、各メンバーが自分の専門知識を活かしながらも、全員が同じ顧客価値を中心に結束しているからです。
4.2. 機械学習チームの例
Ben：機械学習により焦点を当てたチームに変更した場合、例えばそれらのウィジェットチームが使用する機械学習アルゴリズムを構築する内部チームでは、スライドの内容をほとんど変更していません。説明の一部以外は変わっていないのです。
Ben：フレームワークは同じです。プロダクトマネージャーはまだそこにいます。UXデザイナーの代わりに研究者がいます。フロントエンドデベロッパーの代わりに、データサイエンティスト、データエンジニア、MLプラットフォームエンジニアなどがいます。
Ben：つまり、チームの基本構造は変わらず、プロダクトマネージャーを中心にして特定のドメインに必要な専門知識を持つメンバーを配置するというアプローチです。機械学習の場合、顧客向けのインターフェースよりもアルゴリズムやデータ処理に焦点が当たりますが、プロダクト開発の原則は同じです。
Ben：重要なのは、どんなドメインであっても、クロスファンクショナルなチーム構成とプロダクト中心のアプローチが維持されるということです。技術スタックや専門知識は変わるかもしれませんが、顧客価値の創造を中心に置いた小規模で密接に連携するチームという核心的な考え方は変わりません。
4.3. シングルスレッド・オーナーシップの重要性
Ben：私たちはプロダクトを最初から最後まで分解し、特定の顧客目的のためにクロスファンクショナルなチームが協力する体制を整えました。では、実際に何に取り組むかをどのように決定するのでしょうか。
Ben：Amazonでは、イノベーションのメカニズムとして「Working Backwards（顧客から逆算する）」を採用しています。Amazonにおいてイノベーションのメカニズムはこれ以外にありません。小規模、中規模、大規模、あるいは超大規模なものを構築したい場合でも、ここから始めます。他の方法はありません。
Ben：この中核となるのが「シングルスレッド・オーナーシップ」の概念です。私たちの各プロダクトチームには、一人の明確なオーナーがいます。この人物がプロダクトの方向性と成功に対して責任を持ちます。これにより、意思決定が明確になり、優先順位付けが容易になります。
Ben：シングルスレッド・オーナーは、複数の優先事項や利害関係者の間で引き裂かれるのではなく、特定のプロダクトや顧客体験に完全に集中できます。この集中力が迅速なイノベーションと顧客中心の意思決定を可能にします。
Ben：シングルスレッド・オーナーシップがなければ、責任の分散や意思決定の遅延が起こりがちです。「みんなの責任」は実質的に「誰の責任でもない」ことになりかねません。明確なオーナーシップがあることで、チームは目標に向かって団結し、真の顧客価値を迅速に提供することができるのです。
5. 顧客起点のイノベーション手法
5.1. 「Working Backwards」アプローチ
Ben：私たちはナラティブ（物語）重視の文化を持っています。多くの文書を読み、これらの文書は当社のプロダクト管理ライフサイクル全体で非常に重要です。当然のことながら、私たちは顧客から始めて逆算します。
Ben：「Working Backwards（顧客から逆算する）」はAmazonのイノベーションのメカニズムです。他のメカニズムはありません。小規模なものから超大規模なものまで、何かを構築したい場合は、ここから始めるしかありません。
Ben：このアプローチには3つの構成要素があり、これは単に既に行いたいことを逆エンジニアリングするものではなく、顧客に立ち返って適切な質問をすることが重要であることを理解する必要があります。
Ben：このWorking Backwardsプロセスの美しさは、コードを一行も書く前に、私たちが何を作ろうとしているのか、なぜそれを作るのかについてチームとして深く議論することを強制する点です。これにより、実際の開発が始まる前に、顧客のニーズと価値提案が明確になります。
Ben：私たちは記者発表を書いてから製品を作ります。多くの企業はその逆で、まず製品を作り、マーケティング部門にそれについてのプレスリリースを書かせます。私たちのアプローチでは、顧客の視点から始め、その体験を中心に考えることで、真に価値のある製品を作ることができるのです。
5.2. 5つの顧客質問とその重要性
Ben：これらの文書を書く前に、私たちが「5つの顧客質問」と呼ぶものを問いかけます。少し挑発的あるいはインスピレーションを与えるだけでなく、明日にでも試せる実践的なことをいくつか提供するという目標も持っています。そしてこれはそのような事の一つです。次回誰かがあなたに何かを作るよう頼んだら、残りは忘れて最初の質問だけをしてください。
Ben：最初の質問は「顧客は誰で、彼らについてどのような洞察を持っているか？」です。もし彼らがこの質問に答えられなければ、そのものを作らないでください。私の経験では、彼らがこの質問にどれだけ詳細に答えられるかによって、問題についてどれだけ考えたか、そしておそらくそのアイデアがどれだけ良いかが非常に直接的に関連しています。
Ben：ですから、私たちはこれらの文書を書く前に、この5つの質問に答えようとします。もし答えられなければ、それらに答えるための情報を取得しに行きます。そして時には、これらの質問に答えた後で「このアイデアについて当初思っていたほど熱心ではない」と判断することもあります。その場合は別のことを試してみましょう。
Ben：これは非常に倹約的なイノベーション方法です。たくさんのものを作ってからフェンス越しに投げて、マーケティング部門にそれについてプレスリリースを書かせるのではなく、実際にはプレスリリースから始めるのです。これはそのような方法で非常に役立ちます。
Ben：この顧客質問アプローチの力は、私たちが明確な意図を持ってイノベーションを進められることにあります。「作って、それから理由を考える」のではなく、「なぜ作るのか、誰のために作るのか」から始めるのです。これにより、無駄な開発を避け、真に価値のあるソリューションに集中することができます。
5.3. PRFAQ（Press Release and FAQ）の作成プロセス
Ben：では、これらの文書とは何でしょうか？プレスリリース、FAQ、ビジュアルの3つです。プレスリリースは単に1ページの文書で、顧客が誰か、彼らの痛点は何か、解決策は何か、顧客体験はどのようなものかについて語ります。リーダーの引用、顧客の引用、そしてアクションへの呼びかけがあり、すべて1ページにまとめられています。
Ben：これは本当に難しいことです。ヘミングウェイの言葉だと思いますが、「短い手紙を書く時間がなかったので、長い手紙を書いた」というものがあります。これがまさにそれです。チームとして「何をしようとしているのか、なぜそれをするのか」について議論し、コードを一行も書く前に反復することを強制するのです。
Ben：ROIや誰が構築するか、なぜこれが私たちにとって良いことなのか、戦略的ロードマップにどのように適合するのか、どのテクノロジーを使用するのかなど、他のすべてのことも大切ですが、これらの質問を早すぎる段階で問うと、イノベーションをすぐに殺してしまいます。あなたのアイデアは基本的なレベルを超えることはないでしょう。
Ben：そのため、これらすべてはFAQに入ります。これはその段階でデファクトのプロダクトバックログとして機能します。顧客FAQがあり、顧客を定義しています。顧客を明確に定義せずに構築されるものの数に驚くことでしょう。少し怖いことです。
Ben：顧客側の内容は「これはどのように使用するのか？」「問題があった場合はどこに行くのか？」「これはいくらかかるのか？」「これはあなたが私のために行う他のことといかに適合するのか？」などです。顧客でない人はすべてステークホルダーFAQに入ります。それは「これは去年の夏にやったこととどう違うのか？」「ROIは何か？」「どのテクノロジーを使用するのか？」といった内容です。
Ben：最後の部分はビジュアルです。ビジュアルは単に顧客体験の低忠実度の図です。ワイヤフレームではありません。そして最後の部分として、私たちは多くの反復を行います。アイデアをより良くするために、何度も修正と改訂を重ねるのです。
6. イテレーションとスケーリング
6.1. PRFAQを「世界一安いプロトタイプ」として活用
Ceileidh：PRFAQを実際には「世界一安いプロトタイプ」だと考えています。なぜなら、あの5つの質問を通じて、あなたは一人でデスクに座るか、あるいは小さなTwo Pizzaチームのグループで「これは素晴らしい、何かが見えてきた、これをリーダーシップや利用者と共有できる」と言うことができるからです。彼らはそれに赤ペンを入れるか、あるいはハイタッチをして進むことを許可してくれるでしょう。
Ceileidh：考えてみると、アウトプットの忠実度が思考の忠実度と一致するのです。そして他の人々をその旅に連れて行くとき、彼らは基本的にその文書をあなたのために強化してくれます。それがより伝統的なプロダクト要件文書のようになり、「よし、これを何かに変換する準備ができた」または「いや、スケールしない、止めよう、その理由はこれだ」と言えるようになります。
Ceileidh：そのような初期段階の本能的反応を得るために、PRFAQを取り巻く逸話とデータの両方のブレンドが非常に重要です。これらをすべてまとめて考えると、私たちの一般的なアプローチは、顧客から始めて逆算すること、世界をプロダクトとして捉えることです。さらに、Amazonのホームページのような、皆さんがよく知っている愛するものに組み込まれている様々なプロダクト体験を考える助けになるスライドがもうすぐあります。
6.2. ビルド・測定・学習のサイクル
Ceileidh：私たちはプロダクトチームとして組織します。Two Pizzaチームと呼んでいますが、厚いクラストのミッドウェスタンピザなのか、ニューヨークの薄いピザなのかと冗談を言うこともあります。要は、5〜8人程度の十分に小さなチームで、目的を達成するために必要なスキルセットがクロスファンクショナルに揃っているということです。
Ceileidh：これらのチームを集め、反復によってリスクを低減します。「ビルド・測定・学習、ビルド・測定・学習、ビルド・測定・学習」というサイクルを繰り返すのです。一般的に安全だと認識されているものに多くの時間を投資する必要はありません。例えば、シングルサインオン体験を再発明する必要はないでしょう。しかし、高価値のものにファネル上部の管理を行ったことがない場合は、そういった領域で反復し、テストする必要があります。
Ceileidh：リスクの高い仮説に対してリソースを調整することは非常に重要で、より速く前進するのに役立ちます。そして、ライフサイクル全体を所有します。Benが言及したように、これは青空グループではありません。私たちのタイトルには「イノベーション」という言葉がありますが、「これは素晴らしいアイデアだ」と言って壁を越えて他の人に実際に運営させるようなものではありません。
Ceileidh：責任あるイノベーションとは、コンセプトからクリッカブル、そしてコードへと進むか、プレスリリースから製品へと進むなど、あなたの組織内でそのライフサイクルを表現するために使いたい言葉は何であれ、そのすべてを行うことを意味します。
6.3. リスクの高い仮説に資源を集中させる重要性
Ceileidh：私たちがこれらすべてを行う理由は2つだけです。知るまでの時間を短縮したいのです。これが素晴らしいアイデアで、市場を席巻するとあなたは知っているかもしれません。あるいは、これは悪いアイデアで、誰も好まず、顧客が興味を持たず、重複しているなど、どのような理由であれ、あなたのエコシステム内での理由があるでしょう。知るまでの時間を短縮することは非常に重要です。
Ceileidh：これらの概念をまとめると、Benのスライドに戻りますが、プロダクトチームは協力してより良くより速い決断を下します。ビジネス価値を表現し差別化するのに役立ち、深い共感を育むことで顧客をより深く知るのに本当に役立ちます。
Ceileidh：基本的に、顧客から始めて、それからそれらの多くの異なるアイデアを実験ループで実行し、そこから学び、製品開発から受け取ったシグナルに基づいてデータ駆動の決定を下すことです。プロトタイプを立ち上げて、それらのKPIのほんの少しの兆しが必要か、あるいは本格的な立ち上げを行って、8,000人のユーザーのための素晴らしい堅牢なトレンドラインが本当にあるかにかかわらず、10人や12人でもそれを行うことができます。
Ceileidh：そのポイントに達すると、スケールする準備ができ、それらの使用パターンを使用してロードマップの将来を定義します。準備の段階で冗談を言っていたように、10年間のロードマップを見せてほしくありません。永続的なニーズについての10年間のロードマップなら見たいですが、モビリティや取引は消えていかないでしょうが、5年後や10年後に何がそれらを構成するのかは正確にはわかりません。
Ceileidh：ですから、それらの永続的な顧客ニーズに基づいてスケールする準備ができていることは非常に重要です。
7. プロダクト思考の実践例
7.1. amazon.comホームページに見るデカップリングされた数百のプロダクトチーム
Ceileidh：基本的に、このプロダクト駆動型の運用モデルを適用すると、さまざまな形で見ることができます。先ほどプロダクトとしてのPRIMEの進化の素晴らしい例がありました。同様のことをデバイスでも行い、Amazon Connectのようなものも作りました。これはamazon.comの顧客にサービスを提供するために作成したプロダクト体験で、比較的最近外部化され、皆さん外部顧客向けの堅牢なプロダクト体験となりました。あるいはAmazon Goのような再構想された小売体験にも見られます。
Ceileidh：内部向けのプロダクト、プログラムなども同様に、プロダクト体験として機能します。生産ラインを任意の時点で停止できるAndon Cordメカニズムや、Toyotaの友人たちからヒントを得たものや、Amazon Heartbeatのようなもので、これは市場で私たちが聞き、感じ、見ていることに基づいて顧客の感情を深く理解するのに役立ちます。
Ceileidh：コンポーネントを分離し、それらの反復的な小さなTwo Pizzaチームでプロダクト開発を行うことについて考えるとき、プロダクトをそれらの独立したコンポーネントとして考えるのが好きです。私の背景はAWS以前におもちゃのプロダクト開発だったので、よくレゴブロックのアナロジーを使います。
Ceileidh：これは単にamazon.comのホームページです。この場では完全にインタラクティブなセッションではないので、Amazonで何かを購入したことがある人？ほぼ全員ですね、素晴らしい。あなたのホームページはおそらくこのように見えますが、子供がいるかもしれないし、犬がいるかもしれないし、何かを出荷するのに時間がかかる地域に住んでいるかもしれないし、異なる税制があるかもしれません。
Ceileidh：あなたのホームページはあなた、あなたの家族、あなたのプロフィール、あなたの購入パターンに合わせて非常にカスタマイズされています。このページには何個のプロダクトチームがあると思いますか？5つでしょうか、50でしょうか？20という人、10という人、5という人がいますね。
Ceileidh：それを分解すると、このように考え始めることができます。マーケットプレイスプラットフォームのウィジェットもプロダクトです。ここではアダプティブホームページを体験として見ていますが、カート、ナビゲーション、検索、プロモーション、コンテンツカートリッジも見えます。割引かもしれないし、推奨事項かもしれません。「先週靴を買ったから、靴磨きや靴下、靴ひもが欲しいかもしれない」と言えるかもしれません。
Ceileidh：私たちはその体験を理解しカスタマイズし始めます。もし私がAmazonカートのプロダクトオーナーで、あなたが割引のプロダクトオーナーなら、私たちは自分のプロダクト体験で反復でき、APIのベストプラクティスガイドラインに従い、私は自分の領域で実験してもシステムが壊れることはなく、あなたも自分の領域で実験してもシステムが壊れることはありません。そして私たちは、それらの分離されたチームの有機体として反復することができます。
Ceileidh：さらに深くなっています。アカウントプロフィール、デジタル資産管理、SKU、広告などに関連するチームがあります。これらのプロダクトチームをさらに詳しく見ていくと、ネタバラシをすると、何百ものチームがあります。誰も正確なプロダクトチームの数を言い当てませんでした。おそらく全員合わせればですが、それも変動します。
7.2. IT部門をコストセンターからビルダーへと変革する考え方
Ceileidh：このようなマーケットプレイス型のアプローチ、複数のプロダクトチームが同期的かつ非同期的に生活し、呼吸し、一緒に働いていることを考えると、企業はどのようにしてBenが議論したようなプロジェクトからプロダクトモデルに移行するのでしょうか。また、Fatimaがここにいる理由でもありますが、物理的な商品の生産と販売のみに本質的に結びついた会社から、よりデジタルなものへの変革をどのように考えるのでしょうか。
Ceileidh：ここがこのプレゼンテーションのタイトルに戻るところです。これはヘルプデスクITではありません。パスワードをリセットしたり、プリンターに接続したり、O365のライセンス問題を修正したりするITではありません。これはビルダーITです。特に多様化された産業にいる方々に奨励したい心の変化は、時に「figital」と呼ばれる物理的とデジタル的なもの、本当にあなたのチームを再構想することです。
Ceileidh：クラウドエンジニアリングは、そういった産業にいるのであれば、機械工学と同じくらい重要です。例えば自動車を作るサービスに携わっているなら、当然、トランスミッションを再設計する機械エンジニアはとても重要です。それらの職務がどのようなものであり、それらのシステムがどれほど堅牢に設計される必要があるかは非常によく理解されています。
Ceileidh：しかし、物理的な製品の上にデジタルインテリジェンスの層を追加し、デジタル製品を物理的な製品と同じくらい堅牢に、あるいはさらに優れたものにしたいのであれば、そういった方法でクラウドエンジニアを考える必要があります。彼らはビルダーなのです。
Ceileidh：ロボット工学と物理的なプロダクト開発の背景から、このように考えるのが好きです。反復は、デジタル側でのみ堅牢な方法で本当に利用可能なのです。私のスライドから一つの重要なポイントを挙げるとすれば、ITを単なるコストセンターではなく、ビジネスを構築し、顧客に新たな価値を生み出すための創造的成長の場として考えることを皆さんに奨励します。コストセンターだけでなく、楽観的で起業家精神に富んだ視点を維持し、顧客に代わって可能性の芸術を見て、隅を見回すことが重要です。
7.3. クラウドエンジニアリングの重要性と物理製品メーカーのデジタル変革
Ceileidh：外部のお客様と協力する際、私たちには2つの目標があります。「より大きく考え、より速く構築する」お手伝いをすることです。これは単に「大きく考える」側面だけではなく、18ヶ月後に閉鎖される青空グループでもありません。また、単にキーボードに手を置いて、言われた通りに構築し、質問をしないというものでもありません。
Ceileidh：私たちは特定のプロセス、つまりBenが言及した「Working Backwards（顧客から逆算する）」を使用します。これがAmazonがイノベーションを起こす方法です。イノベーションを起こすには多くの素晴らしい方法があり、最高または唯一の方法だとは主張しません。これは単に私たちがやり方であり、私たちが知っていることです。
Ceileidh：私たちはこの非常に特定のAmazonのプロセスに従います。これは自社の製品やサービスを作るために社内で行っていることですが、それをお客様と共有することが私たちの仕事でもあります。このAmazonのプロセスに従うことは私たちにとって非常に重要です。
Ceileidh：次に、私たちは文字通りにも比喩的にも「手を汚します」。顧客の共感を育む素晴らしい方法は一つだけです。それは彼らの靴を履いて歩くか、コールセンターで彼らを観察して何システムを統合する必要があるのかを見るか、患者サポートサービスの旅において意思決定支援がなぜそれほど混乱しているのかを理解することです。リクエストの背後にある「なぜ」を知る必要があり、それによって製品やサービスをよりよく表現し、そこから前進することができます。
Ceileidh：最後に、最小限の「愛すべき」製品（MLP）をテストし構築します。MLPは、おそらくMVP（最小限の実行可能な製品）とは少し異なって聞こえるかもしれません。実行可能性と愛すべき性の違いです。私たちは愛すべき性にこだわります。なぜならこれらは本当に針を動かすべき機能だからです。実行可能性は素晴らしい、機能する、それは古い学校の考え方ですが、もし喜ばれるなら、それを使うことができ、信号を得て、体験をどのように強化して価値を生み出すかを理解できます。
8. Bridgestoneの変革事例
8.1. タイヤメーカーからモビリティソリューションプロバイダーへの変革
Ceileidh：これらの要素をまとめると、ブリヂストンタイヤについて話すためにユニークな方法で移行します。私は様々な製品について、4年間オンオフで彼らと協力してきました。AWSで働いていますが、私は完全な機械オタクなので、このブランドに惹かれました。私の土埃バイクと車にブリヂストンタイヤを購入したことがあります。
Ceileidh：私はいつも、企業がタイヤとゴム事業だけでなく、その先に成長し構築するために何をしているのかを理解するのが好きです。それは非常に競争の激しい分野であり、ある面では物理的に差別化されていますが、他の面では、彼らはまだ顧客と接続し、価値を引き出す素晴らしい方法を探しています。
Ceileidh：彼らは「タイヤ提供者からモビリティソリューション提供者にどのように移行するか」という様々な方法で私のところに来ました。エネルギー会社と同様の会話をしたことがあります。「石油・ガス精製会社からエネルギー提供者にどのように移行するか」という話です。そうすれば視野を広げて「もちろん太陽光もできる、風力も確実にできる、天然ガスもできる、バイオ燃料もできる」と言えるようになります。
Fatima：ブリヂストンとの様々なプロジェクトで協力する中で、とても興奮しました。なぜなら、タイヤメーカーからは予期しないような非常に興味深いことを彼らが行っており、私たちが一緒に取り組むことができたからです。2022年には、いくつかの異なるイニシアチブがある大きな傘のような戦略的関係フォーラムがありました。
Fatima：彼らは業界で初めてAWSマーケットプレイスで製品を発売した企業となりました。デジタルトランスフォーメーションの精神において、タイヤメーカーからAWSマーケットプレイスでのフリート管理ソフトウェアへの移行は非常に革新的でした。開発者ガレージでも彼らと協力しました。このブランディングの面白い部分が好きです。どのようなAPIをこの会社が顧客に提供すべきか、そしてフリートサービスプロバイダーや自動車メーカー（OEM）などの顧客がそれらをどのように消費したいかという点での取り組みでした。
Fatima：また、彼らのラストマイルマーケットプレイスの立ち上げでも協力しました。これはそれらのイニシアチブの一部で、「あちこちに小さな火がある」戦略、いわゆるイノベーション主導のトランスフォーメーションと呼べるものです。これは非常に多くの興味深いことが起きているということです。これが私の友人Fatimaを招待して、タイヤメーカーからモビリティサービスプロバイダーへのブリヂストンの旅について話してもらう理由です。
8.2. AWSマーケットプレイス、開発者ガレージ、ラストマイルマーケットプレイスの取り組み
Fatima：今日私たちが話していることは、「可能性の芸術」についてです。私たちが最初に行ったことは、まず顧客を理解することでした。私はスタートアップの背景を持っていますが、ブリヂストンという舞台に飛び込むことは、会社の規模だけでなくビジョンの規模からも本当にエキサイティングでチャレンジングでした。これは私たちが成し遂げてきたことの基盤であり、本当に力を与えてくれるものだと思います。
Fatima：簡単に確認したいのですが、今日、ソフトウェアを主要サービスとして販売しているソフトウェアネイティブな企業で働いている方はどれくらいいますか？わかりました。そして、非ネイティブ、たぶんソフトウェア対応、伝統的なビジネスサイドにいる方はどれくらいでしょうか？素晴らしい。もう一つ質問です。あなたの組織内でプロダクトマネージャーやプロダクト開発者である方はどれくらいですか？素晴らしい。混沌へようこそ。
Fatima：私たちのパートナーシップは、タイヤサービス、メンテナンスサービス、フリート管理サービスの間で交差する顧客価値を見つけることについてでした。Azugaを代表する私として、デジタル体験を通じて顧客に提供できることの中心にあるものですが、物理的なものを忘れないようにしています。
Fatima：少し文脈を説明したいと思います。ブリヂストンは100年近い歴史を持つ会社です。様々な変遷を経てきました。最初はタイヤビジネスのみでした。その後、Firestone小売店に進出しました。皆さんがFirestoneで車のサービスを受けたことがあるなら、それもブリヂストンの店舗です。これは北米だけでなく、グローバルなサービスです。
Fatima：2020年には、ブリヂストン3.0と呼ばれる未来を見据え始めました。これは単なるタイヤとメンテナンスサービスビジネスではなく、ソリューションビジネスへの転換に焦点を当てています。ここで私たちが登場するのです。これはまさにこのブリッジシステムからなのです。
Fatima：組織として下さなければならない本当に重要な決断があると思います。それは、変革を見据える際にどこにアンカーを置くかということです。私たちにとって、それはモビリティでした。
8.3. 組織的変革とクロスファンクショナルチームの構築
Fatima：プロダクトビジョンから始めたいと思います。プロダクトビジョンは常に私たちがそこから逆算する必要があるものです。私たちにとって、リーダーシップの整合性を持つことは非常に重要でした。ブリヂストン3.0が示すように、私たちは変革とは何を意味するのか、そしてその中でお客様がどこに存在するのかについて、全員が本当に整合していました。私たちをその中心に置くことで、少なくとも基盤を構築することができました。そこから信頼を築き、このイノベーションプロセスを通じてイノベーションへの道を歩み始めることができました。
Fatima：実際、最初は運用面から始めました。なぜなら、最初に見なければならなかったのは、私たちのチームがフリートテレマティクス内だけでなく、ブリヂストン全体として顧客価値と整合しているかどうかということでした。そして、どのようにして組織化し、より良く顧客にサービスを提供し、より詳細に顧客を説明するかということでした。そして、それを持った上で、すでにピザチームと呼ばれているものを作りましたが、私たちにとっては、クロスファンクショナルな方法が少し異なっていました。
Fatima：デザイナー、プロダクトマネージャー、テックリードがいますが、プロダクト評議会もあり、ブリヂストンの姉妹パートナーや会社全体に存在する業界や機関の知識を引き出しています。ですから、これらのペルソナを理解し、定義し、文書化することは本当に重要でした。明確な「job to be done（達成すべき仕事）」も重要でした。
Fatima：プロダクトに携わる方はおそらくこれを聞いたことがありますが、これらのチームのための「job to be done」の範囲を決めることが重要でした。イノベーションでは、時に「すべてをやれ」や「私はどこで終わり、誰かが始まるのか」という状況になることがあります。ですから、これらのチームには、プロダクト、デザイン、エンジニアリングがすべてのチームで平等に代表されているという中核的な真実を持ちながら、焦点を当てることが本当に重要でした。
Fatima：伝統的な環境に入ってくる際の別のチャレンジは、問題と解決策を分離することでした。アイデアを思いついたとき、すぐに解決策に飛びつくのは本当に簡単でした。「これができる」「あれに何百万ドルも投資できる」と。しかし、むしろこれらのチームと問題空間にもっと時間を費やし、「本当に何をしようとしているのか」「顧客にとってのその問題の範囲は何か」「顧客が見る必要があるROIは何か」と問いかけました。それが、「はい、私にとって機能している」と顧客に検証されるためには。そうすることで、解決策について話すときのステークホルダーの議論でそれを活用することができます。
Fatima：問題空間の優先順位付けを単なる解決策空間よりも重視するという文化の変化を支援することが本当に重要でした。多くの人が知っているように、それは簡単に感じるかもしれませんが、非常に複雑で挑戦的です。
9. 顧客行動と問題空間の理解
9.1. 問題と解決策の分離の重要性
Fatima：ユーザー体験は、より「ソリューション」と呼ぶものではなく、エンドツーエンドの顧客体験についてリードするという点で、この取り組みの本当に重要な部分になりました。私たちは単に「ユーザー体験」や「顧客体験」ではなく、「顧客設計体験」という言葉に切り替えるほどでした。なぜなら、もはやデジタル製品だけを設計しているのではなく、デジタル設定で具現化し、そして再び物理的な設定に戻る可能性のある物理的な体験を設計しているからです。
Fatima：そのため、サービス、製品、そして小売店に車を降ろすような物理的な場所との相互作用という観点から、問題空間をマッピングすることが本当に重要でした。それが私たちを次のステップに導きました。実際に顧客行動を見ることです。
Fatima：単なる顧客データではなく、顧客行動を強調したいと思います。私たちの顧客フリートだけでなく外部でも、何が見えているかを見ていきました。ここでいくつかの例をご紹介しますが、これらがどのようにして最終的に私たちがリリースしたプロジェクトに具現化したかを説明します。
Fatima：私たちにとって観察された行動には3つの要素がありました。1つ目は、提供物と車両サービスの間の体験です。車両データをどのように活用して、顧客がメンテナンスサービスについて決定を下し、より予測的になるのを助けるかを検討しました。2つ目は、情報へのより迅速なアクセスと、中央プラットフォームでのこの情報の探索です。フリートマネージャーとして、この膨大なデータをどのように理解すればよいのでしょうか。車両、カメラ、トレーラーからのテレメトリーを考えると、多くのデータが入ってきます。
Fatima：フリートマネージャーとして、それをどのように理解すればよいのでしょうか。私にはその方法がわかりません。そして最後に、デジタル製品やメンテナンスサービスに投資することで、それが自分のビジネスにどのようなROIをもたらすかをどのように知ることができるでしょうか。これが顧客として特に重要です。
Fatima：これらが私たちが観察した行動であり、それらからソリューションの機会を生み出しました。
9.2. ユーザー体験からカスタマー設計体験への転換
Fatima：顧客を理解する最良の方法は、マッピング、つまり顧客を理解するための視覚的な方法を持つことです。そこで私たちは、ビジネスのエコシステムと顧客がフィールドで経験していることを対比させて検討しました。私たちが提供するすべてのものがここにあります。そして、それが顧客のエコシステムを通じて経験していることとどのように並置されているか。
Fatima：顧客が彼らのドライバーとフリート両方の快適さと安全性を向上させようとしているとき、彼らは利便性を求めています。ドライバー側での人手不足に取り組もうとしています。道路安全性を支持し、なぜ安全性が重要かを人々に教えようとしています。これらは私たちの顧客が経験している課題です。
Fatima：ですから、私たちが構築するすべてのものをこれに立ち戻らせることが重要です。私たちの目標が構築しているものの最前線にあることを確認するために、それをマッピングしました。
Fatima：そして、ソリューションに関しては、範囲管理と構築方法を考える際に役立つ原則が必要だと言いました。どのように単純な方法でこれを考えることができるでしょうか？そして、これらのいくつかは非常に馴染みがありますが、私たちにとっては文書化し、それらを実践することが本当に重要でした。
Fatima：実行可能性、中核的な運用の強みに基づいて構築できるか？全く新しいことをするのではなく、内部的に多くの強みがあり、それをどこで活用できるか？スケーラブル、私たちは巨大な会社です。ですから、世界中にフリートを持つ巨大な顧客にスケールできるものが必要です。事業性、収益成長のためのユニットエコノミクスを解決するソリューション。
Fatima：これから逸脱することはできません。私たちはまだこれらのソリューションのためのビジネスケースを作る必要があります。そしてMLP（Minimum Lovable Product）の議論に戻りますが、望ましさ、顧客のROIのためにマッピングした実際の顧客の痛みを解決するソリューションです。
9.3. 顧客行動の観察と分析
Fatima：顧客行動を理解するにあたり、私たちは単なるデータ分析を超えた観察を重視しました。顧客が実際にどのように行動し、どのような課題に直面しているかを理解することが重要だったのです。
Fatima：例えば、フリートマネージャーたちは車両データや診断情報、ドライバー行動などのテレメトリーデータを扱っていますが、これらの情報を実用的なものに変換する方法に悩んでいました。車両の摩耗状態、タイヤの状態、ドライバーの運転行動が車両やタイヤにどのような影響を与えるかといった関連性を理解しようとしています。
Fatima：私たちは、このような顧客行動の観察から3つの主要な洞察を得ました。まず、顧客は車両サービスと提供物の間の体験をシームレスにしたいと考えていました。車両データを活用して、メンテナンスサービスについてより良い決断を下し、予測的になりたいと考えていたのです。
Fatima：次に、情報へのより迅速なアクセスと中央プラットフォームでの情報探索についてでした。多くの顧客は「このデータは私にとって神秘的すぎる」と感じていました。車両、カメラ、トレーラーからの膨大なテレメトリーデータがありますが、フリートマネージャーとしてこれをどう理解すればよいのかという課題がありました。
Fatima：最後に、顧客は自分たちの投資が実際にどのようなリターンをもたらしているのかを知りたがっていました。「デジタル製品やメンテナンスサービスへの投資が、自分のビジネスにどのようなROIをもたらしているのか」という具体的な疑問です。
Fatima：これらの行動観察を通じて、私たちは単なる仮説ではなく、実際の顧客ニーズに基づいたソリューションの機会を特定することができました。そして、これらの洞察を製品開発の中心に据えることで、真に顧客中心のアプローチを実現することができたのです。
10. 成功事例と実践されたプロジェクト
10.1. フリート向けエンドツーエンドスケジューリングの実装
Fatima：私たちのプラットフォームで最初に成功したプロジェクトは、すべてのフリートとドライバー向けのエンドツーエンドスケジューリングでした。フリートが私たちのプラットフォームで運用を管理している際、彼らは診断に関するすべてのテレメトリーを得ています。ドライバーが車両をどのように運転しているかという行動データ、そしてそれがタイヤや車両自体にどのような摩耗をもたらすかというデータを取得しています。
Fatima：このようなデータを物理的な空間でのアクションにつなげるために変換することができます。「今なら直接店舗に行って、便利な方法でセルフサービスを受けることができます」と伝えることができるのです。これにより、このプロジェクトの価値提案がIT支援から脱却し、「これは私たちがドライバーやフリート管理者に直接提供できるサービスであり、彼らのビジネスに直接ROIをもたらす」というものになりました。
Fatima：なぜなら、メンテナンス担当者はもはやこれらを手動で管理する必要がなくなったからです。技術者たちはオイルサービス交換が必要かどうかを確認する必要がなくなりました。それはスケールで管理できることです。ですから、これは望ましさと使いやすさという私たちの目標だけでなく、顧客の利便性とサービス性という目標にも沿っていました。
Fatima：これはすべて、AWSチームとビジネス全体で取り組んだ多くのコンポーネントを通じて実現しました。Azugaだけではなく、これを実現させるために貢献した多くの異なるチームがあります。これを可視化するなら、フリート管理側以外にも5〜6のチームが関わったことになります。
10.2. ジェネレーティブAIによるデータの簡素化と活用
Fatima：次に私たちが実験しているプロジェクトはジェネレーティブAIです。車両に関する膨大なデータと情報があり、これを簡素化すれば顧客は車両をより迅速に管理し、安全に運転していないドライバーを指導したり、上手く運転しているドライバーに報酬を与えたり、事故を防いだりすることができるようになります。あるいは少なくとも、起こり得るリスクを理解できるようになります。
Fatima：そこで私たちはアーキテクチャの実験を始めました。一部はうまくいき、他のものはうまくいきませんでした。しかし最終的には、顧客がこのデータとどのように対話したいか、それが彼らにとって馴染みのあるものであり、毎日のコンテキストから引き離すことなく、革新性を馴染みのあるものに取り入れる方法を理解できる良い場所に到達しました。
Fatima：ジェネレーティブAIの活用により、私たちは車両に関する膨大なデータをより理解しやすい形に変換することができました。例えば、複雑な車両診断データを簡単な自然言語の推奨事項に変換したり、ドライバーの行動パターンから安全に関する洞察を導き出したりすることが可能になりました。
Fatima：このプロジェクトでは、単にAI技術を導入するだけでなく、顧客がどのようにデータと対話したいかを深く理解することに焦点を当てました。私たちは顧客が日常的に使い慣れているインターフェースに革新をもたらすことを目指しました。驚くべき新しいものを作るのではなく、既存の顧客体験を強化し、データをより実用的で価値のあるものにすることが重要だったのです。
Fatima：これによって、フリートマネージャーは複雑な技術的知識がなくても、車両データからすぐに行動できる洞察を得られるようになりました。安全運転を促進し、リスクを予測し、運転行動を改善するための具体的なアクションへとデータを変換することが可能になったのです。
10.3. ROI可視化による顧客との戦略的パートナーシップ強化
Fatima：最後に重要なのはROIの側面です。顧客のソリューションパートナーになるにはどうすればよいでしょうか？これらの、私たちにとってはプロジェクトですが、ビジネスにとってはサービスや製品、ソリューションへの投資が、単なる利用以上の方法であなたに利益をもたらすことをどのように確認できるでしょうか？
Fatima：アイドリングによるCO2排出量への影響から、あなたのビジネスに持続可能性を創出するのを助けることができます。フリート全体で見ているリスク要因についてどのように教育するか？より良く安全なドライバー行動の報酬プログラムを高めるのをどのように支援できるか？私たちと一緒に実装したカメラソリューションからの利益やコスト削減をどのように確認できるようにするか？
Fatima：これらはすべて、QBR（四半期ビジネスレビュー）を通じて顧客に提供する準備をしていることですが、それらをまとめることで「私たちはこれらのソリューションビジネスでのパートナーです。単にあなたが活用して展開し、あなたが私たちと一緒にいてくれることを願うベンダーではありません」と伝えることができます。そしてそれが、これらのプロジェクトを実現するためのさまざまなコンポーネントとのパートナーシップの重要な部分でした。
Fatima：このROI可視化の取り組みによって、私たちは単なるサービス提供者から戦略的なビジネスパートナーへと関係性を進化させることができました。顧客に対して、彼らの投資がどのように具体的な成果につながっているかを透明性を持って示すことで、より深い信頼関係を構築しています。
Fatima：例えば、車両のアイドリング時間の削減による環境影響とコスト削減、安全運転プログラムによる事故率の低下とそれに伴う保険コストの削減、カメラソリューションによる運転行動の改善と運用効率の向上など、数値化可能な成果を顧客と共有しています。
Fatima：これにより、単に「製品やサービスを販売する」という関係性から、「顧客のビジネス成功に貢献するパートナー」という関係性に発展させることができました。顧客との各接点が、単なる取引ではなく、共同での価値創造の機会となっているのです。
11. 結論：成功のための鍵
11.1. プロダクトデプロイメント運用モデルの確立と洗練
Fatima：締めくくりとして、皆さんの間と夕食や飲み物の間に立ちはだかっていることは承知しています。私たちが成功を見出したのは、独自のプロダクトデプロイメント運用モデルを確立し、洗練させることを確実にしたことです。これは非常に重要です。
Fatima：シンプルに保ち、問題空間を分離して、経営陣の後援や資金調達の観点から、ステークホルダーと適切な議論をしていることを確認することが重要です。顧客の方法論を通じて、どのように顧客を理解し、彼らのROIを理解するかというこれらのイノベーションメカニズムを体系化することも必要です。
Fatima：焦点を絞ったデジタル体験を立ち上げること、壮大なものではなく、信頼を築き、イノベーションを継続する権利を獲得することが重要です。そして本当に、ITと、これは非常に新しいことですが、ITからビジネス開発、そして顧客向け・収益向けのチームやサービスにどのように橋渡しするかをつなげることが大切です。
Fatima：しかし、正直なところ、最終的には小さく始め、特に人々が理解できる迅速な成功を示し、それからスケールすることです。これが重要な鍵なのです。
Fatima：私たちがBridgestoneで確立したプロダクトデプロイメント運用モデルは、従来の製造業の思考から顧客中心のソリューション提供者への転換を可能にしました。このモデルは単なるプロセスの変更ではなく、組織文化と思考方法の根本的な変革を表しています。
Fatima：このモデルの確立によって、テクノロジー、ビジネス開発、顧客向けチームが一体となって働く環境を作り出すことができました。各部門がサイロで動くのではなく、共通の顧客価値創造という目標に向かって協力することで、イノベーションのスピードと質を高めることができたのです。
11.2. 問題空間と解決策の分離
Fatima：私たちの成功において非常に重要だったのは、問題空間と解決策空間の明確な分離です。伝統的な環境では、アイデアが生まれると、すぐに技術的な解決策に飛びつきがちです。「これはこのように構築できる」「あれに何百万ドルも投資できる」といった具合に。
Fatima：しかし、私たちは意識的にこの習慣を変え、まず問題空間により多くの時間を費やすようにしました。「顧客は本当に何に困っているのか」「その問題の範囲は何か」「顧客にとってのROIは何か」といった質問から始めたのです。
Fatima：この分離は、特に経営陣の後援や資金調達の観点から、ステークホルダーとの対話を変えました。解決策の前に問題を深く理解することで、その後の技術的議論がより焦点を絞ったものになり、実際の顧客ニーズにより密接に関連するようになりました。
Fatima：例えば、フリート管理の課題に取り組む際、最初から技術ソリューションを考えるのではなく、フリートマネージャーが日々直面している具体的な課題を理解することから始めました。彼らのワークフローを観察し、痛点を特定し、それからそれらの特定の問題に対応する解決策を設計したのです。
Fatima：この問題と解決策の分離は、私たちがより焦点を絞ったデジタル体験を設計するのに役立ち、単に「できること」ではなく「すべきこと」に集中できるようになりました。これにより、より小さく、より実行可能な成功を積み重ね、信頼を築き、継続的なイノベーションへの道を開くことができたのです。
11.3. 小さく始めて、迅速に成功を示し、スケールする戦略
Fatima：最終的に、私たちの変革戦略の核心は「小さく始めて、迅速に成功を示し、スケールする」というアプローチにあります。多くの組織が大規模な変革プログラムで失敗するのは、最初から大きすぎるプロジェクトを始めようとするからです。
Fatima：私たちは意図的に小規模な取り組みから始めました。まず、エンドツーエンドスケジューリングのような、明確で理解しやすい成功事例を生み出すことに集中しました。このプロジェクトは規模は小さかったものの、顧客にとって明らかな価値を提供し、社内での信頼構築に役立ちました。
Fatima：特に重要だったのは、「人々が理解できる成功」を示すことです。技術的に洗練されていても、ビジネス価値が見えにくいプロジェクトではなく、顧客とステークホルダーの両方が直感的に理解できる成果を選びました。
Fatima：最初の成功を収めた後、私たちはその経験から学び、次のプロジェクトへと知見を活かしました。ジェネレーティブAIの実験や、ROI可視化のような、より複雑な取り組みへと段階的に拡大していきました。
Fatima：この「小さく始めて、スケールする」戦略により、大きなリスクを取ることなく学習し、実験し、調整する余地が生まれました。各成功が次の取り組みへの信頼と支援を構築し、徐々に組織文化を変革していくことができたのです。これは単なる技術プロジェクトの実施方法ではなく、組織全体がイノベーションと顧客中心主義へと移行するための戦略的アプローチでした。