アーカイブ動画

Amazonのイノベーションを支えるメカニズム『Working Backwards』

アマゾンウェブサービスジャパン合同会社
エンタープライズ技術本部　ソリューションアーキテクト
部長　兼松 大貴氏

地球上で最もお客様を大切にする企業であること──。Amazonのビジネスを展開する上で重要な考え方であり、イノベーションを生み出す源泉である。このAmazon流の考え方を具体化するメカニズムが、「Working Backwards」である。AWSでも頻繁に使われており、重要な意思決定の基盤にもなっている。

まず兼松氏は、ジェフ・ベゾス氏がAmazonを創業する前に、そのビジネスモデルを可視化したフライホイールと呼ばれるスケッチを紹介。顧客ファーストの重要さを語った。

「顧客体験が高まると顧客数が増えます。すると売り手も増え、品揃えも増えると同時に、低コストや低価格も実現します。結果として、顧客数が増すとともに顧客体験もアップする。このサイクルを回すことでビジネスや組織が成長するという考え方であり、すべては顧客体験から始まっている点がポイントです」（兼松氏）

さらに兼松氏は、イノベーションを生み出すための4つの要素である「企業文化」「組織」「アーキテクチャ」「メカニズム」を方程式に落として解説。アマゾンでどのように展開しているかを紹介した。

【企業文化（カルチャー）】社員一人ひとりがリーダーであることを定義

社員一人ひとりがリーダーであるという考え方「リーダーシップ・プリンシプル」に従い、全ての行動を行うように心がけている。いわゆる行動規範であり、サービス開発はもちろん、採用、人事評価でも同様だ。

なお、リーダーシップ・プリンシプルは16項目に細分化されている。兼松氏はその中から、自身が特に好きだという3つの項目を取り上げて紹介した。それが以下である。

●Customer Obsession
リーダーはまずお客様を起点に考え、お客様のニーズに基づき行動し、お客様にこだわり続ける。

●Invent and Simplify
革新的なアイディアを生み出していくためには、短期的には誤解を受けることもある。その誤解を恐れず、理解を得られなかったとしても果敢に行動していく。

●Bias for Action
ビジネスの変化に追従していくためにはスピードが重要。計算されたリスクを取ることに価値がある。

意思決定においては、「一方通行」「双方向」という2つの属性に分けて対応する。その違いは、決定した後でも戻ることができるか否か。例えば、ハードウェアの購入やサービスの値下げは一方通行の判断になるが、実験的なサービス開発は双方向といった具合だ。

一方通行の場合は大量のデータをもとに、専門家とディスカッションや分析を行いながら、意思決定を行う。対して双方向の場合は、判断力の優れた個人や少人数のグループが素早く意思決定することで、ビジネスの初速を高めている。

失敗を恐れず、許容することもアマゾンの文化の一つだ。例えば、発売したものの約1年で販売を中止したFire Phoneである。だが、この失敗を悪く言う人は社内ではいなかったという。

「むしろ失敗を許容するカルチャーがあるからこそ、現在の屋台骨の一つであるAWSも生まれたとも言えるでしょう。失敗は重要だし、失敗し続けなければいけないと思います」（兼松氏）

【組織】2ピザルールでビジネスを推進

アマゾンの組織では、「2枚のピザルール」を採用している。2枚のピザを食べ切ることのできる人数、つまり8名程度の小さなサイズのチームでビジネスを進めることで、意思決定ならびに開発のスピードを早めるというやり方である。メンバーの主体性や自律性を高めることにも繋がる。

【アーキテクチャ】マイクロサービスを全てのアプリケーションに導入

アーキテクチャは、マイクロサービスを全てのアプリケーションで導入。柔軟な機能の追加や、拡張性を持つことができるため、ビジネスの変化が激しい現在においては非常に重要な要素になっている。

組織においてもマイクロサービスを導入している。サービスやシステムは組織のコミュニケーション構造を反映したものになるという、いわゆるコンウェイの法則の考え方をもとに実施している。

【メカニズム】顧客ファーストを実現するWorking Backwards

最後に紹介されたのは、AWSで新しいサービスや取り組みを実施する際においては必ず実施されるプロセス「Working Backwards」である。

Working Backwardsでは「お客様は誰ですか？」 から始まる5つの質問を通じて、本当に必要なサービスを企画・開発していく。具体的にはプレスリリースを書くことでこれからつくるプロダクトやサービスを明確にし、FAQを作成することでより具体的な体験として考えるための手法である。

特徴的な点として、プレスリリースはシンプルな文字のみで書くことが挙げられる。講演などで使われるプレゼン資料のような図やグラフは、Appendixに補足資料として記載するに留める。あくまでも文章で表現することにこだわる。アマゾンではこれらのドキュメントを「ナラティブ」と呼んでおり、サービス開発以外に新しい取り組みを行う際も同様に作成する。

ミーティングなどの際は冒頭など時間を使ってナラティブを参加者が読むことで、チーム全体の認識を共有し合う。開発を進める上で方向性がずれてきたと感じたときも、ナラティブを確認することで軌道修正を図る。

プレスリリースの書き方として、可能な限りシンプルに表現すること。ターゲットとなるカスタマーにどのような利益をもたらすのか、そしてサービスや機能に関して最初の3行で完結に伝えることが重要となる。兼松氏はプレスリリースの構成例を紹介し、セッションをまとめた。

「Working Backwards」メカニズムを活用したプロトタイプ開発事例

アマゾンウェブサービスジャパン合同会社
エンタープライズ技術本部　ソリューションアーキテクト　荒木 柊人氏

続いては、荒木柊人氏がWorking Backwardsのメカニズムを活用した事例を紹介した。

まずは、顧客の現状を理解するところから始まる。今回の事例で紹介されたお客様は日立建機。油圧ショベルなど、建設現場で活躍する重機を開発・製造する世界トップクラスのメーカーであり、拠点は世界各地にあり、売上高は1兆円を超える。

同社からの依頼内容は「製缶構造物溶接内部欠陥を効率よく見分けたい」という難解な相談内容であった。

「実はこの相談をいただいたとき、正直ピンときませんでした。そもそも『製缶』という言葉の意味が分からなかったからです。ただ、このような特定のドメイン知識を得ることができることも、SAの魅力のひとつだなと思いました」（荒木氏）

だが、詳しくヒアリングを繰り返すうちに、製缶構造物とは重機のボディのことであり、その際に行う溶接内部の状況を判別することが難しいこと、そうした課題を解決したいという要望であることが分かった。

さらに、溶接の状態を見分けることができる熟練エキスパートは現状2名しかおらず、その2名が毎日約50枚の溶接のエコー画像をチェックしていること。その状態をABCに振り分ける業務も含め、およそ60分の時間を費やしてくるなど、安全管理が非効率化している課題も見えてきた。

ここまで理解したことで、解決策がいくつか浮かんだ。エキスパートを採用する、あるいは社員を育成してエキスパートを増やすという施策が一つ。もう一つはAI画像診断による自動化だ。顧客にヒアリングを続けていくと、自動化を期待していることも分かった。

とはいえ、自動化が顧客にとってプラスになるかは、この時点では定かではない。コストと精度面において検証を行い、一歩引いて考えることが重要だと、荒木氏は強調する。

顧客との話し合いの結果、自動分類の適合率が90％以上であり、手動と比べてエキスパートの作業時間が6分の1以下であれば、AWS費用を加味しても、メリットがあることが整理できた。

この案件をプレスリリース・FAQで表現したものが、以下のドキュメントである。

「プロダクトを使う人の立場に立って、顧客と一緒に各種機能や実現する体験を記載していきました。入社研修でも同様のプロセスで開発した体験が生かされました。また、読み合わせ時に参加者がコメントを残すことで、より深く議論を進めることができました」（荒木氏）

このプロトタイプのアーキテクチャも紹介された。まずは、診断した画像をアップロードする。実際には撮影した画像がまとまっているフォルダ名を指定すると、Amazon S3に格納されたことをトリガーにLambdaがAmazon Rekognition Custom Labels（以下、Rekognition）で傷の大きさに応じて診断を行う。

Rekognitionで行った診断結果を、再びS3に分類し保存。同時に、精度が指定したしきい値を下回った場合には、Slackチャンネルで診断依頼を担当者に報告する。

Rekognition は、AIや機械学習の知識が不要なAWSのAIサービスである。今回のアーキテクチャのように画像をアップロードすると、あらかじめ学習したパターンに応じて、画像分類や物体検知ができる。

Rekognitionによるモデル作成は、常時起動しているとコストが高くついてしまう。荒木氏は、デバイスから直接S3にアップロードする際のセキュリティの強化や他サービスへの横展開など、今後さらにアーキテクチャを進化させたいと語り、セッションをまとめた。

入社半年の新卒SAが顔認証受付サービスを1カ月で開発

アマゾンウェブサービスジャパン合同会社
インターネットメディアソリューション本部
ソリューションアーキテクト　奥野 友哉氏

最後に登壇した奥野氏は、新卒入社後の1ヶ月半で開発したAIで顔認証を受付するプロダクトを紹介した。

AWSでは新卒メンバーに対し、「Tech-U」という教育プログラムを半年間行っている。プログラムの終盤には、自分たちで考えたテーマで実際にプロダクトを開発する課題も与えられる。奥野氏のチームは、誰がオフィスのどこで働いているのか、簡単に探すことができる人探しサービスを開発した。

さらに、社内イベント会場の受付で参加者リストと入場者の照合に時間がかかり、行列ができている様子を見て、顔認識サービスを横展開させたイベント受付サービスを思いつく。そのアーキテクチャは以下の通りだ。

まずAmazon Rekognition（高精度の画像・動画分析サービス）によって、本人かどうかを確認する。Amazon S3への正解画像は社員証の画像を使うこととした。受付に設置されたUSBカメラが受付者を撮影し、S3の画像と合致すればOKという流れだ。メトリクスとして残すため、ログを残す構成も加えた。

これらの構成は教育プログラムで得た知識を使うことでスムーズに進んだが、セキュリティ、パフォーマンスの領域では苦戦した。

AWSではセキュリティに「強い人」のレビューを事前に受けることで、セキュリティを確保する「Security Guardian」という制度がある。その仕組みを利用することで、アドバイスをもらい、セキュリティを高めていったという。

実際のイベント参加数は数千人規模であるが、まずは数百人のイベントでテスト。精度も含めたパフォーマンスの実証を観察した。すると精度的には問題ないが、撮影した写真をそのままシステムにアップすると、レイテンシーが大きくなることが分かった。

そこで、ローカルPCで認証に必要な顔部分のみをトリミングするひと手間を加えてから、アップするようにした。作業を繰り返し行い、精度とスピード、最もバランスのよい画像サイズを探っていった。メガネの装着有無でもパフォーマンスが変わることも分かった。

目標とした1人あたり2秒という受付時間を達成することはできなかったが、それでも従来のシステムよりはるかにスムーズになったため、利用者からは高い評価の声が届いた。

評価が高かったことで、たくさんの人が出入りする世界最大規模の自社撮影スタジオ「Amazon Fashion Studio」の受付システムとして、導入されることにもなった。さらにはAWS公式のソリューションとしても採用されている。

奥野氏は「現在は AWS Solutions を通して世界中の人に利用いただいています」と述べ、セッションを締めた。

年間3000以上の新サービスや機能をリリースしているAWS。そのアーキテクチャや導入事例の紹介や、顧客課題に取り組むAWSのソリューションアーキテクトたちの取り組みを紹介する「AWS Tech talk Night」。今後も定期的に開催していくので、ぜひ楽しみにしていただきたい。

アマゾンウェブサービスジャパン合同会社
https://aws.amazon.com/jp/

アマゾンウェブサービスジャパン合同会社の採用情報
https://aws.amazon.com/jp/careers/

ソリューションアーキテクト採用情報
https://aws.amazon.com/jp/careers/teams/solutionsarchitect/