1.この記事を書こうと思った背景

チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 (通称、ちいとぽ本）を読み進めていくうちに、以下の疑問を抱くようになった。

Amazon社のピザ２枚ルール、チーム間のコミュニケーションは、インターフェイスを通して行うことというルールは実際にどんなかんじにされているのか？ 気になる。

Teams must communicate with each other through these interfaces.

出所：AmazonのAPI設計方針 (The Bezos Mandate) - Qiita

明確な答えを導き出したわけではないけれども、考えを深めることができたターニングポイントとなったのが、タイトルで触れているインタビュー記事、A Conversation with Werner Vogels - ACM Queue を読んだことだった。また、先にお伝えしておくと新たな疑問も抱くようになったので、インタビュー記事を読んで学んだことと新たな疑問について書き留めておきたい。

インタビュー記事を知ったきっかけ

左記のインタビュー記事を知ったきっかけは、Team Topologies(by Manuel Pais)のキーポイント を読んだことである。この記事は書評記事ではないが、同書の趣旨を理解する上でも大きな助けとなった。“A Conversation with Werner Vogels"をご紹介いただき、ありがとうございました！

2.“A Conversation with Werner Vogels - ACM Queue"を読んで学んだこと

  • 各サービスの構成メンバーは 利用ユーザーの目的やニーズに応えることにフォーカス するべきだということ
    • ↓の例だと、デベロッパーの関心事はアプリケーションを開発することであり、アプリケーションを開発するために内部的に生成されているURLがどうやって構成されるのか？には関心がないということ。責任共有モデルが各サービス間で徹底されているということ。

Do we see that customers who develop applications using AWS care about REST or SOAP? Absolutely not! A small group of REST evangelists continue to use the Amazon Web Services numbers to drive that distinction, but we find that developers really just want to build their applications using the easiest toolkit they can find. They are not interested in what goes on the wire or how request URLs get constructed; they just want to build their applications.

出所：A Conversation with Werner Vogels - ACM Queue

  • 利用ユーザーの目的達成に必要なツールを提供するけれども、そのツールの使い方は限定しない、多くの選択肢を与える。
    • 目的達成に必要なツールの提供と選択肢の多様性は相反するのでは？と思っていた。しかし、IDEの例を読むと、そのツールというのは、ツールはユーザーを選ばないと言えそうだと思った。
  • ユーザーの利用環境問わず、目的を持つユーザーに対しては誰でも利用することができるべき！ツールはできるだけ世の中の デファクト・スタンダードに則った仕様 にしなくてはいけない！など次に考えるべきことがアタマに浮かんだ。

3.新たな疑問

  • エンジニアの採用において、どういった方を採用したいか？という質問に対する回答として挙げている、顧客至上主義 の顧客について。ここでの顧客とは、Amazon.com のエンドユーザーに限らず、Amazon.com の内部サービスを利用する開発者や、小売パートナー、AWS の協業ベンダー も含まれている？
    • そうでないと、上記で挙げた利用ユーザーの目的やニーズに開発者はフォーカスするべきだという、目的達成に向けた考え方とズレてしまう
  • 顧客至上主義と選択肢の多様性、デファクト・スタンダードへの適応。この3つの塩梅が難しく、現実的な折り合いはどうつけているんだ？？

A very important point is whether candidates think the right way about customers and technology. Technology is useless if not used for the greater good of serving the customer. We are a strongly customer-oriented company, and we often use the “working from the customer backwards” approach. This means that in your thought process, you start with the customer and work your way backwards until you have found the simple and minimal technology that you need to satisfy the new customer requirement. It is important that engineers who come to work at Amazon understand that we do not build technology for technology’s sake, but to support the customer.

出所：同上

4.おまけ

最後にインタビュー記事では取り上げられていないけれど、Amazon.com におけるデータベース移行事例 を紹介したい。AWS SAP試験対策のためデータベースの移行事例の資料として読んでいたが、顧客至上主義と選択肢の多様性、デファクト・スタンダードへの適応の塩梅という観点で眺めるとまた違った学びが得られそうと感じた。

とりわけ、以下2つのスライドを読んで、顧客至上主義＝顧客の利益最大化という目的の達成を目指しつつ、社内のステークホルダーとの目線合わせ、落とし所を探っているのだろう？と考えた。スライドのスクリーンショットなどは避けたいのでスライドのタイトルでの共有とする。

  • 戦略#2 経営陣のサポートを加速 (1/2) (33/51)
    • 社内から技術支援などを仰ぐために、数字を可視化
  • 戦略#3 FUD と実際の技術的課題に対処 (36/51)
    • 社内 Oracle DBAとの対話、協調

    • Oracle DBA に新たなキャリアパスとトレーニングの機会を提供

      • 移行に伴い、移行前のポジションの消失という懸念払拭。移行そのものの技術的障壁ではない課題への対策 も練っているところがミソだと感じた