【エンジニア】想定外の挙動が起き調査が進まないときの対処法
ある挙動をさせたい、もしくはバグを直したいと思ったとき、こうすればうまくいくだろうという実装をしたとします。しかし、その実装をして試験的に動かしてみたところ想定通りに動作しませんでした。
こんな時あなたはどのように考えてどのような対応をするでしょうか？
私はこのような状況に何度も出くわしたことがあるのですが、そのたびに進め方が悪く長時間時間を使ってしまうことが多くありました。そんな風に戸惑ってしまっているところを中学生のころからプログラミングをしてきているとても優秀な上司にヘルプをしてもらったところすんなり問題が解決しました。
私の進め方のどこに問題があったのか、なぜ上司の進め方ではすぐに解決したのか、理論的に納得いく説が出来たので共有します。
Badな進め方
まずは私が行っていた悪い進め方を失敗例として話します。
私は想定しない挙動が発生したときにとりあえず考えられる解決策を片っ端から試していきました。その際に重要視したのは断片的に見えている情報です。断片的に見えている情報から最も可能性が高いであろう仮説を立てて、その仮説通りであるならばこうすれば解決するだろう、というような対応を考えて片っ端から試しました。
つまりは以下の流れです。
事象発生→仮説を立てる→実装→結果確認、以後仮説から結果確認を繰り返す
実はこの方法でもうまくいくことはありました。私はエンジニアとしての歴も短くはないので仮説を立てる能力も培われてきており、その仮説がドンピシャであたっていれば一瞬で解決できていました。
ただし、このやり方はうまくいかないときにはとことんうまくいかないです。
というのも仮説が外れて手戻りが発生した際のコストがとても大きいからです。
私がとったBadな進め方では、ある仮説をもとにした対応の結果を確認するには、実装と検証という2つの思い作業が必要です。また仮説自体が正しくなかった場合にはさらに手戻りが多くなります。
つまりこの調査のやり方はかなりハイリスクなのです。かなりの確信をもった仮説が立てられた場合はこの手法でも良いかもしれませんが、そもそも予期しない挙動が発生している時点で知識が不足している可能性は否めず、正しい仮説を立てられている可能性は低いため、基本的にこの対応方法はとるべきではないと私は考えています。
Goodな進め方
実はGoodな進め方とBadな進め方には大きな違いはありません。ある一つの工程が追加されるだけです。
その工程とは「想定外の挙動をしている理由を調査する」ことです。つまりGoodな進め方は以下になります。
事象発生→事象発生理由調査→仮説を立てる→実装→結果確認
想定外の挙動が起きているということは、つまり把握できていない仕様が存在するということです。この把握できていない仕様がどんな仕様なのかを理解しないと適切な仮説を立てることが出来ません。
Badな進め方では断片的な情報しか持っていないにも関わらず、その情報のみを頼りに仮説を立て、実装と検証という工程まで踏んでしまっていました。正確性の低い仮説をもとにコストの大きい実装と検証まで行うのは良くありません。得られる期待値が低いです。
しかし"なぜ想定外の挙動をしているのか"を完全に把握できれば、かなりの確度を持った仮説を立てることが出来ます。
さらなるコツ
実際のところなぜ想定外の挙動をしているのかを理解することはなかなか大変です。少しずつデバッグして確認できれば良いのですが、そうはいかないときもあります。そのときには対象を分割してみることをお勧めします。
例えばある一つの挙動をさせたいソースコードがあるとして大きく4つのフェーズに分けられるとします。その際には一度前半と後半で分けてみるのです。①②/③④のような形で。そしてそれぞれの結果を確認し、どちらに問題があるのかを把握します。この工程を挟むだけで問題の所在が絞り込めます。
もし後半部分にあるとしたらさらに分解してみます。③/④のような形で。このようにすることで問題の所在を当初の1/4に絞り込むことが出来ました。
把握しなおさないといけない仕様の範囲が1/4に絞られたことになります。確認対象をこのように分割→検証の順番で絞り込んでいきネットでの調査が必要な個所を最小限にする対応も有用です。
まとめ
調査タスクに取り組む際のコツについてまとめました。重要なことは以下の二点だけです。
①解決策よりも先に起きている事象の正確な把握に努める
②理解のためには対象の分割をして、正しく理解できていない部分を正確に把握する
この2つのコツを知っておくだけでタスクをこなすスピードは一気に上がるはずです。ぜひお試しください。