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

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

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

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