実装の進め方

設計書に基づいて実装（コーディング）を行う際の進め方を学びます。この章では、実装作業の全体像を理解し、各ステップで何をすべきか、なぜそれが必要なのかを解説します。

なぜ「進め方」を学ぶ必要があるのか

プログラミングのスキルがあっても、「進め方」を知らないと次のような問題が起きます：

flowchart TB
    subgraph 進め方を知らない場合
        A1[いきなりコードを書く] --> A2[途中で仕様の理解不足に気づく]
        A2 --> A3[大幅な手戻り]
        A3 --> A4[納期に間に合わない]
    end

    subgraph 進め方を知っている場合
        B1[仕様を理解する] --> B2[計画を立てる]
        B2 --> B3[小さく実装・確認を繰り返す]
        B3 --> B4[品質の高いコードが完成]
    end

実装の進め方を身につけることで：

• 手戻りを最小限に抑えられる
• 見積もりが正確になり、進捗報告ができる
• レビューでの指摘が減る
• 安定したペースで開発できる

実装の全体フロー

実装作業は、以下の8つのステップで進めます。

flowchart LR
    A[Step1<br/>仕様理解] --> B[Step2<br/>計画]
    B --> C[Step3<br/>実装]
    C --> D[Step4<br/>動作確認]
    D --> E{問題あり?}
    E -->|Yes| F[Step5<br/>デバッグ]
    F --> C
    E -->|No| G[Step6<br/>リファクタリング]
    G --> H[Step7<br/>セルフチェック]
    H --> I[Step8<br/>レビュー]

各ステップの詳細は、それぞれのページで解説します。

各ステップの概要

Step 1：仕様を理解する

何を作るのかを明確にするステップです。

• 設計書・仕様書を読み込む
• 入力・出力・振る舞いを把握する
• 不明点は実装前に確認する

なぜ重要？：仕様を誤解したまま実装すると、「作ったけど違った」という手戻りが発生します。確認に5分かけることで、作り直しの5時間を防げます。

→ 詳細は Step 1：仕様を理解する を参照

Step 2：実装計画を立てる

どう進めるかを決めるステップです。

• タスクを小さく分解する
• 実装順序を決める
• 見積もりを立てる

なぜ重要？：計画なしに始めると、どこから手をつけていいか分からなくなります。また、「今日はここまで」という区切りがつけられず、進捗が見えなくなります。

→ 詳細は Step 2：実装計画を立てる を参照

Step 3：実装する

実際にコードを書くステップです。

• 小さく始めて、少しずつ完成させる
• こまめに動作確認しながら進める
• 既存コードのスタイルに合わせる

なぜ重要？：いきなり完成形を目指すと、どこで問題が起きているか分からなくなります。小さく作って確認を繰り返すことで、問題を早期に発見できます。

→ 詳細は Step 3：実装する を参照

Step 4：動作確認する

作ったものが動くことを確認するステップです。

• 正常系・異常系・境界値をテスト
• 実際に操作して確認
• 問題があればデバッグへ

なぜ重要？：「動くはず」と思ってレビューに出して動かないと、信頼を失います。自分で確認してから出すことで、レビュアーはロジックの確認に集中できます。

→ 詳細は Step 4：動作確認する を参照

Step 5：デバッグする

問題を特定して解決するステップです。

• エラーメッセージを読む
• 問題箇所を特定する
• 原因を突き止めて修正する

なぜ重要？：バグは必ず発生します。効率的なデバッグ方法を知っていれば、問題解決の時間を大幅に短縮できます。

→ 詳細は Step 5：デバッグする を参照

Step 6：リファクタリングする

動作を変えずにコードを改善するステップです。

• 重複を除去する
• 分かりやすい名前に変える
• 構造を整理する

なぜ重要？：「動くコード」と「良いコード」は別物です。まず動くものを作り、それから読みやすく保守しやすいコードに整えます。

→ 詳細は Step 6：リファクタリングする を参照

Step 7：セルフチェック

レビューに出す前に自己確認するステップです。

• 仕様通りか確認
• 規約に従っているか確認
• 不要なコードを削除

なぜ重要？：レビュアーに指摘される前に自分で見つけることで、レビューの効率が上がります。また、セルフチェックの習慣は品質向上につながります。

→ 詳細は Step 7：セルフチェック を参照

Step 8：コードレビュー

他のエンジニアにコードを確認してもらうステップです。

• レビュー依頼を出す
• 指摘を受けて修正する
• 承認されたらマージ

なぜ重要？：自分では気づけない問題を発見できます。また、チームで知識を共有し、コード品質を統一する機会でもあります。

→ 詳細は Step 8：コードレビューの受け方 を参照

よくある失敗パターン

パターン1：いきなりコードを書き始める

flowchart LR
    A[仕様を確認せず実装開始] --> B[途中で「あれ？」と気づく]
    B --> C[仕様を再確認]
    C --> D[大幅な修正が必要に]
    D --> E[時間をロス]

対策：Step 1で仕様を理解してから始める

パターン2：長時間書いてから確認

flowchart LR
    A[100行書いてから実行] --> B[動かない]
    B --> C[どこが悪いか分からない]
    C --> D[デバッグに時間がかかる]

対策：Step 3で「10行書いたら確認」を心がける

パターン3：動いたらそのまま提出

flowchart LR
    A[動いた！] --> B[そのままレビュー依頼]
    B --> C[レビューで大量の指摘]
    C --> D[修正に時間がかかる]

対策：Step 6でリファクタリング、Step 7でセルフチェックしてから提出

1年目に意識すること

「急がば回れ」の精神

• 仕様確認や計画に時間をかけることは、無駄ではない
• 手戻りを防ぐための「先行投資」と考える
• 結果的に、トータルの時間は短くなる

小さく・こまめに

• 大きな塊で作業しない
• 少し進んだら確認する
• 問題は早期に発見する

分からないことは聞く

• 仕様の不明点は実装前に確認
• 技術的に分からないことは質問
• 「聞いていいのかな」と迷ったら聞く

次のステップ

まずは Step 1：仕様を理解する から始めましょう。

関連ページ

• 作業の依頼を受けたら（第1章 案件開始）
• デバッグの基本（第2部 基礎知識）