「PM＝管理者、PL＝現場リーダー」では何もわからない
PLとPMの違いを調べると、どの記事にも同じことが書かれています。「PMはプロジェクト全体を管理する人」「PLは現場を動かすリーダー」「PMが計画を立て、PLが実行する」。
定義としては間違っていません。しかし、この説明だけで「自分がPLになったとき何をすればいいのか」がわかるかと言えば、正直なところわからないでしょう。
実際のSIプロジェクトの現場では、PMとPLの境界はもっと曖昧で、プロジェクトの規模や体制、PMの個性によって大きく変わります。
この記事では、PLとPMの違いを定義ではなく、現場でPLが実際に何に直面するのかという視点から整理します。PLを目指しているSE、あるいはPLを打診されて「自分に何が求められるのか」を知りたいエンジニアに向けて書いています。読み終わるころには、PLを打診されたときに「何を覚悟すべきか」の輪郭が見えているはずです。
まず定義を押さえておく
PMはプロジェクト全体の責任者です。プロジェクトの目的達成に対して最終的な責任を持ち、スケジュール、予算、品質、人員、リスクを全体的にコントロールし、顧客や経営層といったステークホルダーとの窓口になります。
PLはプロジェクトの実行責任者です。PMが立てた計画を、チームメンバーを率いて現場で実行に移します。メンバーへのタスクの割り振り、進捗の把握、技術的な課題の判断、品質のチェックなどを担います。
問題は、この役割分担が現場ではどう機能するかです。
現場でPLが直面する3つのリアル
リアル1：PMが「いない」時間のほうが長い
教科書では「PMが計画し、PLが実行する」と書かれていますが、実際の大規模SIプロジェクトでは、PMは複数のプロジェクトを掛け持ちしていたり、顧客との会議や社内の調整で現場にいない時間が長かったりします。
つまり、日常的にチームが頼りにするのはPMではなくPLです。たとえば結合テスト中に他システムとの連携部分で想定外のエラーが出て、顧客からは「今日中に原因の見立てがほしい」と連絡が来る。PMは別の客先で会議中。この「今、判断する人がいない」状態を、PLが埋めることになります。
この「PMがいない間のプロジェクト運営」が、PLの仕事の大部分を占めます。
だからこそ、PLには「これはPMに判断を仰ぐべきか、自分で決めていいか」の線引きが求められます。何でもPMに聞いていたらスピードが落ちる。かといって、予算や契約に関わるような判断をPLが独断で下してしまえば問題になる。たとえば顧客から「来週リリース予定の機能、画面の文言を一部変えたい」と連絡が来たとき。表記レベルの修正ならPLが即答していいが、画面遷移やデータ項目が変わるならPM案件、というのが多くの現場の感覚です。この判断の線引きが、PLとして最初にぶつかる壁です。
リアル2：PMの「盾」になる場面がある
教科書では「PMがステークホルダーとの窓口」と書かれていますが、現場ではPLが顧客と直接やりとりする場面も多々あります。技術的な質問や仕様の詳細確認は、PMよりPLのほうが正確に答えられるからです。要件定義の打ち合わせで顧客から「このAPIは1分間に何回まで叩けますか」と聞かれたとき、PMは「持ち帰ります」と返すしかないが、PLはその場で「現状200req/min、必要なら設計を見直します」と返せる。この差が、顧客からの信頼にも影響します。
ここで重要なのは、PLが顧客のすべての要望を直接受けてしまわないことです。
金曜の夕方、顧客から「月曜の朝までに追加機能の見積もりがほしい」と連絡が来る。PMは別件で不在。このときPLが「わかりました」とその場で引き受けてしまえば、土日にメンバーが動くか、月曜以降のスケジュールがずれるかのどちらかになります。さらに、PMが把握していない範囲でプロジェクトのスコープや計画が変わってしまう。
ここで「一度持ち帰らせてください」と言えるかどうか。PMの判断が必要な事案をきちんとPMに上げ、メンバーを守る。PLには、PMとメンバーの間の「緩衝材」としての役割が求められます。
リアル3：「技術がわかるかどうか」で信頼が決まる
PMとPLの最も本質的な違いは、ここにあるかもしれません。
PMは技術的なバックグラウンドがなくても務まるケースがあります。プロジェクトマネジメントのスキルと、ステークホルダーとの調整能力があれば、技術の詳細はPLやSEに任せるという分業が成り立つからです。実際、コンサルティングファーム出身のPMや、営業畑から転身したPMは少なくありません。
しかしPLは、技術がわからなければ成立しません。メンバーの設計をレビューする、実装方針の妥当性を判断する、障害が発生したときに原因の切り分けを指示する。これらはすべて、技術的な理解が前提です。
たとえば本番リリース直前にパフォーマンスが想定の半分しか出ないとわかったとき、原因がDBのインデックス設計なのか、アプリ側のクエリの組み立て方なのか、それともインフラ側のリソース不足なのか。この切り分けの初動を指示できるかどうかで、その夜にチームが復旧に向かえるか、朝まで右往左往するかが決まります。
SEとして積み上げてきた技術力が、PLとしての信頼の土台になるのです。メンバーが「この人に聞けば正しい判断をしてくれる」と思えるかどうか。その信頼は、技術力の裏づけがあって初めて成り立ちます。
そして、PLの技術的な判断をPMが尊重しているチームほど、メンバーの動きは速くなります。PMが技術の細部にまで口を出してしまうと、メンバーはどちらの指示に従えばいいかわからなくなり、PLの存在意義も薄れる。技術の判断はPLに任せ、PMは全体の判断に集中する。この役割分担が機能しているとき、PLの技術力は最大限に活きます。
PLは「小さなPM」ではない
ここまでの話を踏まえて強調したいのは、PLはPMの下位互換ではないということです。
「PMが上で、PLが下」「PLは将来PMになるための通過点」。こうした見方は根強いですが、現場の実感としては違います。PMとPLは上下関係ではなく、見ている方向が違うのです。
PMはプロジェクトの「外」を見ています。顧客との関係、経営層への報告、予算の調整、他プロジェクトとのリソース競合。プロジェクトを取り巻く環境を整えることに力を注ぎます。
PLはプロジェクトの「中」を見ています。メンバーの状態、設計の品質、テストの進捗、技術的な課題。プロジェクトの内部を健全に保つことに力を注ぎます。
この「外を見る人」と「中を見る人」がうまく噛み合っているプロジェクトは、大抵うまくいきます。逆に、PLがPMの仕事まで巻き取ってしまえば──たとえばPLが顧客との交渉まで引き受けて、メンバーのコードレビューが回らなくなる──プロジェクトの中身は崩れていきます。逆に、PMが現場に介入しすぎてしまえば──たとえば朝会に毎日出て技術判断にまで口を出し、メンバーがPMとPLどちらの指示に従うべきか迷う──現場の手は止まります。
PLにとって大切なのは、「自分はPMの代理ではなく、プロジェクトの中を守る専門家なのだ」という自覚です。
まとめ
PLを目指すSEにとって、最も大事なのは「中を守る」感覚を持てるかどうかです。そしてその感覚は、SEとして現場を経験してきた人にこそ備わっています。
「中を守る」をさらに具体的なスキルに落とすと、PLが日々向き合うのは顧客・技術・チームのあいだで起こる翻訳の仕事です。3層の翻訳と現場での磨き方はこれからのPLに求められる「翻訳力」とはで扱っています。
スーパーソフトウエアが目指すPL像
スーパーソフトウエアでは、PLを「PMの一歩手前」ではなく、プロジェクトの中核を担う独立した専門職として位置づけています。技術を理解し、チームを動かし、顧客と対話する。その全てが求められるPLこそ、私たちが言う「任されるエンジニア」の姿です。
技術力を土台にPLとして成長していきたい方、ぜひ一度お話を聞かせてください。
この記事のテーマについて、もっと話を聞いてみたい方へ：
- カジュアル面談を申し込む — 30〜45分のオンライン面談
- 募集職種を見る — PL候補の求人一覧
- SESエンジニアが上流工程に進むためのロードマップ — 契約形態を変えずに担当工程を上げる5ステップ
- AI時代のエンジニアに変わらず求められる5つの力 — 現場マネージャーの観察視点で見る5つの力
- 他のキャリア記事を読む — PL／上流工程／キャリアに関する他の記事
