以下のフローとチェックリストを使うと、
「DTO のフィールドを先に決めて詳細設計に落とし込むか／実装しながら都度追加するか」を 10 分で判定できます。
1. まず “計測可能な 5 指標” を埋める
| 指標 | 目安 | 記入例 |
|---|---|---|
| ① 予想 DTO 数 | 1 ～ 5 / 6 ～ 15 / 16＋ | 8 |
| ② 1 DTO あたりの平均フィールド数 | 1 ～ 4 / 5 ～ 10 / 11＋ | 6 |
| ③ 外部公開レベル |
A: 同一モジュールのみ B: 他チームも利用 C: 外部システム(API) へ公開 |
B |
| ④ 要件変更頻度（開発中） |
Low: 月1 未満 Mid: 週1 程度 High: 毎日 |
Mid |
| ⑤ チーム規模 | 1 ～ 3 / 4 ～ 7 / 8＋ | 4 |
2. スコアリングして判断
- 各項目に下記ポイントを付与
- ①②⑤：小→0 pt、中→1 pt、大→2 pt
- ③：A→0 pt、B→1 pt、C→2 pt
- ④：Low→0 pt、Mid→1 pt、High→2 pt
- 合計 ≤ 4 pt なら “直接実装で OK”
- 例）単独開発・内部利用・小規模 DTO
- 合計 5 ～ 7 pt なら “軽量設計”
- ざっくりクラス図／フィールド一覧だけ先に作る（30 分上限）
- 合計 8 pt 以上 なら “フル設計必須”
- 詳細設計レビュー → POJO 生成 → 自動テスト雛形まで用意
経験則：
DTO 1 クラスの「後から追加・リネーム」コストは平均 15 〜 20 分（影響調査＋コンパイルエラー修正）。
逆に「最初にフィールドを洗い出す」コストは 5 〜 10 分。
追加修正回数が 2 回を超える見込みなら、もう先に設計したほうが早い。
3. 迷ったときの補助質問（Yes が多いほど upfront 設計寄り）
- この DTO が API 契約書になるか？
- 複数チームが同時に触るか？
- フィールドの型が複雑（List<Nested> 等）か？
- 将来バージョニングが必要か？
- リリース後に “互換性を壊せない” 制約があるか？
Yes が 3 つ以上 → 設計してから実装。
4. 実際の進め方サンプル
合計 3 pt（直接実装で OK）
- 状況：2 人チーム／内部ツール／DTO 3 クラス × 平均 3 フィールド
- 手順：IDE の generate 機能で POJO をその場で作り、プルリクで名前だけ軽く確認。
合計 6 pt（軽量設計）
- 状況：5 人チーム／社内共通ライブラリ／DTO 8 クラス × 平均 7 フィールド
-
手順：
- Miro で簡易クラス図（20 分）
- フィールド名だけ合意→自動コード生成
- 実装フェーズで getter/setter・validation 追加
合計 9 pt（フル設計）
- 状況：外部公開 REST API／DTO 20＋／マイクロサービス間連携
-
手順：
- OpenAPI/Swagger でスキーマ定義
- PR レビュー＋契約テスト用ワイヤモック整備
- Codegen で DTO クラス生成 → 以降は原則ノータッチ
5. まとめ ― “明確な線引き” は 合計 4 pt
- 0 〜 4 pt：設計せず実装着手、後で微調整したほうが速い
- 5 〜 7 pt：30 分以内の軽量設計で手戻り最低限
- 8 pt＋：最初にしっかり設計し、契約を固めるほうが総工数が小さい
この基準を定例ミーティングの冒頭で 5 分で確認し、毎スプリント使い回すと判断がブレません。