新人エンジニアってどうやって育てればいいの？ 教えなきゃいけないことはいっぱいあるけど、何から教えればいいんだろう？
システムエンジニアって覚えなくてはいけないことがいっぱいありますよね。
設計、プログラミング、サーバー、フレームワークなどなど…。一般的なビジネスマナーの他に、多くの技術系スキルを求められるのがSEという仕事です。
新人教育というと、つい自分が教わってきたやり方を踏襲しがちですが、果たしてそれが正しいのか疑問に思うことがあると思います。
何より教わる側にとって、先輩の教え方によって成長速度が遅くなってしまうのは、それだけで不幸です。
私は10年以上、様々な開発現場のリーダーとして新人教育にも携わってきましたが、その中で『最初にこれをやっておけば間違いないな』という３つのステップがあることに気づきました。
それがこちらです。
- ステップ１ とにかくテストをやらせる
- ステップ２ プログラミングとテスト設計を同時にやらせる
- ステップ３ コードレビューを徹底する
この手順に沿って教育計画を立てると、３ヶ月程度で戦力に数えられるくらいには成長します。（もちろん、優秀な人ならそれ以上の速度で成長します）
その理由と詳しいやり方についてご紹介いたします。
ステップ１：とにかくテストをやらせる
最初に新人にやらせるべきことは、自分たちが開発している製品やサービスのテストです。
テスト設計は任せず、純粋なテスターとして経験を積ませます。
これには３つの目的があります。
- 製品やサービスの特徴を知る
- チームのコミュニケーションを取りやすくする
- 商用プログラミングの厳しさとバグの勘所を覚えてもらう
詳しく見ていきます。
製品やサービスの特徴を知る
新人は、当たり前ですが開発中の製品やサービスについて詳しく知りません。
これから開発に関わってもらう製品やサービスの操作方法や特徴を覚えてもらう意味で、テストは手っ取り早いです。
開発に比べて、一人あたりの担当機能が多くなるので、複合的に製品を理解してもらうのに向いているためです。
しかもテストという特性上、マニアックな機能や設定に触る機会もあるでしょうから、口で説明するより深いところまで覚えてもらえます。
チームのコミュニケーションを取りやすくする
テストをするとバグ（不具合）が出ます。そうでなくても、機能の使い方や操作方法について確認する必要が出てくるでしょう。
バグを報告したり、使い方を聞いたり。開発担当者に話をする機会が必然的に増えるので、チーム内のコミュニケーションに慣れてもらうのに、テストはちょうど良いのです。
また、新人であれば職場の人間関係や上下関係も良く分かってないでしょうから、誰がどういう立場で仕事をしていて、どういう知識を持っているのか知ってもらうにも好都合です。
ただ、仲間とはいえ、いきなり見知らぬ先輩に一人でガンガン質問しに行くような鉄の心臓を持った人は少ないでしょうから、最初は間を取り持って上げるなどの気遣いは必要です。
商用プログラミングの厳しさとバグの勘所を覚えてもらう
多くの新人は、「SEの仕事はプログラミング」という認識で入社してきます。
プログラミング好きなことはSEとして大変結構なことですが、『趣味のプログラミングと商用プログラミングは違う』ということを知ってもらう必要があります。
品質確保のためにどういうテストをしているのか。どういうバグが許されないのか。長く仕事していると当たり前になりすぎて忘れがちですが、そういう基本的なところを叩き込んでおかないと今後も「なあなあ」でプログラミングされてしまいます。
例えば、アプリ系のシステムでは「データ保存中にタスクキルする」という主旨のテストを行います。開発者としてはデータが壊れないか絶対に確認すべき内容ですが、新人の感覚からすると「いや、誰もそんなことしねーよ」だったりするわけです。
こういう感覚で売り物のプログラミングをされてもらっては困るわけで、どういうところに我々は気を付けて開発しているか、意識を変えてもらう必要があるわけです。
合わせて、テストの勘所 = プログラミングや設計をする上で気を付けるべきポイントを学んでもらうためにも、テストが役に立ちます。
テストには一石三鳥から四鳥くらいのメリットがある
以上のようなことを、一つ一つ体系立てて教えていくのは時間もかかるし、何より座学では覚えも悪いです。
テストという実践形式だと身を持って学んでもらえますし、教える側の負担も少なく、経験値も多くなりやすいのでオススメです。
不具合をちゃんと報告しているか、手順を省かずテスト仕様書通りにちゃんとやっているか、など基本的なチェックは必須ですが、教育のためにもテストを任せてみましょう。
ステップ２：プログラミングとテスト設計をやらせる
テストを通してある程度開発の下地を作ることができたら、簡単な機能の開発を任せてみます。
プログラミングと書きましたが、詳細設計あたりからお願いしてもOKです。
ポイントは、自分が作ったものを自分で品質保証させることです。
そのためにテスト仕様書も合わせて作らせます。
テストを設計するということは、「どうやってバグ検出するか」「どうやってバグがないことを証明するか」を考えるということです。
バグを検出する方法を考える → そのバグを出さないようにプログラミングする という思考になり、プログラミングの質が向上します。
とはいえ、新人が作るテスト仕様書なんて穴だらけで役に立たない場合がほとんです。
テスト仕様書はしっかりレビューしてあげましょう。根気よくテストの穴を指摘してあげることで、下手なプログラムは書かなくなってきます。
また、テスト設計の考え方はテストコード作りに繋がりますので、テスト駆動開発でも役に立ちます。
テストの基本的な考え方は、次の本が分かりやすくてオススメです。
ステップ３：コードレビューを徹底する
最後に、コードレビューを徹底して行います。
ここでのコードレビューは、バグ検出よりプログラミングテクニックと書き方の指導が目的です。
ステップ２の実践で、テストによるバグの出し方までは分かるようになります。その上で、バグを出さないプログラムをどうやって作れば良いか、多くの新人がつまずきます。
そこで、プログラミングテクニックや書き方を指導するためのコードレビューです。
デザインパターンのようなテクニックは、このタイミングで教えると効果的です。
「デザインパターンを覚えろ」と言って、新人にデザインパターンの本を与える人がいますが、あまり効果的ではありません。
デザインパターンを知っておくに越したことはないのですが、使いどころが分からなければ宝の持ち腐れです。
必要な時に必要なパターンから覚えさせる方が、圧倒的に実践的で身に付くでしょう。
たぶん最初は、新人の組んだプログラムなんて汚くて読めたもんじゃないです笑。
持てるテクニックを駆使して、先輩としての格の違いを見せつけてやりましょう。
もちろんダメ出しばかりでは気が滅入ってしまうので、「ここはよく考えているね」など、適度にほめることも忘れずに。
ほめるのが苦手という人は、こちらの本をどうぞ！ ほめ方のセリフやバリエーションが豊富に掲載されており、実践で役立ちます。
一人でも部下がいる人のためのほめ方の教科書
ステップ１は１ヵ月、ステップ２～３は２ヵ月くらいが目安
教育スケジュールの目安は次の通りです。
- 開発の下地作り（ステップ１） １ヵ月
- 簡単な開発の実践（ステップ２～３） ２ヵ月
ステップ２（プログラミングとテスト設計）とステップ３（コードレビュー）は、何回かサイクルを繰り返すことになります。
そのため、合わせて２ヵ月くらいの予定で計画を立てるのがオススメです。
優秀な新人であれば、これより早く立ち上がりますので、状況に応じて計画を変更してください。
OJTは忙しいプロジェクトの合間を縫って行うため、新人教育は詰め込みがちになってしまいます。特に、まじめで熱心な人ほど「あれも教えなきゃ、これも教えなきゃ」と、はりきっていろんなことを教えがちです。
重要なのは相手の理解度に合わせた教育です。
テストやプログラムなどの作業を教育の主体にすることで、新米エンジニアが自分のペースで知識と経験を深めていく環境を作ることができます。
適宜フォローは必須ですが、結局のところ、自分で経験して覚えていってもらうのが成長への一番の近道なのです。
今回ご紹介した３つのステップが、みなさんの教育計画のご参考になれば幸いです。それでは(｀･ω･´)ゞ