PMとPLの違いは「外」と「中」｜境界が曖昧になる現場の3場面

PMとPLの違いは「外」と「中」

先に結論を書きます。PMはプロジェクトの「外」（顧客・予算・契約）に責任を持ち、PLはプロジェクトの「中」（メンバー・設計・品質）に責任を持ちます。PMが上でPLが下という上下関係ではなく、見ている方向が違うのです。

ただ、これだけでは足りません。PLとPMの違いを調べると、どの記事にも「PMは全体を管理する人」「PLは現場を動かすリーダー」「PMが計画を立て、PLが実行する」と書かれています。定義としては間違っていませんが、この説明で「自分がPLになったとき何をすればいいのか」がわかるかと言えば、わからないでしょう。

実際のSIプロジェクトでは、この「外」と「中」の境界がしばしば曖昧になります。プロジェクトの規模や体制、PMの個性によって、どこまでがPLの仕事かが変わるからです。

そこでこの記事では、一覧表で定義を整理したうえで、境界が曖昧になる3つの場面を現場の視点から具体的に見ていきます。PLを目指しているSE、あるいはPLを打診されて「自分に何が求められるのか」を知りたいエンジニアに向けて書いています。

定義と一覧表で整理する

まずはそれぞれの定義を押さえておきます。

PMはプロジェクト全体の責任者です。プロジェクトの目的達成に対して最終的な責任を持ち、スケジュール、予算、品質、人員、リスクを全体的にコントロールし、顧客や経営層といったステークホルダーとの窓口になります。

PLはプロジェクトの実行責任者です。PMが立てた計画を、チームメンバーを率いて現場で実行に移します。メンバーへのタスクの割り振り、進捗の把握、技術的な課題の判断、品質のチェックなどを担います。

定義を一覧で並べると、PLとPMの違いはこう整理できます。

ただし、問題は、この役割分担が現場ではどう機能するかです。表のとおりにきれいには分かれません。ここから先は、境界が曖昧になる3つの場面を見ていきます。

「外」と「中」の境界が曖昧になる3つの場面

場面1：PMが「いない」時間のほうが長い

教科書では「PMが計画し、PLが実行する」と書かれていますが、実際の大規模SIプロジェクトでは、PMは複数のプロジェクトを掛け持ちしていたり、顧客との会議や社内の調整で現場にいない時間が長かったりします。

つまり、日常的にチームが頼りにするのはPMではなくPLです。たとえば結合テスト中に他システムとの連携部分で想定外のエラーが出て、顧客からは「今日中に原因の見立てがほしい」と連絡が来る。PMは別の客先で会議中。この「今、判断する人がいない」状態を、PLが埋めることになります。

この「PMがいない間のプロジェクト運営」が、PLの仕事の大部分を占めます。

だからこそ、PLには「これはPMに判断を仰ぐべきか、自分で決めていいか」の線引きが求められます。何でもPMに聞いていたらスピードが落ちる。かといって、予算や契約に関わるような判断をPLが独断で下してしまえば問題になる。たとえば顧客から「来週リリース予定の機能、画面の文言を一部変えたい」と連絡が来たとき。表記レベルの修正ならPLが即答していいが、画面遷移やデータ項目が変わるならPM案件、というのが多くの現場の感覚です。この判断の線引きが、PLとして最初にぶつかる壁です。

場面2：PLが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・PM・PMO・SEの関係を整理する

PLとPMの違いを正しく掴むには、周辺の役割もあわせて並べておくと位置づけがはっきりします。

ざっくり言えば、PMはプロジェクトの外を整え、PLは中を回し、SEは手を動かして成果物を作るという関係です。そこにPMO（プロジェクトマネジメントオフィス）が加わると、PMOは個別の現場を率いるのではなく、複数プロジェクトを横断して進捗・品質・ルールの標準化を支援する立場になります。PLが「一つの現場の中」を見るのに対し、PMOは「組織全体のプロジェクト運営」を見る、という違いです。

注意したいのは、この4つが上下の階段ではないことです。SEがそのままPLになり、PLがそのままPMになる、という一本道で捉えると役割を見誤ります。SEからPLへの移行は、肩書きが上がるというより「中を守る」視点を獲得していく過程です。その具体的なステップはPLになるには何が足りないのかで別途整理しています。それぞれが「見ている範囲」と「担っている責任の広さ」で分かれている、と捉えるのが現場の感覚に近いはずです。

PLの先は、PM一択ではない

「PLの次はPM」と考えている人は少なくありません。しかし前述のとおりPLはPMの下位互換ではないので、PLの先がPM一択ということもありません。

ここで、制度としてどうなっているかを一つ具体例として出します。スーパーソフトウエアの社内クラス体系では、チームを率いる段階を「AMGR（アシスタントマネージャ）」と呼びますが、この段階には2つの担い方があります。

• PL — 顧客の信頼を得て、チームをリードする
• テックリード — 高い技術力で、顧客の開発チームを技術面からリードする

重要なのは、この2つが同じクラスとして評価されることです。テックリードはPLの手前の段階でも、PLになれなかった人の行き先でもありません。管理職にならなくても、この段階に到達できます。

実際にこの道を通った人がいます。実装担当からアプリケーションエンジニアへ経験を広げ、その後、顧客側のアプリ開発チームをリードする役割へ。アプリケーションと顧客業務への深い理解、そして設計・技術判断によって、顧客のアプリ開発そのものを前に進める立場になりました。PLを経由していません。

つまり、役割の名前がキャリアの高さを決めているわけではないということです。決めているのは、どこまで開発を前に進められるか——担える領域の広さと、解ける課題の難度です。PLもテックリードも、その手段が違うだけです。

この2つの担い方と、その先の広がりはキャリアを知るで図解しています。

なお「そもそも自分はPLに向いているのか」という問いは、役割の違いとは別の論点です。適性の見極め方と、向いていないと感じたときにどうするかはPLに向いている人・向いていない人で扱っています。

PLとPMの年収・給料はどう違うのか

役割の違いは、待遇の設計にも表れます。「PMの方が高い」と言われますし、私たちが採用の現場で見ている相場感としても、上流の責任まで負うPMはおおむね600〜900万円程度、現場を率いるPLは500〜700万円程度で、たしかにPMがやや高めに出ます。

ただし、これはあくまで目安です。同じ「PL」でも会社・業界・商流によって年収は大きく開きますし、両者のレンジは大きく重なっています。「PMのほうが偉いから給料が高い」という単純な話ではありません。本来は、その人が出している価値に対して報酬が決まるべきものです。PLであっても、技術判断で現場を支え、チームを動かしているなら、その価値はPMに劣りません。

評価の設計を見るときのポイントは、年功や肩書きではなく「担える領域の広さ」と「解ける課題の難度」で見られているかです。前節のPLとテックリードが同じクラスになるのは、この2つで測っているからです。

逆に、役割の名前で天井が決まる設計だと、PLとしてどれだけ現場を支えても待遇は肩書きの分だけで止まります。それは役割の問題ではなく、評価制度の問題です。

まとめ

PLを目指すSEにとって、最も大事なのは「中を守る」感覚を持てるかどうかです。そしてその感覚は、SEとして現場を経験してきた人にこそ備わっています。

「中を守る」をさらに具体的なスキルに落とすと、PLが日々向き合うのは顧客・技術・チームのあいだで起こる翻訳の仕事です。3層の翻訳と現場での磨き方はこれからのPLに求められる「翻訳力」とはで扱っています。

スーパーソフトウエアが目指すPL像

スーパーソフトウエアでは、PLを「PMの一歩手前」ではなく、プロジェクトの中核を担う独立した専門職として位置づけています。

技術を基盤に、顧客とシステムを理解し、人とAIを組み合わせながら、開発を前に進める力。私たちはこれを開発推進力と呼んでいます。それを支えるのが、作る・理解する・判断する・進める・共有するの5つの能力です。PLは、この5つがそのまま問われる役割です。設計をレビューし（作る・判断する）、顧客の要望の背景を掴み（理解する）、メンバーと合意をつくって案件を進め切る（進める・共有する）。

技術力を土台に担える領域を広げていきたい方、ぜひ一度お話を聞かせてください。PLという担い方でも、テックリードという担い方でも構いません。

この記事のテーマについて、もっと話を聞いてみたい方へ：

• カジュアル面談を申し込む — 30〜45分のオンライン面談
• 募集職種を見る — PL候補の求人一覧
• SESで上流工程に行けるか｜契約を変えずに進む5ステップ — 契約形態を変えずに担当工程を上げる5ステップ
• AIが出したコードを、どう判断するか — 現場マネージャーが見ている5つの観点
• 30代エンジニアが「このまま技術だけでいいのか」と感じたら — 30代の停滞感と35歳定年説の実際
• 他のキャリア記事を読む — PL／上流工程／キャリアに関する他の記事