何かアプリケーションに不具合があったときの原因調査にて何を考えてどういった作業をすべきか
大きく以下の2つに分けて考えるべきだと思っている。
経験と直感から原因を予想する
なんだかんだでまずはこれだと思う。
が、経験と直感による想定が全部はずれた時（もしくは何も思いつかなかった場合）に、経験も直感も度外視した、純粋な「勘」による調査をする人達がいる。あんまり良い結果にならないと思うんだけど、気持ちはわかる。
MVCモデルで作られたWebアプリで画面から選択したソート項目が効いていない場合に、例えばリポジトリとサービスはしっかり試験してるけどコントローラーは怪しいな・・・みたいな経緯があればコントローラーを疑うとか。なるべくプリミティブなところから網羅的に原因を探る
もし経験と直感から原因が判定できなかったのであれば、これをちゃんとやるべきという話をしたいだけ（そして自分でもそれを徹底しようという話）なんだけど、結構これがちゃんとできない。
MVCモデルで〜の例で言えば、まずDBに発行されたクエリを確認するべきなんじゃないだろうか。ちゃんとソートされるような発行されていたら、次にリポジトリで余計なこと（取得したデータの再ソートとか）してないかみて、サービスで余計なことをしてないか見て・・・と、一番根っこのところから一つずつ（可能性を加味した順序付けはしてもいいと思うが、網羅的であること）原因になりそうなところを潰していくべきなんじゃないだろうか。
でもこれをせずに、永遠に感覚に頼った調査をする人はたくさんいる。
今クエリログ出してないし設定かえるのめんどくさいな・・・と思って、ただひたすらにソースコードを眺めるようなことをし続けてしまうような。
どうしてこの作業は面倒くさいのか
効率が（おそらく）よいにもかかわらず、真面目で網羅的な調査は面倒くさい。
なんでか考えて思ったのは、普通の生活でこういうやり方をして特をすることがあまりないからなんじゃないだろうか。
テレビがおかしくなった時に、私たちは、
「経験と直感から原因を予想する」まではやると思う。わからんけど。アンテナを疑ったり、コンセントがちゃんと刺さっているか確認したり。
でも、それで解決しなかったときに私たちはテレビの構造について1から調べたり、テレビを分解して何がまずいのか調査したりはしない。
なぜなら効率が悪いから。叩いてみて、駄目だったら専門家に任せたほうが楽だし、コストもかからない。
でもアプリケーションの開発をしている以上、自分が専門家で、これは必要な作業なんじゃないだろうか。
テレビの専門家に不具合の調査や修正を任せた場合も、まず「経験と直感から原因を予想する」はやると思うけど、叩いてなおそうとはしないんじゃないだろうか。（叩いたときの挙動から原因を判断することはあるかもしれないけど）
何を言いたいのかというと、私が不具合調査をするときに、2を徹底できるようになりましょう、ということ。
4年位SEをやったけど、2を真面目にやらなくてよい結果になったことはあまりなかった気がする。（まったくのゼロじゃないところが意識を鈍らせているが、トータルで考えればうんちである可能性が高い）
