はじめに
「これ、お願いしていた内容と違うんだけど…」
メンバーが仕上げてきたアウトプットを見て、そう思った経験はないでしょうか。方向性がズレている。粒度が粗い。自分がイメージしていたものと明らかに違う。でもメンバーは「指示通りにやりました」と言う。
あるいは逆のパターン。期日が近づいてきたのでメンバーに進捗を確認したら、「実は…あまり進んでいなくて」と切り出される。聞いてみると、何をどこまでやればいいのか分からず、ずっと悩んでいたらしい。
どちらも、PMをやっていれば一度はぶつかる場面だと思います。
こうした問題の原因は、多くの場合指示の抽象度が高すぎることにあります。PM本人は十分に説明したつもりでも、メンバーには伝わっていない。この記事では、なぜこうしたギャップが生まれるのか、そしてどう解決すればいいのかを掘り下げていきます。
PMとメンバーの「解像度の差」
なぜ差が生まれるのか
PMとメンバーでは、同じプロジェクトに対する解像度が大きく異なります。
PMは日頃からプロジェクト全体を俯瞰しています。クライアントの意図、ビジネス上の背景、他チームとの依存関係、スケジュール上の制約——こうした情報を常に頭に入れた上で、タスクを分解して指示を出しています。だから「この機能の設計書を作って」と言うとき、PMの頭の中には「誰向けに」「どの粒度で」「どのフォーマットで」「いつまでに」というイメージがかなり具体的にある。
一方、メンバーは基本的に自分の担当範囲の解像度は高いですが、プロジェクト全体の文脈を同じレベルで把握しているとは限りません。PMが当たり前だと思っている前提知識が、メンバーには共有されていないことは多い。
さらに、傾向としてPMには経験豊富で能力の高い人がアサインされるケースが多いです。その結果、PMが「これくらい言えば伝わるだろう」と思う基準と、メンバーが実際に理解できる範囲にギャップが生まれやすくなります。
100 vs 30 問題
分かりやすく数字で表現してみます。
PMが想像しているアウトプットの完成イメージを100としたとき、抽象的な指示だけではメンバーの脳内に浮かぶイメージは30程度しかない——こういう状態が実は珍しくありません。
| PMの頭の中 | メンバーの頭の中 | |
|---|---|---|
| ゴールの明確さ | 100（具体的に見えている） | 30（ぼんやりしている） |
| 背景の理解 | 深い（なぜ必要か分かっている） | 浅い（言われたからやる） |
| 品質基準 | 明確（過去の経験から分かる） | 不明確（どこまでやればOK？） |
| 優先順位 | 判断できる | 判断できない |
この差が70もある状態で「あとはよろしく」と任せてしまうと、問題が起きないわけがない。
メンバー側で何が起きているか
では、解像度が30のまま走り出したメンバーの身に、具体的に何が起きるのか。典型的なパターンを3つ紹介します。
パターン①: ゴールが見えず、自問自答に陥る
最もやっかいなパターンです。
メンバーは指示を受けたものの、そもそもどこに向かって走ればいいのか分からない。「設計書を作ってほしい」と言われても、何を書けばいいのか、どのレベルの詳細さが求められているのか、見当がつかない。
こうなると、メンバーの頭の中ではこんな思考が堂々巡りします。
- 「こういう内容でいいのかな…でも違う気もする」
- 「質問したいけど、何を聞けばいいかも分からない」
- 「もう少し自分で考えてから相談しよう…」
質問すらできないのがこのパターンの怖いところです。何が分からないのかが分からない。あるいは「こんなことも分からないのか」と思われるのが怖くて聞けない。結果、一人で悩み続けて時間だけが過ぎていく。
PMがこれに気づくのは、たいてい期日ギリギリか、期日を過ぎてからです。「実はあまり進んでいません」と報告が上がってきて初めて事態を把握する。この時点ではもうリカバリーの余地がほとんど残っていません。
パターン②: アウトプットは出てくるが、品質が足りない
メンバーは自分なりに理解して、自分なりに形にしてくる。本人としては「できた」と思っている。ところが、PMが見ると50くらいの完成度にしか見えない。
- 考慮すべき観点が抜けている
- 粒度が粗すぎて実用に耐えない
- 方針の前提がそもそもズレている
これは、メンバーに能力がないわけではありません。PMの頭にあった「100」のイメージが共有されていなかっただけです。メンバーは自分が見えている30〜50の範囲では、きちんと仕事をしている。
このパターンは、早めにレビューの機会があればリカバリーが効きます。途中段階で「方向性はこれで合ってる？」と確認できれば、軌道修正は軽い。しかしレビューが最後の最後になると、やり直しの工数が膨れ上がり、結局期日超過につながります。
パターン③: 方向を間違えたまま全力で走る
これはパターン②の発展形ですが、もっと深刻です。
メンバーがPMの意図を誤って解釈し、しかも自分の解釈に確信を持ってしまう場合。間違った方向に向かって全速力で走り、丁寧に仕上げて持ってくる。
出来上がったものの完成度は高い。しかし、方向が根本的に違う。
「すごく丁寧に作ってくれたんだけど、これじゃないんだよな…」
PMとしてはこれが一番言いにくい。メンバーが時間をかけて頑張ったのは分かっている。でもアウトプットとしては使えない。メンバーのモチベーションにもダメージを与えかねない。
このパターンでは、手戻りのコストが最大になります。間違った方向に進む時間が長いほど、やり直しの量も大きくなる。
PM側に起きる負のループ
こうしたパターンが何度か繰り返されると、PMの中にある感情が芽生えます。
「自分でやったほうが早い」
気持ちはよく分かります。指示を出す→伝わらない→レビューで差し戻す→やり直してもらう→結局時間がかかる。それなら最初から自分でやったほうが品質も速度も担保できる。合理的な判断に見えます。
しかし、これは負のループの入口です。
- メンバーに仕事を振るのが怖くなる
- PMが自分で抱え込む
- PMのリソースが足りなくなる
- PMがパンクする
- プロジェクト全体が回らなくなる
- さらに余裕がなくなり、メンバーへの指示が雑になる
- 1に戻る
「自分でやったほうが早い」は短期的には正しくても、中長期的にはチームもプロジェクトも破壊します。PMが倒れたら全部止まる。その状態は健全ではありません。
この負のループから抜け出すには、「振り方」を変えるしかありません。
解決策: 指示の解像度を上げる4つの方法
① サンプルや類似資料を提示する
最も即効性のある方法です。
「設計書を作ってほしい」ではなく、「この前のプロジェクトで作ったこの設計書と同じフォーマットで作ってほしい」 と伝える。期待するアウトプットの具体的なイメージを目に見える形で共有する。
- 過去の成果物をサンプルとして見せる
- 「こういう構成で、このレベルの詳細さで」と参考資料をつける
- フォーマットやテンプレートがあるなら先に渡す
言葉で100を伝えるのは難しくても、「これと同じようなものを作って」と見せれば一発です。解釈のズレが起きる余地がほぼなくなります。
② メンバーに自分の言葉で説明してもらう
指示を出した直後に、「今の内容を自分の言葉で説明してみてくれる？」 と聞いてみる。
これはシンプルですが、非常に効果的です。メンバーの説明を聞けば、どこまで理解できているか、どこが曖昧かが一目瞭然で分かります。認識のズレがあればその場で修正できる。
ポイントは、**「質問ある？」ではなく「説明してみて」**と言うこと。「質問ある？」に対して「大丈夫です」と返ってきても安心できません。質問がないのは理解しているからではなく、何が分からないか分かっていない可能性があるからです。
説明してもらえば、理解度が言葉として外に出る。曖昧な箇所が可視化される。その場でフォローできる。これだけで手戻りの確率は大きく下がります。
③ 背景と目的を伝える
タスクの「何をやるか」だけでなく、「なぜこれをやるのか」 を伝える。
「この設計書を作って」ではなく、「来週のクライアントレビューでこの設計書をもとに仕様を確認するから、クライアントが読んで理解できるレベルで作ってほしい」と伝える。
背景と目的が分かると、メンバーは自分で判断ができるようになります。
- 「誰が読むのか」が分かれば、適切な粒度が分かる
- 「何のために使うのか」が分かれば、何を優先すべきか分かる
- 「いつ使うのか」が分かれば、スケジュール感が掴める
背景が共有されていないと、メンバーは「言われた通りにやる」しかできません。背景が共有されていれば、PMが想定していなかった部分まで自主的にカバーしてくれることすらあります。
④ 中間チェックポイントを設ける
完成してから見せてもらうのではなく、途中段階でこまめに確認する仕組みを作る。
具体的には、タスクの着手後なるべく早いタイミングで一度確認するのが効果的です。
- 着手直後: 「方針をざっくり考えたら、作り始める前に一回見せて」
- 中間: 「半分くらいできたらレビューさせて」
- 完了前: 「最終版にする前に一回確認しよう」
特に重要なのは最初のチェックポイントです。方向性のズレは早期に発見するほど修正コストが小さい。完成度20%の段階で方向修正するのと、80%の段階で修正するのでは、手戻りの重さがまるで違います。
「マイクロマネジメントになりそうで嫌だ」と感じるかもしれません。しかし、これはマイクロマネジメントとは違います。メンバーの作業の一つ一つに口を出すのではなく、方向が合っていることだけを早めに確認する。むしろ、中間確認が機能していれば、安心して任せられる部分が増えます。
まとめ
PMとメンバーの間には、プロジェクトやタスクに対する解像度の差が存在します。PMが100のイメージを持っていても、抽象的な指示だけではメンバーには30しか伝わらない。
この差を放置すると、メンバーは迷走し、PMは「自分でやったほうが早い」の負のループに陥り、最終的にはプロジェクト全体が回らなくなります。
解決の鍵は、指示の解像度を上げることです。
- サンプルや類似資料を見せる — 言葉よりも実物が伝わる
- メンバーに自分の言葉で説明してもらう — 理解度を可視化する
- 背景と目的を伝える — 自律的な判断を可能にする
- 中間チェックポイントを設ける — 手戻りを最小化する
どれも特別なことではありません。しかし「分かっているけどやっていない」ことは、現場では驚くほど多い。まずは一つでも取り入れるだけで、チームのアウトプットの質は変わってきます。