「PLとして3年やってきた。来月からはPMだ」——昇格を喜びつつ、何が変わるのかは意外と曖昧、というのが多くのエンジニアの実感です。
PLとPMは、似ているようでまったく別の役割です。技術力をさらに磨き続けると、PMとしては逆に失敗します。本記事では、PLからPMに移行するときに変えるべき5つの考え方を整理します。
PLとPMの違いを「役割」ではなく「思考」で見る
「PLとPMの違い」を組織図やJob Descriptionで見ても、本質はつかめません。本質は 思考の軸 にあります。
| 軸 | PLの思考 | PMの思考 |
|---|---|---|
| 主な仕事 | 技術判断・実装主導 | 判断軸の設計・意思決定 |
| 関心の対象 | 開発チーム内 | 顧客・経営・チーム横断 |
| 成功の定義 | 開発が完了する | QCDが達成され、顧客が満足する |
| 時間の使い方 | 技術検討・コードレビュー | 関係者調整・判断・先回り |
| 意思決定の単位 | 技術選定 | 案件全体の方針 |
この思考の違いを 「変えるべき考え方」 として5軸で見ていきます。
変える1：「自分で解決する」から「誰に解決させるか」へ
PLは技術問題を自分で解決します。難しい設計問題、リファクタリングの判断、性能チューニング——自分の手で動かすことが期待されます。
PMは違います。問題を「自分で解決する」のではなく、 「誰に解決させるか」「どう動いてもらうか」 を考える役割です。
具体例：
- データベース設計の判断 → PLが直接決める / PMはチームのアーキテクトに判断を任せる
- 顧客の追加要望対応 → PLは技術的にどう実装するか考える / PMはやるかやらないかを決める
- メンバーのスキル不足 → PLは自分が指導する / PMは育成計画を作り、誰が指導するか決める
「自分でできるからやる」を続けると、PMの本来の役割（判断と調整）に時間が割けなくなります。
変える2：「答えを出す」から「判断軸を作る」へ
PLは具体的な答えを出すことが期待されます。「この設計でいきましょう」「このフレームワークを使いましょう」と決断するのが仕事です。
PMは個別の答えではなく、 「判断軸」を作ること が求められます。
例：追加要望が来たとき
- PLの思考：「これは技術的に難しいので断る」
- PMの思考：「追加判定の3軸（機能の有無・工数・影響範囲）で評価して、追加と判定。見積を出して顧客判断を仰ぐ」
判断軸があれば、自分が不在のときも組織は動けます。 「自分にしか判断できない状態」を作るのはPLとしては優秀、PMとしては失格 です。
変える3：「技術視点」から「顧客・経営視点」へ
PLは「技術的に正しいか」で判断します。性能、保守性、将来の拡張性——これらは技術的に妥当な軸です。
PMは技術視点だけでは判断できません。 顧客の事業価値、経営の利益、納期、信頼関係 の総合判断が必要です。
例：技術的負債が見えたとき
- PLの思考：「リファクタリングしたい。設計が美しくなる」
- PMの思考：「リファクタリングする利益は何か。納期に間に合うか。顧客に追加コストを請求できるか。今やる価値があるか」
技術的に正しい解と、経営・顧客的に正しい解は 必ずしも一致しません。この乖離を受け入れることが、PMの第一歩です。
変える4：「実行する」から「先回りする」へ
PLは日々のタスク実行が中心です。今日のタスクを完了させ、明日のタスクを準備する——時間軸は「今日と明日」です。
PMは時間軸が長くなります。 3週間後・3か月後を見て、今動く ことが求められます。
- 「3週間後のテスト工程でリソースが足りなくなる」と気づいたら、今アサインを動かす
- 「3か月後に顧客側のキーマンが異動する」と聞いたら、引き継ぎ準備を今始める
- 「半年後の検収時に、検収基準で揉めそう」と感じたら、今のうちに顧客と認識合わせをする
PLが「実行型」だとすれば、PMは 「先回り型」 です。
変える5：「自分の評価」から「組織の評価」へ
PLは自分の技術力で評価されます。難しい問題を解いたか、品質の高いコードを書いたか——自分の成果がそのまま評価です。
PMは違います。 チームが結果を出したか、案件が成功したか で評価されます。自分が頑張ったかどうかは、評価の主軸になりません。
これを受け入れられないと、 「自分は何もしていない」 という焦りが湧きます。PMは目立たない仕事です。先回り・調整・判断は、終わってみないと価値が見えません。
「自分の成果を見せる」より「チームの成果が出る環境を作る」ことに集中することが、PMとしての価値を高めます。
チェックリスト：5つの考え方の切り替え度
- 技術問題を「自分で解決」より「誰に解決させるか」で考えている
- 個別の答えではなく、判断軸（ルール）を作ることに時間を使っている
- 技術視点だけでなく、顧客・経営視点で判断できている
- 3週間後・3か月後のリスクを見て、今動く習慣がある
- 「自分の成果」より「チームの成果」を評価軸にしている
切り替えに3〜6か月かかることを覚悟する
5つの考え方の切り替えは、 書いて分かることと、体に染みつくことは違います。実際に体得するには3〜6か月かかります。
その間、「自分は何をしているんだろう」という不安を抱える時期が必ず来ます。これは正常な過程です。 「目立たない仕事」「人を動かす仕事」 に慣れるまで、自分を責めずに継続することが重要です。
まとめ
PLからPMへの移行は、 スキルの追加 ではなく 思考の転換 です。自分で解決する人から判断軸を作る人へ、技術視点から顧客・経営視点へ、自分の成果からチームの成果へ——この5つの切り替えを意識すれば、PMとしての価値が見えてきます。
PMとしての学習順序をどう組むか整理したい場合は、新任PM向け学習ルート を参考にしてください。受託開発のPM基礎を体系的に学ぶには PJM-101 受託開発のPM基礎 もおすすめです。