エンジニアがPM・PLになるまで——指示待ちマインドを抜け出すまでの話

はじめに——この記事で伝えたいこと

国内大手メーカー系SIerに新卒で入社して、最初の数年間は「作る側」のエンジニアとして働いていました。3年目のある時に「チームをまとめてみろ」と言われ、PL（プロジェクトリーダー）になりました。

当時何に苦しんだのかは、今となれば一言で言えます。 「エンジニアのままPLをやろうとした」 こと、それに尽きます。

当時は整理できていませんでしたが、最近、若手の後輩が同じところで詰まっているのを見て、「これは自分がつまずいたポイントと全く同じだ」と気づき、この記事を書くことにしました。

この記事で伝えたいこと：

• エンジニアからPLになる時に最初につまずく「指示待ちマインド」の正体
• なぜエンジニアとして優秀な人ほどこの壁にぶつかりやすいのか
• 自分がどうやって乗り越えたか（体験談ベース）

PL・PMへの移行を控えているエンジニアの方や、移行したばかりで違和感を感じている方の参考になれば嬉しいです。

---

まず「PL」と「PM」の違いを整理する

この記事では2つの用語を使い分けます。

• PL（プロジェクトリーダー）：チームの実行責任者。メンバーへの指示・進捗管理・技術的問題の解決が主な役割。
• PM（プロジェクトマネージャー）：プロジェクト全体の計画責任者。ステークホルダー管理・スコープ/リスク/予算管理まで担う。PLの上位ポジション。

私が3年目に任されたのはPLです。小さなチームを束ねる役割で、PMが立てた計画のもとで実行を動かす立場でした。その後、経験を積んでPMへと移行しています。この記事で語る「失敗」は、PL移行直後の話です。

---

最初の3年間——「作る側」の時代

入社から最初の6ヶ月は研修でした。その後プロジェクトにアサインされ、行政系システムのテスト業務や製造業向けパッケージシステムのカスタマイズを担当しました。

この頃の仕事は「誰かが決めたことを実装・検証する」形です。仕様書を読み、コードを書き、テストして、レビューをもらう。そのサイクルを繰り返す毎日でした。

言い換えれば「設計図を受け取って動く」働き方です。誰かがタスクを整理してくれていて、自分はそれをこなす。この感覚が3年間で深く染み付いていました。

---

3年目、PLになった

私が勤務している大手SIerでは、おおむね3〜5年目でPLへの移行が起きることが多いです。私の場合は3年目に「小さいチームをまとめてみろ」と言われました。

そのプロジェクトには、10年以上のキャリアを持つベテランが前任者としていました。引き継ぎを受けながらPLを引き継ぐ形でしたが、正直に言えばプレッシャーしかありませんでした。そのベテランがやっていたことの全体像が、自分にはまったく見えていなかったからです。

---

一番の失敗——「設計図を受け取る側」のままPLになった

情報収集を「待っていた」

PLになって最初に直面したのは、「誰も自分にタスクを振ってくれない」という現実でした。

エンジニア時代は誰かが「次はこれをやってください」と言ってくれていました。PLになった瞬間、それがなくなります。当たり前のことですが、当時の自分にはその感覚がまったくありませんでした。

前任者からどこまで引き継ぎを受ければいいのか、関係者に何を確認すればいいのか、どのドキュメントを読めば全体像がつかめるのか——こういった段取りを、誰かがやってくれると思っていたのです。

結果として、プロジェクトの状況を把握するのに必要以上の時間がかかりました。チームメンバーへの指示も後手に回り、「PLが全体像を持っていない」という状態が続きました。

「タスク構造を自分で作る」という発想がなかった

エンジニア時代は、やるべきことが誰かによって整理された状態で自分に渡ってきていました。PLになると、その整理を自分がしなければなりません。「何を・誰に・いつまでに」というタスク構造を一から設計する仕事です。

しかし当時の自分には、「タスク構造を自分で作る」という発想そのものがありませんでした。誰かから仕事が降ってくるのを待ちながら、目の前に見えているものだけ対処する——その繰り返しでした。

これがエンジニアとPLの最大の違いだと思います。エンジニアは設計図を受け取って動く。PLは設計図を自分で描いて人を動かす。この切り替えができていないまま動こうとしたことが、当時の最大の失敗でした。

---

厳しい先輩メンターに言われて変わったこと

OJTについてくれた先輩メンターはかなり厳しい方で、「なんで自分で調べてから聞かないんだ」「まず自分で全体像を整理してこい」という指摘を何度も受けました。

当時は正直「厳しいな」と感じていましたが、今振り返ると言っていることは完全に正しかったです。先輩から学んだことを言語化すると、次の2つに集約されます。

① 情報収集は取りに行くもの

前任者・関係者・ベテランのパートナー（下請け）——誰に何を聞けば全体像がつかめるかを考えて、自分から動くこと。「誰かが教えてくれるはず」という待ちの姿勢は、PLになった瞬間に機能しなくなります。

② 細かく指示するより知恵を借りる

経験豊富なパートナーに対しては「こうしてください」という細かい作業指示より、「この問題についてどう思いますか」というオープンな問いかけの方が良い成果物につながります。PLになりたての頃は「細かく指示しなければ動いてくれない」と思い込んでいましたが、それは自分が全体像を持てていないがゆえの不安からくる行動でした。

この②は、最近AIのプロンプトを設計する時にも同じだと感じています。細かく指示しすぎると人間の想像の域を出ない成果物になる。PLの仕事の頼み方とプロンプトの設計は、本質的に同じ構造だと思っています。

---

今、後輩PLを見て気づくこと

最近、若手の後輩がPLに移行しました。その後輩を見ていると、かつての自分と完全に重なります。

自分から情報収集に動けず、「誰かから言われるまで待つ」癖がなかなか抜けていません。これはその後輩が悪いわけではありません。エンジニアとして優秀に育った人ほど「正確に指示を受けて確実に実行する」スタイルが身についていて、そこからの切り替えが難しいのです。

先日、その後輩にこんな話をしました。「経験豊富なパートナーに細かく指示するより、課題をオープンに投げて一緒に考えてもらう方が、結果的に良いものができることが多い」と。かなり共感してもらえました。自分が先輩メンターに言われて腑に落ちた感覚と、同じものを感じてもらえたのだと思います。

---

まとめ——エンジニアからPLになる前に知っておきたいこと

① 「設計図を受け取る側」から「描く側」への切り替えが最初の壁

技術スキルがあっても、PLとして動けるかどうかは別の話です。エンジニアとして優秀であることと、PLとして機能することは異なります。

② 情報収集は待つのではなく取りに行く

「誰かが教えてくれる」という感覚は、PLになった瞬間に機能しなくなります。前任者・関係者・パートナーから積極的に情報を引き出す動き方を、早めに意識することが重要です。

③ 失敗は早い方がいい

3年目に小さなチームで失敗できたことは、今振り返ると本当によかったと思っています。その経験があったからこそ、PMとして動ける今があります。

---

AWS資格の勉強をしている段階から「自分はいずれPLになる」という意識を持って仕事を見ておくと、技術知識がより実践的に活きてきます。この記事が、同じフェーズにいる方の参考になれば嬉しいです。