「顧客は追加機能を来週末までに入れてほしいと言っている。でも開発チームはもう限界だと言っている」——このどちらにも強く言えない状態でPMが疲弊していくパターンは、炎上案件で繰り返し見られます。
板挟みの辛さは、どちらかの側に立てないことではなく、「何を整理すれば前に進めるか」が見えない状態が続くことです。顧客要求に無条件で従えば開発チームが壊れ、現場の声だけを聞けば顧客との関係が悪化する——その二択に追い込まれている感覚が問題です。
しかし実際には、板挟み状態は「整理できていない状態」であることがほとんどです。本記事では、顧客と開発チームの板挟みになったPMが、論点を整理して調整に動くための手順を整理します。
PMが板挟みになる構造
板挟みが起きる構造は単純です。顧客は「できるかできないか」ではなく「やってほしい」という要求を出します。開発チームは「これ以上は無理です」という現実を提示します。PMはその間に立って、どちらかに「違う答え」を持って行かなければなりません。
この状態を抜け出すための第一歩は、「顧客の要求」と「開発チームの制約」を、それぞれ事実として書き出すことです。頭の中で両方を同時に考えようとするから混乱します。
まず事実を分ける
まず、顧客の要求と開発チームの制約を別々に書き出してください。
顧客の要求として書き出すこと：何を、いつまでに、という内容。「来週末までに〇〇機能を追加してほしい」という具体的な要求の内容と期限。
開発チームの制約として書き出すこと：現時点のリソース状況、すでに確定しているタスクの量、追加対応にかかる見積もり工数。「来週末までの残工数が〇人日で、現在のタスクで〇人日分が埋まっているため、追加で動かせる工数は〇人日程度」という形で数字にします。
この2つを書き出したとき、差分が見えてきます。その差分が「交渉の余地がある部分」と「変えられない部分」を分ける手がかりになります。
顧客要求を目的に戻す
顧客の要求を「来週末までに〇〇機能を追加してほしい」という表面の言葉のまま受け取ると、「できる・できない」の二択にしかなりません。
「なぜ来週末なのか」「〇〇機能で何を達成したいのか」という目的を確認すると、選択肢が広がることがあります。「来週末の経営会議でデモをしたい」という目的であれば、「全機能ではなくデモに必要な部分のみ先行で対応する」という代替案が浮かびます。
目的を確認することは「断る口実を探す」ことではありません。顧客のビジネス上の目的を理解して、現実的に達成できる方法を一緒に考えることです。
PM自身のコミュニケーション負荷を管理する
板挟み状態の長期化は、PM自身のコミュニケーション負荷が增すことでも起きます。顧客への訪問対応、開発チームへの内容伝達、上司への報告が重なり、PM自身がボトルネックになります。
この状況を改善するには、顧客との会議の準備時間を山にしないことが大切です。アジェンダを文書化し、顧客に事前送付することで、当日の話し内容の盛り込みを防げ、会議の準備負荷を減らせます。
また、開発チームへの情報伝達を橋渡しにしないことも心がけてください。顧客から受けた内容をそのまま開発に渡すのではなく、「顧客が期待すること」と「開発が実現できること」を整理した形で伝えることが、PMの付加価値です。この変換の質が上がると、板挟みの頻度と辛さがこれまでより小さくなります。
板挟み状態を早期に察知するサイン
PMが板挟みになりやすい状況には、事前に察知できるサインがあります。以下のうち2つ以上当てはまる場合は、意識的に対処を始めるタイミングです。
- 顧客から「直接エンジニアに確認してもいいですか？」と言われた
- 開発メンバーが「PMに言っても何も変わらない」という態度を示した
- 週次定例で「それは難しいです」という言葉が連続して出ている
- 自分が中間でメッセージを伝えるだけになっている実感がある
- 顧客の期待と開発の見積もりに毎週ギャップが出ている
これらのサインは、板挟み状態が深刻化する前の「準炎上状態」を示しています。このタイミングで上司やPMOに状況を共有し、第三者の視点を入れることで、PMが一人で抱え込む状態を防げます。板挟みは「個人の調整力の問題」ではなく「プロジェクト構造の問題」であることが多く、構造に働きかけることが最も効果的な対処です。
開発チームの制約を見える化する
開発チームが「限界です」と言っているとき、その限界が何かを具体的にしてください。
「疲れている」ではなく「今週のタスクが〇人日で、残り稼働が〇人日しかない」という数字にします。「技術的に難しい」ではなく「〇〇の実装に最低〇日必要で、テスト込みでは〇日かかる」という見積もりにします。
数字にすることで、「どこかを調整すれば追加対応できるか」という議論が具体的になります。
選択肢として提示する
顧客の目的と開発の制約が整理できたら、顧客に「選択肢」として提示します。
「来週末の期日でデモ用に部分実装する（ただし全機能は〇日以降）」「期日を〇日延ばせば全機能対応できる」「他のタスクと優先順位を入れ替えれば今の期日で対応できる」など、複数の選択肢と、それぞれのトレードオフを示します。
「できません」と言うのではなく「この3つの選択肢から選んでいただけますか」という形にすることで、PMは「現実をきちんと見せてくれる担当者」として機能できます。
PMが抱え込まない相談先
板挟みが長く続いているときは、PMが一人で抱え込んでいることが多いです。
PMO・上司・PL、あるいはプロジェクトの外のメンターなど、「顧客要求と現場制約の調整」を一緒に考えてくれる相談先を持っておいてください。自分一人で解決しようとすることが、疲弊の最大の原因になっていることがあります。
板挟みを繰り返さないための構造改善
板挟みが発生するたびに対処することも重要ですが、同じ板挟みが繰り返される場合は構造的な問題があります。
「顧客が開発チームに直接指示を出している」「要件変更のプロセスが定義されていない」「開発チームの稼働上限が顧客に見えていない」のいずれかが繰り返しの板挟みの原因になっていることが多いです。
PMとして、顧客と開発チームの間に入る役割を担う以上、窓口を一本化することが板挟み対策の基本です。「開発チームへの依頼はPMを通じてください」という合意を顧客と取ることで、仕様変更の流れが整理されます。また、開発チームに直接話が行くと、PMが把握できないままタスクが増えるという問題も防げます。窓口の一本化は、PMにとって責任を集約することでもありますが、混乱を防ぐ最も実効的な手段です。
顧客と開発チームの調整スキルを高めたい方には、炎上予防・立て直しパックがお役に立てます。板挟み状態のPMが実務で使える調整の技術を、体系的に学べます。ITエンジニア向けビジネススキル講座も参考にしてください。