詳細調査 シリコンバレー内外の企業は、機能や機能性を迅速に開発および展開するための独自の方法を見つけています。
しかし、この Web 大手の巨大なクラウド モンスターである Amazon Web Services の内部には、特定の弱点を受け入れて最大速度を達成する「Away Teams」という概念に基づく特別な消化器系が存在します。
El Regは数ヶ月にわたり、このプロセスの現場を実際に体験した12人ほどの人々にインタビューを行い、その内容をここに公開します。情報提供者はAmazonについて公に発言する権限がないため、匿名とさせていただきます。この米国巨大企業の公式広報担当者は、私たちの調査結果についてコメントを控えました。
Amazonのような大規模組織の実態を把握するのは常に困難です。同社はリーダーシップ原則は公表していますが、マネジメントシステムについてはこれまで公に体系化していません。しかし、この図は、大規模な技術開発の調整を目指す人々に新たなアイデアをもたらすかもしれません。
問題
エンジニアや技術スタッフが数百人、数千人規模になると、組織はチームレベルで機能するあらゆる業務を超過してしまいます。混乱したシステムが本番環境に移行した際には、20、50、あるいは100のチームが互いに支援し合えるような仕組みを何らかの形で見つける必要があります。
Agile、Scrum、DevOps の手法は、特定のプロジェクトを構想から提供までスムーズに進め、進化させ続けますが、多数のチームの作業を調整し続けることはできません。
プラットフォームやアプリケーションの一貫した設計を作成することは、もちろん根本的な問題であり、そのような設計を実装するためのプロジェクトを組織化することも同様に重要です。しかし、最初はどれだけうまくいったとしても、調整は必要です。
それぞれのチームは、特定の目標を達成するために設立されました。それぞれのチームには、個別の損益計算書（P&L）や、目標と主要な成果（Intelの活用にヒントを得てGoogleが採用した有名なOKR）があるかもしれません。しかし、現代のプラットフォームでは、全体を構成するほぼすべてのサービスが相互に連携します。
誰かがあなたのキューブにやって来て、提供しているサービスの新機能やバグ修正、パフォーマンスの最適化について尋ねてきたら、どうしますか？ソースコードへのアクセスを許可しますか？新機能がユーザーや顧客に好評だった場合、それを自分のチームで保持しますか？それとも、より自然な形で機能するチームに提供しますか？もしあなたのチームが、他のチームの収益向上に役立つ機能を追加できる場合、承認済みのロードマップよりも先にそれを実行すべきでしょうか？
このような問題は簡単に解決でき、誰もが正しいことをするだろうと考える人は、現実世界の大規模な組織で働いた経験がありません。
もちろん、優れた経営陣はチームの連携を助けるために介入すべきです。しかし、経営陣の注目を求めると、物事は遅くなります。そして驚くべきことに、経営陣が常に正しい判断を下すとは限りません。
アマゾンの社内コラボレーションシステム
Amazon は創業以来これらの問題に直面しており、サービス指向アーキテクチャの原則 (インターネット企業の大成功の要因となった管理革新を成文化するための重要な追加要素を含む) に基づくシステムを構築してきました。
Amazonの消費者ビジネスは、最後のOracleデータベースの廃止を、スタッフの静かなパーティーと大きな赤いピニャータで祝う
続きを読む
スタンフォード大学の研究者、起業家、AI専門家のアンドリュー・ン氏は、2017年にサンフランシスコで開催されたAIカンファレンスでの講演で、真のインターネット企業とはウェブサイトを持つショッピングモールではなく、短いサイクルタイム、A/Bテストを採用し、意思決定を後回しにする企業であると説明した。
Amazonはここで車輪の再発明をしているわけではない。多くの企業が直面している問題に着目しているのだ。しかし、この問題を解決する興味深い方法を見つけたようだ。Amazonは、独立して管理されるサービス群を中心に開発を組織化し、A/Bテスト、後付けの意思決定、そして斬新なコンセプト「アウェイチーム」を活用した綿密に構築されたコラボレーション文化に基づいた魅力的なポリシーセットを適用することで、社内コラボレーションを最適化するシステムを構築している。
結局のところ、Amazon のシステム、特に Away Teams は、レイ・カーツワイルによる技術の指数関数的進歩の説明や、MIT のエリック・フォン・ヒッペル教授によるユーザー主導のイノベーションの力に関する観察など、技術哲学者の発見と一致しています。
イェッゲの暴言からサービス指向のコラボレーションへ
アマゾンのCEO、ジェフ・ベゾスの行動から私たちが知る限り、彼は強制機能の大ファンであり、CEOの観点から言えば、それは特定の種類の変更を義務付ける上からの命令である。
ベゾスは、自身の魅力、成功のオーラ、そしてCEOとしての権力を駆使して、会社に変革を迫ってきました。Amazon.comに自社のドッグフードを摂取させ、AWSの利用を強制したのも、まさにその一つです。AmazonをOracleから完全に移行させようとした動きもその一つですが、その発起人はAWSの責任者であるアンディ・ジャシーかもしれません。しかし、私が最も気に入っているのは、後に「Yegge Rant」として知られるようになったサービス指向アーキテクチャ（SOA）への移行です。
アマゾンで数年間勤務した後、グーグルに移籍したグーグルのエンジニア、スティーブ・イェッジ氏の話によると、ベゾス氏は2002年頃、アマゾンの社員全員に対し、各部門のサービスをAPI経由で公開するよう要求したという。イェッジ氏の投稿（現在は廃止されているGooglePlusに関するもの）には、この強制的な機能によって、サービス指向アーキテクチャのデバッグ、社内ユーザーが全員、トラフィックを急増させる可能性のある無意識のDOS攻撃者となる可能性がある状況での適切なパフォーマンスの維持、運用サポートの対応、利用可能なサービスの把握など、技術的および運用上の問題に対処するための膨大な労力が費やされたと記されている。なお、イェッジ氏はこの投稿についてすぐに反省した。
しかし、強制機能は計画通りに機能し、興味深い原則を持つサービスを中心とした技術文化を生み出しました。複数の情報源から検証することはできていませんが、そのような原則の一つは、あるチームがAPIの唯一のユーザーになった時点で、たとえそのサービスを最初に開発していなくても、そのチームがそのサービスのオーナーになるというポリシーです。
しかし、成熟したサービス指向アーキテクチャ（SOA）のためのテクノロジー、ツール、運用だけでは、社内コラボレーションの問題を解決することはできません。Amazonはまさにこの点で、特に「アウェイチーム」というコンセプトで新たな境地を切り開きました。The RegisterはAmazonがこのシステムに名前を付けているかどうかは知りませんが、「サービス指向コラボレーション」という言葉が適切だと考えています。
