見出し画像

Findy Team +を通じて開発者体験向上を目指すミチビク(実データ公開します


導入

2024年1月から、Findy Team+を導入いたしました!
導入してこれから頑張っていくぞ!という期待を込めてnoteを書かせていただきます!
また、導入して約1ヶ月がたっての効果も少し記載させていただきます!
実データも公開するので、ぜひ見てください!

目的:開発チームの生産性向上

生産性向上の背景と目標

エンジニア1人あたりの生産性を向上させると共に、開発者体験がよくすることを第一目標として導入いたしました。
Findy Team+を導入するまでは、ミチビクの開発チームはイケているよね!っていうことは社内ではわかっていました。なぜなら、いつもオンスケでロードマップ通りに機能をリリースできていたからです。しかし、定量的にどこにボトルネックがあって、どのような改善をすればいいのかというアイデアがなかなか浮かばず、さらによくするというアクションが取れていませんでした。
したがって、目標は、2024年度のFindy Team+ Awardで受賞されるくらいの数値にすれば、ミチビクの開発チームは、イケているよね!っていうことが証明できるのではないか?という仮説の元、1年間チャレンジする意思決定をしました。

導入直後のスコア

Findy Team+を導入直後の「開発生産性スコアβ」です。
アウトプットスコアは、かなり良い状態ですが、リードタイムスコアがあまりよくないので、リードタイムスコアの改善が急務でした。

リードタイムスコアは、弊社は月1の定期的なリリースをしているので、顧客に直接影響のあるスコアではありませんが、開発体験の改善には必要なスコアです。

たとえば、レビューされるのが遅かったりすることで、開発者の体験が損なわれていたり、Approve後のマージが遅かったりすると、Merge Conflictが発生してしまう可能性が高くなってしまったりするといった感じです。

具体的な改善例


Approveしてからのマージ速度改善

Approveされたら、すぐマージしていいのですが、弊社では月1回のリリースに間に合わせればいいというのが暗黙的な慣習になっていたので、Approveされてから、すぐにマージしようという意識が少なかったです。
ここはすぐに改善できるので、最終レビューワーが承認したら、マージするようにして、スコアの改善をしています。

Pull Requestのレビューしてからのマージまでの速度改善

レビューしてから、Approveまでの時間も少し長くかかってしまっているようでした。
原因として考えられるのは、指摘事項が多いことです。そのボトルネックとなっていたのは、Pull Requestの大きさであると考えました。


弊社では、1機能1エンジニアをコンセプトに、フルスタックに開発をしています。そのため、あまりPull Requestの粒度は気にせずに、フロントエンドもバックエンドもインフラ(CDKでTypeScriptで書いています)も1つのPull Requestで出してしまうということがありました。

Pull Requestを大きくしてしまうと、レビューワーの負担になると同時に、見過ごしがあったり、コメントの数が大きくなってしまうので、可能な限り小さな粒度で大体(300-500行)で出してもらうように運用を改善しました。


レビューワーの一極集中問題の改善

レビュー大変だなーと肌感覚では感じていたのですが、CTOである金杉は、1年間で、1345件のレビューをしていたようです、、、
これをみて、レビューワーを社内で育成する必要を実感しましたので、現在レビュー体制の見直しも行っております。

Dependabotの運用改善

弊社では、Dependabotで日次で3つのバージョンアップのPull Requestを自動で作成しています。パッチバージョンであれば、自動マージをしていて、なにかあったら、E2EテストのAutifyで自動リグレッションテストを走らせているので、そことCIで防ぐ仕組みを取っています。

ただ、DependabotのバージョンアップのPull Requestは、そこまで優先順位が高くないので、レビューワーもやったりやらなかったりみたいな運用をしていました。

そこで、Dependabotのバージョンアップの頻度も見直し、Pull Requestがきたら、すぐにレビューするように改善を進めています。


1ヶ月後の成果


リードタイムスコアが7改善し、開発生産性スコアも4上昇することができました。

また、副次的にですが、開発チーム全員がみんなの開発体験をよくしようということを意識してくれるようになり、レビューしやすいPull Requestをつくってくれたりとか、レビューする速度を早めてくれて、気持ちよく開発ができるような状況をつくってくれています。


まとめ

実際にFindy Team +を導入して、1ヶ月が立ちましたが、非常に有意義なプロダクトであり、ミチビク開発チームの開発者体験がよくなっていることをスコアで定量的にも、そして定性的に実感値としても感じることができました。

導入を迷っている人もいらっしゃると思います。うちはtoBだし、Four Keysに則っても意味ないのでは?と考えている開発責任者の方々がいらっしゃると思います。かくいう自分もそうでしたが、いい意味で期待は裏切られました。

Findy Team +のCSチームの方が手厚いので、実際に自分たちのチームはこういう状況なんですけど、というのを説明すれば、その状況にあった改善案をめちゃくちゃ沢山もってきてくれます。弊社では、週次で開発生産性の振り返りをしているのですが、その議事録にも、Findy Team +のCSチームの方がコメントしてくださり、さらによくするにはどうすればいいのか?といったコメントをしてくださります。

ぜひ、今まで開発生産性を定量的に把握できていなかったチームは、Findy Team +も導入してみることをおすすめします。いろんな目的に合わせて使えると思います。

ミチビクでは、冒頭にも少し触れさせてもらったとおり、自社の開発生産性をあげて、開発者体験を少しでもよくしていき、定量的に社外の人もミチビクってイケてる開発チームだよね!って思ってもらえるようにこの一年努力していきます!!!

Findy Team +のCSチームからのコメント

導入時は3ヶ月で原因の特定をしていく予定だったものを、1ヶ月で特定〜改善にまで着手されており、みなさまのやり切り力やスピード感が本当に素晴らしいなと感じております!
改善できたものに関してはパフォーマンスを維持し、さらなる向上を目指していただければと存じます!金杉さんには積極的にTeam+をご活用頂いており、大変嬉しく思っております!
今後も貴社のさらなる生産性向上に向けてご一緒させてください!

いいなと思ったら応援しよう!