【PdM 1年生】 悩みと学習のプロセス
早いものでプロダクトマネージャー（以下PdM）になってあっという間に1年間が経っていました。
今回はCAMPFIRE Advent Calender 2024の12/9の担当として、アドベントカレンダーにかこつけて、1年間の学習の集大成として、noteにまとめてみようと思います。
▶︎CAMPFIREのアドベントカレンダー
PdM1年目/やってみたい人が、取り掛かる前/1年経った時に、「確かにそうだった」「こいつよりはできた/できなかった」という相対的な視線を持てるようになっていること、を目指して筆を取っています。
特に、BizサイドからPdMになった人向けの要素を詰め込んだつもりです。読んで良かったら絶対に拡散してください。絶対です。
これまでも、優秀な先人たちがたくさんのPdM1年目のnoteを執筆されていますし、体系化された記述や体験記としてはインターネットの海に投げ込まれまくっています。それを踏まえて、このnoteでは実際に僕が抱えた5つの悩みを軸として、ストーリーの形で記述することを心がけます。
▶︎凄すぎる先人たちのnote
このnoteのを読むときの地図
このnoteで描かれる悩みは、僕が直面した悩み時系列順にPickupして記載しています。おそらく同じような流れを何周もしながら、少しずつ一人前のPdMへと成長していくのだと信じていますが、一つの地図として参考にしてみてください。
何から手をつけるのがいいのかわからなかった過去の自分に対しての処方箋の気持ちもあります。と同時に、これから悩む方々の処方箋となってくれることを祈っています。
悩み①：何ができるのか、何を勉強すればいいのかがわからない
どのような悩みか
もう無限に言いたいことはありますが、何を差し置いてもこの悩みが最初に来ると思います。このnoteを読もうとしていただいた方はみんなこれを期待していると言っても過言ではないように思います。
僕はどう悩んだか
誰もが直面する悩みなので、殊更に記載するものでもないかなとも思いましたが、PdMをマネジメントする方々に役立つ気がしているので、あえて詳細に書き記そうと思います。
悩み始めたのは、「自分に価値が出せていないことを実感する瞬間が多ったから」でした。
これはたくさんの要素があると思いますが、多くのPdMの方々が自分たちの業務の範囲を説明することに窮しているのとほぼ同義で、本当に他方面に対する業務が待っています。
その中で、今までは特定の領域で何かしらの価値を発揮できている気がしていた人が、PdMとなったことで急に自分には何ができるのかを見失う、ということです。
その場の処方箋として、僕はよくインターネットで拡散されているPdMのスキルマップを見て自分と相対化してみたりもしてみましたが、今の自分の不足を認識するだけで、あまり建設的に振り返りを進められなかった記憶がすごくあります。
どうするといいか
正直これを勉強すればいい、というものは星の数ほどあると思います。しかし、一番大事なことは「ポジションをとって動く」ということに尽きるのではないかというのが、僕の1年目の振り返りです。
具体的には、これまで自分が比較的できる/得意だった、というものを武器にしてとにかく動く、という点に尽きるように思います。僕の場合は、ある程度データに明るかったことでした。SQLが書けたので、分析を通じてある程度の事業数値/ユーザー行動について定量的に理解をしていました。これは大きなアドバンテージとなります。
もちろん、SQLは書けるに越したことはないですが、ポジションはなにもそれに限りません。CSとしての業務に由来するものでもいいですし、デザインについてでもいいと思うのですが、とにかく自分のドメインについての理解を背景に動く、ということが重要だと思っています。
僕は比較的本やメディアの情報を摂取することに苦はないですが、それでも大事だと思っていない情報はさらっと抜けていくもので、その時の情報は全く身になっていません。良かれと思って「Kentaくん、これ読んでみなよ」と言われた本もその時には大事だと思えないこともしばしばです。
その結果として、今では結構本の役割を割り切っています。
わかったつもりになるために読む（ドメイン理解のきっかけを得る）
得た経験を後から体系化するために読む（整理して血肉にする）
もちろん、前者の建て付けとして何かを学ぶことは重要ですし、意味あることだと思います。しかし、『何かができるようになる』、というプロセスとしては、インプットすることよりも、インプットしたくなる状態を作ることが重要だと思っています。これは向き不向きはあると思いますが、僕は完全に行動で得た経験を後から体系化するために読む、が性に合っています。
なぜこうするといいか、どうするともっと良くできるのか
一番の理由は、学習効率の観点から、これが後続の全ての悩みを生み、解決するきっかけになるからです。行動なくして大した悩みを持てません。逆にいうと、とにかく動けば健全に悩みます。
ただ、動くと言っても大事なことが一つあります。それは、様々な物事に対して「決める」という自負を誰よりも背負おうとすることです。
開発の現場から「⚪︎⚪︎さん、PdMとしてこれ決めてもらえませんか？」というお願いをされる瞬間もそうなのですが、可能であれば、企画や目標設定の段階から、自分が決めた・決めようとした瞬間を作ろうとすること自体に意味があると思います。
結果として、「これは自分が決めた」と思っていることや、「これは××さんが決めたが、この点が大事だった」と整理できていることが全てに効いてきます。
そしてここでの悩みが②につながってくると思うのです。
悩み②：意思決定に自信が持てない
どのような悩みか
意思決定を意識し始めると、必ずと言っていいほど出現する悩みだと思います。しかも、ここでの「意思決定」はかなり多方面の領域を含みます。
上流になれば、予算やロードマップについても決めることがありますし、現場になれば開発の方針や仕様/企画の細部について、意思決定はついて回ります。
この悩みのとても厄介な点は、自分に土地勘が全くない領域でも意思決定を回避できないことが本当に多く、論点を出すことがそもそも自分1人ではできないという点にあると思います。
僕はどう悩んだか
僕が最初に悩んだのは開発についての意思決定でした。より具体的には、ある企画を進めたくて、EMの方に開発是非についてお伺いさせていただいた時です。
事業数値・ユーザー数値にある程度イメージを持てていた僕は、あるファネルにおいての突破率の改善がかなり事業成長に寄与しそうなことを特定します。また、その解決策としても、業界の慣習にも違わないある程度筋の通ったものが企画できていました。
しかし、いざ開発に進もうとすると課題に直面します。
どれくらいの難しさなのか、工数感を把握したくてラフにお伺いしたのですが、「実装に詳しい人がいないのでなんとも言えない可能性が高く… 設計も慎重にしたい箇所ですし…」という回答をいただきました。そして、「2週間ぐらい設計と調査ができれば、大枠は見えると思うのですが…」という精一杯の解決策もご提示いただきます。
さてここで、僕は悩みます。「開発不確実性が高いかもしれないが、解法としての確度も高い」、いわゆるトレードオフが発生している状況です。
結果として、上長などに相談しつつ、実際に開発を進めることにするのですが、この後この開発は紆余曲折することになります。（後述）
どうするといいか
では、先ほどの開発の後日談からです。
実はこの開発はその後、実装設計の課題に直面し、かえって開発難易度を高めてしまいます。ある環境では動作しなかったり、既存の設計に実装を付け加えるだけでは無理がある箇所が出てきてしまいます。
『解決する確度が高いのであれば、開発難易度が高かったとしても多少時間をかけてリリースするべきである』、というのが意思決定のポイントでした。
しかし、この意思決定には不足していた観点があります。それは「なぜ開発難易度が高いのか、不確実なのかを誰もしっかり評価できていない」という点です。端的には、判断するに足る根拠を並べきれていなかったのです。
振り返れば、根拠が出せないのであれば、意思決定の俎上にあげてはいけないという振り返りでもありますし、どうすれば根拠を揃えられるのか、もっとたくさんの人を頼るべきでした。
この話においては、下記が振り返りポイントです。
「実装に詳しい人がいないのでなんとも言えない可能性が高く… 設計も慎重にしたい箇所ですし…」「2週間ぐらい設計と調査ができれば、大枠は見えると思うのですが…」
では、『どの箇所が実際に調査をするべき箇所なのか』、『どの手法を使って調査をすることで「わからないこと」が「わかるのか」をクリアできるのか』、少しでも意思決定のための材料を揃えるべきだったと思います。
ここで、少し抽象度を高めて振り返ってみます。
・根拠がないなら意思決定はしてはいけない
・根拠を出すためには、土地勘がないことがほとんどなので、頼るべき
前者についてはある程度語れた気がするので、ここでは後者について補足していこうと思います。
（特に1年目の）PdMにとって、こうしたクリティカルな論点に対する、根拠出しはできないことがほとんどだと思います。土地勘があれば、そもそも論点と根拠を自分で出せますし、判断に悩む時は大体自分が門外漢のケースだからです。
なので、とにかく頼る、これにつきます。わからないこと自体は恥じることではなく、意思決定の自負を負った自分が、より考え抜いた判断ができていないこと自体を恥じるべき、と肝に銘じましょう。
なぜこうするといいか、どうするともっと良くできるのか
PdMである以上、多くのステークホルダーにプレゼンをし続けることが一つの業務になります。意思決定について、背景となる根拠があることがその際の一番の指針になります。
今でもたまにフラッシュバックするのですが、あるシニアエンジニアさんに
これって誰が決めたんですか？
と言われて、言葉に詰まったことがあります。自分が決めたことだったのですが、「自分です」とはすぐに言い出せないような、根拠のなさと未考慮の論点がありました。
説明できるだけの根拠を揃えておくこと、そして「この人はいつもちゃんと考えている」という信頼を得ることが、懐刀になります。（ｲﾁﾊﾞﾝﾀﾞｲｼﾞ…）
また、もう一つ大事だなと思う姿勢があります。
「ぶっちゃけ、ここはまだわかりません」ということをちゃんと主張できるようになることです。今自分が、「わからないこと」を「わかっている」、というスタンス表明ができることです。
周りの人からすると、「何がわからない」のかも「わからない」というのが、PdMという仕事です。上長や周りの人に「ここは論点と自覚しているな」、と思ってもらえることが論点や根拠を集める上でかなり大事です。
「わからない」のゲシュタルト崩壊を起こしかけていますが、とても大事なことなので、ご愛嬌と受け止めてください。
悩み③：なかなか開発が進まない
どのような悩みか
これはエンジニアバックグラウンドを持たないPdMについて、全員が等しく直面する悩みなのではないでしょうか。
「思っている以上に進まない…」
「どうやって相談をしに行っていいかもわからない…」
悩み始めると結構袋小路です。しかも、レポートラインの上長たちに進捗報告しようとすると、「まだうまく実装が進んでいなくて…」としか説明がつかない状況になるので、ただただネガティブな空気が立ち込んできます。
僕はどう悩んだか
このポイントについて一番悩んだのは、①②の悩みが少し開けてきて、チームにスクラムを導入して初めて取り組んだ、ある決済領域に関する企画を推進している時でした。
▶︎（参考）CAMPFIRE2024春頃に各チームにスクラムを導入してました
スクラムを導入することで、僕は根拠を集められない、という悩みを一部克服しつつありました。少しずつ、判断するための細かな情報がチームで流通するようになってきたためです。
また、チーム全体でわからないことを明確にして、調査を細かく区切って取り組む、という姿勢もかなり相性がよかったです。
しかし、この決済企画、それで以てしても中々に手強いアイテムでした。わかりやすい話、技術的負債が溜まりすぎていて、進みながらリファクタをするしかない、という状態です。
チームとしてもスクラムの習熟度は段々高まっていき、何が障害になっているのかは常々チームに流通していくようになる一方で、最終的な見通しがなかなか立たないほど、ただただ実装が複雑なことを認識していきます。
僕は、この状況をどう乗り越えるのか、中々踏ん切りがつかない中、数ヶ月を経てしまいます。
最終的には、このアイテム開発をペンディングし、僕がPdMとして別で取り組んでいたフロントエンド分離（FE分離）の文脈に載せ、明確に先にリファクタを推進しきることで、不透明な状態を終わらせることにしました。
▶︎（参考）フロントエンド分離を推進しているCAMPFIRE
どうするといいか
大事なことは「理由の把握とブロッカーの除去」、これに尽きると思います。当時の僕は、「理由はわかっているがブロッカー除去に踏ん切りがつかなかった」と言えます。
何が起きているのか、そしてそれを潤滑に進めるために、PdMとして何が折衝に入れるのか、ここに自分の価値を最大限に発揮するべきです。
この場合では、リファクタの必要性と規模を早めに理解した上でブロッカーの除去の優先度を高めるべきでした。（ここでのブロッカー除去は負債への対処）
もちろん、ロードマップの引き直しなど、大変な局面はたくさんあり、時間はかかったものの、この時の僕は何が問題なのかを根拠をもって説明することができたので、最終的に順番の並び替えに至ることができています。
少し抽象化すると、直面する開発課題が負債の場合は、撤退水準を決めておくことも一つ手なのだと思います。まさにバランスシートのような関係だと思いますが、技術的負債については、その上で対処する中長期的なイメージを持っておく必要もあります。ロードマップの折衝においては、なぜそのリファクタを早めに対処するべきなのかを、事業の数値と照らして会話ができるようにしっかり根拠を揃えることも、もちろん忘れてはいけません。
また、開発の難しさを挙げてしまう理由については、下記の要素も挙げられると思います。
・なぜやるのかが伝え切れないことによる解決策の難化
・相談をしにくい環境を作っていることによる問題解決のスピードの低下
ここではそれぞれについて詳細は語らず、概要の記載にとどめますが、これらも大変重要な要素だと思います。
前者については、後述する悩み④（デザインレビューが難しい）にも関連しますが、実現したい体験の設計が弱い時に起きがちな問題です。
作りたい体験と必要な機能についてしっかり説明をすることができていれば、それを実現する実装手段は本来多様だと思います。しかし、その実装手段を狭めるような説明を無意識にしてしまうことがあるので、注意していくべきだ、という話です。
必要以上に機能として説明してしまうと、実装手段を限定してしまい、開発難易度を高めてしまうことに繋がりかねません。もっと「なぜやるのか」から議論を展開することで、別の解決策を考えることができ、そもそもの解決策の難易度を落とすことができます。
また、後者の相談の観点についても、かなり重要なポイントだと思います。、これは僕はスクラムという仕組みの中である程度解消されていましたが、やはり、デイリーを実施するなど、相談を常に拾える体制を作れるのかは生産性に対してダイレクトにヒットしてきます。
PdMとしてありがちな状況として、「⚪︎⚪︎さん（PdM）カレンダー埋まりすぎてて相談しづらいんだよな。もっと考えてから相談しよう」とエンジニアさんに思わせてしまう、というものがあると思います。
これは明確に避けるべきです。そもそも自分の時間としてどこが相談可能なのかを示したり（カレンダー上開いている時間はハドルなどで声をかけてください、と開示しておくなど）、デイリーには必ず出席したり、といった工夫がかなり相談の難易度を下げます。
なぜこうするといいか、どうするともっと良くできるのか
ユーザーに価値を提供する上で、開発スピードは一つの強みになるから、という原点は大事にしておきたいところです。そして、上述のようにうまくやるコツについてはポイントがあると思います。
・負債など、実装ハードルによる問題
・なぜやるのかが伝わっていないことによる問題
・相談のしやすさによる問題
それぞれ対応策は異なりますが、全てに共通するのは、根拠を用意し、意思決定に自信をもつくこと、だと思います。根拠を持って説明すること、またその根拠を常にオープンに受け入れようとしていること、このスタンスの表明ができると、自ずと解決されていくのではないでしょうか。
明日からでも始められる工夫は3つ目の相談に対するオープンな自分を作ることです。ただし、それは裏返しとして、相談に対して明瞭な答えを出せるように自分なりの根拠を常に持っておく旅に出ていく、ということでもあります。
悩み④：デザインのレビューがうまくできていない
どのような悩みか
体験やデザインに対しての議論が難しい、という広い意味で抱く悩みでもありますが、PdMとしてはどのパターンのUIを採用して実装するのか、をジャッジする意味合いで登場する悩みなのではないでしょうか？
よくあるのは、「なんかこっちの方が好き」で「こっちではない気がする」という状態です。こうなってしまうと、デザインレビューが建設的に進まなくなり、デザイナーさんの1000本ノック状態に入っていきます。
なかなか企画がまとまらなくなっていき、次第にこの企画を進めなくてはいけない理由にまで疑念が至ります。
また、この段階での”なんとなく”デザイン案採用は、実装時点でかなり多くの論点を呼ぶことになります。「こうできると軽くできるんですが」というエンジニアさんからの相談を受け入れたりすると、より最悪です。
つまるところ、判断の基準がぶれまくっている状態に陥っていきます。
僕はどう悩んだか
一番最初に悩み始めたのは、先に少し触れたフロントエンド分離の推進の時です。フロントエンド分離は、それ自体としては、開発体験の改善を目的としたプロジェクトでしたが、その一環として、実装だけでなく、既存UI/機能の見直しを行なっていきました。
そのプロセスでは、なぜその機能やUIを残すのか、逆に削るのか、を既存のサービスの画面に対して向き合っていくことになります。ユーザーの行動は最終的には事業の数字につながっています。明確な指針なくして、判断をしていくことはかなり難しいです。
その機能は今まで何を果たしていたのかについて、ユーザーに対する意味合いと、実際のユーザーの使用状況を見直し続ける中で、新UIを確定させるまでのプロセスで大変悩みました。
また、もう一つ転機がありました。
チームに多くのデザイナーさんが合流してくださったことです。より意義のある体験設計プロセスをチームとして組み上げていく過程で、僕の存在がボトルネックになっていくことを徐々に感じていました。
どうするといいか
これまでも根拠を大事にしていきましょう、という話をしていますが、デザインにおいては、体験仮説とストーリーがそれにあたります。
判断がブレないようにするには、ここをどれだけ抑えられているか、に掛かっている、といっても過言ではないです。
・今ユーザーはどういう状態にあるのか＝課題仮説
・それをどのように変えていけるという仮説があるのか＝体験仮説
・それが実現されるとき、ユーザーはどういうストーリーを体験するか
これを議論の土台として据えることができれば、ストーリーラインの順守ができているか、何が順守にあたってのキーポイントになるのか、をしっかり議論することができると思います。
秋口からCAMPFIREでもこれを作るための企画書の運用が少しずつ始まりました。これをしっかり運用していくことで、少しずつチームの文化にしていきます。
また、個人的にROLLCAKEのCXO伊野さんの記事がすごくおすすめです。特に下記の一節です。
伊野：最初に「ユーザー体験設計書」を作ります。これはサービスを作る上での憲法みたいなもの。余談ですが各国の憲法ってゴールダイレクテッドなものが多いんです。その国の国民がどんな国に住みたいかを表現しているものだから。そして、その憲法を運用するために法律があります。
法律の運用にあたって憲法を変えることができないのと同じように、各種の施策を進めるにあたってユーザー体験設計書を変えることは基本的にできません。市場や、ぼくたちの考え方が変化すれば変更を加えることもありますが、頻繁には行いません。
体験の憲法を作る感覚というと、結構根拠としていくべき納得感が出てくると思います。
なぜこうするといいか、どうするともっと良くできるのか
一番のメリットは、判断のブレが細部まで減ることです。デザインを含めた、いわゆる体験のDiscoveryのリズムとして、何を抑えると次に進めるのか、というイメージがつくことで、チームにサイクルが回ってくると思います。
僕もこの点についてはまだまだ学習中なのですが、他社サービスのUIや体験全体から、体験の憲法をイメージしてみるというのはいい訓練になると思っています。
悩み⑤：企画と事業数値が結びつかない（言い換えるとロードマップが作れない）
どのような悩みか
体験として、ユーザー課題としては良質に企画できていても、どう事業数値に対して旨みを作れるのかわからない、というシンプルな悩みもあれば、ロードマップを作るのが難しいというものまで多岐にわたって存在している悩みです。
逆にロードマップを作るための必要性としても語れるかもしれません。様々な指標に対する企画が乱立しやすいが、事業数値と紐づけられなくて推進が難しいという側面もあると思います。
僕はどう悩んだか
僕はロードマップを作る時に悩みました。
ロードマップ作成をする前に、事業とユーザー指標を紐づけて整理をした結果、「伸ばすべきユーザー指標の輪郭は見えてきた！」その一方で、「全然企画が浮かばない」というものです。
どうするといいか
これについてはいくつかアプローチが取れると思うのですが、良質な企画は数字からは直接生まれてくれない、という事態をしっかりと受け止めるのが大事だと思います。
これは明確に時間を区切ってそれぞれ分けて戦うべきです。また、事業数値とユーザー指標の接続については、ある程度のパターン化がされていると思うので、それはそれで時間をとって、何の数字が動くといいのか、についてはある程度のイメージを常日頃から持っておくといいのでしょう。
一方で、企画については、事業数字からは生まれないと割り切るべきだと思います。先に企画をある程度検討した上で、後から事業場の主要数字に接続できるのか、について考えていくことも時には重要です。
もちろん、全ての企画がそういうわけではないです。
課題を特定した時に解決策がオペレーション改善によるものでしかない、とわかった際には、ユーザー体験の企画のスコープは自ずと絞られてくれるので、そこまで悩む必要もないかもしれません。
常日頃から、何か企画を思いついた時にフレームまでは一息で書き切ってしまいストックしておくことや、論点までは記述をしておくことが大事だと思います。
ロードマップはそうしたストックからアイテムを見繕ってくる、ぐらいの方が楽しさと数字への向き合いを両立できるように思うからです。
また、ユーザーの数値を動かす肝は、悩み④で記載した、仮説とストーリーの憲法化を高いレベルで続け、体験設計から逃げないこと、だと思います。
良質な企画でしか、いい体験は作れず、事業の数字は動きません。その意味でも、僕個人としても企画を作ることから逃げずに今後も取り組んでいきたいと思っています。
なぜこうするといいか、どうするともっと良くできるのか
大抵ロードマップや予算を作る時には時間がないことが多いので、そもそも別物と捉えておく方がいい、というのが一番大きな理由です。
また、企画の質を高めることこそが、数字の実現にあたっても、開発の質を高める上でも重要なので、企画自体を別の場所でしっかり議論できる状態をチームで作っていく、というのはかなり生命線なのだろうと思っています。
ここについては、まだチームでしっかりとした企画のストックや先回りしたDiscoveryはできていないので、まだまだ僕も挑戦中です。
まだまだ旅は続くけれども…
長々と悩みベースで僕の苦悩と学習の歴史を綴ってみました。今1年目だ！という方も、これから挑戦してみようと考えている方も、一つの物差しとして捉えていただけると嬉しいです。
そして、これが何より大事なわけですが、CAMPFIREは絶賛仲間を募集しておりますし、僕もTwitterをフォローして欲しいです！！！！
また来年もPdMとしてこの時期に振り返ろうと思います。
それでは！
▶︎カジュアル面談のご案内
CAMPFIREは社会に影響を及ぼす大きな変化を起こそうとしています。想像を超える大きな挑戦をしたい方、仕事を通してワクワクしたい方をお待ちしております。まずは採用ページやカジュアル面談を通してCAMPFIREの今を深く知り、ご興味をお持ちいただけると嬉しいです。
▶︎採用ページはこちら
▶︎僕のTwitterはこちら（Twitter派です）
https://x.com/kenta_otsuka_