PL（プロジェクトリーダー）の参画初月にやること｜現場で信頼される進め方

PL（プロジェクトリーダー）の参画初月は、チームの作業と品質の実態をつかみ、PMとの報告の型とメンバーへの依頼の流れを決め、月末に「チームの見立て」と「改善の案」を出すところまでを目標にします。最初の1か月で求められるのは、チームを大きく変えることより、このPLにチームを任せて大丈夫だとPMとメンバーの両方が感じられる材料を示すことです。

参画前の契約・環境の準備は参画が決まってから開始日までにやること、職種を問わない最初の1週間の進め方は参画初日から最初の1週間でやることで解説しています。この記事では、PLならではの初月の動き方に絞ります。

初月のゴールを3つに分ける

この3つを、1週目、2週目、3〜4週目の順に重心を移しながら進めます。

1週目：コードとチケットと人から実態を集める

PLとして最初に見るもの

PLは、PMより一段細かいところまで見る必要があります。次の順で目を通すと、チームの実態をつかみやすくなります。

1. 体制図とメンバーの一覧：誰がどの会社の所属で、どんな契約で入っているか。作業の依頼をどこから通すか
2. チケットとタスクの一覧：終わっていない作業の量、担当の偏り、長く動いていないチケット
3. 設計書とソースコード：チームが触る範囲の構成、レビューの記録、テストの書かれ方
4. 不具合の一覧：どの機能に不具合が集まっているか、直すまでにかかっている時間
5. 開発の環境と手順：ブランチの運用、ビルドやデプロイの流れ、手元で動かせるか

読みながら、「計画ではこうなっているが、実態は違いそう」という点を書き留めておきます。この段階では結論を出さず、仮説としてためておきます。開発の環境は、初週のうちに自分の手で一度動かしておくと、メンバーの困りごとが分かりやすくなります。

メンバー一人ひとりと短く話す

チケットだけでは分からないのが、人の状況です。メンバー一人ひとりと短い時間で話す機会をつくり、次の3つを聞きます。

• 今の作業で困っていること
• 得意な領域と、これからやってみたいこと
• チームの進め方で変えてほしいこと

同じ質問を全員にすると、人による見方の違いと、チームの詰まりの場所が見えてきます。協力会社の人がいる場合は、その会社のリーダーを通して話す機会をもらうのが無難です。

2週目：報告とレビューの型を整える

PMへの報告の形を合わせる

PMに、どの頻度で、どの粒度の報告がほしいかを確かめ、初回の報告を出します。PLの報告は、作業の一覧より「遅れの芽」と「PMに決めてほしいこと」を先に書くと読まれやすくなります。進捗は「何割できたか」ではなく、終わった作業と残っている作業で示すと、PMも判断しやすくなります。

朝会とレビューの運営を引き継ぐ

2週目には、朝会やレビューの運営を自分の手に移していきます。いきなり形を変えず、前のやり方を踏襲しながら、レビュー待ちの件数を確かめる、詰まっている人を朝会のあとに個別に助ける、といった足りない部分だけを足していきます。レビューは、自分が見るべきもの（設計の方針、性能や安全に関わる部分など）と、メンバー同士で見られるものを分けておくと、自分がボトルネックになるのを防げます。

依頼の流れを一枚にまとめる

メンバーごとの所属、作業の依頼をどこから通すか、顧客や他チームとの約束は誰が決めるかを一枚にまとめ、PMと発注側の窓口に確かめます。ほかの会社のメンバーへの指示の考え方は偽装請負の記事で解説しています。ここがあいまいなままだと、2か月目以降に指示が二重に出たり、誰も決めなかったりします。

3〜4週目：見立てを出し、改善に合意を取る

チームの見立てをまとめる

1〜2週目で集めた情報をもとに、チームの見立てをまとめます。中身は次のとおりです。

• 計画と実態の差（残作業、品質、人の配置）
• 差の原因についての見立て
• このまま進んだ場合に起きそうなこと
• チームの中で打てる手と、PMに決めてもらいたい手

改善案は小さく、選択肢で出す

改善が必要な場合、一度に多くを変える案を出すと、チームが混乱し、見立ての誤りも大きくなります。レビューの分担を変える、チケットを小さく分け直す、担当の偏りをならす、といった小さな手から始め、体制や期限の見直しが要る話は、選択肢と影響を並べてPMに決めてもらいます。

次の1〜2か月の作業計画を引く

合意した内容をもとに、次の1〜2か月の作業計画を引き直し、チームとPMに共有します。ここまでできれば、初月の役割は十分に果たせています。

案件の型によって初月の重心は変わる

開発の途中から入る案件

すでに作業が進んでいる案件では、チームの流れを止めないことが第一です。1週目から朝会とレビューに入りつつ、チケットとコードで残作業を確かめ、遅れの芽をPMに早めに伝えます。前任のPLがいる場合は、引き継ぎの期間に、判断を保留している事項の一覧をもらっておきます。引き継ぎの進め方は引き継ぎの記事をご覧ください。

チームの立ち上げから入る案件

メンバーがそろう前に入る場合は、開発の環境、ブランチの運用、レビューの決まり、作業の分け方を先に整えることが初月の中心になります。メンバーの受け入れの手順を用意しておくと、人が増える時期に慌てずに済みます。立ち上げの時期は出社を求められやすいため、リモートとの組み合わせ方はPLのリモートの記事も参考にしてください。

品質の立て直しの案件

不具合が積み上がっているチームでは、メンバーが疲れ、外から来たPLへの警戒もあります。1週目から、不具合の優先順位づけなど目に見える小さな手を一つ打ちつつ、原因の見立ては3〜4週目に出す、という二段構えが合います。

管理と実装を兼ねる案件

自分も実装を担う体制では、手を動かすうちに管理の時間がなくなりがちです。初月のうちに、週のどの時間を管理にあてるかを決め、PMにも伝えておくと、報告やレビューが後回しになるのを防げます。

初月に避けたい動き

範囲外の依頼が増えてきたときの扱いは業務範囲が変わったときの記事、PLがつまずきやすい場面はPLのフリーランスがつまずきやすい点と対策で整理しています。

1か月の終わりに振り返ること

1か月が過ぎたら、次の点を自分で振り返ります。

• PMに、チームの見立てと改善案を伝えられたか
• メンバーごとの依頼の流れと、誰が何を決めるかが共有できているか
• レビュー待ちや長く動かないチケットが減っているか
• 契約で決めた業務の範囲と、実際の管理と実装の割合がずれていないか
• 稼働時間の記録が残っているか

ずれている点があれば、2か月目の早い段階で窓口と話しておきます。PMやPMOの初月の動き方はPMの記事とPMOの記事で扱っています。

よくある質問

前任のPLがすでに抜けていて、引き継ぎがありません。何から始めればよいですか？

チケットの一覧と不具合の一覧、直近のレビューの記録から読み始め、止まっている作業と判断が保留になっている事項の一覧を自分で作るのが近道です。そのうえで、メンバー一人ひとりに困っていることを聞いてください。引き継ぎがない状態そのものも、チームの見立ての一部としてPMへの報告に含めておくとよいでしょう。

メンバーのほうが、現場の技術に詳しい場合はどうすればよいですか？

すべての技術で上回る必要はありません。詳しいメンバーには設計やレビューの一部を任せ、PLは作業の割り振り、遅れの芽の把握、PMへの報告といった、チームとして決める役に重心を置きます。分からない点を素直に尋ねるほうが、メンバーとの信頼もできやすくなります。

初月から実装の担当も割り当てられ、管理の時間が取れません。

まずは、管理と実装にどれだけの時間を使っているかを記録し、契約で決めた業務の範囲と照らし合わせます。そのうえで、レビューや報告が遅れている事実とあわせてPMに伝え、実装の担当を減らすか、管理の範囲を絞るかを決めてもらうことをおすすめします。紹介を受けたエージェントにも早めに伝えてください。