Spotifyのプロダクト開発フローから見るシリコンバレー流強いエンジニアの育て方

シリコンバレーに来て、早18年

河根拓文氏：みなさん、初めまして。河根です。よろしくお願いします。今日は簡単に「生成系AI時代のプロダクト開発」とは何か、何が変わってきたのか。そこで必要なチームのスキルはどんなものになっていくのかを簡単に、私なりの経験や考え方を紹介していければなと思っています。

まずは本題に入る前に軽く自己紹介からしたいと思います。私はシリコンバレー、サンフランシスコのベイエリアに来て、早18年ぐらいになりました。

行く前は日本のマッキンゼーでコンサルタントをしていて、プロダクトマネジメントやテック系の企業にはいなかったんですけれども、やはりそういうものが好きだったので、ベイエリアにあるUCバークレーという大学に来まして、そこを卒業したあとはマッキンゼーに戻らずに、そのままeコマース企業の大手であるeBayに入って、そこで戦略やプロダクト関連の仕事をいろいろとしていました。

そのあとはここにあるような、いろいろなモバイルゲームやコンシューマー向けのアプリ、はたまた企業向けのソリューションなども作っていました。これらいろいろなスタートアップでそういうようなものをやるうちに、だんだんプロダクトマネージャーから、プロダクトマネージャーのヘッドになっていきました。

その後、さらにいろいろなスタートアップを渡り歩きまして。例えば左側にあるのがバーチャルリアリティのテクノロジーを活用して、大企業の従業員向けにトレーニングを行うような、そんなプラットフォームを提供するスタートアップとか。そのあとMetaに行って、その中でも「Messenger」のチームにいて、プロダクトの開発に関わっていたり。今はこちらにあるような、ホンダに買収されたスタートアップのドライブモードというところで、ホンダの方々と一緒になって将来の電気自動車向けソフトウェアの開発をしています。

このように10年以上、さまざまな企業で一貫してプロダクトマネジメント、そのトップやリーダーというような仕事をやってきました。なのでエンジニア、ソフトウェアエンジニアとはもう十数年、ずっと一緒に働いてきたことになります。

シリコンバレー的プロダクト開発

では、そのようにいろいろ経験してきた中で、この「シリコンバレー的なプロダクト開発ってそもそもどんな感じなの？」ということを簡単に紹介したいと思います。

一番、よく例に出されて私が個人的にこういう解説をするのに便利だなと思っているのが「Spotify」。みなさんご存じのSpotifyのプロダクト開発フローです。厳密にいうとSpotifyはヨーロッパの企業なので、シリコンバレー企業ではないんですが、我々も含めいろんな企業がこれを参考にプロダクト開発をしています。

ざっくり言うと5つのステップがあって、最初のステップがSpotifyで「Understand it」と呼ばれています。ここではそもそもどんな課題があるのか、どんな課題を解くべきか、それを特定する・発見する・探索するというプロセスです。顧客開拓ですとか、顧客開発、ニーズの開発、問題の発見などを行います。

そのあと2番目は「Think it」。このプロセスでは、ここで発見された課題をどのように解くのかというソリューションについての仮説を立てて、それをクイックに検証する、そのようなプロセスになります。

3番目が「Build it」といって、ここでいよいよ開発を始めるわけです。1番と2番で、そもそも何のために何をするのかをしっかり固めて、それを基に開発するのがBuild itのプロセスですね。

それで4番目が「Ship it」と言いまして、少しずつ市場に出して実際にユーザーに使ってもらいながら学ぶと。ここで大事なのは、大々的に一気に出していっぱいお金をかけてやるのではなくて、少しずつ市場に出して学んで改善をしていく、というのが4番目です。

めでたく「あ、このプロダクトはいけそうだ」となったら、しっかりと出して、プロモーションもして、そこから実際の大きなユーザーベースをもとに改善を続けていくと。分析を続けて改善をしていくというのが、5番目の「Tweak it」というプロセスになります。

このように書くと、ステップバイステップで順番を追ってやっているんだなと思われがちなのですが、実際はけっこうゴチャゴチャしていて。Spotifyでもこれがいろいろなフェーズで、いろいろなプロジェクトで走っていて、いろいろなところをスキップしたりして、ある意味半分カオスな状態で進んでいくのが現実かなと思います。

5つのステップの間にやること

ちなみに、このそれぞれの間に成果物というか判断ごとがありまして、1番と2番の間では、先ほども言いましたが誰のために何のためにこれをやるのか、そもそもどんな問題を解決するのかというのをしっかり定義するWHY、WHOがないとダメです。

さらに実際にお金をかけて開発、リソースもかけて開発する前には「Problem Solution Fit」、PSFと呼ばれるような、この問題に対してこのソリューションだったらいけそうだということに合意する。これを簡単なプロトタイプなどを作って、ユーザーインタビューなどを通じて確認するという作業があります。

作ったあとは、みなさんご存じのMVP、「Minimum Viable Product」というのを作ってみて、少し出して顧客の反応を見ることが必要でしょうし、最後、大々的売っていくためには「Product Market Fit」。このマーケットのニーズとプロダクトそのものがしっかりとフィットして、成長がしっかりできそうかどうかをいろいろなKPIを見ながら判断する、というようなことを実際にやっていきます。

当然、このプロセスをエンジニアだけでやるわけではなくて、ここに書いてあるようなマーケティングやデザイナー、DSというのはデータサイエンティストですね。分析する人たち。あとはPM、私のようなプロダクトマネージャーが、全員をオーケストラの指揮者のようにまとめ上げることによって、一丸となってやっていくのが特徴です。

その他プロジェクトマネージャーや、スクラムというプロセスを使っていたらスクラムマスター、テストをするQAなどが一丸となって、このプロセスを支えていくのが非常に重要になってきます。

Spotifyの中でももっとも成功した機能

1つ有名な例を挙げますと、SpotifyでいうところのDiscover Weeklyという、毎週自分の好みに沿った新しい曲をおすすめしてくれるプレイリスト。この機能はまさにこの5つのステップを通じて出された機能の1つです。まず始めのこのUnderstand itのところでは、知らない曲をそもそもSpotifyでは発見しにくいという課題があったり、さらに発見したユーザーはSpotifyをより使ってくれているというデータがあったりしたそうです。

このようにしっかりとしたこの課題を実際のユーザーデータから発見した、これが1つ目のステップです。そこに対してのソリューションをThink itで思いついたのが、これまで聞いた曲をもとにして、このプレイリストを作ってはどうか。また、そもそもこれをやるゴールは何なのかみたいなことをしっかり定めたんですね。

Build itなんですが、ここはすごく手間をかけて一気に作ったり、すごくいろいろな調査をしたというよりは、ハッカソンを使ってクイックに作って、本当に少人数で作って試すようなプロセスを取りました。なのでこのUnderstand itからBuild itに行くまでは、あまり時間がかかっていないはずです。

そのあとハッカソンで作ったようなプロトタイプそのままでは、もちろんリリースはできないので、よくドッグフーディングと言いますが、社内の従業員向けにだけリリースして、どんどんフィードバックをもらって、どんどん改善していく。そのようなプロセスを通じて、どんどんローンチできるレベルまで上げていきました。

そしてめでたく全ユーザーに対してリリースしまして、これをしっかり月曜配信にしたり、このどのぐらいの長さの曲数にすればいいのか、どこにプレスしたら見つけやすいのかみたいなことをどんどん改善していって、結局は期待以上のエンゲージメントの向上につながったそうです。なのでこれは、Spotifyの中でももっとも成功した機能の1つと呼ばれています。

シリコンバレー流強いエンジニアとは？

ここまででものすごく駆け足ではありましたが、そもそもシリコンバレーではどのようなプロセスを通じて、どのようなチームでプロダクト開発を行っているのかをザッと見ていきました。このプロセスをベースにすると「強いエンジニアってそもそもどんな人なんだろう？」ということがわかってくるかなと思います。

多分に主観も入っていますが、私が今までいろいろなエンジニアと関わってきた中で、やはり強いエンジニアというのは、この課題解決志向であったり、チームワーク重視、スピード重視、また常にどんどんプロセスも改善していこう、コードも改善していこう、プロダクトも改善していこう、というマインドを持っている人。

また、当然専門性はあるんですけれども、そこそこフルスタック的な考え方。サーバーサイドやクライアントサイド、あとはプラットフォームやデータエンジニア的なこともできるような、そういうエンジニアがやはり強いなと感じました。

逆に今まで見てきて、やはり伸び悩んでいたり活躍度合いが少ないのが、言われたことのみをやる、何かこう命令が来て、それをやってお終いというようなタイプのエンジニアさんだったり。あとはスペックの資料を重視する、スペックの完璧な資料や「このモックアップがないと何もできません」みたいな感じの方。

他には、改善したりするのはプロダクトマネージャーやエンジニアリングリーダーの問題であって、自分の問題じゃないからと、そういう議論に参加しなかったりとか。あとはこの専門領域があるのは非常に重要なんですが、そこだけに閉じこもって他のことを学ばないような方は、やはりこのチームワーク重視で課題解決のためのプロセスを行うのには向いていなかったのかなと思います。

いくつか簡単に例を挙げますと、まず私が前職でいたMetaでは、実は「スクラム」という言葉は禁句なんですね。みなさんも多くの方はスクラムを聞いたことがあると思いますし、実践しようとされていたりしている方も多いのかもしれませんが、Metaではアジャイルな動き、素早く物事を顧客のために作り上げて、その価値を提供してみて、それがどんどん改善していくアプローチのマインドは非常に強く持っているものの、スクラムは禁句である。

なぜならば、Metaでは自前で培ったような、さらに良いプロセスがあると自負しているからなんです。そのプロセスは、けっこうどちらかというとカンバン式に近いようなかたちで、どんどん来た課題をどんどんやっていって、それをどんどんマージして、しっかりテストして、自動テストが書けて、どのあとドッグフーディングをちょっとして、どんどんこれのフィードバックループを回して、どんどんタスクを切っていくという、そういうやり方に近い。

チームによっていろいろ差はありますが、（そういうプロセスを）しています。なぜこれができるかというと、やはり各エンジニアがけっこう自立をしているからですね。なのでこう「全部揃っていないと何もできません」というわけではなくて、どんどん重要なものを、もちろんプロダクトマネージャーの戦略的なガイダンスの中でピックしていって、それを自らで形にする。

（形を）もう作ってしまって、テスト環境でマージして、テストしてみて、調整する。そこからまたフィードバックを学んでから次にいくみたいな、そういう特に自立的で課題解決志向が強いようなエンジニアが揃っているからできることかもしれません。

「Threads」は非常に少ないバジェットと人数で短期間で出た

あとここに「Threads」（リリース日：2023年7月5日）という、みなさんもご存じのMetaが出した「Twitter（現X）」の競合アプリ。これももうさっきのSpotifyのDiscover Weeklyに近いかたちで、ハッカソンみたいなかたちで、非常に少ないバジェットと人数で、非常に短期間で出しました。その前にドッグフーディングなどを繰り返して、ドンと出してみたというものです。このプロダクト自体が成功か失敗かはさておき、こういうマインドを持ってそういうことができるエンジニアが、やはり強いエンジニアなのかなと思います。

こちらの例は「Hotspot Shield」というプロダクトで、私が2013年頃に入社したAnchorFreeというスタートアップのプロダクトなんですが、その頃はまだ40人ぐらいのチームでして、そこではもう最初はCEOやCTOの言ったことだけをやる。とにかくやってローンチしてしまえというようなプロセスでした。

何が問題になるかというと、スピードは速いものの、バグが多く発生したときに、ユーザーのフィードバックが反映されていなかったりですとか。なので、この「App Store」の星の数も3以下だったりしたこともありしました。ちょっと顧客価値を満足に提供していない。

CEOの言ったこと（をやって）CEOを満足させることにフォーカスしていたので、そこを私やその他のQAのリーダーだったりが入って、長い時間をかけてカルチャーを変えて、強いエンジニア、先ほど申し上げた強いエンジニアを採用したりすることによって顧客価値を上げて、売上も数倍になって買収され、イグジットできたというような例もありました。このように、やはり強いエンジニアを揃えて、それを育てることが非常に重要になってくるかなと思います。

AIは開発を効率化している

こういったスキルや要件が、この生成系AIでどのくらい影響があるのかというと、今のところ、いくつかのAI系のスタートアップで働いているようなエンジニアの友人や、あとはプロダクトマネージャーなどに聞いてみても、基本的には今はAIは開発を効率化している。むしろそれに仕事を奪われてどうのこうのという段階ではなくて、効率化の手助けをしているとまとめられるかなと思います。

Understand itのところでも、情報収集を自動でやってくれたり。プロトタイプを作る時にいつもよりも速くできたり、AIを使ってみなさんもご存じのようにコードを書く支援でCopilotのようなことをしてくれたり。分析を効率的に進めるようなツールもあって、なのでこのTweak itのところの改善のスピードが早まったり。このように全体の効率化の手助けをしている、逆に言うとそれだけということですね。

ちょっともう駆け足でいきますと、私はよく巷にいるAIツール屋さんでも何でもないのであまり詳しくもないんですが、例えば最初のUnderstand itのところで、私がデモを見て「おもしろいな」と思ったのはこの「Zeda.io」というツールです。これは社内に溜まったデータ、ユーザーフィードバックみたいなデータをクロールして、AIがそれをまとめて「こんなプロダクト、こんな問題が大きいですよ。なのでこんなプロダクトを作ってみてはどうですか？」みたいなとこをAIが推薦してくれるみたいな、そういうツールです。

Copilotはたぶんみなさんご存じなので、ちょっと飛ばします。この「Uizard」というのは、モックアップやプロトタイプをわりと簡単に作ってくれるツールです。こういうのが今どんどん出てきていますし、Adobeのような大手がこういう機能を取り込んで来ています。

これも、みなさんご存じ「ChatGPT」の有料版にある分析ツールで、このデータのファイルを上げて、データの分析の仕方をチャットで言うと、こうやって分析してくれる。こういうようなツールにフォーカスしたスタートアップもどんどん出てきていますし、似たようなことが、やはり大手のSaaSのプロダクトにどんどん取り込まれてきています。

ここでちょっと注目してほしいのは、これはエンジニア向けではなくて、プロダクトマネージャーを採用する際にどんなスキルが重視されているかのランキングなんですが。これはレニーという有名なプロダクトマネジメントのブロガーが取ったアンケートで、これを見ていくとけっこうおもしろくて、上のほうにあるランキングがわりとソフトスキル的なものだということに気づくかと思います。

コミュニケーションやリーダーシップ、実行力みたいな内容ですよね。これはプロダクトマネージャーだけに言えることではなくて、この生成系AIが全体を効率化してくる中では、エンジニアにもこういうリーダーシップ的な、または戦略家としてのソフトスキルが、今までも重要だったのがこれからさらに重要になってくる、そのような気がしています。

なので生成系AIは恐るるに足らず。これは全体を効率化してくれるような武器なので、それを有効活用しながら、先ほどのようなソフトスキルをエンジニアであったとしてもしっかり伸ばして、AIに取って代わられないようなリーダーシップのある戦略的思考力の強いエンジニアを育てる、エンジニアを採用して育てるのが、どんどん重要になってくる、そのように感じています。

単にハードスキルができるだけという人はどんどん窮地に立たされる

まとめると、この効率化によって、より少ない人数で、よりアジャイルに、より高速にあの5つのステップができるようになります。そして、このようなハードスキル（専門性の高いスキル）の手助けをAIがしてくれるので、そもそもの問いが立てられる人。エンジニアでも何の課題を解決すべきなのか、そもそもCopilotするのも最初のコードがないといけないですし、そもそもの問いを立てられるような、あとはビジョンや機会を創出できるようなエンジニア、そういうことに関われる人がどんどん重要になってくるでしょう。

さらにこのAIがどんどん進化していったとしても、プロダクト開発がチームスポーツであることには変わらないと思います。なので、ソフトスキルを活用してみんなで協働して結果を出せる、そんな人材がますます重要になってくる。単にハードスキルができるだけという人はどんどん窮地に立たされる、そんなふうに思っています。