PL（プロジェクトリーダー）のフリーランス案件の仕事内容｜案件の種類別の1日・1か月の流れ

フリーランスのPL（プロジェクトリーダー）の仕事は、PMの下で一つのチームを受け持ち、作業を割り振り、進み具合と品質をつかみ、PMに報告することです。プロジェクト全体の計画や予算を持つPMと違い、PLの1日は「チームの今日の作業が回っているか」を中心に組み立てられます。

ただし、どんなチームを受け持つかで、時間の使い方も向き合う相手も大きく変わります。この記事では、フリーランスのPL案件を5つの種類に分け、それぞれの1日と1か月の流れ、関わる相手、成果物を整理します。報酬の決まり方はPLの報酬の記事、求められるスキルはPLのスキルの記事で扱っているので、ここでは「参画したら実際に何をしているか」に絞ります。

PLの仕事は「受け持つチーム」で中身が決まる

PLの案件は、肩書きが同じでも働き方の違いが大きい役割です。違いを生むのは、主に次の3つです。

• チームの所属：自分と同じ会社の体制か、事業会社の社員か、協力会社や海外拠点か
• 工程：設計・開発・テストの最中か、リリース後の保守や改修か
• 手を動かす割合：管理に専念するか、自分も設計や実装を担うか

これを組み合わせると、フリーランスのPL案件はおおむね次の5種類に分けられます。

以下では、それぞれの1日と1か月の流れを、典型的な例として紹介します。時間の配分は案件ごとに違うため、目安として読んでください。

受託開発のチームリーダーの仕事

開発会社やSIerの体制の中で、機能や画面の単位で分かれたチームの一つを受け持つ案件です。フリーランスのPL案件では、最もよく見られる形です。

1日の流れ（例）

朝は、チケットや進捗表で前日の作業の結果を確かめ、朝会でメンバーの今日の予定と困りごとを聞きます。午前は、詰まっているメンバーの相談に乗ったり、仕様の不明点を設計の担当者や上流のチームに確かめたりします。午後は、設計書やコードのレビュー、不具合の振り分けに時間を使います。夕方は、チームの状況をまとめてPMに報告し、翌日の作業の順番を見直します。

PMが「プロジェクト全体のずれ」を見るのに対し、PLはメンバー一人ひとりの作業のずれを見ています。

1か月の流れ（例）

• 月初：その月に終える機能と作業の一覧をつくり、メンバーに割り振る
• 毎週：PMが開く定例でチームの状況を報告する。他チームのPLと、つなぎ目の仕様や日程をそろえる
• 月の半ば：遅れている作業を見つけ、順番の入れ替えや応援の依頼をPMに相談する
• 月末：工程の区切りに合わせてレビューやテストの結果をまとめ、次の工程に進めるかの判断材料をPMに渡す

成果物

チーム単位の作業一覧とスケジュール、課題と不具合の一覧、レビューの記録、週次の報告、チーム内の手順書などです。設計書の一部を自分で書くこともあります。

事業会社の内製チームのPLの仕事

自社サービスや社内システムを社員のエンジニアとともに開発するチームを回す案件です。スクラムなどの短い周期で進めることが多く、PLという呼び方をせずに「チームリーダー」「エンジニアリングマネージャーの補佐」として募集されることもあります。

1日・1か月の流れ（例）

毎日の短い朝会のほか、周期ごとに計画、成果の確認、振り返りの会議が回ります。PLは、プロダクトの責任者が決めた優先順位をチームの作業に落とし、作業の見積もりや分け方をメンバーと決めます。1か月の単位では、次に作る機能の準備が間に合っているか、チームの作業量に無理がないかを見ながら、プロダクトの責任者と次の計画をすり合わせます。

社員のエンジニアに開発の進め方やレビューの観点を伝え、チームが自分たちで回るようにすることも期待されやすい仕事です。

成果物

作業の一覧と見積もり、周期ごとの計画と振り返りの記録、レビューの基準、開発の進め方をまとめた文書などです。細かな進捗表はチーム自身が管理することも多く、PLが資料をつくる時間は受託開発より少なくなりがちです。スクラムで役割が分かれている現場の働き方はスクラムマスターの仕事内容が参考になります。

協力会社・海外拠点をまとめるPLの仕事

開発の作業を協力会社や海外の拠点に依頼し、その作業をPL側でまとめる案件です。自分の会社の上下関係が及ばない相手に作業を頼むため、依頼の書き方と受け入れの確認に多くの時間を使います。

1日・1か月の流れ（例）

日中は、依頼する作業の範囲と完了の条件を文書にまとめ、相手先のリーダーと内容をすり合わせます。海外の拠点と組む場合は、時差のある時間帯に定例の会議を置き、質問への回答を翌日に持ち越さない工夫が要ります。納品された成果物は、レビューやテストで受け入れの基準を満たしているかを確かめ、直してほしい点を返します。

1か月の単位では、相手先ごとに進み具合と品質の傾向を確かめ、依頼の仕方や受け入れの手順を見直します。拠点との間に立つ役割はブリッジSEの仕事内容とも重なります。

成果物

作業の依頼書や仕様の補足、質問と回答の一覧、受け入れの確認の記録、相手先ごとの進捗と品質の報告などです。

開発もするPLの仕事

3〜5名ほどの少人数のチームで、自分も設計や実装を担いながらチームをまとめる案件です。スタートアップや、立ち上げ直後のプロジェクトで見られます。

1日・1か月の流れ（例）

午前に朝会とメンバーの相談、レビューをまとめて済ませ、午後は自分の担当の設計や実装に集中する、という時間の分け方が多くなります。PMへの報告も、文書より会話や短いチャットで済ませる現場が少なくありません。1か月の単位では、自分の作業がチームの進みの妨げになっていないかを振り返り、難しい作業を自分が抱え込みすぎていないかを見直します。

成果物

自分が担当した設計書やコードに加え、作業の割り振りとレビューの記録、短い報告などです。技術の判断に重心があるため、テックリードに近い働き方になります。

保守・改修チームのPLの仕事

リリース後のシステムで、問い合わせへの対応、不具合の修正、小さな機能の追加を受け持つチームのPLです。

1日・1か月の流れ（例）

毎日、運用の担当者や業務部門から届く問い合わせと改修の依頼を受け付け、急ぎかどうかを見分けて担当者を決めます。障害が起きたときは、原因の調査と暫定の対応、関係者への報告を優先します。1か月の単位では、改修の依頼をまとめて優先順位をつけ、リリースの計画をつくり、本番に反映する手順と日程を関係者とそろえます。

成果物

問い合わせと改修依頼の一覧、障害の報告書、リリースの計画と手順書、月次の対応実績の報告などです。開発の案件より日々の動きが読みにくい分、障害時の連絡体制に自分が入るかどうかが働き方を大きく左右します。

どの案件にも共通するPLの仕事

種類が違っても、次の仕事はほぼすべてのPL案件にあります。

1. 作業を分けて割り振る：機能や不具合を、メンバーが1〜数日で終えられる大きさに分け、得意・不得意を見て担当を決める
2. ずれに早く気づく：朝会やチケットの動きから、詰まっている作業を見つけて手を打つ
3. 品質をそろえる：レビューの観点をチームでそろえ、不具合の傾向から手順を見直す
4. 上に上げる：チームで決められないことを、事実・影響・対応案の形でPMに渡す

フリーランスならではの仕事として、自分の稼働の記録と報告もあります。月の稼働時間に幅を決めて精算する契約が多いため、会議やレビューに使った時間を日々つけておくと、精算のときに迷いません。精算の仕組みは精算幅の記事をご覧ください。

関わる相手と、その相手に出すもの

PLは、上と下と横の間に立つ役割です。相手ごとに整理すると、次のようになります。

PMとの役割の境目は案件によって違います。PMの仕事の中身はPMの仕事内容、PMOとの違いはPMOの仕事内容で解説しています。働く場所については、作業の割り振りやレビューはオンラインで回しやすい一方、チームの立ち上げや新メンバーの受け入れでは出社を求められやすくなります。詳しくはPLのリモート案件の記事をご覧ください。

よくある質問

PLとPMの仕事は、どこで線が引かれますか？

一般的には、プロジェクト全体の計画、予算、発注元との合意はPM、チームの単位で計画を実行に移すのがPLです。ただし小さなプロジェクトでは、PLが発注元との打ち合わせに出ることもあります。どこまで任されるかは、参画前に確かめておくと安心です。

フリーランスのPLは、どのくらい自分で開発しますか？

案件によって大きく違います。管理に専念する案件もあれば、作業の半分以上が自分の設計や実装という案件もあります。管理と実装の割合は報酬や稼働の見込みにも関わるため、案件の選び方はPL案件の選び方で整理しています。

参画して最初の1か月は何をすることが多いですか？

メンバーの顔ぶれと得意分野、作業の管理の仕方、PMへの報告の流れを確かめるところから始めるのが一般的です。初月の進め方はPLの参画初月にやることで解説しています。