eコマースの巨人Amazonの創設者であるJeffBezosが、一度に8〜10人以上の人と会議を開かないようにする方法についての教訓はよく知られています。 これは、2ピザルールとして知られています（会議の参加者を養うことができなければなりません）。
小規模な作業チームに基づくAmazonの構造は、ライバルに欠けていた敏捷性を会社にもたらしました。
「Amazonの2つのピザチームは機敏で、柔軟なチーム間構造を開発し、明快さや目的を提供し、革新が早いです。 また、自律性も高く、Amazonは一般的にAndroidの会社ですが、PrimeNowチームは最初にiPhoneでパイロットを開始することができました。 チームのワークロードが大きくなりすぎると、Amazonは敏捷性を維持するために、チームを複数の小さなチームに分割することを決定する場合があります」と、ロビン・ガスターは「Amazon Rising：Power and Seduction in the AgeofAmazon」で説明しています。
アマゾンの成功の鍵は、その小さなチーム構造にあります
各従業員は、自分の通常のチームの内外で自由にサポートとバックアップを求めることができます。 コマンドのチェーンを明確に定義しているため、アイデアを実装するには、コマンドのチェーンを上に移動する必要がある従来の企業とは異なり、Amazonではそうではありません。
この本は、決定が財源や法的な問題を伴う企業では、会計士や弁護士に相談しなければならないことを示しています。 そして、プロセス全体を通して、拒否権の無限の機会があります。
対照的に、Amazonは「イエスへの複数の道」を提供しています。 人々は自分のチームや部門の外に出て、アイデアに興味のあるチームを見つけることができます。 チームは、プロジェクトを後援およびサポートするシニアリーダーをいくつでも見つけることができます。
アマゾンがイノベーションを容易にするわけではありません。 しかし、Amazonの構造はそうなるように設計されている、と著者は私たちに保証します。
Amazonの作業プロセスはどのように見えますか？
アマゾンでは、イノベーターはプロジェクトが何のためにあるのか、誰にサービスを提供するのか、そしてなぜ特に顧客が利益を得るのかについての明確なビジョンを開発するために後方に働き始めます。
プロジェクトが具体化し、プロジェクトに価値があるという証拠が追加されると、元のチームの内外からより多くのリソースを引き付ける可能性があります。 これには、ロジスティクス、人材、広告などの他の分野からのパートタイムの支援が含まれる場合があります。
このフェーズでは、プロジェクトは既存の構造からのアクションラインを使用してリソースを追加します。 人事担当者は才能の獲得を支援しているかもしれませんが、既存のチーム内にとどまります。 APIを介して情報フローを管理するというAmazonの以前の決定により、より多くの情報リソースが利用可能になります。 新興チームは、承認を求めることなく情報にアクセスできます。
ある時点で、プロジェクト/チームはパイロット生産に移行するための青信号を取得します。 それには、より多くのリソースと、より焦点を絞ったチームの作成が必要です。
Neil Ackermanは、前述のテキストで、Small and Light Fulfillmentプロジェクトのチームを構築し始めたとき、Amazonの内部ディレクトリから必要なチームメンバーを探し、数週間の作業で「多数のコーヒーミーティング」について連絡したと説明しています。 。 彼は最終的に新しいチームへの参加を求めた7人のうち、3人が受け入れ、4人を外部から採用しました。
プロジェクトがより成功するにつれて、Amazonの全体的な階層における彼の位置は落ち着きつつあります。
それはもはや実験のパイロットではありません。 現在は既存のサービス内のサービスです。 このように、アッカーマンの小型軽量プロジェクトは、市場のニーズに応えるための成功したツールとしての地位を確立しました。
時が経つにつれて、Amazon Retailの利用を引き付け、現在はAmazonのロジスティクスネットワーク内の永続的なサービスであり、一連のコマンドを通じてレポートを作成し、標準のOP1メカニズムを通じて資金を提供しています。 プロジェクトが統合されると、チームはAmazonエコシステム内で完全に独立したエンティティになります。
小さなチーム構造の違いは何ですか？
主な違いは、Amazonの内部環境は、チームの継続的な形成を促進するように設定されており、チームが迅速に前進できるようにする重要な先行リソースを提供することです。
もちろん、これを実現するには、イノベーションを期待し、さらには要求するリーダーシップと、初期段階で十分な「肥料」を提供するための構造、プロトタイピングとテスト段階での十分なサポート、および最終段階での十分な明確な経路が必要です。可決。
少なくともAmazonで（そして理論的には少なくとも）チームの構造上の利点は、チームを増やすことができることです。 新しい内部構造や直属の部下を追加せずに新しい製品ラインを追加でき、会議やプロジェクト、ロジスティクスおよびeコマースプラットフォームのプロセスを必要とせずに追加できます。
もちろん、この画像はやや理想化されています。 小さなチームもリソースとプロジェクトをめぐって競争するため、別の観点から、Amazonはチームがプロジェクトとイニシアチブを競うダーウィン環境を作成しました。 すべてに資金が提供されているわけではないので、当然、勝者と敗者がいます。 この非常に競争の激しい環境は、Amazonがチームに革新を促すもう1つの方法です。
最後に1つ注意してください。 小規模なチームが可能なのは、Amazonが初期の頃から、他のAmazonチームだけでなく、部外者とも電子的に情報を共有することをすべてのチームに要求していたためです。 この重要な要件により、何百ものチームが接続できるようになります。 そうしないと、情報過多、電子メールやメッセージングなどの手動による通信の時間とリソースのコストに溺れてしまいます。