⚠️ Python2or3とClaudeが使えることが前提です。
こんにちわ。
皆様。日々時間を気にして実装してますか？
私はある日「自分は実際どれくらいコードを書いてるんだろう？」と思い立ち、Gitログから作業時間を推定するスクリプトを作りました。
コマンドの中身
手っ取り早くコマンドの中身を説明します。
# Git作業時間計算フロー
## 概要
DORAメトリクスに基づいて、Gitリポジトリから特定の作者の総作業時間を計算する
## 計算ロジック
コミットする人の候補は
- GitHubのメールアドレス
- アカウント名
です。
### 1. コミットデータの収集
```bash
# 全ブランチから特定作者の全コミットを取得
git log --all --author="GitHubのメールアドレス" --format="%ai"
```
### 2. セッションベースの作業時間計算
#### セッションの定義
- **セッション**: 連続した作業期間
- **セッション境界**: コミット間隔が2時間以上の場合、新しいセッションとする
#### 計算アルゴリズム
1. コミットを時系列順にソート
2. 各コミット間の時間差を計算
3. 2時間以上の間隔があれば新セッション開始
4. 各セッションの作業時間を計算（最小30分/セッション）
5. 各コミットに15分の準備時間を追加
### 3. メトリクスの計算
- **総作業時間**: 全セッションの合計時間 + (コミット数 × 15分)
- **平均コミット間隔**: 同日内のコミット間隔の平均
- **人日数**: 総作業時間 ÷ 8時間
## 使用方法
もしファイルを作らずに結果を取得可能ならそうする。
### ワンライナーでの実行
```bash
# コミット数を取得
git log --all --author="GitHubのメールアドレス" --format="%ai" | wc -l
# 期間を確認
git log --all --author="GitHubのメールアドレス" --format="%ai" | sort | head -1
git log --all --author="GitHubのメールアドレス" --format="%ai" | sort -r | head -1
```
## 計算例
```
総作業時間: 214.7時間
コミット数: 411
平均コミット時間: 124分
人日数: 26.8
```
上記のテンプレートで出力してください。
## 注意事項
- このアプローチは、実際の作業時間の推定値です
- セッション最小時間（30分）とコミット準備時間（5分）は調整可能
- 長期間のプロジェクトでは、実際の作業時間と差が出る可能性があります
## 最後に
- 今回のフローで作ったファイルは、必ず最後に削除してください。
- この指示は必ず日本語で記載してください。という感じで「GitHubのメールアドレス」と書かれている部分を自身のGithubに登録したメールアドレスに登録し、
~/.claude/commands/git-total-time.mdに保存してください。
実際に使ってみる
このスクリプトを ~/.claude/commands/git-total-time.md に保存しておけば、Claude Code から次のように呼び出せます。
/git-total-timeこれで、自分がどれくらいの時間を費やしてコードを書いたのかを、コミットログをベースに推定して表示できます。
普段なんとなく「今日はたくさん書いた気がする」「最近あまり進んでないな」と思っていた感覚を、数値として確認できるのはなかなか新鮮です。
DORAメトリクスとは
DORAメトリクス（DevOps Research and Assessment） は、GoogleのDORAチームが提唱した、ソフトウェア開発チームのパフォーマンスを評価する指標群です。7年以上にわたる研究に基づいており、速度と安定性の２つの視点からチームの成熟度や改善点を測定できます。
4つの主要なメトリクス（Four Key Metrics）
種類 | 指標 | 説明 |
|---|---|---|
速度（Velocity） | デプロイ頻度（Deployment Frequency） | 本番環境へのリリースの頻度。頻繁なリリースは高効率を示す指標 |
変更のリードタイム（Lead Time for Changes） | コードコミットから本番反映までの時間。短いほど開発プロセスが効率的 | |
安定性（Stability） | 変更失敗率（Change Failure Rate） | 本番リリースで失敗（ロールバックや修正対応など）が発生する割合。低いほど品質が高い |
復旧時間（Time to Restore Service / MTTR） | 障害発生から通常稼働に戻るまでの時間。短いほど回復力が高い |
これら4つのメトリクスは、開発の速度とリリースの品質は相反しないことを研究が示しており、高パフォーマンスを目指すチームは両面で優れている傾向があります 。
信頼性と背景の資料
DORAメトリクスの起源や目的、研究の背景などは、Google公式のMatterでも紹介されています 。
mablとBigQueryによるDORAメトリクスの改善 | mabl
mablの強化されたBigQuery統合により、ソフトウェアテストの可視性とコラボレーション性が向上しました。これにより、DevOpsを成功に導くことができます。
また、GitLab や New Relic のドキュメントにも具体的な活用法や意義が記されています 。
DevOps Research and Assessment (DORA) metrics | GitLab Docs
Gain insights into DevOps performance and identify opportunities for workflow improvements.
なぜ今回のコマンドに採用しているのか
- コミットログを「時間の粒度」として扱いやすい
リードタイムの基本は「コードが変更されてからユーザーに届くまでの時間」ですが、個人に置き換えると「コミットが行われるまでの作業時間」と捉えられます。
- 実作業を完全に記録するのは難しい
実際には設計・調査・休憩などが混ざりますが、コミットは「区切りの証跡」として残るため、一定の妥当性を持つ時間単位になります。
- 改善ポイントを見える化できる
「平均コミット間隔」や「セッションの長さ」を可視化することで、
集中して短いサイクルで進めているのか
まとめて一気に作業しているのか
など、自分の開発スタイルを客観的に分析できるのが大きな利点です。
実際の使用例
それでは過去に作ったpotgさんのポートフォリオサイトで使ってみましょう。
過去に作った
potg portfolio
イラストレーター兼マンガ家のpotgです。SNSで日常や空想をユーモア混じりのタッチで描いています。シンプルな線画から色彩豊かな作品まで、私の絵で少しでも笑顔を届けたいです。
のサイトのリポジトリをローカルにクローンしてclaudeコマンドを実行後に /git-total-time を叩いてみます。
こんな感じで出力をしてくれます。2回実行して同じような出力をしてくれました。実際には仕事終わり家に帰ってからの20時〜24時の4時間くらいの間で2週間くらいで実装したので精度的にはあっていそうです。
というわけで
あくまでGithubにリポジトリがあることが前提ですが、結構重宝してます。
ページ数は少なくても演出が多いサイトなど、自身がどれくらいのレベル感なのかどれくらいで実装したっけ？となることが多いので(特に並列してサイトを作っていると)かなり重宝しています。