📖 読了目安 約7分
この記事の目次

Step4: 動作確認する

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

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

初心者あるある: 「エラーが出ないから大丈夫」→ 実は正しく動いていない

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

  • バグの発見が遅れる: テスト工程や本番で初めて問題が発覚
  • 原因特定が困難: 時間が経つほど「どの変更が原因か」分からなくなる
  • 手戻りが大きい: 後工程で見つかるほど修正コストが増大
バグ発見タイミングと修正コスト

実装直後  : ████ 1時間で修正
単体テスト: ████████ 数時間
結合テスト: ████████████████ 1日
本番環境  : ████████████████████████████ 数日〜

動作確認の3つのレベル

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

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

✅ チェックポイント
- コンパイルエラーがないか
- 構文エラーがないか
- 型の不一致がないか

方法:

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

# TypeScript
npm run build

# Python
python -m py_compile script.py

レベル2: 実行確認

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

✅ チェックポイント
- 実行時エラーが出ないか
- 処理が最後まで完了するか
- 明らかな異常動作がないか

方法:

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

レベル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());
}

何を確認すべきか

正常系の確認

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

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

□ 商品ID: 1, 数量: 1 で注文できる
□ 商品ID: 1, 数量: 10 で注文できる
□ 注文後、DBにレコードが登録されている
□ 注文後、確認メールが送信される

境界値の確認

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

境界値の例

数量の境界値:
- 最小値: 1（注文可能な最小）
- 最大値: 99（注文可能な最大）
- 境界: 0, 1, 99, 100

文字列の境界値:
- 空文字: ""
- 最大長: 100文字ちょうど
- 最大超過: 101文字

異常系の確認

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

異常系の例

□ 必須項目が空の場合、エラーになるか
□ 数量に0を入れたら、エラーになるか
□ 存在しない商品IDでエラーになるか
□ 在庫不足の場合、エラーになるか

確認結果の記録

なぜ記録が必要か

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

記録の方法

1. スクリーンショット

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

2. ログの保存

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

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

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

動作確認でよくある失敗

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

実践チェックリスト

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

確認の網羅性

  • [ ] 正常系を確認した
  • [ ] 異常系を確認した
  • [ ] 境界値を確認した

確認の質

  • [ ] 期待値を事前に決めて照合した
  • [ ] 結果を目視だけでなく、データも確認した
  • [ ] 確認結果を記録した

確認のタイミング

  • [ ] コード修正後に再確認した
  • [ ] コミット前に確認した

次のステップ

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

→ Step5: デバッグする

関連ページ