![見出し画像](https://assets.st-note.com/production/uploads/images/133174468/rectangle_large_type_2_6e7dd3342fa7d68b4e15f2b7b4ed54c3.png?width=800)
Findy Team+を導入して、リリースまでの時間が1/3に減った話
mentoではFindy Team+を導入して開発生産性をトラックして改善しています
可視化し改善することでリリースまでのリードタイムが1/3ほどに短縮できたので、その時の話をシェアします
メンバーが増え、Pull Requestが溜まりがちなチーム状況
開発メンバーとしてはフルタイム・業務委託エンジニアが3人ずつだったのですが、GithubでPull Requestが常に20個くらい溜まっている状態が続いていました
![](https://assets.st-note.com/img/1709785182112-s1usHSwFy4.png?width=800)
生産性の指標を置いておらず、トラックもしていなかったので、チームの状況が良いのかどうかもわからない状況でした
ここ1年ほどでチームメンバーも増えてきたこともあり、そろそろ定量的に開発チームの目標を置きたくなってきました
とはいえ、指標作りからやり始めるほど時間に余裕はないし、独自のものを置いたりはしたくなかったのでFour Keysをメインに考えていきました
Four Keysのうち、リードタイムにフォーカスした
ご存知の通り開発生産性を図る指標であるFour Keysには4つの指標があります
![](https://assets.st-note.com/img/1709785249657-gr9m8xOQhb.png?width=800)
最初から全てを追っていくのは難しい(注1)と判断し、スピードに関する指標に初手としてはフォーカスしようということになりました
その中でも課題感も大きいリードタイムにフォーカスすることで、リリース頻度も上がるだろうと判断しました
![](https://assets.st-note.com/img/1709785296828-X5CrV0PEVi.png?width=800)
(注1)
余談ですが、Four Keysのうち、変更障害率やサービス復元時間はトラックするのが難しいと感じています。
特にトラフィックがそこまで多くないmentoのようなサービスだとリリースした後に障害がすぐに起きるとは限らないため「どのコミットが障害になったのか」を見極めるのにコストがかかり「そのコミットの復旧コミット」としてgitのcommitだったりbranchの名前をうまく紐付けることが難しいためトラッキングもうまくいきません。うまくやっている方がいたら教えてください!
数値可視化ツールを自前で作るのが難しそうだったので、Findy Team+を入れた
まずは現状を把握しよう、ということで可視化のツールを探しました
一応Four keysを可視化するツールがOSSでもあって、自前で取得することも検討しました
しかし、過去の情報をうまく取れないなどのデメリットや自前で建てるコストを考えて利用はしないこととしました
![](https://assets.st-note.com/img/1709785390608-LrpZd1WFlh.png?width=800)
Four Keys可視化の方法を調べる中で、Findy Team+が良さそうだったのでトライアルをすることにしました
トライアルしてみるとすごく使いやすく、簡単な設定で詳細に分析したり可視化をしたりがすぐにできたので、継続的に使っていくこととしました
![](https://assets.st-note.com/img/1709785652021-seMIiL3LG0.png?width=800)
レビューにリードタイムの課題があることがわかったので「レビュー最優先」を合言葉に
元々の感覚としてもあったように、数値を見てもレビューのリードタイムに課題があり、平均してレビューまで1日、マージまで3日以上かかることがわかりました
![](https://assets.st-note.com/img/1709785748877-cMTbTycIY7.png?width=800)
そこで、みんなで合言葉を「レビュー最優先」にしてレビューを優先的に捌くための仕組みとして、毎週火曜木曜に1時間ずつエンジニア全員でレビュー会を行うことと、デイリースクラムの後にレビューの時間を取るようにしました
Pull Requestがたくさんたまる原因を深掘っていくと、作業を止めてレビューをするスイッチングコストを払うのが気が引けるため結局レビュー時間が生まれない、というところに課題感があるようでした
スイッチングコスト(注2)に関してはトレードオフだと思いますが、コストを飲みつつ、レビューを優先しなければ状況は変わらないと思い、それをチームの合意としました
(注2)
スイッチングコストとは言ってますが、実際には「コードを書いているときにレビュー依頼が飛んでくるとコードを書く手を止めてレビューする」ということはほぼなく、「タスクのキリが良いときにレビューを優先的にやる」となっていて、それが現実的でちょうど良いラインになっていると思います
やり始めて2ヶ月くらいでリードタイムが1/3に削減された
最初は溜まったレビューを消化したりしていたところもあり、リリース頻度が下がった時期もありました
![](https://assets.st-note.com/img/1709785943430-xSXhlFltAP.png?width=800)
線グラフがリードタイム
しかし、1ヶ月くらいでPull Requestが綺麗になって、リードタイムが下がり始めた
![](https://assets.st-note.com/img/1709785925424-VJY2BqZk4f.png?width=800)
最終的にリードタイムが1/3ほどになり、細かい単位でリリースをするようになったのでリリース頻度も増えていきました
![](https://assets.st-note.com/img/1709785911966-7BpaqLRYic.png?width=800)
フルタイムじゃないエンジニアメンバーも含めた平均の数値で、レビューまで10hマージまで1日くらいで安定するようになりました!
![](https://assets.st-note.com/img/1710121031980-m8Od2ufjY1.png?width=800)
コストはかかる。だがレビューを最優先にするメリットもある
レビュー最優先、にしているので、スイッチングコストやレビューにかける時間は増えている感覚はあります
ですが、レビューを最優先のメリットはたくさんあったと思います
リリースを細かく頻繁に行うことで、テストも細かく行えてビッグバンリリースも減り、全体としてもリリース時の負担も減った感覚があります
同期的なレビュー時間を毎週ちゃんと確保することによって、レビュー意識が上がり、逆説的ですが非同期的なレビュー依頼もすぐに捌かれるようになりました
一例で言うと、細かい文言修正などはコミット〜レビュー〜リリースまでに15分くらいで完了することもあります
レビュー最優先の文化になったことで全体の生産性としても上がった感覚はありますし、またもちろん、ユーザーに早く価値が届きより早くチームが学び・フィードバックを得られやすくなるというメリットも大いにあるかと思います
レビュー最優先な環境で一緒に働く人を募集中!
mentoでは「コーチングとテクノロジーで日本の主観的ウェルビーイングを世界No.1にする」をミッションに、組織開発を提供しています
自分たちがウェルビーイングに働くための開発生産性を作っていきたい方、ぜひ一緒に働きましょう!
テクノロジーを用いて今後やっていきたいことは弊社CTO松山の記事をぜひ見てみてください!
採用情報についてはこちらをご覧ください!
ビビッと来た方、ぜひカジュアル面談にお申し込みください!
この記事が気に入ったらサポートをしてみませんか?