Step 2：実装計画を立てる

仕様を理解したら、次はどう進めるかを計画するステップです。計画なしにいきなりコードを書き始めると、途中で迷子になります。

なぜ計画が必要なのか

flowchart TB
    subgraph 計画なしで始めた場合
        A1[いきなりコードを書く] --> A2[どこから手をつけるか迷う]
        A2 --> A3[途中で「あれも必要だった」と気づく]
        A3 --> A4[行ったり来たりで混乱]
        A4 --> A5[進捗が見えない、終わりが見えない]
    end

    subgraph 計画を立てた場合
        B1[タスクを分解] --> B2[順序を決める]
        B2 --> B3[一つずつ消化]
        B3 --> B4[進捗が見える、達成感がある]
    end

計画なしで始めると：

• どこから手をつけていいか分からない
• 「あ、これも必要だった」と後から気づく
• 見積もりが立てられず、進捗報告ができない
• 「終わりが見えない」感覚に陥る

計画を立てると：

• 全体像が見えて迷わない
• 抜け漏れを事前に発見できる
• 「今日はここまで」と区切りがつけられる
• 「1つ終わった」という達成感を得られる

タスクを分解する

なぜ分解するのか

大きな塊のまま取り組むと、「終わりが見えない」感覚になります。

flowchart LR
    subgraph 分解しない場合
        A[ユーザー登録機能を実装する] --> B[巨大なタスク]
        B --> C[どこまで進んだか分からない]
    end

    subgraph 分解した場合
        D[入力フォーム作成] --> E[バリデーション実装]
        E --> F[DB登録処理]
        F --> G[完了画面作成]
    end

小さく分解すれば：

• 「1つ終わった」という達成感を得られる
• 進捗が具体的に把握できる
• 問題が起きても影響範囲が小さい

分解の粒度

目安：1つのタスクが1〜2時間で終わる大きさ

flowchart TB
    A[粗すぎる] --> B[ユーザー登録機能を作る]
    B --> C[何日かかるか分からない]

    D[適切] --> E[入力フォームを作る]
    E --> F[1〜2時間で終わる]

    G[細かすぎる] --> H[ボタンの色を設定する]
    H --> I[管理が煩雑になる]

分解の例

例：ユーザー登録機能の実装

## タスク分解

### 1. 入力フォーム
- [ ] 1.1 フォームの枠組みを作成
- [ ] 1.2 各入力項目を配置
- [ ] 1.3 送信ボタンを配置

### 2. バリデーション
- [ ] 2.1 必須チェック
- [ ] 2.2 メールアドレス形式チェック
- [ ] 2.3 パスワード強度チェック
- [ ] 2.4 重複チェック（API呼び出し）

### 3. 登録処理
- [ ] 3.1 APIエンドポイント作成
- [ ] 3.2 データベースへの保存処理
- [ ] 3.3 確認メール送信処理

### 4. 画面遷移
- [ ] 4.1 登録完了画面の作成
- [ ] 4.2 エラー時の表示処理

分解のコツ

1. 動作確認できる単位で分ける

✗ 「変数を定義する」「メソッドのシグネチャを書く」
  → 動作確認できない

○ 「入力フォームを表示する」「バリデーションが動く」
  → 動作確認できる

2. 依存関係を意識する

flowchart LR
    A[フォーム作成] --> B[バリデーション実装]
    B --> C[API呼び出し]
    C --> D[DB保存]

Aができないと B が作れない、という関係を把握します。

3. 不確実なものを識別する

• 「よく分からない技術を使う」→ 調査時間を見込む
• 「仕様が曖昧」→ 確認待ち時間を見込む
• 「他のチームの作業に依存」→ 待ち時間を見込む

実装順序を決める

順序を決める観点

1. 依存関係を考慮

前提となる処理を先に作る

flowchart LR
    A[1. DBテーブル作成] --> B[2. API作成]
    B --> C[3. 画面からAPI呼び出し]

2. 単純な部分から始める

flowchart LR
    A[単純な処理] --> B[複雑な処理]
    A --> C[理解が深まる]
    C --> B

なぜ単純なものから？

• 全体の構造を理解できる
• 自信がついてから難しいものに取り組める
• 問題が起きても切り分けやすい

3. テストしやすい単位で進める

○ 「入力フォームを作る → 動作確認」
   「バリデーションを作る → 動作確認」

✗ 「全部作ってから動作確認」
   → 問題が起きたときに原因特定が困難

順序の例

例：ユーザー登録機能

見積もりを立てる

なぜ見積もりが必要か

• 自分のため：「今日はここまで」という目標が立てられる
• チームのため：進捗報告ができる
• 計画のため：スケジュールに収まるか確認できる

見積もりの立て方

1. タスクごとに時間を見積もる

## 見積もり

| タスク | 見積もり時間 |
|--------|-------------|
| 入力フォーム作成 | 1時間 |
| バリデーション実装 | 2時間 |
| API作成 | 2時間 |
| DB保存処理 | 1.5時間 |
| 完了画面作成 | 0.5時間 |
| エラー処理 | 1時間 |
| **合計** | **8時間** |

2. バッファを加える

見積もりは楽観的になりがちです。1.2〜1.5倍のバッファを見込みましょう。

見積もり合計：8時間
バッファ込み：8 × 1.3 = 約10時間

なぜバッファが必要？

• 予期しない問題が発生する
• 割り込み作業が入る
• 仕様の確認待ちが発生する

3. 不確実なものは別枠で

## 確実な見積もり
- 入力フォーム：1時間
- バリデーション：2時間
- 合計：3時間

## 不確実な見積もり（調査が必要）
- 外部API連携：2〜4時間（使ったことがない）
- メール送信：1〜3時間（仕様確認中）

見積もりが外れたら

見積もりは「予測」であり、外れることはあります。

大切なのは：

• 早めに報告する（「予定より時間がかかりそうです」）
• 原因を分析する（なぜ外れたか）
• 次に活かす（同様のタスクの見積もりを調整）

計画を書き出す

なぜ書き出すのか

頭の中だけで管理しようとすると：

• 抜け漏れが発生する
• 進捗が分からなくなる
• 中断後に再開しづらい

書き出すと：

• 全体が見える
• 終わったものをチェックできる
• 他の人にも共有できる

書き出し方の例

シンプルなチェックリスト

## ユーザー登録機能 実装計画

### 今日の目標
- [ ] 入力フォーム完成
- [ ] バリデーション（必須チェック）完成

### タスク一覧
- [x] 1. フォームの枠組み作成 ← 完了
- [ ] 2. 入力項目の配置 ← 作業中
- [ ] 3. 送信ボタン配置
- [ ] 4. 必須チェック
- [ ] 5. 形式チェック
- [ ] 6. API作成
- [ ] 7. DB保存
- [ ] 8. 完了画面
- [ ] 9. エラー処理

詳細な計画

## ユーザー登録機能 実装計画

### 概要
- 開始日：2024/01/15
- 予定完了日：2024/01/17
- 見積もり工数：10時間

### 1日目（1/15）
- [ ] 入力フォーム作成（1時間）
- [ ] バリデーション実装（2時間）

### 2日目（1/16）
- [ ] API作成（2時間）
- [ ] DB保存処理（1.5時間）

### 3日目（1/17）
- [ ] 画面遷移・エラー処理（1.5時間）
- [ ] テスト・調整（2時間）

### 確認事項
- [ ] メールアドレスの重複チェック仕様（田中さんに確認中）

計画のチェックリスト

計画を立て終わったら、以下を確認しましょう。

• [ ] タスクは1〜2時間で終わる粒度に分解されているか
• [ ] 依存関係を考慮した順序になっているか
• [ ] 各タスクの見積もり時間を記載したか
• [ ] バッファを見込んでいるか
• [ ] 不確実な部分は識別されているか
• [ ] 書き出して管理できる状態になっているか

よくある失敗と対策

まとめ

実装計画のポイント

1. タスクを分解する：1〜2時間で終わる粒度に
2. 順序を決める：依存関係を考慮、単純なものから
3. 見積もりを立てる：バッファを見込む
4. 書き出す：頭の中だけで管理しない

次のステップ

計画を立てたら、Step 3：実装する に進みましょう。

関連ページ

• 実装の進め方（全体概要）
• Step 1：仕様を理解する
• 作業の依頼を受けたら