調査依頼があったときのおおまかな進め方

• 1. 調査依頼の受領
  • 「こんなエラーが出た」「この辺りの仕様はどうなっていますか？」などの調査依頼がチケットとして届く
• 2. 再現性の確認
  • もらった情報を元に、まずは依頼者が直面しているエラーや問題が手元で再現するかどうかを試行する。
    • 再現できた場合 ... 3.へ進む。
    • 再現できなかった場合 ... エラー発生時の状況（実行したコード、画面操作の内容、入力した値、どの環境で実行したかなど）を追加で詳しく連携してもらう。
• 3. 事実の収集
  • 処理の流れを考え、「最初のエラーは具体的にどこで発生しているのか」「どこまでは想定通り動いているのか」を明確にする。
  • こちら側で追加で収集できるもの（動作ログや開発資料）があれば、収集しておく。
• 4. 調査の実施（原因の仮説を定義し、仮説の検証を行う）
  • いろんな側面で原因の仮説を立て、可能性の高いものから動作確認を行い、具体的な発生条件を順に明らかにする。
    • <具体的な発生条件の例> 「6桁のときはエラーになるが、7桁の時はエラーにならない」などの切り分け情報
  • バリエーション・発想が大事になってくることもあるので、必要に応じてメンバーに相談する。
• 5. 真因の特定
  • 明らかにした発生条件を整理し、エラーや問題に直接的に作用している発生条件を明確にする。
  • 必要に応じて、その真因が発生するに至った背景・経緯も可能な範囲で調べる。
• 6. 不具合の修正および報告
  • 原因や修正内容を整理し、対応と報告を行う。
  • 本番運用などでは「暫定対処」「恒久対処」のように、2段階で対処を行う。（まずは取り急ぎ問題を解決してから、その後の根本的な原因を解消する、といった流れ）

「原因の仮説定義および仮説の検証」のイメージ

• [疑問や課題]どうしてこのようなエラーが出るのか？
  • [原因の仮説1] 変数のデータ型が異なっているために処理中の型変換が行えず、エラーとなってしまう。
    • [仮説の検証結果1] いいえ。データ型をdouble型で揃えてみても、エラー内容に変化はなかった。
      • [得られた事実1] データ型の差異はエラーの原因ではない。
  • [原因の仮説2] 文字コードがUTF-8ではなく、想定外の入力値となってしまっている。
    • ...