後輩育成が難しい

こんにちは。

大学を卒業して社会人になってから、いつの間にか長い時間が経ってしまいました。

会社に後輩ができて色々と世話をする機会が増えていますが、最近後輩育成って本当に難しいと感じます。

IT業界の謎

何故かIT業界って未経験の人が毎年大量に入ってきますけど、プログラミングとかシステム設計って未経験の人が少し勉強したくらいでは到底マスターできるものではありません。

なので新卒の中でも大学でソフトウェア工学とかをしっかり学んできた人と完全に未経験の人で圧倒的な差が最初からあるわけなんですが、未経験の人をそれなりに育てるのが本当に難しい。

何で未経験の人がIT業界に入ろうと思うんですかね？

企業側も何で未経験の人にITやらせようと思うんですかね？

よくネットの広告で「1週間でプログラミングをマスター！」とか見ますけど、普通に考えて1週間でマスターできるわけないですから。

基本構文が書けるようになればマスターしたことになるんですかね？

未経験者の人にこれだけは言いたいんですけど、そんなにプログラミングは簡単じゃないっていうのをしっかり理解した上でIT業界に入ってください。

育成活動

後輩の教育を任されたわけではないので、そこまで本気で育成に取り掛かったわけではありませんが後輩を育成をするためにやったことを書きます。

勉強会

ありがちですが、勉強会を開催していました。

私と後輩が学んだことを互いに説明や質問をしあって理解度を高める方式を取りました。

また、先輩エンジニアにも参加してもらって、先輩に誤りの指摘や関連する知識の伝授をお願いしています。

最初は毎週やるつもりでしたが後輩が「毎週はちょっと厳しいです」と言ってきたので2週に一度にしました。

それでも後輩が「すみません、まだ終わってません」とか「今ちょっと忙しくて。。。」などと言い始め、徐々に頻度が低下して月に1回やるかやらないかという感じになってしまいました。

勉強会は後輩の育成も目的でしたが、自分のスキルアップも目的だったため途中から後輩をメンバーから外して今では私と先輩エンジニアだけで勉強会を継続しています。

各工程の最初に概要を説明する

弊社ではなんちゃってウォーターフォール形式でソフトウェア開発が進められますが、各工程ごとに何を作るべきか、どう作るべきかを簡単に説明した上で作業に当たらせました。

言ってしまえば当たり前のことですが、重要なことだと思います。

もちろん、概要説明だけで全てを伝えるのは不可能なので不明点はその都度質問して貰うようにしました。

質問は基本的に拒否らない

先ほどのと被ってしまいますが、質問されたら回りくどいことをせずに答えをまず言うようにしています。

また、できるだけ意味不明な質問も理解しようと心がけています。

正直何言ってるかさっぱりわからないことも多いし、「ググれ」とか「ドキュメント読め」で終わらせたいときが多いんですがわかる範囲ではある程度答えています。

自分が質問の答えを持ち合わせていないときは検索ワードを教えたり、ドキュメントがどこに置いてあるのかを伝えたりするようにしています。

※あまりにも簡単な質問や過去に何度も受けた質問などは嫌な顔が滲み出ちゃってたと思います

こうしてみて見ると大したことやってない。

でも教育係じゃないからこんなものかと思います。

後輩は成長したのか

後輩と一緒に仕事をし始めて早いことで2年以上が経ちましたが、結果を先に言ってしまうと3年目の社会人エンジニアとして外に出せるレベルまで育てることはできませんでした。

そう判断した事例をいくつか。

switch文の中にswitch文を入れる

私が作った検証用コードを後輩に渡して機能追加をお願いしたんですが、後日出てきたソースコードには信じられないコードが混じっていました。

そうです、switch文の中のswitch文です。

少なくともネストはあまり深くしないように、メソッドは長くなり過ぎないように今まで折を見て説明してきたつもりでしたがどうやら彼の心には届いていなかったようです。

switch文のなかにswitch文を入れるときにちょっとは違和感とか罪悪感を抱いて欲しかった。

caseを増やすとかで対応できなかったのか。

雑にもほどがある。

テストの確認項目で「コストラクタが生成されること」

テストの設計をやらせたんですが、コンストラクタのテスト項目で「コンストラクタが生成されることを確認する」という記述がありました。

たぶんインスタンスのことを言いたいのかな？って思ったんですが、ぐっとこらえて「これはつまりどういうこと？」って聞いてみたら「コンストラクタが生成されてreturnされることです！」と訂正してきたので絶望しました。

「コンストラクタってなに？」って聞いたら「クラスのことです！」と言ってきたので絶望は深まるばかりです。

そう、彼は2年以上Javaの開発をしてきているのにクラスもインスタンスもコンストラクタも理解していなかったのです。

ユニットテストは手動でやった方がいいですか？自動でやった方がいいですか？

この質問が飛んできたときはちょっとびっくりしました。

手動でテストするっていう発想は一体どこから出てきたんでしょうか。

私はもちろん、たぶん世の中のどこを見渡しても手動を推奨する人はいないはずです。

この2択が出てきたことも驚きですが、しかもどちらを選ぶか悩んでいたことも驚きです。

悩む要素がどこにあるのでしょう。

私の後輩に手動テストの選択肢を吹き込んだ輩を見つけたらぶっ飛ばしたい。

引継ぎ

後輩が期限内に終わらせることができなかった業務を引き継いだことがありますが、引継ぎ資料が30行にも満たないテキストファイルだけでした。

ユニットテストの引継ぎだったんですが消化した項目も、未消化の項目も何も一覧にせず「XX機能はまだできていません」くらいの内容。

試験の設計基準もわからないし、全体の規模や未消化項目の規模も不明。

さすがに資料の作成をお願いしました。

勉強会に来なくなる

前述したように後輩と勉強会をやっていました。

スケジュールも後輩に合わせてかなり頻度を抑えめにしましたが、最終的に後輩はスッと消えてしまいました。

参加していた時期も正直準備不足や理解不足が目立っていたので最初からやる気はなかったのかもしれません。

おかしいね、誘ったときは「やりたいです」って言ってた気がするのにな。

勉強会のテーマも後輩君のやりたいことをやったはずなのに。

やりたくない人に無理にやらせるつもりはないので、今では私と先輩エンジニアだけで勉強会を開いています。

先輩エンジニアにはあまりメリットがない集まりですが、嫌な顔をせずに付き合ってくれる先輩エンジニアには感謝してもしきれません。

環境要因もある

以前までは(一応)IT企業に勤めていましたが、今は非IT企業に転職してその中でITの仕事をしています。

私を悩ませている後輩は、その会社に新卒で数年前に入ってきた方です。

その後輩も同じ部署で働いているのでIT系の仕事をしているんですけど、会社が非IT企業なので当然研修などもなく、周りにIT人材も少ないので目指すべき人が見つからないとか、質問できる対象が少ないとか、そもそも開発の仕事が少ないとか、ソフトウェア開発のノウハウが蓄積されていないとか、色々な環境要因もあります。

周りにかっこいいエンジニア、尊敬できないエンジニアがいない環境ではモチベーションを保つのは難しいのかもしれません。

また、事業としてもソフトウェア開発がメインではないので開発のチャンスが少ないのも問題かもしれません。