みなさん、こんにちは。
普段、エンジニアなら何気なく使っているGit。多くの現場では「ソースコードのバージョン管理ツール」として欠かせない存在ですよね。ですが、少し視点を変えてみると、Gitの履歴は単なるファイルのバックアップではないことに気づかされます。
Gitのログには、開発者が直面した試行錯誤、土壇場での設計変更、そして泥臭い問題解決のプロセスがすべて刻み込まれています。
いわば、Gitとは「開発者の思考ログ」そのもの。
今回は、Gitログから抽出できるいくつかの指標を読み解きながら、数字の裏側に隠された「エンジニアの仕事のリアル」について考えてみたいと思います。
コミット数 – 作業の「リズム」を知る
まず、最もシンプルで分かりやすい指標が「コミット数」です。
git log --since="2026-01-01" --until="2026-03-01" --pretty="%an" | sort | uniq -c | sort -nr
※指定した期間内の、作成者（Author）ごとのコミット数ランキングを表示するコマンドです。
この数字から見えてくるのは、その人の「開発のリズム」です。
- 作業の粒度： 変更をどれだけ細かく切り出しているか
- 頻度： どのくらいのペースでキーボードを叩いているか
コミット数が多い人は、一歩ずつ着実に石橋を叩いて進む「スモールステップ型」かもしれません。逆に少ない人は、頭の中で設計を完結させてから一気に形にする「一気呵成型」の可能性があります。
ただし、ここで注意したいのは、コミット数は「作業量」を正しく示すものではないということです。粒度の基準は人それぞれ。これは評価のための数字ではなく、あくまでその人の「作業スタイル」を映す鏡なのです。
編集行数 – コードへの「接触量」を探る
次は、実際にどれだけのコードを書き換えたか、という「変更量」を見てみましょう。
git log --pretty="%an" --numstat \
| awk '
NF==1 { author=$0 }
NF==3 { add[author]+=$1; del[author]+=$2 }
END {
for (a in add) print add[a]+del[a], a
}' | sort -nr
※追加行と削除行を合計し、作成者ごとの「総編集行数」を算出します。
新機能の実装や大規模なリファクタリング、あるいはバグ修正の苦闘がこの数値に現れます。
面白いのは、「削除行数」が多いときです。無駄なコードを削ぎ落とし、より洗練された設計へと進化させた証拠かもしれません。一方で、自動生成されたコードやフォーマット修正だけで数字が跳ね上がることもあります。
つまり、編集行数は「作業のヒント」にはなりますが、「仕事の質」を保証するものではない、という絶妙な距離感で眺めるのが正解です。
実働日数 – 継続的な「熱量」を可視化する
Gitからは「実際に手を動かした日数」も導き出すことができます。
git log --pretty="%an %ad" --date=short \
| sort -u \
| awk '{count[$1]++} END {for (a in count) print count[a], a}' \
| sort -nr
ここで、あるプロジェクトの二人の開発者を比較してみましょう。
| 開発者 | コミット数 | 実働日数 |
| エンジニアA | 400回 | 120日 |
| エンジニアB | 150回 | 140日 |
- Aさん： 短期間に集中して一気にアウトプットを出す「瞬発型」
- Bさん： 毎日コツコツと積み上げる「継続型」
どちらが良いという話ではありません。プロジェクトのフェーズや役割によって、最適なリズムは変わるからです。Git履歴は、こうした個々の働き方の特性を可視化してくれます。
変更ファイル数 – 仕事の「影響範囲」を見る
最後に、一度の作業で「いくつのファイルに触れたか」という視点です。
git log --pretty="AUTHOR:%an" --name-only \
| awk '
/^AUTHOR:/ { author=substr($0,8); next }
NF { files[author]++ }
END { for (a in files) print files[a], a }
' | sort -nr
変更ファイル数からは、その開発者の「役割（ロール）」が透けて見えます。
- 広範囲に触れる人： システム全体の整合性を整えるアーキテクトや、基盤修正を担当する人。
- 特定の領域を深く掘る人： 特定の機能を磨き上げる実装担当や、専門性の高いモジュールを保守する人。
自分が今、チームの中でどのような立ち回りをしているのか。それを客観的に振り返る良い材料になりますね。
Git履歴は、私たちが紡いだ「開発の物語」
さて、ここまでいくつかの指標を紹介してきましたが、最も大切なことをお伝えします。
それは、これらの数字を「誰かを評価するため」に使ってはいけない、ということです。
昨今、生成AIの活用によってコードの生成量自体は爆発的に増えています。もはや「書いた行数＝生産性」という方程式は成り立ちません。むしろ重要なのは、AIをディレクションしながら、「どのような意図でその変更を選択したのか」というプロセスの方です。
コミット履歴を丁寧に読み解いていくと、
- 「ここで設計の壁にぶつかったんだな」
- 「このバグ修正には相当な試行錯誤があったんだな」
- 「ここで将来を見据えたリファクタリングを入れたんだな」
といった、ソフトウェアが形になっていく息遣いが聞こえてきます。Gitの履歴とは、コードの変更履歴である以上に、「開発者の思考の軌跡」なのです。
たまにはGitの軌跡を振り返ろう
普段は作業の道具として当たり前に使っているGit。
たまには、自分のプロジェクトのログをじっくり分析してみてください。そこには、ただの数字の羅列ではない、「開発の物語」が隠されているはずです。
その軌跡を振り返ることで、次の開発に向けた新しい気づきが得られるかもしれません。
本日も最後までお読みいただき、ありがとうございました。
それでは、よいエンジニアライフを！
