はじめに

自己紹介

名前：よつ
年齢：20（26卒、4年制2年）
所属：麻生情報ビジネス専門学校
得意：PM、バックエンドまわり
好物：コーヒー（よくお腹を壊す）
Progate Path公認アンバサダー & コミュニティ運営コアメンバー

なにしたの

所属してるクラスで、Git & GitHubの入門セミナーを開きました。

イベントは　

前説明30分
Progateによる演習60分

という構成で、先生からゼミ¹の時間を~~分捕って~~お借りして行いました。

背景

学期も後半になり、「チーム開発」が単元として出てきました。
これはその名の通り、ランダムに4~5人のチームを組み、半年間プロジェクトを運営するといった感じ。

そしてチームで開発をするわけなので、もちろんソースコードの共有も課題として挙がります。

しかし、この授業が始まった段階では、私たちはGitを習っていません。
ましてや「GitとGitHubって何が違うん？」という人が大半という始末です。
ということで、実際に開発が始まったとしても、みんなは路頭に迷ってしまうわけです。

そこに偶然、Progateの有料枠を配れる男がいました。そう、 **俺** です。

先生　「チーム開発、設計はみんな楽しそうだけど、開発が始まるとGitで詰まりそうなんよな～」
俺　　「それ、Progateで勉強できますよ」
先生　「ほなゼミの時間使ってイベント開くか」
俺　　「オ～ウ」

という流れで、セミナーを開催する運びになりました。

作ったスライド

開催しての気付き

当日は前述のとおり、スライド発表が30分、残りの60分をProgateによる自習形式で開催しました。

参加者や担任からは概ね好意的な評価を貰えたんですが、もちろんいくつかの問題点もありました。
ここからは後学のために、今回感じた課題点を、自分自身の体験も踏まえつつメモしておこうと思います。

Gitを学ぶ上でのブロッカー

コマンドベースの使い方が書かれていることが多い

一番大きいのがコレだったかも。

Gitを学ぶ上での主な問題として、

多くの情報がコマンドラインベースで提供されていること
参加者の中にはコマンドをあまり使い慣れていない人がいること

が大きいと思ってます。

特に、Gitに関するトピックはしばしばコマンドライン操作に焦点を当てているため、これが参加者にとっては抵抗があるようでした。一応、私たちは一年次でLinuxを学んでいることもあり、コマンドラインに対する抵抗感は完全な初見というわけではないのですが。
日常的に使ってないこともあり、コマンド操作に慣れている人は少なめでした。

これを考慮し、スライド作成時には例や図を多用するように意識しました。
先に作業の流れを言葉で理解し、そのフレームワークに当てはめるようにして知識をつけてもらうイメージです（あまりうまくいったとは思えませんが）。

また、実際にプロジェクトに導入する際にはGitHub DesktopのようなGUIツールを導入することを強くお勧めしました。これは前期に友人と参加したハッカソン²の反省もあります。

ハウトゥーが「エンジニア目線」で書かれていることが多い

これはGitがよい例なのですが、基本操作の用語がすでにその技術特有の概念で、用語と操作内容を紐づけて記憶する必要があります。
そのため、この前提がない状態でドキュメントを読むと理解があやふやになったり、「用語を知るために用語を調べる」みたいなよくない体験を生んでそう、と感じます。

また、多くの場合、ハウツー記事は 「エンジニア目線」³ で書かれています。これは目的を確認し、そのための手順を説明し、その手順を実現する手段をサンプルコードなどで考えを共有するといった構成。

これに対して初心者は 「ユーザー目線」 ³で話を理解しようとすることが多く、この目線の違いから、ドキュメントの理解を難しくしていることが多くある、と僕は考えています。
「ユーザー目線」というイメージをかみ砕いていえば、自分でロジックを変更したりすることなく、なるべくそのままの状態で自分の目的を実現する方法を探すような考え方でしょうか。ユースケースを抽象化することなく、そのままの形で求めているような、 「説明書」ではなく「手順書」を求めているような感じ。

これによって前提である「手順の説明」が冗長に感じ、本当に必要な情報（手段）にたどり着けなかったり、あるいは説明と手段をごちゃまぜに書いていたりすることもしばしばあり、この場合だと話全体の見通しがつけにくく、初学者にとっては読み解くのに時間がかかったりします。こういった技術記事の性質が初心者には受け付けないのかも、と思っています。
なにより「[ゲーム|Web|アプリ]を作りたいんや！」と思ってプログラミングを始めたけど、蓋を開けたらドキュメントとにらめっこする仕事だった、だとやるせないですよね。

この問題に対する自分なりの解としては「とりあえず体験してもらう」ことだと思っていて、そういう点でProgateはとてもよいサービスだと捉えています。スライドによるインプットと実践によるアウトプットが分離されてたり、体験によるフィードバックが保証されているので、置いてけぼりになっている感が少ないというか。

とにかく触って楽しむことでよい経験を積んでもらって、技術に対して興味が出てきたタイミングでドキュメントの読み方を学んでいくといいんじゃないかと思います。最近は要約してくれるAIもいますし。

使用するメリットが伝わりにくい

「ソースコードを共有する」という言葉だけでは、チーム開発未経験の場合、Gitの利点が十分に伝わりにくいです。実際、Gitの学習にはそれなりのコストがかかりますが、その学習コストに見合ったリターンがあることを直感的に伝えることは困難です。

Progate Pathの運営として初学者の方と話す機会も多くなってきてるんですが、やはり勉強のブロッカーとして「モチベーション」はあるようで。わりと冗談半分にされがちな話題ですが、実際に僕も数年前までは同じ状況でしたし、今なおモチベーションが保てなくなることも多いです。今回の話題も、そういった学習モチベーションにかかわる課題のように感じます。

今回はチーム開発があるという前提があったので比較的意欲的に取り組んでもらえましたが、ここに関しては課題が残るかな～と考えています。もっとわかりやすいユースケースを模索するべきかな、といった感じ。
一応、スライドにいくつかアンチパターンの紹介をすることで改善したつもりです。

おわりに

実はイベントの一週間前に開催が決定したり、イベントの日とチーム開発のマイルストーンが被ったこともあり、万全の状態での開催はできませんでしたが、とても良い機会にはなったかなと思います。
僕たちはまだ設計などを学んでおらず、これから難しい概念を学ぶ機会も増えていくかなと思うので、こういった機会をまた設けたいな～と思います。設計の話とかしたい。

ここでの「ゼミ」とは、クラスごとに毎週一時間ある、各クラスの活動に割り当てられる自由時間を指します。今まではアイスブレイクのボードゲーム、時間が足りないコマの課題を解く時間、先輩によるセミナーなどに使われてきました。 ↩
[技育CAMP vol.7] ふりかえり　を参照。 ↩
ここに関しては自分なりの表現なので、よりよい表現がありそうな気がしています。コメントで意見などいただけるとうれしいかもです ↩ ↩²