エンジニアが PM を兼務してわかったこと — 技術とビジネスを繋ぐ視点

開発者として働きながら PM を兼務した経験から、両者の視点を持つことのメリットと難しさを振り返ります。仕様の曖昧さ・優先度判断・ステークホルダーとのコミュニケーションなど、リアルな現場の話を共有します。

きっかけ

スタートアップでエンジニアとして働いていたある日、PM が退職することになりました。人員補充まで時間がかかるという事情から、自分が暫定的に PM を兼務することになりました。最初は「コードを書きながら仕様も決める、一石二鳥じゃないか」と軽く考えていましたが、現実はそう甘くありませんでした。

エンジニアとして仕様書を受け取る立場のとき、「なぜこう決めたのか」と疑問に思うことは多くありました。PM になってみると、その「なぜ」を決めることがいかに難しいかを痛感しました。

ユーザーインタビューをすると、ユーザーは「欲しいもの」は言えても「なぜ欲しいのか」を明確に語れないことが多い。そこから本質的なニーズを抽出し、技術的な制約も考慮しながら仕様に落とし込む作業は、想像以上に高度な判断の連続でした。

プロダクトに関わる全員が「これを作りたい」「あれも必要だ」と言います。PM の仕事は何を作るかを決めることではなく、何を作らないかを決めることだと気づきました。

この「諦める」判断は、エンジニア視点だけでは難しい。ビジネスインパクト・ユーザー価値・技術コストを同時に評価する必要があり、どれか一つの軸だけで判断すると必ずどこかが歪みます。

営業・デザイナー・経営陣、それぞれが異なる言語で話します。エンジニアリングの文脈で「このAPIは設計上難しい」と言っても伝わらない。「ユーザーへの価値を出すのに3ヶ月かかるが、別のアプローチなら1ヶ月で出せる」という翻訳が必要でした。

「これ3日で作れます」「これは2週間かかります」という判断が自分でできるため、ロードマップ策定の精度が上がりました。外部の見積もりに振り回されることがありません。

リファクタリングをビジネス側に説明するとき、「コードが汚い」では説明できません。「このまま放置すると機能追加のたびに1週間余分にかかる。今リファクタすれば半年で回収できる」という形で説明できたのは、両方わかっているからこそでした。

コードを書いている最中に「ちょっと仕様の確認を」と割り込まれると、集中が途切れます。Deep Work が必要なエンジニアリングと、レスポンスが求められる PM 業務は、本質的に相性が悪いと感じました。

「なぜこの機能を先に作ったのか」「あの機能はいつ出るのか」全部自分への質問になります。エンジニアとして実装したものが PMとしての自分の判断ミスだったときのダメージは、普通の2倍でした。

兼務経験を通じて、エンジニアリングとプロダクトマネジメントは相互補完的だと強く感じました。エンジニアが PM の仕事を理解していれば、より良い議論ができる。PM が技術を理解していれば、より現実的な判断ができる。

どちらかのキャリアを歩む人も、もう一方への理解を深めることは長期的に大きな武器になると思います。