トラブルシュートができないエンジニアは、変数いじりすぎて自爆してる

@nabeemichi です。

エンジニアとしてプログラミングしていると、トラブルシュートはつきものです。 開発中に期待値とは異なる結果になってしまった場合やエラーが起こってしまった場合にすることもありますし、 既存システムを保守していて、ユーザーからエラー報告があった場合に修正するときにもトラブシュートをする必要があります。 なので、世の中のすべてのエンジニアはトラブシュートは経験するし、永遠にお友達なわけです。 ですので、効率的に開発するにはトラブシュートの時間を短くするとエラーに時間をられなくなるわけですが、これを効率的にできないエンジニアが多いのです。

効率的なトラブシュートって何？

ということなのですが、それは、

最短でエラーの根本原因を見つける

という、元も子もない当たり前のことになります。 もう少し具体的に話すと、 同じ動作のトラブシュートをしないでエラーの原因を特定するのです。

トラブシュートは理論と現象の２軸攻め

で原因を絞り込んでいきます。 エラーの現象やログを見て、原因がありそうなソースコードにある程度の予想をします。 その予想をもとに、ソースコードを読み漁り、原因になりそうな部分のを特定し、ソースコードから読み取った条件を整えて再現させ、条件を変更してエラーの根本原因を探します。

重要なのはソースコードから読み取った条件

この条件を変更させて、エラーの発生条件を探すのですが、 この条件が１つのパラメータだけで構成されている場合は問題ありません。 １つしかないパラメータの条件を変更して、動作を確認という作業を繰り返していれば、そのうちエラー発生条件は見えてくるでしょう。

ですが、このパラメータが複数になった場合が問題です。 例えば、エラーの原因の可能性がありそうなパラメータが[A, B, C]と３つあったとします。 パラメータ[A, C]の２つがエラーの原因だと予想できる状況だとしたとき、

トラブシュートが効率的なエンジニアは、一度にパラメータは１つしか動かさない

のです。 上記の場合だと、パラメータ[A]だけを変更させて、動作を確認してエラーの発生条件を探します。 では、なぜ同時にパラメータ[A, C]を動かさないかというと

同時に２つ動かしたら、どっちが原因かわからない

じゃん！ 同時にパラメータ[A, C]を動かして、エラーが直ったとすると、パラメータ[A]が原因だったの？それともパラメータ[C]が原因だったの？ と動作を見ながら判断できないですよね？

原因がわからなければ修正方針も考えられないので、最終的には

パラメータ[A]だけを動かして、動作確認をする

っていうことをするんです。 最初から1つだけうごかしてら、動作確認の回数減らせますよ。原因の特定もできるし。

最も効率的なトラブシュートは変数を１つしか動かさない

という、最も非効率そうなことが実は効率的なんですよね。 これやらないと原因わかっても修正方法わからなかったりしますから。

エンジニアになりたい人多かったりして、ITエンジニアとかいうと華やかなイメージあるのかもしれませんが、 正直エンジニアなんて ちょー地味 な作業ばっかりですからね。 なんたってIT技術なんて、ルーチンワークを機械に任せるのが目的ですからね。 ルーチンワークを消すためにはルーチンワークをするしルーチンワークを理解しないといけないですから。