システム開発のテストは、障害（バグ）をつぶす作業とも言えます。
しかし、システムが納品（リリース）され、運用が始まったあとも障害（バグ）は発生することがあります。
障害（バグ）には、２つの原因が存在します。
それは、「直接原因」と「根本原因」です。
この２つの原因は、因果関係にあります。
根本的なミス（根本原因）によって表面化された（直接原因）不具合が障害（バグ）となるのです。
通常、障害が発生すると、直接的に障害が引き起こされた「直接原因」を究明することに力が注がれることが多いです。
しかし、「根本原因」を知り、分析することで、多くの直接原因を減らすことができるのです。
今回は、この２つの原因の違いを理解し、品質を高めるための思考を学んでください。
障害（バグ）の直接原因とは？
直接原因とは、障害（バグ）が発生した直接的な原因となるものです。
例えば、if文の判断文の誤りや、計算式の演算子や数値の誤りなどがそれにあたります。
設計では、「ある数値が0の場合に、A処理を行う」としていたが、実際には、0以外の場合に、A処理を行う作りになっていた。
この場合の障害（バグ）は、A処理を行う判断文が誤っていたために、A処理を行うはずが、処理されなかったということになります。
つまり、A処理を行う条件が誤っていたことが「直接原因」となります。
ですので、この条件文を正しく修正し、0の場合に、A処理を行うことを確認することで問題が解消されたことになります。
しかし、ここで考えてみてください。
この判断文誤りによって障害（バグ）が発生したということを受け、他の判断文は大丈夫なのか？って思いませんか？
この思考により、いわゆる類似調査のように同じような判断箇所の妥当性を調査してみるという視点をもつことができます。
この思考がないと、場当たり的に、障害が出ては対処して、また、出ては対処してを繰り返すことになります。
全く別な原因の障害であれば、まだ良いですが、同じように判断文の誤りが原因だった場合、いい加減、全部修正箇所を確認した方がよいとなります。
ただでさえ、障害対応は疲れますから、作業効率を上げたいところです。
作業を効率化してよい場合とだめな場合を見極める簡単な考え方でも書いていますが、明らかに、効率化することで、同じような判断文の誤りを事前に調査し修正しておくことで、障害を出す前に、問題を解消することもできるのです。
ですから、この思考は、とても大事です。
確かに面倒な調査であるため、できればやりたくないです。しかし、後々大問題に発展させないためにも、事前に苦労することは品質を上げるためにも重要なことです。
ですが、そもそも、なぜ、判断文誤りが発生してしまったのでしょうか？
その原因が「根本原因」になるのです。
そもそもの原因「根本原因」とは？
判断文が誤っていたために、想定しない動作を起こした。
という場合、判断文の誤りが直接原因でした。
では、そもそも、なぜ、判断文を間違えてしまったのでしょうか？
この、そもそもの原因が「根本原因」なのです。
設計書には、「Aが0の場合」と書いてあるにも関わらず、ソースには、if(A!=0)と書いてしまっていたのです。
考えられることは、
- 設計書には文章だけで条件文が記載されていたため、分かりづらく、間違った解釈をしてしまった
- ケアレスミス、うっかり思い込みで作ってしまった
などでしょうか。他にも様々あると思いますが、集約すると、解釈を誤った、うっかり思い込んだといったところに大体が落ち着きます。
とすると、うっかりミスをなくすためにはどうすればよいのかを考えるのです。
例えば、判断文だけをまとめたチェックリストを作成し、コーディングしたあとに、そのチェックリストで判断文が一致しているかをチェックするようにするとか、設計書自体の書き方を誤解釈しないように文章だけではなく、表組にするとかなど、対策が見えてきます。
これらを用意し、チェックしていくことで、同様の障害（バグ）を未然に防ぐことができるようになります。これが、「再発防止策」です。
これをすることで、次の実装に活かすことができます。結果として、同じような障害（バグ）を減らすことにもつながるのです。
このように、根本原因を知ることは、自分の性格や癖など、特性を考慮した対策を考えることにもつながります。そして、この対策を次回からの実装に活かすことで、スキルを高められ、品質の高いシステムをユーザーに提供できるようになるのです。
直接原因の対策だけでは、同じ失敗を繰り返す可能性が高いです。ですが、根本原因を対策することで、効率よく、品質の高いシステムを作り上げていくことが可能になります。
２つの原因を知り、次のシステム開発に活かすことを考えていくように心がけてください。但し、対策を立てても、机上の空論だけでは論外ですので、ご注意を。
カテゴリ：問題管理
