課題：コミットの山が「混沌」と化すとき
5〜10人の開発チームを率いていると、コードは頻繁にプッシュされているのに、状況が全く見えない「情報不足」に陥ることがあります。プロジェクトは動いていても、誰がどのモジュールに集中しているのか、あるいはどのファイルが頻繁に変更（コードチャーン）されて不安定になっているのかを俯瞰しようとすると、途端に困ってしまいます。
素の git log を使うのは、目次のない小説を読むようなものです。デバッグのための詳細は見えますが、レポートの作成や進捗評価のために情報を集約するのは苦行でしかありません。今週Aさんがいくつのタスクをこなしたのか、Bさんが無意味な「スパム」コミットを繰り返していないかを、一行ずつ数えて確認するわけにはいかないのです。
原因：デフォルトのGit logは統計向けではない
本質的に、git log は時系列ですべての変更を記録する日記です。追跡には非常に優れていますが、以下の理由から数値の集約には向いていません。
- 情報のノイズ： 「タイポ修正」や「README更新」といった些細なコミットが重要な機能実装と混ざり合い、データが希釈されます。
- 定量化の欠如： 個々のコミットを詳しく調べない限り、実際の作業量（追加・削除された行数）を把握できません。
- 分類の難しさ： 特定の期間における各メンバーの貢献を、整理された形で抽出するのは、基本的なlogコマンドではほぼ不可能です。
解決策：標準コマンドから専門ツールまで
この課題を解決するために、私は必要とするデータの即時性や分析の深さに応じて、3つのレベルのアプローチを使い分けています。
1. Git shortlog：非常に強力な「即戦力」ツール
これはGitに標準で組み込まれているコマンドです。詳細を羅列する代わりに、コミットを作者ごとにグループ化します。週末のクイックな同期ミーティングなどで最もよく使っています。
# 各メンバーのコミット数を集計し、多い順にソート
git shortlog -sn
# 過去14日間の各メンバーのコミットタイトル詳細を表示
git shortlog --since="14 days ago"メリット： インストール不要で即座に実行でき、レスポンス速度はミリ秒単位です。
制限事項： コミット数を数えるだけで、作業の複雑さまでは把握できません。
2. Git log –stat：作業量を詳細に分析する
誰かが本当に「バリバリ働いている」のか、それとも表面をなぞっているだけなのかを知りたいときは、--stat を使います。このコマンドは、変更されたファイル数と、各メンバーの追加・削除行数の詳細を抽出します。
# 2024年初めからの特定の開発者の変更統計を表示
git log --author="Hoang Nguyen" --since="2024-01-01" --stat3. サードパーティツール：git-quick-stats と git-effort
プロジェクトが複雑なメンテナンスフェーズに入ると、どのファイルが「ホットスポット（頻繁に変更される場所）」になっているかを知る必要があります。この段階では、デフォルトのコマンドだけでは視覚的な限界が出てきます。
実践的な導入ガイド
方法1：スプリントレビュー用のクイックレポート作成
スプリントレビューの準備として、チーム全体の貢献度を俯瞰するために以下のコマンドを実行します：
git shortlog -sn --all --no-merges-s：合計数のみ表示。-n：降順でソートし、誰が最も「活発」かを確認。--all：すべてのブランチをスキャンし、フィーチャーブランチにあるコードも見逃さない。--no-merges：マージコミットを除外。マージコミットには通常新しいコードが含まれないため、これを含めると実際の数値が歪んでしまうので非常に重要です。
実体験： ある時、一人の開発者のコミット数が300件もあり、他の人は50件程度ということがありました。git shortlog -e で確認したところ、その人が2つの異なるメールアドレス（個人用と会社用）を使っていることが判明しました。.mailmap ファイルを使って同一人物として統合し、正確なレポートを作成できるようにしました。
方法2：Git Effortで「バグの温床」を見つける
どんなプロジェクトにも、触れるとエラーが出るような「デリケートな」コードファイルが存在します。私はこれらを「ホットファイル」と呼んでいます。これらを特定するために、git-extras スイートに含まれる git-effort を使用します。
# Ubuntuでのクイックインストール
sudo apt install git-extras
# 最も編集頻度の高いファイルを探す
git effort --activeこのコマンドは、そのファイルに対して作業が行われた日数と総コミット数を表示します。もし auth_service.py が3ヶ月で150回のコミットを受けているなら、それは間違いなく即座にリファクタリングが必要な最有力候補です。
方法3：git-quick-stats による視覚的なダッシュボード
ターミナル上でインタラクティブなメニューを使ってプロフェッショナルに分析したいなら、git-quick-stats はベストな選択です。
# インストール後、以下のコマンドで起動
git-quick-statsContribution stats by author セクションでは、月ごとの貢献グラフが表示されます。これを見ることで、チームが過負荷になっている時期や生産性が低下している時期を容易に把握し、適時に作業量を調整できます。
手法の比較
| 評価基準 | Git Shortlog | Git Log –stat | Git-quick-stats |
|---|---|---|---|
| 利便性 | 非常に高い（標準搭載） | 普通 | インストールが必要 |
| 詳細度 | 低い（カウントのみ） | 高め（行数） | 非常に深い（グラフ） |
| 最適な用途 | クイックレポート | タスク確認 | システム分析 |
結びに：数字に騙されてはいけない
長年のマネジメント経験から得た教訓があります。それは、「コミット数やコードの行数は、決してエンジニアの実力に比例しない」ということです。
シニアエンジニアは、たった1回のコミットと10行のコードで深刻なロジックエラーを根本的に解決するかもしれません。一方で、ジュニアエンジニアは50件の細かなコミットを繰り返しながら一週間苦戦しても、まだ終わらないかもしれません。これらのツールは、方向性を定めるための「コンパス」として使い、決して唯一のKPI（評価指標）として扱わないでください。
私の習慣は、git shortlog とコードレビューを組み合わせることです。「update」といった中身のないゴミのようなコミットが多すぎるメンバーがいれば、git commit --amend や squash commit を使って、プロジェクトの履歴を常にクリーンでプロフェッショナルな状態に保つよう指導しています。
