こんにちは。オリエンタルインフォーメーションサービス、エンジニアの原と申します。
4月に入り、弊社にも新卒が入社しました。現在は新人研修を行っていますが、多くの会社でも現在、新人研修の最中ではないかと推察します。
というのも、私はエンジニアである一方、弊社の「インターンプログラム」や「新人研修カリキュラム」作成にも携わっているからです。
そしてこの「新人研修」ですが、個人的には結構重要な事だと考えます。若手が大きく伸びなければ、結局自分たちが苦しいだけであり、会社の未来はありません。
この認識は多くのベテラン勢が持っていると思いますが、さりとて新人の教育に多大な時間を費やすほどのリソースはありません。
「どうしたら新人を早く一人前にすることができるか？」
は、新卒採用を行っている会社にとっての大きな課題の一つでしょう。
そこで今回は「若手の育成」について、私がこれまでに得ている知見を書いてみたいと思います。
＊＊＊＊＊＊
私は弊社に新卒入社したのではなく、十数年前にパナソニック系のシステム会社からこの会社に転職してきました。
ですので、新卒の際の研修はパナソニックの社内の「人材育成センター」という学校のような場所で受けました。そこでは、グループ会社も含めて新人はセンターに集められ、2ヶ月から3ヶ月、研修を受けることになります。
研修の質は高く、新人は現場に無理なく溶け込める訓練ができる上、職種に関係なく横の繋がりもできるということもあり、私は非常に良い印象を持っていました。
そういったこともあり、転職の際、私は弊社の採用担当に
「若手の育成の仕組みはどうなっているのですか？」
と何気なく聞いてみたところ、ちょうど課題を抱えており、
「原さんに若手の研修プログラムを創ってほしい」と白羽の矢が立った、という次第です。
ですから、現在の弊社の新人研修プログラムは、パナソニックでの経験を元に、それを弊社の実態に合わせて再構築したものとなっています。
では、その「新人研修」の中身です。
新人研修の期間は２，３ヶ月です。それほど多くのことを身につけさせることはできません。
かと言って、必要最低限のことを満たしていなければ、現場に迷惑がかかります。
本質的には仕事は現場で憶えるものではありますが、うまく新人が現場に溶け込むために必要なことは網羅していなければなりません。
そこで決めたのが、「新人研修で教えるべき、3つのこと」です。
その3つとは、
1.業務遂行に必要な最低限の知識
2.業務の練習
3.報告・連絡・相談の作法
です。
これらが新人研修中に身につけば、ひとまず研修の成果があがった、と見てよいのではないかと思います。
まず1.です。
弊社はシステムエンジニアリングの会社ですので、プログラミング言語の知識は必須です。幸い、世の中にはたくさんの良いテキストが市販されてますので、そのテキストを元に知識を入れていきます。
ですが、テキストを独学するだけであれば、何も新人研修でプログラミングをわざわざやる必要はないでしょう。
我々がプログラミング研修の中で重視しているのは「ソフトウェアを作るときの答えは一つではない」と知ってもらうことです。
例えば
「◯◯というデータを元に、◯◯というアウトプットを吐き出すソフトウェアを作れ」
という課題があります。
その課題に対して、学生の間や独学であれば、「一つ」それが実現できるプログラムをつくることができれば、問題はないとみなされるでしょう。
しかし、我々はプロなのですから、「プログラムが動く」のは当然です。新人に学んでほしいのは、「動けばよい」という感覚ではありません。
では何を学んでほしいか、といえば、
「ソフトウェアの実現の方法はたくさんあり、複数のやり方を検討した上で、最善の方法で実現する」という手続きです。
例えば、先ほどの
「◯◯というデータを元に、◯◯というアウトプットを吐き出すソフトウェアを作れ」
という課題にたいして、その実現の方法をどのくらい数多く考えることができるかが、しばしばプロの仕事には問われます。
◯メンテナンス性が高いのはどの方法か？
◯仕様変更に強いのはどの方法か？
◯処理とデータをどのように分けたら動作が早いか？
そういった実務的な知識を、この研修を通じて身に付けてもらいます。
つぎに、2.の「業務の練習」です。
業務は1.で身に付けた知識をもとに行われますが、だれしも最初からうまく仕事ができるわけではありません。おそらく試行錯誤と失敗を繰り返しながら、スキル向上を実現するのではないでしょうか。
しかし、もちろん現場では大きな失敗はできません。お客様に迷惑がかかるからです。
「失敗を奨励する」ことは会社の文化としては重要ですが、お客様から大きなクレームをいただけば、現実として一つの失敗で、新人が自信を失ってしまうことも多々あります。
だからこそ、研修中は大いに失敗すべきです。
手を動かして、まずは課題に取り組んで見る。そしてうまくいかないという体験をする。ときには課題が難しく、行き詰まる時もあります。そんなときにどうするか、先輩への聞き方や、どの程度まで自分で調べてから聞けばよいのか、そういったことも学んでもらうことが大切なのではと思います。
リクルートなどの営業会社ではよく「営業ロールプレイ」をやると聞きます。
ロールプレイは上司がお客様役、若手が営業役で、現場をシミュレートし、緊張感を持った練習をすることができます。
同じように、弊社においても「仮想プロジェクト」を作り、いわば「開発ロールプレイ」を行っていると考えても良いと思います。
ロールプレイであれば、どんどん失敗もできますし、いざという時の対処法も学べます。
最後に3.の、報告・連絡・相談の作法です。
いわゆる「報連相」ですが、弊社の研修における報連相は、通常とは少し異なる意味を含んでいます。
一般的に、「報連相」は、上司と部下のコミュニケーションを細大漏らさず実施しなさい、という文脈で使われます。
たしかにそれは正しいと思います。しかし、システムエンジニアリングの会社にとって、報連相はもう少し深い意味を持ちます。
それは、「エンジニアは、自分の作ったソフトウェアのコードの1行1行を、確実に説明できなければならない」という考え方です。
つまり、「何故このようなコードを書いたのか」をきちんと説明できることを、報連相は含みます。
エンジニアの中では当たり前なのですが、実は、ソフトウェアの技術者として最もまずい状態が、「自分が作ったものの意味を理解していない」ことです。
経験を積んで、様々な会社のエンジニアの方とお会いすると、中には「なぜこのようなやり方をしているのですか？」と聞くと、「なんとなくです」という答えしかできないエンジニアがいます。
これでは技術力が伸びないばかりか、トラブルになったときに原因がわからず、お手上げになってしまう可能性が高いといえるでしょう。
もちろん自分の行った仕事に対して逐一「これはこうなっている」と説明を与えることは大変な手間と労力がかかります。
動きそうなコードをコピー＆ペーストして適当に納品したほうが、楽なのは間違いありません。
しかし、それではエンジニアの成長は望めません。
その考え方を新人の時から徹底的に体得しなければ、困るのは彼らなのです。
私もかつて、あるプログラムを作って先輩に見てもらった時、「なぜこのように書いたのか？」と聞かれ、「参考としたコードに書いてあったから」と答えたところ、メチャクチャ怒られた記憶があります。
それ以来、「自分書いたものだから、100％自分が責任を持って、品質を担保しなければならない」と、考えるようになりました。
質の低いエンジニアはこうしたポリシーを持っていませんし、同じアウトプットを出すのに、何故か違う処理を書いたり、複雑過ぎる処理を書いたりします。
説明を求められても、「なんとなく」「このほうがいいとおもったので」と言った答えしか帰ってきません。
そう言ったエンジニアに成ることを防ぐため、われわれは新人の研修のときから、厳しく「報連相」のなかで、そういったことを求めていくのです。
【お知らせ】Books&Appsでは、企業の広報活動を支援するサービスを行っています。ご興味のある方はこちらからご連絡ください。
