PL（プロジェクトリーダー）のスキルシートの書き方｜面談で評価される実績の見せ方
公開 2026-10-29 監修：株式会社エージェントベスト
PL（プロジェクトリーダー）のスキルシートは、技術の一覧より先に「どんなチームを、誰の下で、どの範囲までまとめたか」を読ませるのが基本です。1件ごとに「チームの規模と構成・報告先・担当工程・まとめた範囲・管理と実装の割合・工夫と結果」をそろえて書くと、読み手は任せられる範囲をすぐに判断できます。
エンジニアのシートのように技術を並べるだけでは、PLとしての力は伝わりません。反対に、PMのシートのようにプロジェクト全体の判断を書こうとすると、実際の役割より大きく見えてしまいます。この記事では、PLのシートに固有の書き方を紹介します。全体の構成や基本の型はフリーランスのスキルシートの書き方で解説しています。
PLのシートはどう読まれるか
PLの案件のシートを読むのは、多くの場合、そのチームの上に立つPMや開発の責任者です。読み手は「この人を自分の下に置いたら、チームを任せられるか」を考えながら読みます。そのため、次のような点を探します。
- 何人のチームを、どんな構成でまとめていたか
- 誰に報告し、どこまでを自分で決めていたか
- 作業の割り振り、進捗、品質のうち、どこまで責任を持っていたか
- 自分も手を動かしていたか、その割合はどのくらいか
- チームで使っていた技術を、自分で判断できるか
PLに求められるスキルの全体像はPLのスキルの記事で整理しています。ここでは、それをシートの上でどう表すかに絞ります。
要約欄は「どんなチームを率いるPLか」を3行で
要約欄は、もっとも読まれる部分です。PLの場合は、率いてきたチームの型と技術の軸を先に書きます。
例：
- Javaの業務システム開発で、5〜8名の開発チームのPLを複数回担当
- 協力会社2社のメンバーを含むチームで、作業の割り振り・レビュー・不具合の管理を担当
- 設計レビューとテスト計画まで責任を持ち、PMへの週次報告を担当
これは書き方を示すための架空の例です。実際には、応募する案件のチームの規模や技術に近い行を一番上に置き、案件ごとに並べ替えます。
プロジェクト欄に入れる項目
PLのプロジェクト欄は、基本の型にPL固有の項目を足して書きます。
| 項目 | 書き方のポイント |
|---|---|
| 期間 | 年月で書く。PLを担った期間とメンバーだった期間が違う場合は分ける |
| 案件の概要 | 業種と目的で書く（例：小売業向けの在庫管理システムの改修）。社名は書かない |
| 体制と報告先 | 全体の人数、自分のチームの人数と構成（社員・協力会社・拠点）、自分の報告先（PMなど） |
| 担当工程 | 基本設計、詳細設計、製造、テスト、リリースなど、チームとして担った範囲 |
| まとめた範囲 | 作業の割り振り、進捗、課題、レビュー、テスト計画、不具合の管理、他チームとの調整のうち、自分が責任を持ったもの |
| 管理と実装の割合 | 自分が手を動かした割合のおおよそと、担った作業（例：共通部品の実装） |
| 技術 | 言語、フレームワーク、データベース、クラウド、使っていた管理ツール |
| 工夫と結果 | チームの運営で変えたことと、その結果 |
「管理と実装の割合」は、PLのシートで特に大事な項目です。読み手は、応募する案件の形（管理に専念か、開発もするPLか）と照らし合わせて読みます。割合は厳密でなくてかまいませんが、面談で聞かれたら説明できる程度にしておきましょう。
記入例（架空）
以下は、項目の埋め方を示すための架空の例です。実在の案件や人物をもとにしたものではありません。実際の経験に置き換えて書いてください。
期間：（例）約1年。うち最初の2か月はメンバー、その後PL
案件の概要：（例）物流業向け 配送管理システムの機能追加
体制と報告先：全体約25名。自分のチームは6名（社員2名、協力会社4名）。報告先はPM
担当工程：詳細設計〜結合テスト、リリース準備
まとめた範囲：作業の割り振り、進捗と課題の管理、設計とコードのレビュー、不具合の管理。他チームとの接続の調整はPMと分担
管理と実装の割合：管理がおよそ7割。共通部品の実装と難しい不具合の調査を担当
技術：Java、Spring Boot、PostgreSQL、Git、課題管理ツール
工夫と結果：レビュー待ちが積み上がっていたため、レビューの担当を2名に分け、観点の一覧をつくった。レビュー待ちの滞りが減り、結合テストを予定どおり開始
「工夫と結果」の書き方
PLのシートで差が出るのが「工夫と結果」の欄です。読み手はここから、「この人に任せたら、チームに問題が起きたときにどう動くか」を想像します。
書くときは、チームの状況、自分が変えたこと、その結果の3つを1文ずつで表すと、短くても伝わります。
| 書き方 | 例 |
|---|---|
| 伝わりにくい | チームをまとめ、円滑に開発を推進した |
| 伝わりやすい | （例）新しいメンバーが立ち上がるまでに時間がかかっていたため、環境構築の手順書と最初の作業の一覧を用意した。参画から作業開始までの日数が短くなった |
「円滑に推進」「チームをまとめた」といった言葉は、どのPLのシートにも書かれているため、読み手の目に留まりません。自分が変えた仕組みを、名詞と動詞で具体的に書くほうが伝わります。結果の数字は、自分で確かめられた範囲のものだけにしましょう。
肩書きと実際の役割がずれるとき
PLの経歴では、肩書きと役割が一致しないことがよくあります。その場合は、肩書きと役割を分けて書くのが誠実です。
- 肩書きはメンバーだったが、数名の作業を割り振り、進捗をPMに報告していた場合は、その範囲を役割として書けば、PLの経験として伝わります
- 肩書きはPLだったが、実際は自分の担当の実装が中心で、まとめる仕事は少なかった場合は、メンバーとしての経験として書くほうが、面談での食い違いを防げます
- 肩書きはPLだったが、PMが不在でプロジェクト全体の調整まで担っていた場合は、その範囲を具体的に書きます。PMの案件にも応募するなら、PMのスキルシートの書き方も参考にしてください
テックリードとPLを兼ねていた場合は、技術の判断として担ったことと、チームの運営として担ったことを分けて書くと、読み手がどちらの役割で評価すればよいかを判断しやすくなります。テックリードの経験の示し方はテックリードとして参画する記事で扱っています。
書いてよいこと・伏せること
PLのシートでは、チームの構成を書く過程で、協力会社の名前や、メンバーの名前、社内の呼び名が入り込みやすくなります。
- 書きやすいこと：期間、人数、会社や拠点の数、担当工程、技術
- 伏せること：発注元や協力会社の社名、メンバーの名前、プロジェクトの社内での呼び名、システムの固有の名前
どこまで書いてよいかの考え方は、スキルシートに書いてよいこと・いけないことで詳しく解説しています。
提出前に見直したいこと
- 要約欄の1行目に、応募する案件のチームの規模や技術に近い経験が来ているか
- すべてのプロジェクトに「体制と報告先」と「まとめた範囲」が入っているか
- 「管理と実装の割合」が書かれ、面談で説明できるか
- 「工夫と結果」が、状況・変えたこと・結果の形で書けているか
- 肩書きと実際の役割がずれる経歴は、分けて書いているか
- 社名、メンバーの名前、社内の呼び名が入っていないか
よくある質問
PLの経験が短く、メンバーの経歴のほうが長い場合はどう書けばよいですか？
同じプロジェクトの中でメンバーからPLに変わった場合は、期間を分けて書きます。PLを担った期間が短くても、まとめた範囲と工夫を具体的に書けば、任せられる範囲は伝わります。メンバーの時期の経歴は、技術の経験として簡潔に書きましょう。
チームの人数には、協力会社のメンバーも含めてよいですか？
含めてかまいません。ただし、社員と協力会社、拠点ごとの内訳を分けて書くと、読み手が調整の難しさを判断しやすくなります。自分が作業を割り振っていた人数と、チーム全体の人数が違う場合も、分けて書いておきましょう。
PL向けとメンバー向けで、シートを分けたほうがよいですか？
両方の案件を探す場合は、分けておくと便利です。PL向けのシートでは、要約欄と各プロジェクトの「まとめた範囲」「工夫と結果」を厚く書きます。メンバー向けのシートでは、技術と担当した作業を厚く書きます。どちらも事実は同じで、並べ方と厚みを変えるだけにしましょう。