第4部：実務スキル ／ 第2章：実装作業

Step 4：動作確認する

実装したコードが正しく動くかを確認するステップです。「動かしてみたら動いた」ではなく、意図通りに動いているかを確認することが重要です。

📖 読了目安 約12分 対象：実装作業に入る方

なぜ動作確認が重要なのか

初心者あるある

「エラーが出ないから大丈夫」→ 実は正しく動いていない

動作確認を怠ると、以下のような問題が起こります：

  • バグの発見が遅れる：テスト工程や本番で初めて問題が発覚
  • 原因特定が困難：時間が経つほど「どの変更が原因か」分からなくなる
  • 手戻りが大きい：後工程で見つかるほど修正コストが増大
flowchart LR
    subgraph 修正コスト
        A["実装直後
1時間で修正"] --> B["単体テスト
数時間"]
        B --> C["結合テスト
1日"]
        C --> D["本番環境
数日〜"]
    end

    style A fill:#e8f5e9
    style B fill:#fff3e0
    style C fill:#ffe0b2
    style D fill:#ffcdd2

動作確認の3つのレベル

レベル 1：コンパイル・構文チェック

確認すること：コードが文法的に正しいか

  • ✅ コンパイルエラーがないか
  • ✅ 構文エラーがないか
  • ✅ 型の不一致がないか

方法：

  • IDEの赤線（エラー表示）を確認
  • ビルドコマンドを実行
## Java
mvn compile

## TypeScript
npm run build

## Python
python -m py_compile script.py

レベル 2：実行確認

確認すること：プログラムが動くか

  • ✅ 実行時エラーが出ないか
  • ✅ 処理が最後まで完了するか
  • ✅ 明らかな異常動作がないか

方法：

  • アプリケーションを起動
  • 対象の機能を実行
  • ログやコンソール出力を確認

レベル 3：仕様通りの動作確認

確認すること：仕様通りに動いているか（最も重要）

  • ✅ 期待した結果が返ってくるか
  • ✅ 画面に正しい値が表示されるか
  • ✅ データベースに正しく保存されるか
  • ✅ エラーケースで適切に処理されるか

なぜレベル 3 が最も重要？

コンパイルが通り実行時エラーがなくても、仕様と違う動作をしていることは多々あります。「動いている」と「正しく動いている」は別物です。

動作確認の具体的な方法

方法 1：手動で動かして確認

最も基本的な方法です。

Webアプリの場合

  1. ブラウザで画面を開く
  2. フォームに値を入力
  3. ボタンをクリック
  4. 結果を目視で確認

APIの場合

## curlでリクエストを送信
curl -X POST http://localhost:8080/api/orders \
  -H "Content-Type: application/json" \
  -d '{"itemId": 1, "quantity": 2}'

## レスポンスを確認
{"orderId": 123, "status": "created"}

バッチ処理の場合

  1. 入力データを用意
  2. プログラムを実行
  3. 出力結果を確認
  4. DBの状態を確認

方法 2：デバッガで動作を追う

処理の流れを詳細に確認したい場合に有効です。

  1. ブレークポイントを設置
    • 確認したい行にブレークポイントを設定
  2. デバッグ実行
    • 通常の実行ではなくデバッグモードで起動
  3. ステップ実行
    • F10：次の行へ（Step Over）
    • F11：関数の中に入る（Step Into）
    • Shift+F11：関数から出る（Step Out）
  4. 変数の値を確認
    • 各変数の中身をリアルタイムで確認

方法 3：ログ出力で確認

本番に近い形で動作を確認する場合に有効です。

// 確認用ログを追加
logger.debug("注文処理開始: orderId={}", orderId);
logger.debug("在庫確認結果: stock={}", stock);
logger.debug("計算結果: total={}", total);

確認後はログを整理

確認用に追加したログは、確認後に適切なレベルに修正するか削除しましょう。

方法 4：単体テストを書いて確認

再現性のある確認方法です。

@Test
public void 正常な注文が登録できること() {
    // 準備
    Order order = new Order();
    order.setItemId(1);
    order.setQuantity(2);

    // 実行
    OrderResult result = orderService.createOrder(order);

    // 確認
    assertEquals("created", result.getStatus());
    assertNotNull(result.getOrderId());
}

何を確認すべきか

正常系の確認

まずは「うまくいくケース」を確認します。

確認項目例（注文登録機能の場合）

境界値の確認

「ぎりぎりの値」を確認します。

境界値の例

数量の境界値：

  • 最小値：1（注文可能な最小）
  • 最大値：99（注文可能な最大）
  • 確認する値：0, 1, 99, 100

文字列の境界値：

  • 空文字：""
  • 最大長：100文字ちょうど
  • 最大超過：101文字

異常系の確認

「うまくいかないケース」も確認します。

確認結果の記録

なぜ記録が必要か

  • 証拠として残る：「確認しました」の裏付け
  • 再現性：同じ確認を誰でもできる
  • レビュー材料：コードレビューで確認方法を説明できる

記録の方法

1. スクリーンショット

  • 確認画面のスクショを撮る
  • 「正常に登録できました」画面
  • エラーメッセージの画面

2. ログの保存

  • 実行時のログを保存
  • 正常終了のログ
  • エラー発生時のログ

3. テストケースとして残す

  • 自動テストとして記録
  • 後からいつでも同じ確認ができる
  • 回帰テストとして活用

動作確認でよくある失敗

失敗 1：正常系しか確認しない

❌「商品を1個注文したら登録できた。OK!」

→ 0個や100個、存在しない商品IDは？
→ エラーケースで適切にエラーになる？

対策：異常系・境界値も必ず確認する

失敗 2：目視で「なんとなくOK」

❌「画面にデータが表示された。たぶんOK!」

→ 表示されている値は正しい？
→ 計算結果は期待通り？

対策：期待値を事前に決めて、照合する

失敗 3：一度だけ確認して終わり

❌「さっき動いたから大丈夫」

→ その後コードを修正していない？
→ 環境が変わっていない？

対策：コード修正後は再度確認する

失敗 4：本番環境と違う条件で確認

❌「ローカルでは動いた」

→ 本番のデータ量では？
→ 本番の設定では？

対策：できるだけ本番に近い条件で確認する

失敗パターン対策
正常系しか確認しない異常系・境界値も必ず確認する
目視で「なんとなくOK」期待値を事前に決めて、照合する
一度だけ確認して終わりコード修正後は再度確認する
本番環境と違う条件で確認できるだけ本番に近い条件で確認する

実践チェックリスト

動作確認時は、以下を意識しましょう：

確認の網羅性

確認の質

確認のタイミング

次のステップ

動作確認で問題が見つかったら、デバッグに進みます。

→ Step 5：デバッグする

関連ページ