はじめに
こんにちは、テクノロジー本部の後藤です。
エンジニア一年目ということで、この間プロジェクトへの配属を経験しました。大抵配属後には開発研修を実施されるかと思いますが、今回は僕が体験した「シャドーイング研修」なるものについて紹介します！
！ プログラミングの基礎は、配属前の研修で習得する、もしくはすでに知識があるという前提で書いてます。
また、こちらはアドベントカレンダー12月23日分の記事です。
シャドーイング研修とは
僕のいるプロジェクトで勝手にそう呼んでいる研修は、
既存の機能と同じものを追加実装する
という模擬開発です。 具体的には、僕の場合はWEBエンジニアなので
「☆☆画面と同じものを△△画面に（別のパスに）作成」
・CRUDのエンドポイントをAPIに追加する
・クライアント側の画面を作ってAPI呼ぶ
・単体テスト作る
という感じでした。既存の☆☆画面のコードを参考にして（コピって）、△△用のファイルやコードを書いていくわけです。そして、知らないコードはその都度調べながら、学習していきます。
目的
シャドーイング研修の目的は
- 担当プロジェクトで使われている技術の学習
- ソースコードの構成やルールの把握
- プロジェクトでの開発フローの理解
になります。シャドーイング研修では、このような「実際の業務がこなせるようになるために、開発研修で達成したいこと」をある程度網羅することができると考えています。
（この記事の最後で、他の研修形態との比較を取り上げています）
ポイント
私見ですが、目的を達成するにあたってのポイントとしては
- 実際の開発と同じ環境、同じルールで
- 開発におけるすべてのレイヤーを一通り
- 例：データベースアクセス～クライアント側の画面
- （研修者の業務範囲すべてという意味）
- コードはコピペしてもいいけど、分からないまま使わない
- 仕様をオリジナルからちょっとだけ変える
あたりでしょうか。
ひとつ目に関連しますが、一番重要なのは、「成果物は本物の機能追加を想定する」ことだと思います。自分の好き勝手に書いてはダメですし、上手く既存の共通コンポーネントを利用することも、実際の開発には必要です。
（時間まで本番を想定すると、じっくり学習できないのでご勘弁）
また、本番と同じようにコードレビューしていただくことも可能で、レビュー文化を知る機会ともなります。そのプロジェクトでの、アーキテクチャ・変数の付け方・コーディング規則などが体験でき、そこがシャドーイング研修の醍醐味と言っても過言じゃないです！
感想
実際に自分が行ってみた感想は
- ゴールがあるので学習が進めやすい
機能を１つ追加するという分かりやすい目標があると、何を学習すればよいか明確になりますし、何よりモチベーションになると思います。 - 担当プロジェクトのコードをしっかり理解できる
眺めるだけじゃなく自らコードを書く＋レビューをいただける＋研修なので不明点はとことん調べられる＝完全に理解した - 知識ゼロの開発言語だと根気が要る
既存コードの中身を理解するために、定義内にあるメソッドを調べそのメソッドが参照しているライブラリを調べ・・・のように、地獄の果てまで参照先を追い続けることもありました。 - 最短で実務のための準備が整えられる
必要とされる技術スキルとプロジェクトに対する理解が、同時に手に入ります。
です。つまるところ、PBL（Project Based Learning）が好物の人は体に合うと思います。
他の形態との比較
プロジェクト配属後の開発研修には、他にも
- 技術を動画や自主開発等で勉強する：教材型
- 不具合修正などの簡単な案件で学習する：実践型
という形態があるかと思いますので、それらと比較してみました。
| 利点 | 欠点 | |
|---|---|---|
| シャドーイング |
|
|
| 教材型 |
|
|
| 実践型 |
|
|
おわり
自分がさせてもらった研修の形式が結構良かったので、その紹介的な感じでこの記事を書きました。シャドーイング研修が最強！ということはなく、個人ごとに向き・不向きがあると思いますので、今後何かの参考になれば幸いです。
