日曜日のワークアウト分の筋肉痛がとれなくて困ってる。
気づけばもう２月になった。早すぎる。ジャネーの法則が効きすぎる。
さて、最近は不具合調査を何件もやっている。謎解きゲームみたいで面白い。
不具合調査のコツは「確率の高い順に素早く仮説検証を繰り返す」に尽きる。順を追って説明する。
１．不具合調査のゴールは「再現させること」
再現させることができれば、修理することができる。ソフトウェアのプログラムが複雑であれば複雑であるほど、不具合を再現させることが難しくなる。
たとえばスマホを操作していて、「何度タップしてもフリーズしてアプリが動かなくなった」みたいな状況は誰しも経験したことがあると思うが、そのフリーズ状態をもう一度再現させようと思って色々操作してみても、意図的には二度と発現させることができないといった具合だ。
そのフリーズ事象を、必ず再現させる方法が見つけるのがゴール。
２．すぐにやる。
今日処理したらエラーになったが翌日になったら直った。さっきは起きたけど今は起きない。
こうしたことは往々にしてある。だから、素早く仮説検証に着手する必要がある。
わかりやすい例としては、再起動したらメモリがクリアされて直ったとか、自動配信のファームアップで直ったとか、４年に１度しかない閏日が考慮されておらず2/29には不具合が出たが3/1になったら直るといった、「時点が移動すること」で発現しなくなることも多く、そうなると不毛な調査コストをとられるので、とにかくその時点を捕捉して素早く調査に入ることが肝要。
３．レイヤーの特定。
基本的に、本番環境（実機）で試せるなら本番環境でやるべきだ。無論、そうした確認が憚れる場合もあるため、やむなくステージングで確認しなければならない場合もあるが、その辺は業務特性に応じて頭に入れておかねばならない。
次に、レイヤーを見極める。レイヤーというのは、その「端末」で起きているのか、「ネットワーク」が悪いのか、「ソフトウェア」が悪いのか、「データが悪い」のか、「機械が故障」したのか。ここは能力の差が現れる。いろいろな切り分け方法があるため一言では語り尽くせないが、強いてあげるなら『他の状況と見比べる』が有用。
他のPCでは動作する、他の業務画面は動作する、他のデータであれば動作する といったように、瞬時に確認パターンを思いついて実行する。
経験によるところが大きいとは思うものの、素人とて 電子機器が不調になると、ケーブルを変えてみたり、入力デバイスを変えてみたり試行錯誤すると思うが、それと全く同じ。
４．原因の特定。
レイヤーがわかったら、あとはひたすらログ・ソース・データ を見る。これに尽きる。
４が得意なエンジニアは強い。１～３は比較的誰でもできるようになるビジネススキルだが、４についてはスキルが物言うエリア。そして４が一番おもしろい。高級なIDEでステップ実行して見つけるのも醍醐味だが、エディタ１つで見つけるのもこれまた腕の見せ所。
コンソールログやプログラムソースは、ドラクエで言うところの村人たちの会話だ。ちゃんと読めば原因まで案内してくれる。
大事だけど言語化されていない仕事の内容って結構ある。不具合調査の方法 なんていう抽象的なテーマにも普遍的なことを体系的に積み上げていけると良い。
