エンジニア経験がPMで武器になる人、ならない人──実装力の次に見られているもの

エンジニア経験がある人がPMになると強い。

そう言われることは多いです。
たしかに、技術が分かるPMは頼もしく見えます。
会話の解像度も高いし、現場の苦しさも分かる。
見積の無理も、仕様の危うさも、非機能の怖さも、感覚としてつかみやすい。

でも、現実はそこまで単純ではありません。

実装経験が長い人でも、PMになった途端に評価が伸びないことがあります。
むしろ、技術が分かるはずなのに、なぜか案件が前に進まない。
メンバーとの会話はできるのに、顧客との認識差が埋まらない。
正しいことを言っているはずなのに、会議が長くなる。
自分が入るほど整理されるどころか、逆に周囲が動きにくくなる。

この違いは、能力の有無だけでは説明できません。

今日は、エンジニア経験がPMで武器になる人と、そうならない人の差を整理してみます。
僕が思うに、分岐点は実装力そのものではなく、その実装経験を何に変換して使っているかです。

実装力は土台だが、それだけでは評価されない

まず前提として、実装経験は無駄ではありません。
むしろ土台としてかなり強いです。

仕様の曖昧さに早く気づける。
無理なスケジュールに違和感を持てる。
障害の再発ポイントを想像できる。
チームがどこで詰まりやすいかも読める。

ここまでは、たしかに強みです。

ただ、PMとして見られているのは、詳しい人かどうかだけではありません。
もっと言えば、技術が分かること自体は、PMの評価の入口にすぎません。

PMで本当に見られているのは、技術を使って何を前に進められるかです。

• 論点を切れるか

• 優先順位を通せるか

• 認識差を埋められるか

• 関係者の判断を前に進められるか

• リスクを早く言語化できるか

つまり、作る力より、進める力です。

ここを取り違えると、実装経験はあるのにPMとしては強く見えない、ということが起きます。

武器になる人は、技術を論点整理に変換している

エンジニア経験がPMで武器になる人は、技術を知識として持っているだけではありません。
その知識を、関係者が判断できる形に変換しています。

たとえば、会議で仕様がふわっとしているとき。
武器になる人は、技術的に正しい説明を延々としません。
そうではなく、今決めるべきことと、まだ決めなくていいことを切り分けます。

今この場で決めないと後工程で手戻りになる点は何か。
逆に、今は幅を持たせておいても問題ない点は何か。
どの選択肢が、コスト・納期・品質のどこに効くのか。

この整理ができると、場が進みます。

現場で評価されるPMは、知っている人ではなく、絞れる人です。
選択肢を増やすより、判断の土台を作れる人のほうが強い。

エンジニア経験が効くのは、ここです。
技術の深さがあるからこそ、曖昧な会話を具体化できる。
でも、その価値は技術説明の長さではなく、論点整理の精度として出るべきです。

武器になる人は、優先順位を通せる

もう一つ大きいのは、優先順位の付け方です。

実装経験がある人は、現場の苦労が分かるので、全部ちゃんとやりたくなります。
品質も守りたい。
運用も考えたい。
保守性も気になる。
セキュリティも落としたくない。

その感覚自体は正しいです。
ただ、PMの仕事は、全部を同時に守ることではありません。
限られた条件の中で、何を先に守るかを決めることです。

ここで差が出ます。

武器になる人は、技術的に気になることを全部並べるのではなく、今この案件で絶対に落とせないものを通します。
たとえば、性能課題よりもまず受け入れ条件の合意を優先する。
運用改善よりも、まず責任分界を固める。
理想の設計よりも、今は変更管理のルールを置く。

この優先順位を、現場にも顧客にも伝わる言葉で通せる人は強いです。

逆に、武器にならない人は、技術的に正しい論点を全部同じ重さで出してしまう。
すると、場に情報は増えるのに、判断は進まない。
PMとしては、詳しいが収束しない人になってしまいます。

武器にならない人は、実装目線の正しさで押し切ろうとする

ここはかなり重要です。

エンジニアとして優秀だった人ほど、PMで一度つまずくことがあります。
なぜなら、実装の世界で評価された正しさと、PMで評価される正しさは少し違うからです。

実装では、正解に近い案を出せることが強みになります。
設計の筋が通っている。
レビューで穴を見つけられる。
不具合の原因に早くたどり着ける。
これは強い。

でも、PMでは、最初から答えを持ちすぎると逆に危ういことがあります。

顧客がまだ腹落ちしていない。
メンバー間の認識も揃っていない。
意思決定者も論点を理解しきっていない。
その段階で、正しい答えを一人で持ってしまうと、周囲は置いていかれます。

するとどうなるか。

PM本人は、こんなに合理的なのになぜ進まないのか、と感じる。
周囲は、言っていることは正しそうだが、自分たちで決めた感覚がない、と感じる。
結果として、正しいのに進まない状態が起きます。

PMで必要なのは、答えを出す力だけではありません。
答えに至るための合意の道筋を作る力です。

ここが、エンジニア経験が武器になる人と、ならない人の決定的な差だと僕は思っています。

武器にならない人は、自分で持ちすぎる

もう一つの落とし穴は、自分で持ちすぎることです。

技術が分かるPMは、問題を見つけるのも早いし、対処の方向性も見えやすい。
だからこそ、自分で整理し、自分で判断し、自分で埋めたくなります。

でも、それをやりすぎると、組織としては弱くなります。

メンバーは考えなくなる。
相談は全部その人に集まる。
判断待ちが増える。
その人がいないと止まる。

短期では回るかもしれません。
ただ、中長期では確実に詰まります。
そして、その詰まりはしばしば、頼れるPMという評価の裏側で進行します。

PMで見られているのは、自分が何問解けるかではありません。
チームとして何を回せるようにしたかです。

実装経験を活かすなら、答えを持つ方向ではなく、判断可能な状態を増やす方向に使ったほうがいい。
ここに変換できると、技術知識は個人芸ではなく、案件推進の武器になります。

では、実装経験をどう変換すればいいのか

僕なら、次の3つを意識します。

1. 技術知識を説明ではなく判断材料にする

詳しく説明する前に、何を決めるための情報かを先に置く。
この仕様差は工数にどう効くのか。
この選択は運用負荷にどう跳ねるのか。
この設計は将来変更にどれだけ効くのか。

技術を語るのではなく、判断に変換する。
これだけで、同じ知識でも価値の見え方は大きく変わります。

2. 自分の頭の中の論点を、人が選べる形に分ける

技術者の頭の中ではつながって見えていることも、非技術側には一気に入ってきません。
だから、論点は分けたほうがいい。

今決めること。
後で決めること。
決めないと危ないこと。
好みの問題で済むこと。

この分け方ができるPMは強いです。
実装経験は、論点の危険度を見抜く材料として使うべきです。

3. 正しさより、認識差の解消を優先する

場が止まる理由の多くは、能力不足より認識差です。
言葉の定義がズレている。
期待値がズレている。
責任の置き方がズレている。
完了条件がズレている。

実装経験がある人は、そのズレを見つけやすい。
だからこそ、自分の正しさを出すより先に、どこがズレているかを整える。
この順番のほうが、PMとしてははるかに効きます。

実装力の次に見られているもの

結局、PMで見られているのは何か。

僕は、変換力だと思っています。

• 技術を、判断材料に変換できるか

• 詳しさを、論点整理に変換できるか

• 不安を、優先順位に変換できるか

• 個人の答えを、チームの前進に変換できるか

実装経験そのものは、たしかに強いです。
でも、それは持っているだけでは武器にならない。
武器になるのは、その経験を使って、人と仕事を前に進められるときです。

PMに移ったのに、思ったほど評価が伸びない。
技術は分かるのに、なぜか案件が前に進まない。
そんな違和感があるなら、足りないのは知識量ではないかもしれません。

もしかすると今、見られているのは、技術をどれだけ知っているかではなく、技術をどう収束に使っているかです。

あなたは技術を、説明のために使っていますか。
それとも、前に進めるために使っていますか。

次に読む：

はじめての方へ：

マガジンの紹介：

IT業界の「技術×キャリア×整える」を束ねるマガジンを公開中です！
ビジネスや心と体を整える良記事が集まってきていますので、
是非、覗いてみてくださいね。
記事は全て無料記事のみです。
気に入って頂けたらマガジンのフォローもよろしくお願いします！
共同マガジンに参加希望の方も募集中です！

＜PR＞

次のキャリアを考えたい方へ。
求人サイトGreenを応援しています。