日本と米国の違いの乗り越え方　スマートニュースのグローバルアプリ担当者が大切にする共通のマインドセットとロードマップ

スマートニュースで日本語が話せない最初のプロダクト・メンバー

Jeannie Yang氏（以下、ジーニー）：ジーニーと申します。よろしくお願いします。申し訳ありませんが、ここからは英語になりますので、ご容赦ください。

本日の議題でポール（前田俊太郎氏）と話すのは初めてなので、さっそく中身に入らせてください。スマートニュースのプロダクト・ディビジョンで、日本語が話せない最初のメンバーが私だったわけですが、そのことが私自身にとって、またチームの皆にとって、どのような壁になると思われましたか？

前田俊太郎氏（以下、ポール）：率直に言うと、言葉の問題は間違いなく心配していました。でも、文化の違いや時差、物理的な場所の違いなどの他の懸念事項もありましたし、何よりも重要だったのは、日米のプロダクト・マネジメントのやり方の違いだと思います。さまざまな違いがあっただけに、スマートニュースにとっては大きな変化とチャレンジでした。正直に言って、最初は少し怖いと思ったこともあります。

しかしそれと同時に、グローバル市場に打って出ようとする中では、必要な変化だとも思いましたし、チームを強化するためにも、スマートニュースが継続的に成長する上で必要な変化だと強く確信しました。これが、ジーニーが入社する前に自分が考えていたことです。

逆にジーニーに聞きたいのですが、入社する前はどのような印象をもっていましか？　心配事などありましたか？

ジーニー：そんなに怖がられていたとは知りませんでした、誰もそんなことを言っていなかったように記憶しているので（笑）。私も気になっていたことは2つあって、1つは言葉の問題。ご存知の通り、私は日本語がまったく話せません。そして2つ目の問題はダイバーシティーに関するものでした。

もう少し詳しく話していきますね。言葉については、スマートニュースにはすばらしい通訳チームがあります。通訳チームが伝えたほうが、私が英語で話すよりも、むしろわかりやすく日本語で言ってくれていると思うくらいです。それくらいすばらしいです。

ですが、英語か日本語かという問題なのではないのだと気づきました。私たちは皆で共通の問題を解決することに取り組んでおり、同じプロダクトのために働いているので、言語が問題なのではありません。そう考えると、言葉がどうこうというのは、誰にとっても同じことなので、英語と日本語のどちらが話せるのか、あるいは話せないのかは関係ないと思いました。

そして、ダイバーシティーに関しては、私はこれまでにも常に多様性に富んだチームと仕事をしてきました。さまざまなバックグラウンドや異なる視点をもったメンバーがいることが私にとって重要であり、それによってすばらしいプロダクトが作れると思っています。

というのも、ユーザーも多様ですし、米国では多民族、多文化ということが一層顕著です。スマートニュースがそのような方向性にどんどん進んでいって、その部分で進化していくことはすばらしいことで、これからも皆で取り組み続けなければならないことだと思っています。

それ以外にも、スマートニュースでは、誰もが非常にオープンで、他者の意見を聞いて学ぶことに前向きだと感じました。そこがスマートニュースの原点であり、さらに多様性のあるチームになっていこうとしているのだと思います。

ですが、入社する前には気づかなかったことがありました。今となっては当たり前なのですが、それは時差の問題です。時差のことなんて気にしたこともなかったのですが、時差は全員が対応しなければならないことです。時差を変えることはできません。

もっとわかりやすくいうと、私は今サンフランシスコにいますが、ポールはもう「明日」にいるということです。日本は常に「未来」にいるのです。米国側は常に追いつかないといけません。ですから、時差を超えてお互いの足並みを揃えるためには、皆で協力し合うことが特に大事でした。

以前はプロダクト・マネジメントはエンジニア主導だった

ところで、プロダクト・マネジメントの違いについても先ほど話されていましたが、当時のスマートニュースが、どのようにプロダクト・マネジメントを捉えていたのかについて、聞かせてもらえますか？

ポール：スマートニュースのプロダクト・マネジメントは、日本においても少し特別だったと思います。

ジーニーが来る前は、かなりエンジニア主導のやり方だったと思います。最初のプロダクト・マネージャーは、エンジニアでもあり共同創業者の浜本階生さんでしたし、私やユウヘイ（西岡悠平：スマートニュース現Director of Product）さんなど、元々エンジニアとして入社したメンバーがプロダクト・マネージャーになりました。このようにスマートニュースでは、エンジニア出身者がプロダクト・マネージャーをやっていることが多かったです。

ある意味では、それがいい影響になっていました。例えば、エンジニアリングが主導して、基礎となるランキング・システムやレコメンデーション・システムを作るプロダクトアウト型のプロジェクトではかなり効果的です。

ですが、一方で課題もありました。その一例として、米国市場のユーザーが求めているものがわからなかった、というのがあります。ユーザーに対してスマートニュースが実際的な価値を提供できるのかどうかわかりませんでした。このことがチームの課題でした。

広告に関しても、私がプロダクト・マネージャー兼エンジニアリング・マネージャーとして、かなりの期間を担当しており、我々のチームは世界でもトップクラスのアルゴリズムと配信システムを構築した自負はありますが、広告主の意見を聞き、彼らが求めていることを理解する点では苦労しました。

エンジニアがプロダクト・マネジメントすることについては、このようなメリットとデメリットがあったと思います。

スクワッドとピラーの導入

ジーニーが入社してからは、すばらしい変化がたくさんありましたが、中でも米国のユーザーが求めていることや、これまで聞くことができなかった彼らの意見や本当に求めているものを知れたのは本当によかったと思っています。

フィードバックを収集する仕組み、そしてイテレーションの仕組みを作れたと思います。このようにユーザーをプロダクト構築のプロセスに組み込むことが可能になったのが、非常に大きなプラスです。

また、このやり方はスケールできるので、それまでのアプローチのように特定の個人に頼るのではなく、いろいろなチームやメンバーが関わって進めていけます。これはジーニーがプロダクトマネジメントにもたらしてくれた最大の変化であり、これからも進歩し続ける部分だと思います。

全社的にいい影響をもたらしてくれてありがとうございます。スクワッドとピラーという組織体制を導入したのもジーニーですね。どのような理由から導入しようと思ったのですか？

ジーニー：ポールが言うとおり、スマートニュースはすでにすばらしい基礎ができていました。プロダクトのすばらしさが印象的でしたし、メンバーもすごい人ばかりで、さまざまな勢いのあるプロジェクトに皆が関わっていました。

ですが、おっしゃっていた通り、スマートニュースは非常に早いスピードで大きくなっていたので、個々の人材という単位から、皆が協力し合いながら一つのプロダクト開発プロセスを通して連携できるようになる必要がありました。

スクワッドとはあくまでもチームのありかたの名称のひとつに過ぎませんが、万国共通で機能する原則です。個人が一人で考えるよりもチームが一緒に考えていいソリューションを出すことを重視し、スクワッドを導入することによって部門を超えた体制を建てられることがなにより重要です。自主性をもって明確な意思決定を行い、ミッションとゴールに対してチームがしっかりアラインするということです。

このような体制であれば、アジャイルなプロダクト開発プロセスでイテレーションを回すことができ、チームですばらしい成果を達成可能です。ポールも言っていたように、イテレーションが重要なのです。最初のバージョン (V1) でうまくいくとは限りませんので、V2、 V3、そしてまさにV8や場合によってはV10まで繰り返すこともあります。

ある機能を世に出したら終わりで、うまくいかなくてもそれで終了、ということではありません。どの部分がうまくいったのか、そしてどこがいけなかったのかをしっかり理解することが大事なのです。

スクワッドで重要なのは、そのクロスファンクショナル性です。エンジニアリングやプロダクトだけで考えるのではなく、部門を超えて取り組んでいきます。マーケティングチーム、コンテンツチーム、ビジネス開発チーム、セールスチームのすべてと協力しながら、そして何よりもデザインチームと一緒にプロダクトを作っていきます。

ユーザーに関する理解をエクスペリンスに生かせるのがデザインだと思いますし、マーケティングとのコラボレーションによってユーザーの層やペルソナの理解を深め、デザインをユーザーテストで検証していきます。つまり、エンジニアリングの開発段階の前に、デザインプロセスの時点で既にイテレーションは始まっているのです。

スクワッド体制という性質のおかげで、チームがより分散型になったことが非常に興味深いと思っています。例えば、日本のメンバーが米国のメンバーと同じスクワッドで仕事することは今まではありませんでした。

日本、中国、米国のエンジニアがモチベーションを保つ方法

前から一度質問してみたいと思っていたのですが、エンジニアリングの立場から考えて、日本のエンジニアに米国のプロダクトフィーチャー開発を担当してもらいたい、となった場合には、どうやってモチベーションをもたせるようにしているのですか？

ポール：米国向けの機能開発は日本、中国、米国のエンジニアが一緒になって取り組んでるので、意欲を出させるのは重要です。

日本にいるエンジニアは、プロダクトを開発・デバッグして、海外市場、特に米国市場に展開するというハードルの高いことに取り組むことにやりがいを感じていると思います。

その一方で、日本にいるため、ユーザーニーズを完全に理解できません。エンジニアに与えている課題に対してなぜそれをやるのかを常に伝え続けていくことは重要ですし、また実際のユーザーからのフィードバックを見てもらうのも大事です。例えばこのプロダクトがローンチしたものの、これらの問題は依然残っているよとか。新しいアイディアを生み出したり、やってもらっている取り組みを本当に理解してもらうには、このような生の声が必要です。デザイナー、マーケティング、データサイエンスなどの各チームから、フィードバックや学びの共有があることはとてもありがたいと思っています。

第二に、我々のエンジニアはさまざなは経歴をもっています。中国の巨大テック企業BATや米国のGAFA出身者もいれば、さまざまな地域でのスタートアップ出身の方も多いです。このようなさまざまな経験をもったエンジニアと一緒に仕事する機会があることで、より多くを学ぶことができ、またエンジニアの働きがいを作り出しています。

3つめは似たような話ですが、私を含め多くのエンジニアは、大きなインパクトを出せる複雑な問題を解決するのが好きです。そして約200人のチームでプロダクトを作る中で、米国と日本向けの機能の問題を解決するには、複雑に絡み合う課題を解決する必要があります。それは地域性の違いからくる機能であったり、または1つのアプリを数百人の体制で開発することからくるものもあります。

これは非常に複雑ですが、このような問題を解決すること自体が、エンジニアの意欲を生み出しています。これは重要なポイントのひとつでもあります。プラットフォームチームも導入しており、ここに対しても大きく投資して、グローバルな開発体制をサポートしています。

この中には機械学習に関するプラットフォームチームも含まれています。これは世の中におけるインパクトだけでなく、難しい課題であることも意欲をかき立ててくれます。プラットフォームの開発には時間がかかるため、この方向に対しては、この先数年は投資を続けていると思います。

エンジニアリングのロードマップを作る際は、基本的にはグローバル・プロダクトロードマップを見て、何を作ればプロダクトの開発を加速できるかを考えます。そのため、グローバル・プロダクトロードマップがとても重要です。これを作ることが、エンジニアが未来を見据えたマインドセットをもつのに、一役買っていると思います。

グローバルなロードマップの重要性

グローバルなロードマップを作るだけでも難しいのですが、我々はこれを保ち続けることにも大きな力を注いでいます。これはジーニーにとってどれぐらい重要ですか？

ジーニー：みなさんロードマップには、我々がどこに向かっているのかというビジョンであったり、今から3年後にどこに向かっているのか、あるいは今月何を作るのか、どのようにしてやるのか、ということを期待していると思います。ポールのいうとおり、ロードマップというのはこれらすべてのレベルにおいて、意識を合わせために重要なものでもあります。

チームがどこに向かっていくべきかは、当然これでわかりますが、ロードマップについてもうひとつ強調したいのは、これは変わるべきものでもあるということです。ロードマップにはゴールがあり、そこに向かっていくべきですが、実際には、これが変わっていくことで、ロードマップが保たれることになります。

それには、どのようにして学ぶか、どのようにして改善するか、そういった情報を集めながらアップデートし最適化して、ロードマップに次のステップ、次のフェーズを作ることが大切です。我々は常にこれらのゴールに向かいながらも、調整をくわえ、翌月、翌四半期の目標を達成して近づいていくことを意識しなくてはなりません。

ポールがユーザーについて、そしてエンジニアの視点について話してくれたのはうれしかったです。プロダクトマネージャーの観点からエンジニアを納得させる最善の方法は、実際のユーザーからのフィードバックとクレームを見せることです。ユーザーからの声が、一番エンジニアの意欲をかき立てるものだと私も思います。

難しいところとして、すべてのユーザーフィードバックから、どの部分が（方向性と）アライメントを取れるのかを探し出すことです。なぜならば、ユーザーは現在あるものは見えていますが、将来何があるかについては見えません。そこはまた、このロードマップによって、個々のフィードバックに反応せずに、我々の焦点を定め続けることが大切になります。

我々がユーザー視点を考える際に、日米のマーケットの違いについてよく聞かれます。しかし、ユーザーをみていると、たとえ日米間であっても、違いよりも類似点が多く、ユーザーニーズや悩みは、我々が考えるよりも、どの国であっても普遍的です。

日本にいても米国にいても、情報の過剰摂取の問題、誤った情報に接してしまう問題、良質な情報へどのようにアクセスするかなど、ユーザーの悩みやニーズは同様です。その上で、地域や文化の差を考慮してどのようにこれらに対応していくかが非常に重要になってきます。

よく言われることですが、日米間でにおけるプロダクトの課題のひとつは、日本に比べて米国が地理的にとても大きいということでしょう。米国内には4つもタイムゾーンが存在します。たとえば、プッシュ通知を送信すること1つとっても、東西海岸の時間を気にする必要があります。カリフォルニア時間の夜9時にプッシュ通知を送信しようとすると、東海岸ではもう真夜中になっているのです。この時間にプッシュがきたら、ユーザーは不満でしょうし、避けたいものです。このことは常に認識しておく必要があるもののひとつです。

これは米国でプロダクト機能をリリースすることの難しさでもあります。すべてのユーザーを対象にしたものなのか、もしくは一部のユーザーに向けたものなのか。

雨雲レーダーを例に挙げますと、これは日本に続いて米国でもリリースされ、期待も大きいですが、現在カリフォルニアは熱波の最中で、今週末は雨が降らない予報ですが、一方ニューヨーク州ニューヨーク市では熱帯暴雨が予測されています。

したがって、プロダクト機能をリリースする際に、すべてのユーザーが対象でないことを認識する必要があります。ここからどう学んで、改善し、追加して、プロダクト機能をよくして、すべてのユーザーニーズに答えていくのか。

これは一発でうまくいくとは限らず、全面的にみていく必要があるかもしれません。例えば日本で展開している機能によって解決するかもしれない。そうしたら、これらを次の季節に向けて移植したりすることがあります。

もう一つ、日米間の違いで認識しなければいけないことは、マーケットの違いです。日本ではSmartNewsはナンバー１ですが、米国ではまだそうではありません。つまりユーザーは多種多様なニュースサービスや情報サービスを使っており、我々はそれらと差別化を図りつつ、闘う必要があります。

ここについては、私が思うに、スマートニュースが日本の視点をもっていることがアドバンテージになると思っています。同じ問題を異なる考えを通して見ることができ、これにより、他の会社よりもさらにクリエイティブな解決策を見いだせるかもしれません。この観点から、日本の視点をもっていることが、差別化要因になるのはいいことだと思っています。

V8は、日本だけではなく、米国でもローンチされたものなので、これらの展開を本当に心待ちにしています。健さん（スマートニュースCEOの鈴木健氏）が指摘したように「グローバルナビケーションバー」は、1年かけて議論して、まずは米国でローンチをして問題がないことを確認してから、日本でのローンチを準備しました。

また多くの人たちには知られていないですが、日米のチームがやってきた一年間の取り組みから、基盤と組織を作り、学んだことから実践に移していきました。この成果が今後に向けて我々がいろいろできる糧になっているので、今後の展開をものすごく楽しみにしています。今はエンジンがフル回転している状況です。

V8から得られたエンジニアリングの成果

ポールは、V8から得られたエンジニアリングの成果としては、何が印象に残っていますか？

ポール：V8では多くの挑戦がありましたね。米国向けの雨雲レーダーを立ち上げる際には、グローバルな気象データの処理パイプラインが必要だったので、数多くのデータプロバイダのデータを統一的に処理するデータ処理パイプラインを作りました。また、マップUIのためのマップモジュールも作りました。これは将来開発予定の他の機能にも活用できるでしょう。

また、気づいていない方も多いかもしれませんが、V8の機能の中にはHTML5ベースで開発されたものもあります。これらを実現するために、プロダクト機能を迅速にHTML5で構築できる基盤を用意したり、またネイティブと同じような体験を提供する必要があり、これが難しかったですね。

米国版にしかない機能ですが、「ローカル」に関しては、Two-tower DNNモデルをベースにしたレコメンデーションシステムを構築しました。ローカルトピック検出アルゴリズムも作りました。

そのほかに構築した基盤としては、ローカル記事のタグ付けがあります。記事のタグ付け方法は、非常に複雑な問題です。地域の呼び方には、例えばサンフランシスコと呼んだりベイ・エリアと呼んだりすることがあり、これらが同じ地域かかどうか理解する機能も必要でした。

また検索も課題が大きかったです。検索はElasticsearchをバックエンド構築に用いました。またアカウントシステムは、FirebaseやOpen ID Connectなどをベースにしたものをバックエンドで構築しました。これらすべて難易度の高い問題です。

また、V8のみでなく、今後もより効率的に開発できるように、プラットフォームの構築も進めています。Kubernetesベースのマイクロサービスプラットフォームの構築がその一例です。

また、統合された機械学習のためのユーザー情報システムをFlinkとDynamoDBで作りました。このシステムが、ニアリアルタイムにユーザー情報を収集し、これを他のシステムからも取得可能にします。そうすることで、例えばレコメンデーションシステムを作っているエンジニアがこのデータベースにアクセスすれば、例えば1秒前にユーザーがこの記事を読んだなどがわかります。なのでこのようなプラットフォーム構築も重要な投資だったと言えます。

大きく変貌するプラットフォームとして、今も実は構築中のものもあり、例えば機械学習におけるインクリメンタルトレーニングと言った、優秀なレコメンデーションシステムを作るのに欠かせない基盤も、今回影でV8を支えたと思います。

このようなチャレンジが非常におもしろいものでした。そして、このようなことは継続していくと思いますし、将来的にも非常におもしろいチャレンジを迎えると思います。

ジーニー：そうですね、これらの取り組みもすばらしかったと思いますし、将来的に振り返ってみるとこういう技術的なことが背景にあることも気づいたりすると思いますね。

そこで先ほども少し触れたグローバルプロダクトロードマップをどう維持していくかという話にもつながってくると思います。先ほど言っていた技術的なアーキテクチャーの話は、米国だけとか日本だけの問題ではなかったと思います。すべてグローバルで作られるので、グローバルロードマップを理解することが本当に重要で、各地域にとってそれはどういう意味をもつのか、そして「なぜグローバルロードマップが必要なのか？」というよりも、それをどうやって維持していくのかが大切だと思います。

よく話題にも上がりますが、当然ながら（こういう状況なので）コミュニケーションというものが非常に重要であり、すべての土台になります。

チーム内のコミュニケーションは非常に良好ですし、コミュニケーションを促進するには、実はプロセスがより重要になってきます。しっかりとプロダクト開発プロセスを確立し、プロダクトエンジニアリング間で共有して、そのプロセスに対して協業することです。これは1つのチーム内だけの話ではありません。

ご存知のとおり、私はかつてエンジニアでもありましたので、実をいうとこの「プロセス」というワードは好きではありませんでした。とにかくコードを書いて完了、としたかったのです。ですが、スケールして大きなチームで作業する際、いいプロセスが非常に大事になってきます。それがあって初めて実行に移れると思います。

オペレーションから意思決定まで、すべてが同調されてしっかりと実行に進めていると言うことが本当に大事です。なので以前はプロセスというワードを煙たがっていましたが、今はプロダクトチームとエンジニアリングチームで一緒にプロダクトをどう開発していくかというところで、頻繁にプロセスについて話をしますね。

それに加え、グローバルプロダクトロードマップを維持するのに大事な要素として言及したいこととして、デザインの戦略という非常に重要な要素があります。デザインが共通したユーザーエクスペリアンスをもたらすわけですから。

天気は、場所によっては少し違うかもしれませんが、共通したパターンや体験はあります。なので、日本の天気機能デザインと異なるものを米国向けにデザインしたくありませんでした。部分的にローカルにカスタマイズしないといけない部分もありますが、どういうデザインがグローバルなユーザー体験を提供できるかについて考えました。

ここまでで、技術的なアーキテクチャーのイノベーションについて聞けて本当にワクワクします。プロダクト側の人間としていうのも変かもしれませんが、考えてみるとグローバルなアーキテクチャーというのは、本当に重要だと思います。日本で機能をリリースして成功した場合に速やかに米国にも持ち込みたいと思いますし、再度構築しなくてもいいようにしておきたいですよね。

そのようなことは、アーキテクチャーを一つの国のエディションだけ作っていてもうまくいきません。グローバルなアーキテクチャーをもつことによって、柔軟性がもてるようになります。どこでどう何をデプロイするかも、非常に重要だと思います。

ユーザーが、JPエディションかUSエディションかを選ばなくても、勝手に起動するだけでどこにいるのかがわかるようになる時代を、今から非常に楽しみにしています。

今後のグローバルアプリの開発に必要なマインドセット

今後のグローバルロードマップをみると、プロダクトイテレーションの速度も加速すると思います。現状でも20を超えるスクワッドがあり、各スクワッドがロードマップをもっています。この課題に取り組むために、次のレベルに向けて、エンジニアリングのマインドセットはどのように変わっていくべきだと思いますか？

ポール：どのようなスケールにおいても、エンジニアがEnd-to-endなインパクトをもたらすことに対して意欲をもてることが大事だと思います。そしてイテレーションなどを楽しめることも大事です。ですが20を超えるスクワッドで同じプロダクトに対して協業するということになると、他にもハードルがあると思います。

先ほど言いましたが、エンジニアは例えばグローバルなマインドセットをもっていないといけません。機能を開発しているときに、それがどのように米国のチームにも役立つか、などを意識しないといけません。また、デザインするのであれば、どうデザインすればより柔軟に他のニーズに対応できるようにするか、なども考えないといけません。

そうするにはエンジニアリングのマインドセットは「顧客中心」でないといけません。ですのでエンジニアは社内のさまざまなチームと会話して、どのような顧客の悩みの種があるのか、何をやっているのかなどを理解するべきだと思います。

またどのように他のチームをサポートできるか、何が作りたいのかなどを意識することも非常に大事です。先ほどプロセスについて触れていましたが、私も以前DeNAという会社でエンジニアをやっていました。そのとき、私もプロセスというものが嫌いでした。

ですがスケール化して物事を進めようとするときには、プロセスは実は大事です。これが一つの学びでした。プロセスとは例えばプラットフォームチームなど、他のチームからいかにスケーラブルな形でフィードバックを得るのか？どうやって他のチームからオフィシャルにフィードバックを得るのかなどです。

または技術的なレビューの機会もそうです。新しいものをデザインするとより複雑になるので他のシニアエンジニアからフィードバックを得ることが重要です。エンジニアは元来協力的に働くものですが、しっかりとデザインされたプロセスがないと、このような協業の効率を悪くすると思います。

ですのでプロセスへの投資というのはやらなければならないことだと思いますし、継続的な努力が必要だと思います。デザインすればはい終わり、とはならず、エンジニアリングプロセスに投資をし続けないといけないと思います。

ジーニー：そうですね。スクワッドもそうでしたよね、最初はイテレーションを繰り返して進化してきました。こんなにプロセスについてイテレーションすることが楽しめるとはまったく思っていませんでしたが、結果としてそれが各チームをエンパワーしてよりすばらしいものを作り出しているのだと思います。

更にスケールするためにグローバルなマインドセットは本当に大事だとは思いますが、実は今同時に我々のルーツを意識するクリティカルなタイミングでもあると思います。グローバルと聞くと怖じ気づくこともあります。例えばこれもあれもグローバルアーキテクチャーを、と気を張りがちになるかもしれませんが、同時に我々はまだスタートアップなので、アジャイルに素早く行動しながらスケールするのか、を考えるタイミングだと思います。

新しいことに挑戦したり、それの導入を試みたりなど、必ずしもスケールする必要はなく、そのような野心は持ち続けていくべきなのではないかと思います。

プロダクトとエンジニアリングの両方の観点から、本当にそう思います。構想は大きく、でも依然としてスタートアップとして、とにかくフットワーク軽く軽快に動くということですね。