Skip to content

イテレーション 6 ふりかえり

イテレーション情報

項目 内容
イテレーション番号 6
期間 2026-02-10 〜 2026-02-13
実施日 2026-02-13
参加者 Claude Opus 4.6, Codex
フォーマット KPT(Keep / Problem / Try)

実績サマリー

完了状況

指標 計画 実績 達成率
ストーリーポイント 19SP 19SP 100%
ストーリー数 4 4 100%
コミット数 - 15 -
バックエンドテスト - 648 パス
フロントエンドテスト - 507 パス
ビルド状態 - 成功
SonarQube Quality Gate - Passed

主要成果物

ストーリーID ストーリー名 SP 状態 完了日
US-JNL-009 仕訳差し戻し 3 ✅ 完了 2026-02-10
US-JNL-010 仕訳確定 5 ✅ 完了 2026-02-10
US-LDG-004 月次残高照会 5 ✅ 完了 2026-02-10
US-LDG-005 残高試算表表示 6 ✅ 完了 2026-02-13

コード変更統計

メトリクス
総コミット数 15
変更ファイル数 113
追加行数 6,288
削除行数 326
コミット内訳 - feat 6
コミット内訳 - test 3
コミット内訳 - fix 3
コミット内訳 - refactor 1
コミット内訳 - docs 2

KPT 分析

Keep(続けること)

技術的成功事項

  1. Day 1 で 13SP 完了の高速開発

  2. US-JNL-009(3SP)、US-JNL-010(5SP)、US-LDG-004(5SP)を初日で完了

  3. 既存の承認ワークフローパターン(Command/UseCase/Service)の再利用が効果的
  4. Codex への明確な設計指示による並列実装が機能

  5. バックエンド・フロントエンド一貫した TDD

  6. バックエンド 648 テスト、フロントエンド 507 テスト、全パス

  7. 各ストーリーでバックエンド実装 → フロントエンド実装の順序を徹底
  8. recharts モックや共通テストヘルパーの活用

  9. SonarQube Quality Gate パス

  10. Coverage on New Code: 100%

  11. Duplication on New Code: 0.0%
  12. 47 件のバックエンドテスト追加でカバレッジ改善
  13. フロントエンドの重複コードを共通部品に抽出

  14. ヘキサゴナルアーキテクチャの成熟

  15. MonthlyBalanceController/TrialBalanceController の Output Port パターン確立

  16. MyBatis mapper による直接テーブル参照(monthly_account_balances)
  17. trial_balance ビューの date フィルター対応設計

プロセス的成功事項

  1. イテレーション計画の精度向上

  2. 19SP の挑戦的目標を Day 4 で全完了

  3. 残り日数を品質改善(SonarQube 対応、E2E 安定化)に活用

  4. GitHub Project との同期

  5. Issue #24, #25, #29, #30 のクローズ

  6. Milestone 進捗の自動更新

チームワーク

  1. Claude + Codex の役割分担最適化

  2. Claude: 設計・計画・E2E テスト・品質改善・ドキュメント

  3. Codex: TDD 実装・ユニットテスト・リファクタリング
  4. 両者の成果物を統合するフローが安定

Problem(問題点・課題)

共通タスク未着手

  1. COMMON-18〜25 が全て未着手のまま

  2. リリース 1.0 リリースノート作成(COMMON-18)

  3. API ドキュメント更新(COMMON-19)
  4. 仕訳ステータス遷移図ドキュメント作成(COMMON-23)
  5. フロントエンド権限チェック(COMMON-24)
  6. E2E テスト CI 統合(COMMON-25)
  7. ストーリー開発を優先した結果、連続で後回しに

E2E テストの不安定性

  1. CI 環境での E2E テスト失敗(2件)

  2. submit-journal-entry.cy.ts: PENDING エントリが他テストで消費され存在しない問題

  3. reject-journal-entry.cy.ts: filterJournalEntriesByStatus 後のレースコンディション
  4. テスト間のデータ依存性とフィルター結果の非同期待機が根本原因
  5. 修正済み(visibilityTestSetup 追加 + ステータスラベル待機ガード統一)

見積もり精度の課題

  1. 計画期間と実績期間の乖離が継続

  2. 計画: 10 日間(2026-02-10 〜 2026-02-24)

  3. 実績: 4 日間(2026-02-10 〜 2026-02-13)
  4. AI アシスタント活用時のベロシティ基準が未調整

Try(次に試すこと)

# アクション 責任者 期限 内容 期待効果
1 共通タスク消化を必須化 Claude イテレーション 7 COMMON-18〜25 をイテレーション計画の必須項目として組み込む 技術的負債の解消
2 E2E テストの自己完結化 Claude 完了 各 spec ファイルが他テストの実行順序に依存しないよう visibilityTestSetup で事前データ作成 CI の安定性向上
3 フィルター操作後のガード統一 Claude 完了 filterJournalEntriesByStatus 後に必ずステータスラベル待機を追加 レースコンディション排除
4 ベロシティ基準の見直し Claude イテレーション 7 計画時 実績ベロシティ(平均 16.5SP/4日)を反映した計画調整 計画精度向上

次イテレーションへの引き継ぎ事項

必須対応事項

  1. US-FS-001: 貸借対照表表示(8SP)

  2. 残高試算表データを基にした貸借対照表生成

  3. 資産・負債・純資産の区分表示

  4. US-LDG-002: 補助元帳照会(5SP)

  5. 勘定科目の補助科目別明細照会

共通タスク(必須)

  1. COMMON-18: リリース 1.0 MVP リリースノート作成(3h)
  2. COMMON-19: API ドキュメント更新(3h)
  3. COMMON-23: 仕訳ステータス遷移図ドキュメント作成(4h)
  4. COMMON-24: フロントエンド権限チェック(4h)
  5. COMMON-25: E2E テスト CI 統合(4h)

技術検証タスク

  1. 貸借対照表の表示レイアウト設計

  2. 勘定式 vs 報告式の選定

  3. 残高試算表データとの連携方式

メトリクス

開発メトリクス

メトリクス
総コミット数 15
変更ファイル数 113
追加行数 6,288
削除行数 326
純増行数 5,962

品質メトリクス

メトリクス バックエンド フロントエンド
テストケース数 648 507
テストファイル数 - 62
ビルド状態 ✅ 成功 ✅ 成功
SonarQube Coverage(New Code) 100% 100%
SonarQube Duplication(New Code) 0.0% 0.0%
SonarQube Quality Gate Passed Passed

プロセスメトリクス

メトリクス 計画 実績
イテレーション期間 10 日 4 日
ベロシティ 19SP 19SP
達成率 100% 100%
1SP あたり開発時間 約 7h 約 3h

ベロシティ推移

全イテレーション実績

イテレーション 計画 SP 実績 SP 計画期間 実績期間
1 15 18 2 週間 2 週間
2 14 16 2 週間 1 週間
3 18 18 2 週間 1 週間
4 10 10 2 週間 2 日
5 17 17 2 週間 3 日
6 19 19 2 週間 4 日
累計 93 98

平均ベロシティ: 16.3 SP/イテレーション


学び(Lessons Learned)

技術的学び

  1. E2E テストのテストデータ独立性が重要

  2. CI 環境ではスペックファイルがアルファベット順に実行される

  3. 先行テストがデータを消費するため、各テストは自己完結型であるべき
  4. before() フックでの事前データ作成パターンが有効

  5. 非同期フィルター操作後のガード必須

  6. filterJournalEntriesByStatus 後にフィルター結果がロードされる前に古い行データが残る

  7. ステータスラベルの表示待機ガードを統一することでレースコンディションを防止

  8. SonarQube カバレッジ改善はテスト追加で対応

  9. 47 件のバックエンドテスト追加で 76.7% → 100%(New Code)

  10. フロントエンドの重複コードは共通ヘルパー抽出で 3.2% → 0.0%

  11. MyBatis の直接テーブル参照パターン

  12. monthly_account_balances テーブルを直接クエリ(ビュー不使用)

  13. trial_balance ビューは日付フィルター未対応のため daily_account_balances を直接参照

プロセス的学び

  1. 品質改善タスクにバッファを活用

  2. ストーリー完了後のバッファ期間を SonarQube 対応・E2E 安定化に活用

  3. 品質メトリクスの継続的な改善が可能に

  4. 共通タスクは計画に明示的に含めるべき

  5. 3 イテレーション連続で共通タスクが未着手

  6. イテレーション計画の「必須」枠に組み込む必要あり

総評

成功した点

  • 全ストーリー完了(19SP/19SP): 挑戦的な目標を Day 4 で達成
  • 仕訳承認ワークフロー完成: DRAFT → PENDING → APPROVED → CONFIRMED の全遷移を実装
  • 残高管理基盤構築: 月次残高照会 + 残高試算表表示で財務諸表の基盤完成
  • SonarQube Quality Gate パス: Coverage 100%、Duplication 0.0%
  • E2E テスト安定化: CI 環境での flaky test を根本修正

改善が必要な点

  • 共通タスク(COMMON-18〜25)が 3 イテレーション連続で未着手
  • ベロシティ見積もりの調整: 計画 10 日 → 実績 4 日の乖離
  • E2E テストの設計方針: テストデータの独立性を初期設計時に考慮すべき

総合評価

イテレーション 6 は大成功でした。仕訳承認ワークフローを完成させ、月次残高照会と残高試算表表示を実装することで、リリース 2.0 の中核機能を確立しました。さらに SonarQube の品質メトリクスを改善し、E2E テストの不安定性を根本修正しました。累計 98SP を完了し、プロジェクト全体の 63% が完了しています。

次のイテレーション 7 では、貸借対照表表示と補助元帳照会に加え、3 イテレーション連続で先送りされている共通タスクの消化を必須目標として組み込みます。


更新履歴

日付 更新内容 更新者
2026-02-13 初版作成 Claude Opus 4.6

関連ドキュメント