同じエラーを何度も調べているなら、エラー名だけを集めるより、起きた作業、確認した事実、次に見る場所を一緒に残します。メッセージが同じでも、入力が欠けた場合と、実行者の権限が変わった場合では、対応が違うためです。
エラー対応表は原因を即断するための一覧ではありません。次の担当者が何を確認済みで、何をまだ調べる必要があるかを読める形にします。
1件の記録へ入れる項目
最初に、業務名、実行日時、処理した対象を記録します。続いて、止まった段階、エラー名、確認した入力と出力、実施した対応、結果を残します。
| 項目 | 記入する内容 |
|---|---|
| 実行の識別 | 日時、処理名、実行を見分ける値 |
| 対象 | 入力ファイルや受付ID、処理期間 |
| 発生した段階 | 読み取り・検査・保存・送信など |
| 観測した事実 | メッセージ、件数、保存先の状態 |
| 原因 | 確認できた内容。仮説とは分ける |
| 対応と結果 | 何を変え、どの入力で確かめたか |
「権限エラーだった」とだけ書くと、どのアカウントと対象の組み合わせかが残りません。ファイルIDや実行者の確認が必要な場合は、その値を保存してよい範囲で記録します。
症状と原因を分ける
以下は記録の書き方を示す架空の例です。実際に起きた障害の報告ではありません。
| 症状 | 確認した事実 | 次に見る場所 |
|---|---|---|
| 集計結果が0件 | 入力の件数も0件だった | 対象期間と読み取った範囲 |
| Driveのファイルを開けない | 担当交代後のアカウントで失敗 | ファイルIDとその人の権限 |
| 通知の記録がない | 保存は終わっているが送信結果が不明 | メールの実物と送信記録 |
0件の原因がコードとは限りません。データの提出前に処理を動かしただけ、という場合もあります。調べる前の仮説を、確認済みの原因として記入しないようにします。
GoogleのDriveAppリファレンスでも、対象が存在しない場合やアクセス権限がない場合の例外が説明されています。メッセージだけから、ファイルの削除と権限不足のどちらかを決めつけないことが大切です。
対応を再現できる形で残す
「設定を直して解決」では、次に同じ状況が起きた人が再現できません。どの設定名を、どういう理由で変え、何を確認したかを書きます。秘密の値そのものを対応表へ残す必要はありません。
変更前の状態が必要なら、公開してよい設定名や件数を控えます。結果は「エラーが消えた」に加えて、出力の件数や、保存先、通知の状態も確認します。処理が正常終了しても、対象を読めていなければ、業務の成功にはなりません。
再実行と二次被害の確認
再実行前にはどこまで終わったかを調べます。行の追加や外部送信を含む場合は、既に処理済みの対象をもう一度扱わない条件が必要です。
完了した範囲が分からないなら、「再実行保留」と理由を書き、確認する人を決めます。対応表には再実行してよい条件と、止めて連絡する条件を分けて載せます。すべてのエラーへ同じ再試行を当てはめないようにします。
対応表の見直し方
古い行は現在のコードやサービスの仕様でも同じ対応になるかを確認します。最後に確かめた日と、確認したバージョンや環境を残すと、過去の手順をそのまま使ってよいか判断できます。
GASのログの種類は公式ロギングガイド、利用量や制限による停止は割り当ての説明で確認できます。原因の種類を分け、実際に役立った確認手順を残していくと、次の調査で同じ入口へ戻らずに済みます。
