「コードを書くのが評価されて、気づいたらPMを任されていた」——これは、多くのエンジニアが経験するキャリアの転換点です。

25年以上、プログラマーとしてキャリアをスタートし、その後プレイングマネージャーとして最大20名の社員と70名のパートナーを率いる立場になりました。技術者としての評価が、そのままマネジメントの評価につながるわけではないという現実に、当初は何度も直面しました。この記事では、エンジニアからPMになる過程で直面した変化と、それにどう向き合ってきたかをお伝えします。

エンジニアとPMでは、「正解」の出し方がまったく違う

エンジニアの仕事は、多くの場合、技術的に「動くか、動かないか」「正しいか、正しくないか」という、比較的明確な基準で評価されます。優れたコードを書けば、その品質は他のエンジニアが見ても分かりやすく、努力の方向性を見失いにくい仕事です。

一方、PMの仕事には、この種の明確な正解がほとんどありません。予算、納期、品質、チームの状態、顧客の要望——複数の要素の間でバランスを取り続けることが求められ、「これが唯一の正解」という状態は存在しません。この違いに戸惑い、PMになりたての頃は、エンジニア時代の感覚のまま「正しい答え」を探そうとして、かえって身動きが取れなくなっていた時期がありました。

エンジニアからPMになって、変わった3つのこと

1. 「自分が最速で解決する」から「チームが最速で解決できるようにする」へ

エンジニア時代は、目の前の課題を自分の手で解決することに、大きな達成感を感じていました。しかし、PMという立場になると、自分一人が速く動くことよりも、チーム全体がスムーズに動ける状態を作ることの方が、はるかに大きな成果につながります。

この意識の転換に苦労した時期がありました。自分でやった方が速いと分かっている作業でも、あえてメンバーに任せ、育成の機会として使うという判断が、当初はなかなかできませんでした。「自分が手を動かさない」ことに、生産性を落としているような感覚があったためです。しかし、チーム規模が大きくなるにつれて、この考え方を変えない限り、組織全体の成長が頭打ちになることを痛感しました。

2. 「技術的に正しいか」から「事業として妥当か」への視点の広がり

エンジニアとして技術力を磨いてきた立場からすると、技術的に美しい設計や、拡張性の高い実装にこだわりたくなる場面が多くあります。しかし、PMという立場では、その技術的なこだわりが、予算やスケジュール、事業のフェーズに見合っているかを常に問い直す必要があります。

技術的には理想的でも、今のプロジェクトの状況では過剰investmentになる、という判断を下さなければならない場面が何度もありました。エンジニアとしての誇りと、PMとしての現実的な判断のバランスを取ることは、今でも簡単なことではないと感じています。

3. 「自分の理解」から「相手に伝わる説明」への転換

エンジニア同士のコミュニケーションでは、専門用語や技術的な前提を共有した状態で会話が進みます。しかし、PMとして顧客や経営層、他部署と話す場面では、同じ説明の仕方はまったく通用しません。

技術的な内容を、相手の立場や知識レベルに合わせて言い換える力は、エンジニア時代にはほとんど意識してこなかったスキルでした。この力を磨くために、技術的な説明をする前に、「相手は何を知っていて、何を知らないか」を必ず考えてから話す習慣をつけるようにしました。

エンジニア出身だからこそ、PMとして活きること

視点や求められる能力は大きく変わりますが、エンジニアとしての経験がPMの仕事にまったく無駄になるわけではありません。むしろ、エンジニア出身のPMだからこそ発揮できる強みもあります。

1. 実現可能性を、技術的な裏付けを持って判断できる

顧客や経営層からの要望に対して、「技術的にどのくらいの難易度か」「どこにリスクが潜んでいるか」を、自分の経験に基づいて判断できることは、大きな強みです。技術を知らないPMが、実現困難な約束をしてしまい、後から現場が苦しむというケースは少なくありません。

2. エンジニアの言葉と、事業側の言葉を"翻訳"できる

エンジニアの技術的な懸念を、事業側に分かる言葉で伝え、逆に事業側の要望を、エンジニアが納得できる形で伝える——この双方向の"翻訳"は、両方の言葉を理解しているエンジニア出身のPMだからこそできる役割です。

3. 現場の負荷感を、実感を持って想像できる

無理なスケジュールがエンジニアにどれほどの負荷をかけるか、その感覚を実際に経験してきているからこそ、現実的なスケジュールを組む判断ができます。この感覚は、現場を経験したことのないPMには持ちにくいものです。

これからPMを目指すエンジニアへ

エンジニアからPMになることは、単なる役職の変化ではなく、評価基準や求められる能力そのものが根本から変わる転換です。技術力の延長線上にPMの能力があるわけではなく、まったく別の筋肉を鍛える必要があると捉えておくと、戸惑いを減らせると思います。

一方で、これまで培った技術的な視点は、PMになったあとも確実に武器になります。技術を手放すのではなく、技術者としての経験を、より広い視野で活かす立場に移っていく——そう捉えることが、この転換をスムーズに進めるための助けになると感じています。

まとめ

エンジニアからPMになる過程で直面した変化は、次の3つに整理できます。

  • 「自分が最速で解決する」から「チームが最速で解決できるようにする」への意識転換
  • 「技術的に正しいか」だけでなく「事業として妥当か」を問う視点の広がり
  • 専門知識を前提にした説明から、相手に合わせた"翻訳"への転換

一方で、実現可能性の判断力、事業側との"翻訳"能力、現場感覚に基づいたスケジュール感といった強みは、エンジニア出身のPMだからこそ発揮できるものです。役割が変わっても、これまでの経験は無駄にならない——この視点を持てるかどうかが、エンジニアからPMへの転換をうまく乗り越えるための、一つの鍵になると感じています。