AWS開発文化のベースとなる分散チーム: 組織構造からイノベーションを加速させる仕組み【AWS re:Invent 2023】

• keyboard_arrow_down はじめに
• keyboard_arrow_down Amazonのミッションからつながるプロダクトマネージメント
• keyboard_arrow_down AWSの分散チームとそれを支えるメカニズム
• keyboard_arrow_down 分散チームのリスク対策
• keyboard_arrow_down おまけ
• keyboard_arrow_down まとめ

レバレジーズ株式会社 テクノロジー戦略室室長の竹下です。

2023年11月27日 ~ 2023年12月1日に、ラスベガスで開催された「AWS re:Invent 2023」に、現地で参加してきました。この記事では、現地で聴講したセッションの一つの「AWS product innovation approach: Bring your best ideas to life faster」を元に、AWS開発文化のベースとなる分散チームの仕組みについて解説します。

AWSのチームはどのように顧客にフォーカスしながら、素早くイノベーティブなプロダクトを生み出し続けることができたのか。そのメカニズムを組織の観点から紹介します。日本の開発文化と比較を行いながら、どのようにして分散した小規模チームでの開発体制を維持しているかを紐解いていきたいと思います。

また、この記事以外にもAWS re:Invent 2023に関する技術ブログも書いているので、興味あればLeverages テックブログの記事もご覧ください。

Amazonは、”to be Earth’s most cutomer-centric company” – 「Amazonは、地球上で最もお客様を大切にする企業」をミッションに掲げており、その理念が組織の隅々まで行き渡っています。セッションでは、登壇者のKristenさんが過去に、Amazonでドラムセット頼んだらチューバが入ってたのでカスタマーサービスに連絡した所、数時間でドラムセットを送ってくれたというエピソード紹介がありました。（普通ドラムセットとチューバは間違わないだろうと思いますが笑）カスタマーサービスのオペレーターにまでミッションが浸透していることの証左になっているかと思います。[1]

もちろん、AWSのプロダクトマネージメントにもこのミッションは浸透しています。昨今日本でもベンチャー企業では、ミッション、ビジョン、バリュー、クレドを定義する会社が増えてきていますが、こういった理念の浸透に頭を悩まされているマネージャーや経営者もいるかと思います。では、AmazonはどのようにAWSのプロダクトマネージメントにミッションを融合させることに成功しているのでしょうか？

まず、ミッションを達成するために、Innovationが重要だと考えられています。そのInnovationを支える柱として、「Culture（カルチャー）」、「Architecture（アーキテクチャ）」、「Mechanisms（メカニズム）」、「Organization（組織）」の4つが挙げられます。

Innovationを起こすには、お客様を的確かつ素早く理解することが重要であり、限りなく小さなチームで、特定のお客様にフォーカスできる独立したチームである「分散チーム」にしていく必要があります。分散チームで数多くの実験を繰り返し、そこからお客様が何を望んでいるのかを学び続けることが重要です。実際にAmazonは、成功失敗かかわらずこれまで数多くのサービスをリリースしてきました。Prime wordrobeやEcho lockなどリリースしたものの、今では廃止されているサービスも数多くありますが、それらからも顧客のニーズを学んで来ています。

[1] – Amazonでは間違った商品が届いた場合、間違った商品はそのままもらえるというのは有名ですが、チューバももらえたそうです。さすがに持て余したのか中学校のバンド部に寄付をしたというのですが。

AWSでは、分散チームを維持し、組織化するために数々のメカニズムを用意することで、素早く独立した状態の維持を支援しています。

2 Pizza rule（ピザ2枚ルール）

チームのサイズに関して、AWSは2Pizza ruleを採用して徹底した小さいチームを維持しています。2Pizza ruleとは、チームのサイズはピザ2つを分け合える人数以内にしましょうというルールで、大体6~8人程度[2]になります。6人の時はお互いにコミュニケーションを取る場合のコミュニケーションパスは15パスですが、10人だと45、15人になると105と、人数が増えるにつれコミュニケーションパスが増大して、認知負荷が高くなってしまいます。その結果、コミュニケーションコストが高くなり作業効率が落ちたり、コミュニケーション不足が続き、心理的安全性の低下や情報の不均衡に繋がったりします。

[2] ダンパー数として、コアな関係を築ける5人~少し親しさが薄れる10人という数が知られており、この範囲内にチーム人数を収めることは、関係性を築く上で科学的にも合理的な人数となっています。

Tenets（原則と信念）

各チームには、原則と信念を記載したシンプルな意思決定のためのガイドラインが定められています。そのチームが何を大切にするかが記載されており、複数の選択肢が出てきた場合にどの選択肢が良いかを素早く判断したり、間違った方向に進みそうになった際の軌道修正に使われます。

Single-Threaded Owner/Team（シングル・スレッドなチーム構成）

基本的に意思決定はそのチームで完結できるようになっています。1つのチームにドメインエキスパートとテクニカルエキスパートが所属し、すべてのことを自チームで決定し、チームで実行できるようにしています。チームに所属する人も、そのチームが携わるサービスによって千差万別で、そのサービスを実現するために必要な職種の人が集められています。

一方で、スクラム開発における「プロダクトオーナー」がSingle-Threaded Owner/Teamのアンチパターンとして挙げられています。スクラム開発では、チーム外にステークホルダーとしてプロダクトオーナーが存在します。そのため、その体制自体が既にチームが独立して判断を行うことを妨げてしまっているためです。

また、分散チームを成り立たせるには、プロダクトマネージャーも重要な役割です。Amazonでは様々なバックグラウンドを持ったプロダクトマネージャーが働いています。AWSのプロダクトマネージャーには、特定の経験やスキルを持っていることが求められていません。分散チームを維持し、お客様のニーズを学び続けるために、チーム内における多岐に渡る役割が求められます。そして、Single-Threaded Ownerの原則に則って、チームの中で完結したオーナーシップを持つようになっています。一般によくある、プロダクトリーダーがいて、そのリーダーが何人ものプロダクトマネージャーの報告を受け取るという組織構造は、独立したチームを阻害するアンチパターンとして挙げられています。

分散チームが実現したとしても、すべてが上手くいくわけではありません。分散チームの仕組みにも、様々な欠点があります。例えば、

• ・複数のチームが同じような決断をし同じものをつくってしまう
• ・完成するまで結果が見えづらい
• ・全部できてから失敗すると大きな損失を被ることになる
• ・etc.

これらの課題に対して、AWSが取る対策や考え方が紹介されています。

Risk of Duplication（重複のリスク）は無視する

すべてのチームが独立して判断をするということは、時には同じようなものを複数のチームがつくるリスクをはらみます。通常の企業だと、全体最適を考えてチーム間の連携を取って一つのサービスをつくるようにする所を、AWSはシンプルに（チーム間の調整などによって）「何もつくられないより、2つ同じものが出来てお客様に価値を届けられることのほうが良い」と割り切っています。

Minimum Lovable Product（MLP）へ分割してリリースする

Minimum Viable Product（MVP）というのは聞き慣れていると思いますが、AWSではMinimum Lovable Product（MLP）という単位を採用しており、リリース単位をこのMLPの単位に分割してイテレーションしています。MVPは顧客に価値提供できる最小単位という意味ですが、MLPは顧客に十分に喜ばせられる最小単位を指します。機能を小さく分割してリリースすることで、すべてが出来てから成功失敗の判断を行うより、リスクに早く気づくことが出来、顧客のフィードバックから学ぶことで軌道修正も行えるようになります。

Batch Funding（小さい単位の資金調達）を行う

予算も、年間予算で確保するのではなく、MLP単位の短い期間で投資枠が確保されます。MLPで出した結果が良ければ次の投資を受けられますが、結果を出せない場合は投資が打ち切られることになります。この仕組みにより、財務上のリスクも低下させています。

AWSの特徴的な文化もセッション中に出ていたので、いくつか簡単にご紹介しておきます。

Our Leadership Principle (OLP)

Amazonは、リーダーシップを重要視しており、全社員にリーダーシップを持つことを求めています。採用の時にも重視され、入ってからも常にOLPに従った行動を起こすように指導されます。実際採用ページにも用意されており、もしこの記事を読んでAWSの採用を受けようと考えている方がいれば、しっかりと読み込んでおくと良いと思います。

Press Release ドキュメント

有名な「Amazonはパワポ禁止」というルールに関連しており、企画を提案する場合は以下の順につくっていきます。

1. 1. Press Releaseの模したA4 1,2ページ程度の資料の作成
2. 2. FAQsページを模した、カスタマーの質問に答える資料の作成
3. 3. サービスの見た目を説明するヴィジュアル資料の作成

AWSでは、Amazonの掲げるミッションの実現のために分散チームという組織構造を取っており、分散チームを支えるメカニズムが用意されており、分散チームの体制が維持できています。その結果、組織規模が巨大になった今でも、様々なサービスを高速で実現し、イノベーティブなプロダクトを生み出し続けられています。

この記事は、分散チームに焦点を当てて解説をしましたが、本セッションはAmazonのお客様に対する執着だったり、素早く動くためのメカニズムだったりと盛りだくさんとなっているので、この記事で興味が湧いた方はぜひ動画も視聴してみてください。