エンジニアとPdMのあいだ
こんにちは！
dely, Inc.で新規事業のプロダクトマネージャー (PdM) をしている奥原 (@okutaku0507) といいます。役割としてはPdM兼エンジニアです。このnoteでは、エンジニア出身のPdMとしてキャリアを振り返り、どう考えキャリアの意思決定をしたのか、何が良くて何が課題として残っているのか、言語化にチャレンジしたいと思います。将来、エンジニアからPdMになりたいと考えている方、PdMをされている方でエンジニアリングに課題がある方など広くお役立ちできたら幸いです。
はじめに
僕はdely, Inc.に入社した2016年から元々はずっとサーバーサイド (Ruby on Rails) のエンジニアをしていました。そして、2018年の5月ごろからプロダクトマネージャーになり、レシピ動画サービスであるクラシルのプロダクトマネージメントを担当していました。現在は、新規事業のPdM兼エンジニアをしています。PdMになって、1年目に欲しかった記事を書いたので参考にしてみてください。
エンジニアからPdMになるということ
お名前を列挙することは避けますが、エンジニア出身のプロダクトマネージャーが増えてきています。これが意味するのは、プロダクトの成長に対して責任を追う役割において、エンジニアリングの知識が必要なケースが増えてきているということでしょうか。なぜ、プロダクトマネジメントにおいてエンジニアリングが必要なのか。考えてみます。
稚拙ながら、Clubhouseを例にエンジニアリングとプロダクトマネージメントの関係について考えます。Clubhouseが超急激に広まったのには、招待制という仕組みが存在しました。IT界隈で流行が起き、関係性があるインフルエンサー、そして芸能人にまで一気に波及していきました。1週間もしないうちにテレビのニュースで取り上げられていたのには正直驚きました。Clubhouseの招待サイクルを以下のように簡略化できたとします。ただ、これを実装できれば、Clubhouseと同様に急激なグロースを起こすことができるのでしょうか。
必要であった機能を列挙してみます。語尾とか整えてなくてすみません。
・電話番号とユーザー名を入力して、招待待ちという状態
・連絡帳と連携して、招待を付与する仕組み
・SMSで招待が付与されたことを通知する
・SMSからシームレスにアプリに飛ばし、登録完了までさせる
・1ユーザー3枠という招待権の付与
・アクションによって招待権が付与される仕組み
招待制のSNSは歴史の中にも存在し、真新しい発明ではありません。mixiが流行った時と比べて、SNSが高度に発達したこと、インフルエンスの仕組みが民主化して、個人の発信力が高まっていたこと、様々な要因がありビッグウェーブが生じました。Clubhouseが実現した令和版招待制SNSを実現するためには、簡単に列挙したよりもさらに複雑なことを考えなければなりません。そもそも開発言語は何にすべきか、アーキテクチャはどうすべきか、クラウドはどこにすべきか、音声配信の基盤を高品質に保つためにはどうすべきか、開発にかかる全てとコストとのバランスをどうすべきか。開発に不具合は切っても離せられません。上記のサイクルで一つでも不具合が生じて、ユーザーが登録できない状態が続いてしまえば、せっかく起こしたビッグウェーブに完全に乗れなくなってしまいます。まして、スマホアプリは一度リリースしてしまえば、簡単には修正バージョンを配布しきることはできないので、下位バージョンとの互換性をどうするかという問題がずっと付きまといます。僕の稚拙な考えはここで終わりますが、Clubhouseについて詳しく書かれているので参考にしてみてださい。
そして、機能的価値がすぐにコモディティ化する時代において、概念自体を知ることができれば機能がすぐにコピーされてしまうのは避けることができません。その結果として、主要SNSのほとんどは類似している機能を提供しています。Twitterでも「Spaces」というClubhouseに似た機能が実験されています。
法律で縛られているとか、技術難易度が鬼のように高いとか、データを保有していることでアルゴリズムが訓練されているなどで機能的な優位性を出すことはとても難しい世界になっています。
この世界において、プロダクトマネージャーはどう闘うべきなのか。とはいえ、Clubhouseのように急激に成功するスタートアップは存在している (現状がどうかというところはさておき) のが現実です。アプリケーションをプロダクトとしている事業において、新しい機能を開発する時も、画期的なマーケティング施策を実施するにしても、データ分析の基盤を整えるとしても、何かしらの開発が必要です。技術が進歩して、NoCodeでアプリが開発できるようになったとはいえ、その枠組みから外れるようなことに手を出すと開発業務は必須です。
前置きが長くなってしまいましたが、プロダクトマネージメントにおけるエンジニアリングとは、複雑に入り組みすぐにコモディティ化してしまう世の中において、技術的な難易度や工数を加味した優先度を決めて、質が高いプロダクトを提供しつづけることが市場から求められているのではないかと思います。このプロダクト開発のライフサイクルがどんどん加速していった結果として、素早くエンジニアリングに関する意思決定を行い、プロダクトの成長を牽引していく役割として、プロダクトマネージャーが求められているのではないかと考えています。この流れはすでにシリコンバレーでは何年も前 (もしかしたら10年というスパンで) に生じていて、米国のPdMではコンピュータサイエンスの学歴が必須だったりするのではないでしょうか。
そして、エンジニアからPdMになるということはエンジニアリングだけではなく、幅広く染み出していくことを意味するので、プロダクトの成長をエンジニアリングという側面から支え、幅広い知見を活かし、継続して価値を提供し続けられるプロダクトに対して意思決定をしていくことだと考えています。
何がしたいのかをまずは考える
プロダクト開発において、エンジニアリングもプロダクトマネージメントもつまるところ、一つの手段でしかないです。そのため、手段に拘ってしまうと、組織やプロダクトの変化が激しい中で自分自身が不本意に成長を阻害してしまうことになりかねません。何を言っているかというと、組織やプロダクトが激しく変化をしていると、自ずと求められる役割も急激に変化していくわけで、その中で最適化が行われることになります。当たり前のことですが、自分よりも役割に適した人が現れれるかもしれない中で、手段に固執してしまっていると、適した人に権限移譲ができずに、自分がボトルネックになってしまったり、組織に歪みが生じてしまうことになります。
そして、プロダクトマネージャーとは組織やプロダクトによって、担うべき役割が変わるので、とるべき手段も変わってきます。その環境において、大事なのはエンジニアリングだとかプロダクトマネージメントだとかは置いておき、その根底で自分が何をしたいのかという芯をしっかりと持っておくことです。世界に使われるプロダクトが創れたら、役割はなんでも構わないとか、常に目的に立ち返る必要があります。なぜ、こんなことを書くかというと、プロダクトマネージャーになった瞬間からほとんどの場合、専門性の方向がジェネラリストに向かうため、めちゃくちゃ努力しない限りは、常にキャッチアップして手を動かして経験を積んでいるエンジニアからは遠ざかっていくからです。プロダクトマネージャーになる前は、エンジニアリングを拠り所、強みとしていたのであれば、その立場が再構築されるのと、新しい領域にチャレンジにしているので、必ずすぐに上手くいくという保証はどこにもないので、エンジニアリングでもない、プロダクトマネージャーとしても未熟といった過程を誰しもが通るはずです。その時に、心が折れないためにも、そもそも自分が何がしたい人間なのかという芯を持つべきだと僕は考えています。
PdMになったらエンジニアを信頼する
先ほども、プロダクトマネージャーになった瞬間から緩やかにエンジニアリングのスペシャリストからプロダクトを成功させるためのジェネラリストへと移行していきます。エンジニアを何年やっていたとしても、今まで積み上げてきたものは貯金になり、それを切り崩していくことになります。これは悲観することではなく、その貯金を使ってプロダクトマネージメントという新しい資産に対してレバレッジをかけにいくことを意味しています。
プロダクト開発において、機能の仕様を決めたら次にはどのように実装するかというHowを考えることになりますが、元々エンジニアをやっていたら、Howに強みがあるので、ここはこうした方が良いと感じる時が何度かやってくることと思います。これはプロダクトマネージャーに限らず、マネージメントという役割を担っている人であれば、ほぼ必ずやってくるような場面かと思いますが、プロダクト開発においては、エンジニアリングのことはエンジニアに任せてしまった方が、長期的に見たら絶対良いということを考えています。
もちろん、責任と権限はセットなので、エンジニアリングに対して責任があるのであれば、エンジニアリングに対して意思決定をできる権限を持っていることになります。そういう意味でも、自分が元々エンジニアだったとしても任せるべきだとは思いますが、生産性の観点からも一人ができることは非常に限られているので、プロダクトマネージャーはプロダクトを勝たせることに全リソースを投下すべきだと思います。信頼し、任せ切ること。これが頭ではわかってきても、エンジニアからプロダクトマネージャーになった時に非常に難しい問題として横たわっていました。
結局は求められる能力は全てに帰着する
組織規模やプロダクトのフェーズによって、プロダクトマネージャーが担うべき役割は変わります。しかしながら、フェーズが進んでいった先に行き着く先は一緒なのではないかと考えるようになりました。
プロダクトマネージメントにおいてはBTC (ビジネス、テクノロジー、クリエイティブ) 軸で考えることが必要だと言われています。どこに強みを持っていたとしても、何かが偏ってしまっていたら、間違った意思決定を下しかねないので、少なからずBTCそれぞれで経験値をためていくことが重要です。つまり、エンジニア出身だとかデザイナー出身だとかは最初の強みがどこにあるのかというだけで、後に必要になってくるのではほぼ全ての能力、経験だということです。
プロダクトがメルカリくらいの規模になってくると、組織が肥大化して複雑性が増してきます。その結果として、意思決定を独立化させつつ秩序を保つための仕組みが重要性を増してきます。プロダクト開発の初期段階で、PdM、エンジニア (バックエンドエンジニアとフロントエンドエンジニア)、デザイナーが最小単位でチームを構成している時には、PdMが何かしらの専門性を持っていることはチーム内での役割を上手く補填しつつ開発が進むため、非常に筋肉質にスピーディーに物事が進行します。これがプロダクト開発の最小単位とすると、プロダクトと組織が肥大化していくと、チームの交通整理が必要になってきます。このフェーズに求められるプロダクトマネージャーの役割に、BTC軸で全体像を見渡して交通整理をして、プロダクトが健全に成長するための改善をし続けることが必要になります。このフェーズまでくると、エンジニアリングに強みがあるとかデザインに強みがあるとの先に適切にステークホルダーを調節して、プロダクトの未来を創造し、理想と現実に潜む不確実性を最速で落としていくアプローチができるかになってくると考えているので、全ての能力値の向上が必要だということが僕の今の考えです。結局、求められる役割が全てのことに明るいスーパーサイヤ人のような人材に寄ってくることになると考えています。
エンジニア出身PdMであって良かったこと
全ての能力が求められているとはいえ、エンジニアであって良かったことについて考えてみます。
全てのプロダクトは永続的ではありません。ほとんどの場合、いつかは衰退していきます。企業は常にリスクに晒されていて、プロダクトライフサイクルはどんどん短くなっていると言われています。
つまり、プロダクト開発において既存プロダクトにおいては成熟期をできるだけ長くすること、衰退期に差し掛かったらテコ入れをして再度成長曲線に乗せること、新しい価値を作り続けるために新規事業を立ち上げることが重要になってきています。一つのプロダクトで勝ち続けるためには、日本という市場で戦ってもアッパーが見えてきるのでグローバルで闘うこと、事業の多角化を進めることが必須になってきます。
プロダクトの導入期と衰退期が、不確実性の検証をスピーディに行い、競合関係を見ながら、成長曲線にプロダクトを乗せることを意味するので、プロダクトマネージメントにおけるエンジニアリングの重要性が増す期間であると考えています。このフェーズにおいては、小さいチームでスピーディに物事を推進していく必要があるので、エンジニアリングの知識や経験があることが非常に役立っていると感じています。
またエンジニアに戻ったっていい
僕たちを取り巻く環境は常に変化しています。その変化の中において、価値を発揮する一つの形がプロダクトマネージャーであって、状況によってはまたエンジニアに戻ってもいいと考えています。プロダクトマネージメントを専任している期間は、どうしてもエンジニアリングからは遠ざかってしまいます。今までの知識や経験の切り売りをしている状態なので、そこからスキルを伸ばすことはリソースの観点からも難しいと思います。
そのため、エンジニアに戻ったっていいし、他の役割になったっていい。何がやりたいのかという核を持ってさえいれば何にもでなれると信じています。エンジニアに戻って、今度はその時のスタンダードになっている言語やフレームワークを学び直しても新しい発見があるかも知れません。また一から学び直して技術をキャッチアップしてもいいと思います。プロダクトを成長させるために何でもやる、その姿勢がエンジニアからプロダクトマネージャーになって非常に大事であることを学びました。
この記事が気に入ったらサポートをしてみませんか？