ミツカリのたなしゅん(@tanashun_dev)です。
以前、弊社のつかびーさんからFindy Team+という生産性の可視化ツールの導入について記事を公開しました。
そちらのツールを導入している企業のうち、特に生産性の高い企業を表彰するイベントが先日あり、見事ミツカリが選出されました！
プレス記事やnoteも公開されておりますのでぜひそちらもご覧ください。
受賞の喜びやツールの概要などはnoteなどに記載させていただいていますので、こちらでは詳細な取り組みについて書いていこうと思います。
導入前後での変化
導入前はgithubのマージ済PRのリストを追ったり、タスクチケットから掘っていったりしないとなかなか詳細な数字を出すのは難しく、どうしても記憶や雰囲気でしか生産性を感じるものがありませんでした。
Findy Team+ではグラフィカルにgithubの活動レポートを見ることができるので、特定期間内のPRの数、平均の変更量、サイクルタイムなどが一目瞭然です。
「先週より今週はPRが5個多いね！やったね！」
といった単純な数値向上によるモチベーション向上もさることながら、
「先月に比べて今月はPRあたりの平均の変更行数が大きいからもっと作業の分割を意識しよう」
など、ボトルネックが何かがわかりやすく、取るべき改善アクションを明確にできることがすごく助かっています。
チームだけでなく個人のアクティビティも計測できるので、評価にも使いやすいです。
実際にどのくらい生産性が伸びたのか
Findy Team+では生産性のスコアに3つの指標があります。
- 開発生産性スコア
- アウトプットスコア
- リードタイムスコア
アウトプットスコアとリードタイムスコアの平均値が開発生産性スコアです。
| 指標 | 2025年1月 | 2025年7月 |
|---|---|---|
| 開発生産性スコア | 59 | 64 |
| アウトプットスコア | 62 | 71 |
| リードタイムスコア | 56 | 56 |
スコアの単位は偏差値です。
計算式は公開されていないため、利用者目線での想像になりますが、リードタイムスコアは実測値が小さい方が評価が高くなる上限値のある性質のため、分散が小さくなっているんだと思われます。
アウトプットスコアについてはPRを出せば出すほど加算されていくわけなので、こちらは努力次第でどこまでも伸ばせることになりますね。
実際にミツカリでは半年で偏差値にして9のアップを実現しています。
参考までにPR数は1月から7月で189件→487件と脅威のアップをしています。
続いてどんな取り組みがこの結果につながったのかを深堀ってみます。
特に結果につながった取り組み
まずはとにかくゲーム感覚で数字を上げようと試みました。
アウトプットスコアを伸ばすにはPR数を増やすのが一番効きそうです。
しかし、弊社メンバーも決してこれまでサボっていたわけではないので、
明日からPR数を2倍にしましょう
なんて言われても無理です。
そこで、まずは今のPRのサイズを見直すことから始めました。
これまでもいくつかルールとして制定されてはいたものの、なかなか徹底されていませんでした。
制定したルールが徹底されない理由として考えられるのは以下です。
- 制定した瞬間しか意識されず、メンバーの入れ替わりなどで形骸化していく
- 開発者自身がなぜそうするべきなのかを真に理解していないから
ミツカリは基本的には個々の考えを尊重しているので、無理強いするような制度の決め方はしません。
しかし、完全に野放しでも上手くはいきません。
そこで、今回の改善の取り組みとして、2の開発者の理解の部分からアプローチすることにしました。
PRが小さくあってほしいのはレビュワーの視点からするとごく自然ですが、レビュイーからすると本人はその負担を感じません。
むしろPRを分割して何度もPRを出す分疲れる、、、くらいの気持ちです。
そこにFindyTeam+の数値の見える化が本領を発揮しました。
弊社のエンジニアはゲームが好きなメンバーも多く、FindyTeam+の数値上げはゲームのレベル上げに近いものがあります。
成果は目に見えない形になるとなかなか実感もしずらいですが、FindyTeam+上でメンバーも自身だけでなくチーム全員の数値としての成果をいつでも見られるようになったことで、小さなPRを作るレビュイー側のモチベーションを形成することができました。
PRの分割の例をあげます。
例えば、RailsのAPIを実装するというタスクは機能としてはひとつですが、コーディングのステップとしては細分化可能です。
- Controller
- Model
- Form
- Job
- Module
- Spec
- etc...
これらの細かな実装をガッチャンコするとひとつのAPIになります。
このようにひとつの機能実装を複数のPRに分割することから始めました。
この取り組みはPR数を増やすだけでなく以下のような良い作用をもたらしてくれました。
- PRが分割されたことでレビュー負荷が大きく減り、隙間時間でレビューが可能になった
- レビューのレスポンスが高速化されたことでレビュイーの待ち時間が減って効率的にタスクが進むようになった
- レビュー内容がコンパクトになったことでレビューでの見落としや目の滑りが減った
- 何時間も作業してから方向性のミスが指摘されるということがなくなり、無駄になってしまう工数が減った
- コンフリクトがほとんど発生しなくなり、コンフリクト解消工数や、解消ミスという不安との戦いが消えた
取り組み始めもタスク数を増やすことではなく、PRの分割を意識するようにしただけだったので開発者に極端なプレッシャーがかかることもなく進みました。
また、これを皮切りに、今では機能設計時の作業タスクのリストアップもPRの粒度まで落とし込んで考えられるようになっており、タスクの実装イメージが共通理解しやすくなり、プロジェクト進行も円滑に進むようになりました。
単に分割した分のPRが増えただけでなく、上記のようにプロジェクトを円滑に進めるための様々な細かい改善が重なった結果、機能全体の実装もスピード感が大きく向上しました。
数値的な結果としてはPR数が半年でおよそ2.5倍になりました。
あまりやりすぎても逆に負担が増えてしまうので、現在はこのペースを維持することを目標としています。
もっと細かい取り組みは多々ありますが、今回紹介するのはここまでにしておきます。
もっと知りたい方はぜひミツカリで一緒に働きましょう！
私は改善手法を考えたりはしましたが、実際にこれが体現されて数値としての結果を成せたのは、同じ目標に向かって努力を続けてくれるメンバーがいたからです。
ミツカリは向上心と責任感のあるチームが魅力です！
最後に
そんなFindy Team+については下記からお申し込み可能です。
ミツカリでは新たな仲間を募集中です！ご応募お待ちしております！
