イテレーション 1 ふりかえり¶
イテレーション情報¶
| 項目 | 内容 |
|---|---|
| イテレーション | 1 |
| 期間 | Week 1-2 |
| 実施日 | 2026-02-28 |
| 参加者 | 開発者 1 名 + AI（Claude + Codex） |
| フォーマット | KPT |
実績サマリー¶
完了状況¶
| 項目 | 計画 | 実績 |
|---|---|---|
| ストーリーポイント | 10 SP | 10 SP |
| 達成率 | 100% | 100% |
| コミット数 | - | 11 |
| テスト数 | - | 24 |
| ビルド状態 | BUILD SUCCESSFUL | BUILD SUCCESSFUL |
| テストカバレッジ（命令） | 80% | 75% |
| テストカバレッジ（分岐） | - | 64% |
主要成果物¶
| カテゴリ | 成果物 | 数量 |
|---|---|---|
| 記事 | docs/article/java/ |
13 ファイル（index + 12 章） |
| プロダクションコード | apps/java/src/main/ |
11 ファイル / 333 行 |
| テストコード | apps/java/src/test/ |
4 ファイル / 277 行 |
| 合計追加行数 | 全体 | 4,538 行 |
パッケージ別カバレッジ¶
| パッケージ | 命令カバレッジ | 分岐カバレッジ |
|---|---|---|
tdd.fizzbuzz.domain.type |
94% | 91% |
tdd.fizzbuzz.domain.model |
74% | 31% |
tdd（App.java） |
0% | 0% |
| 全体 | 75% | 64% |
KPT 分析¶
Keep（続けること）¶
技術的成功事項¶
- TDD サイクルの厳守: Red → Green → Refactor のサイクルを全章で一貫して実行できた。テストファーストにより、設計品質が自然に向上した
- 段階的リファクタリング: 手続き型 → カプセル化 → ポリモーフィズム → デザインパターン → SOLID → 関数型の段階的進化が、記事の教育的価値を高めた
- Nix 環境の活用: 再現性のある開発環境で、環境構築トラブルがゼロだった
- 静的解析の統合: Checkstyle + PMD + SpotBugs + JaCoCo の fullCheck タスクにより品質チェックが自動化された
プロセス的成功事項¶
- Claude + Codex 分業体制: Claude が記事執筆・計画・受入を担当し、Codex が TDD 実装を担当する分業が効率的に機能した
- Conventional Commits: コミットメッセージが feat/docs/refactor/ci に分類され、変更履歴が明確になった
- 記事と実装の同期: 実装コードを先に TDD で完成させ、動作確認済みコードを記事に転記するフローが正確性を保証した
- 進捗ドキュメントの更新: release_plan.md、iteration_plan-1.md、workflow.md を同期的に更新し、Single Source of Truth を維持した
チームワーク¶
- AI 間の連携: Claude（設計・記事）と Codex（実装）の役割分担が明確で、手戻りが少なかった
Problem（問題点・課題）¶
未完了項目¶
- テストカバレッジ未達: 目標 80% に対し 75%（命令）/ 64%（分岐）。特に
tdd.fizzbuzz.domain.model（74%/31%）とtdd（App.java: 0%/0%）が低い - 第 4 部の進捗追跡漏れ: 仕上げタスク 4.1-4.4 がイテレーション計画では未チェックのまま。第 4 部の完了が進捗ドキュメントに未反映
見積もり精度の課題¶
- 第 4 部を 0 SP（バッファ）とした見積もり: 実際には章 10-12 の執筆・実装に相当な工数がかかった。バッファではなく正規の SP として計上すべきだった
- 理想時間の精度: 合計 43.5h と見積もったが、AI + Codex の並列作業により実時間は大幅に短縮された。AI 活用前提の見積もり手法が必要
プロセス課題¶
- カバレッジ閾値の CI 未統合: JaCoCo の閾値チェックが CI に組み込まれていないため、カバレッジ低下を自動検知できない
- GitHub Project の手動同期: Issue の Status 更新が手動のため、ドキュメントとの乖離が発生しやすい
Try（次に試すこと）¶
| # | アクション | 責任者 | 期限 | 期待効果 |
|---|---|---|---|---|
| 1 | App.java の除外または テスト追加でカバレッジ 80% 達成 | IT2 | IT2 開始前 | カバレッジ目標達成 |
| 2 | FizzBuzzList/FizzBuzzValue の equals/hashCode/toString テスト追加 | IT2 | IT2 開始前 | 分岐カバレッジ向上 |
| 3 | AI 活用前提の見積もり手法（SP の定義見直し） | IT2 | IT2 計画時 | 見積もり精度向上 |
| 4 | GitHub Project 同期の自動化検討（gh CLI スクリプト） | IT3 | IT3 | 同期コスト削減 |
次イテレーションへの引き継ぎ事項¶
必須対応事項¶
- イテレーション計画の仕上げタスク 4.1-4.4 を完了マーク
- workflow.md の Java 第 4 部を「完了」に更新
- release_plan.md の IT1 状態を「完了」に更新
- テストカバレッジを 80% まで改善
テンプレート確立事項¶
- 章ごとの執筆フォーマットが確立（markdown 構造、コード例の配置）
- TDD 実装の段階的リファクタリングパスが確立（Part 1-4 の進化パス）
- Claude + Codex 分業体制のワークフローが確立
- MkDocs への記事追加フローが確立
次言語（Python）への知見¶
- Python では第 4 部にジェネレータ、デコレータ、functools を含む
- pytest を使用し、JUnit 5 との対比を記事で示すと教育的価値が高い
- 型ヒント（typing）の活用を第 3-4 部で段階的に導入する
メトリクス¶
開発メトリクス¶
| メトリクス | 値 |
|---|---|
| コミット数 | 11 |
| 追加行数 | 4,538 |
| プロダクションコード行数 | 333 |
| テストコード行数 | 277 |
| テスト/プロダクション比率 | 0.83 |
| ファイル数（プロダクション） | 11 |
| ファイル数（テスト） | 4 |
品質メトリクス¶
| メトリクス | 目標 | 実績 | 判定 |
|---|---|---|---|
| テストカバレッジ（命令） | 80% | 75% | 未達 |
| テストカバレッジ（分岐） | - | 64% | - |
| テスト数 | - | 24 | - |
| Checkstyle 違反 | 0 | 0 | 達成 |
| PMD 違反 | 0 | 0 | 達成 |
| SpotBugs 検出 | 0 | 0 | 達成 |
| fullCheck | PASS | PASS | 達成 |
プロセスメトリクス¶
| メトリクス | 値 |
|---|---|
| 計画 SP | 10 |
| 実績 SP | 10 |
| 達成率 | 100% |
| 記事完成率 | 12/12 章（100%） |
| ベロシティ | 10 SP/イテレーション |
学び（Lessons Learned）¶
技術的学び¶
- Java の Stream API と Optional: FizzBuzz のような小さなドメインでも、Stream API の filter/map/collect や Optional によるエラーハンドリングを効果的にデモできる
- enum ファクトリパターン:
FizzBuzzTypeNameenum とFizzBuzzType.create(FizzBuzzTypeName)の組み合わせは、型安全なファクトリメソッドの良いサンプルになった - JaCoCo の分岐カバレッジ: equals/hashCode の生成コードやエラーパス（switch default 等）が分岐カバレッジを下げる主因。テスト対象として意識的に扱う必要がある
プロセス的学び¶
- AI 分業の最適粒度: 1 章単位での Codex 委託が最も効率的。部単位（3 章）だと指示が複雑になりすぎる
- 進捗管理の同期タイミング: 部（3 章）完了時に進捗ドキュメントを更新するリズムが適切。章ごとでは頻繁すぎ、イテレーション終了時では遅すぎる
- ふりかえりのデータ収集: git log、JaCoCo、fullCheck の結果を定型的に収集するスクリプトがあると効率的
更新履歴¶
| 日付 | 更新内容 | 更新者 |
|---|---|---|
| 2026-02-28 | 初版作成（IT1 ふりかえり） | - |