イテレーション 2 ふりかえり¶
イテレーション情報¶
| 項目 | 内容 |
|---|---|
| イテレーション | 2 |
| 期間 | Week 3-4 |
| 実施日 | 2026-03-01 |
| 参加者 | 開発者 1 名 + AI（Claude + Codex） |
| フォーマット | KPT |
実績サマリー¶
完了状況¶
| 項目 | 計画 | 実績 |
|---|---|---|
| ストーリーポイント | 10 SP | 10 SP |
| 達成率 | 100% | 100% |
| コミット数 | - | 4 |
| テスト数 | - | 32 |
| 品質チェック | PASS | ALL PASSED |
| テストカバレッジ | 80% | 100% |
主要成果物¶
| カテゴリ | 成果物 | 数量 |
|---|---|---|
| 記事 | docs/article/python/ |
13 ファイル（index + 12 章） |
| プロダクションコード | apps/python/lib/ |
11 ファイル / 229 行 |
| テストコード | apps/python/test/ |
4 ファイル / 199 行 |
| 合計追加行数 | 全体 | 2,623 行 |
モジュール別カバレッジ¶
| モジュール | カバレッジ |
|---|---|
lib/application/ |
100% |
lib/domain/model/ |
100% |
lib/domain/type/ |
100% |
| 全体 | 100% |
KPT 分析¶
Keep（続けること）¶
技術的成功事項¶
- テストカバレッジ 100% 達成: IT1 の課題（75%）を大幅に改善。
pyproject.tomlのexclude_lines設定と意識的なテスト設計により、全モジュールで 100% を達成した - TDD サイクルの厳守: Red → Green → Refactor のサイクルを全章で一貫して実行。Java テンプレートの Python 適応がスムーズだった
- 型安全性の確保: mypy による静的型チェックをゼロエラーで維持。
TYPE_CHECKINGパターンで循環インポートを回避した - 段階的リファクタリング: 手続き型 → カプセル化 → ポリモーフィズム → デザインパターン → SOLID → 関数型の段階的進化が、Python でも効果的に機能した
プロセス的成功事項¶
- IT1 テンプレートの再利用: Java で確立した章構成・コード構造・設計パターンを Python に効率的に適応できた
- 部単位のコミット戦略: 4 コミット（部ごと）で管理し、変更履歴が明確になった
- 品質ツールの統合: Ruff + mypy + pytest-cov の組み合わせが、Java の Checkstyle + PMD + SpotBugs + JaCoCo に匹敵する品質保証を実現した
- Pythonic な実装: リスト内包表記、
@property、ABC、Enum など Python らしい機能を活用し、Java の直訳にならない記事を執筆できた
IT1 からの改善事項¶
- カバレッジ目標達成: IT1 の 75% → IT2 の 100%。
__eq__/__hash__テストを最初から含める方針が効果的だった - 第 4 部の正規 SP 計上: IT1 で問題になった「0 SP バッファ扱い」を改善し、第 4 部を含む全体を 10 SP として計画した
- 進捗ドキュメントの同期: 部完了ごとに workflow.md を更新するリズムを維持した
Problem（問題点・課題）¶
イテレーション計画のタスク状態未更新¶
- 第 3 部・第 4 部のタスクチェックが未更新:
iteration_plan-2.mdの第 3 部（タスク 3.1-3.6）と第 4 部（タスク 4.1-4.8）のチェックボックスが[ ]のまま。実際には完了済みだがドキュメントに反映されていない - 進捗率の記載が古い:
iteration_plan-2.mdに「進捗率: 70%（7/10 SP）」と記載されたまま。実際は 100% 完了
CI/CD の未整備¶
- GitHub Actions python-ci.yml が未コミット: 記事（第 6 章）に CI 設定を記載しているが、実際のワークフローファイルがまだコミットされていない
- コード複雑度チェック（C90）の未反映:
.ruff.tomlにC90が追加されたが、記事の.ruff.toml設定例との同期が必要
見積もりの課題¶
- 実時間の未計測: AI 並列作業により理想時間（46h）と実時間の乖離が大きいが、実時間を正確に計測していない。ベロシティ予測の精度向上には実時間データが必要
Try（次に試すこと）¶
| # | アクション | 責任者 | 期限 | 期待効果 |
|---|---|---|---|---|
| 1 | イテレーション計画のタスクチェックを完了時にリアルタイム更新する | IT3 | IT3 開始時 | ドキュメント整合性の向上 |
| 2 | python-ci.yml をコミットし CI パイプラインを稼働させる | IT2 | IT2 終了時 | 自動品質チェックの実現 |
| 3 | tox の全品質チェック（uv run tox）を各コミット前に実行するフローを確立 |
IT3 | IT3 | 品質ゲートの強化 |
| 4 | 次言語（Node/JS/TS）の特徴を事前調査し、第 4 部の内容を計画段階で確定する | IT3 | IT3 計画時 | 見積もり精度向上 |
次イテレーションへの引き継ぎ事項¶
必須対応事項¶
- docs/article/python/ に 12 章の記事が作成済み
- apps/python/ のテストが全パス（32 テスト、カバレッジ 100%）
- mkdocs.yml に Python セクションが追加済み
- iteration_plan-2.md のタスクチェックボックスを完了に更新
- python-ci.yml のコミット
- release_plan.md の IT2 状態を「完了」に更新
テンプレート確立事項¶
- Java → Python のテンプレート適応パターンが確立
- Python 固有の機能（
@property、ABC、Enum、リスト内包表記、ジェネレータ）の記事構成が確立 - 品質ツールの対応表が確立（Ruff = Checkstyle + PMD、mypy = SpotBugs、pytest-cov = JaCoCo）
次言語（Node/JS/TS）への知見¶
- テストフレームワーク: Jest または Vitest を使用
- リンター: ESLint + Prettier（Ruff 相当）
- 型チェック: TypeScript のコンパイラが mypy 相当の役割を担う
- パッケージマネージャ: npm / pnpm
- タスクランナー: npm scripts / package.json
メトリクス¶
開発メトリクス¶
| メトリクス | 値 |
|---|---|
| コミット数 | 4 |
| 追加行数 | 2,623 |
| プロダクションコード行数 | 229 |
| テストコード行数 | 199 |
| テスト/プロダクション比率 | 0.87 |
| ファイル数（プロダクション） | 11 |
| ファイル数（テスト） | 4 |
品質メトリクス¶
| メトリクス | 目標 | 実績 | 判定 |
|---|---|---|---|
| テストカバレッジ | 80% | 100% | 達成 |
| テスト数 | - | 32 | - |
| Ruff 違反 | 0 | 0 | 達成 |
| mypy エラー | 0 | 0 | 達成 |
プロセスメトリクス¶
| メトリクス | 値 |
|---|---|
| 計画 SP | 10 |
| 実績 SP | 10 |
| 達成率 | 100% |
| 記事完成率 | 12/12 章（100%） |
| ベロシティ | 10 SP/イテレーション |
IT1 との比較¶
| メトリクス | IT1（Java） | IT2（Python） | 変化 |
|---|---|---|---|
| テスト数 | 24 | 32 | +33% |
| カバレッジ | 75% | 100% | +25pt |
| プロダクションコード行数 | 333 | 229 | -31% |
| テストコード行数 | 277 | 199 | -28% |
| 記事行数 | 3,399 | 2,127 | -37% |
| コミット数 | 11 | 4 | -64% |
| 品質チェック違反 | 0 | 0 | 同等 |
学び（Lessons Learned）¶
技術的学び¶
- Python の簡潔さ: 同じ設計パターンを Java の 69% の行数で実装できた。
@property、リスト内包表記、ABC の組み合わせが簡潔なコードを実現する - TYPE_CHECKING パターン: 循環インポートを回避しつつ型ヒントを維持する
if TYPE_CHECKING:パターンは、Python の大規模プロジェクトで必須のテクニック - Ruff の統合力: Checkstyle + PMD + black + isort に相当する機能を 1 ツールで実現。設定が簡潔で CI 統合も容易
- pytest の表現力: JUnit 5 と比較して、フィクスチャやパラメータ化テストが直感的。日本語テスト名もそのまま使えて教育的価値が高い
プロセス的学び¶
- 部単位のコミットが最適: IT1 の 11 コミット（章ごと + 追加修正）に対し、IT2 は 4 コミット（部ごと）。コミット粒度を大きくすることで、まとまった変更を一括管理できた
- テンプレート再利用の効果: IT1 で確立した章構成が、IT2 の執筆速度を大幅に向上させた。3 言語目以降はさらに加速が見込める
- カバレッジ戦略の重要性: IT1 の反省を活かし、
__eq__/__hash__テストを最初から含め、exclude_linesを適切に設定することで 100% を効率的に達成できた
更新履歴¶
| 日付 | 更新内容 | 更新者 |
|---|---|---|
| 2026-03-01 | 初版作成（IT2 ふりかえり） | - |