イテレーション 2 ふりかえり（Retrospective）¶

基本情報¶

項目	内容
イテレーション番号	2
期間	2026-01-21 〜 2026-02-03（計画）、2026-01-21 〜 2026-01-26（実績）
実施日	2026-01-26
参加者	開発チーム全員
フォーマット	KPT（Keep, Problem, Try）

実績サマリー¶

完了状況¶

項目	計画	実績	達成率
ストーリーポイント	16SP	16SP	100%
ユーザーストーリー	3件	3件	100%
理想時間	119h	99h	120%効率
作業日数	10日	6日	40%短縮
コミット数	-	7件	-

テスト結果¶

カテゴリ	件数	結果
フロントエンドユニットテスト	223件	✅ 全パス
バックエンドユニットテスト	47ファイル	✅ 全パス
E2E テスト	52件+	✅ 全パス
テストカバレッジ（フロントエンド）	92%+	✅ 良好

ビルド状態¶

環境	状態
バックエンドビルド	✅ 成功
フロントエンドビルド	✅ 成功
CI/CD パイプライン	✅ 正常稼働

主要成果物¶

勘定科目削除機能（US-MST-003）
削除前確認ダイアログ
使用中チェック（仕訳で使用されている科目は削除不可）
削除成功メッセージ表示
勘定科目一覧表示拡張（US-MST-004）
勘定科目種別によるフィルタリング
科目コード・科目名による検索
API クエリパラメータ対応
仕訳入力機能（US-JNL-001）
仕訳日付、摘要入力
複数明細行の動的追加/削除
貸借一致バリデーション
勘定科目選択コンポーネント
下書き（DRAFT）ステータスでの保存
仕訳ドメインモデル
JournalEntry（集約ルート）
JournalEntryLine（明細行）
Money（金額値オブジェクト）
JournalEntryStatus（ステータス列挙型）

KPT 分析¶

Keep（続けること）¶

技術的成功事項¶

ドメインモデル中心設計: 仕訳ドメインを集約ルートとして設計し、貸借一致などのビジネスルールをドメイン層に集約
Vavr Either/IO モナドの継続使用: エラーハンドリングを関数型スタイルで一貫して実装
コンポーネント再利用: イテレーション 1 で作成した共通コンポーネント（Table, Modal, Button 等）を活用
型安全な API 設計: TypeScript の型定義と OpenAPI スキーマの整合性を維持

プロセス的成功事項¶

早期完了の実現: 計画 10 日に対し 6 日で完了（40% 短縮）
段階的実装: バックエンド → フロントエンドの順序を維持
小さなコミット: 各機能を論理的な単位でコミット
GitHub Issue との同期: 完了した Issue を即座にクローズ

チームワーク¶

効率的なタスク分担: Codex による並行実装で高い生産性を維持
問題の即座共有: 技術的課題を早期に検出・解決

Problem（問題点・課題）¶

未完了項目¶

共通タスク: 以下のタスクが未着手のまま
COMMON-07: 仕訳テーブルマイグレーション確認
COMMON-08: 日次バーンダウン収集仕組み構築
COMMON-09: ESLint 複雑度チェック CI 統合
COMMON-10: 仕訳ドメインのアーキテクチャテスト追加
将来拡張機能: 以下は意図的にスキップ
ソート機能（MST-004-07）
ページネーション（MST-004-08）

見積もり精度の課題¶

過大見積もり: 計画 119h に対し実績 99h で完了。基盤が確立されていたため予想以上に効率的だった
コミット数の減少: イテレーション 1（177 件）に対し、イテレーション 2（7 件）。大きな機能単位でのコミットになっている

プロセス課題¶

日次バーンダウン未追跡: イテレーション 1 から引き続き、日次進捗データの収集が未実装
ドキュメント更新のタイミング: 実装完了後にドキュメント更新が遅れる傾向

技術的課題¶

React Router の警告
問題: v7 への移行に関する Future Flag 警告が発生
影響: 機能には影響なし、将来の互換性リスク
対応: イテレーション 3 以降で対応検討
コミット粒度の粗さ
問題: 1 コミットに複数の変更が含まれる傾向
影響: 履歴の追跡性低下
対応: より小さな単位でのコミットを意識

Try（次に試すこと）¶

具体的改善アクション¶

#	アクション	責任者	期限	期待効果
1	日次バーンダウンの自動収集仕組み構築	-	イテレーション 3 開始時	進捗の可視化向上
2	ESLint 複雑度チェックの CI 統合	-	イテレーション 3 中	早期の品質問題検出
3	React Router v7 Future Flags の有効化	-	イテレーション 3	警告解消、将来互換性確保
4	より小さなコミット単位の徹底	-	イテレーション 3	履歴追跡性向上
5	バックエンドのインポート整理	-	イテレーション 4	コード品質向上

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

必須対応事項¶

仕訳編集機能（US-JNL-002） - イテレーション 3 で実装予定
仕訳削除機能（US-JNL-003） - イテレーション 3 で実装予定
仕訳一覧表示（US-JNL-004） - イテレーション 3 で実装予定
仕訳検索（US-JNL-005） - イテレーション 3 で実装予定

技術検証タスク¶

仕訳編集時の楽観的ロック機構の設計
仕訳一覧のページネーション・ソート実装方針

ドキュメント整備タスク¶

イテレーション 3 計画書の作成
仕訳管理機能の API ドキュメント更新

メトリクス¶

開発メトリクス¶

メトリクス	値
総コミット数	7
追加行数	約 5,025
削除行数	約 118
変更ファイル数	51

品質メトリクス¶

メトリクス	値	目標	判定
フロントエンドテストカバレッジ	92%+	80%	✅
ユニットテスト合格率	100%	100%	✅
E2E テスト合格率	100%	100%	✅
ビルド成功率	100%	100%	✅

プロセスメトリクス¶

メトリクス	値
計画 SP	16
実績 SP	16
ベロシティ	16SP/イテレーション
作業効率	120%（10 日計画 → 6 日完了）
累積実績ベロシティ	17SP/イテレーション平均（(18+16)/2）

学び（Lessons Learned）¶

技術的学び¶

ドメインモデル設計の重要性
貸借一致バリデーションを JournalEntry 集約ルートで管理することで、ビジネスルールの一貫性を確保
Money 値オブジェクトで金額計算の精度を保証
ステータス遷移を enum で明示的に管理
フロントエンドの動的フォーム
仕訳明細行の動的追加/削除は React の状態管理で実現
バリデーションは入力時と送信時の両方で実施
勘定科目選択は API からの動的取得で実装
検索・フィルタリング機能
バックエンドでクエリパラメータ対応
フロントエンドで検索条件の状態管理
デバウンス処理で API 呼び出し最適化

プロセス的学び¶

基盤確立後の開発効率
イテレーション 1 で確立した基盤（認証、共通コンポーネント、テスト環境）により、イテレーション 2 は大幅に効率化
新機能追加が既存パターンに沿って実装可能
ベロシティの安定化
イテレーション 1: 18SP、イテレーション 2: 16SP で安定
今後の計画は 16-18SP/イテレーションで見積もり可能

次回イテレーションへの期待¶

達成目標¶

イテレーション 3 ゴール: 仕訳管理の基本機能（編集・削除・一覧・検索）を完成させる
計画 SP: 18SP
対象ストーリー: US-JNL-002, US-JNL-003, US-JNL-004, US-JNL-005

重点項目¶

仕訳編集時の楽観的ロック実装
仕訳一覧のページネーション・ソート実装
日次バーンダウン収集の仕組み構築

総評¶

成功した点¶

全ストーリー完了: 計画した 3 ストーリー（16SP）を 100% 達成
大幅な効率化: 計画 10 日に対し 6 日で完了（40% 短縮）
仕訳ドメインの確立: 財務会計のコア機能である仕訳入力の基盤を構築
高い品質維持: テストカバレッジ 92%+、全テスト合格を継続

改善が必要な点¶

日次進捗追跡: 2 イテレーション連続で未実装、優先度を上げる必要あり
コミット粒度: より小さな単位でのコミットを徹底
技術的負債: React Router 警告、バックエンドインポート整理への対応

次イテレーションへの自信度¶

非常に高い - イテレーション 1-2 で基盤が確立され、チームのベロシティ（16-18SP/イテレーション）も安定。仕訳ドメインの設計が完了しているため、編集・削除・一覧機能の追加は効率的に進められる見込み。

更新履歴¶

日付	更新内容	更新者
2026-01-26	初版作成	Claude Opus 4.5