若手の保守技術者に一言言えることが有るとするなら、「トラブルの原因を覚えることには、意味がありそうであまり意味がない。」と言う事だ。
例えると、「ネットワーク不通」というトラブルがあったときに、LANケーブル断線が原因だった場合、そんなことを覚えても、LANケーブルが断線していたという１つのパターンしか解決できない。
覚えるべきは「そのトラブルが如何に解決されていったか」だ。
例えば、「ネットワーク不通」と言うトラブルについて、1.アプリケーションで気がつき、2.ＯＳの警告を確認し、3.ping、telnet等を用いてレイヤを確認し、4.別機器を用いて問題が発生している区間を確認し、5.区間内の媒体を確認する。といった当たり前かつ技術者なら無意識にやってる手順を記憶か記録すれば、それに当てはめるだけで、大多数のトラブルは解決できる。
1.あれ、インターネットつながんねえ。
2.LANカードの状態は・・・もんだいなさげだな。
3.サーバへPINGしてみるか・・・つながんねえ。
4.お隣さんは・・・おなじ状態か。隣の課はどうかな・・・つながってんじゃん。
5.んじゃフロアの親HUBと課のHUBの間の問題だな。おお、親HUBからのLANケーブル挿したところ、ランプついてねえ。LANケーブル交換してみるか。
問題の解決方法にはパターンがある。パターンを見出すためには記録するのが一番効率がいいだろう。しかし、原因はパターンではない。だから、原因を記憶することにあまり意味はないのだ。
これが、開発系技術者であれば、原因記録には意味がある。一人の技術者が発生させやすい問題はパターンであることが多い。たとえばバグそばの全く同じバグを見つけられない、グローバル変数を使いすぎて整合性がとれなくなる、イベントの発生をトリガとして、別イベントを発生させた際、別イベントをトリガとして発生する処理が最初のイベントと競合するなど。それを認識することでミスは減らせる。
