1人目のPdMを採用した。あるいは、業務委託でPdMに入ってもらった。ところが数週間経っても、プロダクトに関わる判断がほとんど自分のところに集まってくる——このような状態に心当たりのある経営者は少なくありません。
役割としては「プロダクトを任せる」と決めたはずなのに、実際には仕様の細部から機能の優先順位まで、最終的な決めの部分は自分が握ったままになっている。PdM本人も「勝手に決めてよいのか分からない」と判断を止め、確認のためのやりとりが増えていく。任せたはずが、かえって自分の確認作業が増えているように感じる。
この行き詰まりの原因は、たいていの場合「意思決定の権限をどう渡すか」を設計しないまま採用に踏み切ったことにあります。業務そのものは引き継げても、「どの判断を、いつ、どこまで委ねるか」を決めていなければ、判断は自然と経営者に戻ってきます。本記事では、1人目のPdMへ意思決定の権限を委譲していくための4ステップと、委譲の度合いをどう設計するかを解説します。
なぜ権限委譲は後回しになりやすいのか
意思決定の委譲が進まない背景には、経営者の姿勢の問題ではなく、構造的な理由が3つあります。
1つ目は、自分がどんな意思決定を日々下しているかを把握していないことです。 経営者がプロダクトを兼務している間、判断は頭の中で瞬時に完結し、意識に上りません。「この要望は今期は対応しない」「この画面はもっと簡単にすべきだ」といった判断を、1日に何十回も無意識に下しています。渡すべき対象そのものが見えていないため、何を委譲するかを決めようがありません。
2つ目は、意思決定を「渡す・渡さない」の二択で考えてしまうことです。 実際には、判断のすべてを丸ごと委ねる必要はありません。「案はPdMが作り、最終的な決めだけ経営者が承認する」「一定の金額・影響範囲まではPdMが決めてよい」といった中間的な渡し方があります。二択で考えると、「まだ全部は任せられない」という結論になり、結局すべてを握り続けることになります。
3つ目は、一度渡した判断を取り戻すことへの心理的な抵抗です。 「渡したあとで方向性が違ったらどうするか」という不安から、渡す前に完璧な線引きをしようとして動けなくなります。しかし委譲の範囲は、実際に任せてみて調整していくものです。最初から完璧な線引きはできないという前提に立たなければ、いつまでも第一歩を踏み出せません。
委譲を始める前に：意思決定を「種類」で捉える
4つのステップに入る前に、前提を1つ揃えておきます。プロダクトに関わる意思決定は、大きく次の3種類に分けられます。この区別が、後の仕分けの土台になります。
- 方向性の意思決定：どの顧客セグメントを狙うか、どの事業領域に張るか、プロダクトの中核となる価値をどこに置くか。誤ると事業全体の軌道に影響し、取り返しがつきにくい。
- 設計の意思決定：ロードマップ上の機能の優先順位、大きな仕様の方針、どの指標を目標に置くか。方向性の範囲内で、プロダクトの形を決めていく判断。
- 実務の意思決定：個別機能の仕様の細部、UIの詳細、バックログの並べ替え、日々の開発チームへの判断の返し。頻度が高く、1つあたりの影響は限定的。
多くの経営者は、採用時に「プロダクトを任せる」と言いながら、実際には実務の意思決定すら手放せていません。逆に、最初から方向性の意思決定まで丸ごと委ねてしまい、事業の軌道がずれてから慌てて取り戻すケースもあります。委譲とは、この3種類を一律に扱わず、種類ごとに渡し方とタイミングを変えていく作業です。
意思決定の権限を委譲する4ステップ
STEP1：自分が下している意思決定を洗い出す
最初にやるべきは、経営者自身が現在下しているプロダクト関連の意思決定を、1〜2週間かけて書き出す作業です。判断が発生するたびにメモを残し、「何を決めたか」「その判断の根拠は何だったか」「どのくらいの頻度で発生するか」を記録します。
この棚卸しをせずに委譲を進めると、頭に浮かびやすい判断（機能の優先順位など、目に見える意思決定）だけが対象になり、「営業からの仕様相談にその場で答える」「顧客の要望を聞いて対応可否を即断する」といった、日常に溶け込んだ判断が抜け落ちます。これらは委譲されないまま経営者に残り続け、「任せたはずなのに忙しさが変わらない」という感覚の正体になります。
業務そのものの棚卸しの手順は、以下の記事で詳しく解説しています。意思決定の洗い出しも同じ要領で進められます。
STEP2：各意思決定を「委譲レベル」で仕分ける
洗い出した意思決定を、次章で示す5段階の委譲レベルに当てはめていきます。ここでのポイントは、「今すぐ完全に任せられるか」ではなく、「どの段階なら渡せるか」を考えることです。
たとえば「機能の優先順位づけ」は、いきなりレベル5（PdMが決めて事後報告も不要）にはできなくても、レベル3（PdMが案を作り、経営者が承認する）なら今日から始められます。すべての意思決定について、現状のレベルと、3か月後に到達したいレベルの2つを書き添えておきます。
STEP3：渡す順序を決める
すべての意思決定を同時に委譲することはできません。順序をつけます。基準は2つです。
1つは「頻度が高く、1件あたりの影響が小さいもの」から渡すこと。 バックログの並べ替えや個別UIの判断のように、毎日発生し、間違えても軌道修正が効くものは、早い段階で委ねます。頻度が高い判断を経営者が握り続けると、そこがボトルネックになり、開発の速度そのものが落ちます。
もう1つは「PdMが必要な情報にアクセスできるもの」から渡すこと。 判断に必要な情報（顧客の声、利用データ、競合状況など）が、経営者の頭の中にしかない意思決定は、いきなり渡しても質が落ちます。まず情報が共有されている領域から委譲し、非公開情報や創業の経緯に依存する判断は後回しにします。
方向性の意思決定は、この順序でいえば最後です。当面は経営者が握り、PdMが事業を十分に理解し、判断の質がすり合ってきた段階で、徐々に関与を増やしていきます。
STEP4：委譲した判断を振り返る場を設計する
権限を渡したら、渡しっぱなしにせず、判断を振り返る定例の場を用意します。週1回30分でも構いません。この場で見るのは「その判断が正しかったか」ではなく、「経営者ならどう考えたか」「PdMはなぜそう判断したか」の擦り合わせです。
この場があることで、経営者は「任せても方向性は把握できている」という安心を得られ、PdMは「この範囲は自分が決めてよい」という確信を持てます。逆にこの場がないと、経営者は不安から個別の判断に口を出し始め、PdMは萎縮して判断を止めるようになります。委譲がうまくいくかどうかは、渡し方そのものよりも、渡したあとの振り返りの設計にかかっています。
なお、採用したPdMがなかなか判断できるようにならない場合、原因は本人の力量だけでなく、この振り返りの場や情報共有の設計にあることも少なくありません。
委譲レベルの5段階
STEP2で使う「委譲レベル」を具体的に示します。意思決定を「渡す・渡さない」の二択ではなく、次の5段階で捉えると、少しずつ手放していく道筋が見えます。
レベル1：経営者が決め、PdMは実行する 判断は経営者が下し、PdMはその判断を形にする。採用直後や、方向性に関わる意思決定はここから始まります。
レベル2：PdMが選択肢を出し、経営者が選ぶ PdMが複数の案とそれぞれのメリット・デメリットを整理し、経営者が選ぶ。PdMに情報収集と論点整理を委ね、決めの部分は経営者が持つ段階です。
レベル3：PdMが推奨案を出し、経営者が承認する PdMが「これでいく」という案を1つ示し、経営者が承認または差し戻す。判断の主体はPdMに移りつつあり、経営者は拒否権を持つ立場になります。設計の意思決定の多くは、まずここを目指します。
レベル4：PdMが決めて実行し、経営者に事後共有する PdMが判断して進め、結果を経営者に報告する。経営者は事後に把握するが、原則として覆さない。実務の意思決定はこのレベルに置きます。
レベル5：PdMが決めて実行し、共有も任せる PdMが判断・実行し、共有の要否も本人が決める。細かいUIの調整やバックログの日々の並べ替えなど、経営者が把握する必要のない判断はここまで委ねます。
同じ「機能の優先順位づけ」でも、四半期のロードマップ方針はレベル2〜3、その中の個別機能の並び順はレベル4、というように、粒度によってレベルを変えて構いません。重要なのは、どの意思決定が今どのレベルにあるかを、経営者とPdMの双方が同じ認識で持っていることです。
渡してよい意思決定・握り続けるべき意思決定
5段階のレベルを踏まえると、1人目のPdMへ早めに委譲してよい意思決定と、当面は経営者が握るべき意思決定は、次のように整理できます。
早めに委譲してよい意思決定の例
- バックログの並べ替えと、決まった方針に沿った優先順位の調整
- 個別機能の仕様の細部、UI・UXの詳細
- ユーザーインタビューの設計と、対象者・質問項目の決定
- 開発チームからの仕様に関する問い合わせへの日常的な判断
- 分析で見る指標の選定と、レポートの構成
当面は経営者が握るべき意思決定の例
- どの顧客セグメント・事業領域を主戦場にするか
- プロダクトの中核となる価値の定義
- 大きな方針転換（ピボット）の判断
- 資金調達の状況や投資家との合意事項に依存する判断
- 採用・組織体制に関わる意思決定
境界線上にある意思決定も多くあります。たとえば「四半期のロードマップ」は、方向性は経営者が示し、その範囲での機能選定と順序づけはPdMが案を作る、という分担になります。こうした中間的な意思決定こそ、レベルを明示し、「どこまでがPdMの裁量で、どこからが経営者の承認事項か」を言葉にしておく価値があります。
任せる範囲そのものの切り分けについては、業務委託の文脈になりますが、次の記事の視点も参考になります。
権限委譲でよくある失敗パターン
委譲レベルを設計しても、運用の中でつまずくパターンがあります。事前に知っておくと避けやすくなります。
失敗1：レベルを共有しないまま「任せた」と言ってしまう 経営者の頭の中ではレベル4で渡したつもりでも、PdMはレベル1（経営者が決める）だと受け取っている。この認識のずれがあると、PdMは判断のたびに確認を取りにきて、経営者は「なぜ自分で決めないのか」と感じます。渡すレベルは口頭でも文書でも、必ず言葉にして揃えます。
失敗2：一度渡した判断を、感情的に取り戻してしまう PdMの判断が自分の想定と違ったとき、その場で覆してしまうケースです。1回でも覆すと、PdMは「結局は経営者が決めるのだ」と学習し、以後すべての判断を止めるようになります。想定と違う判断が出たら、その場では覆さず、STEP4の振り返りの場で「なぜそう考えたか」を擦り合わせます。
失敗3：低頻度・高影響の意思決定から渡してしまう 「大きな判断を任せたほうが信頼を示せる」と考え、方向性の意思決定を早い段階で委ねてしまう。PdMがまだ事業を十分理解していない段階でこれをやると、軌道がずれてから取り戻すことになり、双方の信頼を損ないます。渡す順序は、頻度が高く影響の小さいものからです。
失敗4：振り返りの場を設けず、Slackの流れで判断を追う 専用の振り返りの時間を取らず、日々のチャットのやりとりだけで委譲した判断を把握しようとすると、経営者は断片的な情報から不安になり、個別の判断に介入し始めます。短くてよいので、判断を俯瞰する定例の場を確保します。
委譲は一度で終わらない：見直しのリズム
意思決定の権限委譲は、一度線引きをすれば完了するものではありません。PdMが事業とプロダクトへの理解を深めるにつれて、渡せる範囲は広がっていきます。
目安として、採用から1か月・3か月・6か月の節目で、各意思決定の委譲レベルを見直す機会を設けます。1か月時点では実務の意思決定がレベル4に乗っているか、3か月時点では設計の意思決定がレベル3に進んでいるか、6か月時点では方向性の意思決定にPdMがどこまで関与できているか——このように、時間軸に沿って到達目標を持っておくと、委譲が停滞しているかどうかを判断できます。
見直しの場では、「渡しすぎて経営者が把握できていない判断はないか」「逆に、まだ握ったままでボトルネックになっている判断はないか」の両方を確認します。委譲は広げる一方ではなく、渡しすぎた部分を一段階戻すこともある、双方向の調整だと捉えてください。
採用直後の立ち上げ全体をどう設計するかは、以下の記事で3つのフェーズに分けて解説しています。権限委譲は、その中の中核となるテーマです。
まとめ
1人目のPdMへ意思決定の権限を委譲するには、「渡す・渡さない」の二択ではなく、5段階の委譲レベルで捉えることが出発点になります。進め方は、(1)自分が下している意思決定を1〜2週間かけて洗い出し、(2)それぞれを委譲レベルに仕分け、(3)頻度が高く影響の小さいものから順に渡し、(4)委譲した判断を振り返る定例の場を設計する、という4ステップです。
方向性の意思決定は当面経営者が握り、実務の意思決定から先に手放していきます。渡したレベルは必ず言葉にして双方で揃え、一度渡した判断はその場で覆さず、振り返りの場で擦り合わせます。そして委譲は一度で終わらせず、1か月・3か月・6か月の節目でレベルを見直し、渡しすぎ・握りすぎの両方を調整していきます。この設計があって初めて、「プロダクトを任せた」という言葉が実態を伴います。
プロダクトマネジメントについてお気軽にご相談ください
プロダクトマネジメントの顧問支援や、1人目のPdM採用・育成のサポートを承っています。 「経営者が兼務してきたが、そろそろ限界かもしれない」という段階からでもお気軽にご連絡ください。 おおむね2営業日以内にご返信します。
