4月も少し過ぎ、新しく入社したエンジニアたちは会社の事業内容や規則、業務フローの説明などもほどほどに具体的に現場で仕事をするための教育が始まっているかもしれません。
ここでは、プログラミングやHTMLの知識、ネットワークやサーバー周りの知識など所定のカリキュラムに沿って教育が実施されと思いますが、何れも十分な時間をとることができないため、広く浅くといった教育になりがちです。
また、一方でそのような教育を受けたとしても具体的に何を何処で使うのかがわからなかったりするため、次のステップとしてOJTなどでもう少し具体的な知識を身につけさせたり、実践に近いような形式で課題を与えてスキルアップさせたりする次の教育が始まったりもします。
ここで課題となるのがより実践に近いものを作らせるというものなのですが、そもそも具体的に何を作らせればいいのかと今度は教育をする側が悩むことにもなったりします。
理由は、インフラやサービスが整いすぎて新人レベルで作らせられるものが見つかりにくいというものです。
新人エンジニアの教育を取り巻く課題
何か新しい技術を教育したとしてもあくまでそれは机上のことであって、実際にそれを使ってみないことにはなかなかスキルというものは身につきにくかったりしますし、保守・運用の課題は実際にそれを保守・運用してみないと気が付かないことは多々あります。
要は、一定のスキルアップを図るためには実際にそれを作らせ、運用させ自分自身で体験し、自分自身で気が付かせるということが大事だったりします。
ただ、問題はその適当に作らせるものが見当たらないということです。
適当というのは、架空のサービスを作らせたとしても実際にそれを運用させるというのは難しかったりもしますし（作ったら終わりとなるので）、利用者が多いサービスの改修などをやらせてしまっては影響が大きかったりもして、その粒度が適当なものが見つかりにくいというものです。
例を挙げると以下のような点が理由にあります。
1. クラウドなどで安価な外部サービスをすぐに使うことができるのでわざわざ作る必要が無い
2. 知識としては必要だが、その技術を自社で保有していない
3. 失敗しても許される環境が無い
4. 業務フローやマニュアル外のことをやらせたくない
5. 技術がカプセル化しすぎていて具体的に中身を見せるのが難しい
6. システムのライフサイクルが長くなっている
7. そもそも時間が無い
もう少し具体的に書いていくと、1.に関しては車輪の再発明を避けるために今あって正しく動いているものをわざわざ新たに作る必要は無いという考え方です。
もちろん、教育の一環で作らせることは幾らでも可能なのですが、この場合はそれが本番としてサービスインできるようなものを新人自らに作らせるか、という点においてです。
一昔前なら、「これは自分が新人のときに作ったサービスだ」ってものが動いていたのかもしれませんが、今やよりよいサービスが低コスト・短納期で始められるのに悠長に作らせている時間は無いと思っている人も多いのかもしれません。
2.に関してはクラウドの流れと関連がある話ですが、以前に書いた「クラウド化によって捨て去られる技術 」のように捨てた技術というものもあったりして、ただエンジニアとして最低限その知識は持っておきたいものの具体的に触れることができる環境が手元に無いというものです。
ですので、参考書で読みました、ネットで調べて知識を得ましたというレベルまでしか教育ができなかったりします。
3.に関してはシステムの数が増え、また互いに密接に関わりあうような構成になっている関係で、一つのトラブルが他にも大きく波及してしまうので失敗が許されないというものです。
当たり前の話だったりもするのですが、それに加えてITサービスに対してユーザーの目が肥えていることもあり、何かトラブルが起きることのリスクを保守・運用側も恐れ、絶対に失敗させないような教育カリキュラムにすることで、踏み込んだ経験をさせることができなかったりもします。
実際には失敗でわかることやその経験が次に活かせることは大きかったりするので失敗することは悪いことではないんですけどね。
4.は3.の失敗できない環境に関連して、そのリスク回避として膨大なマニュアルが作られたり厳格な業務フローが定義されていたりすることです。
マニュアルどおりにすることを優先させ、その技術の本質に触れる機会が奪われたり、本番環境ならまだしも開発環境やソースにコミットをかけることすら申請が必要だといった厳格なフローが決められていたりしたらそのマニュアルやフローから外れるような知識は一切身につけることができなかったりもします。
5.は豊富なライブラリや仮想化技術の発展により、技術のコアに触れる機会がなくなっていたりしています。
開発効率を上げるために作り上げた独自のメソッドやAPIを通してデータアクセスや加工ができるとなると、その中で行われている処理の詳細がわからなくてもシステムを組み上げることができたり、物理的なサーバーがなくなることでハードウェアに触れる機会が無かったり、アプリケーションの仮想化によりミドルウェアが抽象化され何が動いているのかわからなかったり、簡単に環境がコピーできたりもします。
こういった知識はトラブルが起きたときに影響が大きかったりもして、この環境がないと対応できませんとか、GUIじゃないとやったことがありませんとか、API叩いているだけなんでデータ構造は知りませんとかなったりして何もできない状況に陥ったりもします。
6.は仮想化などの技術の発展、ベンダーによる保守の延長、クラウドを利用することによるオンプレミス型の運用からの開放など、システムのライフサイクルがずっと長くなることでリプレイス案件などが少なくなってきたりしています。
つまり、先輩が作ったものを後輩が作り変えるといった案件がなくなることで、経験の場が失われていったりもします。
7.は言うまでもなく新人教育に割く時間がそもそも無いというものです。
初期の教育期間が終われば即、現場に出されるというのも珍しくありませんし、そこで経験を積めばよいという考え方の管理職も多数いたりします。
しかし実際には、これまで書いてきたような理由により現場でもなかなか思った以上の経験を積むことができず、要するにその環境でしか仕事ができなかったり、マニュアルどおりの対応しかできないエンジニアが育ったりして何時までも教育に関する悩みは尽きない状況となります。
まとめ
何れにせよ、思い切った経験をさせるということは本人にとってかなりプラスになることです。
自分としてはかなり恵まれていた（？）のか、多くの失敗が経験できる環境で教育を受けました。
実際のところ教育というよりは放任され、自分たちで作れ何とかしろって感じだったので、自ら作ったもので失敗を重ね、改良を加えていくということを繰り返してわかったことが多かったように思えます。
今ではそのような堂々と失敗できる環境や全てをコントロールできるような環境というのはなかなか見つからず、ある意味新人エンジニアにとってはつまらないものとなっているかもしれません。
そのようなことを促進できるためにも、管理する立場がもう少し自由度を与え、何かあったら自分たちで責任とって復旧するぐらいの考えを持たないといけないのかもしれません。