ミツカリにおける昔の開発生産性計測と今後(Findy Team+導入)
※この記事は自分が所属する組織で書いた以下の記事のコピーです。投稿した記事は個人の著作物として自ブログにコピーして良いルールとしています。
https://tech-blog.mitsucari.com/entry/2025/03/28/120629
こんにちは、ミツカリCTOの塚本こと、つかびー(@tsukaby0) です。
ミツカリでは2025年からFindy Team+というSaaSを利用しています。
このサービスはgitリポジトリ、GitHubを分析し統計情報から様々な情報を可視化、組織の開発生産性向上を行うようなサービスです。
今回の記事ではこのサービスを導入する以前の弊社の計測方法と、導入直後の運用や所感などを共有します。
※この記事はタイアップでも広告でもなんでもありません
昔の開発生産性の計測
私はミツカリ社の創業メンバーではなく、創業4年目(2018年)からJoinしました。その頃は特に効率や生産性という言葉が今より頻繁に使われる時代ではありませんし、Four keysという用語がまだ世に出たばかりの頃でした。
2020年頃までは前CTOが開発組織を統括していましたが、その頃は開発生産性を高めていこう、計測していこうという文化は確立されていませんでした。明確な理由はないですが、おそらくは用語や世の中の文化として浸透していなかったということがありそうです。また、エンジニア全員がシニア以上だったので、各自自走できるでしょう(自分で改善できるよね)、という考えが多少なりともあったのかなと思います。
現在の開発生産性の計測
前CTOが退任した2020年頃から私が開発部長として採用や組織の再構築をしてきました。当然ですがより素早く顧客の要望に答え、革新をもたらして行くことが開発部には求められます。そのため自然と生産性に目を向けるようになりました。
私がFour keysという用語を知ったのは2023年頃だったと記憶しています。そのため、Four keysで言うところの変更障害率やサービス復元時間は当初測ろうと思いませんでした。また、変更のリードタイムについても、測りたいし測る必要がありそうと薄々思っていてもなかなか難しくて、できていませんでした。用語を知った今でもこれら全てを測りたいというモチベーションはないので、完全にFour keys通りやろうとは思っていませんでした。
独自に計測する路線を歩んできましたが、測ってきたものは以下の２つです。
- MergeしたPR数(commit数)
- リリース数
ミツカリでは創業時からSquash mergeを基本としてきました。Squashしている理由は履歴を綺麗に保つため、という理由です。
Squashしているため、MergeしたPR数とcommit数は一致します。そのため、計測は楽で、四半期や半期に一度以下のコマンドを実行するだけです。
tsukaby@tsukabyair ~/I/mitsucari (master)> git shortlog -ns --since="2022-07-01" --until="2023-01-01"
987 dependabot[bot]
701 Shuya Tsukamoto
582 Another Developer
...
※上記のコミット数の数値は適当です
ミツカリではCI/CDを構築しているため、masterブランチにPRがmergeされると自動でSTG環境にデプロイを行います。しかしこれを計測してもあまり意味はなくFour keysでも本番環境へのリリースを指標としています。
前回、Slack Workflowを使ってリリースの通知を行っているという記事を書きました。本番環境へのリリース数はこの仕組みを使って計測しています。
https://tech-blog.mitsucari.com/entry/2025/03/26/184503
具体的にはワークフローのステップでSpreadsheetに行を追加するようにしています。そのため、特定の期間で誰が何回リリースしたかは計測できます。
計測した値の利用
計測した値は半期ごとに行う全社的な振り返りの際に利用していました。開発部が日々改善していることや成果のアピールに繋がります。
※半期ごとの振り返り資料の一部
また、各開発メンバーの定量的な評価や振り返りにも利用していました。例えばコミット数が多少他のメンバーより少なくてもリリース作業を頻繁に率先して行っていたメンバーはその点で評価できます。
課題
このやり方には以下の課題がありました。
- 生産性向上のためにより詳細に分析を行いたいが、その値は見れない
- gitから分析するのではなくGitHub APIから値を取得すれば分析可能であるが、自作するのが面倒
- データを手動で集めなければならず統合されていない
- コミット数と生産性に相関はあると思うが、完全にそれだけで計算できるものではない (コミットに応じて生産した価値は異なるなど)
例えばミツカリには２時間レビュールールというものがあります。２時間という基準を設けたのは私ですが、前CTOの時代から似たような文化がありました。これが生まれた背景としては、前CTOが自分がブロッカーとなって他者の仕事を妨げてしまうことを嫌っていたためです。私自身も過去のチームでブロックしてしまうこともブロックされてしまうことも経験してきたので、気持ちはわかります。
とにかく基本的に２時間以内にレビューすることをルールとしていますが、必ずしも守られるとは限らないので、レビューや修正にどれくらい時間がかかっているか知りたくても知れません。GitHub APIを使えば把握できますが、そのような仕組みを自作したくもありません。
例えば以下のようなGitHub Actionがあり、これを使うとそのようなことができます。
https://github.com/github/issue-metrics/tree/main
ただし、これは統計情報をMarkdownファイルとして作成し、GitHub Issueとして投稿するというものです。ミツカリではIssueは使わずに外部のプロジェクト管理ツールに情報を集約しているので、Issue機能を禁止しています。そこをオープンしたくありません。
Issueとして作成するのではなく、Slackに投稿したいですし、そのような開発をしてみたことはあります。ただし、SlackはMarkdown形式とは少し違うのでフォーマットが崩れてしまいます。
結果的にこのGitHub Actionの利用は停止しました。
これからの計測 Findy Team+
上記のような課題を解決しつつ開発生産性を計測することができます。それがFindy Team+です。
GitHubと連携して統計情報を取得でき、1箇所に統合されるため、運用はとても楽です。
(データを集める等の運用は楽ですが、導入後の地道な改善活動が楽という意味ではありません。ただ、ある程度の使い方や改善点の提案などはFindyさんのCS担当者の方々がかなり手厚くサポートしてくれるため安心感はあります。)
各メンバーのレビュー頻度やレビュー速度、PR数などを可視化できます。リリースやデプロイについても特定のタグを付けている、特定のリリースブランチを用意している、などのケースに対応しており計測が可能です。
例えば先程２時間ルールというものを説明しましたが、それが実現できているかどうか、どこに改善点があるかはしっかりとFindy Team+で見ることができます。
これは私を含む特定のチームのレビュー分析結果です。全員2時間以内にレビューできていることが分かります。
Findy Team+を導入した動機としては開発生産性向上もありますが、採用としての側面もあります。
Findy Team+では毎年表彰を行っています。
弊社では受賞を狙って現在Findy Team+で日々改善を行っています。受賞すること自体が会社・開発組織のアピールになりますし、開発者としてはこのような改善活動に真剣に取り組んでいる企業、開発者体験を向上しようとしている企業は魅力的だと感じるはずです。
まだ運用は始まったばかりですが、一定の効果を得られていると感じています。チーム全員で改善していこうという一体感を醸成できたかなと思います。個人的には素晴らしいプロダクトだと思いますし、全てのエンジニアリングマネージャ、開発組織にオススメしたいです。
今回はレビュー分析のごく一部だけを参考値として出しました。Findy Team+を利用してどう改善したかはまた数カ月後に弊社のエンジニアリングマネージャであるたなしゅんより共有するかと思いますので、公開した際はぜひ御覧ください！
※ 私は組織全体に責任を持っており、ツール選定、検討、導入した意思決定者ですが、運用および改善はEMのたなしゅんさんが頑張ってくれています
Findy Team+のリンクはこちら。
現在、ミツカリではITエンジニアを募集しています。興味のある方はぜひお気軽にご連絡ください！