惠良

各AWSサービスを担当しているサービスチームが世界中のお客様と議論をする場ですね。

AWSは、EBCを通じてお客様の課題を解決し、またはサービスの改善に関するFeedbackを受け取ることを目標としているらしいです。

今回私たちが行ったAWS社とのEBCは、Amazonの本社機能が集中している、シアトルの一角で行いました。

惠良

EBCは年に1回のイベントのようなものではなく、恒常的に顧客と行われているんです。「AWS改善のためのディスカッション」を顧客と常に行っているという感じですね。

顧客側として参加する場合、まず事前にAWSへのフィードバックや要望をいろいろとためておきます。それを日本にいる間に、AWS側担当者とも何度もすり合わせ議題を固めてからEBCに行くんです。

EBCの場では、この議題についてAWSから一方的に話されるのではなく、双方向のディスカッションが行われます。

惠良

タイムテーブルが決まっており、それぞれ決まったテーマの内容についてAWSのMTGルームでディスカッションを行いました。

各事業部によってニーズが違うので、事業部でセッションを分けたり、時には一緒になってディスカッションしたりもしましたね。

土屋

ディスカッションの際にすごく印象的だったのは、AWSの人たちが必ずユースケースを聞いてくることです。「なぜこの機能が必要なのか」を、彼らが納得するまで説明する必要があった。要望を理解してもらうのに30分くらいかかったりもしたんですよ。

土屋

準備は念入りに行いました。

AWS Japanの方が定期的にDeNAにお越しくださるので、まずはその場で議論内容をすり合わせ、USチームにも事前にその内容を伝えていただきました。

その後、こちらでは必要なデータを集めたり資料を準備したりして当日に臨むという感じです。

加茂

横断的な話や、様々なサービスに共通するニーズの話もしましたが、私や惠良さんはどちらかというと担当領域に特化した内容をお伝えしました。

惠良

そうですね。私はオートモーティブ部門に所属する立場から、IoT系のサービスに関してお話しました。

オートモーティブ部門は、AWS Japanのオフィスで1度EBCを行っているので、今回のアメリカでのEBCは「日本で伝えた要望がどうなったか」という確認も行いました。

逆にAWS側からは「こんな機能はいるか？」と聞いてくるので、それに対して必要、不必要と考えを伝えていったりもしましたね。

惠良

たとえば今、AWS IoTの上で作っているシステムのアーキテクチャを変えている最中なんです。それをリファインする時に「前はこの機能がほしかったけど、今はいらない」というのが出てきたので、それを改めて伝えたりしました。

アーキテクチャの変更も「そもそもコストがかかっていたので変えることになった」という経緯があります。それで、実際変えた時にどういう課題が生じるのか「さらにコストを下げるためにはどういうアイデアがあるのか」を聞いたりしました。

惠良

すべて反映されるとは限りません。ですが、基本的に改善の必要性を理解してもらえれば、半年から1年を経て次の開発スケジュールに組み込んでくれるんです。

すごく壮大な改善だと難しいですが、現実問題として「この機能があれば他の会社も嬉しいよね」というものにはAWSは積極的に対応してくれるんですよ。

なので「その機能があればこんな使い方ができます」という追加提案もこちらから行いました。

加茂

確かに、EBC参加は労力もコストもかかります。

ですが、その価値はあると思いますね。DeNAでの業務改善にも大幅に影響してくる話ですし、AWSに直接提案できる貴重な機会です。

土屋

ディスカッション内容によっては、AWS側もバイスプレジデントクラスなど、エグゼクティブ層が来てくれたりもします。それでしっかりと改善要望を聞いてくれますね。

「本音で要望を伝えてほしい」というのがAWS側のニーズとしてあるんです。

我々は他社のサービスも使っているので、他社サービスとの違いも踏まえてAWSが改善すべき点は忌憚なく話はできたかなと思っています。

惠良

行動規範的な部分は興味深かったですね。

EBCでは最初に、現地のAWSで働いている日本人の方が「AWSの開発者がどういうカルチャーで仕事をしているか」という話をしてくれました。

Amazonは基本的には全社員がオーナーシップを持っていて全員がリーダーだという考え方。リーダーシッププリンシパルというカルチャーがあるそうなんです。

加茂

あとは彼らは「Think Big」という言葉も頻繁に使っていましたね。広い視野で考えようという意味です。

DeNAが掲げる行動指針DeNA Qualityと似ているかなとも思う部分もあるし、Amazonらしいなという部分もあるなと思いました。全員がリーダーという考え方は、全員が球の表面積を担うDeNA Qualityの「全力コミット」に似ているかなあとか。

惠良

特徴的なのは「AWSはサービス・ソリューションが非常にたくさんあり、その1つのソリューションの開発にしても短期間でチームが変わる場合がある」ということ。

Amazonではインターナルトランスファーを積極的に推奨しているため、部署間異動が多いようですね。だから、誰でも、どのソリューションでもできるようになるという、ゼネラリスト的観点が強くなるのではないでしょうか。

DeNAのエンジニアの場合、たとえばAIでいうと、業界でも抜きん出たスペシャリストやエキスパートが多い。インフラもそうだと思います。

ですが、Amazonはどちらかというと職能で分けない印象です。だからこそ人に紐づく仕事はしない。業務をできるだけ自動化するとか「誰でもできるようにするまでが仕事」という考え方です。

加茂

私が印象に残っているのは、やはりMTGの場にAWSのエンジニアはもちろんのこと、バイスプレジデントなど、エグゼクティブ層が来て真剣に話を聞いてくれるということです。しっかり顧客からニーズを吸い上げようとしているモチベーションを感じました。圧倒的な顧客目線ですよね。

土屋

彼らは「認識をすり合わせてしっかりと理解すること」をとても大事にしているんだなと感じました。

何かこちらから質問をした際には、AWS側から「今の質問を正しく理解するために、こちらからも質問するけど……」という返しが多く、曖昧な理解のまま進めようとしない姿勢があります。

日本人同士だと、どうしてもお互い曖昧な理解で相手を推し量り、擦り合っていないまま進んでしまう議論って多いと思うんです。ですが、彼らは絶対にそれをしない。

土屋

ええ。質問するほうも答える方もすごく労力を使うのですが、姿勢としてすばらしいと思いました。

ユースケースを大切にするのも、結局「Think Big」の考え方なんじゃないかな、と。1つの機能を改善するときに「それがなぜ必要か」を俯瞰で考える。そして「なぜそうすべきなのか」を理解する、というやり方ですよね。

土屋

わからないことは「わからない」と言うのは大切ですね。日本だと性質としてなかなか言わない人が多いかなと思うので。

あと、業務に取り入れたいという観点でいうと、彼らの「ミーティングを行う際は事前に議論内容を文章にまとめ、それを読むところから始めるというやり方に非常に感銘を受けました。

土屋

MTGの参加者にとっても口頭でざーっと話されるより、体系だって簡潔にまとめられた資料があったほうが理解の助けになりますし、書く側にとっても文章を書くことで自分の考えが整理でき、論理が破綻している箇所があればその段階で気づけえるからです。

実際EBC で、私が事前に用意した資料を映しながら進めたのですがAWS側から「一旦資料読むから待って」と言われることがありました。

MTG のたびにこれをやるのは大変だと思いますが「今のMTGなんかふわっと話しただけになったな」というのをなくすために極力実践したいと思いました。

惠良

インフラ部門のような間接部署になると、いろいろな部門を見てそれぞれの要望を聞き分ける必要があります。「本当は何やりたいの？」を拾い上げるというところでは、AWSと同じような立ち位置かもしれません。

土屋

ええ、とても刺激を受けますね。

事業部や担当している業務によると思いますが、DeNAは海外に行く機会が多い会社だと思います。

加茂

AI部門は特にカンファレンスの参加が多い印象ですね。リサーチャーは国際学会に頻繁に行っているようです。実際、今回僕らがシアトルに行っている間に、5～6人でドイツに行っていましたね。

土屋

カンファレンスにとどまらず、学会もそうですし、国際会議に参加しているメンバーも多い。

惠良

国際学会とかカンファレンスには要請を出せばだいたい行けますね。AIは特に研究が大事なので、そこへの投資は会社として積極的にしています。

土屋

インフラ系で言うと、DeNAは現在クラウド化を進めている（※3）ので海外に行く機会が増えてきています。オンプレミスだと海外に行く機会はほぼなかったのですが、時代が変わってきました。

いろいろと学ぶべきことは多いですが、仕事を通した成長機会に加え、海外に行く機会など外からの学習機会も得やすい会社です。