🦁

エンジニア出身PMが実践する、開発チームとの効果的なコミュニケーション術

に公開
it
idea

はじめに
こんにちは、近藤洋士です。IT企業でプロダクトマネージャー（PM）をしています。
エンジニアとして約10年働いた後、PMにキャリアチェンジして3年。エンジニア出身だからこそ感じる「PMとエンジニアの間の溝」と、その解決方法について書いてみます。
この記事で伝えたいこと

エンジニアとPMの「共通言語」の作り方
技術的な意思決定へのPMの関わり方
スプリント計画での具体的なコミュニケーション手法
エンジニアから信頼されるPMになるためのポイント

対象読者：

PMに転向したエンジニア
エンジニアと協働するPM
PMとのコミュニケーションに悩むエンジニア

PMとエンジニアの間にある「壁」
PMに転向して最初にぶつかったのが、この壁でした。
よくある失敗パターン
パターン1：ふわっとした要件を投げる
悪い例

PM「ユーザーがもっと使いやすいUIにしたいです」
エンジニア「...具体的には？」

これ、PMになりたての頃の僕です。
良い例

PM「ユーザーインタビューで『検索結果が見づらい』という声が5件ありました。具体的には、検索結果の一覧で商品画像が小さすぎて判断しづらいとのこと。画像サイズを現行の120px×120pxから200px×200pxに変更し、商品名も1行表示から2行表示に変更したいです。ただし、スマホ表示時のパフォーマンス影響が気になるので、技術的な懸念があれば相談させてください」

具体的な数字、理由、懸念点まで伝える。これが大事。
パターン2：技術的な制約を無視した要望
悪い例

PM「来週のリリースまでに、この機能追加できますか？」
エンジニア「...（無理だけど、どう断ろう）」

良い例

PM「この機能、ユーザーからの要望が多いんですが、実装の難易度はどれくらいでしょうか？もし時間がかかるなら、MVP（最小限の機能）だけ先に実装することも検討したいです」

実装の難易度を聞く姿勢が大事。
パターン3：「なぜ？」が伝わらない
悪い例

PM「この画面、レイアウト変更してください」
エンジニア「...なんで？」

良い例

PM「この画面のCVRが業界平均より2%低いんです。ヒートマップ分析で、ユーザーがCTAボタンを見つけづらいことがわかりました。そこで、CTAボタンを画面上部に移動したいと考えています。A/Bテストで効果検証もしたいです」

背景・理由・期待効果を明確に伝える。
僕が実践している5つのコミュニケーション術

  1. 技術的な勉強を続ける
    PMになったからといって、技術の勉強をやめてはいけない。
    僕がやってること

週1回、エンジニアのコードレビューを見学
技術的な議論を聞いて、チームの技術スタックへの理解を深める
新しい技術トレンドをキャッチアップ
Zenn、Qiita、HackerNewsなどで最新情報を追う
月1回、簡単なコードを書く
勘を鈍らせないため。社内ツールの小さな改善とか

完全に理解する必要はないけど、「会話についていける」レベルは維持する。
なぜ必要か
技術的な背景を理解していると、エンジニアとの会話がスムーズになります。
PM「このAPIのレスポンスタイム、ユーザー体験的には200ms以内が理想です。
キャッシュ戦略で対応できそうですか？」
エンジニア「Redis使えば対応できそうです。ただ、インフラコスト増えますが...」
PM「ユーザー数考えると月5万円くらいですかね。ROI考えると十分ペイすると思います」
こういう会話ができるかどうかで、信頼関係が変わります。
2. WHYとWHATを明確に、HOWは任せる
これ、めちゃくちゃ大事。
役割分担を明確にする
役割内容担当WHYなぜこの機能が必要かPMWHAT何を実現したいかPMHOWどう実装するかエンジニア
PMの仕事は、WHYとWHATを明確にすること。HOWはエンジニアの専門領域です。
実例：検索機能の改善
僕（PM）が提示した内容
markdown## 背景（WHY）

  • 現在の検索機能の利用率が全ユーザーの15%に留まっている
  • カスタマーサポートに「検索しても欲しい商品が見つからない」という問い合わせが月20件
  • 検索からのCVRが、他の導線より10%低い

実現したいこと（WHAT）

  • 検索精度の向上（曖昧検索、同義語対応）
  • 検索結果のソート機能（価格順、人気順、新着順）
  • 検索履歴の保存とサジェスト機能

制約条件

  • 開発期間：2スプリント（4週間）
  • 予算：追加コストは月3万円以内
  • パフォーマンス：検索レスポンスタイム500ms以内

成功指標

  • 検索機能の利用率を15%→25%に向上
  • 検索からのCVRを10%向上
  • 「検索が使いづらい」という問い合わせを50%削減
    エンジニアからの提案（HOW）
    markdown## 技術的なアプローチ

  1. Elasticsearchの導入を検討

    • メリット：高速な全文検索、同義語辞書の設定が容易
    • デメリット：インフラコスト増（月2.5万円程度）

  2. 既存のMySQLでの対応

    • メリット：追加コストなし
    • デメリット：パフォーマンスに懸念、同義語対応が困難

→ Elasticsearch導入を推奨
このように、PMが「何を実現したいか」を明確にすれば、エンジニアは最適な技術的アプローチを提案してくれます。
3. スプリント計画での工夫
スクラム開発での具体的なコミュニケーション方法です。
スプリントプランニング前の準備
僕は、プランニングの2日前に以下を準備します。

  1. ユーザーストーリーの作成
    markdown## ユーザーストーリー
    【誰が】ECサイトで商品を探すユーザーが
    【何をしたい】曖昧なキーワードでも目的の商品を見つけたい
    【なぜ】正確な商品名がわからなくても、簡単に検索できるようにするため

受け入れ条件

  • 「スニーカー」と検索したら「運動靴」もヒットする
  • 「ノートPC」と検索したら「ノートパソコン」もヒットする
  • ひらがな・カタカナ・漢字の表記揺れに対応
  • レスポンスタイムは500ms以内
  • 検索結果がゼロ件の場合、類似商品を提案する
  1. 優先順位の明確化
    優先度機能ユーザー価値ビジネス影響High同義語検索CVR +10%期待売上 +5%期待Mid検索履歴保存UX向上再訪率 +3%LowサジェストUX向上直接影響小
  2. 参考資料の準備

ユーザーインタビュー動画
競合サービスの分析
デザインモックアップ
データ分析結果

スプリントプランニング当日
チームでの会話例：
PM「今回は検索機能の改善を優先したいです。背景を説明させてください」
（背景・データ・ユーザーの声を共有）

エンジニアA「なるほど。技術的には、Elasticsearch導入が良さそうですね」

PM「そうですね。ただ、MVP（最小限の機能）だけ先にリリースして、
効果検証してから本格実装というのはどうでしょう？」

エンジニアB「いいですね。まずは同義語検索だけ実装して、
検索履歴とサジェストは次スプリントでも良さそう」

PM「完璧です。じゃあ、今スプリントは同義語検索に集中しましょう。
ストーリーポイントはどれくらいになりそうですか？」
ポイント：

PMが一方的に決めない
エンジニアの意見を聞く
一緒に優先順位を決める

  1. デイリースタンドアップの活用
    毎朝15分のスタンドアップ。これを有効活用してます。
    僕が意識してること
  2. ブロッカーの早期発見
    エンジニア「昨日はAPIの実装を進めました。
    今日は認証部分に着手します。
    ブロッカーは、外部API仕様書がまだ届いてないことです」

PM「了解です。今日の午前中に先方に催促します。
それまでは、モックデータで開発進めてもらえますか？」
2. 他チームとの調整
エンジニア「今日、インフラチームとMTGがあります。
Elasticsearch環境の構築について相談します」

PM「ありがとうございます。もし何か懸念点あれば共有してください。
必要なら私も同席します」
3. スコープ調整の判断
エンジニア「検索履歴の実装、予想より時間かかってます。
今スプリント内の完了が厳しいかもです」

PM「わかりました。それなら、基本機能だけ今スプリントで、
フィルタリング機能は次に回しましょう。
今日の昼に詳細相談させてください」
5. レトロスペクティブでの振り返り
スプリント終了後の振り返り。ここでの学びが次に活きます。
僕が大事にしてる質問
エンジニアへの質問

PMからの情報提供で、足りなかったものはありますか？
実装で困ったこと・悩んだことはありますか？
次のスプリントで改善してほしいことはありますか？

自分への質問

要件定義で曖昧だった部分はなかったか？
エンジニアの懸念を無視していなかったか？
技術的な議論についていけていたか？

エンジニアから信頼されるPMになるために
3年間PMをやって、エンジニアから「この人と働きやすい」と思われるために大事だと感じたこと。

  1. 技術をリスペクトする
    「実装は簡単でしょ？」「すぐできるよね？」
    こういう態度は絶対NG。実装には時間がかかるし、見えない複雑さがある。それを理解し、リスペクトする。
  2. 失敗を認める
    要件の見落とし、スコープの見誤り、優先度判断のミス。PMも失敗します。
    大事なのは、それを認めて、改善すること。
    「今回の機能、要件定義が不十分でしたね。申し訳ないです。
    次は事前にもっと詳細まで詰めてから相談します」
    こういう姿勢が、信頼関係を作ります。
  3. エンジニアの意見を聞く
    PMが全て決めるんじゃなく、エンジニアの意見を聞く。
    特に、技術的な実装方法、リファクタリングのタイミング、技術的負債の返済。こういう話は、エンジニアの方が詳しい。
    PM「この機能、実装的にどう思いますか？」
    エンジニア「実は、今のコードベースだと結構複雑になりそうです。
    先に〇〇のリファクタリングをした方が、長期的には良いかと」
    PM「なるほど。じゃあ今スプリントでリファクタリングして、
    次スプリントで機能実装にしましょう」
  4. 感謝を伝える
    当たり前だけど、意外と忘れがち。
    「今スプリント、難しい実装お疲れさまでした。
    おかげでユーザーからの評価も上がってます。ありがとう」
    こういう一言が、チームの雰囲気を作ります。
    まとめ
    PMとエンジニアの関係は、「発注者と実装者」じゃなく、「一緒にプロダクトを作るチーム」です。
    エンジニア出身のPMとして、僕が大事にしてるのは：

技術を理解する努力を続ける
WHYとWHATを明確に、HOWは任せる
スプリント計画で丁寧にコミュニケーション
デイリーでのブロッカー解消
レトロスペクティブでの継続的改善

完璧なPMなんていません。僕もまだまだ勉強中です。
でも、エンジニアをリスペクトし、一緒により良いプロダクトを作ろうとする姿勢があれば、きっと良いチームが作れるはず。

この記事が役に立ったら、いいね・コメントいただけると嬉しいです！
PMやチーム開発についての質問・相談も大歓迎です。

Discussion