エラーの内容を渡すときの形

• エラー文だけでは、推測になる
• 何をしたときに出たか、添える
• 直前に変えた箇所を必ず書く

エラーが出たとき、文面だけ貼っていた。それでは解決しないと分かった。

エラー文だけでは足りない

貼るだけだと、こうなった。

• 一般的な原因が並ぶ
• 自分の状況に当てはまらない
• 試して、どれも違う

3つ目で時間を失った。状況を渡していないので、推測しかできない。

添える情報

いまは、4つ添えている。

• 何をしたときに出たか
• 直前に何を変えたか
• エラー文の全体
• 関係しそうなコード

2つ目が最も効く。直前の変更が原因である場合が多い。

エラー文は全部渡す

最初は、1行だけ貼っていた。

• 最後の行だけでは、場所が分からない
• どこから呼ばれたかが、上の行にある
• 長くても、全部渡す

2つ目が重要だ。原因は、エラーが出た場所と別のことがある。

再現するか確認する

渡す前に、再現するか確かめている。

• 同じ操作で、また出るか
• 毎回出るのか、時々なのか
• 条件が分かれば、添える

2つ目が判断を分ける。時々しか出ないものは、原因の種類が違う。

直前の変更を書く

最も効く情報なので、必ず書いている。

• 何を変えたか
• 変える前は動いていたか
• 戻すと直るか

3つ目を先に試す。戻して直れば、原因はその変更にある。

戻して確認する

聞く前に、自分で切り分けている。

• 直前の変更を戻す
• 直れば、その変更が原因
• 直らなければ、別の原因を探す

2つ目まで分かると、聞く内容が具体的になる。

環境も渡す

環境の情報も添えている。

• 使っている仕組みと、その版
• どこで動かしているか
• 手元か、公開中のものか

1つ目が必要だ。版によって、原因が変わる。

エラーが出ています。

エラー文：（省略せず全文。スタックトレースも）
いつから：（直前に変えたこと）
どの操作で：（再現する手順）
毎回起きるか：（毎回／たまに／特定の条件のときだけ）
環境：（PHP・WordPress・テーマ・プラグインの版）

原因の候補を、可能性の高い順に3つ挙げてください。
それぞれ「どう確かめるか」も添えてください。まだ直さないでください。

関係しそうなコードを絞る

コードは、全部渡さない。

• エラーに出ている箇所の周辺
• そこから呼ばれている箇所
• 関係ない箇所は渡さない

3つ目が理由だ。量が多いと、指摘が浅くなる。

推測で埋めさせない

情報が足りない場合の扱いも指定する。

• 「足りない情報があれば、聞いて」
• 「推測で答えないで」
• 聞かれたら、渡す

2つ目を書いている。書かないと、推測で答えが返る。

複数の原因を出させる

1つに絞らせないようにしている。

• 「考えられる原因を3つ」
• 「確認する順番も書いて」
• 確認しやすい順に並べさせる

3つ目が実用的だ。確認が簡単なものから試すと、速い。

確認の手順を聞く

原因より、確認方法を聞くほうが役に立つ。

• 「どこを見れば切り分けられるか」
• 「どう確認すれば分かるか」
• 自分で確認して、原因を特定する

3つ目の形にした。確認の手順が分かれば、自分で進められる。

直し方は後で聞く

原因が分かるまで、直し方は聞かない。

• 原因が違えば、直し方も違う
• 先に直すと、別の問題が出る
• 原因を特定してから、直し方を聞く

2つ目が起きた。原因を押さえずに直すと、症状が変わるだけ。

記録を残す

解決したら、記録に残している。

• エラー文の特徴
• 原因
• どう確認したか

3つ目が後で使える。同じエラーが出たとき、確認方法から試せる。

同じエラーが出たとき

記録があると、対応が速い。

• 記録を検索する
• 同じなら、前の手順で確認する
• 違えば、新しく記録する

1つ目のために、エラー文の特徴を記録に入れている。

解決しない場合

それでも分からない場合の手順も決めた。

• いったん戻して、動く状態にする
• 小さく作り直して、再現させる
• 再現する最小の形で、聞き直す

2つ目が効く。最小の形にすると、原因が見える。

人に聞く場合との違い

人に相談する場合も、渡す情報は同じだ。

• 何をしたとき出たか
• 直前に何を変えたか
• 自分で何を試したか

3つ目を添えると、相手の手間が減る。試したことを書かないと、同じことを勧められる。

まとめ

• エラー文だけでは、推測しか返らない
• 何をしたとき出たか、直前に何を変えたかを添える
• エラー文は1行ではなく、全体を渡す
• 原因より、確認の手順を聞くほうが使える
• 原因を特定する前に、直し方を聞かない