「Amazonの文化は実際の開発にどう活きているのか、経験者に訊いてみる」Qiita Conference 2024イベントレポート
2024年4月17日〜19日の3日間にわたり、日本最大級*¹のエンジニアコミュニティ「Qiita」では、オンラインテックカンファレンス「Qiita Conference 2024」を開催しました。
*¹「最大級」は、エンジニアが集うオンラインコミュニティを市場として、IT人材白書（2020年版）と当社登録会員数・UU数の比較をもとに表現しています
当日は、ゲストスピーカーによる基調講演や参加各社のセッションを通じて、技術的な挑戦や積み重ねてきた知見等が共有されました。
本レポートでは、アマゾン ウェブ サービス ジャパン合同会社でスタートアップ事業本部 技術統括部 本部長を務める塚田 朗弘氏と、パブリックセクター技術統括本部のシニアソリューションアーキテクトである松井 佑馬氏によるセッション「Amazonの文化は実際の開発にどう活きているのか、経験者に訊いてみる」の様子をお伝えします。
※本レポートでは、当日のセッション内容の中からポイントとなる部分等を抽出して再編集しています
登壇者プロフィール
スタートアップ事業本部 技術統括部 本部長
パブリックセクター 技術統括本部 シニアソリューションアーキテクト
自己紹介
塚田：アマゾン ウェブ サービス ジャパンの塚田と申します。前職ではCTOをやっていたり、サーバーサイドの開発者をやっていたりしましたが、AWSではソリューションアーキテクトをやっています。テックロールではあるものの実際にサービスとかを作っているわけではないので、今日は実際にAWSでの開発経験を持つ松井さんにお話しを伺いたいと思っております。
松井：アマゾン ウェブ サービス ジャパンのパブリックセクターという部門で、教育／研究のお客さまを担当しております松井と申します。今はAWSのソリューションアーキテクトをやっていますが、2014年入社時にはソフトウェアエンジニアで、その後プロダクトマネージャーなどもやっておりました。具体的には、Amazon ショッピングアプリの開発に関わっていましたので、今日はそういった経験もお話しできればと思っております。
いつからマイクロサービス？ Amazonが20年以上実践する開発とカルチャー
塚田：では早速、1つ目のテーマに行きましょう。こちらはどんなトピックですか？
松井：「Amazonって昔からマイクロサービスやってるんでしょ？」みたいな話をたまに言われるのですが、じゃあそういうAmazonの開発カルチャーってどういう風に始まって、どう進化してきたのかをお話しできればと思います。
松井：こちらは「Amazon フライホイール効果」という、米 Amazon.com創業者のジェフ・ベゾス氏がナプキンに書いた、Amazonのビジネスモデルと言われているものです。
ご注目いただきたいのは右側にある「Customer eXperience（CX : カスタマーエクスペリエンス）」ですね。Amazonという会社は、このカスタマーエクスペリエンスが良くなると、トラフィックが増えて、セラーの方も増えて、商品の性能が良くなって、そうやってまたカスタマーエクスペリエンスが良くなるという、正のフィードバックループが回るとしています。
そしてそれと同時に、ビジネスが成長するとコスト構造がスリム化され、価格も低廉になっていきます。この考え方がAWSではキホンとして浸透しています。
松井：このフライホイールを高速に回して成長していくためのエンジニアリング原則がこちらです。
1つ目が「分解する」。これは、大きいシステムを細かく分解しましょうという話です。
2つ目は「自律的なチーム」。システムを分解してチームを分解したところで、互いが絡み合っているとスピードが出ないので、独立して自律的に動けるようにしましょうという話です。
そして3つ目が「全てを自動化」。人の手をかけずにやることでフライホイールのスピードを上げることが、この原則につながっています。
松井：こちらも創業時から掲げている考え方ですね。しばらくはモノリシックなアーキテクチャでAmazonのシステムがあったわけですが、やはり限界が来て、これ以上のスピード感を以って開発を続けるには分解するしかないだろう、というタイミングが訪れました。
そこでトップダウン型でサービスを分割していき、かつアーキテクチャの分割だけではなく組織も分割していく過程で、 “Two-pizza” チームと呼ばれている比較的小規模なチームに分けていったという経緯があります。
塚田：私もよく、ソリューションアーキテクトとしてお客さまから技術的な課題のご相談をいただくときに「チームもサービスも大きくなってきたのでマイクロサービスにしていきたい」「具体的にどうやって進めていったらいいのか？」「どうしても依存関係が疎結合にし切れない」といったお話をよく伺います。
そのようなところに関連して、ジェフ・ベゾス氏が「サービス間はAPI以外ではコミュニケーションしない」というルールにしたと聞いたことがあります。Amazonのサービス開発でもそれは徹底されている感じだったのですか？
松井：徹底されていましたね。なので、自分たちが機能開発をするときに他チームのデータを使いたい場合、APIで呼ぶ以外の方法はありませんでした。基本的に、相手チームのデータベースを直接触るなどといったことは原理的にできないようになっていました。
松井：次の話題にも関係するので、ここで “Two-pizza” チームについて、少し補足します。
チームの特徴としてはまず、「サービスを所有する」ということで、開発チームであればコードを書いて終わりではなく運用まできちんと行うなど、サービスに対して責任を持つというところですね。また、「チーム同士の依存関係をなるべく最小にする」ということで、せっかくチームを分けてもそこが密結合していると結局大きいチームと変わらないので、なるべく疎結合にしましょうというところです。
この図には8スライスのピザが2枚で16スライスあるわけですが、1人2スライス食べるとしたら、8人分ですよね。
意思決定のための自律した組織としては10人未満ぐらいのチームが適正サイズなのではないか、ということでAmazon社内に “Two-pizza” チームの考え方が浸透していきました。
塚田：“Two-pizza” チームの特徴でお話しいただいた「運用まできちんとやる」が次の話題ですが、こちらの図の「DevOps: “You build it, you run it”」は、「あなたが作ってあなたが運用するんだよ」ということですかね。
松井：そうですね。ソフトウェアエンジニアの方がコードを書いたら「あとは運用をお願いします」ではなく、その後もシステムを運用していく。運用も見据えた上で開発をしていくことが、非常に大事ですね。
塚田：一方で現実問題として、スキル的に両方ができる人ばかりではないですよね。Amazonだと、入社時／採用時で開発と運用のスキルをどれだけ求めているものなのでしょう？
松井：もちろん職種にもよりますが、私の場合でお伝えすると、ソフトウェアエンジニアとしての入社だったので基本的に求められていたのはソフトウェアエンジニアとしての基礎的なスキルでした。
私自身、入社前はそんなに運用経験がなくてですね、入ってから学んでいきました。ただ一方で、そういった運用を行うためのオブザーバビリティ関係などの様々なツールが揃っていたり、AWS Well-Architectedのようなノウハウが揃っており、最短で学べるような形になっていました。
松井：プロダクト開発でも、ここまでお伝えしたような内容に近い考え方があります。この図にある通り、開発者やデザイナー、プロダクトマネージャーなど様々な職種の方が集まってプロダクトを作るわけですが、基本的にそのメンバーは特定のプロダクト／エリアにフォーカスし、そこに責任を持つというプロダクト開発体制になっています。
塚田：シングルスレッド化されたチームは、いわゆるCPUのスレッドのようにその1つの責務を担っているチーム、という意味でシングルスレッドなのでしょうか？
松井：おっしゃる通りです。1つの実行プログラムを1つのスレッドで行うのがシングルスレッドですよね。
CPUであれば複数コアでマルチスレッド化すれば効率よく実行できますが、人間の脳はそうではないので、基本的には各チームがそれぞれフォーカスしたところに責任を持って仕事をするという体制ですね。
塚田：非エンジニアのメンバーもたくさんいると思うのですが、非エンジニアにとっての “You build it, you run it” はどういう意味になるのでしょうか？
松井：基本的には同じ考え方ができるかなと思います。
例えばプロダクトがローンチした時に、その後放置していいわけがありません。また、「ビジネス的なメトリクスが成功を収めているのか」、「ユーザー体験がいいものになっているのか」など、そのようなビジネスにおける運用を常に改善していくという体制を考えると、やはり “You build it, you run it” が職種を問わずなされていると思います。
塚田：面白いですね。アーリーフェーズのスタートアップがたくさんあるみたいな、そんな感じですね。
松井：そうですね。プロダクトマネージャーはミニCEOのように言われたりすることもありますね。
再発明してもいいんだ！ 鍵はスピード優先でお客さま中心であること
塚田：続いてのトピックです。こちらはどんなお話になりますか？
松井：こちらは私がAmazonの開発でちょっと驚いたことでして。自律的なチームがたくさん動いていると、どうしても「同じようなことを考えていた」ということもあり得ます。その場合にAmazonではどうしているのか、いくつかのトピックをお話しできればと思います。
松井：こちらは、Amazon.comの「一度買ったものをもう一度買う」という機能の画面です。非常に便利な機能ですね。これの元になるものの開発に関わっていたのですが、まさに同じようなことを考えている方が社内の別の国にいました。
塚田：どうやって解決していったかの前に、そもそも、Amazonでプロダクトを作る時は、どのような進め方をするのか教えていただけますか？
松井：基本はフライホイールの考え方が起点になります。お客さまの体験をまず考えて、そこから逆算して開発していきます。これが “Working Backwards” です。
松井：PR/FAQとは、 “Working Backwards” のプロセスを始めるための起点となるようなドキュメントの仕組みです。PRは、いわゆるプレスリリースのことなのですが、通常プレスリリースはプロダクトや機能ができた時に出すかと思います。
しかしAmazonのPR/FAQに関しては、プロダクトや機能を開発をする前にあらかじめローンチした想定でプレスリリースを書きます。
そうすることで、このプロダクトはどういうものでお客さまにどういう点で喜んでいただいているかが明確になるので、チームとして意思統一できるわけです。
塚田：実際に松井さんもPR/FAQを書いたことはありますか？
松井：プロダクトマネージャーをやっていた時は、そもそもPR/FAQが仕事の1つになるので、むしろ必須でした。それがないとプロダクトを作り始めることができませんし、関係者を巻き込むこともできません。一方で、プロダクトマネジャー以外の方でもPR/FAQを書く機会はあります。
私もソフトウェアエンジニアのときに、「こういう機能を作りたい」というアイデアをPR/FAQへと落とし込んで書いていましたね。
塚田：なるほど、ありがとうございます。その前提で、冒頭にお話があった「別チーム同アイデアの衝突をどう乗り越えるか」についてはいかがでしょう？
松井：ここに列挙されている内容は、Amazonのカルチャーの根幹になるようなリーダーシップの考え方なのですが、衝突をどう乗り越えるかっていう観点でいうと “Customer Obsession” というお客さまを第一に考えるところと、あとは “Have Backbone; Disagree and Commit” という、自分の主張をしながらも決まったことに対しては結果をコミットする考え方が、メカニズムとしてはかなり重要かなと思います。
塚田：例えば松井さんチームがプロダクトAを作っています。そこに私がめちゃくちゃ似たアイデアを思いついて、PR/FAQ書いて、周囲の人を巻き込んで、プロダクトAダッシュを作り始めたとします。そのような時、この “Have Backbone; Disagree and Commit” は具体的にどう発揮されるのですか？
松井：さきほどの「もう一度買う機能」の例でもそうなのですが、基本的には議論を戦わせますね。PR/FAQをお互いに見ながら、データを共有し、利用状況や想定するユーザー体験などをしっかりと主張していきます。もうそれに尽きますね。
塚田： “Customer Obsession” が第一にあって、どういうものがお客さまのために一番いいかは共通認識として持っているので、単なるぶつかり合いにはならないと。
松井：チームのエゴよりもお客さま視点、というところがやっぱり大事になります。
塚田：これは、前半の方に出てきた “Two-pizza” チームにおける自律性にも関連するところですかね。
松井：そうですね。先ほど “Have Backbone; Disagree and Commit” で議論するとお伝えしましたが、どのように議論するのかや、意思決定するときのメカニズムについても簡単に2点ご紹介したいなと思います。
1つは「データに基づく判断」というところで、当たり前のことかなと思いますが、議論する上で成功の指標は絶対に必要ですよね。ビジネスのメトリックスを見たり、開発チームのスキルとして運用がきちんとできているかを見たり、リリースも問題なくできているかチェックしたりと、そういうところを含めてデータを出しながら議論するのが前提としてあります。
もう1つは 、“One-way/Two-way ドア” ということで、何か判断が難しい時に、その判断がOne-way、つまり判断したらもう後戻りできないようなものなのか、それともTwo-way、つまり一旦ドアから出たとしてもまた戻れますよというものなのかを区別すると、かなり判断の幅が広がります。
Two-wayならば、まずはやってみるという判断もできますし、One-wayであれば注意して判断する必要があり、事前にデータを集めて議論し尽くさないといけない。といったように見極めをすると、全体としての判断スピードがかなり上がるという考え方です。
塚田：意思決定の速度を速くするための考え方のフレームワークみたいな感じですね。実際に松井さんがやってきた開発中の意思決定の例にはどのようなものがありますか？
松井：結構ありがちな話なのですが、とあるWEBアプリケーションのフレームワークを使って開発をしていた際に、新しいものが社内に出てきまして。新しいWEBフレームワークって、キラキラしていてエンジニアとしてはぜひ使ってみたいという気持ちになるじゃないですか（笑）一方で新しいがゆえに未成熟なため、どこまで使っていいのかというところもありました。
その中で、ソフトウェア開発マネージャーの方が「この新しいフレームワークを使うのはチームのスキルアップにとってはすごく良いことだ」と。「ただし、非常に大きいプロジェクトで採用してしまうとOne-wayになりかねず、プロジェクト自体が害される可能性もある」ということで、まずはスコープを絞ったある程度小さなプロジェクトでやってみる。と判断をしたことがありました。
それで進めてみると案の定ですね、新しいフレームワークで様々な問題があり、結局は元のフレームワークに戻しました。
塚田：ただ単にリスクを伴って突っ走るのではなく、適切にTwo-wayにしながら試す。そういうところもこの考え方でできていくわけですね。
まとめ
塚田：本日はこの2点のテーマに沿ってお送りしてきましたが、振り返っていただくといかがでしょうか？
松井：「Amazonの文化は実際の開発にどう活きているのか」というテーマでお話させていただきましたが、やはりその根本には、ここに再掲しているフライホイールの考え方があります。
そして、これを高速に回すための仕組みとして、マイクロサービスや “Two-pizza” チームの話などをご紹介させていただきました。またプロダクト開発に関しても、都度発生し得る衝突に対して、カルチャーや仕組みでどう乗り越えていくかをお伝えしました。
塚田：セッションの内容は以上になるのですが、最後にお知らせでございます。日本最大のAWSを学ぶイベント「AWS Summit Japan」が、2024年6月20日・21日に参加費無料で幕張メッセで開催されますので、ぜひご参加いただければと思います。初心者から経験者まで学べる150以上のセッションをご用意しております。
皆さんご視聴ありがとうございました！
文：長岡 武司