自分が所属する学生団体では、最初新メンバーに一定期間を使ってどのようにWeb開発をするかについて教えています。
ただ、こういったことは全国の部活とかサークルで同じように行われていることだろうな、と思ったので、自分がやってよかったこと・悪かったことなどの知見を一度まとめておこうと思います。
同じように後輩に技術について教える機会がある方は是非参考にしてみてください
教える準備・実際に教えるときの手順について
まず、どのような手順で準備をしていったかについて触れます。
ステップ1:どこまで教えるのかを決める
まず最初に、どの技術範囲まで教えるのかを決める必要があります。例えば、Webの開発を行うにしても、HTMLが使えるぐらいの知識が求められているのか、それともアプリケーションフレームワークによって開発できることが必要か、などによって教える内容が変わってきます。
そこで、最終的な目標を定めた上で、どの技術を教えていくのかを決める必要があります。
自分たちの場合、Railsによる開発ができるようになることが目標だったので、だいたい以下の様なことについて教えることにしました。
- HTML/CSS
- Ruby
- Vagrant
- Linuxコマンド
- Git
- Webのちょっとした概念
- Rails
あと、誰が教える役割を担うかもこの段階で決めた方が良いかもしれません。例えば教えるのに割く人員が2人だった場合、役割の分担をここで済ませておくと準備がスムーズになります。
ステップ2:教える期間を決める
教える技術の内容が決まったら、次はそれらをどれくらいの期間で教えるのかを決めます。大抵は夏休み前〜夏休みまでくらいの長さになると思います。3〜5ヶ月といった感じでしょうか。
自分たちは夏休みに自由課題としてRailsでアプリ(サービス)を作ることを課題にしたので、夏休み前くらいにステップ1で述べた技術については一通りおさえるようにしました。
ステップ3:教材の準備をする
教えることと期間が決まったら、次は教材の準備をします。
必ずしもすべて作る必要はないと思いますが、教える側の勉強にもなると思うのでできるだけ自分たちで作ったほうがいいと思います。自分が教えた時は作った教材もあれば、ネットで資料を探したこともあった、という感じでした。
教材の準備をするにしても、しないにしても春休みから準備ができると余裕をもって教えられると思います。自分たちの場合、春休みに多少準備はしたのですが、全部の準備は出来なかったため教えている途中は教材の準備を自転車操業的な感じで進めていったため、きつい時期もありました。
ステップ4:実際に教える
ステップ3まで準備出来たら、あとは教えるだけかと思います。以下、自分が教える時に意識してやったことをまとめておきます。
実践的な内容にする
座学というか、理論的な内容は(情報系の学校であれば)授業で習ってたりするので、この場ではより実践的な内容(自分でコードを打って何か作るなど)にするよう心がけました。
まぁ、これは教材を作るタイミングでの話であるように思いますが、教材が座学っぽいものでも「じゃあ、実際にコード書いてみようか」みたいな感じで何か手を動かすタイミングを作るようにしたほうがいいと思います。
課題をだす
学生なので学校の課題もあり大変かとは思いますが、活動時間に教えた内容の復習として次の活動日までにできる課題を出すように心がけていました。
毎日活動している団体は別ですが、活動日と活動日の間に時間が空く場合は、積極的に課題を出すようにしたほうがいいと思います。
課題の内容ですが、時間がある場合は何か作ってくるようなもの、ない場合はクイズみたいなものにしていたと覚えています。
エラーを誘発させる
Vagrantで開発環境を整える時など、サーバーまわりを操作するときはインストールや何かプログラムの実行時にエラーが起きることが多かったです。
そのエラーは、慣れたエンジニアにとってはよくあることなのですぐ直せるものだったりしますが、新メンバーにとってはわけがわからないものだと思うので、そういうものの対処法を最初から教えるのではなく、あえてエラーを起こさせて、検索などを用いてどうやって解決すればよいかを教えるようにしていました。
教えていてよかったこと・あまりよくなかったこと
次に、実際に自分が教えてみてよかったことと、「もう少しうまくできたかな」と思うことについてまとめておきます。
よかったこと
- 教える側が逆に勉強になった
- 資料を作る能力が上がった
- 何が重要かを考え、取捨選択できるようになった
やはり学生なので、技術的な知識・能力が未熟である部分も多いと思います。そのような中で、他人に教えるために教材を作ることはこれまでに自分が学んできたことの復習にもなるので、良い機会だったかなと思います。
また、教材を作成・用意する際に、どうしても時間の都合上すべて教えきれない部分が出てくるでしょう。そこで、実際に開発をする時にどのような知識が外せないか、逆にあってもあまり役に立たない知識は何か考えて準備することは難しいことでしたが、ためになったように感じています。
あまりよくなかったこと
- 教えるための準備にあまり時間を割けなかった
- 最後は時間の都合上、新メンバーまかせになった
- 予期せぬエラーに対処できなかった
完全に言い訳ですが、思いの外準備に時間がかかり、もっと時間をかければさらに良いものができるとわかりつつ、できない部分がありました。その結果、最後などは「じゃあ、あとはがんばれ」的な感じになってしまったのが残念でした。
また、起きることがわかっているエラーは良いのですが、そうでないエラーの対処に時間をかけることが多かったです。これに関しては、エラーが出たらその原因を探るのは誰か他の人にまかせ、新メンバーの教育はさっさと次に進む、などとしたほうが良かったように思います。
さいごに
個人的に、社会人になったらこういった「人に教える」機会は絶対にあると思うので、それを今のうちに疑似体験できたのは良かったな、と感じています。
人に教えることは自分で理解する以上に難しいことですが、教えたことは自分にも返ってくるので、がんばって教えましょう!