問題が起きたときは、原因の特定が一番肝心です

2024年6月13日（木）

デバッグの特定速度と報告内容を見れば、エンジニアの能力を、ほぼ特定できます。そこに思考のプロセスが大きく反映されるからです。

心の声

一日リリース作業

朝から夜までリリース作業。様々な問題が起き、ひとつひとつを解決していきました。いくつが問題は残りましたが、とりあえず一旦完了となりました。明日に持ち越した問題もあるので、明日また頑張ります。

原因の特定が一番肝心

問題が起きたときは、原因の特定が一番肝心です。そしてそれが一番難しかったりします。問題が起きた瞬間は、複数の可能性があり、そのどれかが原因である、みたいな状況がほとんどです。そのなかからひとつひとつの可能性を消していき、最後は一つに特定するのです。どちらかが原因なんだけど原因が他システムに関連していて特定できない、みたいなこともよくあります。その場合は、ここを調べてください、と他システムの開発者に依頼を出し、回答をもって次の判断に進む感じになります。

何が問題かが分かれば解決は比較的簡単です。原因が明確に具体的に分かれば分かるほど、修正はシンプルで単純になると思います。

数学的思考とパズルを解く発想

原因特定が終われば半分以上（5～7割）完了したイメージです。原因特定の作業は数学の問題や、パズルを解いている感じで楽しい瞬間もあるのですが、一日中ずっとそれが続くとさすがに頭が疲れてしまって、クタクタになります。

経験と知識の積み上げで、問題特定が早くなり、正確性も上がっていきます。ただ、その価値が分かって貰えなかったりします。分かる人には分かるのようですが、「勘が良いね」みたいに思われてしまうことも多々あって、残念に思うこともしばしば。

全て理屈があったり、裏付けがあったりするんですが、その理由までは求められていないことも多いです。説明を聞かれなくても、プロですから、理屈と理由を説明できるレベルまで理解するのは当然必要です。