はじめに

みなさん、こんにちは。
この度私は、今回のプロジェクトにおいてPL（プロジェクトリーダー）を務めることとなりました。

それに際して、この記事ではPLとはどういうものか、また業務を実際にするにあたってどのようなことを心がけているかを紹介したいと思います。
PLを目指している人の助けとなれば幸いです。

PLとは

最初に断っておきますが、この記事で書くのは今回のプロジェクトにおけるPLです。
プロジェクトや部署、会社が違えばこの「PL」という言葉がさす役割も少しずつ違ってくるかもしれませんので、そこはご留意ください。

今回のプロジェクトにおけるPLとは、このプロジェクトの技術的な責任者 です。
PLとは別にPM（プロジェクトマネージャー）も存在しており、PMがプロジェクトの全責任者になります。
なのでプロジェクトの遂行という面はPMに任せて、技術的な範囲を見ることがPLの役割となります。

業務内容

業務内容を以下に箇条書きしていきます。

• システム全体の理解
• アウトラインのレビュー
• 上がってきたコードのレビュー
• 自分のタスク
• 指導教育

などです。

業務の実践方法

基本的なスタンス

まず、基本スタンスとしては、やることが多いので、任せてもいいと判断したものはメンバーに任せ、自分がやるべきだと判断したものは自分がやるようにしています。その下地を作るためには、プロジェクトのメンバーとのコミュニケーションは積極的にするようにしています。

また、自分で調べても15~20分くらいわからなかったら、メンバーに聞くようにしています。 PLになる前は、わかるまで自分で調べまくっていたのですが、PLになってからは仕事量も増えて、時間が足りなくなってしましました。

自分の時間が節約できる上に、コミュニケーションをとることもできるので、一石二鳥です。（聞かれる側は迷惑かもしれませんが笑）

システム全体の理解

ポジションが変わったことによって、システム全体を今まで以上に理解する必要が出てきました。各タスクの繋がりや、全体として見た時に、実装する際の矛盾を考慮しないといけなくなりました。

なので、メンバーが行なっているタスクは基本的には全て把握しないといけなくなり、１つ１つは簡単でもタスクの数が多くなると一杯一杯になる場面も少なくはないです。

ただし、悪いことだけではなく、メンバー時の自分のタスクのみを実装している時に比べて、より広い範囲でさまざまなことを考えなければいけないので、経験値が増えやすいという良い面もあります。

レビュー

今回のプロジェクトではメンバーが開発に着手する際に、最初にアウトラインを書きます。 アウトラインには、dbの設計であったり、大まかなデータの流れを書かれており、実装者がどのように実装していくかが書かれています。
そしてそれに加えて、実装が完了したらそのコードもレビューしなければならないので、１タスクにつきアウトラインとコードの2回レビューをします。

アウトラインに際しては、自分が考えた方法より効率がいい方法がメンバーから上がってきたり、自分が知らない技術の情報などもあったりするので、その都度勉強しなければいけません。 アウトラインで間違えるとその後も間違い続けたまま実装が進んでいってしまう可能性があるので、ここはしっかり見なければいけないところです。

コードレビューに際しては、細かな動作確認はPMがしてくれるので、自分は主にコードの質の担保をします。
基本的なコードの書き方（インデントやメソッドの使い方など）やロジックが正しいか、例外的な場合の処理などについて見たりします。

これに関してPL特有というのはなく、通常のレビューの見方と同じだと思います ただし、メンバー時のレビューと違って、自分のOKサインがないと本流のブランチにマージできないこととなっております。
なので、自分がレビューにもたついていると、メンバーの手が空いてしまったりするので、自分のタスクもありますが、状況を見てレビューはなるべく優先してやっています。
1タスクにつき2回レビューするので、例えば自分のタスクも含めて5つタスクがあったら、10個なるべく早くレビューしなければいけません。

レビューに関しては自分が責任者という都合上、他の人に任せることはできないので、他の業務を爆速で終わらせたり、任せられるものは他の人に任せたりして効率を上げることが重要だと思っています。

指導教育

新卒や、ジュニア層の方などの指導教育やヘルプを行います。
これは先輩社員からの受け売りなのですが、「ティーチングよりもコーチング」という言葉が自分の心の中に残っています。
できないからといっていきなり答えを教えるのではなく、ヒントを教えて、その人が今後も通用するような考え方を身につけてもらうというものです。

自分の体は1つしかないので、つきっきりで見るのではなく、自分のタスクの合間合間に新卒の人の仕事を見にいったりしています。

教えることによって自分の理解が深まることもよくありますし、人と話すことによって気分転換にもなるので、意外に好きな業務であったりします。

自分のタスク

PLといえば一般的には自分でゴリゴリコードを書いたりすることはないように思われがちですが、今回のプロジェクトでは、自分もゴリゴリコードを書いていきます。

意外に自分のタスクにも苦しめられます。 メンバーよりもやることが多いので、時には自分のタスクの難易度を調節することも大事だと思います。
一番難しいタスクをやることも多いのですが、自分が忙しい時は、メンバーの成長も兼ねて難しいタスクはメンバーに任せて、自分はそれより一個下くらいの難易度のタスクをやり、残りの時間を他の業務に充てる、といったやり方も有効であると思います。

終わりに

自分がPLになってみて、前任者のPLの人は涼しい顔をしてやっているように見えましたが、こんなに大変なのかと思いました。

ただし、大変なことだけではなく、自身の成長を感じる良い面も同じくらいあると思っています。

メンバーの成長も見つつ、自分も成長できるように日々頑張りたいと思います。

お悩みご相談ください