ミツカリにおける昔の開発生産性計測と今後(Findy Team+導入)

※この記事は自分が所属する組織で書いた以下の記事のコピーです。投稿した記事は個人の著作物として自ブログにコピーして良いルールとしています。

ミツカリにおける昔の開発生産性計測と今後(Findy Team+導入) - ミツカリ技術ブログ tech-blog.mitsucari.com

こんにちは、ミツカリCTOの塚本こと、つかびー(@tsukaby0) です。ミツカリでは2025年からFindy Team+というSaaSを利用しています。このサービスはgitリポジトリ、GitHubを分析し統計情報から様々な情報を可視化、組織の開発生産性向上を行うようなサービスです。今回の記事ではこのサービスを導入する以前の弊社の計測方法と、導入直後の運用や所感などを共有します。 ※この記事はタイアップでも広告でもなんでもありません昔の開発生産性の計測私はミツカリ社の創業メンバーではなく、創業4年目(2018年)からJoinしました。その頃は特に効率や生産性という言葉が今より頻繁に…

こんにちは、ミツカリ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を使ってリリースの通知を行っているという記事を書きました。本番環境へのリリース数はこの仕組みを使って計測しています。

Slack Workflow Builder使った年休申請やリリース通知の例 - ミツカリ技術ブログ tech-blog.mitsucari.com

こんにちは、ミツカリCTOの塚本こと、つかびー(@tsukaby0) です。突然ですが、みなさんはSlackのWorkflow(Builder)機能を使っていますか？ slack.com 何らかの申請や処理フローなどをSlack上で構築できる機能です。マネージドとしてデフォルトで用意されているものもあれば、Workflow Builderで自作することもできます。ミツカリでは創業当初からずっとSlackが使われてきており、フルリモートの会社ということもあってSlackが職場という状況です。日々の相談、たとえば年次有給休暇の取得相談などもSlackで行われており、そのような定型業務の際にWo…

具体的にはワークフローのステップでSpreadsheetに行を追加するようにしています。そのため、特定の期間で誰が何回リリースしたかは計測できます。

計測した値の利用

計測した値は半期ごとに行う全社的な振り返りの際に利用していました。開発部が日々改善していることや成果のアピールに繋がります。

※半期ごとの振り返り資料の一部

また、各開発メンバーの定量的な評価や振り返りにも利用していました。例えばコミット数が多少他のメンバーより少なくてもリリース作業を頻繁に率先して行っていたメンバーはその点で評価できます。

課題

このやり方には以下の課題がありました。

生産性向上のためにより詳細に分析を行いたいが、その値は見れない
gitから分析するのではなくGitHub APIから値を取得すれば分析可能であるが、自作するのが面倒
データを手動で集めなければならず統合されていない
コミット数と生産性に相関はあると思うが、完全にそれだけで計算できるものではない (コミットに応じて生産した価値は異なるなど)

例えばミツカリには２時間レビュールールというものがあります。２時間という基準を設けたのは私ですが、前CTOの時代から似たような文化がありました。これが生まれた背景としては、前CTOが自分がブロッカーとなって他者の仕事を妨げてしまうことを嫌っていたためです。私自身も過去のチームでブロックしてしまうこともブロックされてしまうことも経験してきたので、気持ちはわかります。

とにかく基本的に２時間以内にレビューすることをルールとしていますが、必ずしも守られるとは限らないので、レビューや修正にどれくらい時間がかかっているか知りたくても知れません。GitHub APIを使えば把握できますが、そのような仕組みを自作したくもありません。

例えば以下のようなGitHub Actionがあり、これを使うとそのようなことができます。

GitHub - github/issue-metrics: Gather metrics on issues/prs/discussions such as time to first response, count of issues opened, closed, etc. github.com

Gather metrics on issues/prs/discussions such as time to first response, count of issues opened, closed, etc. - github/issue-metrics

ただし、これは統計情報を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+ Award 2024」〜約450社・20,000チームから、多様な観点で優れた48社を選出〜 | ニュース | ファインディ株式会社(Findy Inc) findy.co.jp

金融業界における柔軟な開発スタイルへの転換や、自動車産業を支える開発組織が経営計画に組み込む開発生産性向上プロジェクトなど、5社の事例発表エンジニアのプラットフォームを提供するファインディ株式会社（東京都品川区、代表取締役：山田裕一...

エンジニア組織の開発生産性スコアが優れた企業を表彰「Findy Team+ Award 2025」募集開始【締切：2025年6月末】 | ニュース | ファインディ株式会社(Findy Inc) findy.co.jp

〜今年は、大手企業のDX内製化組織づくりでの活用や、AIエージェント導入も高く評価予定〜累計会員登録数20万人、登録企業数3,000社（※1）が利用するエンジニアプラットフォームを提供するファインディ株式会社（東京都品川区、代表取締役：...

弊社では受賞を狙って現在Findy Team+で日々改善を行っています。受賞すること自体が会社・開発組織のアピールになりますし、開発者としてはこのような改善活動に真剣に取り組んでいる企業、開発者体験を向上しようとしている企業は魅力的だと感じるはずです。

まだ運用は始まったばかりですが、一定の効果を得られていると感じています。チーム全員で改善していこうという一体感を醸成できたかなと思います。個人的には素晴らしいプロダクトだと思いますし、全てのエンジニアリングマネージャ、開発組織にオススメしたいです。

今回はレビュー分析のごく一部だけを参考値として出しました。Findy Team+を利用してどう改善したかはまた数カ月後に弊社のエンジニアリングマネージャであるたなしゅんより共有するかと思いますので、公開した際はぜひ御覧ください！
※ 私は組織全体に責任を持っており、ツール選定、検討、導入した意思決定者ですが、運用および改善はEMのたなしゅんさんが頑張ってくれています

Findy Team+のリンクはこちら。

経営と開発現場をつなぐ戦略支援SaaS Findy Team+ findy-team.io

Four Keysなどの開発アクティビティや開発者体験データを自動で可視化し、チームの課題発見・改善を支援。データに基づく改善で開発スピードを加速。

現在、ミツカリではITエンジニアを募集しています。興味のある方はぜひお気軽にご連絡ください！

株式会社ミツカリの全ての求人一覧 herp.careers

株式会社ミツカリの全ての求人一覧です。