Amazon の 2 つのピザチームによるイノベーションとスピードの促進

Amazon は、ドットコムの時代に創業した多くの企業と同様に、迅速な俊敏性を実現し、絶え間ない価値をお客様に提供することを目的として組織されていました。ジェフ ベゾスは 1997 年の最初の株主への手紙で、常にお客様を起点に考え、短期的な企業利益を犠牲にしても、お客様のために継続的かつ長期的な価値を提供することの重要性について語りました。常にお客様を起点に考えるというこの習慣を実現するには、毎日目を覚ましたときに、お客様の最も厄介な問題を解決し、お客様のために発明することに心を躍らせる、自律的なビルダーから成る組織構造を採用し、維持する必要がありました。

「採用へのアプローチの基準を高く設定することは、Amazon.com の成功の最も重要な要素であり、このことは今後も変わらないでしょう」と Jeff はしたためています。

これは、ビジネスが e コマースに重点的に取り組み、チームと、迅速なイノベーションを実現するために利用していた技術アーキテクチャがより一元化され、緊密に連携していた初期の頃は容易でした。しかし、時が経つにつれて、Amazon がお客様のニーズを満たすためにビジネスや新たなイノベーションの数を増やしていく中で、業務を遂行できるスピードと俊敏性の低下を感じ始めました。ジェフが 2015 年の株主への手紙で概要を述べたように、「発明マシン」(「規模によって可能になる並外れたカスタマーサービスの能力と、通常は起業家精神にあふれたスタートアップが備えている動きの速さ、機敏さ、リスク受容の考え方を組み合わせる」ことができる会社) であり続けたいという願望に、悪影響が生じ始めたのです。当社の緊密に結合されたアーキテクチャと組織は、当社が望んでいた程度に、または必要としていた程度に迅速に行動するのに役立つものではありませんでした。

速度と効率性の低下に対処するため、当社は技術アーキテクチャをマイクロサービスアーキテクチャと呼ばれるものに根本的に変更しました。モノリシックアーキテクチャを単一のスタンドアロンサービスの広大なネットワークに分離しました。これにより、新しいイノベーションやオファーを迅速に立ち上げ、絶えず変化するお客様のニーズに基づいて既存のサービスのイテレーションを迅速に実行し、お客様のために考案する新しいアイデアを継続的に実験できるようになりました。

しかし、ビルダーがイノベーションを推進するために使用していたテクノロジーを単にオーバーホールするだけでは十分ではありませんでした。また、チームの編成方法を再構築して、お客様やニーズに寄り添い、お客様のために革新的な製品やサービスを迅速にリリースし、マイクロサービスアーキテクチャが提供できる俊敏性とスピードを最大限に活用できるようにする必要がありました。この組織構造は、Amazon の「ピザ 2 枚チーム」として知られるようになりました。

Amazon のピザ 2 枚チームのコンセプトはシンプルです。すなわち、ピザ 2 枚では足りない大きさのチームを編成すべきではないということです。トッピングの数や性質は脇に置いておいて (ここで「パイナップルはピザに合いますか?」という議論を解決するための時間とスペースはありません)、これは 10 名未満のチームであるのが理想的です。チームが小規模であるほど、お互いの距離が近くなり、官僚的な機構や意思決定で生じるオーバーヘッドが削減されます。これにより、ピザ 2 枚チームは、より多くの時間をお客様に費やし、お客様のために実験やイノベーションに継続的に取り組むことができます。これは、Amazon で高いパフォーマンスを発揮しているチームにとっての最優先事項となっています。

また、チームが小規模であるほど、オーナーシップは強化され、付与される権限も多くなります。これにより、リンゲルマン効果 (大規模なグループで個人の生産性が低下する傾向) を低減できます。チームのリソースが増大するにつれて、メンバーは個人の努力にあまり重点を置かなくなり、自らの負荷を処理する際に他のメンバーを頼るようになります。チームの規模が大きくなると、個人の貢献度は低下します。逆に、チームの規模が小さくなると、個人の努力も増えます。

また、小規模なチームでは従業員の満足度が高まります。従業員の満足度は、今日の組織が最高の人材を引き付けて維持しようと努力する上で重要な懸念事項となっています。Hackman と Vidmar による注目すべき研究によれば、チームの規模が大きくなるにつれて、個人の満足度が低下することが示されています。大規模なチームでは、個人の貢献が認識されにくくなり、特定の領域に対する個人のオーナーシップがより弱くなることがよくあります。

これはワークフォースに関する調査でも裏付けられています。Gallup の「The State of the American Workplace」の調査によると、従業員が 10 名未満の組織のエンゲージメントレベルは 42% 以上であるのに対して、より大規模な組織の平均エンゲージメントレベルは 30% 未満でした。

しかし、Amazon のピザ 2 枚チームは、規模だけを問題にしているわけではありません。ピザ 2 枚チームの構造で絶え間ないイノベーションとスピードを実現するための重要な要素は、シングルスレッドでの注力を可能にすることです。

► ポッドキャストを聴く: C-Suite Strategies for Leading Significant Change

ピザ 2 枚チームは、規模だけを問題としているのではなく、オーナーシップや独立性を育み、チームレベルにまで落とし込むことも重要視しています。

Amazon と AWS において、ピザ 2 枚チームは、特定の製品やサービスに対するシングルスレッドのオーナーシップを持っています。複雑なシステムを維持したり、複数のサービス、事業部門、または顧客セグメントにまたがる問題を解決したりするのではなく、ピザ 2 枚チームは、ただ 1 つのサービスやオファー、そしてそれを利用するお客様のみに焦点を合わせます。このシングルスレッドのフォーカスは、効率とスケーラビリティを向上させます。ピザ 2 枚チームのロードマップ (必要なトレードオフと優先順位付けを含む) は、自らが担当するサービスとそのサービスを利用する顧客セグメントのためだけに革新することに焦点を絞ったものとなります。

また、2 ピザの構成により、チームの説明責任も強化されます。ピザ 2 枚チームは、自らがリリースしたものを、別のチームに運用してもらうために引き渡すことはありません。このシングルスレッドオーナーシップは、カスタマーエクスペリエンス全体と、ピザ 2 枚チームの製品やサービスのライフサイクル全体に及びます。

そのため、ピザ 2 枚チームは、明確な目的や信念と厳密に定義されたミッションをもって、サービスのあらゆる部分を常に把握している必要があります。サービスが常にお客様にとって価値あるものであるようにするため、チームはお客様に寄り添い、適切な追跡メカニズム、メトリクス、および KPI を作成する必要があります。

また、これを実現するには、サービスをエンドツーエンドで所有して実行するのに役立つように、ピザ 2 枚チームに適切なリソース (エンジニアリング、テスト、製品とプログラムの管理、運用など) が組み込まれている必要もあります。

製品やサービスについての需要が高まる中で、メンバーを増やしてチームを拡大するのではなく、個別のピザ 2 枚チームに分割して、各チームがサービスのシングルスレッドのサブエリアに取り組めるようにする方法を模索しています。この分割により、俊敏性、自律性、およびシングルスレッドオーナーシップを保持する、よりフラットな組織構造が維持されます。

つまり、ピザ 2 枚チームは、規模だけを問題にしているのではなく、オーナーシップと独立性を育み、アイデアの創出から実行、継続的な業務改善から絶え間ない製品のイテレーションやイノベーションに至るまで、チームレベルにまで落とし込むことも重要視しているのです。これは、チームが迅速に行動し、早い段階で頻繁に実験し、学習した内容を迅速に適用して、継続的にお客様に価値をもたらすことを可能にします。また、より迅速なイノベーションや実験は、失敗のコストを下げるのに役立ちます。開発の後半の段階で直面するよりも、早く学習でき、リスクを低く抑えることもできます。

ピザ 2 枚チームの構造は Amazon と AWS では機能していますが、すべての組織やすべてのビジネスユニットに適しているわけではないことも認識しています。ピザ 2 枚チームは完璧ではなく、制限の影響を受けないわけでもありません。とても多くの自律的なシングルスレッドチームが、それぞれのお客様のニーズを満たすために高速に運営されているため、重複やサイロ化された開発のリスクがあることはその一例です。各チームがオーナーシップを持つそれぞれの領域でイノベーションを推進する能力を阻害することなく、純粋に複製的な取り組みをどのようなタイミングで、どのように統合するかを決定するための適切なガバナンス構造を備えておく必要があります。

実験を迅速に行うには、複数のチームで協力して成功の可能性を倍増させ、リソースを合理化する必要もあります。また、失敗から得た教訓を把握して共有し、それらの教訓を将来の実験により適切に応用し、イテレーションの方向性と投資に関する将来の意思決定を微調整する能力はさらに重要です。

Amazon と AWS の組織において、チームが迅速に、独立して、自律的に運営できるようにしながら、ガバナンスと監督を促進するのに役立つ 1 つの側面が、シングルスレッドリーダーという概念です。

シングルスレッドリーダーの役割は、チームがお客様のために独立してイノベーションを起こすための権限を維持できるよう、適切なレベルの監督を行う上で不可欠です。

今日の経営幹部は、イノベーションとデジタルトランスフォーメーションを迅速に提供できることの大きなメリットを認識しています。新しい製品やサービスを迅速に市場に投入できることは、お客様に一定の価値を提供する上で重要であるだけでなく、企業が差別化を図るための競争上の優位性にもなり得ます。しかし、ビジネスの規模と範囲が拡大する中で、経営幹部は、チームが迅速に業務を遂行できるように、適切な組織とリーダーシップを構築する必要があります。

チームのガバナンスと管理には、チームが革新的な実験を進める前の承認や調整のラインを厳しく設定してスピードを低下させる「料金所」ではなく、「ガードレール」、すなわち、チームが迅速に業務を遂行し、質の高い、迅速な意思決定を行うことを可能にするメカニズムを提供する必要があります。

Amazon と AWS において、シングルスレッドリーダーの役割は、適切なレベルの確認と方向性のあるビジョンを実現する一貫したメカニズムを構築しながら、チームがお客様のために独立してイノベーションを起こすための権限を維持できるよう、適切なレベルの監督体制を確立する上で不可欠なものとなっています。シングルスレッドリーダーは、戦略的なビジョンを提示するのをサポートし、その後はチームの邪魔にならないように行動します。チームリーダーは、すべての意思決定で乗り越えなければならない障壁となるのではなく、障害を取り除くのをサポートする必要があります。小規模、アジャイル、自律的で、日々お客様を起点に考えているチームは、自らのサービスと顧客セグメントの第一人者です。

シングルスレッドリーダーは、ビジネスにとって最善の意思決定を行うために、チームの自律性を維持する必要があります。シングルスレッドリーダーがチームの意思決定に関与するのは、多くの場合、適切なデータインストルメンテーションや研ぎ澄まされた判断力があっても、今後の道筋が明確でない可能性がある状況でチームにガイダンスを提供するためです。

Amazon において、シングルスレッドリーダーがこれらのチェックポイントを監督しやすくするために用いられている仕組みの 1 つが、ナラティブと呼ばれる文書です。このような状況でのナラティブは、表面化したお客様側の問題の概要を説明すること、詳細な分析結果やチームが収集したデータからの情報を次のステップに役立てること、チームが推奨する決定事項と、検討された代替方法、それぞれの方法のリスクとメリットを明確に説明することに役立ちます。

時間をかけてナラティブを作成することは、スピードと絶え間ない業務の遂行を維持することに対して直感に反するように見えるかもしれませんが、Amazon と AWS ではナラティブを使用することで、非常に大きなメリットが得られました。1 つは、これらの文書は多くの場合、経営幹部のデスクに届く前であっても、チーム、その関係者、およびチームのオファーや顧客セグメントの対象分野の専門家によって何度も議論され、洗練されているということです。これは、コラボレーションを促進し、多様な視点を生み、前提条件の正しさを検証し、文書内のアイデアや推奨事項を洗練するのに役立ちます。最終的に、これは多くの場合、より質の高い意思決定につながります。

Amazon と AWS には多くのさまざまなナラティブがあります。私たちの Working Backwards アプローチから生まれる PR/FAQ 文書 (Press Release (プレスリリース)/Frequently Asked Questions (よくある質問) の頭字語) など、新製品のリリースに焦点を当てたものもあります。また、チームのビジネスで発生する主要なメトリクス、トレンド、意見の相違、リスク、およびオポチュニティに関する確認結果やガバナンスを提供する運営上のビジネスレビュー (多くの場合、週次、月次、四半期次) であることもあります。

新しいサービスのリリース前に運用上の準備状況を厳密にレビューし、サービスのアーキテクチャ、そのリリースの質と手順、および関連するインシデントやイベントの管理手順のさまざまな側面が適切に定められ、文書化するために詳細な確認を行うナラティブを用意しています。Correction of Errors 文書などの他のナラティブは、サービスがお客様に悪影響を及ぼした場合に事後的に作成されます。これらの文書は、サービスを所有するチームによって作成されます。責任を追及するためではなく、そのサービスを所有するシングルスレッドチームとして、そのサービスとそのお客様に最も近いところにいて、その知識を豊富に有しているからです。

これらの Correction of Errors (または COE) 文書では、チームは発生した事象を詳細に記述するために深く掘り下げて調査し、サービスの障害の影響とその事象が発生した理由に関連する定量分析とデータを提供します。1 枚ずつレイヤーをはがして根本原因 (すべての寄与要因を含む) を特定し、その根本原因にどのように対処したかだけでなく、二度と起こらないようにするために継続的にどのように対応すべきかを概説します。多くの場合、確認と継続的な改善のメカニズムを更新または作成します。これらの文書は検索可能なデータベースに保持されるため、部門を超えて貴重な教訓を共有できます。