男もすなる新人研修レポといふものを、私もしてみむとてするなり。
こんにちは、巳波みなとと言います。
もう4月からかなり時間が経って、各社新人研修レポが出切った感じだと思いますが
私も今年は、新人研修を仰せつかったので、レポートとして残したいと思います。
（この記事は、新人研修を「する」側のレポートです）
...という文章を去年の夏頃に書いて、気がついたら一年経ってました。
ただ、途中まで書いて勿体なかったので、頑張って書ききってみます。
この記事は2023年4月に私が実際に行った新人研修を元に書かれています。
あまり参考にならないかもしれませんが、ぜひ読んでいただけると嬉しいです
会社について
私は（自分の会社も含め）複数の会社に所属しているのですが、今回はその中の「株式会社ブイノス」で新人研修を実施しました。
簡単にブイノスを紹介すると
- 従業員数10名未満の小規模な会社
- 主にSES事業、一部では自社サービスを用いたプライム案件もやっている
- フルリモート推進（案件によっては出社あり）
- 東京都のテレワーク東京ルール宣言にも載ってるらしい
- 社員全員に本名とは別の名前がついている
- VR系コミュニティVNOSとの関わりがある
といった、ちょっと変わった会社です。
もっと気になったらHPでも見てみてください。
私について
- フリーランス含めてエンジニアとしての勤務経験4年
- フリーランス以前は高校生だったので、そこから合わせるとプログラミング歴は8年強くらい
- SESはブイノスがはじめて
- 主にフロントエンド、バックエンドもやる
といった感じです。
ぼっちエンジニア歴が長く、チーム開発はここ数年でやっと経験した感じです。
新人について
- 今年は2人（新卒）
- 両者共に大学にてプログラミングを学習
- ただしどちらもレガシーな言語
- 業務経験ほぼなし
- インターネットコミュニケーションツール（SlackやDiscord、Teamsなど）は使いこなせる
といった感じで、PCは日常的に使う文化があるが、プログラマとしての経験や新しめの言語の経験はない、といった感じでした。
新人研修立ち上げの背景
3月あたりに、4月から新人研修担当としてアサインされることが決定しました。
弊社では、新卒採用は初の試みだったので、当然マニュアルもなければ、前例もない、本当にゼロからの新人研修の立ち上げとなりました。
新人研修の立ち上げにあたり、上司から提示された目標が
- 1.5ヶ月で現場に出れるようなエンジニアにする
- SlackやGoogle Workspaceなどのコラボレーションツールを利用して、非同期で仕事ができるような知識と経験をつける
- GitHubフローなどを活用して、実際の現場に近いアサイン・レビューフローを習得する
- 社内の標準言語がGo言語なので、Go言語をある程度できるようにする
といった感じでした。
思想の整理と目標設定
話は変わってしまうんですが、私は昔からよく通話などで「プログラミングやりたいんだけどどれからやればいい？」とか、「サイト作りたいんだけどどうやって勉強すればいいの？」などの相談を受けてきました。
なので、新人研修ではそれらの知見を最大限に反映してカリキュラムを組もうと、アサインを受けた時点で決めていました。
思想の整理
まずは目標を立てるにあたり、自分の指針というか思想を整理することにしました。
1. 想像しやすい目標を立てる
例えば、ユーザー登録機能を作ってみよう！とか、画面になにか表示してみよう！とか、学習サイトではよく、その機能自体をゴールとしがちですが
極端な例だと、「怪しいフィッシングサイト風のウェブサイトを作ってみよう！」とか、「気温を教えてくれるサイトを作ってみよう！」とか、身近かつ想像しやすい題材にすると、一気に解像度があがりますよね。
会員登録画面を試しに作る課題を想像してみてください。
- SNSの会員登録画面
- 通販の会員登録画面
同じ会員登録画面ですが、両者共に性質が違うものだとわかりますね。
具体的な、想像しやすい目標を立ててあげることで、「会員登録画面」を作るというタスクが、ただの作業からではなくなります。「これってこういうものだよね」という想像ができるようになるんです。
2. ワクワクする目標を立てる
「計算機を作ってみよう！」という課題があったとして、これってテンション上がりますか？
上がる人がいたらごめんなさい。でも、計算機ってもう世の中にありふれてるじゃないですか。
それって今更作っても面白くないと思うんですよね。
なので、そこから一手間加えて、現在の為替レートを取ってきて、計算結果を外貨で表示してくれたら、便利だし面白そう！ってなると思うんですよね（まぁこの機能は割りとありがちですけどね、バルミュー◯フォンとか）
これはハッカソンの考えに似ていそうです。
ハッカソンも、決められた期間内に面白いプロダクトを作るのが目標ですが、新人研修でも、一定期間内に手が届く範囲で、面白いものを作るのが、個人的にはとても良いと思います。
今回の新人研修では、そのあたりの"ワクワクする目標"も、新人と一緒に決めようと考えました。
3. 実際に手を動かす
割と研修では、学習プラットフォームをやらせよう！みたいなのが多い気がします。
でも私は、学習プラットフォームで勉強したことがなく、自分の作りたいものに向かってひたすら調べたり書いたりエラーに遭遇して解決したりして、そうやって技術を身に着けてきました。
私はこういう経験がとても大切だと考えていて、なので基礎を学習プラットフォームで学ぶのは良いけど、最小限にして、あとは試行錯誤して苦労してもらう、という進め方をしようと考えました。
4. 提案できる環境を作る
昨今の情勢として、やはりAIの台頭があります。
正直、言われたことをやるのであれば、AIで事足りる時代になってきました。
SES事業の会社ではありますが、言われたことだけやるエンジニアは、淘汰されて消えていくと私は確信しています。
なので新人研修では、意見や提案ができる環境を用意しようと考えました。
意見や提案がないことでマイナスになるわけではないですが、プラスになるような環境を作ることを考えました。
目標を決める
どういった思想で新人研修をやっていくかは決まりました。
それでは実際に新人研修をやっていくにあたり、目標を決めてみます。
まず、必須事項を整理します。
- GitHubを一通り使えるようにする
- Go言語を実務で使えるようにする
- SlackやGitHub Issueを用いた、非同期的な開発ができるようにする
これらを踏まえて、Go言語を実務で使えるようにする、の解像度を上げてみます。
いろんな業務があるので一概には言えませんが
- APIを作る
- フレームワークも使ってみる
- 外部のAPIを呼ぶ
- DB操作をする
これくらいができれば、一先ずサポートを受けながら実務ができそうです。
そうしたら次は、新人たちと一緒に何を作るか決めます。
私は「こんなのがあったらいいな？とかある？」みたいな感じで、作りたいものがないか誘ってみました。
結果的に、今回は「気圧や天気の情報から、頭痛が起きそうな確率を出して、それを画像として生成する」というアプリケーションを作ってみることにしました。
新人たちは気圧に弱い体質らしく、そういうアプリケーションを作ってみたい、ということでした。
既存のサービスとしては、頭痛ーるが近いというかまんまですね。
そういうところも想像しやすくてよさそうです。
実際に研修をやってみる
1. GitHubを学ぶ
まずは、事前に用意した資料を元に、GitHubを触りながら覚えてもらいました。
お恥ずかしながら、自分は基本的なGit操作しかCLIでできず、また、GUIで直接見たほうが間違いが減ると思っているため、今回はGit操作は基本操作以外はすべてGUI（VSCodeのGitGraph）で教えました。
実際にGitHubでpush, pull, ブランチの作成, プルリクの作成などをやったり、コンフリクトをわざと発生させて解決してみたり、といったことをやりました。
実際にアプリケーションを作成する上で、実務上の動きはわかってくると思うので、ここではGitとはなんぞ、GitHubとはなんぞ、といった全体像がしっかりわかるようにしました。
2. 基礎学習
目標としてはアプリケーションを作るところですが、やはり基礎を何も知らなければ詰まってしまう部分も多いです。
そこでとりあえず、基礎学習をProgateを使ってやってもらうことにしました。
また、Progateの内容を発展させたタスクを自前で作って、学習した基礎を応用まで発展できるようにしました。
3. 要件定義・概要設計
今回新人研修で作成する「気圧や天気の情報から、頭痛が起きそうな確率を出して、それを画像として生成する」アプリケーションの要件定義と設計をしていきます。
まずはどんな機能が必要かを考えてみます。
- 気圧や天気を元に頭痛が起きそうな確率を出す
- 画像を生成して出力する
意外と単純そうです。
それを踏まえて、必要な内部機能を考えます。
- 気圧や天気を取得する
- 取得したデータをDBにいれる
- 実務上はいらないかもしれないけど、今回はDBを使いたかったのでこれは必須
- APIリクエストをトリガーに、画像を生成して返す
- これを生成して置いとけばいいんだけど、今回はAPIリクエストを使いたかったので必須にした
4. 実際に実装を進めていく
今回は
- 天気などの情報を取得してDBに入れる
- その情報を元に頭痛確率を計算して画像を作成して返す
というのを機能として分けて、同時に進めることにしました。
代わりに、お互いのコードをお互いにレビューし、何をしているのかをしっかり理解してもらうことにしました。
また、最終的なコードレビューは私が担当し、実務経験者の視点を持ったレビューも両者にみてもらうことにしました。
タスクはIssue化して投げており、期日も設けておきました。
これで新人たちは「自分は期待されている通りの速度で進められているか」がわかります。
基本的には、Issueでタスクを振って、IssueごとのFeatureブランチで作業、その日の作業終了時にpushしてもらうという流れで作業を進めました。
また、解決できない問題があればSlackで質問やGoogle Meetでの質問もできるようにしました。
VSCodeのペアプロ機能も早めに教えて活用しようと思ってたのですが、誰がどこを操作しているのかわかりにくかったりしたので、途中からは使ってません。
5. レポートを書いてもらう
これについては悩みました。
個人的な思想ではありますが、ただやったことを記載するレポートに意味がないからです。
こっちではレポートに書かれなくても、何をやってるか把握してるので、やったことレポート、は意味がないと思いました。
そこで、感想や、もっとこうしてほしい、といったことを、何でも書いて良いレポートにしました。
書きたいことなんでも書いて良いことにしました。
ここができなくて悔しかった、とか、この解説してもらったけど意味わからなかった、とか、そういう感じのことを書いてもらいました。
あと美味しいご飯とかでも良いです。
お手本は自分ができるように、言葉にはしてないけど感じたこと、新人研修の教育側の立場として、今どう考えてるか、今後どうしていきたいかなど、すべて書くことにしました。
あと美味しいご飯も書きました。
堅苦しいレポートには絶対にしたくなく、感覚としては交換日記に似た活用をしてほしいと考えました。
結果的にはこれはうまく機能していたように思えます。
Slackの分報（Times的なあれ）にもかなりいろいろと現在の状況を書いてくれてたので、インターネットコミュニケーションに慣れていた部分も、このレポートがうまく機能してくれた要因に思えます。
6. 開発終了時の発表
開発中の細かい話はここでは書ききれないので省略しますが、紆余曲折ありながらも開発が完了しました。
無事要件定義を満たすものが期限内に作れました（ちょっとオーバーしそうな部分は自分が実装しましたが）
最後に、開発終了時にはすべての社員の前で、新人教育で学んだことや作ったものを発表する場所を作ることになっていたので、それに合わせてスライドを作ってもらいました。
こういうことができるのは小規模な会社の面白いところですね。
私も新人教育をやってみてどうだったかみたいなスライドを作って発表しました。
その後も、会社独自のフレームワークを使った学習だったり、汎用フレームワークを使った開発だったりをやったんですが、ここでは触れません。
研修時に困ったこと・起こったこと
「これは理解できるだろう」はあてにならない
個人的には「この解説ならどんな人にも理解できる！イチコロや！」と思って説明したんですが、次には忘れてたりします。
あとはちゃんと伝わってなかったりもします。
その他にも、A＝Bなのはわかるよね？そしたら当然Bは・・・・？みたいな、関係性が全然理解されませんでした。
同じようなことでも、形が変わったり、ちょっと応用すると途端にわからなくなる、みたいなのもありました。
実務やってたり、普段からコードを見まくってる人間は、そもそもどうやってコードを見るのかを知ってますよね。
新人はそういう視点がまだなく、見慣れてないから関係性などが見いだせなかったり、納得できなかったりするのかもと思いました。
自分ならわかりやすく説明できる！と思ってたんですが、なかなか現実はそううまくはいかなく、実際にそういう経験ができたのは本当に良い体験でした。
思いもよらないところで躓いたりしますからね。
対策としては
- 理解できないところはより時間をかけて丁寧に説明する
- コードを分解して、実際にこのコードで何が起きてるのかを標準出力で出したりしてみて確認してみる
- どういうことをやってるのかをわかるような図を描いてみる
みたいなことをしました。
図を描いてビジュアライズしてみると案外すとんと理解してくれる場面もあったので、そういう方法の転換は大切そうです。
また、進めるにあたってペアプロもやったんですが、これが私が慣れてなく試行錯誤でした。
最初はVSCodeのペアプロ機能（LiveShare)でやってたんですが、全然意思疎通が取れない。
開いてるファイルなどが共有されず、各個人の画面で開いてるファイルが違うので、ここ！って言っても伝わりません。
これは速攻でやめました。
次はGoogle Meetで画面共有しながらのペアプロだったんですが、ここでは新人が実際に操作して、私がヘルプする、といった感じでやりました。
用語でいうと、私がナビゲーター、新人がドライバーと言う感じです。
そうしたら結局、私が全部指示して終わっちゃいました。
できる限り新人に考えるように促したかったんですが、ほとんど全部こっちに確認が飛んできて、それを全部修正していくので結局私が考えることになってしまいました。
一旦ここで、事例を調べてみます。
この記事では、新人がナビゲーター、私がドライバーという感じになってます。
記事に従い、実際に入れ替え、また、一定時間でナビゲーターとドライバーを入れ替えてみると
- 新人の発言量が増えた
- さっきまでの流れを把握しているので、理解度が進み、コードの進捗もよくなった
と、かなりいい感じでした。
これに関してはまだ最適解とは言えない感じなので、いろいろ試してみてその人に合うペアプロのやり方を見つけてみると良いかもしれません。
人によっては、ペアプロよりも自分で考え込むほうが理解もできるし速いみたいなこともあると思いますし。
コードは理解して書いているとは限らない
ある日、通話でレビューをしていた時、「ここは理解できてる？何をしているところ？」と聞いてみたら、すごく頓珍漢な回答が返ってきました。
そこで過去にレビューをパスした部分についても聞いてみたところ、「わからない」「〇〇をしているところ（←間違っている）」「書いたら動いた」みたいな回答がありました（もちろん正しいところもたくさんありましたよ）。
すべてのエンジニアが、すべてのライブラリをすべて理解して書いているとは思いません。
実際、ライブラリのサンプルコードを取ってきて動かせば、入出力だけわかってれば良い部分もあると思います。
ですが、自分が今なにをやっているか、根本からわかっていないのは大問題で、それは無駄な処理を呼ぶことにもつながっていきます。
これの対策として、相互レビューのあとの私によるレビューについては、処理の内容を理解しているかも含めた、通話でのレビューに切り替えました。
理解していないところは再度理解してもらった上でレビューを行いました。
これによって、コードの解像度がかなり上がったかなと思います。
コードは人が書いているとは限らない
ある日、コードレビューをしていたところ、違和感がありました。
コメントがめちゃくちゃ流暢な英語で細かいし、変数や定数の命名が適切すぎるのです。
...なるほど。
「これ、ChatGPTに書かせたよね？」
「はい...」
これの対応はめちゃくちゃ迷いました。
GitHub Copilotはもはや誰でも使ってるし、ChatGPTもみんな使ってます。
これからの時代、むしろAIといっしょに作業をして効率化していくこともスキルのひとつとなっていきそうな感じです。
この新人教育も、ChatGPTと相談して決めたところがいくつもあります。私も実務で許可されてる場合はAI使いますし。
ですが、先のコード理解度の低下の件もあります。
それに、AIを活用されている方なら分かる通り、脆弱性を孕んだ恐ろしいコードを出してくることもあります。
そこで、以下のように決めました。
- 原則ChatGPTなどにコードを生成させることは禁止
- 質問や相談、データの変換などの用途で使うのはOK（できれば私に相談してほしいけどね）
- ただし、ChatGPTにコードを生成させても、細かく直せば気付けないので、もしもコードを生成してしまった場合、しっかり内容を理解した上でコードを採用すること
としました。
コード理解度については、対面レビューで担保することにして、進めていきました。
私ではなくChatGPTに頼らせてしまったのは、自分が忙しいこともあり、気を遣わせてしまったのかなと後悔しています。
Markdownって案外むずかしい
新人研修中、MarkdownでREADMEを書いてもらってたのですが、書き方もそれぞれ、Markdown記法もあんまり活用されてなかったり、書くだけでものすっごい時間がかかったり、Markdown記法まとめとにらめっこしたり....
Markdownって慣れてない人からしたら案外むずかしい。ということを痛感しました。
まぁこれに関しては慣れてもらうしかないわけですが。
（番外編）Dockerクソ重い
DBを用意するにあたって、WSL上で作業をしてもらっていたのですが、CPU Corei7, RAM 16GBある社用PCでも重かったです。
原因はおそらくWSLとDockerのメモリバカ食い。
(WSLではファイルをLinuxファイルシステム上に置いてもらってたのですが、それでも重かった）
私は社用PCでWindowsもMac(Apple Silicon)の両方貸してもらってるのですが、Docker想定なら最初からMacを配っておいたほうがよさそうな気がします。
初めて新人研修をやってみた感想
えー、正直めちゃくちゃ楽しかったです。
ずっと自分の中にあった「ぼくのかんがえたさいきょーのえんじにあおんぼーでぃんぐ」が、全然最強じゃないこともわかりました。
ペアプロのことも全然知らなかったし、人によってこんなにも理解度や、考え方に差があると思いませんでした。
新人2人も、自身の性格を反映したような書き方や悩み方をしてて面白かったです。
ChatGPTを始めとするAIの台頭により、市場では「考えられるエンジニア」が求められていきます。
プロダクトをもっと良くするにはどうすればよいか、より高速に実行されるようにするにはどうすればよいか。
今回の新人教育では、新人と一緒に「考える」ことを重きにおいて、進めていきました。
この記事を書き始めてから普通に1年が経ちましたが、二人は今上司のサポートを受けながら、現場で頑張ってます。
この記事に書いてあることや、この教育カリキュラムについては、一応社内に資料を残しておきました。
実は3月で転職してしまうので、次の教育は私ではないんですが、なにか参考になると良いですね。
最後まで読んでいただきありがとうございました。
ご意見などがあればぜひコメントお待ちしています。
何かあれば Twitter @minatoo86 まで。
Discussion