SocialDog TechBlogPublicationへの投稿
📊

きみは GitClear を知っているか 〜AI ROI をデータドリブンに分析する〜

nao
に公開
AI
Git
OKR
開発生産性
ROI
idea

はじめに

SocialDog が公開する情報ポータルやスライド資料には「GitClear」「Diff Delta」という見慣れない単語が現れます。

SocialDog 情報ポータル/会社制度/人事制度（等級・報酬・評価）/OKRについて
SocialDog 情報ポータル/会社制度/人事制度（等級・報酬・評価）/OKRについて

SocialDog 情報ポータル/採用情報 - 3分でわかる会社紹介資料
SocialDog 情報ポータル/採用情報 - 3分でわかる会社紹介資料

GitClear は開発生産性を可視化するサービスです。

https://www.gitclear.com/

日本であまり知られていませんが、GitLens で有名な GitKraken のサービスGitKraken Insights の分析エンジンも GitClear が提供しています。

SocialDog は 2023年5月から 3 年に渡って GitClear を利用しています。私は日本でもっと知られていいサービスだと考えており、この記事では GitClear について紹介します。

この記事で書くこと

  • GitClear の紹介
  • GitClear が提供する指標「Diff Delta」の紹介
  • SocialDog での GitClear の利用事例の紹介

この記事で書かないこと

  • GitClear 以外の開発分析系サービス・ツールとの詳しい比較

GitClear

https://www.gitclear.com/

GitClear は GitHub / GitLab / Bitbucket / Azure DevOps といった主要な Git ホスティングサービスと連携し、開発生産性の分析に役立つメトリクスを提供するツールです。

GitClear の CEO である Bill Harding 氏 はオンラインマーケットプレイスの Bonanza.com の CEO であった 2016 年に、開発の進捗を効果的に追跡するための構想を始め、2019 年に GitClear を正式リリースしました。

GitClear はもともと Bonanza.com の開発のために生まれました[1][2]。後述しますが、非常にデータドリブン [3] な考え方でサービスが提供されています。

Diff Delta

GitClear で特に特徴的なのは、Diff Delta という独自に設計された指標です。

https://www.gitclear.com/help/technical/diff_delta_calculation

Diff Delta は次のように説明されています。

Diff Delta is the foundational metric GitClear employs to interpret "how much meaningful change is occurring" in a repo over time.
Diff Delta は、リポジトリで時間の経過とともに 「どれだけ意味のある変更が発生しているか」 を解釈するために GitClear が採用している基盤的な指標です。

ここで述べられている 「意味のある変更」 というのが慎重に設計されていると考えています。

まず Diff Delta がどういうものかをイメージできるよう、簡単に紹介していきます。[4]

Diff Delta の計測方法

GitClear は 「第一原理思考（first principles）」 で機能を設計しており、この考え方は以下の記事で解説されています。

https://www.gitclear.com/help/understand_diff_delta_from_first_principles_stats_on_metric_stability

簡単に説明すると第一原理思考とは、「これ以上推測の余地がない前提を使って考える」ことで、語弊を恐れずにいうと 「データドリブンな考え方」 とも言えます。

上記の記事ではコード行数、コミット数、プルリクエスト数といった指標はブレ幅が大きく、判断指標とするにはノイズが大きいとされます。

Diff Delta は次に紹介する計測方法を使って、ノイズを減らした「意味のある変更」を計測しています。

コードの追加


引用: Diff Delta Explained: Calculation, Operations and Idioms - GitClear

コードを新しく追加したときに加算されます。ポイントは実際に追加された文字数などによって変わります。

「コードを追加する」ことは「保守すべきコードを増やす」ことでもあるため、一度に多くの行を追加すると、同じコード量に対するスコアは小さくなります。

コードの削除


引用: Diff Delta Explained: Calculation, Operations and Idioms - GitClear

コード追加は一行あたり最大 10 ポイントの Diff Delta が計上されるのに対し、コードの削除は一行当たり最大 25 ポイントが計上されます。

コードの削除は保守すべきコードベース全体を小さく保つ = 保守コストを下げるとみなされ、コードの追加よりもスコアが高く設定されています。

コード移動


引用: Diff Delta Explained: Calculation, Operations and Idioms - GitClear

コードを別の場所に移動するだけの差分です。Diff Delta として計上されません。

コードの変更


引用: Diff Delta Explained: Calculation, Operations and Idioms - GitClear

部分的な調整・修正を含んだコードです。

古いコードを変更したときほどコンテキストの理解に労力が必要とみなされスコアが大きくなります。

空白やタブ文字のみの修正など、一部の変更は Diff Delta に計上されません。また関数名の変更などにともなう複数個所の差分は、後述の「検索と置換」による変更として扱われます。

検索と置換


引用: Diff Delta Explained: Calculation, Operations and Idioms - GitClear

3 箇所以上の一貫したパターンの置換は「検索と置換」とみなされます。

コピーアンドペースト


引用: Diff Delta Explained: Calculation, Operations and Idioms - GitClear

複数のコミットで同じパターンの行追加が行われた場合、コピーアンドペーストとみなされ、Diff Delta は計上されません。

何もしていない変更


引用: Diff Delta Explained: Calculation, Operations and Idioms - GitClear

空行追加、空白文字種別の変更などは No-ops（何もしていない）とみなされ、Diff Delta に計上されません。

言語の検出

本記事執筆時点で 40 余りある言語を検出し、言語間のスコアは正規化されます。

https://www.gitclear.com/help/general/languages

例えばコードブロックにブレース（{ と } ）が必要な言語や、import / include 文を多用するような言語であっても、これらによってスコアが優位にならないよう調整されています。

また同じ言語間であっても、次のようなコードスタイルの違いで Diff Delta に差異は生まれません。

  • 改行が多い・少ない
  • コメント行数が多い・少ない

コンテキストの考慮

例えば以下の 2 つを比べます。i. で書く 10 行の追加 と、ii. の 1 行の修正 とでは、どちらの方が開発者にとって負担が大きいでしょうか。

i. if (x >= 0) { .... } のような if 文のコード 10 行を新規実装したとき
ii. if (x > 0) の条件を if (x >= 0) に修正することでバグを直したとき

Diff Delta では ii. のような 「単独の変更」 は、コードの前後関係の理解や挙動の検証などに負担がかかるとみなし、複数行を新規追加したときに比べ、1 行当たりのスコアが大きく計上されます。

また、Code Churn （一定期間内に破棄されたコード）は「価値を生んでいない」とみなされ、Diff Delta の計上から外されます。

つまり次のようなケースでは、すぐに破棄された X の修正分は Diff Delta に計上されず、「A と B で Y の修正を行った」とみなされます。

  1. コミット A で X の修正を追加した
  2. A に続くコミット B で、X を書き直して Y にした

他にも ファイルの種類によって Diff Delta スコアのスケーリングを調整できます。

例えば次のようなファイルの違いによって、コード一行あたりの価値が変わると考えることは自然だと思います。

  • CSS（*.css）と Python（*.py）
  • 実コード（例： *.ts や *.go）とテストコード（例：*.test.ts や *_test.go）

このため、ファイルごとに任意のスカラー係数を設定し、Diff Delta スコアの増え方を調整することができます。[5]

Code Domoins 設定
引用: Configuring and using Code Domains - GitClear

ゲーミング耐性

Diff Delta のベロシティ（期間あたりの Diff Delta 増加量）を上げるためには 「意味のあるコードの追加・修正・削除を一定以上のパフォーマンスで行い続ける」 ことが求められます。

このベロシティは GitClear 上で個人、チーム、組織全体それぞれのスコープで確認したり、ディレクトリ単位でも確認できます。

リポジトリ単位の Delta per hour（ベロシティ）を一覧で確認できる
引用: Tech Debt Inspector - GitClear

Tech Debt Inspector ではこの「ベロシティの低いフォルダ」を調べることができます。

Tech Debt Inspector でベロシティの低いディレクトリを表示する
引用: Tech Debt Inspector - GitClear

例えば「このディレクトリは開発が継続しているけどベロシティは他に比べて低いな」という気づきを得られます。

ここから「ベロシティを高くしたい」「継続的に一定の意味あるコードをコミットしたい」という動機に繋がり、「コードべースの健全性を高めよう」という動機にまで昇華することができればリファクタリングの優先度判断に繋げることもできます。

しかもその優先度は計測されたノイズの少ないデータを元に判断することができるということです。

グッドハートの法則では、「ある尺度が目標として掲げられたとき、それはよい尺度ではなくなる」と言われますが、Diff Delta は目標の指標（ゲーミング指標）掲げられたとしても、コードベースに対してポジティブな影響を与えるように設計されており、GitClear はこれを「ゲーミング耐性（gaming-resistant）がある」と表現しています。[6]

GitClear の良さ

開発生産性を分析するためのツールやサービスを調査していたとき、重要視していたのは以下の 3 つでした。

  1. データドリブンに考えられているか
  2. 実績があるか
  3. コスト感が妥当か

前述の通り、GitClear は「第一原理思考」で考えてサービスを開発しており、その点に惹かれました。

また 2016年から構想され、正式リリースまでに3年かけており、この間 Bonanza.com の開発チームで運用されていたということで、実務ベースの実績があると考えました。
そして SocialDog の開発チームで 2 週間ほどのトライアルを経て実際に有用だと判断し正式導入することを決めました。[7]

2023 年導入当時は、GitClear の導入事例は正直あまり紹介されていなかったと記憶してますが、この3年でエンタープライズ向けに採用される事例が増えているようです。

例えばアメリカの医療 IT 大手で 700 名規模の開発組織を擁する NextGen Healthcare で採用されています。

他にも 400 名規模の開発組織を擁し、2025年に「世界最高のデジタル銀行（World’s Best Digital Bank）」という賞を受賞したジョージア銀行は、GitClear が開発パフォーマンスの分析・改善に寄与したそうです。

課金体系はユーザー単位での課金で、組織・リポジトリ規模に応じたプランがあります。

https://www.gitclear.com/pricing

SocialDog の規模感（20 名程度）であれば、競合サービスの中でも比較的安く、以前に利用していたサービスよりも半額程度の運用コストになりました。[8]

また課金単位は「コミットを push したユーザー（データ集計対象とするコミッター）」ごとのため、開発に参加しないマネージャーなどは無料でレポートを見られるのがありがたいです。

SocialDog での活用

SocialDog は GitClear をどのように活用してきたかを紹介します。

OKR

SocialDog は半期ごとに OKR を設定します。[9]

各開発チーム・メンバーは半期ごとに何にフォーカスしたいかを考え、開発に集中したい場合は Diff Delta の目標を掲げています。

Diff Delta の他にもプルリクエスト作成数や Cycle Time [10] なども同時に Key Result に掲げ、全体として開発の目標を設定するようにしていますが、これらの KPI も GitClear 上で確認することができます。

Pull Request Cycle Time をリポジトリ別に確認できる
引用: Pull Request Classic Stats - GitClear

なお GitClear は以下の記事で、ソフトウェアエンジニアリングにおける KPI の種類と考え方について解説しており、しばしば Key Result を考えるうえで参考としています。

https://www.gitclear.com/five_best_engineering_kpis_and_how_they_get_cheated

声掛けタイミングの見極め

Commit Activity Browser という機能では、コミットごとの Diff Delta が時系列でバルーンの形で可視化されます。

https://www.gitclear.com/help/commit_group_pattern_screenshots

Commit Activity Browser でコミットがバブルで時系列に可視化される
引用: Commit Activity Browser - GitClear

この画面で観察できるバブルは、コミットの作り方を直感的に理解するのに役立ちます。

ヘルプページに紹介される例をいくつか抜粋します：

Distraction-heavy to distraction-free programming
引用: Commit Group Pattern Screenshots - GitClear

→ 差し込みが多かったが開発に集中できるようになった

Product launch => Quick bugfixing => Hard bugfixing
引用: Commit Group Pattern Screenshots - GitClear

→ プロダクトリリース後に細かな不具合修正に取り組み、その後難しい修正になった

Developer obsessing over a poorly understood topic
引用: Commit Group Pattern Screenshots - GitClear

→ 理解不足の機能修正に沼っており、修正とコミットを繰り返している

Senior developer working on a well-defined feature in a system they understand
引用: Commit Group Pattern Screenshots - GitClear

→ シニアエンジニアが仕様の明確な開発に取り組んでいる。理想的なパターン。

このように、バブルパターンを見ると、開発に集中できているのか、悩んでいるのか、不具合修正が続いているのかなどに直感的に気づくことができ、チームやマネージャーが必要なアクションを取りやすくなります。

オンボーディング

Cohort Report は「開発に参加し始めてからの Diff Delta の推移」を個人ごとに見ることができます。

例えば、「2024年1月に開発に参加した A さんの 2024年3月時点」と、「2026年3月に参加したBさんの2026年5月時点」で比較できる（開発に参加してから2ヶ月後時点同士で比較できる）ということです。

Cohort Comparison: 過去に参加した開発者と同期間でのオンボーディング進捗を比較する
引用: Cohort Report - GitClear

なおこのレポートは心理面に配慮されており、閲覧は当該ユーザーの承認を得る必要があります。

DORA 指標の確認

開発で必須とも言える計測指標のGoogle DORA メトリクス は当然網羅しており、Four Keys を確認することができます。

DORA タブで Release Count などの Four Keys を確認できる
引用: Google DORA Practical Implementation Guide - GitClear

なお Four Keys に限りませんが、 GitClear の集計に使われる時間指標は、各開発者のコミット時刻などから業務時間を推定して計算されるそうです。[11]

https://www.gitclear.com/help/estimating_time_used_per_commit

例えば次のケースでは、レビュー待ちの時間はほぼゼロとして扱われます。

  1. A さんが業務終了時間ギリギリにプルリクエストを作成
  2. 翌日、Bさんが勤務開始直後に当該プルリクエストをレビュー

その他良かったこと

リファクタリング

Diff Delta を OKR の指標に取り入れることで、リファクタリングが自発的に行われるようになりました。

特にコード削除はスコアが大きめに設定されているため、「使わなくなったフラグや古いコードを消すチャンスがあれば積極的に消す」という動機づけに繋がっています。

スキルへの投資と開発を進めるバランスの参考になる

一定の Diff Delta を目標として掲げ達成を目指すことを考えます。

このとき、「Diff Delta を効率よく上げる」ためには「よく理解している技術領域で開発に貢献する」という動き方になります。

逆に「Diff Delta のベロシティに余裕がある」ときは、「新しい技術領域にチャレンジしてみよう」という行動に繋げやすくなります。

このように、開発とチャレンジのバランスを、客観的な根拠をもって取りやすくなりました。

なお、Domain Experts レポート では、「どのメンバーがどの技術領域に多くコミットしているか」を確認することができ、「新しく触るコードを誰に相談すればいいか」を判断する上での参考にできます。

Domain Experts レポート: Code Domain ごとに最も詳しい開発者を一覧で確認できる
引用: Domain Experts Report - GitClear

サポート対応が速い

問い合わせや改善要望へのレスポンスがとても速く、改善要望やバグ報告に対する修正が数日のうちにリリースされることもありました。この点は安心できましたし、カジュアルにフィードバックを伝えられることにも繋がっています。

AI 時代の GitClear

ROI の変化を確認する

AI を使った開発が当たり前になりましたが、AI 利用には安くはないコストも発生します。

「AI を開発に使っているが、実際 ROI（Return on Investment、投資利益率）は実際どうなんだ」という疑問は当然でてくると思いますが、GitClear は ROI を確認するための機能を着実に増やしています。

https://www.gitclear.com/help/calculating_ai_roi_per_line_with_usage_cohorts_and_directory_breakdown

例えば AI のヘビーユーザー・通常ユーザー・非利用者で生産性と品質指標を比較できる AI Cohort Stats 機能や、AI の生成コードが Code Churn や重複コードの増大にどう影響しているか分析できる機能を提供しています。

Diff Delta by AI Cohort: AI 利用度ごとに Diff Delta の推移を比較できる
引用: AI Cohort Stats Overview - GitClear

AI の生成コードはGitHub Copilot / Cursor / Claude Code 等で集計可能です。

ちなみに Claude Code のテレメトリ集計は、Hooks を使って計測するのですが、この Hooks の最初の利用者は SocialDog の開発チームです😎

AI 時代の開発インパクトのリサーチ

GitClear は毎年 AI が開発に与える影響のリサーチペーパーを公開しています。

前述のように Diff Delta はコードのコピーや Churn を検出してスコアリングするという性質上、AI によってこれらがどのように変化したのかにも触れています。

これらのリサーチは AI 開発を議論する上での一次情報として、 Stack Overflow や DevOps.com、 LeadDev などのメディアでも引用されています。[12]

GitClear を使う上で気をつけていること

終始 GitClear を絶賛してますが、次のような注意点もあります。

英語が前提

日本語の情報はありません。[13]
UI は英語で操作する必要があり、ヘルプや機能の解説記事も英語です。

Google 翻訳 などを使ってページを翻訳すればよいかもしれませんが、ヘルプページは iframe による埋め込みで作られているからか、うまく翻訳できないことが多くあります。。

複数の指標を使って考える

冒頭に示した第一原理思考の解説記事では「There's no "silver bullet" developer metric（銀の弾丸となる開発指標はない）」と述べられています。

Diff Delta という指標は丁寧に調整されていますが、それだけですべてが判断できるわけではありません。

例えば プルリクエストの作成数 や Cycle Time といった数値を総合的に見て、全体として開発が良い方向に進んでいるのか、テコ入れが必要なのかを判断する必要があります。

なお、こういった開発指標の考え方について、
GitClear CEO の Bill Harding 氏が熱量のある記事を書いていらっしゃるので、ぜひご参考ください：

https://www.gitclear.com/blog/measuring_durable_change_velocity_in_2026_prompt_to_production_era

https://www.gitclear.com/measuring_code_activity_a_comprehensive_guide_for_the_data_driven

あとがき

改めて私は GitClear から依頼を受けてこの記事を書いたわけではありません。

一人の個人として以前から GitClear を推していましたが、AI が開発のあり方を書き換えていく中でも、GitClear は淡々と AI が生み出すコードをリサーチし、「開発がどのように変わってきたのか」「何を指標としそこから何を見出すべきなのか」を第一原理の考え方で考察し、サービスにも反映してきた様子が伺えました。

日本ではほとんど言及されることがないサービスですが、ぜひ一度お試しください。

SocialDog はエンジニアを募集しています！ 開発生産性に興味がある方はぜひカジュアル面談にご応募ください！

https://portal.socialdog.jp/recruit

脚注

  1. Static Object tracks the progress of programmers by focusing on the 5% of code that's meaningful – GeekWire や About GitClear で読める。 ↩︎

  2. About GitClear - GitClear ↩︎

  3. ここでは計測したデータに基づき意思決定・課題解決を行うこと ↩︎

  4. 詳しい式の解説は Diff Delta factors - GitClear を参照されたい ↩︎

  5. デフォルトでも設定されており、生成コードや package-lock.json などのファイルは Diff Delta が計上されないようになっていたり、マークダウンファイルや Yaml などのドキュメント関連ファイルは Diff Delta がやや高めに計上されるようになっていました。 ↩︎

  6. Measuring Code Activity: A Comprehensive Guide for the Data Driven - GitClear ↩︎

  7. Twitter（現 X）のAPI 制限騒動の最中で熟考したと言えなかったかもしれませんが、機能はわかりやすく不明瞭なことはなかったのでそのまま導入に進みました。 ↩︎

  8. ドル払いのため為替の変動を受けます ↩︎

  9. SocialDog 情報ポータル/会社制度/人事制度（等級・報酬・評価）/OKRについて ↩︎

  10. cycle-time ↩︎

  11. 指標の性質上、Four Keys のサービス復元時間（Time to Restore Services）の計算に使われる時間については、業務時間は考慮されず、純粋な経過時間によって計算されます ↩︎

  12. Press Mentions - GitClear ↩︎

  13. GitClear の日本語解説記事は調べた限りこの記事が初のはず… ↩︎

GitHubで編集を提案
SocialDog TechBlog
SocialDog TechBlogPublication

SNSマーケティングのためのオールインワンツールSocilaDogを開発しているエンジニアのテックブログです。

Discussion