*** 1．概論

同じ業種で長くやってると所属内外とわず、教育というものをやらなければいけないことがある。
そのたびにいろいろ考えることは数多くあるのだけれど、肝心なのはこの世に普遍的なものなどないということを教える側が意識しておくことが必要なのだと思う。

というのも、現在ベストプラクティスとされているものは、現在の最適解であるというなのだから、あるタイミングでブレイクスルーが起きたときにその常識がいとも簡単に崩れ去っていくものであるから。

この意識を持たずに教育に携わった場合、【教育とは洗脳である】という言葉の通りになってしまうリスクがある。
既存の知識を真実として教えるスタイルの教育はまさに洗脳であるともいえるし、基本的にそのような教育から発展的な何かが生まれる可能性は低い。
例外は数多く存在するが、それは教育方法というよりは対象の個性に由来するものであると考える。

もちろん、ある種の固定化された知識というのも存在するのでそれらについては上述の教育方法が適していると考えるが
IT業界という業界の性質上、常に新しい何かに触れることが多い業界であるがゆえに上述のような教育だけでは適さないのではないかと思うのだ。

我々が教育に携わる場合、短期的なその案件にフォーカスした教育と中長期的に業界を支えていく人材を育てるという大きく分けて二種類の目的が発生する。

多くの場合、時間などの問題から前者だけになりがちだ。
しかし、可能であれば後者の考え方で所属内外問わず向き合いたいと思っている。

これは個人の矜持でしかないのだけれど。

*** 2．社内研修の実情

いままで、見てきた各社の新人教育というもので、まともに成果が出ているものに出会ったことがない。
これはあくまでも個人の観測範囲でのことなのでもしかしたらうまくいっている企業もあるのかもしれないが絶対数は少ないのだろう。

多くのSES企業の場合、入社後に参画案件が決定するまでの間に社内研修という名目で研修を行うことが多い。
※場合によっては、参画案件が決定してから入社という企業もあるのだけれど、それはまたいろいろ別の問題をはらんでいるので、いったんはここでは割愛。

このケースで問題となるケースとしては、社内常駐のエンジニアがおらず営業もしくは管理職が研修の監修を行うことによる現場とのズレがある。

例として、【研修用資料が作成されてから、アップデートが行われず古い知識のまま研修が進む】ことや、【研修という名目であるにも関わらず、基本的には資料をわたされて基本放置】となってしまうことが多い。
また、真の意味での新人の場合、開発/インフラ/運用というカテゴライズすら決まってないまま研修が進むことによって、【JAVAの研修をしてたのに参画先がサーバ構築案件だった】などの問題も起きやすい。

そして、入場時期を優先する考え方から研修カリキュラムが終了する前に、現場参画になるケースもある。

*** 3．OJTの実情

現場参画後には、所属の先輩社員とのセットで入場する場合が一番幸運なケースだろうか?
その場合ではOJT的な教育が受けられる可能性が高い。

けれどこれもその"先輩"次第になるので、教育に対して安定的なクオリティを担保するのは難しい。
多くの場合、その"先輩"は教育しようがしなかろうが仕事が減ることはないし。
そして、その後輩の分のタスクもこなさなければいけないことが想定される。

なによりも、その先輩社員が教育にたいしてモチベーションがあるとは限らないのである。
というのも、その先輩社員もまた同様の教育を受けてきた人である場合が多く、本質的な理解に乏しい場合やその人個人の特性として技術力が高くなっている場合も多いので、
体系だった勉強方法をしてきたわけではないケースが多いため、再現性の低いナレッジの集合になってしまうのだ。

不運なケースとしては、単品で案件に入場するケースだろう。
もちろん現場の他社の社員などから教育的なものを受けることにはなるが多くの場合は、前述の【短期的なその案件にフォーカスした教育】となるため、中長期的なスキルの継承を得られる可能性は低い。

どちらの場合においても、新人のコミュニケーションスキル次第では、得られる効果に大きな差が発生する。

*** 4. 現状の三年目

3年目くらいになると、主として一つのタスクを任される中堅エンジニアとして扱われることが多い。
エンジニアとしての岐路に立たされるのも大体このぐらいの時期から始まる。
自分自身で【向いてないんじゃないか】と考え始めたり、まわりから【向いてないよ】のような発言を受けるのはやはり3年目くらいからであろう。
そこから苦悩し、うつによる休職や他業界への転職などの結論に至るケースも多い。

はたして、【2．社内研修の実情】【3．OJTの実情】で語ってきたような教育を受けてきた人間に一定のスキルが備わっていると思うだろうか?
もちろん、個人の適正の話として本当に向いていない人もいる。

しかし、今の日本のSIer系の働き方であれば、ある種エンジニアとしての特性などなくても、ある一定の品質を担保する職業人を育てることは可能なはずだ。
ISO9001の中には作業標準化及びその管理体制も含まれているので、システムというのが工業製品であると考えるのであれば可能であるといわなければならない。

もちろん、上級システムエンジニアやアーキテクトのような業務をこなせるレベルになるかというのは別の話ではあるのだけれど、新人～中堅(特定のタスクの主担当)くらいは問題なく遂行できるレベルにはできるのではないか?
そのレベルにまで3年目の時点で到達していれば、おそらく35歳くらいまでは何とか働き続けることが可能だろう。

うつ病による離職や求職の危険性も大幅に下がるだろう。
もちろんそこから先の生存戦略については別途考える必要は出てくるのだけれど、それはこの文書の主題ではないので別のタイミングで考える。

*** 5. この問題に対するアプローチ

これまで記述してきた問題についてのアプローチを考えてみる。

【社内研修】
もうこれは研修用資料を定期的に最新化することと、営業開始時期の見極めというのが重要なのだろうと思う。

そして、もちろん付きっ切りで研修を行うのは現実的ではない企業も多いとは思うのだけれど、可能な限り毎日開始終了時には、質疑応答の時間を必ず設ける。
もしくはチャットツールなどで随時質問をエンジニア職の人間に投げられる環境をつくる。
これは必須でやるべきことなのだろう。

営業開始時期についても、各社の都合によりけりになるとは思うのだけれど、リードタイムをある程度設ける必要性はある。
そのリードタイム中に必須である研修は終わらせることになるので、どこまでを必須とするかを新調に判断したうえで現実的なリードタイムを設定するべきだ。
そして、そのリードタイム中に営業職との人間関係を構築していくことも考えつつコミュニケーションをとることも視野に入れて行う必要性がある。

内容としては、どうしてもその企業が強いものを研修でやりたくなるのだけれど、配属先が明確でない場合は必須期間中に、広く浅く全体についての研修を意識しておく必要があるだろう。

開発エンジニアだとしても、各OSの基礎的な研修やTCP/IPの基礎レベルは必須になるだろうし、インフラエンジニアだとしても、各言語の特性や動作の概論は必須になるだろう。
このようにどこに配属されたとしても必須になる基礎知識というものを必須研修に含めるべきなのだと考える。

同様に研修に盛り込んだほうがいいと考えるものとして、【ウォーターフォール開発工程/V字モデル】があげられる。
これを研修で教えておくことによって、各工程の意味やWBSなどの存在意義を把握することができるので、現場参画後の不安感が軽減されるだろう。

必須ではないが可能であれば行ったほうがいい研修内容は各企業の特性に応じて考えることになるけれど、研修の間に課題を与え期限を切って実際にそれをクリアするという作業を実施すべきだ。
この時の課題はちょっと新人には難しいくらいがちょうどいい。

その研修の目的は課題をクリアすること自体ではなくどうそれを解決していくかにある。
例えばGoogleなどで調べるという手段であればどうすればその目的の情報にたどり着けるかを学べるし、質問をするならそのやり取りの中で質問の仕方を学べるだろう。
また、機嫌を伸ばしてほしいと言い出してきた場合には、それに乗じてQCDの意味を教えることもできるだろう。

失敗してもいいが、そこから技術的スキル以外の何か学び取れるものを必須ではない研修に含めるべきだと考える。

具体的な技術スキルの習得に向けた研修は参画案件が決まってから、もしくは配属先部署が決まってからでも遅くはない。
どーせ研修中にコードの研修やったところで、実務になったらそれが使いこなせるかは別の話なんだし。

何よりもコード"だけ"書けるようになったところで、即戦力になるわけがないのだから。

【OJT】
OJTに関していうなれば、一人案件に配属しないこと。もしくは信頼できる企業に配属すること。
これが必須であるといえるし、セットで配属する先輩社員の性質も理解しておく必要がある。

たまに新人キラーのような社員や企業がいるので、そこは避けてアサインすることが大前提となる。
また、先輩社員についてもある程度の見返りは用意したほうがいい。(見返りの内容は人によって好みが分かれるが、会社として一定の取り決めをしておくほうがいいだろう。)

参画した案件によって内容が変わってしますので具体的な指標を出すというのは難しいけれど、OJT中に目標とすべきは、【失敗体験】から何を学ぶかと【成功体験】から何を得るかではないかと考える。
失敗体験を積み重ねて教訓とし失敗するリスクが低いやり方を学ぶことは大事だし、成功体験をもとにモチベーションを維持向上させていくこともまた大事だから。

成功体験をもとに上がったモチベーションで個人学習に乗り出していくようになれば、OJTは成功といえるのではないだろうか。

*** 6. クロージング
本文章はあくまでも個人の経験をもとにした感想と個人の考えです。
ご意見等あればメッセージでも頂ければなぁと。

答えのない課題なので。