はじめに

昨今のエンジニアリングはリモートワークの普及や慢性的な採用競争の激化によって、これまでのエンジニアリングマネージメントでは対応できない場面が増えてきているようです。
Meta 社や Apple 社もマネージメントのみをするポジションを削り、開発現場にコミットすることを促しているとの報道もありました。
このように、今後は EM に頼りすぎないセルフマネージドなエンジニアリングができることが高いレベルのエンジニアとしてのスキルの１つとなっていくのではないでしょうか。

そこで自分も、ファインディ株式会社でフロントエンドエンジニアとして仕事を始めて 2 ヶ月が経ったので初月との比較をして、自分自身の働き方、エンジニアリングの方向性を俯瞰してみたいと思います。
自分が開発に関わっているFindy Team+は、過去に自分が開発マネージャーをしていたときにも活用していました。
自分自身の振り返りをしつつ、Team+をつかってどのようにエンジニアリングの振り返りをしたらよいのかの参考になれば幸いです。

開発アクティビティ

まずは俯瞰データとして、それぞれの月のアクティビティを比べてみました。
すべての項目において、2 月の数値は 1 月を上回ることができました。
これだけでも開発生産性が前月よりも伸びたことがわかりますが、さらに日毎の推移を追ってみたいと思います。

プルリクエスト数

まずは PR の推移です。
前回の入社エントリでもかいたとおり、 1 月の 1 日あたりの平均の PR 作成数は 3.1 件でした。それが 2 月は 3.7 件と微増していました。

グラフを見てみると、前月と比べて最大の PR 数やばらつきに大きな変化はないものの、ミニマムで作成する PR 数が多くなってきたことがわかります。
開発しているフロントエンドアプリケーションの全体像が見えてきて、作業の進め方が安定し、作業を素早く行えるようになってきたのだと思います。

コミット数

つぎにコミット数です。
こちらも PR 数の伸びと同じく、微増しました。

PR を出す数が増えているのでコミット数が増えるのも当然ですが、10.4 commit/day から 12.6 commit/day になったので、プルリク作成数の伸びと比べると少し伸びが大きいように思えます。
2 月は影響範囲が広いリファクタリングを中心に作業をしていたこともあり、異なるドメインで細かく変更を入れることが多かったのがいちばんの要因だと思いました。

リードタイム

最後にリードタイムを 2 ヶ月分で取ってみました。
自分の PR の作成数の平均推移と、それらの PR のレビューやマージにかかった時間を見て取ることができます。

入社直後ではフロントエンドのコードスタイルや設計意図のすり合わせをしながらの PR 作成が多かったため、オープンからマージまでの平均時間 や レビューからマージまでの平均時間 が比較的長めでしたが、
1 月中にグッと改善され、その後も 1 月末から 2 月初頭にかけて緩やかに短縮されていることがわかります。
逆にレビューからマージまでの平均時間が伸びた期間がありますが、この辺がリファクタリング作業の設計共有やすり合わせなどをしていた時期とほぼ重なるので、コードで相談していた、というログになるかと思います。

結果、PR オープンからマージまでの平均時間は現時点の合算で 3.6 hour で、2 月だけでみると 1.5 hour 程度まで速くなりました。
マージまでの時間はかなりの改善があったと見て良さそうです。。

GitHub の芝生もみてみる

前回も取り上げた GitHub の芝生ですが、順調に濃色を保っており、なんだか気持ちがいいものです。

---

自分の感覚でここ最近でいちばんコードを書いていたのが 2020 年だったので、その芝生もみてみました。

そこそこ青くなっていて、これでもまあいい感じだなぁとは思います。年間の contributions は 1,389 件だったようです。

---

じゃあ 2023 としてはどうなるのか、と見てみたのがこちらです。

すでに 871 contributions となっており、2020 年の 60%以上に達していました。
単純計算で 2023 年は、いままでいちばんコードを書いたと思っていた 2020 年の 4 倍弱の contributions をする計算になります。
しかもほぼすべてが仕事のコードで。

振り返り

開発生産性を支えてくれているもの

Findy での開発生産性は順調に改善できていました。では、なぜたったひと月で個人のパフォーマンスがあがるのか、についての所感をまとめておきたいと思います。

CI/CD・自動化がかなり進んでいる

テストの自動化やデプロイフローの自動化などはもはや開発現場では当然となっているかと思いますが、Findy の CI/CD はそれらがさらにちょっと気が利いています。

たとえばバックエンドの API がリリースされていなければならない場合は、PR template にチェックを入れるとリリース PR にそれが反映されます。
なので、「このリリースに何が含まれていて、バックエンドとの整合はとれているか？」というケース・バイ・ケースで考える必要のあるタスクが自動で可視化されています。
他にも、リリース担当者などのアサインや、PR レビューのアサインの通知など、日々の業務がコミュニケーションレベルで自動化されていることで、一日を「PR を作って出す」に集中させることができます

レビューの打ち漏らしがなく、早い

上にも書きましたが、どの PR に誰がレビューアサインされているか、自分はアサインされたか、自分の PR にコメントがついたか、など GitHub でのタイムラインが Slack にリアルタイムで通知されます。
PR を作ってレビューアサインをするとレビュアーに通知され、レビュアーがコメントするとレビューイに通知され...と言った具合です。
これによって PR 作成からレビューまでの時間がかなり短くなり、マージまでの時間も減ります。

レビューがすぐに行われるとわかっているので、全体として大きい作業もいったん PR にして出して、マージされたら続きをやるといったスピードの循環が生まれます。
これによっても個人の作業のしやすさやレビュアーにとって見やすい大きさに PR を分割することが容易になり、PR 数を伸ばすことが簡単にできるようになっています。

転職目的との照らし合わせ

前回の入社エントリでは、転職の目的として以下を掲げていました。

• プレイヤーとしての自分に挑戦したい
• エンジニア向けのサービスを開発してみたい
• 自分が使って良いと思ったものに関わりたい

いずれもこれまでの自分の力を集めてぶつけてやりたい、ということですが、まずはプレイヤーとしての自分のレベル感を再認識できた 2 ヶ月だったと思います。
いまはまだサービスの新機能をつくるよりも、既存のアプリケーションをよりメンテナンスしやすくリファクタし、開発をもっと速くするための仕事をしているので、
後者の 2 つはこれからのお楽しみということにはなります。

エンジニアリングがもっと可視化されて、自分で振り返りやキャリアを描きやすい世界になるために、技術部分のさらに先のコミットメントができるように慣れたらいいなと思います。