すべての記事

開発チームから信頼されるテクニカルPMのコミュニケーション習慣7つ

開発チームから信頼されるテクニカルPMのコミュニケーション習慣7つ

開発チームから信頼されるテクニカルPMのコミュニケーション習慣7つ
── 嫌われる振る舞いも、正直に書いておく

テクニカルPMは「権限」ではなく「信頼」で動く職種。同じ依頼でも「このPMが言うならやろう」と思われるか、「また面倒な依頼が来た」と思われるか──その差は日々のコミュニケーション習慣で決まる。


導入:テクニカルPMは「権限」ではなく「信頼」で動く職種

テクニカルPMは、指示命令でチームを動かす仕事ではない。
現場で本当に効くのは、役職でも権限でもなく、信頼残高だ。

同じ依頼でも、

「このPMが言うならやろう」
「また面倒な依頼が来た」

どちらになるかで、チームの速度も空気もまったく変わる。

そしてその差は、特別なスキルではなく、
日々のコミュニケーション習慣で決まる。

この記事では、開発チーム視点で
「このPMは助かる」「このPMと仕事したい」
と思われる振る舞いを、遠慮なく言語化する。


信頼されるテクニカルPMのコミュニケーション習慣7つ

習慣1 仕様・優先度の「なぜ」をセットで伝える

開発チームが最も困るのは、
「これお願いします」だけが飛んでくること。

  • なぜ今やるのか
  • やらないと何が困るのか
  • 誰が助かるのか

ここまでセットで伝えると、
チームは自分たちで判断できる状態になる。

理由を語らないPMほど、自分が一番忙しくなる。

習慣2 「わからない」を即答できる

分かったふりは、ほぼ100%バレる。

信頼されるPMは、

「今は分からない。調べてから答える」

を自然に言える。

不確実性を隠さず、
前提条件として扱う姿勢があると、議論の質が一気に上がる。

習慣3 外圧を"そのまま横流ししない"

営業・経営・顧客。
外からの圧は必ず飛んでくる。

信頼されるPMは、一度自分で受け止めてから整理する。

  • 本当に求められていること
  • 無茶な部分
  • 交渉可能な部分

そして必要なら、
チームの盾として前に出る。

これができるPMは、圧倒的に信頼される。

習慣4 タスクではなく「完成イメージ」を合わせる

チケットが細かくても、
完成形のイメージがズレていれば手戻りは起きる。

信頼されるPMは、必ず共有する。

  • 画面イメージ
  • 簡単なフロー図
  • 雑なモック

ゴールの絵を合わせるだけで、無駄な議論は激減する。

習慣5 ネガティブ情報を"早く・正直に"出す

遅延・仕様変更・リスク。
嫌な話ほど、早く出す。

目的は「怒られないこと」ではなく、
被害を最小化すること。

この姿勢が一貫しているPMは、
トラブル時ほどチームから協力される。

習慣6 定例では"感情"と"事実"を分離する

問題が起きたとき、
「誰が悪いか」に話が流れると場は一気に冷える。

信頼されるPMは、常にこの3点に集中する。

  • 事実は何か
  • 影響は何か
  • 次に何を打つか

個人攻撃ではなく、
プロセスと前提を一緒に見直す姿勢があると、
チームは防御ではなく改善に頭を使える。

習慣7 日常的に"小さなフィードバック"を返す

「助かりました」だけでは弱い。

  • どこが良かったのか
  • なぜ助かったのか

これを具体的に言葉にする。

1on1でも、雑談でもいい。
この積み重ねが、
"このPMはちゃんと見ている"という信頼に変わる。


逆に嫌われるテクニカルPMの振る舞い

NG よくあるNGパターン

  • 「上が言ってるから」で理由を語らない
  • 技術を理解していないのに実装方針に口を出す
  • トラブル時、外では他人事・中では丸投げ
  • 表では柔らかいが、裏で勝手に約束を増やす

一つひとつは小さくても、
積み上がると信用ゼロPMになる。

注意 善意でも誤解される行動

  • 気を利かせたつもりの仕様変更を、事前相談なしで進める
  • スケジュール優先の言い方で、品質軽視に聞こえる

言い方ひとつで印象は激変する。


セルフチェック:信頼されるPMへの最短ルート

  • 最近のチャットに「なぜ」がどれだけ書かれているか
  • チームに「話しやすさ」を匿名で聞いてみる
  • スプリントごとに、成功と失敗のコミュニケーションを1つずつ振り返る

これだけでも、PMとしての質は確実に上がる。


実例:一言で空気が変わった瞬間

炎上しかけた案件で、PMの言葉が変わっただけで流れが変わった。

Before:

「この仕様、急ぎでやってください」

After:

「この機能、今月入れないと顧客の業務が止まる。
ただ、やり方は任せたい。リスクだけ教えてほしい。」

これだけで、
開発側の反応は「無理です」から「ここまでならできます」に変わった。

コミュニケーションはスキルではなく、習慣だ。


結論:信頼されるPMは、空気を作る

テクニカルPMの仕事は、正解を言い当てることではない。

チームが安心して正解を探せる空気を作ること。

そのための言葉の選び方、距離の取り方、一歩前に出る勇気。
それが積み重なったとき、チームは自然とこう思う。

「このPMとなら、次もやりたい。」