エンジニアとPMで変わる、報連相というスキルの使い方

エンジニアとして働く中で、それなりにコミュニケーションは取れているつもりだった。 ところが、機会に恵まれてPMにも挑戦させてもらえることになり、その役割に踏み出した途端、今まで通りのやり方ではまったく噛み合わない瞬間が増えた。

先日、振り返りでPMリーダーから「ミュニケーションや報連相が圧倒的に足りてないよね」と指摘を受け、ロールが変わるだけでこんなにコミュニケーションの性質が変わるのか、と改めて考えるきっかけになった。

エンジニアとしての自分は、まずアウトプットを作り、それを土台に話を進めるのが常だった。設計のたたき台やモックをサッと形にし、それを見ながらメリデメを議論する。自分にとって「報連相」とは、作ったものを共有して調整する行為に近かった。

ところがPMは、そのスタート地点がまったく違う。 いきなりアウトプットを出すのではなく、まずは戦略を分解し、論点を揃え、関係者の前提を合わせる。いわば考え方を共有する時間が必要で、ここを飛ばすと、どれだけアウトプットのスピードがあっても戦術が妥当でなければ手戻りが増えてしまう。

こうした背景が自分の中でも整理しきれていなかったので、エンジニアとPMの「報連相」がどう違うのか、簡単にまとめてみた。

エンジニアとPMの「報連相」の違い

観点	エンジニア	PM
スタイルの起点	設計書やモックを作る	考え方・前提・論点を揃える
共有するもの	ロードマップや設計書、モック	目的・意図・優先順位・前提条件
コミュニケーションの目的	周知・修正・ブラッシュアップ	合意形成・意思決定
タイミング	形が見えてきてから相談	形にする前の段階で“途中の思考”を共有
求められる視点	実装・設計の具体	全体最適・関係者の期待調整
足りないとどう見えるか	仕様理解不足に見える	方針不明瞭・報連相不足に見える

こうして並べてみると、同じ「報連相」という言葉でも、エンジニアとPMではまったく別物として機能しているのがよく分かる。 自分は長らくエンジニア側の感覚に寄っていたので、PMロールに入った途端にズレが出ていたのも納得だ。

振り返ると、自分は「形にするスピード」が早い分、考え方の整理を後回しにしてしまうクセがある。エンジニアロールではその強みがうまく機能していたが、PMロールでは戦略の理解が曖昧なまま形にしてしまうという弱点として現れていた。

とはいえ、早く形にして議論を前に進められるのは、自分にとって大きな武器でもある。 だからこそ、最終的な成果物の制作に入る前の「整えるプロセス」をもっと丁寧に、でも過剰になりすぎないようスムーズに行えるようになりたい。

今後は、エンジニアとPM、また各ロールそれぞれに求められる報連相の“質”を意識しながら、最終的なアウトプットにたどり着くまでのスピードをもっと高めていこうと思う。