トラブル対応の考え方

トラブル対応の基本姿勢

1. 慌てない、焦らない

トラブルに遭遇すると焦りますが、焦ると判断を誤ります。落ち着いて対応することが最も重要です。

• ❌ 焦ってやりがちなこと：原因が分からないまま、あちこち変更する
• ❌ 焦ってやりがちなこと：変更した内容を記録しない
• ❌ 焦ってやりがちなこと：30分悩んでから相談する（遅い）
• ⭕ 落ち着いてやること：まず深呼吸する
• ⭕ 落ち着いてやること：現状を正確に把握する
• ⭕ 落ち着いてやること：変更する前に状態を記録する

2. 「動いていたこと」を信じる

「さっきまで動いていた」なら、その間に何かが変わったはずです。何が変わったのかを探すことから始めましょう。

変わったことの候補：

• 自分が変えたもの：コード、設定ファイル、環境（インストール、再起動）
• 自分以外が変えたもの：他の人のコード更新（git pull）、外部サービス障害、サーバー側の変化

3. 仮説を立ててから動く

「とりあえず色々試す」のは非効率です。仮説→検証→結果のサイクルを意識的に回します。

flowchart LR
    A[問題発生] --> B[情報収集]
    B --> C[仮説を立てる]
    C --> D[検証する]
    D --> E{解決?}
    E -->|No| C
    E -->|Yes| F[原因と解決策を記録]

仮説の立て方：

• 「〇〇が原因ではないか？」と具体的に考える
• 一度に1つの仮説だけを検証する
• 検証結果を記録する

問題の切り分け方

トラブル対応で最も重要なのは「どこで問題が起きているか」を特定することです。これが分からないと、間違った方向で対応に時間を費やすことになります。

切り分けの基本：二分法

問題を半分に分けて、どちら側に原因があるかを特定します。例えば、Webアプリで画面にデータが表示されない場合：

• フロントエンド側の問題？データは受け取れている、表示処理でエラーが出ている、そもそもAPIを呼んでいるか
• バックエンド側の問題？APIは正しく動いている、データベースにデータはある、認証/権限の問題

このように「前半か後半か」「自分側か相手側か」という二者択一で絞り込んでいくことで、調査範囲を効率的に狭められます。

切り分けの質問リスト

以下の質問に答えていくと、問題の場所が絞り込めます。

切り分けのテクニック

1. 変更を元に戻す

直近の変更が原因かを確認する最も確実な方法です。

1. 直近の変更を一時的に元に戻す
2. 動作確認：動く場合は直近の変更が原因、動かない場合はそれ以前の問題
3. 判定後、変更を戻す

2. 最小構成で試す

問題が起きる範囲を狭めていきます。

1. 問題が起きるコード全体で試す
2. 関係なさそうな部分を削除して試す
3. さらに削除して最小構成にする
4. 動いた地点から、最後に削除した部分が原因と判定

3. 別の方法で試す

同じことを別の方法で試して、問題の切り分けをします。例えば、APIが動かない場合：

• ブラウザから直接アクセス → 動く？
• 別のツール（cURL、Postman等）で呼び出し → 動く？
• 別のデータで試す → 動く？

動くなら、元の方法に問題があります。

情報収集の方法

問題を解決するには、正確な情報が必要です。何を見て、何を記録するかを知ることが、効率的なトラブル対応につながります。

何を見るか

1. エラーメッセージ

最も重要な情報源です。全文を読むことが鉄則です。

エラーメッセージの構造：

• 最初の行：何が起きたか（エラーの種類）
• 2行目以降：どこで起きたか（ファイル名と行番号）
• 自分のコードで最初に出てくる行：調査開始地点

2. ログ

処理の流れと、どこまで動いたかが分かります。確認すべきログ：

• アプリケーションが出力するログ
• フレームワークやサーバーのログ
• ブラウザの開発者ツール（Console, Network）

3. 実際の値

「こうなっているはず」ではなく、「実際はどうか」を確認します。

• 変数の中身を出力してみる
• 処理の途中経過を出力してみる
• 入力と出力を確認する

何を記録するか

問題を報告したり、後で振り返るために、以下を記録する習慣をつけましょう。

• 何をしたら問題が起きたか（再現手順）
• どんなエラーが出たか（エラーメッセージ全文）
• いつから起きているか
• どの環境で起きているか
• 試したこととその結果

記録の例：

## 問題
ログインできない

## 再現手順
1. ログイン画面を開く
2. 正しいメールアドレスとパスワードを入力
3. ログインボタンをクリック
→ 「認証に失敗しました」と表示される

## エラーメッセージ
POST /api/login 401 Unauthorized

## 試したこと
- 別のアカウントで試す → 同じエラー
- パスワードリセット → リセット後も同じエラー
- 開発者ツールで確認 → トークンが null になっている

## 分かったこと
認証トークンの発行処理に問題がありそう

調べ方のコツ

エラーメッセージの読み方

1. キーワードを抽出する

エラーメッセージから、検索に使うキーワードを抽出します。固有のパス名や数値は除き、エラーコードや一般的なメッセージの部分に注目します。

2. 固有の情報を除いて検索する

• ❌ ダメな例：「Cannot find module '/Users/yamada/project/src/helper.js'」（パスが固有）
• ⭕ 良い例：「Cannot find module」エラー

3. エラーコードがあれば活用する

HTTP 500、ORA-12154、SQLSTATE[42000]のようなエラーコードがあれば、そのコードで検索すると公式情報が見つかりやすいです。

検索のコツ

検索結果の信頼度（優先順位）：

1. 公式ドキュメント → 最も信頼できる
2. GitHub Issues → 同じ問題を踏んだ人がいる
3. Stack Overflow → 解決策が見つかりやすい
4. 技術ブログ → 解説が詳しい（ただし古い情報に注意）
5. AI → 素早く概要を掴める（検証は必要）

古い情報に注意：記事の投稿日・更新日、対象のバージョン、現在のバージョンとの差を確認することが重要です。

助けを求めるタイミングと方法

いつ助けを求めるか：15分ルール

トラブル対応では「一人で悩みすぎない」ことが大切です。以下が目安です。

1. 問題発生
2. 15分間、自分で調査・試行
3. 15分経っても解決しない → 助けを求める

ただし、本番環境に影響がある、他の人の作業をブロックしている、全く見当がつかない（調べ方も分からない）、同じエラーで30分以上悩んでいるような場合は、すぐに相談しましょう。

どう助けを求めるか：相談の準備

相談は「相手の時間をもらう」ことです。以下の準備をしてから相談しましょう。

トラブル対応のチェックリスト

問題が起きたら、このチェックリストを上から確認してください。

まとめ

トラブル対応の考え方は、技術や言語が変わっても変わらない基本的な「思考プロセス」です。以下のポイントを意識することで、トラブルに直面した時の対応時間を大幅に短縮できます。

• 慌てない - 焦ると判断を誤る
• 仮説を立てる - 「とりあえず試す」は非効率
• 切り分ける - 「どこで問題が起きているか」を特定
• 記録する - エラーメッセージ、試したこと、結果
• 15分で相談 - 一人で悩みすぎない

トラブル対応力は経験で伸びます。解決したら記録を残す習慣をつけることで、次のトラブルに対する対応速度も格段に上がります。

関連ドキュメント

• デバッグの基本 - デバッガの使い方（ツールの操作）
• 不具合対応の進め方 - 不具合調査のプロセス（業務の流れ）
• 調べ方の基本 - 効果的な検索方法
• 困ったときの対処法 - 困ったときの相談方法