プロジェクトリーダー（PL）の年収相場｜PMとの差と評価を決める4つの責任

プロジェクトリーダー（PL）の年収は、肩書きではなく、チームの進行と品質の責任をどこまで任されているかで決まります。役割が増えても等級が変わらなければ年収は動きません。一方、この経験を判断の形で説明できれば、PMへの昇格や転職の提示額を動かす材料になります。

SEとして働く人全体の水準はシステムエンジニアの年収相場で確認できます。この記事ではPLという役割に絞り、PMとの違いと年収の決まり方を説明します。

公的統計にPLの区分はない

結論として、プロジェクトリーダーの平均年収を示す公的統計はありません。賃金構造基本統計調査の職種区分では、PLは主な仕事の内容に応じて、設計者かソフトウェア作成者のどちらかに含まれると考えられます。

年収換算額は当サイトが月額と年間賞与から算出した概算で、調査の公表値ではありません。この差をPLの価値として読むのは適切ではありませんが、実装中心の区分と設計中心の区分で水準が違うという向きは確認できます。PLはこの2つの間に位置する役割です。

年齢別の推移も参考になります。PLを任され始めることが多い30代の層で、情報通信業の平均給与は30〜34歳が574万円、35〜39歳が660万円です。ただしこれは業種全体の断面の平均で、営業や管理部門も含みます。同じ人が年齢とともにこの額を受け取るわけではありません（年齢別の年収）。

PMとPLの違いは何の責任を持つか

PLとPMの違いを年収の観点で見ると、責任の種類に行き着きます。どの会社でも全く同じ線引きがあるわけではありませんが、一般には次のように整理できます。

PMのほうが高く評価されるのは、失敗の金額的な影響が大きく、責任の範囲が広いからです。ただし「PMになれば必ず高い」とは言えません。

PMの相場についてはITプロジェクトマネージャーの年収相場で詳しく説明しています。

具体例として、同じ案件の中で、PLはチームのタスクを分割して遅れを早期に見つけ、PMは遅れが見えた時点で顧客と機能の範囲を調整します。どちらも「進行管理」ですが、決める内容の重さが違います。

残業代があるPLの収入は額面で見誤りやすい

PLの年収を見るときに重要なのは、残業代です。結論として、PLからPMへの昇格直後は、額面が増えても実質があまり増えないことがあります。

理由は、PLの多くが残業代の対象である一方、上位の役割では管理監督者として扱われ、対象から外れる場合があるからです。案件の山場でPLが長時間働くと、残業代が年収の大きな部分を占めます。法定の割増率は時間外で25%、月60時間を超える分は50%です。

具体的な比較は、前年の年収から残業代を除いた額と、昇格後の額を比べることです。さらに働く時間で割った実質時給でも比べます。残業代込みの額を基準にすると、昇格のメリットを過小評価したり、逆に残業代を失う影響を見落としたりします。計算方法は管理職に登用されて残業代がなくなるときの年収を参照してください。

例外として、みなし残業や裁量労働制の会社では、PLの時点で残業代が固定されていることがあります。その場合は、昇格で何が変わるかを別に確かめます（みなし残業と実質時給）。

SIerと自社開発で役割が変わる

PLという言葉は、主にSIerや受託開発の案件で使われます。自社サービスの会社ではテックリードやチームリードと呼ばれることが多く、同じようなポジションでも評価の基準が違います。

SIerのPLは、計画に対する進捗と品質、顧客への説明が評価の中心です。計画どおり終わらせることに価値があります。そのため、WBSの作成、課題の管理、品質指標の報告が重要になります。一方、自社サービスのチームリードは、機能が事業に効いたかどうかも問われます。計画の変更が前提となる場面が多いので、優先順位の判断が重要になります。

企業タイプごとの推定レンジは次のとおりです。

このモデルはPL専用の係数を持たず、実務6〜9年のエンジニアが企業タイプごとに置かれる位置を示すものです。同じPLという役割でも、会社の種類で基本の水準が変わることが分かります。商流の深い案件のPLは、役割が大きくても単価の上限に当たります（一次請けと二次請けの年収の差、ユーザー系・メーカー系・独立系SIerの年収の違い）。

注意点として、PLの経験をそのまま自社サービスの会社へ持ち込むと、「計画管理の人」と見られて実装力を問われることがあります。逆に、チームリードがSIerへ移ると、文書や報告の基準に戸惑うことがあります。

評価を決める4つの責任

PLの実績を昇格や転職で説明するときは、次の4つの責任の範囲で整理します。

1つ目は、スコープの調整です。遅れが見えたときに、何を削るか、何を後回しにするかを判断した経験です。単に人を増やす、残業で埋める、といった方法以外を選べる人は評価されます。

2つ目は、品質の責任です。不具合の傾向を見てテストの重点を変えたり、受け入れの基準を調整したりした経験です。品質の指標を報告するだけでは足りません。

3つ目は、人の配置と育成です。メンバーのスキルに合わせて担当を割り振り、弱い部分を支え、次のリーダーを育てる経験です。全部を自分で引き取ってしまう人は、スケールしません。

4つ目は、外部との調整です。顧客や他チームとの間で、仕様の解釈の違いや依存関係のリスクを解決した経験です。問題を上に報告するだけでなく、解決の案を持って相談する形が評価されます。

具体例として、「10名チームのリーダーとして開発を完遂」と書くと、結果しか分かりません。「結合テストの遅れを受け、影響の小さい帳票の機能を次期へ移すことを顧客と合意し、残業に頼らず本番の日程を守った」と書くと、判断が見えます（職務経歴書の書き分け）。

手を動かすPLの落とし穴

プレイングマネージャーとしてのPLには、落とし穴があります。自分で手を動かせることが、かえって役割の成長を妨げることがあるのです。

遅れが見えたとき、自分で実装すれば短期的には解決します。しかしチームの力は伸びず、自分が抜けると進まない状態になります。また、管理の時間が夜に回り、残業が増えます。この働き方は短期的には評価されても、チームを任せる範囲を広げる根拠にはなりません。

抜け出す手順は、まず自分しかできない作業を洗い出し、メンバーへ渡す計画を立てることです。レビューの観点を文書にする、難しい部分を一緒に実装する、といった方法があります。

例外として、チームが小さく、実装を減らせない環境もあります。その場合は、自分の時間の配分を記録し、管理の仕事に使っている時間を上司に示します。実装と管理の両方を担当している事実を評価の材料にできます。

技術で伸びるかマネジメントで伸びるか

PLの次の選択肢は、大きく2つに分かれます。PMに進むか、技術の専門職に進むかです。どちらを選ぶかで、これから積むべき経験が変わるので、早めに方向を決めるとよいでしょう。

PMに進むなら、予算と契約の知識、顧客との交渉、リスク管理の経験が必要です。プロジェクトマネージャ試験などの資格が評価の材料になる会社もあります（エンジニアの資格と年収）。PMOに寄る道もあります（PMOの年収）。

技術に進むなら、テックリードやアーキテクトの方向です（ITアーキテクトの年収相場、テックリードとマネージャーの比較）。ただし、自社の等級の階段が技術の方向にどこまで伸びているかを確かめてください。階段がなければ、技術を選ぶことは社内での年収の上限を受け入れることになります（専門職コースの年収）。

判断の材料として、自分が仕事のどの部分にやりがいを感じるかだけでなく、社内の等級と市場の求人の両方を見ます。社内で片方の階段しかなければ、転職で選択肢を広げることも考えられます。

役割は増えたのに年収が変わらないとき

PLの役割を任されたのに年収が変わらない場合、いくつかの原因が考えられます。役職手当がない、等級の要件を満たしていない、評価のタイミングがまだ来ていない、のどれかです。

確認の手順は次のとおりです。

1. 自社の等級の定義で、PLの役割に対応する等級を確認する
2. 現在の等級の要件と、次の等級の要件の差を書き出す
3. 役職手当の制度があるか、対象の条件を確認する
4. 次回の評価や昇格の判定時期を確認する
5. 評価面談で、担当の範囲と等級の対応を具体的に質問する

面談では「年収を上げてほしい」と言うより、「PLとして担当している範囲は、次の等級の要件のどこまでを満たしているか」と聞くほうが建設的です。答えが明確なら準備の方向が分かり、答えが曖昧なら制度そのものに問題がある可能性があります。話し合いの進め方は評価に不満があるときの面談で扱っています。

社内で評価の見込みがない場合は、PLの経験を持って転職市場で確かめる選択もあります。実績を判断の形で整理しておけば、どちらの場合も使えます。

求人票で確かめること

PLの求人では、次の点を面接で確かめます。

• チームの人数と構成、外部ベンダーの有無
• 実装に使う時間と、管理に使う時間の想定
• 予算や顧客との調整の権限の範囲
• 残業代の対象か、役職手当はいくらか
• 対応する等級と、PMやテックリードへの道筋
• 案件の商流上の位置

名前がPLでも、実際には実装の担当者である場合や、逆に実質的なPMの責任を負わされている場合があります。責任の範囲に対して等級が低いなら、提示額の交渉の根拠になります（年収交渉の進め方）。

この記事の数字が当てはまらないケース

年収換算額は当サイトが計算した概算で、PLだけを取り出したものではありません。情報通信業の年齢別平均は業種全体の断面です。

割増率は法定の下限です。診断モデルのレンジはマネジメントの範囲を反映していません。いずれも目安であって、個別の提示の判定には使えません。

最終チェック

• スコープ、品質、人、外部調整の4つの責任の範囲を整理した
• 判断の事例を、結果だけでなく過程まで説明できる
• 残業代を除いた額で年収を比較した
• 自社の等級で、PLの役割に対応する位置を確認した
• PMと技術のどちらの方向に進むかを考えた
• 自分しかできない作業を減らす計画を立てた

PLは肩書き以上に、中身で差がつく役割です。何を判断したかを記録し、等級の要件と対応させることで、次の提示額につなげられます。