本日は、技術者・エンジニアを名乗る自分自身が、なぜ自己研鑽を続けなければならないか、という点についてご報告します。
システム部門に所属する社員は「技術者」とか「エンジニア」を標榜することになります。
私が新入社員時代、「技術者は生涯学ぶこと、生涯向上心を絶やさないこと。これでいいと思ってしまった時点で、終わり。」と日報に書かれたことがあります。
だから、日々励めよ、という意味合いで送られた言葉なのですが、世の中の新入社員や既存の社員の内、エンジニアを名乗る人がこうではない、というパターンも存在します。
生涯現役。
私が好きなアスリートはこういった看板を掲げて現役にこだわる選手が多いです。
先に出てきた「エンジニアは生涯学び、向上心を絶やさない」ということは、常に学ぶ姿勢や勉強し続ける一生を示唆しています。
ここでの勉強の定義は、学術的な知識を仕入れる勉強はもちろんのこと、新製品について独自に調査して購入検討したり実際に購入して使ってみたり、新しいサービスが誕生すればわざわざそれを使ってみたり、使い方が分からないユーザに成り替わり自らが使い方を調査したり、と、このようなITを中心とした学び全般を指しています。
なぜ、エンジニアは学び続ける必要があるのでしょうか？
システム管理者としては、その理由について気になるところだと思いますので、考えてみました。
システム管理者は障害との闘いが多いです。例えば、障害と勉強との関係性について考えてみます。
障害は待ってくれない。
障害が一旦発生すれば、もう待ったなしになってしまいます。使えるべき機能が使えなくなっているわけですから、その機能で業務を遂行しなければならないユーザの業務はこの時点でストップしています。
障害に対して「ちょっと待った！」して「障害は明日発生してくれ！」というコントロールが出来ればいいのですが、残念ながら障害は待ってくれません。
発生してしまえばすべての優先順位は引っ繰り返って、障害対処が優先されることが多いでしょう。
「勉強が終わるまで障害の発生は待ってくれ。」などと言っても、無情にも障害は人間の都合を無視して発生するものです。
その障害発生時にすぐ取り掛かれる、迅速に原因を特定できる、対処を有効に処理できる、そしてユーザの業務に影響を与えない、と、このような理想を実現するためには障害を対処するための下地となる知識や経験（体験）によって自身の経験値を常に向上させるような日常を過ごす必要があります。
障害が発生してから勉強して対処を一つ一つ実行し確かめていくのと、普段の勉強の成果として最短ルートで障害解決（一次対処）が完結できるのは、普段の勉強量の差が歴然と出ます。
障害はいつ起きるか分からない
これはマーフィーの法則的な考え方ですが、手を抜いたところほど障害が発生します。で、手を抜いたところはあまり勉強していないことが多いです。
いつ起きるか分からない、ということは明日起きるかもしれないし、1年後に起きるかもしれないし、そのシステムを廃棄するまで起きないかもしれない、ということです。
本当に使うかどうか分からない知識、これを勉強しておくためには「単純に障害のために勉強しておく」という打算的な考え方では学ぼうという意思の継続性に欠けます。
打算的な考え方だけでいえば発生するかどうかわからない障害に備えた知識を勉強するくらいなら、目の前にある事務処理や楽しそうなネットサーフィンのほうが自分の優先順位が上がってしまいいつまでたっても学びをスタートできないからです。
こうなると打算だけではなくて、「別の目的や意義を学びに見出す。」という点も必要になってきます。つまりいつ使うか分からない知識を自己研鑽で学び続けるためには使う局面だけの想定でなく「別の要素」が必要になるということです。
単純に興味があるから、ということでもいいですし、やってて楽しいから、ということでもいいですし、部内で第一人者となって尊敬されたいから、という主旨でもいいと思います。
結局、自己研鑽ができる人、というのは知識を使う局面以外の別の動機を持って勉強している人が多いように感じます。
で、いざ障害が発生し、幅広く学んでいる人は幅広い知識から該当する点をうまく組み合わせて障害のポイントをつかめるようになります。
先の解説と似ていますが、勉強時間を待ってくれない障害の対処は日頃からの勉強によって抗するしかないのです。
障害を対処するには知識が必要
障害対処、いわゆるトラブルシューティングの基本となるノウハウは、
「仮説を立て仮説を実証することで、阻害する要因を取り除くこと。」
です。
平たく言えばトライ＆エラーです。
この仮説を立てる段階で障害が発生している環境に対する知識が必要になります。
ネットワークのトラブルを解消するためにパケットの動きを知る必要があったり、
Windows（OS）のトラブル解消にはWindowsの動作の中身を知る必要があったり、
異常な動作が障害だとすれば、正常な動作を知っておかなければ、どこが異常なのかが分からない、という点もあれば、正常な中身についての知識がなければどう修正することで異常が取り除けるのか、という点も分からないことになります。
前出のトライ＆エラーの回数を減らすために、不要なトライを減らし必要なトライに集中することで、エラーの総数を減らす、ということです。
正しい知識は確実にこのトライ＆エラーの効率を上げます。
こうしてエンジニアは様々な知識を要求される
障害一つとってもこれだけの勉強する理由があるので、その他の業務も加えたら
「勉強する理由だらけ」
になってしまうかもしれません。
当然人間ですから、プライベートの時間も必要ですし、ゲームや娯楽で息抜きする時間も必要です。
ですが、プライベートから勉強しているのが当たり前に要求される、という点は他の職業に比べてハードルが高いように思います。
非エンジニアがエンジニアに技術の話を振って、知らない？というリアクションになると、なんとなく「勉強不足なエンジニア」という空気がその場に蔓延するような気になるのは私だけでしょうか？
非エンジニアはエンジニアに技術の話を向けたときに、何かしらの答えを期待していることが多く、その答えは普段からの勉強によって得た知識が役に立つ、という会話が多いように感じているのです。
最終的に「勉強したくない」というエンジニアって？
実際には「います。」
現実社会に存在はしていますけど、勉強したくない/勉強することを止めた、時点でエンジニアとしては深みがない状態にハマっていきます。
言うならばエンジニアは自分の知識や技術（腕前）が商品と言えます。
で、時の流れとともにこの知識や技術がが陳腐化してしまうタイミングが絶対にやってきます。
陳腐化する状態というのが、自身が有する商品の鮮度が落ちて価値が失われていく、という状態です。鮮度の落ちた商品を購買者は見向きもしないのと同様、陳腐化した技術しかないエンジニアに仕事を任せようと思う非エンジニアはいないと考えていいわけです。
よって、エンジニアとしては通用しなくなってしまい、エンジニア以外の仕事にシフトしていかざるを得ません。シフトできればいいのですが、この仕事をシフトさせることができなくなっている方も世の中にはいらっしゃいまして、こうなると互いに不幸なことになってしまうことが予想されます。
こう考えると、エンジニアがプライベートでも研鑽が必要になる理由は、
「エンジニアがエンジニアとして存在するため」
という言い方が最もしっくりくるのではないでしょうか？
もし、システム部門の部下（若手？）が不幸にも怠惰でまったく勉強しないタイプだとしたら、
「お互い不幸にならないために、勉強することの必要性と目標設定/意識付け」
を貴方の力で助けてあげると、自分に思わぬリターンが返ってくるかもしれません。
