新入社員研修を振り返る【2021】

2021年の4月〜6月末までの約3ヶ月間のIT企業向けの新人研修を振り返る。

研修の日記はこちら。

ちなみに去年の研修の振り返りはこちら。

カリキュラムについての振り返り、改善案こちら。

ここではカリキュラム以外の、研修の運用という観点から振り返りをしていきます。

ソースコードレビューの仕組みを考える

今年は個人的に、ソースコードのレビューを今まで以上に強化していこうという目標を立てていました。
研修開始から約2ヶ月は、ほぼ毎日演習や課題という名目でプログラムを提出してもらっていたので、そのプログラムのソースコードを細かく読んでフィードバックをしていこうと思っていました。
結果はというと、、全然できなかった。。

レビューができなかった理由を挙げると
1. 単純にめんどくさい
2. 演習問題に最初からコードが書かれすぎている
3. 物理的に時間が足りない

1. 単純にめんどくさい
これは、単純に私がめんどくさがりの性格というのが一つ。
それに加えて、演習や課題の提出方法がよくなかったと反省。
演習や課題の提出は、講師用のPCにSamba環境を構築し、その中の共有フォルダに提出してもらいました。
共有フォルダに提出する方式にしてしまうと、ソースコードを読むためにはファイルを開かなければいけない。提出をプロジェクト単位での提出にしてしまうと、フォルダの階層も深くなってファイル数も多くなる。
20人以上いる研修生のプログラムを１つ１つファイルを開いてチェックするのはめんどくさすぎました。

2. 演習問題に最初からコードが書かれすぎている
演習問題や課題は、私ではなく別の講師が作成したものだったのですが、演習問題の中を見てみると、初めからコメントやコードがある程度書かれていた。私は自分で演習問題を作っていないので、コードを見た時に、どの部分が最初から書かれている部分で、どの部分が研修生が書いたものなのかを判断することが出来なかった。（事前に確認すればよいだけではあるけれど、そこに労力をさく必要があるのかと思ってしまった。）

演習問題にヒントが多すぎるのは、コードレビューがしにくいという観点からもあまり良くない傾向ですが、それ以上に、研修生の考える力を鍛えることが出来ないという点でも色々と問題があります。が、この問題はコードレビューとは別の問題なのでまた別のテーマで触れます。

3. 物理的に時間が足りない
これはシンプルに私の仕事の効率の問題。面倒な作業はシステム化して効率化を図ったり、アシスタント講師とうまく連携してより効率化していくしかないでしょう。

解決策
ソースコードレビューの仕組みについては、私の中で既に解決策はあります。それは「GitHubを活用する」です。まず、共有フォルダにプログラムを提出してもらう形式にすると、レビューするときにファイルを開く手間が発生します。この手間が意外としんどい。GitHub上にプログラムを置いて貰えば、確認する側は全てブラウザ上でコードの確認が完結します。
また、これは最近知ったGitHub関連の便利機能なのですが、GitHubのリポジトリを参照しているときに、URLの.comの前に「1s」という文字列をつけると、リポジトリの内容をVS CodeのようなUIで参照することが出来ます。
この機能を使えば、かなり楽に時短してコードレビューができます。
これを実現するには、研修のかなり序盤の方でGitの使い方について講義をして慣れてもらい、かつ演習や課題は全てGitHubで管理する必要がありますが、大した手間ではないので、この仕組みを使えばコードレビューの課題をクリアできそうです。

ファイル共有の仕組みを考える

ソースコードの問題はGitHubを使えば（おそらく）解決できそうだけど、コード以外のファイル共有の仕組みも考えておく必要があるなと思った。
ファイルの共有も、Samba上の共有フォルダを使ってやりとりをしてもらっていたけど、これも色々と問題を抱えていた。
特に、研修後半のグループ開発時のファイル共有が色々と厄介でした。
グループ開発時には、グループでスケジュール管理をしたり設計書類を主にExcelを使って作成してもらっていましたが、共有フォルダでExcelを管理していると、1人が作業しているときに他の人が編集をすることが出来ないし、時々誰もファイルを開いていなくても、ファイルが誰かに掴まれている状態になって編集が出来ない状態になることがありました。
また、講師側も、各グループのスケジュール表を確認することもありますが、コードレビューの時と同様、階層をたどってファイルを探して、ファイルを開かなければいけないのが結構ネックで、確認するのがかなりしんどかったです。

解決策
１つのExcelファイルを複数人で共有する場合には、OneDrive上でExcelファイルを作成して、ブラウザ上で編集する仕組みにするのがおそらくベスト。あるいはGoogleのスプレッドシートを使用する。ブラウザ上のExcelやスプレッドシートは、アプリのExcelに比べると操作性やできることは制限されますが、スケジュール管理や要件定義書の作成程度なら、そこまで高度な機能を使うこともないので、ブラウザ上から複数人が同時に編集・閲覧できる方がメリットが多そうです。

ディスカッションをする際には、Excelで議事録を作成してそれをメールで送信してもらうという実にレガシーな方法を採用しています。色々と事情があってそういう運用をしている部分もありますが、これもわざわざメールからファイルを開いて確認する必要があって非常に手間。議事録のような、テキスト情報を複数人で簡単に閲覧・編集できるようにするには、OneNoteを使うのが良いかもしれません。Excelを使う都合上、Microsoftのアカウントを作ることになるので、どうせならそれを有効活用して、ブラウザ上でのOneNoteで記録していくことが良さそうです。

Excelやスプレッドシートを使うとメンバー同士で同時にファイルを共有するのに非常に便利ですが、厄介なのが、印刷を前提としたファイルを作成する場合です。実際の現場の仕事では、紙で印刷することを前提としてExcelで作成したファイルをお客さんにメールで送付することがあります。研修でも、一部のファイルはそのように作成する必要があるものがあって、その場合だけはブラウザ上で作成したExcelファイルをダウンロードして、印刷されることを前提に整える必要が出てきますが、それはもう仕方がないと割り切ろう。

日報の仕組みを考える

研修中は研修生に毎日日報を書いてもらっています。
日報はExcelに書いてもらい、それをメールで添付して送ってもらっています。この仕組みもどうにか効率化できないものかと思ってしまう。

日報を書いてもらうのはいくつかの目的があります。
1. 研修生がメールの書き方や報告書の書き方を鍛えるため
2. 研修を依頼した企業の担当者に研修生の状況を知ってもらうたね
3. 講師が研修内で知り得ない研修生の状況を知るため

日報を書くこと自体は必要だと考えますが、毎日メールを使ってExcelファイルを送る必要があるのかは微妙なところです。メールの書き方を覚えるという意味において、研修開始１週間程度は意味があるかもしれませんが、それ以降はメールの内容もほぼテンプレをコピペする形になるので、あまり意味はなくなってきます。
講師側にとっては、研修生の人数分毎日メールが増えてくるので、目的のメールを探すことが日々面倒になってきます。特定の研修生の日報を探そうとしたときに、探すのが非常に手間というデメリットが大きいです。
企業の担当者にも日報を見てもらうと考えると、メールで送るというのは最も手っ取り早い手段ではあります。
しかし、Excelで日報を書いてしまうと、データとして蓄積することが難しくなります。本来なら今の時代、全てをデータとして蓄積して、AIを活用して分析して研修の品質向上に繋げていくのがあるべき姿のように思います。

解決策
この日報問題を解決する方法は、システム化するの1点でしょう。
Web上で日報を作成してもらい、全てのデータをデータベースに蓄積する。
そうすることで、データを蓄積しながら、講師は検索機能などを使って簡単に日報を検索・閲覧することができます。
書き方についてフィードバックを送ることができる機能までつけることができれば、指導もしやすくなって一石二鳥です。
企業担当者にどうやって見てもらうかが一つ課題となりそうですが、システムで自動でメールを送信する仕組みにするか、システム側で閲覧機能のみの権限を付けてそれを企業担当者に付与して確認してもらう仕組みにすると良さそうです。

グループ開発について考える

研修の最後の約２週間はグループ開発という、５〜６人でチームを作って要件定義からテストまでの開発工程を経験してもらいます。今年はグループ開発の様子を見ていて色々と思うところがありました。

グループ開発という名前について
そもそも、グループ開発という名前は、チーム開発という名前に変えるべきなのかもしれません。
記事の中でも、グループという言葉とチームという言葉がごちゃ混ぜになっていますが、グループという言葉とチームという言葉は明確に違いがあります。グループは、ただ複数人の集まりでしたが、チームは、何か明確な目標があって、その目標達成のために集められてた人たちのことです。
研修のカリキュラムではグループ開発という名前になっていますが、１つのシステムを作るという明確な目標があるので、名前を変えたほうが良さそうです。

期間が短い
グループ開発では、要件定義、基本設計、詳細設計、プログラミング、テストといういわゆる一般的な開発工程を一通り経験してもらいます。要件定義と基本設計は講師がレビューをしますが、詳細設計以降は時間が足りないためレビューはしていません。
しかし、品質の向上を考えるなら全ての工程でレビューをしたかった。特にソースコードレビューはやるべきでした。
そもそもレビューがあってもなくても２週間という期間はかなり短い。
期間を1ヶ月程度まで延ばせば、レビューをしながら、研修生も無理せずそれなりの品質のものを完成させることができるのかなと思いました。

資料の刷新
グループ開発をやるにあたり、スケジュール管理表や設計書類のサンプルを用意していましたが、それぞれの資料を刷新しておけばよかったと後悔。
まず、スケジュール管理表が少し複雑で扱いにくかったので、もっとシンプルな資料にしておくべきでした。
そして、課題管理表も作っておくべきでした。これらは先にも話しましたが、ブラウザ上で共有できる形で作っておくことで、よりスムーズな運用ができたのではないかと思う。

振り返りをする
プロジェクトは終わった後の振り返りが大事。今年は、研修最終日の前日に１時間ほどとって振り返りの時間を作ったけれど、思ったほど有益な振り返りができなかった。もっと時間をとりながら、講師も参加して有意義な時間にする必要があるなと思った。

開発物の決め方
グループ開発で何を作るのかは、グループでディスカッションをして自分たちで自由に決めてもらっている。これはこれで良いのだが、いくらか制限は儲けた方が良かったかもしれない。
自分たちにとって役に立つもの、自分たちの生活や仕事で何かを効率化するもの、世の中の課題の解決に役に立つもの、といったある種のミッションは作っておくほうが良さそう。そうすることで、ただ面白そうという理由でゲーム性の高いものを作ろうとするのを防げる気がする。

まとめ

今回、振り返りの記事を書くのにあたり、去年書いた振り返りの記事を読み返してみました。
去年はZoomを導入して、リモートで講義をすることもあったので、リモートの運用に関して得たことが中心に振り返りをしているなと思いました。あれはあれで有益なノウハウが得られました。しかし、その反面研修の本質的な部分にはあまり触れられていないなとも思いました。
今年は、Zoomは活用しつつも、全員対面で講義をすることが出来たので、研修の運用方法に関してより本質的なことを色々と考えられた気がします。来年以降また研修の講師をすることができるかは分かりませんが、機会があれば今回の気づきを改善してより良いものにしていきたい。