TL;DR
- PMは「進行を妨げてしまう関係者」と向き合う場面に必ず出会う
- 相手を変えようとするより自分の構え方を変える
- 共通する原則は「相手が動きやすい構造を作る」こと
対象読者
- ステークホルダー対応に消耗しているPM
- 「自分の伝え方が悪いのか」と悩んでいるPM
- これからPMになる方
はじめに
PMをやっていると、どうしても噛み合わない関係者に必ず出会います。悪意があるわけではなく本人なりにベストを尽くしています。それでも結果的にプロジェクトが進みづらくなるというパターンです。
本記事では、現場でよく出会う3つのパターンと「PM側ができる現実的な向き合い方」を検討します。
本記事は「相手が悪」という話ではありません。相手にも事情があり構造的にそうなっている場合がほとんどです。そのうえでPMができる工夫を中心に書いています。
相手を変えようとしない
前提として、「他人を変えるのは極めて難しい」のでこの方針で進めようとすると概ね失敗します。
上記の前提があるため「自分の関わり方を変える」しか方法はありません。
これは諦めということではなく、PMとして一番費用対効果が高いアプローチだと考えています。
【壁1】 決断ができない関係者
よくある場面
判断を求めると、「もう少し情報が欲しい」「もう少し検討したい」と返ってくる。これを繰り返すうちに開発工数を多分に使ってしまう
何が起きているか
決断できない人は、「判断の責任を取ることに不安がある」場合がほとんどです。情報が足りないのではなく「決められないから情報を求めている」というのが実態に近いです。
ここで開発リソースを使って質問に回答しても、たいてい別の質問が来ます。経験則から情報量を増やしても決断は生まれません。
PM側ができること
■ 調査の深さに上限を設ける
"〇〇日で調べられる範囲の回答します" と先に宣言してしまいます。リスクとして、決断する側は後の予定が見えていない場合があり、その場合開発側の後続スケジュールが厳しくなります。解決しなさそうな場合は別の案で対応をおすすめします
■ 判断材料を3パターンに絞って提示する
選択肢が多くても人は決められない場合が多いので、A案・B案・C案に推奨案を添えて出します。これが現実的に一番の有効解だと感じています。
■ 決めない場合の影響を明示する
"〇〇日までに決まらないとリリースが○週間後ろ倒しになります"と数字で示す。
あくまでポイントは相手が決断しやすい状況を作ることです。
【壁2】 意見が変わる関係者
よくある場面
ミーティングでA案で進めることに合意したはずが、数日後に「上司と相談した結果、B案にする」という連絡が来る。
何が起きているか
意見が変わること自体は誰にでもあります。問題は「変わる過程が共有されないこと」です。
多くの場合、当人は自分の意見ではなく上司の意見を伝えています。当人の中で消化されないまま降りてきた決定なので、理由を聞いても明確に答えられない、という状況が起きやすいです。
PM側ができること
■ 決定の背景に上司を巻き込む
基本的なことですが、重要な意思決定の場には最初から決裁者を呼ぶ。後出しを構造的に防ぐ構造としてもっとも効果的ですが、予定が取れないことも多々あります。
■ 議事録に「決定事項」と「決定者」を明記する
こちらも基本的ですが、ミーティングなどでの議事録は取りましょう。後から覆そうとしたとき何を覆すのかが共通認識になります。リリースを遅らせる場合に開発側の責任にならないための根拠にもなります。
■ 覆されたときの追加コストを早期に提示する
"再設計するとリリースが〇〇人延期されます"となるべく数字で会話する。感情論を避けるのに有効ですが、代案を求められることが多々あります。
ポイントは意見が変わりにくい構造を作る
【壁3】 言語化が苦手な関係者
よくある場面
要望はあるが、文章にすると要点がぼやける。チャットで何往復しても合意点が見えない。
何が起きているか
言語化が苦手な人は、「頭の中のイメージを言語化する作業に負荷がある」パターンがあります。テキストで内容を深くしようとするとドツボにはまります。
PM側ができること
■ 直接話す場をすぐに設ける
5分の会話が1時間のチャットより速いケースがほとんどです。直接話して言語化に協力しましょう。
■ PM側で要点を仮置きして投げ返す
"○○ということですか？" と仮説で当てる。Yes/Noで返してもらえる質問にすることで相手の言語化負荷が下がります。
■ 議事録を相手の言葉で書く
PMの整理した言葉ではなく相手が言った表現を残すようにしましょう。そのまま残すことで「そんな意図で話していなかった」というのを防ぎ建設的な会話が進みます。
ポイントは面倒でもプロジェクトの成功のために言語化をPMが手伝うことです。
共通する原則
3つの壁に対するアプローチには共通点があります。
それは「相手の能力や性格を変えず相手が動きやすい構造を作る」ことです。
これは前作の「開発者が進めやすくなることであれば、PMは何でもする」と同じ思想です。向き合う相手が開発者か、ステークホルダーか、というだけの違いです。
PMの仕事は調整であり、調整とは「人を変えること」ではなく「構造を整えること」だと考えています。
それでも難しいとき
正直に書くと、上記の工夫を尽くしてもうまくいかないケースはあります。その場合は以下の選択肢が残ります。
■ より上位の決裁者にエスカレーションする
PMだけで抱え込まない。困っている状況を話すだけで有能な上司が解決してくれる場合があります。
■ 役割を再設計する
対応が難しい人の代わりにハブとなる担当者を立てる。ハブとなる方の能力次第ではこれだけで解決します。
■ プロジェクトのスコープを見直す
人ではなく計画の方を動かす。最終手段的なイメージです。
チーム全体が前に進める形を再設計する、という発想が重要です。
おわりに
進まない関係者に対して、「あの人さえいなければ」と思う瞬間は、PMをやっていれば誰にでもあるかと思います。
ただ、その思考では状況は変わりません。「相手も困っている」という前提に立ち、自分の関わり方を設計し直す方が、結果的にプロジェクトの成功確率も上がります。
あわせて読みたい
これは前作の「PMは感謝」とも繋がる話となります。