Step 1：仕様を理解する

実装を始める前に、何を作るのかを明確にするステップです。このステップを疎かにすると、後で大きな手戻りが発生します。

なぜ仕様理解が重要なのか

flowchart TB
    subgraph 仕様を理解せずに実装
        A1[「たぶんこうだろう」で実装] --> A2[完成後に確認]
        A2 --> A3[「これじゃない」と言われる]
        A3 --> A4[最初から作り直し]
        A4 --> A5[時間のムダ、信頼低下]
    end

    subgraph 仕様を理解してから実装
        B1[仕様を確認・質問] --> B2[正しい理解で実装]
        B2 --> B3[期待通りのものができる]
        B3 --> B4[スムーズにレビュー通過]
    end

仕様を理解しないまま実装を始めると：

• 「作ったけど違った」という手戻りが発生する
• 途中で「あれ？これでいいんだっけ？」と迷う
• レビューで「仕様と違う」と指摘される
• 信頼を失い、次から細かく確認される

仕様を理解してから実装を始めると：

• 迷わず一直線に実装を進められる
• 手戻りが発生しない
• レビューがスムーズに通る
• 「任せられる」という信頼につながる

確認すべき4つのポイント

1. 何を実装するのか（What）

機能の目的と範囲を把握する

なぜ範囲の確認が必要？：「ついでにこれも」と範囲外のことを実装すると、テストケースが増え、予定より時間がかかります。また、他の機能との整合性が取れなくなることもあります。

2. どう動くべきか（How）

入力・出力・振る舞いを把握する

flowchart LR
    A[入力] --> B[処理]
    B --> C[出力]

なぜ入出力の確認が必要？：「入力はこれでいいだろう」と思い込んで実装すると、後から「この項目も必要だった」「この形式じゃないとダメ」となります。

3. 関連する機能は何か（Relation）

他の機能との関係を把握する

flowchart TB
    A[ユーザー登録] --> B[ログイン機能]
    A --> C[メール送信機能]
    A --> D[ユーザー管理画面]

なぜ関連機能の確認が必要？：関連する機能のコードを参考にできますし、影響範囲を事前に把握できます。また、共通処理があれば再利用できます。

4. 制約や注意点は何か（Constraint）

守るべきルールや考慮事項を把握する

なぜ制約の確認が必要？：「自由に作っていい」と思っていたら、後から「それはダメ」と言われることがあります。事前に制約を把握しておけば、手戻りを防げます。

設計書の読み方

ステップ1：まず全体を眺める

いきなり詳細を読み始めず、全体像を把握します。

• 目次を見て全体構成を把握
• 図やフローチャートを先に見る
• 「結局何を作るのか」を理解する

flowchart LR
    A[目次を見る] --> B[図を見る]
    B --> C[概要を読む]
    C --> D[全体像を把握]

ステップ2：自分の担当範囲を特定

設計書全体のうち、今回自分が実装する範囲を明確にします。

• 担当する機能はどの部分か
• 画面のどこからどこまでか
• 処理のどこからどこまでか

注意：「全部理解してから始めよう」とすると、時間がかかりすぎます。まずは担当範囲に集中し、必要に応じて周辺を読みましょう。

ステップ3：詳細を読み込む

担当範囲について、詳細を理解します。

• 画面項目の一つ一つを確認
• 処理フローを追う
• 条件分岐を把握
• エラー処理を確認

ステップ4：不明点をメモする

読んでいて分からない点をメモします。

• 曖昧な記述
• 矛盾している箇所
• 書いていないこと
• 複数の解釈ができる箇所

## 不明点メモ

1. 「適切なエラーメッセージを表示」→ 具体的なメッセージは？
2. 「登録完了後、メールを送信」→ 送信失敗時はどうする？
3. 「重複チェック」→ メールアドレスだけ？ユーザー名も？

不明点は確認する

なぜ確認が必要なのか

flowchart TB
    A[曖昧な仕様] --> B{確認する？}
    B -->|しない| C[自分の解釈で実装]
    C --> D[レビューで「違う」と言われる]
    D --> E[作り直し]

    B -->|する| F[正しい仕様を理解]
    F --> G[正しく実装]
    G --> H[スムーズに完了]

確認に5分かけることで、作り直しの5時間を防げます。

確認の仕方

良い確認の仕方

〇〇の機能について質問があります。

設計書の△△ページに「□□する」とありますが、
以下の理解で合っていますでしょうか？

・入力値が空の場合 → エラーメッセージを表示
・入力値が不正な場合 → エラーメッセージを表示（メッセージは異なる）
・入力値が正常な場合 → 次の処理へ進む

また、「適切なエラーメッセージ」とありますが、
具体的なメッセージ文言は決まっていますでしょうか？

ポイント：

• 自分の理解を示す（丸投げしない）
• 具体的に質問する
• 選択肢を提示する（可能であれば）

悪い確認の仕方

✗「設計書がよく分かりません」
  → 何が分からないか具体的に

✗「どう実装すればいいですか？」
  → 自分の理解や案を示してから質問

✗「〇〇でいいですよね？」（確認せず実装してから）
  → 実装前に確認する

確認のタイミング

注意：質問をためらって「たぶんこうだろう」で進めると、後で大きな手戻りになります。迷ったら聞くが鉄則です。

仕様理解のチェックリスト

実装を始める前に、以下を確認しましょう。

機能の理解

• [ ] 何を実装するか説明できる
• [ ] なぜこの機能が必要か理解している
• [ ] 今回の実装範囲が明確になっている

入出力の理解

• [ ] どんなデータが入力されるか把握している
• [ ] どんな結果を出力するか把握している
• [ ] 正常系・異常系の動きを理解している

関連の理解

• [ ] 関連する機能を把握している
• [ ] 参考にできる既存コードを見つけている
• [ ] 共通処理があれば把握している

制約の理解

• [ ] 守るべきルールを把握している
• [ ] やってはいけないことを把握している
• [ ] 不明点は確認済み

よくある失敗と対策

まとめ

仕様理解のポイント

1. 実装前に仕様を確認する：「たぶんこう」で始めない
2. 4つの観点で確認：What、How、Relation、Constraint
3. 不明点は質問する：確認5分で手戻り5時間を防ぐ
4. 担当範囲に集中：全部理解しようとしない

次のステップ

仕様を理解したら、Step 2：実装計画を立てる に進みましょう。

関連ページ

• 実装の進め方（全体概要）
• 設計書・仕様書の読み方
• 作業の依頼を受けたら