この記事の要約
- 「失敗したくない」という心理から、細かい論点潰しやデータ収集に時間を使いすぎ、結果としてチームの足を止めてしまう「分析麻痺」の状態は問題
- 原因は 意思決定を「正解当てクイズ」だと誤解していること。そして、反対意見を持つメンバーや後輩PdMを納得させ、巻き込むための「具体的・政治的な作法」を知らないこと。
- 解決のために 「撤退ライン」を握ることで反対派を合意させる技術、後輩PdMへの「権限委譲」の急所、そして開発フェーズでの「雪かき」による速度最大化が必要」。
プロダクトマネージャー（PdM）として経験を積み、任される領域が広がると、ある「恐怖」に襲われる瞬間があります。
「この仕様で本当に大丈夫か？」
「もしリリースして数字が下がったら、どう説明しよう」
その結果、あと少しデータが集まれば確信が持てるかもしれない、このコーナーケース（稀なケース）まで考慮しておかないと手戻りになるかもしれない、と石橋を叩き続けている間、エンジニアやデザイナーの手は止まり、チーム全体の空気が停滞していきます。
完璧なロジックを組み上げることに必死で、会議室で悩み続け、現場の足を止めてしまっているのです。
しかし、PdMの仕事は「正解を当てること」ではありません。「不確実な中で何かを決め（Decide）、泥臭く前に進める（Execute）こと」。これに尽きます。
この記事では、PdMが陥りがちな「分析麻痺」からの脱却方法と、反対派や後輩PdMをも巻き込んでプロジェクトを加速させるための、具体的で生々しい「推進の技術」について解説します。
PdMの仕事は「100点の正解」を探すことではない
なぜ僕たちは細かい論点まで潰そうとしてしまうのか？
真面目なPdMほど、「想定外」を恐れます。
リリース後にトラブルが起きないよう、あらゆる可能性を検討し、論点を潰しきってから開発に着手しようとします。
しかし、インテル元CEOのアンドリュー・グローブが名著『High Output Management』で定義したように、「マネージャーのアウトプット ＝ 自分の組織のアウトプット」です。
あなたがどれだけ高尚な戦略を脳内で練っていても、あるいは完璧な仕様書を時間をかけて作っていても、その間チームがコードを書けず、デザインを作れていなければ、あなたのアウトプットは「ゼロ」です。
むしろ、あなたの迷いはチームに伝染し、速度を殺す「マイナス」の要因になり得ます。
「開発が遅い」と言う前にPdMが自責で見直すべきポイントでも触れましたが、チームの速度を落としている最大のボトルネックは、実は「PdMの決定待ち」であることが往々にしてあるのです。
「分析麻痺（Analysis Paralysis）」の自覚症状
また、「情報が足りないから決められない」というのは、多くの場合、決断を先送りするための言い訳です。
情報が7割あっても動けない。残りの3割（どうなるか分からない未来）を埋めるために、追加のユーザーインタビューを企画したり、ログを漁ったりしていませんか？
データで証明できない意思決定はどうすればいいのか？という記事でも書きましたが、ビジネスにおいて情報が100%揃うことはありません。
「決定の遅れ」は、「誤った決定」をして後で修正するコストよりも、遥かに高くつくことが多いのです。
「決める力」をハックする。不確実性の中で前に進む技術
では、どうすれば怖がらずに決められるのか。
シリコンバレーの巨人たちが実践しているフレームワークを借りるのが近道です。
ジェフ・ベゾスの「Type 1 / Type 2」と「70%ルール」
Amazon創業者のジェフ・ベゾスは、意思決定を2種類に分けています。
（元々は行動経済学の概念でD・カーネマンの『ファスト&スロー』などで詳しく紹介されています）
- Type 1（不可逆）： 一度通ったら戻れないドア。慎重に議論すべき。
- Type 2（可逆）： ドアを開けて入ってみて、気に入らなければ戻ってこれる。
PdMが直面する意思決定の9割は、実は「Type 2（可逆）」です。
「ABテストをしてダメなら戻せばいい」「一部ユーザーに公開して反応を見ればいい」。そう捉え直すだけで、肩の荷は降ります。
また、ベゾスは「情報が70%揃ったらGoサインを出すべきだ」とも言っています。90%まで待つのは遅すぎます。残りの30%は、走りながら補正する覚悟を持つ。これがスピードの源泉です。
アニー・デューク『確率思考』に学ぶ
また、ポーカーの世界チャンピオンであり認知心理学者のアニー・デュークは、著書『確率思考（Thinking in Bets）』の中で、「結果論（Resulting）」の危険性を説いています。
「失敗した」＝「あの時の判断が間違っていた」とは限りません。
確率は常に変動します。【要約】『確率思考の戦略論』でも触れたように、その時点で最も期待値が高い選択をしたのであれば、たとえ結果が裏目に出ても、それは「良い意思決定」だったのです。
「正解」を選ぼうとするから足がすくみます。
「進める力」① 反対派を動かす「Disagree and Commit」のリアリティ
さて、決めた後は「進める」フェーズです。
ここで壁となるのが、メンバーからの「反対意見」や「懸念」です。
よく「Disagree and Commit（反対してもいい、だが決定にはコミットせよ）」と言われますが、これは精神論だけで実現できるものではありません。
「議論は尽くしたから、俺に従ってくれ」と言われても、納得していない人間は心の底ではブレーキを踏み続けます。
反対派を本気でコミットさせるには、プロダクトを前進させる合意形成のフレームワークでも触れたような、具体的な「契約」が必要です。
技術1：「撤退ライン（ガードレール）」を握る
これが最も強力な合意形成テクニックです。
反対している人は、あなたの案が失敗して、プロダクトが毀損することを恐れています。
だからこそ、「失敗した時の安全性」を保証するのです。
「〇〇さんが懸念している『離脱率の悪化』のリスクは理解しました。
では、こうしませんか？
リリースして1週間で、もしCVRが5%下がったら、即座に元の仕様に戻すと約束します。
その代わり、そこまではこの新仕様でチャレンジさせてくれませんか？」
このように「撤退ライン」を明確に握ることで、反対派も「最悪の事態は回避できるなら、実験として協力しよう」と、前向きにコミットできるようになります。
技術2：相手の懸念を「自分の言葉」で語り返す
人は「自分の意見が理解された」と感じない限り、他人の意見を受け入れません。
『人を動かす』をプロダクトマネージャーが実践するための具体指針にもある通り、まずは相手の言い分を肯定することから始まります。
「でも」「いや」と反論する前に、「なるほど、〇〇さんの懸念はAとB、特にBのリスクが高いと考えているわけですね？」と、相手以上に相手の懸念を解像度高く語り返してください。
「分かってくれているなら、任せてみるか」という信頼は、ロジックではなく「傾聴」から生まれます。
「進める力」② チームと後輩PdMを加速させる「ブロッカー除去」
また、あなた自身のタスクだけでなく、チーム全体、あるいはあなたがマネジメントする後輩PdM（ジュニア/ミドル）を動かすことも「進める力」です。
対エンジニア・デザイナー：「雪かき」に徹する
開発フェーズに入ったら、PdMは「司令官」である必要はありません。
進行路の障害物を取り除く「スノープラウ（除雪車）」になってください。
- 他部署からの急な割り込みタスクをブロックする
- 法務確認や文言のチェックを最速で終わらせる
- 細かい仕様の質問に対して、Slackで即レスする
開発者が「コードを書く」「デザインする」こと以外に脳内メモリを使わなくて済む環境を作ること。これが最も手っ取り早くプロジェクトを加速させる方法です。
対・後輩PdM：委譲と介入のバランス
あなたが先輩として後輩PdMにプロジェクトを任せる時、「なかなか進まない」とイライラすることはありませんか？
それは多くの場合、後輩への「Whyの共有」が不足しています。
「この機能を作って」とWhatだけを渡すと、後輩は判断に迷うたびにあなたに確認しに来ます。
後輩PdMへの構造的なレビューを行い、「なぜこの機能が必要なのか」「意思決定の判断基準は何か」というロジック（OS）をインストールしてください。
そして、「判断に迷ったら相談して。責任は僕が持つから、思い切ってやっていいよ」と背中を押す。
マイクロマネジメント（Howへの口出し）は速度を殺します。介入すべきは「意思決定のロジック」のみです。
「進める力」③ 開発中の「勇気ある撤退（Descoping）」
最後に、リリース直前の修羅場で試される推進力について。
開発が進むにつれ、「思ったより実装が難しい」「予期せぬバグが出た」などの理由で、スケジュール遅延が見えてくることがあります。
この時、失敗を恐れるPdMは「エンジニアに気合を入れ直す（残業をお願いする）」か「納期を延ばす」選択をしがちです。
しかし、真に推進力のあるPdMは、ここで「スコープを削る（Descoping）」決断をします。
「今回のリリースのコア価値は何か？」に立ち返り、「この機能はマストじゃない。フェーズ2に回そう」「このアニメーションは凝らなくていい。標準挙動でいこう」と、「つくらない判断」を瞬時に下すのです。
捨てることは、作ること以上に勇気がいります。しかし、この「勇気ある撤退」こそが、リリース（Time to Market）を守り、ビジネスを前に進めるのです。
不確実性の霧の中で、最初に松明を掲げ、最後まで泥をかぶる
「決める」とは、正解を選ぶことではなく、不確実な未来への恐怖に打ち勝つことです。
「進める」とは、号令をかけることではなく、撤退ラインを握って安心させ、障害物をどけ、時には身を切ってスコープを調整する泥臭い営みです。
チーム全員が霧の中で立ちすくんでいる時、「こっちだ」と最初に松明（たいまつ）を掲げる。そして、もしその道が間違っていたら、誰よりも早く「すまん、こっちだった！」と泥をかぶって方向転換する。
『採用基準』でも語られるような、そんな「リーダーシップ」を発揮するPdMのもとでなら、チームは安心して全速力で走れるはずです。
今日から実践できるアクションリスト
- 現在「検討中」で止まっているタスクを書き出し、「情報不足」なのか「勇気不足（Type 2の決断）」なのかを分類し、後者なら今日中に決める。
- 反対意見が出ている案件について、「どの数値（KPI）を下回ったら元の仕様に戻すか」という撤退条件を明文化し、反対派と合意する。
- 開発チームに対して、「今、僕が取り除けるブロッカー（邪魔なタスクや未決事項）はある？」とSlackで聞いてみる。
よくあるQ&A
- Q. 「70%の情報」ですら集まらない時はどうすれば？
- A. それは新規事業や全く新しい機能の場合によくあります。Fake Doorなどの“プレトタイピング”で最速で仮説を検証するなど、開発せずに情報を集める手段を検討してください。それでもなければ、小さく賭ける（Type 2の決断）しかありません。
- Q. 後輩PdMが明らかに間違った方向に進んでいたら？
- A. 致命傷（Type 1の失敗）になりそうなら即座に止めます。しかし、リカバリー可能な失敗（Type 2）であれば、あえて失敗させて学ばせるのも手です。『失敗の本質』を学ぶ良い機会になります。ただし、「なぜその判断をしたのか」の事後振り返りは徹底しましょう。
コメント