2020年総括

2020年の初めは, ほとんど一科目も落とせないような緊張感のある期末試験からスタートした. と同時に大学入ってからおそらく最も真剣に学問に取り組んだ. 昔の頭の良い人たちはこのようなことを考えて, 理論を確立して応用させてきたのだなぁと少し感慨深い気持ちになったのを覚えている.

GeekSalonとの出会い
1月に大学生向けのプログラミングコミュニティのGeekSalonに入会し, プログラミングでアプリ制作に励んだ. 大学1年の頃に没入していたサークル活動を辞め, 授業とバイトと少しの遊びしかない大学生活に, ハリがなかった. 無意識に成功体験を渇望していたような気がする. 久しぶりに自分の作品を作る楽しさを感じた瞬間だった. そのままメンターにならないかと誘われた.

GeekSalonのWebメンターへ
もともと受講生の頃からメンターは面白そうだなぁと見ていて思っていたが, 自分の過去の経験から生じる心理的な壁に囚われることもしばしばあった. 日本の場合, 顧客が非常に高い満足を得るような状況は往々にして働く人たちの弛まない努力, 言葉を変えれば犠牲によって成り立っている側面があるので, それが少し重なって見えてしまった. (昔入っていた部活やサークル, バイトで過剰なレベルを要求するパワハラに近い現場を何度も見たり遭遇してきたこと. 中国では皆8割くらいで肩の力を抜きながらまったり生きる文化があり, それと過度に比較し過ぎていたことが当時の心境としてあった)
メンターにならないかと誘いの声をいただいた瞬間は非常に嬉しかったのと同時に, 裏側があまり見えない不安も多々あった. 特にメンターになるタイミングは緊急事態宣言で完全オンラインだったので尚更であった. しかし, メンターみんなが前向きに生きているような様子や, 楽しそうな素直な表情を見て, 安心してメンターになることを決めた.

最初の一か月は色々な先輩に頼りながら,とにかく分からないことをすぐに聞いて解消するような日々を送っていた. 完全オンラインだったので, 初の説明会やイベント等はかなり緊張したのを覚えている.今年新1年生や新卒社会人になった人たちはこれ以上に大変な思いをしているんだぁということを慮った.

そうこうしている内に, ぼちぼち現場に行って交流する機会が復活していくと, 逆説的にその良さを知ることになった. (風邪を引くと予防の大切さを実感するような). また, もともと文章を書いたり体系的にまとめて伝えたりするような営みが好きだったのもあり, Qiita記事を色々書いたりしていた.

その流れで, Webコースの教材は問題が山積しているなと受講生の段階から密かに思っていて, それらを変えたい思うようになった. 誤解を生みそうな記述, 流れが良くない所, みんな実装するのに一般の記事頼りになってしまっている箇所, 教材通りに実装すると100%エラーが生じる箇所,それらがいくつもあり, それに対処する受講生の時間と, 対応するメンターの時間がかなり割かれていると感じた. そのような問題を未然に防ぐように教材を書き換える動きがあまりないのはなぜだろう？と当時は不思議に思っていたが, 個人的には非常に根幹となる大事な部分だと思ったので, 大胆に書き換えていった. もちろん今まで教材の土台を作ってくれた先人たちの意志を引継ぎ, よりグレードアップしてどこからも不満が出ないようにという目標を抱いた. 同時にどうしても教材のInputのみでは賄いきれない部分をゼミとして実施し,そのコンテンツを作成していった.

教材に関しては細かいところまで挙げるとキリがないが, 大きく以下の改編を行った.
①6-3(オリジナル開発初期手引書)の作成
②ログイン機能, アソシエーションに触れるタイミングを企画面談前に移動し必修化
③Resources記事, ユーザーマイページ記事, 編集権限記事の作成
④リリース記事, 環境構築記事の確立
⑤3-7にてmigration操作をより実践的な記述へと変更

①に関して, これは当時, 企画面談後オリジナルアプリ開発に入るタイミングでスピードダウンする受講生が多いという問題があった. 当時はオリジナルアプリの開発は3章を参考に進めていくのが定石であった. 例えば, 初学者にとってはボリューミーで理解がままならない部分も大きいことはあるのだが, 3章を読みながら投稿機能を一通り作成するのに1~2週間かかるのが当たり前で, その過程で様々なエラー(ルーティング等)や, 無駄な作業(必要ないのにhelloコントローラーを作ったり, Tweetモデルを作ってしまったり)が横行していた. ここで調子を落とし, C層や離脱の要因になったり, そのC層を救うべく, 応用して作成するポイントをメンターが逐一手伝ったりする雰囲気があった. これを変えるべくして作成したのが6-3(オリジナル開発初期手引書)である. オリジナルへの応用を念頭に置き, 必要なポイント, 情報への動線を敷いた. これにより, 投稿機能の作成が数日で終わるようになり, 過不足のないプロダクトの割合が高まったように思う. (余計なものを作って残したままにしておくと, 後々リリースのタイミング等で困ることがある) 
②に関して, ログイン機能とアソシエーションはもともと追加教材の中に位置づけされていた. この改修は6-3がユーザーモデル(ログイン機能)を必ず最初に作るように書いていることと関係している. ユーザーモデルを最初に作っておかないと, migrationエラーに見舞われる可能性が高まってしまう. 例えばリリースするときはmigrationファイルを基にデータベースが構築されるが, 投稿やコメントテーブルでuser_idカラムを外部キー制約やアソシエーションを定義された状態で先に作ってしまうと, relation users does not exit(usersテーブルが無いよ)と怒られてしまうのである. そうすると, オンラインで口頭でかなり複雑なコマンド操作やmigrationファイルの書き換えを指示しなければならず, 非常に多くの労力が投下されてしまうことになる. これは特殊なものでもなく, 何件も同様の事象が発生していたため, 根本から未然に防ぐべく, 変えねばならないと思った. そこで6-3にてユーザーモデル最初に作成し, そのためにはログイン機能やアソシエーションをオリジナル開発に入る前に触れる必要があると考えるに至ったのである.
③に関して, これらは受講生ほぼ全員がつける機能なのに一般の記事頼みになっている現状があった. そうすると, 一般の記事のここは正しくてここはこう書いて！のように余計なコミュニケーションが発生していたので, GeekSalonWebコースの文脈に合わせて作成する必要があると感じた.
④に関して, 当時はwindowsユーザーはリリース記事の通りに実行すると100%エラーに見舞われるという現状があった. これは, おそらく, もともとmacの知見が中心でwindowsの知見があまりなかったことと,(windowsユーザーは教材と異なる可能性があるという注意書きが昔からの教材中に書いてあるので), バージョンが変わって仕様が変わったことが影響していると思う. 具体的にはwindowsユーザーはgitを入れずにrails newすると, リリースする際にgitignoreされるべき.bundleファイル(without production)が送られてしまうことがリリースエラーの原因になっていた(所謂gem pg問題). macはデフォルトでPCの中にgitが入っているのでこの問題は生じないというカラクリだ. 当時, この問題を内包していたリリース記事を使うリリースdayを迎え, 一人でwindowsユーザー6人を口頭で注意事項を述べながら対応したりしていた. これを踏まえ,もっと効率よくできないかな？という気持ちが教材改修へ加速する燃料となった. 実はwindowsのこの対応を教材中に書き加えたのが教材改修デビューであった. 環境構築記事や, リリース時のエラー対応の記事も様々な対応の知見をまとめて共有することで,  メンターによる知見の格差(知っているメンターに過度に負担が行ってしまったり, メンターによって解決に差が生じたり)を無くすという意義もあったりする.
⑤に関して,当時3-7はカラムを持たない空のTweetモデルを作成し, カラムの追加をaddコマンドで行うという流れで記述されていた.この影響で, オリジナル開発においてもまず空のテーブルのみ作成し, カラムを一つ一つaddコマンドで追加していって,migrationファイルが20個以上できてしまうことが頻発していた. そうするとmigrationエラーが生じる可能性が高まる上に, 一度そこでエラーが生じてしまうと, その箇所を特定するのが非常に困難(オンラインであれば尚更)になってしまうという問題が生じていた. そのため, 6-3とも合わせて, モデル作成ではカラムも一緒に作る記述に変えた. これにより上記のような現象はあまり見られなくなったように思う.

ゼミに関しては, 主に基本的な機能の仕組みやMVCの理解に重点を当てたMVCゼミと, migrationコマンドの練習とオリジナル開発のリハーサルに焦点を当てたデータベースゼミのコンテンツを作成した. MVCゼミはもともと自分がメンターになる前から存在していたが,データベースゼミは私がゼロから考案し, 作成していった.
MVCゼミは当時, MVCの流れを理解することに焦点を当てていたものの, 3章の理解(コードの意味等)を醸成するには至っておらず, 実効があるか疑わしい内容であった. そこで, 他のメンターが3章チェックポイントを考案していたのをヒント(3章はボリュームが多く何が大事が分かりにくいところがある)に3章理解クイズを作成した. このクイズに理解できれば, 3章の内容理解は概ね大丈夫という内容に仕上がり, 受講生のアンケートを見ても「理解できていない部分が浮き彫りになって良かった」のような声が多く, とても満足している.
データベースゼミに関しては, 当時migrationコマンドの操作方法の理解が不十分でオリジナルアプリ開発の初期足を引っ張ってしまう要因になっていたこと, アソシエーションの理解が不十分で, これに自力でエラー解決できる受講生がほぼ皆無だったため, 毎回ゼロからアソシエーションの説明をして対応するような雰囲気があった. これらの問題を解決すべくデータベースゼミを作成した. 上記の問題はかなり大きいissueだと思って訴えていたが, 実はなかなか賛同の意志を表明してくれる人が少なく不思議に思っていた. 最初はゲリラ開催からスタートした. そして徐々に定着していった. しかし, 2時間のパッケージで開催する場合, migrationコマンドの練習とアソシエーションの理解の両方を含めるのは二兎を追う者は一兎も得ずになってしまうのでは？という懸念があった. 確かに受講生のアンケートを見てみると,「難しかった」という声が多かったため, 取捨選択でmigraionコマンドの練習に焦点を当てたコンテンツに変更した. それ以降はアンケートを見ても非常に良い結果が出ており, 実効のあるゼミとして価値が生まれているように思う. またアソシエーションの理解に関しては, エラーが出ないように未然に防ぐように気を配って教材の記述を改修しているので,そもそもエラー自体があまり起きないようになっている. 私自身,アソシエーションを初めて納得して理解した瞬間が`受講生の3か月の終わり頃だったため, 今はここを全員に深く理解してもらうのは負担が大きすぎるかなと思っている. 教材中にある最低限の記述に頼り, それ以外は観念しているところがある.

もちろんGeekSalonのメンターとして他にも色々なことに取り組んできたが, 自分を代表する取り組みとしてはtech系の改修や作成だと思ったので, これらに焦点を当てて書いてみた. 根本的な理解の醸成を後押しし,スムーズなオリジナルアプリ開発への動線を敷き, 3か月を通したストーリー(環境構築がリリースエラーの原因になっていたりすることも)の視点で教材は今かなり良いクオリティに仕上がってきているように感じている. 確かに教材のボリュームが多くて大変という懸念もあるが, これらに触れていかないと,いずれにせよオリジナル開発やリリースでエラーの原因になったり向き合わなければならない要素であるので, 仕方のない側面もある. しかし, 技術的にこれだけ多くの要素に触れて学べる3か月間(HTML,CSS (JS), Ruby, Rails, データベース, (SQL), クラウドサービス)もなかなか機会が無いので, Webコースの卒業生は完全に初心者から逸脱して, ITを学び続けていく土台や素養として血肉になっていると思う.

次は, デザインの実装にスピードダウンしてしまうという問題が生じている. また, エラー対応の立ち回りが分からず, せっかくの成長の機会を逃してしまっているなぁと感じる瞬間が散見されているような気がしている. なので, これらの問題に対処することが今後の自分がやるべきことの一つとしてあると思う.