常駐先で、ORACLEデータベースの管理やってます。ORACLE Platinum10g、データベーススペシャリスト保有してます。データベースの話をメインにしたいです

教えたり、教えてもらったり

»

 二十代の頃、上司にこんなことを言われたことがあります。
 
エンジニアは職人や。目で見て盗め


 眼で盗め1.jpg

 エンジニアが職人というのは同意できますが、
 仕事柄、目で見ただけでIT技術を盗むことは無理なのではないかと思いました。
 何より、この方法だと時間が掛かりすぎます。
 「目で見て盗め」までの突き放し方は無いまでにしても、ある程度の放置プレイな現場はありましたね。
 訊きに行くと、忙しいからと言う理由で後回しにされて忘れ去られることもありました。

このやり方でできるから

 と渡された手順書について質問すると、作った人がもういないから「何でこの操作をするか分からない」とか。
 手順書があるのはまだいい方で、

口伝でずっとやって来た。何でこうするかは引き継いでないし、文書も無い

 という文化を持つ現場、なんてのもありました。
 やっては失敗を繰り返すような、難易度の高い死にゲーのような仕事ぶりにびっくりしました。

 こうして、失敗して覚えての繰り返しで、時間がいくらあっても足りないし、残業ばかりの日々になります。
 業務効率化を目指して情報システムは作られるものなのですが、その作ってる現場がこれでは世の中矛盾しています。
 恐らく、上司としては実際に手を動かして、失敗することで覚えて行ってほしいという願いも込めて、そう言ったのでしょう......
 

 ですが、失敗なんて基本的にしない方がいいんです。
 ミスでお客さんのデータを消したとかあってはならないし、
 それが知識不足から来るなら最初から教えてあげれば良かったんです。
 だから、最初に理屈をしっかり教えて失敗しないようにしてあげるのが一番良いのです。
 例えば、

  ■データベースに接続する度に
   「select name from v$database;」
   を実行しているのは何故なのか?
   →接続先を間違えていないかの確認のためです。
 
  ■データベースを変更操作した後、毎回アラートlogを確認しているのは何故なのか?
   →今の操作が原因で、ORAエラーが出ていないかを確認するためです。

 上記のようなことは、失敗から学んでそれを防ぐために考えられた回避策なので、教科書には載っていません。
 こういった作業を「おまじない」と言ってしまうと、見ている側は必要性を感じなくなるので、今後やらない可能性があります。
 見せて分からせようとしたり、悟らせようとするよりも、ここは何故そうするのか、理由をしっかり教えましょう。

 そうしないと、いずれミスをしたり思うように仕事が出来なくて、自ら悟るときが来たとしても、それでは時間が掛かりすぎて、効率が悪いです。
 そして、悟ることも出来なければ、原因を環境のせいにしたりして最悪、仕事を辞めることだってあります。
 だから、教えて理解させることは大事なことなのです。

 それでもミスすることがあれば、それは仕方ないこととして教え方や学び方を変えればいいのだと思います。

 私も色々な人に、色々と教わりました。
 その中でも、こういった感じで理屈や理由を教えてもらったときはやっぱり腑に落ちました。
 そうやってお世話になった人は、ちょっと憧れの存在と言うか、目指すべき存在になりましたね。
 実際、障害や何か大変なことが起こった時は、

「あの人だったら、こうするかな?」

 とか、頭の中で、その人が取る行動をシュミレーションして、実際にやってみたりするようになりました。
 その部分に関しては、目で盗んだとも言えるし、しっかり教えてもらえたから考え方を継承出来た、だから同じように動けるようになったのかなとも思います。

Comment(0)

コメント

コメントを投稿する