この間、トラブルシューティング（デバッグ）に参加する機会があった。
そこで、気づいたこと・得た教訓を記録しておく。
気づいたこと・教訓
-
作った人/直す人以外の人がデバッグするのもよい
- 作った人/直す人以外の人がデバッグすると、冷静にやれるし、バイアスがかかりにくい（思い込みの罠にはまりにくい）。
- 作った人は、自分の問題ではないと思いたい。直す人は、早く問題を特定したいと、焦る。
-
急がない
- 地道に仮設検証が大事。
- 間違った仮説を一つづつ積み上げ、調べる範囲を狭めていく。（原因を一発で見つけようとするのではなく、原因でないことを一つづつ見つけ積み上げていく）
- 原因は現象からすごく離れたところに存在していることもあるので、注意。
- まずは、問題を明らかにしようとするのではなく、メカニズムを明らかにする。
-
記録する
- 検証したこと・検証することは記録することが大事。同じ検証を繰り返さないように。「本当なの？あれ確認してたっけ？念のためもう一回確認してみよう。」などと、無駄に調べる行動が、抑制される。
- 仮説をツリー状に（FTAのような形式で）書いていくとよい。
-
仮説検証を停滞させない（そのために以下が大事）
- 自分の仮説に固執しない。
- 1人ではなく3人くらいでやる。新たな仮説が、誰かから出てくる。
- そもそも前提としていたことを疑う。
- 調査で使うツールも疑う。調査結果が間違っていることもある。
- 人の見解ではなく、目に見えている事実（コードとデータ）をもとに分析する。人の言葉を信用しない。
- わからないことは後回し、わかることから分析する。
- ちょっと休憩する。
-
その他注意点
- うまくいくときとうまくいかないときを比較するのは重要だが、比較しているデータに原因を示すものが含まれていない、または原因を示すものに目が向けられていなければ、結局原因に辿りつけない。差は、原因ではなく、現象である可能性もある。
参考文献
[1] 金子龍三，「先端技術者のためのトラブルシューティング技術―組込みシステムの品質問題をこの一冊で原因究明」，日科技連出版社，2005，https://bookmeter.com/books/1345074
[2] J. マイヤーズ，M. トーマス，T. バジェット，C. サンドラー，「ソフトウェア・テストの技法」，近代科学社，2006，https://bookmeter.com/books/4071