コーチングの話。

ここ半年程、3年目の社員から色々と質問されては答えるというのをほとんど毎勤務帯行っている。

質問の内容は、保守対応に関する技術的(?)な質問。例えばハードウェアの状態を確認するためにはどういうコマンドを打ったら良いかとか、このコマンドはどういう意味かとか。あとは、もっと情報工学寄りな、RAID 冗長の仕組みとか、仕組みを踏まえた上でディスクがどれくらい壊れても完全性が確保できるかとか。最近の製品、例えばストレージひとつとっても、単純な RAID5 などの構成ではなく、もうちょっとこねくり回した製品が出てきたりしていて説明するのが面倒なのだけれど、運用で使う情報理論は、大体は中学生くらいまでの数学と、国語(できれば英語)が分かれば乗り切れる。

では、簡単な数学と国語が分かれば乗り切れる程度の知識をいくらか教えたところで、その本人に何の糧になるかという問題がある。製品は移り変わりが激しいので、そこで使っている技術についてイチイチ覚えていても、何年かすればどうでも良くなってしまう。何より、そういった知識というのは動機があってこそ役に立つ。

例えば、ストレージのディスクがが複数台壊れ始めたら、「あと何台壊れても完全性が確保できるのか?」という疑問が湧く。それを把握するためには RAID 等の設定を確認するコマンドを把握する必要がある。またその結果から判断するためには RAID の仕組みをを理解しておく必要がある。ということで、動機を持たせないといけない。

それならば、知識を与えるよりも動機を持たせる方が良いのではないか。もっと言えば、「自分は何が分かっていて、動機を解決するためのは何を知る必要があるのかを切り分ける力」を受けつければ、あとは、google で勝手に調べるかもしれない。

しかしながら、もしかしたら知識がなければそもそも疑問とか動機も生まれないのかもしれない。という卵と鶏の問題が常につきまとっている。