社会人5年目、ひよっこPL2年目を振り返ってみる

はじめまして。
東京でモバイルアプリ開発をしているふっち(@shofucchi)です🐱

新卒入社3年目の終わりあたりからPLをやりはじめ、もうすぐ今いるプロジェクトを離れるタイミングになったので、自分なりにやったこと・わかったことを振り返ろうと思い書いています。

〜2023年11月

2023年11月現在、とある会社さんのプライムベンダー企業としてアジャイル手法でモバイルアプリ開発をしています。

Android/iOSどちらも開発していて、自分含めて6人チームのPLをやっています。
2021年の冬あたりからPLをはじめて、気づいたら約2年経っていました。

今までのメンバー経験や先輩リーダーなど身近なところを参考に、自分なりに試した中で印象に残っているものを記載します。

やったこと🏃

「!」 や絵文字を多用した。リアクションを多用した。

流行病で絶賛フルリモートワークの最中PLになったので、チャットでのコミュニケーションが主でした。

相手の顔が見えないので簡素なチャットよりかは、「!」や絵文字やリアクションで親しみやすさを伝えるよう意図的に使いました。

好きな絵文字は 🐱 です。

レビューとは、を共有した。

チームはほとんど若手メンバーで構成されていたので、レビューは基本的に自分が行なっていました。

レビュー＝指摘、レビュー対応があるということは自分に至らない点があると捉えるレビュイーも見かけたので、レビューは品質のために成果物に対して行うものであること、レビュワーも間違ったコメントをしてしまう時があるので、レビューを通して対話することでお互い品質に貢献できたら嬉しいとレビューについての自分の考えを共有しました。

会話の中でも「指摘」ではなく「コメント」と呼ぶよう徹底したり、レビュイー本人が考えてアウトプットできるよう問いかけでコメントをしたり、対話である意識づけをしました。

プルリクのテンプレートを作った。

一個上でも記載しましたが基本全て自分がレビューをしていました。
チームには初学者の方も多く、ちょっとした箇所でのレビュー対応はお互いに疲れてしまうため、レビュー負担をなるべく減らすためにプルリクテンプレートを作成しました。

プルリクの目的やセルフレビューチェック、どこからレビューした方が良さそうかなどを記載してもらいました。

自分の負担を減らすと同時に、メンバーも将来レビューをする経験が必ずあるので、レビュワーの立場も意識してもらうきっかけになったらと思い作成しました。

実際のテンプレート。
レビュイーの負担も考えて(optional)の箇所は任意で良いルールにしてました。

勉強会を実施した。

チームに初学者の方がいること、Android/iOSでエンジニアがわかれていないことから学習のきっかけになれるよう定期で勉強会を開くようにしました。

テーマはデザインパターンやアーキテクチャ、標準APIや非同期処理ライブラリなど開発に必要な基本スキルを扱いました。

自分は入社からAndroid開発が主だったのでiOSに馴染みがなく、勉強会や日頃のサポートに備えてiOS中心で学習していた時期もありました。

障害分析をチーム内で回した。

単体試験やユニットテスト後の受入試験・結合試験で出た不具合は、障害分析をチーム内で行い、障害発生原因に対して向き合ってもらいました。

障害分析では障害が起こったことを責めているのではなく、起こってしまったことに対して次からどう防げるかを考えるのが大事であることをチームの共通認識としてはじめに伝えて原因を考え、出てきた施策は次回実行するようにしました。

わかったこと💡

レビューとは、は今後も伝えていきたい。

レビューを恐れず対応してもらえるようになりました。

対話としてやり取りが進んでいくため、どうしてこうしたか理由を深めていったり、こちらの方が良いのではといったアイデア出しをお互いにできたことが良い点だと思いました。

自分の知らないことをレビューを通してメンバーから教えてもらうこともありました。

Win-Winな関係はお互い嬉しいし気持ち良いです。

プルリクテンプレートはアプデをしてもよかった。

テンプレート作成からしばらく経つと、メンバーもだんだん慣れてきて特にセルフレビューはチェックをただつけていくだけの作業になっていたかもしれません。

内容の見直しや、インデントなり警告なりはLintを採用することで防ぐなどを途中から検討すべきでした。
Lintに関わらず、プロジェクトにとって新しいものを採用するのは難しかったです。

Coroutinesやマルチモジュールなど採用できたものもあれば、継続的に運用コストがかかりそうなものに関してはチームの成熟度を踏まえたメリデメを自分の中でうまく判断できなく、結果そのままになってしまっているというものが数多くありました。

勉強会や障害分析はメンバー主体で声を上げてもらうのは難しい。

勉強会のテーマはメンバーから学びたいことを引き出すのが難しく、どうしても自分からテーマを決めてしまいがちでした。

自ら決めたテーマもLT形式で実施していたため、一方通行な印象が少なからずありました。

障害の分析も引き出すのが難しかったです。
どう防げるかの検討は自分自身も難しく、的を得てない意見でメンバーに負荷をかけてしまうだけにならないか不安でした。

また自分だけでなぜなぜを進めてしまい、何か意見がないか、認識あっているかを問うだけで進めてしまうこともありました。

さいごに

わかったことから反省点が多いなと思いつつ、やっぱり自分自身経験がまだ浅いのでそこから得られる知識や進め方などがうまくいかないのは当然でした。
反省点を見つけて次にどう活かすかを繰り返すことが今後にとって大事だと思っています。

一方メンバーフォローは少し頑張れたかなと思います。
人によってはぬるいと思われるかもですが、いわゆる心理的安全性を確保することがめぐりめぐって品質にもつながると考えながら過ごしてました。

メンバーフォローを頑張れたのも、自分が未経験でなんのスキルも持たない状態からスタートした経験があったからかもしれないです。

PLをやる前は人に指示してリードするのは苦手だと思っていましたが、一緒に進めると考えたら気が楽になりました。
同じように考えている新人PLさんがいて、もし少しでも参考になっていたら嬉しいです。

ここまで読んでくださりありがとうございました。

余談

PLをやったことで減ってしまいましたが、コードを書く時間はやっぱり楽しいです。
特にAndroid開発は公式がアーキテクチャやSDKなどを推奨してくれて、サンプルコードもたくさん公開しているので大好きです。（Now In Androidはモダンスキルを体系的に学べておすすめです！Material3のUIデザインもかわいい🙌）
副業でコーディングとかできたら楽しいだろうな。。🤔