この記事の要約
- 経験の浅いPdMは「どこがレバーか」を見抜けず影響力の小さい施策に時間を浪費してしまう。先輩PdMの役割は問題の構造を可視化し、最大の効果を生むレバレッジポイントを特定して示すこと
- 構造的レビューとは、PRDを1行ずつ添削するのではなく「方程式分解」「ファネル分解」「フィードバックループ分解」などの5つのパターンで問題を分解し、影響度・制御可能性・ギャップ・波及効果の4軸でレバーを判定するプロセス
- 段階的に支援レベルを下げていくことで、後輩が自分で構造を見抜き、レバーを特定できるようになる。最終目標は完全提示から確認のみへの移行
なぜジュニアPdMは「どこがレバーか」を見抜けないのか
プロダクト組織によっては先輩PdM（ミドル~シニア）が後輩PdM（ジュニア）のレビュー役を担う場合も多いのではないでしょうか？その際にもちろん自分よりも経験値が少ないPdMなので意図しないものやクオリティ不足のアウトプットが出てくることもあるでしょう。
例えば、ジュニアPdMに成長が鈍化している理由を分析してきてもらったら、
- 「競合が広告を増やしているから、うちも広告予算を増やすべき」と提案
- リテンション改善の施策として「ユーザーから要望の多い機能Aを優先して開発しましょう」と提案
これ自体が絶対間違いではないのだが、本当にそこがレバーなのか？という疑問が残りますよね。
システム思考の世界では、レバレッジポイント（Leverage Point）という概念があります。
これは「小さな変化が大きな影響を生む場所」を指す言葉で、環境学者のドネラ・メドウズが1997年に発表した論文「Leverage Points: Places to Intervene in a System」で体系化された概念。彼女はレバレッジポイントを12段階にランク付けし、「パラメータ（数値）の変更」は最も低次のレバーであり、「フィードバックループの強度」「システムの目的」といった深い層への介入の方が遥かに大きな影響を持つと指摘しています。
さて、話は戻ってジュニアPdMが「どこがレバーか」を見抜けない理由は、主に3つあります。
1. 問題を構成要素に分解できていない
「成長 = 新規獲得 × アクティベーション × リテンション × バイラル係数」、といった構造が見えていない。そのため、「広告を増やす」という表層的な打ち手しか思いつかない、といった要因が1つ目です。
実際には、バイラル係数が競合の1/3しかなくそこを改善する方が遥かに効果が高いかもしれないのに。
2. 症状と根本原因を区別できていない
「ユーザーからの要望が多い」というのは症状であって、その要望が出てくる背景（初回体験でのコンバージョンが15%しかなく、価値を実感する前に離脱している、など）が見えていないケース。
症状に対処しても、根本原因が解決されなければ、また別の症状が出てくる。
3. 明白なものをレバーだと勘違いしている
また、メドウズは「明白なレバレッジポイントは決して真のレバレッジポイントではない」と警告しています。これは一体どういうことでしょうか。
例えば、問い合わせが多い = サポート体制を強化すべきと考えがちなパターン。しかし問い合わせ内容を分析すると、「初回ログイン時の手順が分かりにくい」という同じ質問が80%を占めていて、かつ定量データを見ても初回ログインで躓いたユーザーの50%が3ヶ月以内に解約しているということがわかりました。
この場合、真のレバーは「サポート人員の増員」ではなく「オンボーディングフローの改善」です。オンボーディングを改善すれば、問い合わせ自体が減ります。サポート体制の強化は、問い合わせという症状への対処であって、根本原因への介入ではありません。
このように、最も目立つ問題、最もストレスが大きい場所は、往々にして症状であり、真のレバーではありません。真のレバーは、因果関係の上流（根本原因）や、時間軸で過去にあります。
だからこそ、先輩PdMの役割は、問題の構造を可視化し、症状ではなく根本原因を特定して示すことになります。
構造的レビューの — 「構造の可視化」と「レバーの特定」
構造的レビューとは、PRDの文章を1行ずつ添削することでも細かいロジックの穴を指摘することでもなく、2つの重要な行為を重視するレビューです。
行為1: 構造の可視化
問題を構成要素に分解し、要素間の因果関係や相互作用を明示する。これを図や方程式、ツリーといった視覚的な形で表現しましょう。
例えば、「リテンションが低い」という問題に対して、「リテンション = 初回成功体験率 × 習慣形成率 × 継続価値」という方程式に分解。あるいは、「認知 → 獲得 → アクティベーション → リテンション → 収益」というファネルで可視化する、みたいなイメージです。
行為2: レバーの特定
構造を可視化したら、その中でどこに介入すれば最大の効果が得られるかを判定していきます。「ここに集中すべき」を明示しその根拠を説明するのです。
例えば、方程式に分解した結果、初回成功体験率が15%で業界平均の50%を大きく下回っていることが分かったとしましょう。一方、習慣形成率は60%で悪くない。この場合、「習慣形成の改善よりも、初回成功体験の改善がレバーだ。オンボーディングの再設計に集中しよう」と示す。
重要なのは、完璧な構造図と完璧な結論を渡すのではなく、後輩が自分で考えられるように60-80%の完成度で渡すこと。「おそらくXがレバーだと思うが、君はどう見る？」という問いかけと共に渡すイメージです。
これにより、後輩は「なるほど、問題をこう分解すればレバーが見えるのか」という構造的思考の型を学ぶことができます。
問題の構造化手法 — 5つの分解パターン
さて、問題をどう分解するかには大きく5つの典型的なパターンがあります。この典型パターンは後輩PdMに対して構造的レビューをする際のあなたの頭の中の補助線になるはずです。
パターン1: 方程式分解
目標指標を構成要素の掛け算や足し算などの四則演算に分解する最もシンプルな構造化のパターンです。
ARR = ユーザー数 × 課金率 × ARPU（ユーザー単価）
この分解をすると、「ARRを伸ばすには、ユーザー数を増やすのか、課金率を上げるのか、ARPUを上げるのか」という選択肢が明確になりますよね。ここからさらに、以下のように各要素をさらに構造化してデータなどを当てはめていきます。
- ユーザー数 = 要素A x 要素B x 要素C….
- 課金率= 要素A x 要素B x 要素C….
- ARPU= 要素A x 要素B x 要素C….
現状のデータを見て、どの要素が最も改善余地が大きいかを判定することができるのがポイント。
パターン2: ファネル/ジャーニー分解
ユーザーの流れをステップに分解し、どこがボトルネックかを特定するパターン。
認知 → サイト訪問 → サインアップ → アクティベーション → 有料転換 → リテンション
各ステップのコンバージョン率を見ると、例えば「サインアップ → アクティベーション」の転換率が20%しかない、ということが分かるかもしれない。この場合、新規獲得よりもアクティベーション改善がレバーになります
パターン3: フィードバックループ分解
システムを動かしている正のループ（成長エンジン）と負のループ（制約）を特定するパターン。
・正のループ: ユーザー増加 → コンテンツ増加 → 魅力向上 → さらにユーザー増加
・負のループ: ユーザー増加 → スパム増加 → 体験悪化 → ユーザー離脱
正のループを強化するか、負のループを弱めるかが、成長のレバーになります。Twitterは初期、「リツイート機能」によって正のループを劇的に強化し、ある時は「スパム対策」という負のループの弱体化に苦労したみたいなイメージです。
メドウズの理論では、フィードバックループの強度を変えることは、パラメータを変えるよりも遥かに高次のレバーだとされています。
パターン4: レイヤー分解（Iceberg Model）
問題を4つの層に分解するパターン。
- 表層: 見える事象・症状（例: ミーティングが多すぎる）
- 中層: パターン・トレンド（例: 承認フローが長い）
- 深層: 構造・システム（例: 権限が分散している）
- 最深層: メンタルモデル・前提（例: リスク回避文化）
表層の症状（ミーティングを減らす）に対処しても、深層の構造や最深層のメンタルモデルが変わらなければ、また別の症状が出てきますよね。より深い層への介入の方が、持続的な影響が大きいのです。
パターン5: 制約理論（TOC）分解
システム全体のスループットを決める制約（ボトルネック）を特定するパターン。
制約理論では、「システムのパフォーマンスは、最も弱いリンク（制約）によって決まる」とされる。したがって、制約以外の部分をいくら改善しても全体のパフォーマンスは上がらず、制約こそが真のレバーだと言えます。
企画 → 設計 → 開発 → QA → リリース
各工程の処理能力を見たとき、「QA」の処理能力が10件/週で、他の工程が20件/週だとしましょう。この場合、企画や開発をいくら高速化してもQAがボトルネックになってリリース速度は上がらない。QAの処理能力を上げることがレバーになります。
レバレッジポイント特定の4つの判断軸
ここまでで、構造を可視化してレバーの仮説を立てるというイメージがついたと思います。構造を可視化した後、「この要素が本当にレバーか？」をどう判断すれば良いのでしょうか？ここでは4つの判断軸を提示します。
判断軸1: 影響度（Impact）
この要素を動かすと目標指標がどれだけ変わるか？の判断軸です。感度分析やエラスティシティ（弾力性）の推定方法があります。
例: 課金率を1%上げると、ARRが10%伸びるが、ARPUを10%上げてもARRは3%しか伸びない、というケース。この場合、課金率の方が影響度が高い。
判断軸2: 制御可能性（Control）
実際に変更できる要素か、など外部依存度やリードタイムを考慮する判断軸です。
例: 極端に言うと「競合の価格を下げさせる」は影響度が高くても制御不可能。「自社の価格を調整する」は制御可能。
判断軸3: 現状のギャップ（Gap）
現状値とベンチマーク/理想値の差で判断する形で、改善余地の大きさを見ます。
例: 初回成功体験率が15%で、業界平均が50%なら、35ポイントのギャップがある。一方、リテンション率が80%で、業界平均が85%なら、5ポイントのギャップしかない。前者の方が改善余地が大きい。
判断軸4: 波及効果（Ripple Effect）
1つの変更が他の要素にどう波及するか、二次効果・三次効果を予測する判断軸です。
例: オンボーディングを改善すると、初回成功体験率が上がるだけでなく、リテンションも上がり、さらにはバイラル係数（満足したユーザーが他人に勧める）も上がる可能性がある。このように波及効果が大きい施策は、レバーとしての価値が高い。
これら4軸をマトリクスにして、各要素をスコアリングと例えば以下のような表になります。
| 要素 | 影響度（1-5） | 制御可能性（1-5） | ギャップ（1-5） | 波及効果（1-5） | 合計 |
|---|---|---|---|---|---|
| 初回成功体験率 | 5 | 4 | 5 | 4 | 18 |
| 習慣形成率 | 3 | 3 | 2 | 2 | 10 |
| 継続価値 | 4 | 2 | 3 | 3 | 12 |
この表を見ると、「初回成功体験率」が最もスコアが高く、レバーであることが分かります。こうした判断のフレームを持って後輩に「ここに集中しよう」と示してみましょう。
実践シナリオ別 — 構造とレバーの提示例
典型的な5つのシナリオで、先輩PdMがどう構造を可視化し、レバーを示すかの具体例を紹介します。
シナリオ1: 成長鈍化への対応
後輩の提案: 「競合が広告を増やしているので、うちも広告予算を増やすべきです」
先輩の構造化:
成長 = 新規獲得 × アクティベーション × バイラル係数
データを見ると、新規獲得は月1,000人で悪くない。アクティベーション率は70%でこれも問題ない。しかし、バイラル係数（1人のユーザーが何人を連れてくるか）が0.3で、競合の1.0を大きく下回っている。
レバーの特定: 新規獲得（広告）にリソースを投入するより、バイラル係数の改善（既存ユーザーの招待機能強化、紹介インセンティブの設計）の方が、長期的な成長エンジンとして遥かに強力だ。
渡す成果物: 構造図（方程式）+ 数値比較表 + 「バイラル係数を上げる施策を3つ考えて、再提案してほしい」
シナリオ2: 機能開発の優先順位
後輩の提案: 「ユーザーからの要望が多い機能Aを優先すべきです」
先輩の構造化:
リテンション = 初回成功体験率 × 習慣形成率 × 機能充実度
ファネル分析をすると、サインアップ後の初回成功体験率が15%で、業界平均の50%を大きく下回っている。一方、機能充実度は競合と遜色ない。
レバーの特定: 機能Aは「機能充実度」を上げる施策だが、今のボトルネックは「初回成功体験率」だ。まずオンボーディングを再設計し、ユーザーが価値を実感する前に離脱するのを防ぐ方がレバーになる。
渡す成果物: ファネル図 + コンバージョン率の数値 + 「機能Aの前に、オンボーディングの改善案を3つ出してほしい」
シナリオ3: プライシング戦略
後輩の提案: 「競合と同じ価格帯にすべきです」
先輩の構造化:
収益 = ユーザー数 × 課金率 × 価格
感度分析を行うと、価格を10%下げても、ユーザー数は5%しか増えない（価格弾力性が低い）。一方、課金率が現状3%で、競合の10%を大きく下回っている。
レバーの特定: 価格を下げてもユーザー数は増えない。むしろ、価値訴求を変えて課金率を上げる方がレバーだ。無料ユーザーに対して、有料プランの価値を伝えるメッセージングやオンボーディングを改善しよう。
渡す成果物: 感度分析表 + 「価格ではなく、価値伝達を見直す施策を考えてほしい」
シナリオ4: パフォーマンス問題
後輩の提案: 「レスポンスが遅いので、サーバーを増強すべきです」
先輩の構造化:
レイテンシ = クエリ数 × 1クエリあたりの処理時間 × インフラ性能
ログを見ると、1ページ表示で平均50回のクエリが発行されている。しかもそのうち40回は不要な重複クエリ（N+1問題）だ。
レバーの特定: インフラを増強しても、クエリ数が多すぎるので根本解決にならない。まずN+1問題を解消し、クエリ数を10回に減らす方が、コスト効率も効果も高い。
渡す成果物: パフォーマンス分解図 + ログ分析結果 + 「N+1問題の解消から着手してほしい」
シナリオ5: 組織課題（意思決定の遅さ）
後輩の問題認識: 「ミーティングが多すぎて、意思決定が遅いです」
先輩の構造化: Iceberg Modelで分解する
- 表層: ミーティングが多い
- 中層: 承認フローが長い（5段階の承認が必要）
- 深層: 意思決定権限が分散している（各レベルに拒否権がある）
- 最深層: リスク回避文化（失敗を恐れ、全員の合意を求める）
レバーの特定: ミーティングを減らす（表層）のは対症療法に過ぎない。意思決定権限の再定義（深層）、あるいはリスク許容度の文化変革（最深層）がレバーになる。例えば、「金額100万円以下の施策は、PdMが単独で決定できる」というルールを作る。
渡す成果物: Iceberg図 + 「権限マトリクスの見直し提案を作ってほしい」
レビューの実践技術 — 「渡し方」と「問いかけ」
構造図を作って渡すだけでは不十分。後輩が自分で考えられるような渡し方と問いかけの技術が必要になります。
“レビューの渡し方”の3原則
1. 完成形ではなく80%で渡す
後輩が最後の20%を埋めるよう、意図的に余白を残す。例えば、「初回成功体験率、習慣形成率、継続価値」の3要素は示すが、「どれがレバーか」は後輩に考えさせる、などです。
2. 結論を言い切らない
「絶対にXがレバーだ」ではなく、「データを見る限りXが有力だと思うが、君はどう見る？」と問いかける。これにより、後輩は自分の頭で考える習慣がつきます。
3. 選択肢を提示する
「AとBどちらがレバーだと思う？根拠は？」と選択肢を示し、判断プロセスを学ばせる。
効果的な問いかけパターン
- 「この構造を見て、何が一番大きく効くと思う？」
- 「もし予算が1/10になったら、どこに集中する？」（制約による優先順位の炙り出し）
- 「この要素を2倍にしたら、ゴールにどれだけ近づく？」（感度の直感テスト）
- 「競合はこの構造のどこに投資していると思う？」（外部ベンチマーク）
避けるべき渡し方
- 完璧な構造図 + 完璧な結論: 後輩の思考機会を奪う
- 「これ見て考えて」だけ: ガイダンス不足で後輩は迷子になる
- 構造なしで結論だけ: 「Xに集中して」とだけ言っても、なぜそれがレバーなのか理解できない
重要なのは、構造的思考の「型」を学ばせること。
後輩の構造思考力を育てる — 段階的支援の引き算
最終目標は、後輩が自分で構造を見抜き、レバーを特定できるようになること。そのためには、支援レベルを段階的に下げていく必要があります。
Lv.1: 完全提示（初期）
先輩が構造図を作成し、レバーを特定する。「これをベースに進めて」と渡す。この段階では、後輩は「こういう風に考えるのか」という型を学びます。
Lv.2: 共同作成（成長期）
先輩が分解パターンを提示する（「方程式で分解してみよう」「ファネルで見てみよう」）。後輩が実際に分解し、一緒にレバーを議論する。この段階では、後輩は「どのパターンを使うか」の判断力を学ぶ。
Lv.3: レビュー（自立前期）
後輩が構造図を作成し、先輩がレビューして修正点を指摘する。「この要素が抜けている」「因果関係が逆」「ここはもっと分解できる」といった形で、精度を上げるサポートをする。
Lv.4: 確認のみ（自立後期）
後輩が構造図とレバー特定を完成させ、先輩は最終確認のみ。「良いね。ただしリスクXも考慮しておいて」といった補足をする程度。
打席の数にもよりますが、この4段階を、6ヶ月〜12ヶ月で移行していくイメージ。もちろん、後輩のレベルや問題の複雑さによって柔軟に調整する必要ありです。
重要なのは、いつまでもLv.1に留まらないこと。後輩が依存してしまい、自分で考える力が育たない。
また、急にLv.4に飛ばないこと。後輩が迷走し自信を失ってしまいます。
よくある失敗パターンと対策
構造的レビューを実践する際いくつかの落とし穴があるのでそれも記載しておきます。
失敗1: 構造が複雑すぎる
15個以上の要素を含む構造図を作ってしまい、後輩（というかプロダクトチーム）が理解できない。
対策: 3〜5要素に絞る。必要なら階層化して（大項目と小項目に分ける）まずは大項目だけを見せる。
失敗2: レバーを断定しすぎる
「絶対にXがレバー」と言い切ってしまい後輩が思考停止する。あるいは、後輩が「本当にそうかな？」と疑問を持っても言い出せない。
対策: 「データを見る限りXが有力だが、Yの可能性も検証してほしい」と、選択肢を残す。
失敗3: 構造が抽象的すぎる
概念図のみで数値やデータが入っていない。「リテンション = 初回成功体験 × 習慣形成」という方程式だけを示して、実際の数値（初回成功体験率15%、習慣形成率60%）を示さない（実際の数字出しを後輩PdMの役割として出してもらうことを意図するならあり）。
対策: 必ず現状値・目標値・ギャップを数値で示す。数値があるからこそ、レバーの判断ができる。
失敗4: レビューの頻度ミス
毎日レビューしてしまい後輩が依存する。あるいは、月1回しかレビューせず後輩が迷走する。
対策: 初期は週1~3回、徐々に隔週、そして月1回へと頻度を下げていく。問題の複雑さや後輩のレベルに応じて調整する。
失敗5: 「なぜそれがレバーか」を説明しない
「Xに集中して」とだけ言ってなぜXがレバーなのかの根拠を示さない。後輩は納得できずモチベーションも上がらない。
対策: 4つの判断軸（影響度・制御可能性・ギャップ・波及効果）を使って、定量的に根拠を示す。
今日から実践できるアクション
アクション1: 次回の1on1で1つの問題を分解する
後輩が取り組んでいる問題を1つ選び、「方程式分解」「ファネル分解」「フィードバックループ分解」のいずれかのパターンで一緒に分解してみる。ホワイトボードや紙に書きながら、「こういう風に分解すると、レバーが見えるよね」と型を示す。
アクション2: レバー評価マトリクスを作ってみる
影響度・制御可能性・ギャップ・波及効果の4軸で、各要素をスコアリングする表を作る。エクセルやNotionで簡単に作れる。これを後輩と一緒に埋めながら、「どの要素がスコアが高いか？」を議論する。
アクション3: 「80%の完成度」で渡す練習をする
次に構造図を作るとき、意図的に20%の余白を残す。例えば、「初回成功体験率、習慣形成率、継続価値の3つに分解したけど、君はどれがレバーだと思う？根拠を3つ挙げてほしい」と問いかけてみる。
Q&A
Q1: 後輩が「レバーが分からない」と言ってきたらどうすればいいですか？
A: まず、4つの判断軸（影響度・制御可能性・ギャップ・波及効果）を1つずつ一緒に評価してみる。「初回成功体験率を上げたら、リテンションはどれくらい変わると思う？」「これは君がコントロールできる要素？」と具体的に問いかけながら、判断プロセスを体験させるのがおすすめ。
Q2: 構造図を作る時間がないときはどうすればいいですか？
A: 完璧な図を作る必要はないです。ホワイトボードに手書きで5分で描く程度でも十分。重要なのは、「問題を分解する」という型を示すこと。後で清書するのは後輩に任せてもいいです。
Q3: 後輩が提案してきた施策が明らかに低レバーなとき、どう伝えればいいですか？
A: まず構造を可視化し、「君の提案はこの要素に効くよね。一方、こっちの要素はどう？データを見ると、こっちの方がギャップが大きい気がするんだけど」と問いかける形で気づかせる。頭ごなしに否定せず、一緒に構造を見ながら議論するのが建設的です。
Q4: 「構造的レビュー」と「細かいレビュー」のバランスはどうすればいいですか？
A: 構造的レビューは「大きな方向性」を示すもの。細かいレビュー（PRDの文章、ロジックの穴）は、方向性が合っていることが前提で行う。順序としては、まず構造的レビューで方向性を合わせ、その後に細かいレビューをする。逆にすると、細部を詰めても方向性が間違っていて全部やり直し、ということになります。
Q5: 後輩が自分の構造図に固執して、修正を受け入れない場合は？
A: データや数値で示す。「君の構造図だと、Xがレバーになるけど、実際のデータを見るとXの改善余地は小さい（現状値80%、目標値85%）。一方、Yは現状値20%、目標値50%で、改善余地が大きい」と定量的に示せば、感情論ではなく事実ベースの議論ができます。それでも無理なら上司にアラートを出しましょう。
参考情報
- Donella H. Meadows (1997). “Leverage Points: Places to Intervene in a System.” https://donellameadows.org/archives/leverage-points-places-to-intervene-in-a-system/
- Abson, D. J., Fischer, J., Leventon, J., Newig, J., Schomerus, T., Vilsmaier, U., … & Lang, D. J. (2017). “Leverage points for sustainability transformation.” Ambio, 46(1), 30-39.
- Peter Senge (1990). “The Fifth Discipline: The Art and Practice of the Learning Organization.” Doubleday.
- Eliyahu M. Goldratt (1984). “The Goal: A Process of Ongoing Improvement.” North River Press.
コメント