1人目のPdMが入社して1か月。オンボーディングの計画も立て、資料も渡した。それなのに、エンジニアは相変わらず仕様の相談を経営者に持ってくる。経営者のほうも、気になる点を見つけると、つい開発チームのチャットに直接書き込んでしまう。PdMは、決まったことを後から知らされる立場になっている。
こうした状態は、PdM本人の力量が足りないから起きるとは限りません。多くの場合、原因は開発チームと経営者のあいだに、これまでの通り道が残っていることにあります。経営者がプロダクトを見てきた期間が長いほど、その通り道は太く、使い慣れたものになっています。
1人目のPdMの立ち上がりについては、PdM本人が何をするか、経営者が何を渡すかという観点で語られることが多くあります。一方で、開発チームに受け入れてもらう過程で、迎える側の経営者がどう振る舞いを変えるかは、あまり語られていません。
本記事では、1人目のPdMが開発チームで「頭越し」にされてしまう構図と、それを変えるために経営者が見直す4つの習慣、最初の3か月の動き方、そして開発チームが抱きやすい不安への応え方を解説します。
1人目のPdMが「頭越し」にされるとき、何が起きているか
まず、よく見られる状態を整理します。次のような場面に、心当たりはないでしょうか。
- エンジニアが仕様の不明点を、PdMではなく経営者に質問している
- 経営者が顧客との打ち合わせで聞いた要望を、そのまま開発チームに伝えている
- PdMが決めた優先順位について、エンジニアが経営者に「本当にこれでいいですか」と確認している
- 定例の場で、PdMが説明した後に経営者が補足し、結論が変わることがある
- PdMが、開発の進み具合を開発チームからではなく経営者から聞いている
一つひとつは小さなことです。経営者の側にも、PdMを軽んじているつもりはありません。急ぎの判断が必要だった、自分が答えたほうが早かった、という理由があります。
ただ、これが続くと、開発チームの中で「最終的に決めるのは経営者で、PdMは調整役」という理解が固まっていきます。そうなると、PdMが何かを決めても、その判断は経営者の確認を経るまで仮のものとして扱われます。PdMは決める立場ではなく、経営者の意向を伝える立場になり、本来期待していた役割が果たせなくなります。
なぜ開発チームは経営者に直接相談し続けるのか
開発チームが経営者に相談し続けるのは、チームのメンバーに悪気があるからではありません。理由は主に3つあります。
1. 経営者に聞くのが、これまでいちばん確実だった
PdMが来る前は、プロダクトの判断はすべて経営者が下していました。エンジニアにとって、経営者に聞けば必ず答えが返ってきて、その答えが覆ることもない、という経験が積み重なっています。新しく来たPdMに聞いても、結局は経営者に確認が必要になるのであれば、最初から経営者に聞いたほうが早い、と考えるのは自然なことです。
2. PdMが何を決める人なのか、開発チームに伝わっていない
「今日から1人目のPdMとして○○さんが入ります」という紹介はあっても、何を任せたのかまで伝えられていることは多くありません。開発チームから見ると、PdMが決めてよい範囲と、経営者に確認すべき範囲の境目が分かりません。分からないときは、確実なほうに聞く、という判断になります。
3. PdMの判断が、経営者によって覆された経験がある
入社直後に、PdMが決めた優先順位を経営者が変えた場面を一度でも見ると、開発チームは「PdMの判断は変わることがある」と学びます。経営者としては、まだ慣れていないPdMを補ったつもりでも、チームには「最終的には経営者が決める」という印象が残ります。
3つの理由に共通するのは、どれも経営者の振る舞いによって変えられるという点です。PdM本人がいくら努力しても、経営者への通り道が開いたままであれば、開発チームはそちらを使い続けます。
経営者が見直す4つの習慣
1人目のPdMを開発チームに受け入れてもらうために、経営者が見直したい習慣は4つあります。
習慣1：PdMの役割を、経営者自身の言葉で開発チームに伝える
最初に行いたいのは、PdMに何を任せたのかを、経営者から開発チームへ直接伝えることです。PdM本人が「私はこういう役割です」と説明するよりも、経営者が「この範囲は○○さんに任せた。○○さんが決めたことは、私が決めたことと同じに扱ってほしい」と伝えるほうが、チームの受け止め方は大きく変わります。
伝える内容は、次の3つに絞ると分かりやすくなります。
- PdMが決める範囲：例として、開発の優先順位、仕様の細部、リリースの中身など
- 経営者が引き続き決める範囲：例として、事業の方向性、大きな投資判断、価格など
- 迷ったときの相談先：まずPdMに相談すること
伝える場は、全員がそろう定例やキックオフが適しています。チャットの一斉連絡だけでは、重みが伝わりにくいためです。口頭で伝えたうえで、同じ内容を文章にして残しておくと、後から入ったメンバーにも共有できます。
習慣2：自分の依頼も、PdMを通して開発チームに渡す
経営者がもっとも見直しにくいのが、この習慣です。顧客との打ち合わせで要望を聞いた、競合の新機能を見て気になった、そういうときに開発チームへ直接依頼するのをやめ、PdMに渡すようにします。
経営者が直接依頼すると、PdMが決めた優先順位とは別の仕事が開発チームに入ります。エンジニアは「経営者からの依頼だから優先すべきだろう」と判断し、PdMの計画は崩れます。そして開発チームには、「本当に大事な依頼は経営者から来る」という理解が残ります。
PdMを通すことで遅くなる、と感じるかもしれません。ただ、本当に急ぎの依頼であれば、PdMがその場で優先順位を組み替えれば済みます。PdMを通すことで失われるのは数時間程度であることがほとんどで、その代わりに、開発チームの予定が経営者の思いつきで崩れることを防げます。
依頼を渡すときは、「何をしてほしいか」だけでなく、「なぜ気になったのか」「どのくらい急ぐと思うか」を添えると、PdMが判断しやすくなります。
習慣3：エンジニアから相談されたら、PdMに戻す
PdMの役割を伝えても、しばらくはエンジニアから経営者への相談が続きます。これまでの習慣は、一度の説明では変わりません。
そのときに経営者が答えてしまうと、「やはり経営者に聞けば答えが出る」という経験が上書きされます。相談を受けたら、内容がPdMに任せた範囲であれば、「それは○○さんと決めてください」と戻します。必要であれば、その場でPdMを呼んで三者で話してもかまいません。大切なのは、結論をPdMが出す形にすることです。
戻すときには、突き放す言い方にならないよう注意が必要です。「私は分からないから」ではなく、「この件は○○さんに任せているので、○○さんの判断を優先したい」と理由を添えると、エンジニアも納得しやすくなります。
この習慣は、1〜2か月続けると効果が見えてきます。経営者に聞いても戻されると分かれば、エンジニアは最初からPdMに相談するようになります。
習慣4：PdMの判断に異論があっても、人前では覆さない
PdMの判断に違和感を覚えることは、当然あります。経営者の頭の中には、PdMがまだ知らない事情や過去の経緯があるためです。
ただ、その違和感を開発チームの前で表明し、その場で結論を変えると、チームはPdMの判断が仮のものだと受け止めます。異論があるときは、定例や開発チームのチャットではなく、PdMとの1対1の場で伝えます。そのうえで、判断を変えるかどうかはPdMに決めてもらい、変える場合はPdMの口から開発チームに伝えてもらいます。
例外は、事業の方向性に関わる判断や、顧客との約束に関わる判断など、経営者が引き続き決める範囲に入っていた場合です。その場合も、「この件は私が決める範囲だったので、私から伝えます」と、範囲の問題として扱うと、PdMの判断そのものを否定する印象を避けられます。
PdMの判断に繰り返し違和感があるようであれば、それは判断を伝える場面ではなく、判断の前提となる情報が渡っていない可能性があります。過去の判断の経緯や、顧客との関係などを、改めてPdMと共有する機会を設けてください。
最初の3か月の動き方
4つの習慣は、入社した日から同じ強さで続けるものではありません。PdMが状況を把握するまでの時期と、判断を任せはじめる時期とでは、経営者の関わり方が変わります。目安として、3か月を次のように分けて考えます。
1か月目：経営者が前に立ち、PdMを紹介してまわる
入社直後は、PdMはまだプロダクトの経緯も、メンバー一人ひとりの得意分野も知りません。この時期に「すべてPdMに相談してください」としても、PdMが答えられない場面が多くなります。
1か月目は、経営者が引き続き判断を下しながら、PdMを隣に置いておく時期です。開発チームとの打ち合わせにはPdMを同席させ、経営者がなぜその判断をしたのかを、PdMにも聞こえる形で説明します。メンバーとPdMの1対1の時間も、経営者から声をかけて設けます。
この時期の終わりに、習慣1の「役割を伝える場」を設けると、PdMがある程度状況をつかんだうえで、任される範囲を開発チームに示せます。
2か月目：判断の主語をPdMに移し、相談を戻しはじめる
2か月目からは、任せた範囲の判断をPdMが下す形に切り替えます。開発チームとの打ち合わせでは、経営者は発言を控えめにし、PdMが進行と結論を担います。経営者は、習慣2と習慣3を意識的に続けます。
この時期は、エンジニアからの相談がまだ経営者に来ることが多く、戻す回数がもっとも多くなります。戻すたびに手間に感じますが、この時期にどれだけ戻せたかで、3か月目以降の開発チームの動き方が決まります。
3か月目：経営者は一歩引き、PdMとの1対1を中心にする
3か月目には、開発チームとの日々のやりとりはPdMが担い、経営者は週に一度のPdMとの1対1を中心に関わる形を目指します。開発チームの定例にも、毎回出る必要はなくなります。
経営者が定例を離れることに不安を感じる場合は、月に一度だけ参加する、議事録を読んで気になった点はPdMに伝える、といった関わり方にすると、離れすぎずに済みます。
3か月目の終わりに、エンジニアからの直接の相談が月に何件あったかを振り返ってみてください。ほとんどなくなっていれば、開発チームの通り道はPdMに移っています。
開発チームが抱きやすい不安と、その応え方
経営者の振る舞いを変えるだけでなく、開発チームの側にある不安に応えておくことも大切です。1人目のPdMを迎えるとき、開発チームのメンバーは次のような不安を抱きやすくなります。
「確認する相手が増えて、遅くなるのではないか」
これまで経営者に聞けば済んでいたことに、PdMという段階が一つ増えるように見えるため、出てきやすい不安です。実際には、PdMが判断を担うことで、経営者が忙しくて返事が来ない、という待ち時間は減ることが多くあります。
この不安には、「PdMに聞けば決まる。私には確認しなくてよい」という形で、確認する相手は増えずに入れ替わるだけだと伝えるのが効果的です。
「技術的な判断にまで口を出されるのではないか」
エンジニアの中には、PdMが実装方法や技術選定にまで関わってくるのではないか、と心配する人もいます。PdMの役割は、何を作るか・なぜ作るかを決めることで、どう作るかは開発チームが決める、という分担を、役割を伝える場で明確にしておきます。
技術責任者がいる場合は、PdMと技術責任者のあいだでどう分担するかも、あわせて伝えておくと混乱が起きにくくなります。
「経営者と話す機会がなくなるのではないか」
少人数のチームでは、経営者と直接話せることを大切に感じているメンバーもいます。PdMが間に入ることで、経営者が遠くなると感じる人もいるでしょう。
プロダクトの判断はPdMに任せても、事業の方向性や会社の状況を経営者から直接話す場は残しておきます。月に一度の全体の場などで、経営者が何を考えているかを話す機会を設ければ、距離が離れたという感覚は和らぎます。
経営者が手放さなくてよいもの
ここまで、経営者が手放すものを中心に述べてきましたが、すべてをPdMに渡す必要はありません。次のようなものは、1人目のPdMを迎えた後も、経営者が持ち続けて差し支えありません。
- 事業とプロダクトの方向性：どの顧客に向けて、何を実現するのか
- 大きな投資判断：人員の追加や、大規模な作り直しなど
- 重要な顧客との関係：経営者自身が築いてきた関係
- プロダクトへの関心：使ってみて気づいたことを、PdMに伝えること
最後の「プロダクトへの関心」は、手放す必要がないばかりか、持ち続けてほしいものです。経営者がプロダクトに関心を持ち続けていることは、PdMにとっても心強いことです。変えるのは関心の持ち方ではなく、気づいたことを伝える先を、開発チームからPdMに変えることだけです。
よくある失敗
役割を伝えたことで、受け入れが済んだと考える
役割を伝える場を設けても、それだけで開発チームの動き方は変わりません。変わるのは、伝えた後の経営者の振る舞いが一貫していたときです。説明の翌日に経営者が開発チームに直接依頼すれば、説明の効果はなくなります。
PdMを守ろうとして、経営者が代わりに説明してしまう
PdMの判断に開発チームから反論が出たとき、経営者が「○○さんの判断は正しい」と援護したくなることがあります。気持ちは自然ですが、経営者が説明を引き取ると、結局は経営者の判断として受け止められます。経営者は「○○さんに任せているので、○○さんと話してほしい」と伝えるにとどめ、議論はPdMと開発チームのあいだで進めてもらうほうが、長い目で見ると受け入れが進みます。
急ぎの件だけは例外にしてしまう
「急ぎのときだけは直接伝える」という例外を設けると、経営者にとっての急ぎが増え、例外が日常になります。急ぎであっても、PdMに連絡し、PdMから開発チームに伝えてもらう流れを守ります。PdMにすぐ連絡がつく体制を整えておけば、遅れはほとんど生じません。
具体例：エンジニアの相談先が3か月で切り替わったケース
従業員15名ほどのBtoB SaaSのスタートアップで、1人目のPdMを迎えたケースです。開発チームはエンジニア5名で、それまでは代表がプロダクトの判断をすべて担っていました。
PdMが入社して1か月が経っても、エンジニアからの仕様の相談は代表のもとに集まっていました。代表は顧客との打ち合わせの後、開発チームのチャットに要望を書き込むことも続けており、PdMが作った優先順位の一覧は、週の半ばには形が崩れていました。
そこで、まず代表から開発チームに向けて、PdMに任せた範囲を説明する時間を設けました。開発の優先順位と仕様の細部はPdMが決めること、代表は事業の方向性と大口顧客との関係を担うこと、迷ったらまずPdMに相談すること、の3点です。
あわせて、代表は顧客から聞いた要望を開発チームのチャットに書き込むのをやめ、PdMとの共有メモに書くようにしました。エンジニアから直接相談が来たときは、「その件はPdMと決めてほしい」と返し、必要に応じてその場でPdMを呼びました。
最初の1か月は、代表のもとへの相談は週に10件ほどありましたが、3か月目には月に数件まで減りました。PdMが立てた優先順位の一覧も、週の途中で大きく崩れることが少なくなりました。代表は、開発チームの定例への参加を月に一度に減らし、その分の時間を顧客や採用に使えるようになりました。
よくある質問（FAQ）
Q1. PdMがまだ慣れていないうちに任せると、判断を誤るのではないかと心配です。
誤ることはあります。そのため、最初から任せる範囲を広げすぎず、取り返しのつく判断から任せることをおすすめします。判断を誤った場合も、人前で覆すのではなく、1対1の場で背景を伝え、PdM自身が修正する形にすると、開発チームからの信頼を損なわずに済みます。
Q2. 開発チームのリーダーが、PdMの役割に納得していないようです。
役割を伝える場の前に、リーダーとだけ個別に話す時間を設けることをおすすめします。PdMが入ることで、リーダーの仕事がどう変わるのか、何が楽になるのかを具体的に話し、懸念があれば先に聞いておきます。全体の場で初めて聞かされるよりも、受け止めやすくなります。
Q3. 経営者である自分がプロダクトの細部に口を出したくなるのを、どう抑えればよいでしょうか。
抑える必要はありません。気づいたことは、PdMとの共有メモや1対1の場に集めるようにしてください。伝える先を変えるだけで、関心を持ち続けることはできます。週に一度、たまったメモをPdMと一緒に見る時間を設けると、気づきが埋もれることもありません。
Q4. 業務委託のPdMの場合も、同じ進め方でよいでしょうか。
基本的な考え方は同じです。ただし、業務委託のPdMは稼働日が限られるため、稼働していない日にエンジニアから相談が来たときの扱いを、あらかじめ決めておく必要があります。次の稼働日まで待てるものはPdMに回す、待てないものだけ経営者が答えて後でPdMに共有する、といったルールを伝えておくと混乱が起きにくくなります。
Q5. 3か月経っても、エンジニアが経営者に相談してきます。
まず、経営者自身が直接依頼していないか、相談に答えてしまっていないかを振り返ってください。振る舞いが一貫していたにもかかわらず相談が続く場合は、PdMに相談しても答えが出ない、返事が遅いなど、PdM側の動き方に原因がある可能性があります。その場合は、エンジニアがなぜ経営者に聞くのかを、PdMと一緒に確かめることをおすすめします。
まとめ
1人目のPdMが開発チームで頭越しにされてしまうのは、PdM本人の問題というより、開発チームと経営者のあいだに、これまでの通り道が残っているためです。その通り道を閉じられるのは、経営者だけです。
見直したい習慣は4つあります。(1)PdMの役割を経営者自身の言葉で開発チームに伝える、(2)自分の依頼もPdMを通して渡す、(3)エンジニアから相談されたらPdMに戻す、(4)PdMの判断に異論があっても人前では覆さない、です。最初の3か月は、経営者が前に立ってPdMを紹介する時期から、判断の主語をPdMに移す時期、経営者が一歩引く時期へと、段階的に関わり方を変えていきます。
まずは、この1週間で開発チームに直接伝えた依頼や、エンジニアから直接受けた相談が何件あったかを数えてみてください。その件数が、PdMに移すべき通り道の太さを示しています。
プロダクトマネジメントについてお気軽にご相談ください
プロダクトマネジメントの顧問支援や、1人目のPdM採用・育成のサポートを承っています。
「経営者が兼務してきたが、そろそろ限界かもしれない」という段階からでもお気軽にご連絡ください。
おおむね2営業日以内にご返信します。
