この記事の要約
- プロジェクトの未来が霧の中にあるような「見通しの悪さ」と「確信のなさ」こそ、PdMが抱える不安の根本原因
- この不安は、状況を成り行きで「管理」する限りなくならず、解決策は学習と合意形成のプロセスを自ら「設計」し、不確実性をコントロールすること
- プロセスを設計できるPdMは、単に不安を解消するだけでなく、チームに自信と明確な見通しを与えるリーダーへと役割が進化し、プロダクトの成功確率を劇的に高める
順調に進んでいるはずのプロジェクト。でも、ふとした瞬間に胸をよぎる一抹の不安。
- 「本当にこれでユーザーは喜ぶのか？」
- 「リリースしたとして、事業は伸びるのか？」
- 「主要なステークホルダーは、心の底から納得しているのだろうか？」
この漠然とした、しかし無視できない不安こそが、我々プロダクトマネージャー（PdM）のパフォーマンスを蝕む真の敵です。ビジネスサイドと開発の狭間で、プロジェクトの未来に対する全責任を一身に背負っているような感覚。
この不安の正体は、プロジェクトの未来に対する「見通しの悪さ」と、自分たちの意思決定に対する「確信のなさ」に他なりません。そして、この霧を晴らす鍵こそが、プロジェクトマネジメント（PjM）スキルの本質で、それは状況の「管理」ではなく、成功へのプロセスを「設計」する能力なのです。
なぜ我々は不安になるのか？ — 管理者（Manager）の限界
プロダクト開発は、本質的に不確実なものです。シリコンバレーのプロダクトマネジメントの第一人者であるマーティ・ケーガンが名著『INSPIRED』で述べたように、私たちのアイデアの少なくとも半分は期待通りには機能しない、という厳しい現実があります。
この不確実性の高い環境で、「管理者」として振る舞おうとするとどうなるでしょう。必然的に、後手に回ります。
- 大切な要求の検証がやり切れてなくて意思決定が遅れる
- 仕様の抜け漏れが発覚して対応に追われる
- ステークホルダーから突然の横やりが入り計画が狂う
- 開発チームから「これは技術的に実現不可能です」と言われ、仕様の再検討を迫られる
こののような「問題が起きてから対処する」というモードこそが不安の源泉。コントロールできない状況をなんとかしようと必死にもがき、疲弊していくのです。
上記のような状態に対して、僕がマーケター/プロダクトマネージャーとして叩き込まれたり学んだりしたことが、「戦略なき戦術は無意味」という思想でした。プロダクト開発も同じで、場当たり的な問題解決は戦術レベルの話に過ぎません。我々PdMが立つべきは、戦術を支配する「戦略」、すなわち「プロセスを設計する」という視点です。
管理者（Manager）から設計者（Architect）へ
そこで、思考のOSを入れ替えましょう。
PdMのプロジェクトマネジメントは、家が建っていく工程を管理する現場監督の仕事ではありません。そもそも、どんな家を、どんな手順で、誰と協力して建てれば、最も住み心地が良く、かつ頑丈な家が出来上がるのか、その「設計図」と「工程表」を描く建築家（Architect）の仕事なのです。
設計すべきものは、大きく2つ。
1. 航路図（Route Design）：確信を積み重ねるためのプロセス設計
「何を作るべきか」という問いに対し、学習サイクルを回すことで「我々は正しい道を進んでいる」という確信を一段ずつ積み上げていくための設計図です。
2. 海図（Chart Design）：見通しを立てるためのプロセス設計
プロダクトに関わる多様な人々の思惑や制約を可視化し、組織的な座礁を防ぐことで、プロジェクトの未来に対する見通しをクリアにするための地図です。
この2つを設計し、運営することこそが、我々を不安から解放し、プロダクトを成功に導くのです。
実践①：『航路図』で「確信」を積み重ねる
まずは、プロダクトの価値の源泉である「発見（ディスカバリー）」のプロセス設計、すなわち『航路図』の描き方です。その目的は、チームの「確信」を育てることにあります。
僕も過去大きな失敗をしました。とある新機能開発で考えた仕様を詰め込んだPRDを作成しました。しかし、開発終盤のユーザーテストで「そもそも、この機能が解決しようとしている課題は、そこまで重要じゃない」という致命的なフィードバックを受けたのです。
そうならないた目には、問いの定義→検証デザイン→実行と意思決定→のプロセス設計が必要。
Step 1: Define (問いの定義)
確信を積み上げる旅は目的地を定めることから始まります。それは、ビジネス上の意思決定に繋がる具体的な「問い」を立てることです。
悪い問いは、漠然としていてチームを迷わせます。
- 悪い問い: 「ユーザーが何を欲しがっているか調査する」
良い問いは、具体的で、検証可能で、チームに進むべき方向を示します。
- 良い問い: 「X事業のLTV向上という目標に対し、既存ユーザーは月額500円を払ってでも『〇〇の手間を自動化する機能』を使いたいか？」
まずはこの「問い」を書き出し、チームやステークホルダーと「今回の航海の目的は、この問いに答えを出すことだ」と合意する。これにより、チームの活動に明確な焦点が生まれます。
Step 2: Design (検証のデザイン)
次に、目的地（問い）にたどり着くための最短ルート、つまり検証サイクルを設計します。重要なのは、いきなり完璧なプロダクトを作ろうとしないこと。『リーン・スタートアップ』で提唱された、MVP（Minimum Viable Product：実用最小限の製品）の考え方がまさにこれです。
ここで役立つのが、シンプルな思考ツールです。
▼ 仮説検証キャンバス
問い：（Step1で定義した問い）
仮説：我々は、「（ターゲットユーザー）は（特定の課題）に深く悩んでおり、我々の（解決策アイデア）を使えば、その課題が解決できる」と信じている。
検証：この仮説を証明／反証するための、最も安価で速い方法は何か？
例：課題の存在を確かめるために5人のターゲットにユーザーインタビューを行う。／解決策の価値を確かめるためにFake Door（偽のドア）で事前登録を募る。判断基準：何を以て「仮説が検証された」と判断するか？
例：インタビュー対象5人中4人以上が「お金を払ってでも解決したい」と発言する。／事前登録率が目標のX%を超える。
例えば、初期のメルカリは「個人間取引は、知らない相手とのやり取りが怖い」という大きな不確実性（問い）に直面しました。彼らは最初から完璧なシステムを作るのではなく、エスクロー決済（運営が代金を一時的に預かる仕組み）というMVPを導入し、「これならユーザーは安心して取引できるはずだ」という仮説を検証しました。この小さな検証の成功が、「自分たちは正しい道を進んでいる」というチームの確信を一段階高めたのです。
Step 3: Do & Decide (実行と意思決定)
計画ができたら、あとは実行（Do）し、そして最も重要な意思決定（Decide）の場を運営します。
学習スプリントの最後には、必ず「意思決定会議」をセットしてください。この会議の目的は、進捗を報告することではありません。チームでファクトを共有し、「この航路を進むべきか（Go）」「引き返すべきか（No-Go）」「別の航路を探すべきか（Pivot）」を決めることです。
PdMの仕事は一人で正解を出すことではありません。チームがファクトに基づいて賢明な意思決定を下せるプロセスを設計し、ファシリテートすること。これこそが求められています。この場を通じてチーム全員が「自分たちで決めた」という当事者意識を持つことこそが、揺るぎない確信の土台となります。
実践②：『海図』で「見通し」を立てる
さて、どれだけ確信を持って航海に乗り出しても、組織という大海原には予期せぬ岩礁や嵐が待ち受けています。そこで必要になるのが、プロジェクトの未来に対する『見通し』をクリアにするための海図、すなわち合意形成のプロセス設計です。
これも僕の苦い経験ですが、あるプロジェクトで開発終盤に営業チームへ共有したところ、「そんな仕様では全く売れない。現場のニーズとズレすぎている」と大反発を受け手戻りが発生したことがあります。
海図なき航海は、必ず仲間割れや外部からの圧力で座礁します。
Step 1: Map & Analyze (関係者のマッピングと分析)
まず、この航海の成功に誰が関わっているのか、彼らの関係や関心事を可視化します。
ここで何かフレームワークを使うなら、その1つが「ステークホルダー影響度マップ」です。これは、縦軸に「影響力の大きさ」、横軸に「関心度の高さ」を置いた4象限のマトリクス。ここに、経営陣、事業責任者、営業、マーケティング、法務、カスタマーサポートなど、関連する人物や部署をプロットしていきます。
しかし、ただプロットするだけでは不十分です。さらに一歩踏み込んで、それぞれのステークホルダーが持つ「期待（何を成功と見なすか、KPIは何か）」と「懸念（どんなリスクを恐れているか、制約条件は何か）」を具体的に書き出します。
Step 2: Plan (関与シナリオの計画)
勢力図が描けたら、それに基づいて「誰と、いつ、どのように関わるか」を戦略的に設計します。場当たり的な報告や根回しではなく、計画的なコミュニケーションをデザインするのです。
▼ コミュニケーションプランの例
- 密に連携する（影響力：大、関心度：大）
- 対象：事業責任者、開発リード
- 関与方法：週次の定例会議で意思決定に参加してもらう。Slackの専用チャンネルで常にオープンに議論する。
- 満足させる（影響力：大、関心度：小）
- 対象：経営層
- 関与方法：月次でのサマリー報告会を設定。重要な意思決定事項は事前に1on1でインプットをもらう。
- 情報提供を続ける（影響力：小、関心度：大）
- 対象：営業チーム、CSチーム
- 関与方法：隔週での進捗共有会を開催。リリース前の勉強会でフィードバックをもらう。
- 観察する（影響力：小、関心度：小）
- 対象：関連性の薄い他部署
- 関与方法：四半期ごとの全社共有会でアップデートを報告する程度。
例えばSlackは、元々ボトムアップで各チームに導入されましたが、全社的なエンタープライズ契約を獲得する上では、情報システム部門やセキュリティ担当者といった影響力の大きいステークホルダーの協力が不可欠でした。彼らは当初、セキュリティへの「懸念」が大きかったはずです。Slackは彼らを重要なステークホルダーと捉え、懸念を解消するための機能（SAML認証やeDiscovery対応など）を開発し、対話を重ねることで、巨大な市場を切り拓きました。これは、見通しを立てた上で戦略的に関与した見事な事例です。
Step 3: Execute (公式なプロセスとして実行)
最後に、そして最も重要なことですが、この計画をあなた個人のタスクリストではなく、プロジェクトの「公式な運営プロセス」として実行します。
プロジェクトのキックオフで、このコミュニケーションプランを全関係者に説明し、合意を得るのです。「この会議ではこれを決めます」「このドキュメントを見れば最新の航路図が分かります」という共通認識を作る。これが、俗人性を排し、プロジェクトの見通しを良くする仕組みの力です。
より具体的な合意形成のフレームワークについては、「プロダクトを前進させる合計形成のフレームワーク」の記事でも詳しく解説しているので、ぜひ参考にしてみてください。
優れたPdMは、個人の突破力だけでなく、チームと組織が自律的に動ける「仕組み」を設計する能力に長けています。この海図は、まさにそのための強力なツールとなるでしょう。
『プロジェクトの航海日誌』こそが、あなたの価値になる
ここまで、プロダクトマネージャーにとってのプロジェクトマネジメントを『航路図』と『海図』という2つの設計図について解説してきました。
これらのプロセスを実践しその記録を残していくこと。それは、単なるドキュメント作成作業ではありません。不確実な航海を成功に導いた、あなた自身の『航海日誌』を紡いでいく行為です。
この航海日誌こそが、プロダクトの成功確率を再現可能なものにし、チームの学習資産となります。そして何より、「どんな困難な航海でも成功に導けるPdMである」というあなたの市場価値を証明する、最も強力なエビデンスとなるのです。
今日から実践できるアクション
- 次のプロジェクトで、たった一つ「答えを出すべき問い」を文章で書き出す。誰にも見せなくて構いません。まずは自分の中で、今回のプロジェクトの「目的地」はどこなのかを言語化する癖をつけましょう。
- プロジェクト関係者を3人だけ選び、彼らの「期待」と「懸念」を聞いてみる。ランチや雑談の時間で構いません。「今回のプロジェクトで、〇〇さんは何を期待していますか？」「逆に、何か心配なことってあります？」と聞いてみましょう。これがあなたの「海図」作りの第一歩です。
- チームの定例会議のアジェンダの冒頭に5分だけ「学習の共有」時間を設ける。進捗報告ではなく、「この1週間でわかったこと・学んだこと」を共有する時間です。小さな成功も失敗もオープンに話す文化を作ることが、「航路図」を描くチームの土台になります。
Q&A
Q1. チームが協力的でなかったり、ステークホルダーが多忙で時間を取ってくれなかったりする場合はどうすれば良いですか？
A1. 完璧を目指さないことが重要です。最初は、最も協力的で影響力のある一人を味方につけることから始めましょう。その一人と一緒に小さな成功体験（例：小さな学習ループを回して、有益なインサイトを得る）を作り、「このやり方は、我々にとって有益だ」という事実を示します。成功の輪は、徐々に広がっていきます。「まず、やってみる」の精神が大切です。
Q2. 時間がなくて、こんなに丁寧な設計はできません。日々の業務に追われています。
A2. 気持ちは痛いほどわかります。しかし、これは「時間をかける」話ではなく「時間の使い方を変える」話です。最初にプロセスを設計する1時間は、後工程で発生する手戻りや調整の10時間を節約してくれます。今、あなたが火消しに使っている時間は、そもそも設計を怠ったことから生まれている「負債」かもしれません。まずは1時間だけ、目の前のタスクから離れて、プロジェクト全体の設計図を描く時間を確保してみてください。
Q3. EM（エンジニアリングマネージャー）との役割分担はどう考えれば良いですか？
A3. 理想的な分担は、PdMが「Why/What」に関する不確実性を解消する『航路図』と、組織を動かす『海図』の設計に責任を持ち、EMが「How」に関する不確実性（技術的実現性、開発プロセスの効率化、チームの健全性）の解消に責任を持つ、という形です。彼らはデリバリーにおける最高のパートナー。この記事で紹介した航路図や海図を、ぜひEMと一緒になって描いてみてください。最高の相棒になってくれるはずです。
参考情報
- マーティ・ケーガン『INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント』（日本能率協会マネジメントセンター、2021年）
- エリック・リース『リーン・スタートアップ』（日経BP、2012年）
コメント