発注者との温度差を埋める（受注者側PM向け）
受注者側のPMをしていると、こんな経験はないでしょうか。定例会議では「順調です」と伝え、相手も「わかりました」と言っていた。それなのに、終盤になって「そんな話は聞いていない」「これでは使えない」と言われてしまう。
これは、どちらかが嘘をついていたから起きるわけではありません。同じ会議に出ていても、発注者と受注者では見ているものが違うためです。その差を「温度差」と呼びます。温度差は放っておくと必ず広がります。埋めるのはPMの仕事です。
■ 発注者と受注者では、何が違うのか
大きく3つの場面でズレます。
■ ズレ1：進捗の「時間軸」が違う
受注者PMは、工程表のタスクが終わったかどうかで進捗を見ます。「設計80%完了」「単体テスト消化率65%」といった言い方です。一方、発注者が知りたいのは「いつから自分たちの業務が変わるのか」です。設計が80%終わったと聞いても、それが自分にとって何を意味するのかは伝わりません。
埋め方はシンプルで、進捗を「工程の％」ではなく「業務としてできるようになったこと」で言い換えて報告することです。
×「基本設計80%完了」
○「受注入力と在庫照会の画面は固まりました。残るは請求まわりで、来週の打ち合わせで決めたいです」
言い換える作業自体が、PMにとって「本当に進んでいるか」の点検にもなります。
■ ズレ2：品質の「合格ライン」が違う
受注者側は、仕様どおりに動くかどうかで品質を判断します。バグ件数やテスト消化率が指標になります。ところが発注者は「自分の業務が回るかどうか」で判断します。仕様どおりに動いていても、実際の伝票が1日500件流れる現場で画面遷移が多すぎれば「使えない」と言われます。
これを防ぐには、テスト工程まで待たないことです。設計の早い段階で、実際に使う人に画面や帳票のイメージを見てもらい、「この操作を1日◯回やることになりますが、大丈夫ですか」と具体的な使い方で確認します。プロトタイプや画面イメージを1枚出すだけでも、後戻りは大きく減ります。
■ ズレ3：変更の「重さ」が違う
発注者にとっての「ちょっとした変更」は、悪気のある要求ではありません。単に、それがどれくらいの作業量なのかを知らないだけです。逆に受注者PMには、1件の変更が工数と納期に直結することが見えています。
ここで「できません」と先に言ってしまうと、協力的でない相手だと受け取られます。順番を変えて、断る前に影響を数字で見せます。
対応した場合、追加で何人日かかるか
納期は何日ずれるか。ずらさないなら何を後ろに回すか
費用はどう変わるか
この3点をそろえて出すと、判断は発注者の側に返ります。「やらない」と決めるのが相手であれば、後から蒸し返されることもありません。
■ 悪い知らせを出す場を、あらかじめ作っておく
温度差が一気に開くのは、悪い情報の伝達が遅れたときです。とはいえ「悪い話があります」と切り出すのは誰にとっても気が重いものです。
そこで、定例の議題に「気になっていること」という枠を最初から入れておきます。まだ問題になっていない段階の懸念を毎回1つか2つ出す習慣ができると、本当に悪い知らせが出たときも「いつもの枠」として自然に共有できます。
■ 発注者側にも「決める人」と「決める日」を持ってもらう
回答待ちが続いてスケジュールが遅れたとき、受注者PMが自分で抱え込んでも解決しません。プロジェクトの最初に、発注者側の意思決定の形を確認しておきます。
誰が決めるのか（担当者か、その上の部門長か）
いつ決められるのか（次の部内会議は何曜日か）
決まらなかったときは、いつまでに誰に上げるのか
これを決めておくと、遅れが出たときに「催促」ではなく「事前に合意したルールの確認」として話せます。
■ まとめ
温度差は、相手の理解が足りないから生まれるのではありません。立場が違えば見えるものが違う、というだけのことです。受注者側PMにできるのは、相手の側から見た言葉に翻訳して伝えること、そして判断に必要な材料を先に渡すことです。
「伝えた」ではなく「伝わった」を確認するところまでが、PMのコミュニケーションの仕事だと考えておくとよいでしょう。