今日は4月1日ということで新年度を迎える企業が多い日。
新人の方が入社する事も多いこの時期たまたま下記の記事を見つけたのですが、ここで書かれてる特徴というのはコレをやってしまう社員に問題がありますね。
ホワイト企業でもこれに近い方は見受けられるので、こういう方々は反面教師と捉えて必要最低限の関係性にしておくのが処世術というものです。
これで早期退職されても企業としては困ったものなので、管理職がキャッチアップできるよう工夫して手を打つべきですね。
さて今回は新人エンジニアの育成について書きます。
入社前に基本情報技術者試験に合格してる程度の知識を持ってることが前提になりますが、始めから設計工程から裁量を持ってやらせてみるのがいいんじゃないでしょうか。
ありがちなのがテストからやらせてみるケース。
私がそうでしたが、来る日も来る日もテストばっかりやるのはツライので、機能単位で内部設計とプログラミングをセットでやらせてみるのがいいと思うんですよね。
よく設計とプログラミングで担当を分ける場合があるのですが、システムはどうしても設計と開発の工程をいききしながら作るので、プログラミングと設計は同じ人間がやるのがいいと思います。
ただ丸投げはダメゼッタイなので、進めるにあたって困った事は全力でフォローすべきだし、成果物のレビューはしっかりやりましょう。
話を聞く際、体はPCを向けて耳だけで聞くのではなく、体ごと向けて話を聞くのが人としての礼儀なのでお忘れなきよう・・(忙しいとついやりがちです)
レビューの頻度ははじめは日次でやって認識齟齬がなく、アウトプットがだせるようになったら、3日に1回とか1週間に1回とか間隔をあけていけばいいんじゃないでしょうか。
あとレビューで注意すべきなのは「ダメだと思うんだよね」とか感覚で伝えるのではなくで、言語化してフィードバックする事とフィードバックの内容は会議の議事録のようにデータで残しておくこと。
これをやっとけばレビューする側が変わってもフィードバックの粒度が異なる事を防げますし、人材育成するにあたっての資産になりますからね。
というのが私なりの育成方法なんですが、設計からお願いして上手くフィットする方もいれば、しない方もいます。
1年くらいやってみて、それでもパフォーマンスが上がらない場合はエンジニアという職種自体がその方に向いてない可能性もあるので、その方の特性を活かせる職種に異動する事を視野にいれたほうがいいんじゃないでしょうか。
冷たいようだけどそうしないと労使ともにハッピーになれませんからね。
