爆速開発をしていくためのFindyの取り組み 〜2022年編〜
こんにちは、Findy CTO の @ma3tk です。最近は広背筋下部のトレーニングが好きです。この記事は開発生産性 Advent Calendar 2022の5日目の記事です。 sumiさんのコンテキストスイッチの記事では悪いコンテキストスイッチを避ける方法もあり、学びになりました！
本日は、以前出した爆速開発をしていくためのFindyの取り組みという記事にて、Findyが爆速開発できている状況やどうやって開発スピードを上げてきたのかについて書きましたが、その記事を書いてから1年半の間にどんな動きがあったのかについて振り返ってみます。
2021年よりもプルリク作成数とリードタイムはさらに改善された2022年
これが昨年の記事に貼ったプルリク作成数とリードタイムの推移です。遅いときだとプルリク作成してマージされるまでに75時間もかかっていた2020年ですが、2022年の今、以下のようなグラフになりました。
橙枠は過去記事と同期間、赤枠は記事掲載以降の期間
グラフを見てわかるように、ほとんどの期間においては
プルリク作成数の推移(棒グラフ)は右肩上がりで増えている
1日8件程度→1日85件程度と10倍以上に成長
記事執筆時から比べても1日40件から2倍以上の成長ができている
プルリクを作成してからマージするまでの時間は短くなっている
巨大なプルリクが減り、ばらつきが減った
平均して25時間を超えることなく10時間程度で安定して推移している
土日も含むデータになるのですが、土日を含めてもリードタイムは25時間を超えないのがわかるかと思います。
年末年始やGWの期間には稼働をしていないため全体で数値が悪くなりますが、プルリクを作成してから1日以内でマージができている状況が常に実現できています。
リードタイムについてはエンジニア間でのスピードは出せていると思いますので、この高い生産性をいかに維持できるかが今後のポイントかなと思います。
さらにエンジニアリング組織での開発生産性が良くなっている理由とは？
大きく4つの観点で2022年はトライし続けました。
毎月・毎週振り返り続けて改善点を見つけ続けた
ユニットテストの強化をし続け、CI/CDを整え続けた
優秀なメンバーの採用が進み、やりたかったけどやれなかったことにトライできるようになった
オンボーディングプロセスや1on1から組織の考え方を浸透させ続けた
1. 毎月・毎週振り返り続けて改善点を見つけ続けた
圧倒的に今年大事にしてきたポイントが振り返りです。特に、自社で作っているFindy Team+を元に、
どういう結果になったのか
先月(or先週)のトライの結果、どう変化したか
結果を受けてどこが課題だと感じるか
課題は解決する必要があるか
解決するとしたらどう解決するとよさそうか
今後目標はそのまま追うべきか、変化させるべきか
課題に感じていることや困っていることはなにか
などを考え続けてもらいました。少なくとも月次で振り返ってもらい、エンジニア経験が短いメンバーについてはなるべく短期間で振り返ってもらえるような動きをしました。
その結果、課題の発見が早くなったり、悩みが強くなる前にお互いに相談ができる状態が作れています。
また、Findy Team+での定量的な数値を元にお互いの「やれている」「やれていない」という感覚をすり合わせることによって、「もっと高い状態(数値)を期待している」ことを伝える場合や「そこまでこのタスクに頑張りすぎて疲れないようにタスク量や目標値を調整する」ということを行いました。
常に目線のズレを振り返りによって吸収できていたので今後も続けていきたい文化です。
2. ユニットテストの強化をし続け、CI/CDを整え続けた
バックエンドを中心にやっているメンバーが多かったため、この2年間でほとんどのプロダクトのユニットテストカバレッジは95%前後をキープし続けています。
ただ、テストカバレッジはあくまでも目安であり、「守れるテストになっているのか」を常々考えながらユニットテストを書いてもらっています。カバレッジアップのためのテスト追加は昨年のうちに終えたので、本格的に守りに行くことを昨年から続けてきました。
守りに行くテストを作り続けると、「動くかどうかわからない」という不定な状態が排除でき、「挙動が確認できているのでAPIとしては想定した範囲は問題なく動くことが保証されている」が実現できます。
ただ、そのテストを強化した結果、テストケースが増えたことでCI/CDの時間が遅くなり、結果としてプルリクのマージまでに時間がかかるという時期もちょいちょい発生しました。
ユニットテスト実行サーバーの高速化
ユニットテストの並列化
キャッシュサーバーの利用
などのチューニングを行い、なるべく実行時間を減らせるような取り組みも昨年に引き続き行ってきました。
自動化テストが書きやすいシステムに変化させることがファーストステップですが、合わせてテストを実行して安全であることが高速で確認できる状態を維持し続けるのを行い続けた2年でした。自動化テストの大事さを毎日感じています！ｗ
3. 優秀なメンバーの採用が進み、やりたかったけどやれなかったことにトライできるようになった
これは1と2の動きをし続けた結果として、「開発生産性もあがったけど、採用にも有効である」ということです。
多くのエンジニアは、優秀な人と働きたいと思う方が多いと思います。採用候補者に対しても、優秀な人で集まれている環境と伝えることで、意思決定の一因になってもらえてることを入社理由のヒアリングで聞けています。
どの会社さんも「うちはいい会社ですよ」と採用広報を行っているかと思いますが、広報の先に「数値的にいい」が伝わるとよりわかりやすく具体的にいいことがわかります。
例えば、上述したFindy Team+の数値以外にも稼働人数と平均プルリク数の数値を持って良い状況がキープできてますよ、と候補者にお伝えすることもあります。
こちらがFindyの稼働人数と平均プルリク数の推移です。稼働人数は8人→31人程度と4倍程度人数が増えています。また、人数が増えてくるとコミュニケーションの壁などが出てきてプルリク数が落ちてくることもありますが、少しの減少で生産性を維持し続けられていることがわかります。31人程度の稼働で平均2.85件ほどプルリクを全員が出し続けられている状態でも非常に良い環境かと思っています。
こういった状況を伝えた上で優秀な人達がさらに入社してくれることで「やりたかったけどやれなかったこと」が「やりたかったし、今改善できているか実現できていること」に変化してきました。
例えば、
古くなったアーキテクチャの設計変更
肥大化した共通コンポーネントのリメイク
AWS等のインフラの移行
難易度の高いバージョンアップの実施
データ取得機構・分析基盤・MLOpsの整備
デザインシステムへのチャレンジ
CI/CD環境の整備
といった、人数が多くないとできなかったアクションにチャレンジできています。優秀なメンバーの参画が開発生産性に寄与するようなことも日々行えているため、想定以上にスケールする組織になっていることを感じています。
4. オンボーディングプロセスや1on1から組織の考え方を浸透させ続けた
開発生産性が高くなることで、僕自身もプレイヤーとしてのお仕事がこの1年でやや余裕が出て、先んじて組織のことに目を向けられるようになりました。
僕のプレイヤーとしてのお仕事が減ってきたので、「爆速で価値を出してもらえる状態にするために初速を良くする」というのをこの数ヶ月トライしてきました。
例えば、
新入社員によく聞かれるQ&A資料の作成
新入社員と既存メンバーのチーム1on1を実施
目標設定の仕方、振り返り方法を周知
ウィークリーで1on1の仕方や相談の仕方をクリアにした
佐藤のことをもっとわかってもらうためにトリセツを作った
(これから) 入社時2週間物理出社してもらうことでオンボーディング効率化
上記のようなドキュメントや仕組みを作ることによって、入社後半年後に成果が出る状態ではなく、今月からすぐに成果が出る状態を目指してよりプロセスを強くしていこうと思います。いろんな施策を実施をしてきましたが、さらに改善していきます。(上記の内容は別途記事として書ければと思います)
去年は採用が大きな課題だった
去年は採用が大きな課題だったが、僕らは開発生産性にベッドし続けて、さらに採用にも力を入れ続けて採用がうまくいき始めました。今年はオンボーディング高速化や育成、エンジニアの域を超えたプロダクト企画からデザイン、そして開発への連動のプロダクト開発全体の高速化をさらに強化したいと考えています。
メンバー数が増え、提供できる価値が増えていきますが、まだまだメンバーも増やし、開発生産性が高い状態を目指し続けて、エンジニアリングが日々楽しい、Findyのプロダクト開発が最高にいいぞと感じてもらえるような状況を作り続けたいと思います。
採用はまだまだ続けていきますし、メンバー全員がテックリードをおまかせできるような技術力、(必要あればマネジメント力も)を向上させ、最高のエンジニアリング組織を実現し続けます。
僕たちの2022年のエンジニアリングの結果がご参考になれば幸いです！