HTML / JS 入門から Next.js での開発を 2 日間で行う研修をして得られた知見など
こんばんは。今日は東京でも雪の予報らしく、まだまだ冬が続きそうな雰囲気ですね。
さて先日の 1 月 31 - 2 日に、自分が所属する筑波大学 全学学類・専門学群・総合学域群代表者会議の一組織である情報処理推進特別委員会[1](以下 IPC)にて、HTML / JavaScript 入門から Next.js での開発を 2 日間で行う研修をいなにわうどんくんと行いました。本記事では、技術系学生組織における問題について述べたあと、その解決方法としての昨日の研修について述べていきたいと思います。
技術系学生組織における問題
技術系の学生組織に籍を置かれる先輩の皆様にとっては、頭が痛くなるほど悩まれたご経験があるかと思います。私も現在は上述の IPC に所属しているものの、一昨年までは筑波大学の学園祭実行委員会に位置する情報メディアシステム局[2](以下 jsys)に籍を置き、Web の開発などを行っておりました。後者の組織においては問題が顕著に現れており、特に次のような問題が散見されました。
- 1 年生の定着率が悪い
- 技術がもともと得意である人とそうでない人との間で、技術力しかりコミュニティの壁ができてしまう
- 技術をやるぞ!という気持ちを持って組織に入ってきた人たちが、実際にデプロイされるプロダクトへの開発に参加できない
いくつかの問題が浮き彫りになる技術系学生組織ですが、結局のところ同期・先輩間での技術力の差がすべての原因の発端になっているような気がします。技術系学生組織においては、往々にして技術トークが行われがちですが、技術について詳しくない人々は当然引け目を感じ、次第にコミュニティからフェードアウトしていってしまいます。また、プロダクトにコミットすることのできない劣等感もフェードアウトの引き金を引きがちです。こうした考察から見えてくることとして、技術中心の学生組織では技術力の有無が組織の存続に直結という点が揚げられます。実際に我々の代の jsys においても、自分たちが執行代になったときに残っていた人のほどんとがエンジニア、または映像を扱える人間のみでした。一部で事務処理的なタスクをしてくれていた方々もいましたが、積極的にお話する機会はなく、コミュニティの中心にいたのは常に我々のみでした。すなわち、代が変わった途端に組織としての人数が減少してしまったのです。新しく人が入ってくるから減っていないだろう、という指摘があるかもしれませんが、結局現役でバリバリ動ける人間の数が減ってしまっている上、少ない人数で実現できる目標には制約があるため、縮小して達成した目標では組織の魅力が減少し、次第に破滅に向かうというのは誰でも予測ができることでしょう
一方でこれをどう改善するかは、各組織における目標、扱う技術、そしてメンバーの数など様々なパラメータによって規定されるため、統一的な解がないのが現状です。また、解があったとしても自分の組織に適合するかどうかはやってみないとわからないため、ある意味では博打でもあります。従って、このような問題をなるべく良い方向に向かわせるには、組織について分かっている先輩たちが熟考して、それぞれの組織にあった解決法を考案・実施するほかにはないと思われます。
IPC における研修
前章では一丁前なことを書いていますが、私の所属する IPC では「技術初心者の 1 年生たちに実際のプロダクトにコミットできるような力をつけてもらうため」に研修を行うことになりました。問題解決のためではなく、あくまでも実務的な側面での動機です。どちらかといえば、この研修を行ったからこそ前述のような問題に思いを馳せることができたのではないかと思います。
IPC では、前述のように「HTML / JavaScript 入門から Next.js での開発を 2 日間で行う研修」を行いました。研修の構想自体は 2023 年の 8 月ほどからありましたが、私といなにわうどんの怠惰により、ずるずると引き伸ばされてやっと行われた形です(笑)。
研修形式と日程
最終的に、GitHub に用意した資料を読みながら各自で進めてもらい、必要に応じて講師である我々を読んでもらうというハンズオン形式[3]で研修を進めました。ハンズオン形式で進めたのにも理由があります。
去年の秋、週に 1 回ほど研修メンバーがオンサイトで集まって、全員で足並みをそろえて Java を学ぶ研修を行っていました。私またはいなにわうどんがホワイトボード等で Java について述べていく形です。しかし次第に進めるにつれ、入門とはいえ研修メンバー間でも進度に差が生まれるようになりました。メンバーにはパソコンを扱うのが得意な人もいますし、そうではない人もいます。この現状を見て、今回の研修ではこの手法は難しいと判断しました。ハンズオン形式であれば、各々の作業ペースで学習をしてもらうことができるので、今回の研修では最適の形式です。また、研修メンバーも 3〜4 名ほどなので、 講師 2 人でも質問対応ふくめ十分にカバーできます。
進め方にも工夫があります。これは組織の高学年で決めたことですが、研修は 2 日間連続で行ったという点です。短期間で濃度の高い研修を行うことで、研修後の達成感はもとより、集中力を最大限引き出すことができます。研修中に学んだことを忘れるといったこともあまり起きないので、短すぎず長すぎずでちょうど良かったと思います。
資料の方針
今回の研修では、手を動かしながら、段階的に技術を学んでいくことに重点を置いています。これは一般的に言うこともできますが、技術を習得するには手を動かすのが一番です。資料には解説が多くありますが、要所要所で演習を入れて実際に手を動かしてもらうようにしています。Next.js のパートでは、チュートリアル形式で簡単なアプリを資料とともに実装してもらう形になっています。
加えて、段階的という点では、資料全体をフェーズ 1 から 4 まで分割しています。各フェーズにおける内容は次のとおりです(資料より引用)。
- phase1
フェーズ 1 では HTML に入門し、HTML を用いた簡単な Web ページの作成を体験します。 - phase2
フェーズ 2 では JavaScript を勉強し、HTML に組み込んで使用する方法について学習します。 - phase3
フェーズ 3 ではこれまでに学習したことを応用し、Next.js によるモダンな Web 開発を実践します。 - phase4
フェーズ 4 では「動くもの」から「使えるもの」へを目標とし、CSS の入門や Cloudflare を用いたバックエンドの作成など、より実践的な開発手法を学びます。
一気通貫で資料を作成しても良いですが、こうすることによって目標が明確になり、学習の見通しが付きやすいという利点がついてきます。また、我々はフェーズ 1 / 2 を 1 日目、以降を 2 日目にやってもらうことを想定していたので、資料作成の点においても目標が立てやすくなりました。
資料の内容
私はフェーズ 1 と 2 を執筆したので、それらについて述べていきたいと思います。
まずフェーズ 1 では HTML について学びます。資料では一般的な HTML の構成や言語仕様、構造について述べました。このフェーズで特に意識した点は、ただ書けるだけではだめということです。よしなに HTML 要素を並べれば HTML ドキュメントは作成できますが、せっかく研修で学んでいるわけですから、そうでない要素も盛り込むべきです。本資料では、その方針のもとアクセシビリティを考慮しつつ、ドキュメントを適切に構造化できることを目標として執筆しました。世の中には無駄に div
タグが使われ、デザインのために冗長な HTML 構成になっているドキュメントが数多くあります。しかしながら、それではスクリーンリーダやリーダモード等の機能が適切に機能しない場合があるほか、不適切な構造化によって情報の検索がしにくくなる場合があります。このような HTML を記述しないようなエンジニアになってもらいたかったため、article
や section
タグなどを適切に用いることや、ドキュメントは常にシンプルであるべき旨などについて述べました。
演習では、このように適切なドキュメントが書かれている例として Yahoo!JAPAN の PC 版トップページを挙げ、この Web ページについて考察してもらう問題を作成しました。以下は問題の例です。
次の画像 Image1 は Yahoo! JAPAN の PC 版におけるトップページのスクリーンショットです。この中で article 要素、section 要素、footer 要素に該当する部分はそれぞれどの部分でしょうか。ソースコードを見ずに考えてみましょう。
また、なぜその要素で実装されているかについても考えてみてください。
フェーズ 2 では JavaScript について述べています。ここは正直世の中に数多くある JavaScript
の入門記事を読んでもらっても良かったのですが、演習がなかったりボリュームが多すぎたりするなどの点から、こちらも 1 から執筆しています。ただし、HTML のフェーズと異なり ChatGPT を用いながら記述しています。JavaScript の言語仕様は莫大で、本来ならば 1 日で学ぶ内容ではないので内容の適切な取捨選択が必要でした。その意味でも、ChatGPT に生成してもらった記事は必要に応じて加筆修正しています。また本研修の資料では、普通の入門では扱わないであろう高階関数についても述べています。これは Next.js に接続することを強く意識したもので、Next.js 等のコンポーネント指向型フレームワークで Web を開発する際には、高階関数の定義がコンポーネントの定義に直結します。このような概念にもさっと触れておくことで、スムーズなフェーズ間の接続を狙いました。
フェーズ 4
最後に、資料の目次にはあるが存在しない資料として、フェーズ 4 があります。フェーズ 4 ではメンバーの関心分野に応じて柔軟に対応する目的がありました (怠惰により資料執筆が研修前夜に徹夜で行われたためでもあります)[4]。特に今回は、CSS よるデザインコースと Cloudflare によるバックエンド構築の2つのコースを用意しました。資料を用意しなかったもう一つの目的として、自分で適切に調べながら進めてもらいたいという意図もありました。
CSS コースは幸い 1 人であったため、私がホワイトボードを用いて言語を教えつつ、ペアプロを行うことで研修を進めていきました。最後になにか作品を作ってもらおう!ということで、いなにわうどん考案の「インスタグラムのスマホ版 UI」をサポート無しで作ってもらいました。1 日で入門した割には完成度が高く、一同驚きの仕上がりでした。
一方のバックエンドコースは、いなにわうどん主導で esa[5] の API を叩いて記事一覧を表示する小さな Web アプリケーションの開発を行いました。具体的は、Next.js で開発したフロントエンドを Cloudflare Pages にデプロイし、バックエンドは Hono を中心に記事のキャッシュに Cloudflare D1、画像のキャッシュに Cloudflare KV を使用したシステムを Cloudflare Workers で動かすというシステムを開発したようです。これは今後 1 年生たちに開発してもらいたいプロダクトのプロトタイプとなるようで、やはり実戦投入されるアプリケーションの開発が題材という点では、1 年生たちのモチベーションのあり方も違うなと感じました。
フェーズ 4 のペアプロで得られた知見として、教えすぎると話しか聞いてもらえなくなり、自分で手を動かさなくなってしまう可能性があるということがありました。例えばペアプロをしている横の人が詰まっていたとき、すぐに教えるべきではないということです。すぐに教えてしまうと相手は考えるのをやめてしまい、結局意味も分からずに写経をしてしまうことがあります。このようなときはぐっと我慢して優しい目で見守り、聞いてくるまではできるだけそっとしておくことが重要だと感じました(それでも限度はあり、あまりに悩んでいるようであれば声を掛けてあげるべきです)。
おわりに
ちゃんとした研修の講師として前に立つことは初めてでしたが、それなりに良い研修を行うことができたと思います。高階が一つだけあるとすれば、研修資料を徹夜でエイヤ!と雑に仕上げてしまった[6]ことくらいです。雑とはいえそれなりに考えた良い資料になったと思いますが、もしもっと早く腰を上げていれば...という点も多々あります。
技術系の学生組織において、メンバー間の技術力の差というものはどうしても解決しきれない永遠の課題だと思います。今回の研修では、技術にそれなりに精通している人は完全に対象から外しており、初心者のみで構成されるメンバーで行いました。よく冗談で強い人はこわい[7]などど言われることがありますが、こういった現場ではほんとうに「こわい」になりかねないので、少なくともメンバーとしては参加してもらわない方向のほうが良いのかなと思いました。
今回紹介したのはあくまでも自分の組織における一例ではありますが、この記事をお読みの皆様における問題解決の道標になるようであれば幸いです。長くなりましたが、ここまでお読みいただきありがとうございました。
-
昨年できた委員会で、まだまだできたての組織。筑波大学の情報系コミュニティである UNTIL. も運営しており、定期的に UNTIL.LT などの LT 会も開催するなど活動の幅を広げている。 ↩︎
-
筑波大学学園祭実行委員会の一組織で、学祭 Web や内部者向けシステムの開発、さらには映像の撮影・制作・配信などを行う局。ご興味のある方はぜひ! ↩︎
-
当初の進め方の案としてハッカソン形式もあったが、参加人数が少ないことや、もし実戦投入するプロトタイプの開発をテーマにした場合の負けたチームのモチベ低下などを勘案して没になった。 ↩︎
-
全代会内部の資料共有に esa が使われている。 ↩︎
-
資料の反響が大きかっただけに、残念... ↩︎
-
バイト先の 2 つ上の先輩にこわいと言われてしまった過去がある ↩︎
Discussion
定着率が低い問題めっちゃわかります。
あと、なかなか本番環境で初心者が書いたコードを使ってあげられないのも申し訳なくて結局全部自分でやろうとしちゃうんですよね…