dimeizaのブログ

興味のある技術(IoT/VR/Smart Speaker)とか、資格試験の話とか、日常で出会ったTechな話について書いています。

Developers Summit 2018【16-C-6】The Amazon Way～Amazonのソフトウェア開発～ 聴講メモ

Developers Summit セミナー聴講メモ

講演資料

　資料公開予定なし。

概要

　外部から伺い知ることが少ない、Amazonのソフトウェア開発の姿について、特にAmazonのバックボーンであるカルチャーを中心に紹介する。

スピーカー

　Amazonの西谷さん。

詳細

  • 今日は、ソフトウェア開発の手前のところ、カルチャーの話をしたい。

The culture of Innovation

  • イノベーション、インベンションがクリエイティビティを開放する、という言葉がAmazonにはある。

  • ミッション

    • 地球上で最もお客様を大切にすること
      • ここでお客様とは、ものを買う消費者だけではなく、販売者、企業、コンテンツクリエイターも含む。
    • 安心感をもたらす
      • お客様の生活を楽にする、というコミットメントに根ざしている。
    • 常にお客様を起点に行動する
      • ミッション、コミットメントのスタート地点として。

  • Customer Obsessionという考え方。

    • Obsessionという言葉の訳は難しいが、お客様への執心、執着というニュアンス。

  • 顧客重視と長期的視点

    • 創業時から一貫して変わっていない。
    • 1997年の株主向けレターにおいて既に明言されている。
      • お客様への徹底的なフォーカス。
      • 長期的視点での投資を継続。
    • 売上は成長し続けているが、純利益自体はフラットに推移している。
      • 得た利益を次の投資として回し続けているということ。

イノベーションの例

  • こうした投資の結果、いろんな領域でイノベーションを起こし続けている。

    • Amazon Dash Button

      • 汎用的なボタンだけではなく機器に組み込まれたボタンなどもある。

    • Amazon倉庫内の流通システム。

      • 商品を搭載した、たくさんの棚が自律的に可動している。
      • 各棚の軌道計算、衝突回避はAWSで行っている。

    • 配送システムも刷新し続けている。

      • ドローンによる配達の実証実験とか。

    • 最近だとAmazon go。

      • シアトルにある実店舗。
      • レジで会計せずに品物を買える。

    • ただ、国ごとに差があって全てのイノベーションを同時に実現することは難しい。

創業時のコンセプト

  • 紙ナプキンのスケッチ。以下の要素が配置された図。

    • Selection(品揃え)
    • Customer Experience(顧客満足)
    • Traffic(トラフィック)
    • Sellers(売り手)
    • Lower Cost Structure(低コスト構造)
    • Lower Price(低価格)

  • 以下の循環の中で成長する。

    1. Selection(品揃え)の実現でCustomer Experience(顧客満足)が向上する。
    2. Customer Experienceが向上するとTraffic(トラフィック)が増える。
    3. Trafficが増えるとSellers(売り手)が増える
    4. Sellerが増えるとSelectionが増える

  • また、以下の構造も含まれている。

    1. Lower Cost Structure(低コストのオペレーションの実現)がLower Price(低価格化)をもたらし、
    2. Lower PriceがCustomer Experienceにつながる

  • AmazonやAWSの社員も普段から親しんでいて、AWSも同様の考え方になっている。

イノベーションのための組織づくり

メカニズム

  • PRFAQ(PR+FAQ)

    • 新しいプロダクトの開発時にプレスリリースから書き始める。
      • 主題、副題、サマリ、課題、解決、引用など。
    • 製品の具体的なアイデアとデータを提供する。
    • FAQも事前に準備する。 　
    • こうしたプレスリリースを書くための研修が社内にある。

    • もちろん初版をそのまま使うことはない。

      • 書いて、見てもらって、リバイスして、プロダクトにつなげる。

    • どういったものを作って誰に売るかというDecisionの後押しをすることが目的。

      • 誰に何を売るかわかりやすくする効果がある。

  • プレゼン文化はない。

    • アマゾンにはプレゼンを使った会議はほとんどない。
      • プレゼン形式だとプレゼンターの喋りが上手ければ、内容も良く聞こえてしまう。
    • Amazonで複数名で検討を行う際には、6pagerと呼ばれるレポートを使う。
      • ファクトベースの数ページのレポートを先に配布し、
      • 数分間読んでもらい、
      • その後ディスカッションする。

アーキテクチャ

  • いわゆるマイクロサービスとセルフサービスプラットフォーム。

    • セルフサービスプラットフォームがAWSの元になった。

  • 2001年頃、Amazonが大きくなる中で、アプリのモノシリック構造が問題になった。

    • 大量のディベロッパーが１個のアプリを構築し、1本のラインでデプロイするプロセス。

      • ちょっとした修正も重厚長大なパイプラインを通さないといけない。
      • アプリ一つ(機能一つ)デプロイするのに全体更新が必要だった。

    • 解決策としてはいわゆるマイクロサービス。

      • そしてDevOps。
      • この辺りは組織とも切り離せない。

組織

2 Pizza Team

  • Amazonのチームは2 Pizza team。

    • ピザ2枚でまかなえる人数がちょうどいい、という発想。
    • アイディアを早く形にしてフィードバックにすばやく対応するには、大規模な組織ではなく少数精鋭でやったほうが効率的。
    • AWS含め様々なプロジェクトで適用されている。

  • こうして作られた2 Pizza teamは、作るものに対するすべてのオーナーシップを負う。

    • プロダクトの計画策定　ロードマップ
    • 開発
    • 運用、カスタマーサポート

  • "You build it, You run it."

    • AWSのCTO(Werner Vogels)が言った。
    • 『Devが作ったものをOpsに投げつけて忘れてしまう』のはやめようという話。
    • なので、DevとOpsを隔てる壁がAmazonにはない。
    • 自分で作ったものは自分たちで動かし、面倒を見る。
      • 小さなチームで独立して全てを見る。

  • という観点で見ていくと、こんな問答になる。

    • QAは誰がやる？
      • 2 Pizza team。
    • オンコール対応は？
      • 2 Pizza team。
        • 順番に持ち合って24時間対応もするし、障害対応もする。
    • Opsは何をするのか？
      • Ops単体、という存在はいない。
チームの動き方

  • 全ての機能はサービスチームに存在するが、自身の役割に集中している。

    • 開発、ディレクション、支援など、個々がそれぞれの担当業務を専任している。
    • (自分たちでお守りをすることになるので)夜遅く起きないようにするために必死に作る。

  • 開発方法についてもチームに権限が与えられている。

    • 会社として統一した手法を指定するのではなく、各チームでアジャイル、ウォータフォールを選んで良い。
    • 採用も各チームでやっている。
    • 言語、開発ツールも自由。
    • ただ、そうは言っても効率化のために、共通で使えるリソースをまとめて用意したりもしている。

  • こうした動きを実現するためには、チームとして高い水準を維持する必要がある。

    • オンボーディングと呼んでいるトレーニング。
    • 定義されたパターン、プラクティス。
    • レビュー。
    • 内部的な技術共有。
    • Our Leadership Priniciple
      • これについては後程述べる。
    • といった原則を徹底的にやっている。

  • パイプラインについては、上述のカルチャー(独立かつ自由選択的な多数のチーム)から、

    • セルフサービス。
    • テクノロジ非依存。
    • ベストプラクティス。
    • 単一目的のサービス群。
    • を提供するためのツール群を社内で共有している。
      • 利用するかも裁量だが、90％以上のチームが使っている。

  • こんな感じで、各チームが開発からデリバリまで並列に動くことになる。

    • 年間5000万回ぐらいのデプロイが行われている。

  • AWSは昨年1年間だけで1400ぐらいの機能、サービスをリリースしている。

    • ただ、これは対外的にアナウンスしたものだけ。細かいリリースはもっと多い。

カルチャー

  • 文化の根底にはOur Leadership Principleがある

    • 14個の行動規範。
    • Amazonでは、マネージャであるかどうかに関係なく、全員がリーダとして動くことを求められる。

  • Web上で公開されている。

    • ちなみに中身は何年かに一回変わったりする。
      • ただし、一番最初の原則と最後の原則は不変。

  • 人事評価にも組み込まれている。

  • 以前からもこのOur Leadership Principleは知っていたが、入社して驚いたのは、普段の会話でこのキーワードが出てくること。

    • コミュニケーションにおける共通言語として使われている。
    • 社外の人が言われても、何のことか分からないが、社内だとニュアンスが伝わる。

  • Amazonの社員を捕まえて『どのOLPが好きか？』と聞くと、それぞれ異なる答えを返してくれるだろう。

Our Leadership Principle

  1. Customer Obsession

    • 全てはお客様から、という発想。
    • Empty chairという慣習がある。
      • 会議を行うとき、あえて椅子の一つを空けておき、そこにお客様が座っているかのように意識して会議を行う。

  2. OwnerShip

    • 長期的な視野に経って役割分担をすること。
    • テストで重要なこととして、すべてを自動化しようとしている。
    • 運用も全て自動化しようとしている
    • 自動化が非常に重要、という考え方が根付いていて、実現している。
    • テストをしやすいようにアーキテクト、デザインし、
    • テストや運用を自動化するためのアプリのアーキテクチャを考えている。

  3. Dive Deep

  4. Learn and be curious

    • 深堀していく。
    • Rootcause analysys
    • 5Whys
      • いわゆる『なぜなぜ』と同じようなことをやっている。
    • Brownbag sessions
      • 社内勉強会。ランチボックスを持って集まって取り組みをシェアしたりしている。

  5. Frugality

    • お客様にとって重要でないことにお金を使わない
    • Door Desk
      • 社員の机はドア用の板に木の足をつけた簡素なものを使っている。
      • 創業時の気持ちを忘れないようにするため。
    • この影響で、目黒のオフィスではドアが天井に並んでいたりする。

  6. Think big

    • お客様に貢献するために大きな視点を持つ。
    • 常識にとらわれない。

  7. Bias for action

    • スピード重視。
    • 取り組みにはやり直しがきくことも多い
      • プロトタイピングとフィードバック。

  8. Hire and develop the best

    • 採用時に高いバーを維持する
      • 各チームが採用活動をしていると話したが、人が足りないから採用する関係上、本来求めるべきレベルを下回っていても採りたくなる心理がある。
      • そこで、そのチームに直接関係ない人が採用に入ってバーを上げるという取り組みをしている。
    • カルチャーにフィットするかを非常に重視する。
      • カルチャーに合わない人だと、会社の成長を妨げてしまうので。

  9. Have backbone;Disagree and commit

    • 敬意をもって異議を唱える。
      • 偉い人に対する反論があっても空気を読んで言わない、とかいうのはやめよう、という話。
    • ただし、決定には全面的にコミットする。

  10. Invent and simplify

    • イノベーションとインベンションを求めてシンプルに。
      • コード、プロセス等全てにおいて。

  11. Are right, A lot

  12. Earn Trust.

    • 話をよく聞く。

  13. Insist on the Hightest Standard

    • 常に高い水準。
    • 同じ失敗、問題を繰り返さない。
    • コードレビューを非常に重視している。

  14. Deliver Results

    • 決して諦めない。
重視している点

  • こういうことを求めていくと『寝ずに働く』しかない。

    • のではなく、重要なことにフォーカスするようにしている。

  • イテレーションを重視している。

    • 必ずしも開発に限らない。
    • 溜め込みすぎずに、小さくしてなるだけ繰り返す。
    • 貯め込むと頻度も下がってしまうのでよろしくない。

  • MVP(Minimum Viable Product)

    • としてモノを作っている。
    • 最小限の仕様でモノを作って、お客様のフィードバックをもとにプロダクトを成長させていく。
    • マーケットに届ける時間と機能セットのどちらを優先するかは悩ましいが、トレードオフして必要最小限の仕様で届けていく。
    • いろいろ考えて、でかいモノを作っても、お客様にマッチしなかったら嬉しいものにはならない。

さいごに

  • Every day is still Day Oneという言葉がある。
    • 常に毎日が最初の一日である。
    • 現状に満足せずに新しい挑戦をし続けよう。