見出し画像

プロダクトマネージャー3年目の教科書

奥原拓也 / PdM / anynote

こんにちは！

dely, Inc.で新規事業のプロダクトマネージャー (PdM) をしている奥原 (@okutaku0507) といいます。

この記事は「dely Advent Calendar 2021」の1日目の投稿です。最初の投稿で緊張していますが、今年もたくさんの仲間が記事をつないでいってくれるので、とても楽しみです。

はじめに

毎年のアドベントカレンダーの時期には、それまでの1年間で学んだことをnoteに書いてきました。

特に、2年前に書いた「プロダクトマネージャー1年目の教科書」は、今でもたくさんの方に読んでいただき、1,000いいねをいただいていて、少しは日本のプロダクト開発に貢献できたのではないかと思うと嬉しい限りです。僕も初心に返りたい時など、読んでいて自分が書いたとは思えない量でびっくりしています。

今年は、何を書こうか非常に悩みました。プロダクトマネジメントについて書きたいけれども、どういう着地にすれば、さらに世の中のプロダクトマネジメントがより良くなるのか。世の中の流れはさらに早くなり、プロダクト開発を取り巻く環境は2年前よりも不確実性が高い世界になっていると思います。そして、自分自身もPdMとなって3年目となり勢いとかポテンシャルとかではなく、しっかりと成果を出さなければならないと実感しています。

2年前と比較し、プロダクトマネジメントについての書籍もグッと増えて、様々な会社でPdMという役割に対する理解がなされ、アーリーなスタートアップでもPdMが採用されるケースが増えてきているように思います。下に挙げた書籍は、どれも本当に良書なので、まだ読んだことがない方は是非読んでみてください。

しかしながら、不確実性が高く情報のアップデートが目まぐるしい中で、プロダクト開発に向き合ってきて、体系的な捉え方ではなく、成果を出すプロダクトマネジメントの活きたノウハウはまだまだ発信されていくべきだと考えています。

2年前の自分を超える必要なんてない。過去を振り返る必要もない。3年目のコミュニケーションであったり、日々の優先順位決めであったり、本当に苦しい時であったり、その時に自分が欲しかった考え方やノウハウを書こう、そう思いでこのnoteを書いています。

もし、このnoteを読んで、プロダクト開発に向き合っている全ての人のお役に、ほんの少しでも立てたら幸いです。このnoteを書くにあたり、過去のnoteはほとんど参考にしておらず、同じようなことを書いてしまうかも知れませんが、今の自分の言語化であるため、あらかじめご了承ください。

プロダクトマネージャーとは

プロダクトマネージャー (PdM) とは、今の考えでは「プロダクトの成功に対して責任を持っている役割」という解釈をしています。

さらに分解すると、まずは「プロダクトの成功」とは何かを考えたいと思います。プロダクト開発は終わりのないマラソンのようなものです。ほとんどの会社には成し遂げた世界の在り方、ビジョンがあります。そのビジョンを成し遂げるために、様々なミッションを持ったプロダクトが創られているという構造だと解釈しています。プロダクトの成功とは、ミッションの達成を意味しているのですが、ほとんどのプロダクトではミッションの達成は現実的にはるか遠くに置かれています。

Our mission is to unlock the potential of human creativity—by giving a million creative artists the opportunity to live off their art and billions of fans the opportunity to enjoy and be inspired by it.

Spotifyのミッションは「Our mission is to unlock the potential of human creativity」であり、壮大です。これが完全に成し遂げられている社会がミッションの達成です。つまり「プロダクトの成功」とは、ミッション達成に向かって常により良いプロダクトを創り続けることを意味してると考えられます。

次に「責任」という言葉について考えます。Weblio辞書によれば、以下で定義されています。

１ 立場上当然負わなければならない任務や義務。「引率者としての責任がある」「責任を果たす」
２ 自分のした事の結果について責めを負うこと。特に、失敗や損失による責めを負うこと。「事故の責任をとる」「責任転嫁」
３ 法律上の不利益または制裁を負わされること。特に、違法な行為をした者が法律上の制裁を受ける負担。主要なものに民事責任と刑事責任とがある。
引用 : https://www.weblio.jp/content/責任

例えば、僕たちがよく見ているニュースにおいて政治家の方が何かよくないことをしてしまった時の「責任」は、辞任を意味することが多いと思います。しかしながら、プロダクトマネジメントにおいて本当にまずいことをしていない限りは、担当を降りることはあっても、それ以上の会社内での責任はほとんどないのではないでしょうか。また、解雇されにくいことを考えるとまた別のプロダクトにアサインされてチャレンジする機会も得られるのではないかと考えると、責任という言葉をどれほど重いものかと解釈するか次第です。

僕が考えるプロダクトマネジメントにおける責任とは、もちろん成果に対してのみ与えられるべきだと考えているのですが、最後の最後に責任を取るというよりも、そこに至るまでのプロセスの中に存在していると考えています。つまり、プロダクトマネジメントにおいて責任を果たすということは、日々の業務、プロダクトの意思決定に対して、自分が出せる全て以上のものを求め続ける姿勢であると考えています。それは、ステークホルダーに対する説明責任をきっちり果たす、限りあるリソースを最大限活用して、プロダクトを成功に導く、この過程においてベストを尽くすことと、周りに言われたからではなく、自分自身で自分のハードルを上げ続けていくことが「責任」だと考えています。

1年目から3年目で何が変わって何が変わっていないか

PdMを任せていただき1年目から3年目になって、自分自身で感じている変化は、より成果が求められるようになったことだと思います。どれだけ上手く物事を進めても、どれだけ周りが満足するようなプロセスを経たとしても、最終的な成果が伴っていないのであれば、それは自分にとってはとてつもなく反省すべきことなんだと思います。あえて失敗という表現はせず、失敗が学びであった捉え方もできるとは思うのですが、ずっと学び (= 失敗) が続いて成功が一つもないという状態は結局誰も幸せになっていないと思いますし、最終的には成功したというような記事もたまに拝見しますが、それはそれで素晴らしいこととして、PdMとして成果にコミットすることの重さを常に感じる3年目であると思います。

これは、PdMが置かれている環境に応じてケースbyケースかと思いますが、自分の場合は2年目から新規事業を0から立ち上げ、なんとか2年間は成長を維持することができ、今後は会社における最大の柱にしていく過程であることを考えると、程度はあるにせよ、一つのプロダクトにずっとコミットし続けることはなくて、複数のプロダクトを見つつ、それぞれのドメインにおいて共通することや共通しないものを経験していくのだと思います。

PdMの責務はプロダクトの成長であることと、人材の流動性を考えると、自分よりも優秀で、そのプロダクトを成長させることができる人が来た、あるいは育ってきたならば、完全に移譲してしまって、自分は新しい価値を創りにいくくらいに考えていた方が、組織全体に対する最適解になると思いますし、全体が成長していくためには必要な健全化だと思います。

1年目から変わっていないことは、業務内容かなと思います。質や量は自体は向上している感覚がありますが、実際にやっていること自体に変化はないように思います。結局は、ミッションの達成に向けた課題解決です。ミッションは抽象度が高いので、ほとんどの場合PLとして具体的になっていて、KGI > KPIという形で、それぞれが四半期で目指すものとして落ちているはずです。その指標を達成するために、課題となっていることは何か、優先順位はどうすべきか、解決策をどう実装すべきか、アウトプットの質は担保されているかというサイクルを回し続ける日々です。

プロダクトマネジメントを取り巻く環境の変化

この数年でプロダクトマネジメントにおける環境が一気に変化してきたように思います。まずは情報の体系化とコミュニティです。

プロダクトマネジメントとは何かという問いに対して、会社やプロダクトの種別やフェーズによって本当に様々な業務があるのですが、それらが情報として体系化されてきたように感じます。先に挙げた「プロダクトマネジメントのすべて」を筆頭に、様々な書籍やnoteなどの記事も多く「ProductZine」のようなメディアも出てきています。

その背景には、SaaSプロダクトの盛り上がりなどから事業=プロダクト (= ほぼ会社) であるケースがさらに増えてきたのと、プロダクト開発を取り巻く環境の不確実性が高く、何を創るべきかという難易度が高くなってきたために、今まで組織の中で誰かが担ってきたプロダクトマネジメントの専門性が高まってきたことが考えられます。結果として、PdMを設置する会社が増えて情報の需要が高まり、ノウハウの蓄積が進むことで発信やコミュニティの形成が活発化してきたと考えられます。

次に、プロダクトマネジメントの細分化が進んできたと思います。

PdMの業務は性質上、小さいチームやフェーズが若いプロダクトにおいては多岐に渡ることが多く、PdMが広告を回していたり、CSの対応をしていたり、コードを書いていたり、デザインをしていたり、採用をしていたり、本当に足りないところを補っているケースが多いように思います。しかしながら、組織やプロダクト、新規事業の立ち上げプロセスが成熟してきている会社で、プロダクトマネジメントの理解が深い組織においては役割の細分化が進んできています。つまり、上に挙げたようなマーケティング領域はPMMがビジネス開発領域においてはBizDevが担っているケースが多くなっています。

SmartHRさんでは「PMの役割ではないこと」をしっかりと明確にしていたりします。PdMという役割が具体的には、ユーザーに向き合うプロダクト開発、つまりエンジニアリングやデザイン領域 (UI/UX) にフォーカスされており、ユーザーさんやクライアントさんへの価値提供に集中できるようになってきています。これは良い悪いという話ではなく、自分の強みを十分に活かせる場がわかりやすくなってきているという解釈をしています。

PdMのキャリア

PdMのキャリア戦略は、PdMになる人が多くなっている中では非常に重要なトピックです。まず、一般的な考え方を整理しつつ、自分なりの考えを書きたいと思います。

僕自身は、エンジニアからPdMに役割をチェンジしつつ、大規模開発から新規事業の立ち上げへと軸が変化してきました。また、向き合うべき顧客もtoCからtoBへと変化してきました。そのため、PdMのキャリアの考え方としては、継続したPdMとしてのキャリア、他職種からの相互におけるチェンジ、プロダクトのフェーズ、toC/toBという切り方ができるかと思います。

他職種からの相互におけるチェンジでは、エンジニアやデザイナ、ビジネスからのPdMへのジョブチェンジとPdMからの他職種へのジョブチェンジについて考えます。まず、はじめてPdMになるケースとしては他職種からのジョブチェンジがあり得ます。新卒からPdMをされている方もいますが、所属する組織において必要性が出てきて、エンジニアやデザイナをしていたけれどもPdMへとジョブチェンジするケースやディレクターからという経路もあります。感覚的に、そもそも新卒からディレクターやプランナー、デザイナなどいわゆる上流工程に関わっていた人が多いように思います。最近では、エンジニアからのジョブチェンジも出てきました。

PdMから次のキャリアですが、元々エンジニアやデザイナのバックグラウンドを持っていて、ある程度のキャリアがある場合はエンジニアやデザイナに戻ったり、またPdMをしたりとする人がいて、専門職に全くの未経験でチェンジするケースはあまりないように思います。加えて、起業、事業責任者、PMM、BizDev (元セールス) が選択肢でしょうか。PdMに止まることなく、多様な選択をしている方が多いように思います。

プロダクトのフェーズでは、0から新規事業を立ち上げるためのプロダクトマネジメントと既存プロダクトを改善していくプロダクトマネジメントでは、使う筋肉が大きく異なる感覚があります。既存プロダクトにおけるプロダクトの根幹を変えるくらいの大きな機能でも同じことが言えるかも知れません。積み上げる成長においては、使ってくれているユーザーの声を聞いたり、データ分析をしてボトルネックを発見して、いくつも仮説を立てながら検証するプロセスを辿ります。しかしながら、非連続的な成長では既存ユーザーの声を拾っていても答えが出てこないので、在るべき姿から逆算して、ユーザーに答え合わせをします。鍛えるべき筋肉が異なるので、どちらも経験しておくことは無駄にはならないと思います。

そして、toCなのかtoBなのかという点では、個人的にはあまり気にしない方がいいと考えています。結局は、誰か"人"の役に立っていることは同じであり、課題を見つけ、解決策の検証をするプロセスは同じだからです。しかしながら、ユーザーの規模が異なったり、自分が作っているプロダクトを家族や知人にも使ってもらえる感覚はtoCの方がより感じられるため、toCをやりたいという気持ちが強いこともあると思います。toCプロダクトでかなりのユーザーボリュームを獲得するプロダクトはかなり難易度が高く、0から立ち上げることは難易度をさらに増していると思います。もし大規模toCプロダクトに携わりたい場合は、そういうプロダクトを運営している会社に転職するとのが早いと思います。

この節の最後に、僕のPdMのキャリアについての考え方を書いておきます。個人的には、PdMという役割に固執せずに、プロダクトを成長させるための役割であれば何でもチャレンジすることが長期でみても自分が成し遂げたいビジョンに近いと考えています。僕の人生におけるビジョンとは、インターネットの力を使って世の中をより良くすることなのですが、その一つの形として、グローバルで勝てるプロダクトを日本からぶち上げるという考えがあります。まだ、1mmも成し遂げられていないのですが、様々な経験を経た方が、その道に近づくと信じています。人生の時間は限りあるので、30代で何かしらのチャレンジをしたいと考えていますが、明確にプランを持っているわけではなく、目の前のこと、自分が最もバリュを発揮できる選択の中で、もっとも不確実性が高いものを選び続けるというポリシーでキャリアを選択してきました。まだ、答えは見えてないですが、PdMを続けるのか、事業責任者になるのか、エンジニアに戻るのかはその時に考えればいいと考えています。

PdM x エンジニアリング

プロダクトマネジメントとエンジニアリングについて考えます。3年目の考えでは、エンジニアリングの知識や経験が活きるケースはプロダクトの強みが技術的な部分にあるケースか、プロダクトの初期フェーズの二つであると考えています。

まず、技術的な強みがプロダクトにあるケース、例えば機械学習がプロダクトの強みである場合、機械学習の経験がある方がどういうユーザー体験が実現可能か、そのためにはどういうアプローチをして、どういう仮説検証をした方がいいのかという解像度はかなり高いと思います。

また、プロダクトの初期フェーズで例えば海外のプロダクトを日本に模倣して持ってくる場合においては何を実装するかがほとんど決まっているため、どう開発すべきかがわかった方が、様々な計画を立てやすいはずです。何をMVPで実装して、何を捨てるべきかを工数を加味しながら、エンジニアと話し、リアルタイムに意思決定できるため、アーリーステージでのスピードが強みになるはずです。ちなみに、インターネット業界において模倣される/することは日常茶飯事なので、劣化版コピーを作るのではなく、ユーザー体験をさらに研ぎ澄まして超越式に模倣していくことが勝ちにつながると思います。下手に違うものを作ろうとする方が、墓穴を掘ることになってしまうと考えています。

一方で、プロダクトフェーズが進んできて、そもそもどういうユーザー体験を実装していくべきかを考える時には、エンジニアリングのスキルはいるというよりも、リーンなUX改善をしていく方が価値があると思います。多少は、どう作るかが役立つ場面もありますが、成熟しつつあるプロダクトにおいては、エンジニアリングのバックグラウンドにこだわることなくプロダクトマネジメントに向き合った方がいい気がしています。

よくPdMもコードが書けた方が良いという話があるのですが、もちろん書けるに越したことはありません。僕は新規事業立ち上げの際に、ゼロベースで構築を進めていたり、2年経った今でも簡単な修正は自分でやったり、複雑な計算をRubyで書いたりとかなり便利です。しかしながら、コードをしっかり書けるようになるならば、最低でも3年は開発における実務経験を積んだ方がいいと考えています。継続できなければ、中途半端に終わってしまって、ちょっとわかるくらいで業務に活かせるレベルにはならない可能性があります。

もっと考えてみます。そもそも、プロダクトマネジメントにおけるエンジニアリングがわかると良いということは、どのような点でしょうか。ある機能のリリースまでを、デザインフェーズと実装フェーズに分けることができます。下記に僕が作成したSpeaker Deckの資料を貼りましたので、もし良ければ参考にしてみてください。

スクリーンショット 2021-11-20 23.19.47

優先度を決める際に考慮するべきは、この実装フェーズにおける開発期間がどのくらいかかるのかということです。また、その開発によってどの程度開発に無理をしようとしているか、つまり負債になってしまうかどうかという点が考えられます。開発は一つのコードの塊に書き足していくプロセスであり、その一行もエラーが出てはシステムは正しく動かなくなってしまいます。動いているものに変更を加えるため、基本的には注意しなければならない要件が膨れ上がり、簡単な機能でも実装することが困難になっていきます。またQAのことを考えると、機能は少なければ少ないほど良いというのが基本的な考え方です。機能がモジュールに分離されており、テストで担保できる可用性が高く保たれていればよいですが、それには全体を俯瞰しながら設計する熟練度が必要です。

話が長くなってしまいましたが、上記で挙げた考え方以上に様々なことが考慮されてアプリケーションは開発、運用されています。必然と、それらを考慮しながら要件定義したり優先度を考えられた方が良いというのが僕の考えです。しかしながら、僕はサーバーサイド開発 (Ruby on Rails) の実務経験がある一方で、アプリの開発は簡単なアプリをリリースした経験しかありません。そのため、iOS/Androidの開発については素人も同然で、どのように設計されて、どのような複雑性があるのかを詳細まで理解することは困難です。そんな自分がiOS/Androidの工数も自分自身で判断することは不可能です。そのため、普段の業務においても、ある機能を開発する際には各職能のエンジニアに工数を聞きながら優先順位を決めています。先ほど、僕はサーバーサイドの実務経験があると書きましたが、ここ数年、最前線に立って開発はしていないため、サーバーサイドも担当のエンジニアに全任せしています。

工数を見積もる際によく「この機能を開発する際に、どのくらい工数がかかるか？」という質問があると思います。開発には不確実性が伴うため (書き始めたら、どうでもいいところで詰まることがよく起こります) 、エンジニアからは、ある程度余裕を持った工数を聞くことになると思います。この感覚については、エンジニアの経験があれば各職能のエンジニアとスムーズに会話することができると思いますが、エンジニア出身以外のPdMでも各職能のエンジニアと上手くコミュニケーションしながら、要件定義や優先度決めができているので、経験が補ってくれる部分が多いように思います。

もう一点、そもそもその機能を実装する必要があるのかという点がごっそり抜け落ちてしまっていることがあると考えています。つまり、ある機能についての工数は見積もることができていますが、エンジニア視点での、そもそもその機能が必要なのかという観点を考慮にいれた方が適切なプロダクトマネジメントができると考えています。自分がエンジニア出身であればこの観点を持ち合わせていることがありますが、大事なのは「エンジニアの要件定義への参加」だと考えています。エンジニアが要件定義に参加することで、高い精度で要件定義から、優先度決めまでを行えるようになるからです。要するに、UX開発の民主化がPdMがすべきチームビルディングなのだと思います。ここでいう民主化とは、誰しもがUXに口を出すというような形だけのものではなく、ユーザー、セールス、クライアント、エンジニア、デザイナー、マーケティング、CSなど全ての観点をより深く考慮しながら、UXの検証をスピードを落とさずに進めていく方法です。これについては以下のスライドで紹介しているので、お手隙でご覧いただければ幸いです。

PdM x UI/UXデザイン

僕自身はUI/UXデザインの実務経験を持っていないため、あくまでもそういう背景を持ったPdM視点でのプロダクトマネジメントにおけるUI/UXについて考えます。当たり前ですが、UI/UXはプロダクトにおいて非常に重要な役割を持っています。端的に言えば、どのような素晴らしい体験をどのようなユーザーインタフェースで届けるかが範疇ということになります。

僕が考える、プロダクトマネジメントとUI/UXの交差点は、デザインの民主化です。民主化という表現が正しいかはわかりませんが、前述したエンジニアがUXにも越境するという考え方にも似てくるのですが、UI/UXにチーム全員が参加し、コラボレーションする姿が今のプロダクトマネジメントなのだと考えています。というのも、誰しもがエンジニアが書いているコード (アウトプット) に口を出す、例えば「ここのコードはもっと綺麗にできる」というフィードバックは誰もができるものではないですが、デザインにおいては「このデザインはちょっと違うな」とか「このユーザー体験でいいのか？」というように、誰でもフィードバックができてしまいます。ステークホルダーが多くなればなるほど、フィードバックの質や量がバラバラで収集がつかないというようなことはよくあることでしょう。

しかしながら、最も大事なことは自分たちが創りたい、ユーザーに提供したい価値があることは非常に大切ですが、最終的にはユーザーが判断するということです。そして、ユーザーからはデザインが良かったから課金したとか、競合と比べてこっちの方がユーザー体験が良さそうだったから選んだというようなフィードバックはほとんど得られないという性質を持っているため、どれが素晴らしいデザインなのかということを事前に判断することが難しいと考えています。結局は、ユーザーが判断するという前提で、自分たちが最も納得した形でユーザーやクライアントにプロダクトを提供できている状態が目指すべき姿なのだと考えています。

そこで、プロダクトマネジメントが果たす役割こそがデザインの民主化なのだと考えています。 目指す姿はプロダクトを届けるチームが納得した形且つ最高のUI/UXのプロダクトを提供し続けられるチームです。そのチームにおいて、デザイナーはただ単にUIやUXを作っては当てを繰り返す役割などではなく、チームの中心になっていると考えています。なぜなら、エンジニアリングとユーザー、ビジネスとクライアントなど様々な関係性の中で常に介在するのがデザインだからです。

民主化の具体は、デザインプロセスの可視化とチーム内コミュニケーションの最適化だと思います。特に、ステークホルダーになっている人たちはデザインのことだけを考えているわけではないと思うので、定期的にミーティングを開催しては、戻しがあって、また当てては修正をしてというプロセスでは適切なスピードで意思決定をしてプロダクトを届けるサイクルが破綻してしまいます。デザインが決まらなければ、エンジニアの手も止まってしまったりするのであまり良い状態ではありません。とはいえ、一人よがりでプロダクトをデザインしリリースしていても素晴らしい姿とは言えないと考えています (結果よければ全て良しという考え方もありますが) 。PdMが行うべきは、ステークホルダーに対してデザインの重要性を伝え続け、デザインのプロセスに適切に参加してもらう体制作りと、デザイナーと併走したデザインプロセスの可視化、ここでいう可視化は思考プロセス自体もSlackなどのコミュニケーションツールに適切な形で流していく仕組み作りを意味しています。

PdMの役割は、決めることです。先ほど、デザインは誰しもがフードバックできてしまう性質があると書きました。誰でもフィードバックできてしまうがために、ステークホルダーたちの意見が食い違ってしまっていたりした場合に収集がつかなくなってしまう可能性がありえます。その場合、ステークホルダーを一同に集め、情報の非対称性を解消した上でチームの答えに導くファシリテーションが必要かも知れません。また、ソフトウェアを扱っているならば、後からリリースを重ねて適切なデザインにしていくことも可能なので、まずはリリースしてユーザーの反応を見るということを握ることもできると思います。チーム一丸となって本気で半年かけた機能が、全く使われないということが常に起きる世界で僕らは闘っていることを忘れてはなりません。

UI/UXとは少し外れてしまいますが、PdMを含めたプロダクト開発に携わる人をはじめ、チームに属する全ての人がFigmaなどのコラボレーションツール (例としてFigmaを以下で使用します) を使った方がいいという話を書きます。

PdMがFigmaを使うメリットは多くありますが、より具体的性を持ったコミュニケーションができるという点でしょうか。同じコンテクストを持った人たちだけでプロダクトを創っている時は、自分たちが話をしていることのズレが起きづらいですが、今のプロダクト開発を取り巻く環境は多様性を持ったチームメンバー、外部の力も借りながら開発を進めていくことは当たり前になりました。そのため「あれ、こうして」みたいなハイコンテクストなコミュニケーションは通用しません。より具体的なコミュニケーションで認識のズレを整えながら進んでいく方が望ましいと思います。その際に、Figmaでさくっとデザインを作ったり、ミーティング用のスライドを作ったりができることは非常にメリットがあると考えています。Figmaの優れた点は、UIコンポーネントの使い回しで、UIデザイナーが作成したアプリ/webのデザインをわりと簡単にコピーして修正して使い回すことができる点です。そうすることで、自分が考えている意図がチームに具体性をもって伝えることができます。今までもホワイトボードを使ったり、パワポを使ったりしてできていたことではありますが、どこからでもチームがアクセスでき、誰もが変更できるという利点はかなり大きいと日々考えています。

イメージ

PdM x データ分析

普段触れるデータは何種類かあって、定性的なインタビューで拾った言葉たちも定性データとして扱っているはずです。ここでは、定量的なデータを主に考えていきたいと思います。

定量データを取得するための技術は、PdMの必須スキルだと考えています。プロダクトによってデータの置き場所は様々で、Google AnalyticsやFirebaseなどで管理している場合もあると思います。一方で、アプリやwebのログをどこかに蓄積 (S3やBigQuery) していて、SQLで叩けるようになっているケースもあると思います。チーム内にPdMと完全に併走できるデータアナリストが常駐していれば、必要なデータに必要な時にアクセスできるという体制が整っているかも知れませんが、そんなケースはほとんどないと思います。データが欲しいと思っても、すぐには見ることができず、データを依頼したとしてもラグがあったり、出てきたデータと本来取りたかったデータの意図がズレていたり、追加で欲しいデータが出てきたというようなケースはプロダクトマネジメントをしていてもよくあることだと思います。そもそも、データがない状態では目隠しをして闘うようなものです。非常にプロダクトを創るセンスが良く、それが持続的に続くという方ではない限り、再現性は低いと思います。

プロダクトマネジメントにおける、定量データの活用の仕方は、課題発見をする探索型のデータ分析、KPIマネジメント、機能改善における数値の変化、など複数存在します。

課題発見をする探索型のデータ分析をするフェーズはプロダクト解決においても成熟しつつあるフェーズだと思います。そもそも、何が課題になってプロダクトの成長が思ったように上手くいかないのかを調べる方法としては適していると思いますが、あたりをつけて臨まないと広大な海の中から宝を見つけるような途方もない作業になってしまうので気をつけた方がいいです。そして、重要な点は、既存のプロダクトのデータをいくら掘ったとしても、その延長の改善に繋がるだけだということです。既存の延長の改善が望めるケースは、そもそものアクセスしようとしているユーザーやクライアントの母数が大きく、シェアがまだ圧倒的な王者でない状態かと思います。例えば、他社のプロダクトと併用されているケースなどは自社のプロダクトのユーザー行動を定量と定性両面で分析していくアプローチが効果的だと思います。しかしながら、そもそもの市場がすでに枯渇していて、これ以上頑張っても年で数%の改善あるいはその逆しかないケースにおいては、その最適化にリソースを使うほどの余裕がそもそもあるのかを考え、もしも非連続的な挑戦をした方がいい場合は考えを改めた方がいいでしょう。

次にKPIマネジメントについてですが、大事なのはデータを取る手法ではなく、何をKPIとすべきかとどういうコミュニケーションを日々すべきかです。少なからず、会社として握っているPLみたいなものがある状態という前提を考えると、PLに沿うKGI > KPIが存在するはずです。KGIはかなり大きな粒度となってしまうので、KPIを達成していった結果としてKGIが達成されるという分解が必要で、そのKPIをいかにシンプルに設計して、日々チームが向き合って追える数値に落とし込めるかが非常に重要です。できれば、日毎に追える数値と週毎や月毎に追う数値は分けて設計することが望ましいです。そして、日毎に追う数値はみんなが常に見ているコミュニケーションツール (Slack) などに流れるようにするのが望ましいです。

最後に、機能改善における数値の変化のデータ分析についてです。

僕が考えているのは、その機能は本当にプロダクトの数値改善にヒットするのかということをデータ分析をして少しずつ明らかにしていく方法です。プロダクトの改善がクリティカルヒットするケースは限られていて、初回オンボーディングの改善や、コア機能のファネル改善 (ステップを減らすとかガラッとUI変えるとか) などです。しかしながら、そのような機会よりも成熟しつつあるプロダクトにおいては細かいUI改善などをしているケースも多いでしょうか。その場合考慮しなければならないのは、改善しなかった時の差分を慎重に見定めるということで、ABテストを正しくしましょうということです。正しくABテストをしなければ、時期的な要因で上がったのかなどの因子を排除することができず、よくわからない結果になってしまいます。そして、人間は自分に都合のよいデータの見方をするので、本当に正しくデータを解釈することができているかという専門性も必要になってきます。これらがなければ、なんとなく改善して、なんとなく数値が振れたということを数週間かけてやるみたいなことにつながってしまいます。こればかりは、理論を学び実践をしていくしかないので、周りに詳しい人がいない場合は書籍を読んで理論を学ぶことをおすすめします。

なんでも屋のサイヤ人になる必要はもちろんないと思いますが、誰かが書いたSQLをちょっと修正したり、簡単なデータは取得できる、あるいは適切に依頼できるスキルは身につけておくと良いと思います。

PdM x QA

プロダクトマネージャーが考えるQAと歩むアジャイルなチーム作りとQAの越境体験

僕がこの数年でもっとも悩んだ一つがQA (Quality Assurance : 品質保証) でした。なぜならば、QAについて体系的に考えて、その必要性や実施のやり方を考えてこなかったのに加えて、SaaSプロダクトの開発を通じて一つのエラーが起因として様々な方に迷惑をかけてしまうという現実があったためです。一方で、toC向けアプリのQAについてはチーム全員でぽちぽちして主要な機能が問題ないかとか、ユーザー数が多くいればユーザーさんからすぐにフィードバックがあるために、すぐに修正するという改善を回せていました。

そして、QAについてのノウハウもあまりインターネットや書籍で落ちていないように感じました。そんな中、様々なtoBプロダクトに向き合うプロダクトマネージャーの方にお話をお聞きして、それぞれ組織によって異なる方法のQAを自分たちの組織にアレンジして最適化することで、アプリケーションの変更が起因するインシデントを防ぐ、あるいは起きたとしても適切にお客さんにお伝えし、改善する仕組みを構築することができました。

具体的には、PdMと担当したエンジニア、他数人でどんな粒度の変更も変更点を洗い出して影響がありそうな機能と操作を網羅的に箇条書きにして、それぞれが上手くいくかを複数人の目でみるということをリリースサイクルの中にマージした、それだけです。いわゆるダブルチェックの強化です。加えて、もしもインシデントが生じた場合のエスカレーションフローを整え、まず事が生じたら、生じた事象をチーム全体に伝えて、対策チームを発足、すべてのお客さんに同じ対応をするのではなく、個別に対応を変えて最適な形 (お客さんによって契約状態や想定される反応が異なるため) にするなどのフローです。僕の感覚では、QAはプロダクトの性質やプロダクトが提供している価値 (お金に絡むものならめちゃくちゃ厳重にするなど) などによって様々なので、自分たちのチームに合う仕組みをインストールする必要があるように思います。

PdM x マーケティング

「どのようなプロダクトが売れるかを考え、そのプロダクトを売る方法を決める仕事」

マーケティングはかなり広い概念です。PMMの範疇になる領域だと思うので、このセクションではプロダクトとマーケティングの一致について考えたいと思います。

プロダクトとマーケティングの一致とは、もっと噛み砕いて書くと、良いプロダクトを創ったとしても自然と使われるようなことはなくて、どうやって使ってくれる層に伝えるかというコミュニケーションだと考えています。この、素晴らしいプロダクトを創るということと、適切に外部に伝える方法を考えて実行するということが解離してしまうと、せっかく良いプロダクトあるいは機能をリリースしたとしても誰も使わないものになってしまいます。

具体例で考えます。

例えば、日本をはじめ世界中で大流行した「Clubhouse」は招待制という機能をプロダクトに搭載していました。招待制とは、誰かが招待しなければプロダクトそのものが使えないという機能で、これがClubhouseのグロースに大きな貢献したことは否定しようがありません。Clubhouseは最初から、そのように設計されて日本をはじめ諸外国に持ち込まれ、インターネット感度が高いスタートアップ界隈、特にVCや起業家、そしてコネクションがあるインフルエンサーに爆発的に広がっていきました。これは、プロダクトの実装とマーケティングが上手く接合した良い例だと考えています。ユーザーがユーザーを呼ぶ仕組みが上手くアプリに実装されていました。

次にとてもマーケティングが上手いと思うのがPayPayです。PayPayがリリースしてすぐに、ビッグカメラで全額戻ってくるというようなキャンペーンを覚えている方もいらっしゃるのではないでしょうか。これをプロダクトマネジメント観点で考えると、リリースまもない状態で、バグがないことや本当にリテンションするのかということが確信が持てるか持てないというような瀬戸際で、100億円というマーケ費用をぶっこんでくるという、大企業ながらスピードでぶっちぎった例だと思います (大企業の上手い戦い方ですね) 。自分が担当するプロダクトで、数ヶ月後に100億円使うということを考えると、実装が追いつくかどうかなど様々なことを考えなければならないですが、マーケティングとプロダクトの実装が一致するとお金の殴り合いで勝利することができる例ですね。最近では、出前館がかなりアクセル踏んでますね。

新しいプロダクトや大きな機能をリリースする際に、マーケティング、つまりユーザーをどうに連れてくるかを考える必要があると考えています。これは、新機能であればアプリ内のマーケティングも考える必要があることを意味しており、アプリ内であっても素晴らしい機能を実装すれば自ずと使ってくれるというのは幻想です。アプリ内のユーザーの動きは、各々で最適化されており、主要機能でも気がついてないというのがほとんどです。自分もLINEやPayPayにチャットや決済以外の機能がどのくらいあるのかを考えてみてもいいかも知れません。もしも日々使ってくれるユーザ数を増やす場合、新規の獲得が改善するか、リテンションが改善する (起動頻度) かなど、どちからかを考えない限りにはアプリのグロースは難しいでしょう。しかしながら、めちゃくちゃ良い機能ならば自然と口コミで広がっていく (ツイートされるなど) というのもあるので、素晴らしい価値をユーザーに届けることが根底にあると思います。

PdM x ビジネス

まず、日本という市場においてはユーザーを囲ってから広告でマネタイズするという手法は通じづらいと僕は考えています。そもそもの日本語を使う人口のアッパーと広告という不安定なマネタイズで闘うには日本という土俵はとてつもなく難しいと思いますし、諸外国から輸入されてくるC向けプロダクトが強すぎる (エンジニアリングやお金などのリソースの桁が違う) ので、この闘いは非常に難しいと思っています。他にC向けプロダクトのマネタイズとして大成功をしているのは、サブスクリプションを提供しているプロダクトですが、日本全体が貧しくなっているという意見もあるため、NetflixやAmazon Prime、Spotify、払っている人はジムなどにも課金している (NHKとかスマホ代とかもありますね) 中で、さらに月額を払うプロダクトはよっぽどの価値を提供していない限りは課金しないあるいは継続しないだろうと思います。しかしながら、どの山をどのくらいの速度で登るのか次第かなとも思っています。

持続可能なプロダクトを創って上で、ビジネスとして成立するかどうかは最も大事な検証項目の一つです。どれだけ素晴らしいプロダクトを創ったとしても、維持するためには費用がかかるため、長期で回収できる見込みがなければただの慈善になってしまいます (会社によって考え方や仕組みが異なると思うので、一概に言えないです) 。加えて、働く目的は人それぞれ異なりますが、僕が考える働く意味は会社、個人のビジョンの実現であるため、その観点では、お金を儲けることは手段という位置づけになります。

PdMが新しくプロダクトや機能を設計する際に、どうやってマネタイズをするかを初期から考えることは必須事項だと思うようになりました。日本という限られた市場の中で、上場を目指す株式会社においてプロダクトマネジメントに携わっていると、いつどのくらいの売り上げが見込めるかというのが、プロダクト開発の投資判断に重要だと思うからです。少なくとも、僕が考える限りでは、ユーザーを一気に集めてマネタイズというのは難しいと思うからです。難しさというのは、ユーザーが多いプロダクトでは広告でのマネタイズか、サブスクリプション、あるいは投げ銭などのトランザクション寄りのマネタイズがありますが、貧しくなりつつある&諸外国のプロダクトへの課金を考えるとユーザーから課金していただくモデルはスケールするかが懐疑的だからです。

しかしながら、挙げたようなマネタイズを否定しているわけではありません。不確実性が高いと思っているだけなので、適切なアプローチによって不確実性が落ちる (他社プロダクトで成功事例があるなど) ならば攻めるべきだと考えています。考え方としては、マネタイズをグロースしてから考えようというアプローチが今の状況ではかなり不確実性が高いので、最初からセールスに詳しい仲間とどうマネタイズをするかという勝ち筋を粗々でもいいので考えるべきです。

SaaSモデルならば、どのくらいのクライアント数が日本 (あるいは世界) にいるのか、どのくらいが課金してくれる可能性があるか、どのくらいの単価になるか、そのグラデーションはどのくらいかというのを考えると良いでしょう。また、そのプロダクトが提供している価値は一社に一つでいいのか、それとも複数あっても問題ない (メディア的な性質がある場合はこっち) のかを考慮したりします。PdM個人が完全にこなす必要はなく、自分が商談の前線に立つ必要もないので、実際にクライアントと向き合うチームと並走して、不確実性を落とすアプローチを確立するのがいいと思います。感覚的に、クライアントのニーズに刺さっているプロダクトは、まだ開発してないのに少数からめっちゃ引きが強いなどの性質を持っていますが、ソリューションをリリースしたら見向きもされないなどあるので、PMFまで根気強さが必要だったりします。

PdM x 調整力

PdMの3年目で最も意識したことの一つが「調整力」です。どのフェーズにおいても、PdMだけでプロダクトを創っていない限り、ステークホルダーがいるはずです。プロダクトや組織のフェーズが進んでいくほど、調整力は重要なスキルになります。

プロダクトのフェーズが進むに連れて、実装される機能やマネタイズの複雑性が増して、利害関係者が増えます。よくある例は、ユーザービリティを優先するとマネタイズにネガティブな影響がある (アドネットワーク広告はない方が良いよねというシンプルな場合など) ことです。

組織のフェーズが進み、役割が細分化されてくる頃にも調整力は重要になります。例えば、新しいプロダクトをリリースする場合、ステークホルダーはとても多くなりがちで、経営層の承認、リソースを既存組織から確保する場合は既存事業の部門長たちといったように多くの利害関係者と調整する必要があります。

意識することは、メリットを考え続けることと認識の溝を埋め続けることの大きく二つだと考えています。

まず、相手のメリットを考えることでは、シンプルに「どういう状態になれば、相手が笑顔になるか」ということを考えて、笑顔の最大公約数を探すことだと思います。もちろん、関係する全ての人にとってメリットがあることが望ましいですが、そうならない場合もあります。例えば、新規事業を立ち上げる場合、既存組織から人的リソースを異動していただくとなれば、既存組織としてはただ単にリソースが純減するだけということになります。しかしながら、新しく立ち上げる事業からの送客やマネタイズがお互いにしやすくなる状態になったりすれば、事業を統括している人からするとメリットにもなり得ます。ただ単に、搾取し続けるだけでは、協力したいと思ってもらえることは難しいと思います。何がなんでもGiveできるかを常に考えることが利害関係を調整する上では重要です。

次に、認識を揃えることについて考えます。事業や組織の複雑性が増してくれば、役割が細分化されて、情報がどれだけ可視化されている状況でも入ってくる情報には限りがあり、情報の非対称性が生じることになります。情報の非対称性がある状態では、当たり前ですが、正しく意思決定ができるための情報が欠けていてはどれだけ優秀でも間違った意思決定をしてしまう可能性があります。PdMに求められる行動は、正しい意思決定をするために必要な情報を全て揃え、もっとも短い時間で頭に入るように整理をして、意思決定の場をファシリテーションすることです。コツは、全ての情報を集める執念を持ちつつ、情報を適切に構造化したドキュメンテーションを心掛け、出来る限り認識が揃うようにFigmaで図解しながら、何通りもの着地を考えることです。何通りものパターンを思考済みにしておくことで、どんな質問や議論があらぬ方向にいってしまうことを防止し、スムーズに意思決定へと進めることができると思います。また、自分が最もいいと思うパターンを決めておくことも重要です。最終的には、プロダクトに対して意思決定をして押し進めなければなりません。建設的ではないディスカッションが永遠と続き、ディスカッションしていること自体に満足してしまっては誰も幸せにならないのです。そのためには、考えうるパターンにおいてメリット、デメリット、できれば短期と長期のシミュレーションを何度も何度もすることが重要です。もし、自分の力だけでは情報を整理できなかったり意思決定に自信がない場合にはステークホルダーのうち、忌憚なくフィードバックしてくれる人に壁打ち相手になってもらうことで、事前にわかりにくいポイントであったり、議論すべき論点を整理することができると思います。

PdM x 意思決定力

PdMの役割を突き詰めれば、プロダクトを成功に導く意思決定をすることが残ると思っています。この数年で最も悩んだことであり、これからもずっと悩み続けるだろうと思うのが、正しい意思決定をするにはどうすればいいかということかと考えています。

論理的に考えてわかりやすい意思決定については、1~2年目の段階で、課題を構造化しつつ、整理して言語化するステップは経験値が溜まってきた感覚がありました。意思決定をする場合に重要だと思うことを何点か書きたいと思います。まず、複数の課題を同時に解決できる意思決定 (= 解決策) かどうかです。山積していく課題に対して、一つの意思決定で複数の課題に対してアプローチできるかどうかを考えています。また、長期的な意思決定かどうかです。短期視点で、目の前の課題をすぐに解決することは大事な一方で、長期視点になって正しいと思うかどうかを常に思考しておくことが大切だと考えています。そして、複利的に作用するかどうかという点で、一つの意思決定が後に巡って大きな成果を導いてくれるかどうかを考えながら意思決定をしています。また、意思決定においては周りを巻き込みながら進めていくことが大事で、プロダクトに対する意思決定は責任とセットで誰かが最終的に行うものだと思いますが、そこに至るプロセスを正しく進められているかが非常に重要です。なぜかというと意思決定だけでは何も物事は進まないからで、仕事を前に前に進めるのは自分でもありますが、多くは関係するチームのみんなだからです。それぞれ違うバックグラウンド、考え方をしている個が同じベクトルを持って物事を前に進めるためには、納得感がある意思決定プロセスを辿る必要があって、そのことについて橋本さんの記事の中で触れられています。

1．立場、意見が異なる人に主張の機会を与える
2．期限を決める
3．判断権者はいずれの主張の当事者にも加わらない

論理的なアプローチで答えが明確になる課題であれば良いのですが、悩ましいのが論理的なアプローチで選択肢は絞られてたとしても、最終的に正しい意思決定がわからない類のものです。これがあるから、どう意思決定をすべきかという永遠の課題を解決できずにいます。

論理的なアプローチでは答えがでない課題とは、論理的に考えてもわからない不確実性を伴った課題だと解釈できます。不確実性とは、上記noteで説明しているのですが、ランダム性を持った不確実性とフィードバックによる不確実性の二つに大別することができます。それぞれ簡単に説明すると、ランダム性を持った不確実性は、コインのようにランダムな事象が伴ったもので、フィードバックによる不確実性は結果が原因となってという複雑な連鎖を伴った不確実性を言います。どれもどう考えても答えがでないという性質があるのですが、大事なことは何が不確実性を持っているかということを明らかにしておくことです。KGI > KPIという形で構造的に分解をしていき、解像度を上げておき、不確実な部分が上手く行った場合と上手く行かなかった場合の両方のシナリオを短期で考え続けることが大事だと思います。

「長期は楽観して、短期は悲観する」と表現することもできます。プロダクトの大きな方向性は変えないにしても、短期における選択肢は常に不確実性を伴った難しい問しか残らないので、常にどの選択肢を取るとどうなるかということを3 ~ 6ヶ月を目処に考え、ロードマップを引き続け、チーム内あるいは経営層と握り、説明責任を果たすことが重要です。

toCなのかtoBなのか

プロダクトマネジメントをしていく上で、toCプロダクトなのかtoBプロダクトなのかは指向性が分かれる場面です。個人的には、PdM1年目の時には、やるなら絶対toCプロダクトだと考えていました。なぜなら、家族や友人を含め沢山のユーザーが使ってくれ、嬉しいフィードバックが来る量も異なるので、その虜になっている自分がありました。

しかしながら、toC/toB両方を経験して、どっちも誰かの役に立つという最終目的は同じであること、プロダクト開発のプロセスも考え方は多少違うにしても、課題を見つけ解決策を立案して、要件定義をして、実装、リリースするというプロセスは同じだと考えています。そのため、極論すると、こだわりを持たずに自分が最もバリュを発揮できそうなプロダクトを選べばいいというのが今の僕の考えです。

大前提、同じ人が同じプロダクトを違う文脈で使う場合もあり得ます。例えば、LINEを開発していたとして、ある人は友人とのコミュニケーションでLINEを使い、その人は働いている会社の商品をPRするためにLINE公式アカウントをお金を払って利用しているかも知れません。完全なtoC、toBもありますが、BtoBtoCのようなプロダクトも存在します。そのため、toCなのかtoBなのかとバッサリと分けることに意味はないのかなと思う時もあります。

しかしながら、前途したようにPdMを初めた当初は絶対にtoCプロダクトだ！と考えていたのは、日本からグローバルで勝てるプロダクトを創りたいという気持ちからです。正直その気持ちはまだ捨てられてないです。ジェフ・ベゾスさんも30歳で起業したらしいので、むしろ今は経験値や実績を積む期間だと思い、toC/toBどっちでもえり好みせずにチャレンジし続けるのが良いだろうと考えています。

組織/プロダクトフェーズにおけるPdMの役割

PdM1年目、会社として初めてのPdMという役割を任せていただき、PdM3年目にはPdM複数人体制という規模にまで成長してきました。組織のフェーズとしても10名以下の時から100人を超える規模に至るまでにおけるプロダクト開発にずっと携わってきました。PdMの役割は、組織やプロダクトのフェーズによって様々です。1,000人を超えるような会社においても、新規事業の部署で少数でプロダクト開発を行っている場合は、スタートアップに似た部分があるはずです。

プロダクトフェーズが初期で、組織規模も少ない場合はプロダクトを成長させていくために、リソースを充てることができない欠けている役割が少なからずあると思います。エンジニアリング、デザイン、CS、マーケティング、採用にいたるまで、組織にいる人たちだけでなんとかしなければなりません。昨今、スタートアップにおける採用が難航しているケース (特にエンジニア) が多く、一人の守備範囲が広くなってしまう場合もあると思います。そのため、PdMに求められる役割は自ずと広くなってしまいガチです。もちろん、全てをこなすことはできないので、自分が最もリソースを割くべき役割を考え続けることが大切ですが、割となんでも屋な立ち回りが必要なフェーズだと思うので、本当に「崖の上からから飛び降りながら、飛行機をつくる」という言葉が合っていたと思います。

プロダクトや組織フェーズが進んでくると、求められる役割が明確になり、いわゆる組織最適化が行われるようになります。何でも屋PdMから、殻を破って専門性を高める必要性が出てきます。なぜなら、組織最適化が進んでいくと、何でもやりますというのが型にハマらずに、結果として成果に何もコミットできなくなってしまうからです。悲観することではなく、安定した組織でプロダクトを成長させていくためには、必要なことです。個人的には、このフェーズが、小さいフェーズからPdMをやっていた自分にとっては苦しかったと思います。

このフェーズでPdMに必要なことは、そもそもプロダクトはどの方向性に進むのかということを経営層と握り、KGI > KPIを定義して、KPIを達成するために課題になっていることを考えて、改善をひたすら回すというプロセスです。その際に、求めらえることは調整力であったり、不確実性を素早く落とすスキルです。エンジニアリングやデザインの役割は、人が充てやすくなっているはずなので、チームビルディングを通して、自分が手を動かさずに適切に権限委譲して、上手く回すことに徹する方が成果に結びつけやすいと考えています。コツとしてはチームの進捗を定点観測することと、アウトプットの質を高く保つことをチーム全体としてできるかどうかだと思っています。あとは、課題設定が間違っていなければ、プロダクトは成長していくと思います。基本的なプロセスは以下です。

1. 成果 (KGI) とは何かを定義する
2. 成果までのKPIを設定する
3. KPIを達成するまでの期限を明確化させる
4. 進捗を定点観測する
5. 定点観測ごとにKPI達成までのギャップを埋める施策を立案し実行する

組織/プロダクトのフェーズがさらに進んでくると、成長の踊り場に差し掛かる機会が増えます。なぜならば、基本的にはマーケット自体の成長と、そのマーケットにおけるシェアの奪い合いが行われているので、マーケット自体の成長が止まり、類似プロダクトが増えてくる又は別の課題解決手段が出てくるとシェアも分散化するため、そもそも成長することができなくなってしまうからです。特に日本というマーケットだけを狙っている場合は、1億人強が利用者のアッパーになります (もちろんインターネットにアクセスできる人はもっと限られます) 。逆にマーケット自体が成長している場合は、競合プロダクトを含めて、成長を続けることができますが、いつかは止まると考えた方がよいと思います。考えなければならないのは、この成長の踊り場にぶつかった時には、今までの連続成長をするアプローチではどうにも上手くいかない、下手したらシェアを徐々に奪われてしまう可能性もあります。プロダクトのコモディティ化が早い世の中を考えると、シェアの奪い合いは短期では良い戦略ですが、長期で考えると同じことの繰り返しであるため、俯瞰した見かけ上は成長していないかもしれません。必要になってくるのが、解決できる課題を増やすこと (UXの伸長と呼んでいます) か、多事業化を行い、シナジーを効かせていくことです。簡単な例でいくと、SmartNewsがクーポンの提供を開始したり、Amazon Primeに入ると商品がすぐに届くだけではなく値段は同じで何でもありみたいな豪華さがあることでしょうか。僕の勝手な印象ですが、グローバルな企業、SpotifyやNETFLIXはそれだけをやっているわけではないと思いますが、ワンプロダクトで世界に勝負をしているのと、日本企業は国内で様々な事業を運営している印象があります (もちろん、そう見えているだけの話なのですが) 。

解決できる課題を増やすこと、多事業化 (= 新プロダクトの創出) をしていくことは、個人的には連続的な成長とはかなり異質なプロダクトマネジメントが必要だと考えています。不確実性に向き合うスタンスを間違えると、何も上手く行かない膠着状態が続いてしまうことになりかねないと思います。というのは、新しいことは現時点からみると、異質で成功するかわからないものという性質を持っているからです。逆に新しさがなく、誰でも考えつくようなアイデアでは、すでに誰かがやっていたり、すぐに真似されて期待している成長はできないと思います。新しいことは、そういう性質を持っているという認識が組織全体とできるようにPdMは振る舞う必要があります。これがめちゃくちゃ難しいことで、一歩間違えると全体からみて何かよくわからないことをしているチームみたいな見え方がされてしまいます。様々な会社で取り組んでいることだとは思いますが、子会社にして別の管理をする、同じ会社内なんだけど、オフィスを分けるなどのアプローチで、このわからないものを育てるアプローチをしているのですが、既存アセットを活用できないなどの悩みもあって一般解がないと思います。僕自身も新しいプロダクトを創ることの再現性をどうやって高めていくかということを常に考えてチャレンジしている最中です。

僕が考える新規事業の再現性を高める考え方を現時点バージョンで書いておきます。一つは成長するまでPdMが説明責任を果たし続けることです。会社としては人とお金を投資している状態なので、いつになったら成長するの？どのくらい利益があるのか？ということを常に考えていて、投資対象かどうかを判断しています。この時、既存事業にリソースを投資した方が投資対効果が良いと判断されてしまうと解体になってしまうので、新規事業を行う目的から常に認識を合わせることと時間軸を入れた説明をして、現状はどういう状態か、何が不確実な部分でどういうアプローチでそれを解明しようとしているのかを常に説明して、投資価値があるということを示す続ける必要があると考えています。なぜならば、新規事業ほど本質的な価値の開発にフォーカスしなければならない状況下で目の前の数字を求めら続けてしまっては、本来みんなが到達したかった地点に辿りつけないことになってしまうことがあるからだと考えています。全員が成功を願っていて、悪気はなかったにしても、目の前の数値だけを見たマネジメントでは誰も幸せにならないというのが僕のが考えです。加えて、新規事業の目的にもよるのですが、しっかりと利益が上がるビジネスモデルなのかというのがとても大事だと考えています。まずは、ユーザーを大量に囲って (そのために赤を彫り続ける) 後でマネタイズしようという闘い方は何もないスタートアップならではで、既存組織でやろうとすると相当余裕があるか、ぶっとんでいるかどちらかではないと、できない技なのかなと考えています。最後に、既存アセットを最大限活かすということを徹底するということです。なぜかというと、既存アセットがゼロの状態は、スタートアップとなんらかわらない状況なのですが、どうしても既存組織に引っ張られたり、意思決定が遅くなってしまうため、ガチなスタートアップ、それしか生きる道がない組織と闘った時に、スピードでぶっちぎられるという (これがイノベーションのジレンマ) のが起こりえるからです。既存アセットというのは、今まで組織に蓄積されているノウハウや人員リソースを充てるなどもありますが、今まで築いてきた営業リソースや関係値、ブランド名を活用する方法です。これらを使って闘わない限り、決死の覚悟で同じことをしようとしている人たちには勝てないのかなと考えています。しかしながら、既存アセットを上手く活用することは、既存アセットを持っている方の考えからすると、多少なりともリソースを使うことになるので、調整力が必要になります。

PdMは何でも屋なのか

PdMは「何でも屋」だと表現されることがありますが、実態としてはそう見えてしまう部分はありつつ、PdMが意識しておいた方がよいことについて書きます。自分が何でも屋だと思い「ニセ仕事」に奔走させられ、時間はかなり使ったのにプロダクトはまったく成長してないというような状態に陥らないために、日々の仕事に対する考えを整理しておくことは非常に重要です。

プロダクト開発において、誰しもが仕事がなく宙に浮いてるという状態はないと思います。エンジニアとして採用された方はコードを書くし、CSで採用された方はお客さんと向き合っているはずです。しかしながら、プロダクト開発では専門領域に落ちない、あるいは複数部門を横断した課題が無数に存在します。それら課題を全員で取り組んでいては、本来専門性が高くバリュが発揮される場面に適切なリソース配分ができなくなってしまい、それこそプロダクトの成長を阻害することにつながってしまいます。そういう性質を持った仕事の中で、プロダクトの成長に寄与することを拾って解決するのがPdMがやっていることの実態だと考えています。そのため、客観的にみると何でも器用にこなす人という見え方になるのだと思います。もちろん、全てをやるべきではなく、適切に判断する必要があるのですが。

僕は、何をすべきか迷いそうになった日の朝に「業務棚卸し」というnotionを書いて、フラットに自分がやっていることやるべきと少しでも思うことを階層構造に落とすということをしています。タスクを網羅的に書くことでもいいですし、解決すべき課題ベースで書いてもいいと思います。常に自分を客観視して、自分がリソースを使うべきことは何かを考え続けることが大切だと考えています。

全てを完璧にこなす必要なんてない

PdM1年目の時には、任せれた重圧から、一つ一つの施策は失敗ができないと考えていました。完璧主義体質があるので、何でも完璧にこなしたいという思いから、全てのことに対して全力で挑み、それが故に結果として上手くいかないということを繰り返して、精神的にも病んでいました。

その状態から、個人的にはだいぶ改善されたような気がしているのですが、今は「小さな失敗は前進しているためで、大きな方向性が合っていて長期で成果が残せればいい」と考えるようになりました。むしろ、小さな失敗を許容できず、勝率だけを意識してしまうと、細かい積み上がり、長期で見たときの成功とは本来かけ離れたものになってしまうと考えるようになりました。しかも、完璧であることを周りに求めてしまうことも筋が違っていて、細部にこだわることと、細かい失敗が許されないことは別で、大きくチャレンジできないチームになってしまいます。

これは、論理的にも説明することができます。プロダクトを成功を左右する不確実性においては、正しい意思決定は長期的にしか証明することができないという性質を持っています。つまり、短期の予測がある程度できる意思決定の中で失敗をしないということを繰り返すと、誰しもが考えつく、コンセンサスが取りやすい方向にしか進まないため、大きな振れ幅がなく、コモディティ化の道を辿ってしまうと考えられるからです。必要なのは、遠くに旗を立てて、方向性を常に確認しながら、ちょっと躓いたとしても、それを学びにして進んでいけるプロダクトマネジメントであると考えています。

「任せる」の本当の意味

チームでプロダクト開発をしていると、当たり前ですが役割分担が必要になります。そして、複数のプロジェクトや開発案件が同時に走っている時には、全てを一人が担うことは難しいので「任せる」ことが必要になってきます。PdM1年目の僕はこの「任せる」ということの意味を履き違えていて、結局は自分に様々なものが回ってきてしまう状況を作り、自分がボトルネックとなってしまって消化不良を起こしてしまっていました。「任せた」という言葉だけで、考え方を押し付けたり、手法の部分まで口を出してしまうマイクロマネジメントをしているとお互いにとって幸せな結果にはならないということを学びました。そもそも、自分自身もそのようなマネジメントをされたいのかという、相手の立場に立って考えることが欠落してしまっていました。

「任せる」ことの本当の意味は、課題と責任をセットにして託すということだと今は考えています。方法は何でも良くて、助けが必要なら全力で助け、全任せして課題が解決されるならばそれはそれでいい。その方がチーム全員でたくさんの課題を解決することができることに気がついた (というより痛みを伴って学んだ) ことは本当に良かったことだと思います。その際のコツは、情報の非対称性を無くすことです。論理的にはなってしまいますが、同じ情報を持っていれば、間違った意思決定にはならないだろうという考え方で、逆に情報が足りなければ異なった意思決定になってしまうと考えています。それは、課題の全階層において言えることで、課題が解決されたことを評価する立場にあっても情報量が足りてない場合もあるので、チーム内に存在する全ての情報を適切に渡すことが重要です。

素晴らしいプロダクトは素晴らしいチームから

素晴らしいプロダクトがあるから素晴らしいチームができるのか、はたまた逆なのか。ニワトリとタマゴ問題における僕の答えは素晴らしいチームが先にあることです。それは、プロダクトの成功は素晴らしいチームが素晴らしい仕事をしていく積み重ねの上に成り立っていると考えています。

「戦は“数”じゃねェ “人”だ」
by 信 (キングダム)

キングダムには人生、プロダクト開発にも通じる学びが沢山あります。序盤、主人公である信の名言にもある通り、適当に相当量の人を充てたとしても成功しないのがプロダクトを創るということであり、少数のチームが巨人を倒すことができるドラマがあるのもまた然りです。InstagramがFacebookに買収された時の社員数が13人だった話は有名です。

では、ゼロベースで考えた時に何が最初にあるべきなのでしょうか。僕はそれは「思想」だと考えています。言い換えれば、Big Pictureになるのでしょうか。どういう素晴らしい世界を創ろうとしているのか。そのストーリーへの共感が素晴らしいチームを集めるためにまずは必要なのではないかと思います。そして、圧倒的な熱量。もしもたった一人だったとしても、思想と熱量があれば「なんか、勝てそう」という印象を与えてくれるし、それがプロダクトにも反映されていくだろうと思うからです。思想と熱量は、言語化の有無を問わず行動指針になって、日々の小さい業務に落ちていきます。一回一回の商談、プロダクトの細部にも行き届いていくと信じています。実はその小さい積み重ねが非常に重要だと思っていて、ユーザー、クライアントも人であり、人ならば合理的ではない部分がどうしてもあるからです。

叫び続ける

素晴らしいプロダクト、素晴らしいチーム、働きやすい環境、圧倒的な成長機会が得られるスタートアップが本当に多く増えてきたと思います。エンジニアに限らず、全ての職種が引く手数多な市場になりつつあります。

その中で、自分の時間を賭けて関わりたいと思ってもらえるように企業はあらゆる努力をしていると思うのですが、募集を出して、待っていれば優秀な人が来るというようなことは全くないので、自分たちがどういうチームで、何を成し遂げたいのかを叫び続け、お互いの夢を達成するためにチームビルディングをしていく必要があります。どんなに苦しくても、チームビルディングに妥協をしてはいけないと強く思う日々です。

一人では何もできない

当たり前ではありますが、PdM歴が少しずつ長くなるにつれ、自分一人では何もできない、何も成し遂げることはできないと強く意識するようになりました。チームにおけるそれぞれの役割を明確に意識するようになったからです。

プロジェクトマネジメントにおいては、PO、PdM、PjM、エンジニア、デザイナの役割を明確に決めて、認識を合わせます。自分たちの役回りを阿吽の呼吸のように察知して、それぞれが守備範囲を広げていくこともありますが、組織のフェーズが進んでくるに連れて、プロダクトの成功確度を高めるためには、各々の役割を明確にして周知することが重要であると考えるようになりました。これは「任せる」ということにも繋がっています。

それぞれの役割が明確だからこそ、染み出していく距離感もわかるようになり、負担になりそうな時には助けることができるなど、背中を合わせて向き合っていけるような感覚があります。

自走できる組織とは

まずは「自走できる組織」とは何か、から考えます。自走できる組織とは、その組織に所属する者が以下のステップを踏めることを意味していると考えています。

1. 自分が何をすれば良いかを考える
2. 行動する
3. 成果に結びつける

なぜ「自走できる組織」が求められているのでしょうか。それは、自走できる組織の対極の存在である、上下関係の指揮命令によって動く組織がこの不確実性が高い世の中において限界になったことが考えられます。というのは、指揮命令においては、階層構造の中での情報の伝達が下から上へ、上から下へという順番を従って行われます。これが高速にできていればいいのですが、情報量が多かったり、複雑な場合はすぐに意思決定ができなかったり、情報の欠落が生じた場合に現場の考えと経営層の考えとの間のギャップが大きくなりすぎて、結果的に成果にも結びつくことができずに自然淘汰されます。この流れがインターネット化された世の中で高速に変化してきたと考えることができます。「ヒトデはクモよりなぜ強い」においても「開かれた組織」がそうではない組織よりも強いことが、ウィキペディアなどを例として紹介されています。

自走する組織において絶対に必要なことは「情報をフルオープンにする」ことです。自走するためには、チームの全員が自分がすべき役割を自分で考えるために情報が必要になります。また、コツとしては自分の思考プロセスもある程度整理された状態で可視化するのが良いと考えています。「こういう状況なので、次はこういうアクションを考えています」とか、悩んでいることとかを随時オープンにしていくことで、自分がどのように考えているのか、助けてもらいたい余地はどこにあるのかをさらけ出すことができます。チームの各々が、次はこういうアクションを取ろうと、未来について思考しだすことができます。また、状況が変わった場合において、前提条件が揃った状態であれば、同じように打ち手をすぐに変えることが可能だと思います。加えて、3年目のプロダクトマネジメントでは、自分が先んじて思考プロセスやら全ての情報を可視化することで、チーム全員が同じように何を考えているか、他でもらってきた情報 (例えば、他のチームの動きなど) を積極的にシェアしてくれるようになりました。そのような組織は少数であったとしても、同じ方向を向いて力を合わせることができるので、従来よりも早く様々なアクションが取れると信じています。

急成長するプロダクトに身を置くこと

僕自身は最初はエンジニアとして、そして社内初のPdMとして、急激に成長するプロダクトを担当していました。急成長するプロダクト (≒ 組織) に身を置くことで、思わぬ成長チャンスが巡ってくることが多いと考えています。

そもそも、成長チャンスとは僕の定義では簡単には、今のスキルや経験では超えることができない、ちょっとだけ高い壁、課題にぶつかり、自分の自分の試行錯誤で越える過程で身に付くスキルや経験と考えています。つまり、自分がまだ経験していない、高すぎない壁にぶつかる機会が巡ってくる必要があります。

急成長するプロダクトは、成長に応じて、どんどん難しい課題が降ってきます。今の時代、採用の難易度がとても上がっているので組織の成長速度 < プロダクトの成長速度であることが多く、最適なタイミングで課題に適した人材が採用できるということも稀なので、成長速度のギャップから難しい課題を今いるメンバーで解いていく必然性があります。その課題の量と質が高ければ高いほど、成長機会になりうるということです。そして、そのチャンスのバッターボックスに立ち続け、バットを振り続けることが成長に繋がると僕は考えているので、急成長するプロダクトにどの役割でも身を置くことが重要だと考えています。

銀の弾丸なんてない

健全に成長しているプロダクトのPdMに話をお聞きすると、ほとんどが当たり前のことを泥臭く実践しています。そのような話を聞くたびに、プロダクトの成長に銀の弾丸なんてなくて、泥臭い積み上げの先にあるのだと考えています。

しかしながら、その中でも急成長するプロダクトの要素は、泥臭いことを超高速に回していることかと思います。マーケティングならば、広告のパターンを何通りも何通りも試験し、プロダクト改善ならば、ABテスト基盤を構築して並列に何通りものパターンを試すといったように仕組みで成長を促進される試みをしていることが多いように感じます。そして、銀の弾丸はないにしてもアクセルを踏むべきところは、しっかりと踏むことを繰り返しているとも思います。

あとは、一次情報にしっかりとアクセスして学びを得ている印象があります。インターネット上に落ちている情報は基本的には外に出しても大丈夫なように加工されているケースが多いので、情報を持っているコミュニティ、当事者に会いにいく姿勢を持っている人がちゃんといることが大事です。ユーザーインタビューを通して自ら情報を取りにいくことも大切で、とにかく加工されていない一次情報を基に思考して、プロダクトの成長に繋げる動きを直向きにやり続けることが重要なのだと思います。

長期思考と短期思考

PdMは長期と短期において、プロダクトの未来を考えておくことが必要です。そして、そのバランス感覚を保ちながらチームや経営層とコミュニケーションをしていきます。

長期では不確実性が高いので、アバウトな予測、最も遠くではこういう世界を創りたいくらいに考えておき、短期ではコンサバに予測をします。来週はこうなっているだろうという予測はよっぽどのイベントがない限りはそれ通りにいくと思いますが、半年先は今の世の中においてだと見通しがつかないと考えています。「NETFLIXの最強人事戦略～自由と責任の文化を築く～」においても、プロダクト開発最強集団NETFLIXでさえも半年先以上は見通しがつかないと考えているようです。

長期思考をさらに深く掘ると、業界予想というかユーザー環境においても長期のトレンドは何かということを考えて、未来はこうなるだろう、だから自分たちのプロダクトはこういう位置付けで、こういう世の中にしていきたいと考えることが大切だと思います。未来の中で、人間的な不変的な部分とテクノロジーによってゆるやかに変化していく長期トレンドがあります。例えば、買い物であれば、できるだけ安い方がいいし、できるだけ品質が良い物が良いし、できるだけ早く届いた方がいい。そして、今はバズワードになっているかも知れませんが長期ではいずれかのタイミングで「メタバース」のような世界がやってくるのだと思います。自分のプロダクトがどういう長期トレンドに乗っているのか、逆に衰退してしまう業界であった場合にどうしていけばいいのか、考え続けることが大切です。

短期思考を深く掘って考えます。短期とは、最大でも半年先で、多くは四半期くらいをイメージしてます。まずは、一年くらい先のざっくりとしたロードマップを引きます。この時は、具体的な機能というユーザー、クライアントにどういう価値を届けるか、どういう状態になっているのが理想かというように引くことをイメージしてます。どういうビジネスモデルを検証するかということに置き換えても良いです (価値の対価としての利益なので、ほぼ同義) 。そして、四半期の中盤くらいに、次の四半期はどういうプランで行くのかを考えるくらいでいます。四半期のプランは近ければ近いほど綿密にしていて、週単位、プロジェクトであれば日単位のガントチャートでもいいかも知れません。

この長期と短期のバランスを考えることが重要で、日々会社の優先度が変わっている中で、リソースの投下先を間違えたら、時間は取り返しが付きませんし、初期のスタートアップでは死活問題になります。

連続な成長と非連続な成長

連続な成長と非連続な成長を考える際に重要なのは、前後関係があるということと、プロダクトのライフサイクルの短命化です。まず、連続的な成長の前には、必ず非連続な成長、大袈裟に表現すればイノベーションがあります。イノベーションとは大きく言い過ぎですが、非連続的な成長と連続的な成長をしていくプロセスは機能の発明と磨き込みであると考えられます。僕は、この二つの成長を担えるようになりたいと考えていますし、必要性がどんどん高まっていると考えています。

それは、プロダクトライフサイクルの短命化という運命が見えてしまっているからです。その根底には、技術的な革新による社会実装のハードルが下がっていることが考えられます。いわゆる、コピーされやすくコモディティ化しやすいということです。「Moat(モート): スタートアップの競争戦略概論」に書いてありますが、Moat (参入障壁のようなもの) は基本的には時間軸があり、ほとんどの場合、長期でみたらコモディティ化してしまうという未来があります。「スタートアップが利用すべきMoat」と「スタートアップが利用しづらいMoat」も築くのは簡単な話ではないですが、とてもわかりやすいです。

たとえ非連続な成長を繰り返していったとしても、連続的な成長の先が細くなってしまうというような世界になりつつあると感じています。非連続な成長では、そもそもどのような課題が世の中に存在していて、どういう解決策があるのか、それは本当に受け入れられるのかという不確実性が存在します。この仮説検証を高速で回し続けていくアプローチは連続的な成長とは異なります。基本的にはコンセンサスが取りやすい、誰が考えても理論的に考えつく課題は、すでに誰かが解いているかコピーされやすいからです。このイノベーションの罠は、ユーザーに課題を聞いても、自分たちが聞いたとしても競合が聞いたとしても、精度はあるにせよ同じようなことが抽出されるということにあって、同じようなプロダクトが同時期にリリースされるのはこういう性質があるからかとも思います。言うなれば、会議で通しやすいのです。しかしながら、最終的に評価するのは使ってくれるユーザー/クライアントです。ヒアリングで聞くべきは、事実です。どういう生活を送っているのか、どういう業務をしているのかを事実ベースで聞いて、潜在意識の中に潜む心理を一つ一つ紐解いて仮説を立てて、プロトタイプを作って、仮説検証をしていくのが正しいアプローチなのではと考えています。

連続的な成長では、基本的には最適化、機能の磨き込みを考えます。非連続的な成長は最初の一歩であり、ハマりそうということがわかれば次のステップではどうやって機能を磨き込むかということと、どうやってユーザーに知ってもらうかということを考えます。重要なのは、知ってもらうということもセットで考えることだと思います。実際にユーザーに聞いてほしいのですが、新しくリリースした機能を知っているか尋ねるとほとんどの人は知らなくてショックを受けることが多いです。それは論理的に考えると当たり前で、今使っている人たちは、その行動が習慣化しているため、目的を持ってサービスに訪れるため、用が済んだら他のことは目に入っていたとしても認識はしないからです。普段、生活している中で目に入ってくる情報だが気がつかないことはとても多いです。そのため、人類は広告という手段やマーケティングを科学して進歩させてきたわけです。そして、重要なのはスピードです。たとえ同じ価値を提供しているプロダクトであったとしても、最初に頭に入ったものの印象に支配されることはよくあること (第一想起とは別物) で、これと言えばこれというようなブランドを形成していく最初の一歩になると思います。改善と認知を高速で回し続ける。これが連続的な成長で必要なことです。

しかしながら、前述したように長期でみたらコモディティ化してしまうことが考えられるため、非連続的な成長 => 連続的な成長をし続けるのが重要なのだと今は考えています。

未来からの逆算と現在からの積み重ね

プロダクトを創っていく上で重要なことが「思想」と「逆算」だと考えています。思想とは、どういう世界にしたいのかという意志であり、まだ世界にはないし、異質なものと周りから見られてしまうようなものがそれにあたると思います。なぜ重要かというと、目の前のトレンドばかり追いすぎてしまうと、結局何をやりたかったのかがチーム内でもバラバラになってしまうのと、実は一時の流行りで終わってしまい、その後の展開がなく、尻すぼみになってしまうと思うようになったためです。大局を見なければ、素晴らしい　世界は実現できないと思うので、プロダクトを創っていく上では非常に重要です。しかしながら、既存プロダクトを運営していく中で、業界やユーザーの課題について解像度が上がっていき、大きな画を描けるようになるということもよくあることなので、重要なのは常に学び続けることと、サンクコストやイノベーションのジレンマに囚われずに、常に新しい未来を創っていける覚悟があるかどうかだと思います。

次に思想があるだけでは、物事は前に進みません。遠くに旗を立てた後には、10年後はどうなっているか、5年後はどうなっているか、3年後はどうなっているか、1年後はどうなっているか、半年後はどうなっているか、というように逆算して考える必要があります。ちなみにLINEが10年前の2011年にリリースされたらしいので、10年後の世界は本当にわからないですね。当たり前ですが、今から予測した1年後の未来すらも多分大方外れると思います。しかしながら、目指す方向性があるかないかでは、チーム内の意思決定が徐々に変化してくると思います。そして、未来こうあるべきというような考えは常にアップデートし続ける必要があると思っていて、不変的な思想とアップデートされる部分を上手く切り分けて考えると良いと思います。会社でいうとビジョン、ミッションのようなものは階層構造上部になるほど不変であると思います。提供するサービスの在り方は、存在する社会によって変化せざるを得ない部分だと思うので、全員が合意できているのであれば変化してもいいと考えています。

この章の最後に、プロダクト成長におけて積み上げていくことについて書きたいと思います。前途した思想と逆算の話はあくまでも企画の段階なので、日々の業務が動くまでの粒度になっていません。日々の業務は、機能のデザインをするとか、コードを書くとか、クライアントとのアポイントメントに行くなどかなり具体的な作業だと思います。そのような日々の具体的な業務は、プロダクトロードマップを逆算していった先に、四半期の目標があり、そこから月ごとの目標、週の目標というように具体性が高まっていくと思います。超具体的な内容はプロダクトによって様々だと思うので、考え方を書いておきたいと思います。

超綿密に計画されたプランである場合を除いて、具体的な業務をこなしていった先に得られたフィードバックを学びとしてチームにインストールして、未来の業務を規定するといった仕組みがプロダクトを創っていく上では非常に重要だと思っていて、極論言えば、四半期が始まる前に立てたプランと、四半期が終わって振り返ったときの軌跡が全く異なっていても、プロダクトが正しい方向に成長していれば良いと考えています。なぜなら、日々の業務をしていく上で、ユーザーやクライアントの課題の解像度が上がって、少しずつ戦略を変えていくことや、競合の打ち手によって優先度を変える必要があったり、技術的なイノベーションによって実現可能性が変化することで開発のプランが変更になったり、採用が思った以上に進んで解決できる課題が増えたり、新しい人によって新しい視点がインストールされたりなど、様々な要因によって、事業解像度がアップデートされるためです。この日々の積み重ねを組織に最適な形で仕組み化することで、プロダクトは成功へと近づくと考えています。

なぜ新規事業が必要なのか

個人的に行ったアンケートでは、PdMの大体半数が新しいプロダクトと向き合っているようです。新規事業と言っても広いので、既存事業がある中で新しい事業を創っていくことと考えます。そして、新規事業とは会社として取り組む「新しい収益の仕組み」と定義して考えます。

新規事業を立ち上げる目的は、会社によって本当に異なると思います。既存事業も成長しているが新しい収益の柱を創りたい、ビッグウェーブが来ている市場がありチャンスに乗りたい、顧客ニーズをヒアリングしていったら別の予算から収益化できそうな芽が見えてきたなどなど。

新規事業に向き合う際に非常に重要なことは「なぜ、新規事業が必要なのか」という目的を常に経営層 (特に意思決定者) とすり合わせながら進めることです。なぜなら、新規事業は大抵の場合上手くいきません。上手くいかないにもレベルがあって、全くダメなのか、事業計画と比較すると成長速度が少しビハインドしているのかなどです。レベルによりけりですが、必ず「このまま進んでいって良いのか？」という問いが下手したら社内に広がっていきます。この時に立ち返るべきは、そもそもの目的である「なぜ、新規事業が必要なのか」という問いです。この問いに対する答えが少なくとも担当するPdMの中でブレてしまっていると、すぐに撤退からのリソース最適化という状況になってしまうと考えられます。PdMは常に「なぜ？」という問いかけを自分にして、周りに説明する責任があると思います。

プロダクトを信じる

プロダクトが数年以上に渡り、中々成長しない時に誰しも苦しみ、開発を続行すべきか悩んでしまうと思います。これを僕は「沖に出て、ビッグウェーブが来ることを信じて待ち続ける」と表現しています。世の中には耐え忍ぶ期間があって、市況の変化によって一気にグロースするプロダクトも存在します。しかしながら、本当に波が来なくて徒労に終わってしまうこともあるのが現実なので難しいところです。

共通していることは、やはり長期トレンドに乗っていることだと考えています。例えば上のDuckDuckGoでは、ユーザーの検索履歴や位置情報など様々な個人データが取られ、様々なサービスを横断して使われて広告が最適化される。これに対して、ユーザーが意図せず行われてきたものが個人に委ねられるようになるだろうという世界的なトレンドがあります。AppleでもCMで訴求されていますね。この長期のトレンドに乗って、ずっとプロダクトを改善しながら待ち続けていたからこそ、今の成長があると考えることができます。それまで待ち続けるだけの体力が会社としてもあるかどうかが重要です。

別のケースではZoomでしょうか。世界的な在宅ワークの流れに乗って、オンラインミーティングのビッグウェーブが来ました。一長一短あるとは思いますが、実はほとんどがインターネット化された世界においてはオンラインでのミーティングでも生産性はある程度担保できた (そうなるようにみんなが努力し続けた) ということでしょうか。

言うは易く行うは難しで、長期トレンドを見つけて、いつ波が来るかわからないところにずっと貼り続けることは並大抵の精神ではなく、個人レベルでではなく組織レベルで高い熱量を保ち続けることは非常に難しいのだと思っていますが、そういうプロダクト/組織は素晴らしいなとも思っています。

執念とはなにか

執念と表現すると、やや体育会系に聞こえますが、やり切り力と言いますか、PdMにとって非常に重要なスキルだと考えています。なぜなら、人間は論理的な生き物ではないからです。ちょっとした怠惰な心や、苛立ち、浮かれから間違った意思決定をしてしまうのが人間なのです。すべてが論理的な思考の基に行動ができるならば、痩せようと思う時に痩せることができて、英語を勉強したいと思えば1年もすれば誰もがある程度は話せるようになるし、勉強したいと思えば誰しもが偏差値をあげることができます。しかしながら、人間はそういうようには設計されておらず、誰しもがある部分では感情的な意思決定をします。これは仕事においても多少なりとも影響があると思っていて、さすがに仕事をサボるとかは論外ですが、プロフェッショナルだったとしても最後の詰めの甘さであったり、リサーチ不足であったり、どこかでやり切れない場面があるものだと考えています。

だからこそ、何がなんでもやり抜く執念深さがプロダクトの成功を左右することもあると信じています。論理的に考えるのであれば、そうならない方法もあると思っていて、目標管理を厳密にすることです。仕事における目標や何をするかまでをマイクロマネジメントをして未達成でれば減給や降格といったようなペナルティを与え、達成できる者には昇給と昇進というメリットを与えるマネジメント方法ですが、これが破綻しているのは否定しようがないですし、目標管理をする人の目が行き届いてないところでギルティを犯してしまうのはニュースを見ていれば一目瞭然でしょう。個人の自走力、部門を突破するコミュニケーションなどが求めれる時代において、各人の執念深さはどこかで差となって現れてくるのだと考えています。しかしながら、組織の在り方には様々なあって、成功してる企業においても千差万別なので、正直一概には言えないなというのが所感です。

成長し続けるために

PdMとして、一人の社会人として成長し続けるためにこの数年間続けてきたことを書いておきます。

一つはインプットとアウトプットをしまくることです。インプットという面では、重要なのは情報感度が高いコミュニティに属することで、自分一人だと情報収集の網羅性には限りがあるので、多角的な情報を得るためには、情報感度が高い人が属している組織に自分も属して発信をすることだと考えています。また、自分でコードを書いてPdM Tree (@pdm_tree) というTwitter上のメディアを立ち上げたり、自身のアカウントで一次情報を得るための行動をしたりしています。アウトプットという面ではPdMノウハウを不定期で書いていて、それ以外にも様々な節目では自分の頭の中を言語化することにチャレンジし続けています。

もう一つは内省を続けることと、弱い自分と向き合い続けることです。自分は常に劣っていると考えて、どうすればより良い状態になれるのかと常に考えています。内省する技術は、上手くいかないことがあればまずはSlackのDM (誰も見てないところであればOK、Twitterの鍵アカとか) で、何が上手くいかなかったら、どうすればよかったのかをフローで書き込んでいき、一定溜まってきたら、整理してnoteの下書きやnotionに書き込んでいく感じです。二度と同じミスはしないように注意していけば、いつの日かより良い自分になれると信じています。内省していく時に重要なことは、自分は弱い存在であり、その弱さから逃げずに向き合続けることだと考えています。つい自分の弱い部分から目を背けて虚勢を張ってしまうところを、グッと堪えて弱い自分を許し、向き合うことをしています。大切なのは自分自身を否定しないことと、改善を諦めないでいることだと思っていて、そんな簡単には変われないかも知れませんが、より良くする努力は欠かさないようにしようと考えています。

何もかも上手くいかない時

日々、仕事をしていると何もかもが上手く行かない時があって、今でも頻繁にあります。上手くいかないことが続くと、心も病んでいって、心の変化は体にも影響してきてしまいます。僕自身も何度もこの問題にぶち当たって、なんなら今でも悩むことが多いです。

この3年間で身につけつつあるのは、落ち込んだ時の心理に打ち勝つ方法ではなく、上手く付き合っていくマネジメント能力です。誰しもが上手くいかないこともあるという前提に立っていて、スタートアップに入ったばかりの時は自分は特別強い人間だ、そんな自分がメンタルで病むことなんてないとばかり思っていて、実際にその状況に陥った時には、もうやばいという状況になるまで認識できずに爆発してしまうということがあります。そして、それは一回だけの話ではなく、何度も訪れることなのです。メンタルヘルスへの向き合い方は、まず自分がどういう状態なのかという自己認識を高めることから始め、自分がまずい！という状況になったら適切に"抜く"ことを仕事の一部と認識して取り組むことです。

疲れたから美味しいものを食べにいく、リフレッシュのために公園に散歩にいく、無心になって映画を見たり漫画を読んだりするなど、自分が心踊ったり、リラックスできる手段を何個か持っておき、やばそうなら積極的に休むことが長期で見た時には大事であると考えています。

プロダクト開発は終わりのないマラソンです。全力疾走していては体力が持ちません。しかしながら、ペースを上げるべきときにはアクセルを踏む必要もあって、休む時にはしっかり休むというメリハリが必要です。それが自分のメンタルマネジメントの技術を改善し続けることだと考えています。

人生を何に捧げるべきか

日々、仕事に忙殺されていると大局を見失うことがあります。PdMはプロダクトの意思決定者として、世の中を変えるような素晴らしいプロダクトを創る機会があります。どんなプロダクトを創るべきかという長期の視点に立って、時間、つまり限られた人生を何に捧げるべきかは考え続けたいと思う日々です。小さく終わりたくないし、どうせならグローバルで使われるプロダクトを創りたい。

自分がどんなプロダクトに関わりたいのか、情熱を燃やし、寝食忘れるくらい熱中できるプロダクトを創りたい。そうずっと考えてきたのですが、情熱を燃やすということは、巡り合わせではなく、長い実践の中で育まれていくものであり、素晴らしいプロダクトを創れたとしてそれが幸せなのかというと、また次の大きな目標が目の前に立ち塞がるだけなんだと考えるようになりました。

大切なものは、ほしいものより先に来た
by ジン (HUNTER×HUNTER)

HUNTER×HUNTERのジンの名言にもあるように、人生において大切なものは、ほしいものよりも先に来るのだと思います。それは、仲間と共に四苦八苦してプロダクトを創ることに熱中している日々であり、意識しないとすぐに過ぎ去ってしまう時間なのだと思います。何かを達成することではなく、本当に大切なことはそこに到達する過程にあるのではないでしょうか。

成功体験は捨てる

たった数年ですが、プロダクトマネジメントに向き合ってきて、成功するかどうかは運が良いかどうか次第でもあると思っています。同じ論理、同じ手法で挑んでも一年前の成功体験ですら、市況が大きく異なる昨今では成功するかどうかわからないのではないかと思います。つまり、過去の成功体験がむしろ思考を狭めてしまう可能性があることを示唆しています。少なからず、失敗した体験を振り返り伝播していくことは同じ過ちを二度としないように進歩してきた人間に備わっている素晴らしい機構の一つです。

再現性が高いプロダクトマネジメントとは、成功した体験はすぐさま捨て去って、アンラーンをして、今までの経験を紐解き、最も確度が高いと思われる打ち手を高速に仮説検証することだと考えています。その中で、成功体験は、そのまま適用するのではなく、確度が高いだろうアプローチを考える助けになるという位置づけが望ましいと思います。何年プレイヤーになったとしても、このアンラーンのプロセスを持ち続けることで、どの時代においても最先端を学び、成果を残し続けられるPdMになれるのかなと考えています。

プロダクトマネジメントは愛だ

誰しも、成功したいと思っている一方で、どれだけ考えても成功するプロダクトは一握りです。そんなに現実は甘くないのです。特にソフトウェアの領域において、プロダクト創りは終わりのないマラソンです。

果てしないプロダクト創りの旅において、最も重要で欠かせないものは、やはり「愛」なのだと信じています。数値だけを見て、売上だけを目的に設計され、創られたプロダクトには誰も心が響かないのではないかと思います。愛とは、見返りを求めないGiveであり、対象の健やかな成長を望んだ行動、自己犠牲なんだろうと考えているので、自分のキャリアのため、自分の評価をあげるためなど自分にベクトルが向いた行動は短期では結果として見えるかも知れないですが、長期でみるとどこかで破綻するのではないかと考えています。やっぱり、気持ちが籠もったプロダクトには心惹かれるし、何か成し遂げられるエネルギーを感じるんですよね。

最後に

少しでも目を通していただいた方、貴重なお時間をいただき、ありがとうございました。少しでも、読んでいただいた方のお役に立てたら、それ以上嬉しいことはありません。素晴らしいプロダクトが世の中を明るく照らすことを願っています。

ここに書いたことは、現時点で自分が考えていることの言語化です。来年、再来年は考えがアップデートされているに違いないと思います。自分がどんな考えを持っているのか楽しみです。

2021年も残り少ないですが、お体に気をつけてお過ごしください。

次はiOSエンジニアの石田さんの「機械学習を使ってUIを補完するAppleの研究の紹介」です。お楽しみに。

delyでは一緒にプロダクト開発に向き合ってくれる仲間を募集しています。


この記事が気に入ったらサポートをしてみませんか？