複雑さではなくイノベーションの拡大を学ぶ
今日のビジネスリーダーは、市場に投入する新しいサービスを常に革新し、継続的な業務改善を推進し、エンタープライズの全領域で成長を加速させる能力を組織にもたらしたいと考えています。
15 の市場と 10 の業界にわたる 1,500 名の経営幹部を対象として包括的に調査した結果をまとめた「AWS 2022 C-Suite Report: Cloud Enabled Growth」(AWS 2022 経営幹部レポート: クラウドによる成長) では、今日の経営幹部の半数超が、企業戦略においてビジネスの成長を優先していることが報告されています。これには、既存のビジネス全体にわたる迅速なイノベーションだけでなく、新しい顧客価値、収益源、成長機会の創出も含まれます。
チーム全体が俊敏かつ高速であるようにすることは、成長とデジタルトランスフォーメーションを成功させるために不可欠ですが、実現するのは往々にして困難です。従来の組織構造は、イノベーションの加速を企図したペースには向いていない可能性があります。最初はアジャイルだった企業も、ビジネスの範囲が拡大するにつれて負担が増大し、ビジネスが拡大してより複雑になるのに伴って、プロセスや意思決定で行き詰まりが生じる可能性があります。
企業はますますグローバル化しています。製品とサービスは完全にデジタル化されています。そのすべてを通して、情報力と選択力を得るにつれて、顧客の期待が高まっています。
この変化のペースに対応すると同時に、市場のオポチュニティや混乱に対応する能力を得るには、ビジネスにおける俊敏性が必要です。顧客中心のアプローチを採用する IT リーダーは、それを実現できる条件を作り出すことができます。
「真に高いパフォーマンスを発揮するアジャイルな組織になるには、組織構造を違った見方で捉え、考え方や行動を変えることに積極的である必要があります」
ビジネスの拡大を遂げる中で、Amazon と AWS も例外ではなく、これらのダイナミクスに対応する必要があります。ビジネスユニットの数が拡大し、世界中のワークフォースが急速に拡大し、地理的に分散するにつれて、急速なイノベーションと Day One の精神を維持するために、チームの編成方法を変革する必要がありました。
イノベーションのスピード
Amazon は、ドットコムの時代に創業した多くの企業と同様に、迅速な俊敏性を実現し、絶え間ない価値をお客様に提供することを目的として組織されていました。 ジェフ ベゾスは 1997 年の最初の株主への手紙で、常にお客様を起点に考え、短期的な企業利益を犠牲にしても、お客様のために継続的かつ長期的な価値を提供することの重要性について語りました。常にお客様を起点に考えるというこの習慣を実現するには、毎日目を覚ましたときに、お客様の最も厄介な問題を解決し、お客様のために発明することに心を躍らせる、自律的なビルダーから成る組織構造を採用し、維持する必要がありました。
「採用へのアプローチの基準を高く設定することは、Amazon.com の成功の最も重要な要素であり、このことは今後も変わらないでしょう」と Jeff はしたためています。
これは、ビジネスが e コマースに重点的に取り組み、チームと、迅速なイノベーションを実現するために利用していた技術アーキテクチャがより一元化され、緊密に連携していた初期の頃は容易でした。しかし、時が経つにつれて、Amazon がお客様のニーズを満たすためにビジネスや新たなイノベーションの数を増やしていく中で、業務を遂行できるスピードと俊敏性の低下を感じ始めました。ジェフが 2015 年の株主への手紙で概要を述べたように、「発明マシン」(「規模によって可能になる並外れたカスタマーサービスの能力と、通常は起業家精神にあふれたスタートアップが備えている動きの速さ、機敏さ、リスク受容の考え方を組み合わせる」ことができる会社) であり続けたいという願望に、悪影響が生じ始めたのです。当社の緊密に結合されたアーキテクチャと組織は、当社が望んでいた程度に、または必要としていた程度に迅速に行動するのに役立つものではありませんでした。
速度と効率性の低下に対処するため、当社は技術アーキテクチャをマイクロサービスアーキテクチャと呼ばれるものに根本的に変更しました。モノリシックアーキテクチャを単一のスタンドアロンサービスの広大なネットワークに分離しました。これにより、新しいイノベーションやオファーを迅速に立ち上げ、絶えず変化するお客様のニーズに基づいて既存のサービスのイテレーションを迅速に実行し、お客様のために考案する新しいアイデアを継続的に実験できるようになりました。
しかし、ビルダーがイノベーションを推進するために使用していたテクノロジーを単にオーバーホールするだけでは十分ではありませんでした。また、チームの編成方法を再構築して、お客様やニーズに寄り添い、お客様のために革新的な製品やサービスを迅速にリリースし、マイクロサービスアーキテクチャが提供できる俊敏性とスピードを最大限に活用できるようにする必要がありました。この組織構造は、Amazon の「ピザ 2 枚チーム」として知られるようになりました。
(1967 年に有名なコンピューター科学者である Melvin Conway によって提唱された) コンウェイの法則は、組織の構造とチームがコミュニケーションをとる方法が、テクノロジーとシステムの開発方法に影響を及ぼすことを明らかにしています。
ピザ 2 枚チームでイノベーションを促進する
Amazon のピザ 2 枚チームのコンセプトはシンプルです。すなわち、ピザ 2 枚では足りない大きさのチームを編成すべきではないということです。トッピングの数や性質は脇に置いておいて (ここで「パイナップルはピザに合いますか?」という議論を解決するための時間とスペースはありません)、これは 10 名未満のチームであるのが理想的です。チームが小規模であるほど、お互いの距離が近くなり、官僚的な機構や意思決定で生じるオーバーヘッドが削減されます。これにより、ピザ 2 枚チームは、より多くの時間をお客様に費やし、お客様のために実験やイノベーションに継続的に取り組むことができます。これは、Amazon で高いパフォーマンスを発揮しているチームにとっての最優先事項となっています。
また、チームが小規模であるほど、オーナーシップは強化され、付与される権限も多くなります。これにより、リンゲルマン効果 (大規模なグループで個人の生産性が低下する傾向) を低減できます。チームのリソースが増大するにつれて、メンバーは個人の努力にあまり重点を置かなくなり、自らの負荷を処理する際に他のメンバーを頼るようになります。チームの規模が大きくなると、個人の貢献度は低下します。逆に、チームの規模が小さくなると、個人の努力も増えます。
また、小規模なチームでは従業員の満足度が高まります。従業員の満足度は、今日の組織が最高の人材を引き付けて維持しようと努力する上で重要な懸念事項となっています。Hackman と Vidmar による注目すべき研究によれば、チームの規模が大きくなるにつれて、個人の満足度が低下することが示されています。大規模なチームでは、個人の貢献が認識されにくくなり、特定の領域に対する個人のオーナーシップがより弱くなることがよくあります。
これはワークフォースに関する調査でも裏付けられています。Gallup の「The State of the American Workplace」(米国における職場の状況) の調査によると、従業員が 10 名未満の組織のエンゲージメントレベルは 42% 以上であるのに対し、より大規模な組織の平均エンゲージメントレベルは 30% 未満でした。
しかし、Amazon のピザ 2 枚チームは、規模だけを問題にしているわけではありません。ピザ 2 枚チームの構造で絶え間ないイノベーションとスピードを実現するための重要な要素は、シングルスレッドでの注力を可能にすることです。
ピザ 2 枚チームを選ぶ理由
小規模なチームでは、官僚的な機構を最小限に抑え、お客様のためにイノベーションに注力する時間を最大限に活用できるようになり、これは従業員の満足度の向上につながっています
リンゲルマン効果 (大規模なグループで個人の生産性が低下する傾向) を低減します
チームが迅速に行動し、早い段階で頻繁に実験し、学習した内容を迅速に適用して、継続的にお客様に価値をもたらすことを可能にします
失敗のコストを下げるのに役立ちます – 開発の後半の段階で直面するよりも、早く学習でき、リスクを低く抑えることもできます
オーナーシップをもつ
Amazon と AWS において、ピザ 2 枚チームは、特定の製品やサービスに対するシングルスレッドのオーナーシップを持っています。複雑なシステムを維持したり、複数のサービス、事業部門、または顧客セグメントにまたがる問題を解決したりするのではなく、ピザ 2 枚チームは、ただ 1 つのサービスやオファー、そしてそれを利用するお客様のみに焦点を合わせます。このシングルスレッドのフォーカスは、効率とスケーラビリティを向上させます。ピザ 2 枚チームのロードマップ (必要なトレードオフと優先順位付けを含む) は、自らが担当するサービスとそのサービスを利用する顧客セグメントのためだけに革新することに焦点を絞ったものとなります。
また、2 ピザの構成により、チームの説明責任も強化されます。ピザ 2 枚チームは、自らがリリースしたものを、別のチームに運用してもらうために引き渡すことはありません。このシングルスレッドオーナーシップは、カスタマーエクスペリエンス全体と、ピザ 2 枚チームの製品やサービスのライフサイクル全体に及びます。
そのため、ピザ 2 枚チームは、明確な目的や信念と厳密に定義されたミッションをもって、サービスのあらゆる部分を常に把握している必要があります。サービスが常にお客様にとって価値あるものであるようにするため、チームはお客様に寄り添い、適切な追跡メカニズム、メトリクス、および KPI を作成する必要があります。
また、これを実現するには、サービスをエンドツーエンドで所有して実行するのに役立つように、ピザ 2 枚チームに適切なリソース (エンジニアリング、テスト、製品とプログラムの管理、運用など) が組み込まれている必要もあります。
製品やサービスについての需要が高まる中で、メンバーを増やしてチームを拡大するのではなく、個別のピザ 2 枚チームに分割して、各チームがサービスのシングルスレッドのサブエリアに取り組めるようにする方法を模索しています。この分割により、俊敏性、自律性、およびシングルスレッドオーナーシップを保持する、よりフラットな組織構造が維持されます。
つまり、ピザ 2 枚チームは、規模だけを問題にしているのではなく、オーナーシップと独立性を育み、アイデアの創出から実行、継続的な業務改善から絶え間ない製品のイテレーションやイノベーションに至るまで、チームレベルにまで落とし込むことも重要視しているのです。これは、チームが迅速に行動し、早い段階で頻繁に実験し、学習した内容を迅速に適用して、継続的にお客様に価値をもたらすことを可能にします。また、より迅速なイノベーションや実験は、失敗のコストを下げるのに役立ちます。開発の後半の段階で直面するよりも、早く学習でき、リスクを低く抑えることもできます。
ピザ 2 枚チームの構造は Amazon と AWS では機能していますが、すべての組織やすべてのビジネスユニットに適しているわけではないことも認識しています。ピザ 2 枚チームは完璧ではなく、制限の影響を受けないわけでもありません。とても多くの自律的なシングルスレッドチームが、それぞれのお客様のニーズを満たすために高速に運営されているため、重複やサイロ化された開発のリスクがあることはその一例です。各チームがオーナーシップを持つそれぞれの領域でイノベーションを推進する能力を阻害することなく、純粋に複製的な取り組みをどのようなタイミングで、どのように統合するかを決定するための適切なガバナンス構造を備えておく必要があります。
実験を迅速に行うには、複数のチームで協力して成功の可能性を倍増させ、リソースを合理化する必要もあります。また、失敗から得た教訓を把握して共有し、それらの教訓を将来の実験により適切に応用し、イテレーションの方向性と投資に関する将来の意思決定を微調整する能力はさらに重要です。
Amazon と AWS の組織において、チームが迅速に、独立して、自律的に運営できるようにしながら、ガバナンスと監督を促進するのに役立つ 1 つの側面が、シングルスレッドリーダーという概念です。
ピザ 2 枚チームは、規模だけを問題としているのではなく、オーナーシップや独立性を育み、チームレベルにまで落とし込むことも重要視しています。
シングルスレッドリーダー
今日の経営幹部は、イノベーションとデジタルトランスフォーメーションを迅速に提供できることの大きなメリットを認識しています。新しい製品やサービスを迅速に市場に投入できることは、お客様に一定の価値を提供する上で重要であるだけでなく、企業が差別化を図るための競争上の優位性にもなり得ます。しかし、ビジネスの規模と範囲が拡大する中で、経営幹部は、チームが迅速に業務を遂行できるように、適切な組織とリーダーシップを構築する必要があります。
シングルスレッドリーダーの役割は、チームがお客様のために独立してイノベーションを起こすための権限を維持できるよう、適切なレベルの監督を行う上で不可欠です。
チームのガバナンスと管理には、チームが革新的な実験を進める前の承認や調整のラインを厳しく設定してスピードを低下させる「料金所」ではなく、「ガードレール」、すなわち、チームが迅速に業務を遂行し、質の高い、迅速な意思決定を行うことを可能にするメカニズムを提供する必要があります。
Amazon と AWS において、シングルスレッドリーダーの役割は、適切なレベルの確認と方向性のあるビジョンを実現する一貫したメカニズムを構築しながら、チームがお客様のために独立してイノベーションを起こすための権限を維持できるよう、適切なレベルの監督体制を確立する上で不可欠なものとなっています。シングルスレッドリーダーは、戦略的なビジョンを提示するのをサポートし、その後はチームの邪魔にならないように行動します。チームリーダーは、すべての意思決定で乗り越えなければならない障壁となるのではなく、障害を取り除くのをサポートする必要があります。小規模、アジャイル、自律的で、日々お客様を起点に考えているチームは、自らのサービスと顧客セグメントの第一人者です。
シングルスレッドリーダーは、ビジネスにとって最善の意思決定を行うために、チームの自律性を維持する必要があります。シングルスレッドリーダーがチームの意思決定に関与するのは、多くの場合、適切なデータインストルメンテーションや研ぎ澄まされた判断力があっても、今後の道筋が明確でない可能性がある状況でチームにガイダンスを提供するためです。
Amazon において、シングルスレッドリーダーがこれらのチェックポイントを監督しやすくするために用いられている仕組みの 1 つが、ナラティブと呼ばれる文書です。このような状況でのナラティブは、表面化したお客様側の問題の概要を説明すること、詳細な分析結果やチームが収集したデータからの情報を次のステップに役立てること、チームが推奨する決定事項と、検討された代替方法、それぞれの方法のリスクとメリットを明確に説明することに役立ちます。
時間をかけてナラティブを作成することは、スピードと絶え間ない業務の遂行を維持することに対して直感に反するように見えるかもしれませんが、Amazon と AWS ではナラティブを使用することで、非常に大きなメリットが得られました。1 つは、これらの文書は多くの場合、経営幹部のデスクに届く前であっても、チーム、その関係者、およびチームのオファーや顧客セグメントの対象分野の専門家によって何度も議論され、洗練されているということです。これは、コラボレーションを促進し、多様な視点を生み、前提条件の正しさを検証し、文書内のアイデアや推奨事項を洗練するのに役立ちます。最終的に、これは多くの場合、より質の高い意思決定につながります。
Amazon におけるナラティブの役割
Amazon と AWS には多くのさまざまなナラティブがあります。私たちの Working Backwards アプローチから生まれる PR/FAQ 文書 (Press Release (プレスリリース)/Frequently Asked Questions (よくある質問) の頭字語) など、新製品のリリースに焦点を当てたものもあります。また、チームのビジネスで発生する主要なメトリクス、トレンド、意見の相違、リスク、およびオポチュニティに関する確認結果やガバナンスを提供する運営上のビジネスレビュー (多くの場合、週次、月次、四半期次) であることもあります。
新しいサービスのリリース前に運用上の準備状況を厳密にレビューし、サービスのアーキテクチャ、そのリリースの質と手順、および関連するインシデントやイベントの管理手順のさまざまな側面が適切に定められ、文書化するために詳細な確認を行うナラティブを用意しています。Correction of Errors 文書などの他のナラティブは、サービスがお客様に悪影響を及ぼした場合に事後的に作成されます。これらの文書は、サービスを所有するチームによって作成されます。責任を追及するためではなく、そのサービスを所有するシングルスレッドチームとして、そのサービスとそのお客様に最も近いところにいて、その知識を豊富に有しているからです。
これらの Correction of Errors (または COE) 文書では、チームは発生した事象を詳細に記述するために深く掘り下げて調査し、サービスの障害の影響とその事象が発生した理由に関連する定量分析とデータを提供します。1 枚ずつレイヤーをはがして根本原因 (すべての寄与要因を含む) を特定し、その根本原因にどのように対処したかだけでなく、二度と起こらないようにするために継続的にどのように対応すべきかを概説します。多くの場合、確認と継続的な改善のメカニズムを更新または作成します。これらの文書は検索可能なデータベースに保持されるため、部門を超えて貴重な教訓を共有できます。
重要ポイント
ピザ 2 枚チームの構造とメカニズムはすべての組織に適しているわけではありませんが、経営幹部は、俊敏性、スピード、イノベーションの文化を企業全体でより強化できます。これらの経営幹部は、チームレベルで自律性を高め、オーナーシップを強化する方法を検討し、質の高い独立した高速な意思決定を可能にする指針を提供できます (Amazon のリーダーシッププリンシプルはそのような例の 1 つです)。
チーム構造と、その構造がチームの技術アーキテクチャを活用する能力をどのように最適化するか (あるいはその逆) について熟考することは、お客様のニーズを満たす新たなイノベーションの柔軟性、俊敏性、市場投入までの時間を短縮するのに役立ちます。(技術面と管理面の両方の) 依存関係や制約からより切り離されたチームが活用するクラウドマイクロサービスは、市場の変化により迅速に対応し、得られた教訓に基づいてイテレーションを実行できるようにします。
各チームが解決を求められている問題を単純化および合理化して、チームがシングルスレッドにより集中できるようにすることで、イノベーションが加速するとともに、チームが自らのお客様を理解し、これらのお客様のために発明することに多くの時間を費やすことができるようになります。
最後に、経営幹部は、チームが新しいアイデアを出し合えるよう、綿密な仕組みをチームに提供できます。失敗を発明の必要な部分として受け入れる姿勢を保つことで、大胆な実験を促すことができます。また、適切なレベルのシングルスレッドリーダーシップとガバナンスをもって、チームが教訓を把握して共有し、今後の実験をより良いものにしていけるようにすることができます。
これは、企業が「発明マシン」となるのに役立ち、新しいビジネスを成長させるための継続的な手段を提供し、お客様を驚かせて喜ばせ、お客様のために発明することを可能にする真の差別化要因をもたらします。
開始方法
合理化されたサービス、オファー、または顧客セグメントに対するシングルスレッドオーナーシップにより、小規模で自律的なチームを強化する方法を模索します。
シングルスレッドリーダーがいるチームを率いて、意思決定のボトルネックとなるのではなく、障害を取り除いてチームが継続的に実験できるようにすることに専念します。
自律的で質の高い、迅速な意思決定を行うための指針をビルダーに提供する、一貫性があり分散性の高いメカニズムを構築します。
高いスピードと俊敏性を維持し、確実にお客様を起点に考えるようにするために、リーダーに適切なレベルの確認とガバナンスを設定させ、継続的な実験と、失敗から得た教訓の共有を奨励します。
「...発明はすべての真の価値創造の源です。そして、創造された価値はイノベーションのメトリクスと考えるのが極めて適切なのです」
著者について
AWS、イノベーションの文化担当責任者 (ワールドワイド)、Daniel Slater
Dan Slater は AWS のデジタルイノベーションチームの一員として、イノベーションの文化を監督しています。Dan は 2006 年に Amazon に入社し、同社初の D2C デジタルコンテンツサービスを立ち上げました。彼は、Kindle デバイスと Kindle のグローバルコンテンツマーケットプレイス、および Amazon の自費出版サービスである Kindle ダイレクトパブリッシング (KDP) の立ち上げを支援しました。Dan は、トップ 60 の貿易出版社のデジタルビジネスを監督した後に、KDP のコンテンツ獲得、需要創出、ベンダー関係などの仕事を主導しました。Amazon に入社する前は、Simon & Schuster と Penguin で上級買収編集者を務め、出版 IT 企業 (Vista、現 Ingenta) の営業を主導していました。カナダのトロントで生まれた Dan は、妻と 2 人の子供と一緒にシアトルに住んでいます。Dan はデューク大学の Fuqua School of Business で MBA を取得し、コーネル大学で 2 つの文学士号を取得しました。
関連資料
顧客中心のイノベーションの必要性
Amazon での製品管理
