この記事は GameWith アドベントカレンダー2025 24日目の記事です

こんにちは。サービス開発部の神崎です。
エンジニア組織がどれだけ成果を出しているかを、開発以外の人にも納得感がある形で伝えるのは簡単ではありません。

プロダクトの数字だけでは開発部としての頑張りが見えにくい一方で、リーダーの主観に頼りすぎると組織としての貢献を客観的に説明しきれないからです。

GameWithでもこの評価のあり方は日々アップデートしており、今回はAIを活用して導入した新しい評価指標について紹介したいと思います。

これまで評価方法

私たちはこれまで、デリバリーの健全性を測る世界標準としてDORA指標（Four Keys）を重視してきました。

cloud.google.com

特に「リードタイムの短縮」や「デプロイ頻度の向上」は、エンジニアリングの改善が直接的に事業の価値（デリバリー速度）に直結することを示す内外の納得感が非常に高い「共通言語」だったからです。

しかし、この優れた指標を評価の主軸に据えようとするほどある構造的なジレンマに直面することになりました。

「主務」への絞り込みと計測の限界： リードタイムを正確に計測するためには、開始と終了が明確な「メインプロジェクト（主務）」に計測対象を絞り込む必要がありました。
「維持」が前提となる指標の限界： DORA指標の多くは一定の基準を超えると「高い水準で維持すること」が目標となります。しかしプロダクトが複雑化する中で数値を維持するには、絶え間ないリファクタリングや技術改善が不可欠です。「現状維持」のために多大な工数を投じているにもかかわらず、指標が横ばいであるために外からは「改善が止まっている」ように見えてしまうという問題が生じました。
「積み上げ」が見えないもどかしさ： 指標を維持するための「見えない努力」は数値としての「改善」としてカウントされません。現場のエンジニアが最も誇るべき「品質へのこだわり」や「細かな改善の積み上げ」を、組織として正当に評価しきれないジレンマを私たちは長らく抱えてきました。

AIがもたらした「リードタイム増加」の逆説

さらにAI（GitHub Copilot等）の台頭がこのジレンマを加速させました。AIを使いこなすエンジニアは、一人が複数のタスクを並行して進めるスタイルで全体の出力を最大化させます。

人間が設計し、AIが生成し、レビューを待つというサイクルを複数回すことで、組織全体の総スループットは向上しますが個別のタスクの完了期間（リードタイム）は必然的に伸びてしまいます。
事業への貢献を最大化しようとすればするほど、納得感のあったはずの「リードタイム指標」が改善されないという状況になっていました。

プロンプトによる客観的見積もりという新しい物差し

AIを導入することでこれまで実現できなかった見積もりを評価の中に組み込むことができました。

以下が実際に導入にあたって過去のデータを集計した結果です。
ここ1年でAIを活用したツールが多数登場しており、GameWithでの導入に合わせて効率化されているという現場の感覚とも一致しています。

核心となる3つの思想

「見積もり/実工数」による改善率の可視化 主観でバラバラだった基準をAIで標準化します。これにより見積もりに対する実工数の乖離（改善率）が信頼できる指標となり、チームの成長を客観的に追跡できるようになります。
エンジニア組織外（ビジネスサイド）への納得感 難しいから時間がかかるという説明をAIが出力する論理的な根拠に置き換えます。非エンジニアに対しても何に、なぜ、どれだけの工数が必要かを透明化し、組織内の合意形成をスムーズにします。
「書かれていない作業は存在しない」という品質の強制 調査や議論がログに残っていない場合AIはそれを作業工数として認めない設計にします。これにより、正当に評価されるためにプロセスを言語化するという強力なインセンティブを現場に生み出します。

仕組みのポイント：行数（LoC）に依存しない「作業密度」の解析

この思想を実現するため、評価のロジックにおいて以下の2点を徹底しています。

「行数」ではなく「変更の本質」を問う LLMが陥りやすい変更行数（LoC）による安易な推論をプロンプトで封じます。ロジックの複雑性や依存関係を分析させることで、見積もり基準をエンジニアの感覚に近いものへと標準化します。
全工程（調査〜リリース）を網羅する広域解析 PRの差分だけでなく、設計書、Slack上の議論、Issueの背景など、開発に付随する情報を全量投入します。これまで隠れていた思考や合意形成の工数を可視化し、全体の流れを評価対象とします（※この膨大な文脈を読み解く基盤として、Geminiを採用しています）。

[Appendix] 実際に使用しているプロンプト全文

※本プロンプトはブログ用に一部調整しており、サンプルの数値や内容は架空のものです。導入の際は自チームの基準に合わせて適宜チューニングしてご利用ください。

プロンプト全文を表示する

reasoning_example = """### 1. 変更規模の定量分析
- 追加行数: 1,234行（参考値）
- 削除行数: 567行（参考値）
- 変更ファイル数: 15個
- コミット数: 23個
- 変更期間: 5日間

### 2. 変更内容の分析
このPRは4つのキャラクターに対応した確率計算とシミュレーション機能を追加する大規模な変更です。

**主な変更内容:**
- Reactコンポーネントの複雑な状態管理の実装
- 確率計算ロジックの新規実装（数学的アルゴリズム含む）
- 4つのタブ間でのデータ整合性確保
- Discord API連携の追加
- UIコンポーネントの大幅な変更

**複雑性の評価:**
- 既存コードベースへの深い理解が必要
- ゲームドメイン知識が必要
- 新規ライブラリの導入と学習が必要
- パフォーマンス最適化が必要

### 3. ディスカッション・レビューの影響
ディスカッションに15件のコメントがあり、複数回の修正依頼と仕様変更の議論が確認できます。これは通常より多く、手戻りや追加調整が発生したことを示しています。初回実装後に複数回の修正が行われたことから、レビュー対応工数を多めに見積もります。

### 4. 作業フェーズごとの見積もり

- 調査: 2.5時間
  内訳: ゲームドメイン知識のリサーチ、既存コード理解
- 技術検証: 3.5時間
  内訳: 確率計算ライブラリ試用・検証、Discord API動作確認
- 設計: 3時間
  内訳: アーキテクチャ設計、コンポーネント設計、データフロー設計
- 実装: 12時間
  根拠: 新規ロジック実装の複雑性、4キャラクター分の実装、状態管理の複雑さから判断
- テスト: 4時間
  内訳: 4キャラクター × 各種パターンテスト、UIテスト、レスポンシブ確認
- レビュー対応: 6時間
  根拠: 15コメント分の修正対応、手戻り含む
- 追加修正・調整: 2時間
  内訳: レビュー後の微調整、パフォーマンス改善
- リリース作業: 2時間
  内訳: ビルド、デプロイ、ドキュメント更新

合計（estimated_hours）: 35時間

### 5. 見積もり根拠
- 実装時間: 新規ロジックの複雑性、複数コンポーネント間の連携、状態管理の難易度を総合的に判断
- 技術検証: 新規ライブラリ2個 + API連携の実現可能性確認が必要
- レビュー対応: 15コメント分の対応工数、手戻り修正含む
- コミット分析: 23コミット ÷ 5日 = 4.6コミット/日（頻繁な修正発生を示唆）"""

json_example ={
  "reasoning": reasoning_example,
  "estimated_hours": "35"
}

---------

以下のGitHubプルリクエスト(PR)の情報に基づき、業界的に中堅レベルのエンジニアが作業した場合に、このPRを完了するために必要な開発工数を時間単位(person-hours)で見積もり、指定の形式で出力してください。
この見積もりは開発チームのパフォーマンス評価の指標として使用されるため、客観性が極めて重要です。
また見積もりの精度を上げるために、5回試行し、最も妥当と思われる見積もりを最終出力として採用してください。


## 見積もりの条件
- 文章は日本語で回答してください。
- 出力は必ず以下のJSON形式に厳密に従ってください。JSONオブジェクトの前後には、いかなるテキストも含めないでください。
- ここで出す工数は設計からリリースまでの総工数です。レビューやテスト、リリース作業も含みます。
- 人間がコーディングする場合の工数を見積もってください。
- 工数の最小単位は0.5hourとしてください。
- 関連Issueが提供されている場合は、その要件や背景情報も工数見積もりに考慮してください。

## タスク規模による見積もりガイドライン

**極小タスク（追加行数100行以下）の場合:**
このような小規模な変更では、各フェーズを最小限に抑える必要があります。
- 調査: 0.5時間（リポジトリには精通しており、必要最小限のコード理解のみ）
- 技術検証: 0時間（新規技術がない限り不要）
- 設計: 0.5時間（シンプルな変更のため最小限）
- 実装: 0.5-1時間（変更の複雑性に応じて判断）
- テスト: 0.5時間（基本的な動作確認のみ）
- レビュー対応: 0.5時間（コメント数が少ない場合）
- 追加修正・調整: 0時間（極小タスクでは基本的に不要、必要な場合のみ0.5時間）
- リリース作業: 0.5時間（簡易なデプロイのみ）
- バッファ・オーバーヘッド: 0時間
- **重要: 極小タスクでは「調査1時間」「実装2時間」「テスト1時間」「リリース1時間」のような見積もりは過大です。**

**小規模タスク（追加行数100-300行）の場合:**
- 調査: 0.5-1時間程度（リポジトリには精通しており、必要最小限のコード理解のみ）
- 技術検証: 新規技術がない場合は0時間、ある場合でも0.5-1時間程度
- 設計: 0.5-1時間程度
- 実装: diffの内容と複雑性から判断
- テスト: 0.5-1時間程度
- レビュー対応: コメント数が少ない場合は0.5-1時間程度
- 追加修正・調整: 0-1時間程度（レビュー対応に含まれない微調整分）
- リリース作業: 0.5-1時間程度

**中規模タスク（追加行数300-1000行）:**
- 各フェーズを通常通り見積もり
- 実装フェーズ: diffの内容、変更の複雑性、新規実装の難易度を総合的に判断

**大規模タスク（追加行数1000行以上）:**
- 各フェーズを通常通り見積もり
- 規模によるバッファの追加はしない
- 実装フェーズ: diffの内容、アーキテクチャ変更の有無、複数コンポーネント間の連携などを総合的に判断

**重要**: 行数は参考値として提供されますが、以下の要素を総合的に考慮して実装工数を見積もってください：
- 変更の複雑性（アルゴリズム、状態管理、データフローなど）
- ファイルタイプ（通常のコード、自動生成ファイル、設定ファイルなど）
- 新規実装 vs 既存コード修正
- 削除やリファクタリングの難易度
- 技術的負債の解消
- パフォーマンス最適化の必要性

## reasoningの構造例

以下のような構造で詳細に記述してください（具体的な数値・根拠・計算式を必ず含める）：

---
### 1. 変更規模の定量分析
- 追加行数: {added_lines}行（参考値、除外パターンを除く）
- 削除行数: {deleted_lines}行（参考値、除外パターンを除く）
- 変更ファイル数: {changed_files}個（除外パターンを除く）
- コミット数: XXX個
- 変更期間: XX日間

### 2. 変更内容の分析
どのような機能追加・変更か、主要な変更内容をdiffから分析。

**主な変更内容:**
- 箇条書きで主要な変更を列挙

**複雑性の評価:**
- 既存コードの改修難易度
- 新規技術・ライブラリの導入有無
- アーキテクチャ変更の有無
- ドメイン知識の必要性
- パフォーマンス最適化の必要性

### 3. ディスカッション・レビューの影響
コメント数、手戻り・修正の量、仕様変更や設計議論の有無を記載。（1-2文程度で簡潔に）

### 4. 作業フェーズごとの見積もり

各フェーズに具体的な時間と簡潔な内訳・根拠を記載：

- 調査: X時間
  内訳: 主要な調査項目
- 技術検証: X時間（新規技術がある場合のみ）
  内訳: 新規ライブラリ試用、API動作確認など
- 設計: X時間
  内訳: アーキテクチャ設計、コンポーネント設計など
- 実装: X時間
  根拠: diffの内容から判断した実装の複雑性と難易度
- テスト: X時間
  内訳: 単体テスト、統合テスト、UI/UXテストなど
- レビュー対応: X時間
  根拠: コメント数と修正の複雑性
- 追加修正・調整: X時間
  内訳: レビュー後微調整、パフォーマンス改善など
- リリース作業: X時間
  内訳: ビルド、デプロイ、ドキュメント更新

合計（estimated_hours）: XX時間

### 5. 見積もり根拠
主要な工数の判断根拠を箇条書きで明記（3-5項目程度）：
- 実装時間: diffの内容と複雑性から判断した根拠
- 技術検証: 新規技術の有無と検証内容
- レビュー対応: コメント数と対応の複雑性
- その他の主要な判断根拠

**重要**: 
- 内訳や根拠は箇条書き1行で簡潔に記載
- 実装工数は行数での機械的計算ではなく、diffの内容から複雑性を判断
- 自動生成ファイル、設定ファイル、通常のコードなどを区別して評価

## 出力形式（JSON）

上記の内容を以下のJSON形式で出力してください。
**reasoning内の改行は自動的に `\\n` に変換されます。**
{json_example}

**正しいJSON構造:**
{{
  "reasoning": "詳細だが簡潔な文字列",
  "estimated_hours": 数値
}}

**以下の制約を必ず守ってください。これらに違反すると処理が失敗します:**

1. **フィールドは `reasoning`, `estimated_hours` の2つのみ。それ以外は絶対に追加禁止**
   - 追加情報はすべて `reasoning` フィールド内に記載してください

2. **`estimated_hours` の値は、reasoning内の「合計（estimated_hours）: XX時間」と完全に一致させる**
   - reasoning内で計算した最終的な合計値を、必ず `estimated_hours` フィールドにも設定してください
   - 例: reasoning内で「合計: 37.6時間」と計算したら、`"estimated_hours": 37.6` とする
   - この2つの値が異なると処理エラーになります

3. **JSONの構造を正確に守る**
   - 出力の最初の文字は `{{`、最後の文字は `}}`
   - コードブロック記号 ``` は含めない
   - 各行の先頭に `+` や `-` などのdiff記号を含めない

4. **reasoning内での記述ルール**
   - ダブルクオート " は使わず、シングルクオート ' または記号なしで記述
   - 括弧 () は使わず、スペース区切りやカンマ区切りで記載
   - 例: 「新規ライブラリ 2h」「手戻り修正含む」

5. **reasoning内は必要な情報を保ちつつ簡潔に**: 各セクションで冗長な説明を避け、内訳は1行で記載

---

## プルリクエスト情報

### タイトル
{title}

### 本文 (Description)
{body}

### コミットメッセージ
{commits}

### ディスカッション (コメント)
{discussion}
{issues_section}

### ファイル差分 (diff)
{diff}