NaClの岸野です。今年もインターンシップが10日間本社で開催されました。
本記事では、松江本社のインターンシップの全体の流れや、参加者の声、開催側の課題や感想についてまとめております。
今年度のインターンシップの題材は「Rails Tutorial で作成したWebアプリの機能追加」です。
昨年と同じテーマですが、かなり実務に近い形で好評であったため、さらなるブラッシュアップも期待して、
引き続きコチラのテーマを扱っていきます。
参加者のうち3名は前週のRuby合宿にてほとんど初めてRubyに触る、残りの5名は学校の授業などで数年プログラミングをしているということでスキルのギャップがありました。
以下のスケジュールで開催しました。去年の講義パートが好評だったので踏襲するようなスケジュールでの開催です。
赤字は東京支社とのオンラインセッションです。
情報共有ツールとしてDiscordを利用しました。今年は画像・リンクの共有のほかにレビュー依頼通知のために頻繁に活用しました。
まず、最初の自己紹介とインターンシップ概要です。はじめ方と進行がいまいちでぬるっと始まってぬるっと終わったしまった気がします。
去年もこんな感じで微妙だったのは自分が不得意なのもありますが、進行について完全に形式化してしまった方が良いかもしれないですね。
あるいは、リモートワーク続きで自然な会話が減ってしまっているのも要因の一つかもしれないので、数営業日前から出社して会話の慣らし運転をするのも手でしょうか。
その後しばし休憩を挟み、社長の前田より会社説明を行いました。
事前に質問をいくつかいただいていたので会社説明ののちに答えていただきました。
結構面白い質問でしたので、事前に社内でも多少議論が行われていました。
(Meetのセットアップ等をしていたのでメモが十分にとれませんでした、申し訳ありません。)
ずっと話ばっかり聞いているのも退屈なので、午後一番は早速環境構築ということで皆さんに手を動かしてもらいました。
初日の作業は昨年同様チーム関係なしに行ってもらい、各学生のスキルを見極めてチーム分けの材料を集めていました。
一昨年あたりまではここが鬼門だったイメージですが、インターン用のリポジトリがだいぶ整備されてReadmeが親切になったおかげでかなりすいすいと進みました。
ただし、人によってはキャプチャのないReadmeがあまり親切でなかったようで、ゴールがログインできることというのがいまいち伝わってなかった気がします。
Readmeの改修まで必要かというと若干疑問ですが、少なくとも横についてライブコーディング形式でセットアップを進めるという手法をとっても良かったかもしれないです。
今回は7名の方はエディタがVSCodeであったため、WSLでの環境構築はプラグインが統一できてやりやすかったです。
講義その1。Webアプリについての講義でした。
内容としては、WEBアプリとはなにか、HTTPやMVCについてでした。
そのあとの開発に直結する話なので概念だけでもあるとありがたいですね。
講義一発だけだと全部頭に入らないので何回か同じような話を自分もしたのですが、「こういう話があったよね」でリファレンスできるのであるとすごく助かります。
反面、ほかの講義は横にコードがありきで進むので聞いていて直感的にわかるのですが、この講義は横に具体的なコードがあまりなく話が進むので、作業と結び付けづらいというのが一つ課題だと思います。
残りのちょっとの時間環境構築の続きをやりつつ1日目終了。
講義その2。Git, HTMLに関する講義です。
HTMLの講義については学校でやったよという人が昨年ちらほらあったため、今回ははじめての人向け講座という感じでした。皆さん復習がてらの方も居りつつ聞いていました。
Gitの講義については個人的にはかなり良かったと思います。この講義が功を奏したのか、開発フェーズに入った時にGitの質問はほとんど飛んできませんでした、すごい!
今年は昨年の講義にさらにプラスして、加納が個人で運用しているWebサイトを使って、Railsについての具体的な講義も行いました。
社員としても他の社員が個人で作成している作品やWebサイトはそう頻繁に見ることはないので興味深かったです。
コチラの講義は人気だったのか、昼休みの時間にも延長してもっと見てみたいという人に向けて解説する時間もありました。
この辺で担当者で集まりチーム分けについて議論しました。
今回のチーム分けの際に気にかけた点は「スキル」と「所属」です。
「スキル」をベースにチーム分けする理由として、前年までのインターンシップの傾向として、チーム内でスキル差があるとスキルがない人は開発に携わりづらく、かつ我々からもスキルが一番ある人以外の評価が難しいという点がありました。これを一旦別の視点で見るために同じスキル同士が固まって開発するという方向性を一つ作りました。
「スキル」を重視した場合、学校ごとの学習内容に依存する都合上、同じ学校の人が固まりやすいという欠点があり、せっかくのインターンの機会にほかの学校の学生とのかかわりが減ることが懸念されるため、「所属」という観点も挙げました。
今回はスキルのばらつきが顕著な場合にスキルごとにチーム分けをしたらどうなるかという試験的要素から「スキル」に応じたチーム分けにしました。
講義その4。西田のたのしいRubyです。
コードを自分が望む挙動をするものに変えていく様は今回も好評でした。
こうやって教えればいいのかと自分の中でも勉強になるところが毎回あります。
今回は会議室のモニターが大きくなったのでこの講義を参考にしながら、私も道中の開発でのライブコーディング的な教え方を実践してみました。
開発やり方講座。これまた開発がぬるっと始まってしまうと思い、急遽用意したコンテンツです。
GithubにIssueを用意してます。Pull Request出してくださいね。などの開発の基本的な進め方について教えて開発を始める前のワンクッションにしました。
いろいろなチュートリアル的行事を終えていよいよ開発が始まりました。
GitやRuby, Railsについて何も教えなくてもすいすいと進むチームもいれば何もわからず足踏みというチームがでて、「これがスキルで分けた場合のキャッチアップまでの差か」と痛感しました。
夕会について、土壇場でやはり東京とつなごうと提案しましたがこれが良い選択肢でした。
東京でのインターンシップの進捗についてここでつないでいないといまいちわからなかったですし、各講義での機材や進め方についてのフィードバックも得られたのでインターンシップの改善速度の向上に役立ちました。
午前中から開発作業が開始しました。初心者向けのIssueは皆さんわかりやすかったようで開始時点でほとんど終わっていました。
難易度:やさしいの課題からRailsについて本格的に取り組むことになるので、わからない人もちらほらと出てきました。
Railsを扱うに際してどこから見ていけばいいかという「とっかかり」は初心者の方にとっては鬼門だと思うので、Issueを一つ取り上げて、ホワイトボードを使いながらひとつずつ流れを説明していきました。
最終的にその場限りではなんとなく理解はしてもらえたのですが、じゃあいざ自分でやってみるとなるとかなりきつそうでした。
3日目の続きの説明をホワイトボードを使いながら主にしながら、コードレビューをしていました。教えながらだとどうしても全部見きれないところを諸星がサポートする形でのコードレビューでした。
コードレビューをしながらだと、別チームのいいコードを流用して教えることができたのでとても助かりました。ただこれもその場で教える分にはいいのですが、余分なところまで伝わってしまってなかなか完全に理解してもらうのは難しかったです。
今回のインターンシップでは、参加者の気持ちを直接うかがうために伊東・田中により2回に分けてインタビューを行いました。期間中にインターンの進め方についてもフィードバックを得られたので進め方の改善につながりました。
講義その5。超絶技巧プログラミングです。TRICKのコードをいくつか紹介していただきました。相変わらずぱっと見ではよくわからない奇妙なコードばかりで面白かったです。
学生の皆さんもコードに見えない文字列にあっけにとられながらも、動いている様を見て驚いていました。
5日目ということで東京支社とのインターンシップとの並走はここで終了しますが、松江本社は折り返しということでさらに難しい課題へのチャレンジが見られるようになってきました。
5日目のインタビューでのフィードバックを受けて、わからない人向けに今までの作業のおさらいをしてわからないところを埋め合わせる時間を設けてみました。
まず、Gitについてブランチを切ってからプルリクエストをマージするところまでの手順を列挙してみて、いまいち理解できていないポイントについて一つずつ説明していきました。
体感として、git add
やgit push
はおおむねわかっていたのですが、git commit
とgit push
の違いや、git rebase
でのブランチの動き、git stash
やコンフリクトなどの比較的イレギュラーな時の対応についていまいちこちらの説明が行き届いていなかったように感じました。
次に、Railsでの機能開発を一緒にやってみてどういう順序で実装するかを確認しました。例として、マイクロポストの詳細画面を作成して確認しました。
そして昼休みはまた、初日と同じところのお弁当を食べながらキッチンで交流会をしました。今回は社員含めて17名での交流会でした。
このランチ会については今回のインターンシップで最も上手くいかなかったポイントです。当初私が想像していた規模感とは違っており、段取りをそこまで考えてなかったので、最初でまごまごしてしまい、時間的にも流れ的にも満足のいくものにはならなかったです。
今後の反省として部屋を分けたり、社員の数を減らしてでも上限を決めて人数を絞るべきだと思いました。
反省すべき点はたくさんありましたが、ランチ会を期にDiscord上での会話が活発化したのでやはりそういった交流機会を増やすという面では良かったかと思います。
7日目に残りの5名のインタビュー時間を設けました。
初心者向けティーチングに関してもおおむね6日目の続きという感じで行いました。
途中からRailsよりもRubyに関する疑問が多く飛ぶようになったのでirbを立ち上げてライブコーディングでのティーチングをしていました。
今回は7日目から時間に余裕が出てくるパターンでした。一通り初心者向けティーチングをしたあとはおおむねコードレビューのみという流れでした。
7日目に引き続きライブコーディング形式で教えました。8日目はRailsメインで行いました。やはりこのやり方だと板書よりも「こうしたらこうなる」というリアルタイムな動きがわかりやすく、良かったです。
9日目から発表準備にぼちぼち入ろうかという流れだったのでこのタイミングで成果発表の詳細についてアナウンスしました。
最後の開発ができる9日目です。ずっとチームBで原因がわからなかったダークモード機能での画面のちらつきについて説明できるように手元で実装して確認してみました。(実装コード)
ただ自分もstimulusとjavascriptのタイミングの互換まではちゃんとは知らなかったので、とりあえずstimulusを使用すれば接続タイミングでしか呼び出したくない処理を分離させられるとしか答えられませんでした。
後々、諸星よりturbo:load
での呼び出しだと処理のタイミング的に遅いのでturbo:render
を使うとよいのかも、というstimulusを使わない場合のアプローチの提案がありました。
作品の最終調整を終えたのち、発表準備へと移っていきました。
ついに成果発表の日となりました。
各グループの発表がAチームから行われていきます。
今回はメモを取る依頼をし損ねてしまったので内容はうろ覚えですが以下のような内容でした。
スキルごとにチーム分けしたおかげで、各チームそれぞれなりの工夫や頑張りが見られて良かったです。
今回のインターンシップはかなりGitHubにべったり張り付いて助言していたので皆さんのコードをよく知っていたので、それを上手く伝えられているかが見どころでした。ただ、コードからは見えない頑張りや工夫を発表で聞くことができてよかったです。
発表後に今年はインタビューがあると聞いていました。まさか私が対応するとは思わず、引き受けましたが若干段取りがずれて集合写真を取り忘れるなど、最後の書類整理の時間がバタバタしてしまいました。