はじめに

気づけば沼っていた

経験浅めPM（自分）が、プロダクト連携のプロジェクトで、
「このプロジェクト、関係者ちょっと多いけど、まあ何とかなるでしょ」
的なテンションで始めてしまった結果、

誰に話せば決まるのか分からない
どこで話が止まっているのか分からない
次の一手も、「これで合ってるのか…？」と自信が持てない

みたいな沼にハマることになりました。

そういうことを繰り返さない / 読んでいただいた方に同じ体験をさせない
ために、沼をどう回避するかについて書いていきます。

こんな人向け

プロダクトマネージャーの経験や知識が浅い方
ステークホルダーの多いプロジェクトマネジメントが苦手な方

という人向けです。

✅ 完璧に回す方法、ではなく
✅ 経験浅めでも「致命傷を避ける」ための考え方とチェックポイント
を持ち帰ってもらえると嬉しいです。

前提情報

この話はこんな構図です。

自分はプロダクトAのPM / PdM
プロダクトBと連携させるプロジェクトを担当

プロダクトA・Bそれぞれに

開発チーム
コンサルチーム
意思決定に関わる人たち

がいて、そこそこ“ステークホルダー多め”なプロジェクト。
▼イメージ図（大体こんな感じ）

何が起こっていたのか

1. 要件が全く決まらない

こういう機能を作るという要件をプロダクトBチームに相談すると
「それはこのプロダクトの仕様的に難しいですね」
とNGとなり、要件を考え直す必要が出てきます

そのうち、

「じゃあ何ならできるの？」
「どこまでを前提に考えればいいの？」

が分からなくなっていきます。
議論のたびに要件が振り出しに戻り、
「要件定義をしているはずなのに、永遠に定義が終わらない」感覚になっていました。

2. デザイン・システムの制約を知らないまま提案してしまう

連携先(プロダクトB)の

デザインシステム
画面構成
コンポーネントのルール

がしっかり頭に入っていない状態で、
プロダクトAチームの感覚ベースで「こんなUIにしたいです」と提案すると、

「その遷移はこのプロダクトではNGです」
「このアイコンは使えるものではないです」
「このエリアにはボタンを置くのはできないんです」

結果として、
「それは難しい」のループにはまり、
建設的な議論にたどり着くまでに、かなりの時間を使いました。

3. 誰が意思決定者なのか分からない

「この人とすり合わせたら良いかな？」と思って議論を進めていたら、
その一つ下で稼働している方が、実質的な決定権を持っているということがありました。
（下記のようなコミュニケーション取ってた）

当然、決定のリードタイムは長くなり、
「この話、2週間くらいしてないか？」という状況が生まれてました。

4. 情報がどこで止まっているのか分からなくなる

プロジェクトが進むにつれて、

今、誰がどんな情報を持っているのか分からない
誰に何を結節できていないのか分からない

という状況になりました。

その結果、情報の結節が遅れて
「なんでこの話ここで止まってるの？」
と怒られることが多発。

自分が何かをサボっているわけではないのに、気づいたら“止めている人”になってしまう
という、かなりしんどい状態でした。

結果どうなったのか

開発チーム、コンサルの方々がめちゃくちゃ仕事ができる人たちだったおかげもあり、
発生した遅延を無かったことにするレベルで動いてくださり、
なんとか期日までにリリースできるところまで来ました。

結果だけを見ると「ちゃんと間に合ったプロジェクト」です。
ただ、達成感というより、
「もう同じような経験はしたくな、関係者にさせたくない」
という気持ちしか残ってないので

次に同じような案件が来たら何を変えるべきなのか
を、自分なりに構造化して整理してみました。

原因の構造化

出来事を眺め直してみると、
うまく進まない原因は、ざっくり2つでした。

1：コミュニケーションの構造が設計されていなかった

1つ目は、コミュニケーションの構造が最初に設計されていなかったことです。

誰が意思決定者なのか分からない
誰がどの情報を持っていて、誰に渡すべきか分からない
どこで情報が止まっているのか分からない
決まったと思ったら「やっぱりあの人にも確認を…」で戻る

こういった現象はすべて、
「誰と誰が、どんな粒度の情報を、どのタイミングで結節するのか」
「誰がどの範囲の決定権を持つのか」

がプロジェクトとして設計されていなかったことから来ていた、と考えられます。

2：プロダクトの前提・制約理解がスキップしていたこと

2つ目は、プロダクトの「前提と制約」が曖昧なままスタートしていたことです。

プロダクトBのデザインシステム・UIルールを知らないまま要件を考える
プロダクトB内の変数を知らないまま提案する
開発メンバーも、後工程で初めて「そんな仕様があったのか」と気づく

つまり、プロダクトBに対する認識が大きくずれている状態で進めてしまっていました。
だから、後ろのフェーズで「この仕様があったので設計変更します」が頻発するわけです。

もうそういう経験をしないために

前提、プロジェクトに沼る要因は今回記載したこと以外にもっとあるとおもってます。
ですが、「大コケしないために、ここからやる」と決めた内容を共有していこうと思います。

1. 誰と話せば最短で前に進むかの調査・すり合わせをしておこう

「誰と話せば最短で前に進むかを徹底的に調査する」 ことです。

今回でいうと

プロダクトA側
- PM / PdM（自分）
- 担当コンサル
プロダクトB側
- 案件のPM
- 実務で意思決定権を持つリーダー
- PdM
- デザインリーダー

こういった人たちを洗い出し、

誰がどの範囲の決定権を持っているか
誰に話せば、どの情報が最短で伝わるのか
どこが「詰まりやすい結節ポイント」になりそうか

を、明確にしておくようにします。

逆にこういった整理をせず、
「この人にだけ投げておけば何とかなるでしょ」という前提で進めると、
その前提が崩れた瞬間に一気に苦しくなります。

経験が浅いPM（僕みたいな人）ほど、
最初にここを押さえることで、後の負荷はかなり減ると思ってます。

2. とにかく事前インプットしよう

制約は何？どこは変数でこちら側で決めれる？
を明確にするために、わからないことを徹底的に潰すことを
プロジェクトを始める前にやっておくことが重要です。

今回は、プロダクトBの

デザインルール
コンポーネントの制約
プロダクトの仕様

これを調査して、要件定義書などに記載しておくことで
開発メンバーや要件を一緒に決める方々からすると、

「ここは変数として捉えていいんだな」
「このエリアでUIを変えることはダメなんだな」

と言ったように、要件や開発フェーズにおける思考・行動の幅を決めておくことが
プロジェクトの進行スピードはグッと早くなると思います。

チェックリスト

最後に、自分向けのメモも兼ねたチェックリストです。

✅ 誰と話せば最短で前に進むかを調査しよう
■ 名目上のPMと「実際の意思決定者」は誰か整理したか？
■ プロダクトA/Bそれぞれの「情報のハブ」になる人は誰か把握したか？
■ 情報が詰まりやすい結節ポイント（どこで話が止まりそうか）を書き出したか？

✅ とにかく事前インプットしよう
■ デザインルール・仕様の理解はできているか？
■ 要件定義における変数は明確になっているか？

おわりに

どれだけ優秀な開発者・デザイナー・コンサルの方がいても、
PMがコミュニケーションの設計や事前準備を怠ると、
高品質な成果物さえ無駄にしてしまう可能性がある
今回のプロジェクトで強く学んだことです。

今回のような事例に近い案件や、PMむずいなあと考えている方の参考になれば嬉しいです。
自分自身も、次に同じような案件が来たら、
この記事のチェックリストからスタートしようと思います。