注意：長いです。全体としてはキレイにまとまりませんでした。（途中で雰囲気が変わる。）個々の話題で気になるところだけ参照するくらいがよいかもしれません。
前提
2015年6月6日から2015年7月12日の間に2015年のSEゼミが開催されました。SEゼミは学生と企業のマッチングを支援する企画で、複数の学生向けイベントで構成されています。クリアコードはソフトウェア開発とフリーソフトウェアのサポートが主な仕事内容で、学生と企業のマッチングの仕事はしていませんし、イベント開催や講演も機会があったり必要に迫られるとやる、くらいです。
そんなクリアコードですが、2015年のSEゼミでは次のように3/4のイベントのコンテンツ作成とイベント当日の進行をしました。
-
- 2015年6月6日開催 - コンテンツ作成・進行
-
- 2015年6月20日開催 - 関わっていない
-
- 2015年6月27日開催 - コンテンツ作成・進行
-
- 2015年7月11日、12日開催 - コンテンツ作成・進行
なぜコンテンツ作成と進行をしたかというと、SEゼミを企画しているSEプラスさんから「今年はOSS開発をテーマにしたいのです。協力してもらえませんか？」と打診を受けたからです。クリアコードが大事にしていることの1つは「ユーザーが自由に使えるソフトウェア」です。SEゼミの企画を通じてOSSの開発に参加する人が増え、さらに、OSSの開発に参加しているという活動が評価される社会に近づくことは、クリアコードが大事にしていることに通じます。そのためSEゼミをお手伝いすることにしました。
このように、普段はイベント開催やセミナー、学生向けのなにかなどをしていないソフトウェア開発の会社が学生向けのOSS開発をテーマにしたイベントのコンテンツを作成・進行する中で得られた知見を記録しておきます。もしかしたら、同様のイベントを開催するだれかの参考になるかもしれません。それぞれの知見は関連していないことが多いので、部分的に参考にすることもできるでしょう。
方針
SEプラスさんから依頼を受けたときに、一緒に方針を検討しました。
普段は学生との接点もないですし、学生と企業のマッチングの経験もありません。クリアコードの採用情報ページを見てもらうとわかりますが、学生向けのなにかを用意したりしていませんし、世間での一般的な採用プロセスもやっていないので、採用に関するノウハウはありません。そのため、セオリー通り（？あるのかどうかもわからない位の知識ですが…）のマッチングイベントのコンテンツにすることは諦めました。
そうではなく、学生も企業もSEプラスさんもクリアコードもうれしくなるコンテンツにできないか考えました。そのため、まずはそれぞれがどうなるとうれしくなるか考えました。
-
学生 - 自分が興味のある（必要だと思う）知識が増える。
-
企業 - 一緒に働きたい学生と接点ができる。
-
SEプラスさん - 学生と企業のマッチングの「よい」機会を提供する。
-
クリアコード - OSSの開発に参加する人が増える。OSSの開発が評価される社会に近づく。
これだけ見るとみんながうれしくなりそうには見えません。
学生は就職に興味があるかわからないので、企業との接点がうれしいかどうかはわかりません。
企業はどうやって「一緒に働きたいか」判断すればよいのかわかりません。
学生と企業のマッチングの機会を提供しただけで、マッチする人はほとんどいませんでした、となってはSEプラスさんもうれしくありません。
そこで出てきたのが次のアイディアです。
学生がOSSの開発に参加することを段階的にサポートする。サポートするのは企業の現役エンジニア。
学生に「OSSの開発に参加しよう！」と言っても敷居が高く感じられて集まらないだろう。そうすると企業は学生と接点を持てない。それならば、OSSの開発に必要なことを順に学べるようにすれば敷居を下げられるのではないか。
企業でOSSを使うことは当たり前になり、企業にとって重要なところにOSSを使っているケースも増えている。今はまだOSSの開発に参加していないとしても、「OSSの開発に参加しよう」という気持ちを持って学ぼうとしている学生は企業にとって「一緒に働きたい」可能性が高いのではないか。
ただ、企業としては、将来性を含めて一緒に働きたい学生を見極めることは難しい。どうすればよいか。企業のエンジニアが学生と一緒に開発をし、考え方や問題にぶつかった時の対応、アドバイスを受けた時の反応などをみることができれば、それらはよい判断材料になるのではないか。
OSSの開発に参加する学生が増えればクリアコードはうれしい。
よし、学生と企業のエンジニアがOSSを一緒に開発するコンテンツにしよう。これなら、みんながうれしくなりそう。
ということで、「学生がOSSの開発に参加することを段階的にサポートする。サポートするのは企業の現役エンジニア。」という方針にしました。この方針だと次のようにみんながうれしくなりそうだからです。
-
学生 - 自分が興味のある（必要だと思う）知識が増える。
- → 少しでもOSSの開発に興味がありそうな学生ならOSSの開発に参加できるようになる。
-
企業 - 一緒に働きたい学生と接点ができる。
- → OSSを使っている企業ならOSSの開発に興味がある学生は一緒に働きたい人である可能性が高そう。一緒に開発することで必要な判断材料を集められそう。
-
SEプラスさん - 学生と企業のマッチングの「よい」機会を提供する。
- → OSSを軸にした「よい」機会を提供できそう。
-
クリアコード - OSSの開発に参加する人が増える。OSSの開発が評価される社会に近づく。
- → OSSの開発に参加する学生が増えそう。企業がOSSの開発に参加していることを評価することにつながればもっとOSSの開発に参加する人が増えそう。
この方針に沿ってコンテンツを決めました。
コンテンツの作成とイベント当日の進行をすることでいろいろ知見が得られたので紹介します。
コンテンツの質の違い
「OSSの開発に参加する」というOSS Hack Weekendというイベントの前に、OSSの開発に必要な知識を提供する次の3つのイベントを開催することにしました。最初にSEプラスさんと相談していた時点では、このくらいのざっくりとしたことしか決めていませんでした。
-
リーダブルコード勉強会 - OSSを改良・修正したコードをプロジェクトに送るときに「開発者」にとってリーダブルなコードを書けるとよさそう。
-
GitHub勉強会 - 最近はGitHubを使って開発しているOSSが多いので、GitHubの使い方を知っておくとよさそう。
-
OSS Hack 4 Beginners - OSSの開発に参加したことがない人に「参加方法」を教えたほうがよさそう。
イベントページに載っているタイムテーブルはこの頃のざっくりをベースにしたもので、最終的なタイムテーブルは少し違うものになっています。（GitHub勉強会については関わっていないのでわかりません。これ以降の話は、GitHub勉強会以外の話です。）
ただ、目指す方向はこの頃と変わっていません。OSS Hack Weekendも方向は変わっていません。
このときは意識していなかったのですが、イベントのコンテンツの「質」は事前のイベントとOSS Hack Weekendで違いました。事前のイベントは「みんなが同じ課題を使って学ぶ」コンテンツで、OSS Hack Weekendは「それぞれが別の課題に取り組む」コンテンツです。今回はやってみるまでこの違いの影響がわかりませんでした。やってみて初めてやり方を変えた方がよいことに気づきました。
やり方の変え方のポイントは「全員に説明が届く」ことを前提とするかどうかです。
「みんなが同じ課題を使って学ぶ」コンテンツ
「みんなが同じ課題を使って学ぶ」コンテンツは全員が同じタイミングで同じ作業をします。それぞれで多少のズレはありますが、同じと考えて問題ないレベルです。
このコンテンツの場合はある程度「全員に説明が届く」ことを前提とすることができます。
「全員に説明が届く」ということは、進行しながら次のことを実現できるということです。
-
次に何をやるか細かく区切って説明できる。
- 課題としてA→B→Cをやるときに「まずAをやりましょう。やり方は○○です。どうぞ。…みんな終わりましたね。では次はBをやります。やり方は○○です。どうぞ。…」ということができるということです。
-
なぜこれをやるとよいかという背景やねらいをていねいに説明できる。
- 全員の状態が同じなので「みんなが今やった課題は○○という理由でよいからやりました。次の課題の△△は××という理由でよいのでやってみましょう。」と説明できるということです。状態がずれていると抽象的な話や特定の人向けの話しかできません。
↑は学生向けの話ですが、最初の「次に何をやるか細かく区切って説明できる」はメンター向けにも当てはまりました。
今回は、メンターが20人から30人もいました。数人なら事前に進め方や大事なことを具体的に共有して、イベントの最中は学生向けの説明だけにする（必要なら個別にメンターに伝える）、ということもできます。しかし、20人から30人いるとそのようなやり方はできません。
そのため、メンターのうち、事前に伝えられる人には「方向性」だけを伝えて後はいい感じに動いてください、詳細はイベントの最中に学生向けの説明と一緒に説明します、というやり方にしました。「全員に説明が届く」ならこのやり方でもうまくいきました。
なお、「方向性」は「答えを教えない。考え方を伝えながら一緒にやる。」でした。これは、学生が考える機会を奪わない・考え方を知った方が後でもっと役に立つという学生のためでもありますが、学生が考えるところに立ち会うことがメンターの判断材料になるのではないかという期待からでした。
一部のメンターには想定外のよい効果があったようです。自分が無意識のうちにやっていることを言語化するきっかけになる、ということです。
「それぞれが別の課題に取り組む」コンテンツ
「それぞれが別の課題に取り組む」コンテンツでは最初と最後以外「全員に説明が届く」ことを前提とすることができません。
イベントの途中ではそれぞれで取り組んでいることも違いますし、直面している課題も違います。自分の作業に区切りがついている人もいれば、そうではない人もいます。つまり、次のような状態になります。
-
全員にとって有用そうな内容は薄っぺらいものしかない。
-
区切りがついていない人は説明を聞くより作業を続けたい。
これに気づいていなかったので、OSS Hack Weekendではよく知らないプログラムの直し方を説明してしまいました。この話は「今」問題を調査している人には有用な話題でしょうが、そうではない人（これから問題を調査する人も含む）には有用ではありません。「今」必要ではないからです。また、説明を聞く準備ができていない人（作業を進めたい人）もいます。（1日目でこれに気付いたので、2日目は「全員に有用そうな説明をする時間」をなくし、イベント進行だけにしました。）
そのため、「全員に説明が届く」ことを前提とできない場面では、説明はなるべく少なくして、その分、それぞれが課題に取り組む時間を増やした方が有効です。問題にぶつかったときに個別に説明する方がよっぽどその人に説明が届きます。
OSS Hack Weekendでは「ミニガイド」という聞きたい人だけメンターの説明を聞くタイミングがありました。「全員に説明が届く」ことを前提とできないケースでは、個別の説明とミニガイドの組み合わせは有用でしょう。ただし、個別の説明をするためには今回のように参加者数に対してメンター数がそれなりの人数（今回は参加者約40名に対してメンター約30名）いないと成り立たないでしょう。
なお、説明が届かないのはメンターにも同じことが言えます。そのため、イベントを進行しながらメンターに進め方を説明しなくても進められる方法が必要です。
今回はイベントの内容をシナリオとして事前に文書化していたのですが、それを共有して随時参照してもらうのがよいかもしれません。ただし、今の内容よりもメンター向けの記述をもっと増やす必要があります。
不安を解消するためのコンテンツ
2015年のSEゼミを通じて新しい発見だったことの1つは「OSSの開発に参加していない理由は漠然とした不安があるから」です。「参加してみたいと思っているなら手を動かしてみればいいのになんでやらないんだろう」と不思議でしたが「漠然とした不安」があるという理由だとは予想外でした。
「OSSの開発に参加しよう！」というイベントを開催するときは「漠然とした不安」を解消するケアをするとよさそうです。なお、学生は「OSSの開発に参加しよう！」という響きで「敷居が高い」と感じるらしいので、その敷居を下げるケアもすると参加者は増えるかもしれません。ちなみに、今回のSEゼミでは響きの敷居を下げることはしませんでした。今回のSEゼミに参加した学生の中には、参加する前は「OSS」はなんの略だろう、オープンソース…最後のSはなんだろう、というくらいの認識だった学生もいました。そのくらいの事前知識の人が悩みながらも参加しようと思える、くらいの敷居が今回のSEゼミだったようです。
「漠然とした不安」を解消するために、「やり方を教える。練習場所を作る。やってみてもらう。」という方法が有効であることがわかりました。これは他のときでも使えそうです。
具体的にどうやったかはSEゼミ2015 - OSS Hack 4 Beginnersを開催を参照してください。
学生は素直で自分で考えて説明することができる
SEゼミに参加した学生が特別なのか、多くの学生がそうなのかはわかりませんが、少なくともSEゼミに参加した学生たちのうち、個別に話した学生はみな素直で、自分で考えることができ、さらに自分が考えていることを説明できる人たちでした。
どういうことかというと、メンターからの新しい考え方を受け入れ、それに基づいて目の前の課題について自分で考えて、その場でいま自分がどう考えているかを説明できる人たちばかりだったということです。
イベントでは毎回新しい考え方を伝えるようにしていました。全体向けでの説明でもそうですし、個別の説明でもそうです。そして、新しい考え方を伝えて、今の場合だとどうなる？と聞くと、すぐにその考え方に基づいて自分で考え、それを口にしてくれたのです。
これは、社会人でも難しいことだと認識していたのですが、SEゼミに参加した学生（のうち少なくとも個別に話した学生）はみなできていたのです。（将来が楽しみです。）
そのため、「新しい考えを抵抗なく理解できる」、「自分で考えられる」ことを前提のコンテンツにしても問題ないでしょう。
事前準備を手伝ってあげればあとは自分でOSSの開発に参加できる
OSS Hack Weekendでは「難易度の低そうなOSS」ではなく、「自分が開発に参加したいOSS」を開発対象にして開発に参加しました。ソースコードが多いOSSもあれば、難易度の高いOSSもありました。それでも、多くの参加者はOSSの開発に参加できていました。
事前のイベントで必要な知識を伝え、実際に経験したあとなら、「自分はできるわけない…」と思っていた学生も「自分が開発に参加したいOSS」の開発に参加できることがわかりました。未経験の学生がOSSの開発に参加する！というイベントは決して無謀なイベントではありません。うまくやれば成り立つイベントです。SEゼミで使った資料はだれでも自由に使えるように公開してあります。OSSと同じように資料を再利用することもできますし、資料から学ぶこともできます。参加者からのアンケート結果も公開しています。（例：OSS Hack Weekendのアンケート結果）
注意点は「必要な知識」をきちんと伝えることです。例えば、「ドキュメントの改善も立派なコントリビュート」ですし、「コードのコントリビュートだから偉い、ドキュメントだからまだまだだね、ということはない」とかそういうことです。学生にインパクトのある印象を持ってもらうために「有名プロジェクトにコミット！」とか「インターネット上で激しい議論！」とか華々しい話ばかり伝えたくなるかもしれませんが、たとえ地味でも、実際に開発している人目線の地に足の着いた知識も伝えてあげてください。OSSの開発は小さなことの積み重ねがたくさんあって成り立っているのですから。
OSSの開発に関して伝える大事なことは「楽しむ」だけでよい
当初はOSSの開発に参加する理由に「実用的なメリットもあるよ」ということも入れていましたが、最終的（OSS Hack Weekendの2日目）には「楽しむ」だけにしました。楽しむことができたなら、そのあとどうするかは学生がそれぞれ判断できます。コンテンツ作成側は、学生が「自分が開発に参加したいOSS」を選んで、そのOSSの開発に参加することを支援する機会を作って、実際に開発を「楽しむ」ことが大事だと伝えるだけで十分でした。
実は、楽しく開発することはクリアコードが大事にしていることです。学生向けだからとムリに噛み砕こうとせずに、そのまま伝えるだけでよかったのでした。
外部から学生のモチベーションを操作しようとしなくても、実際に体験することを支援すれば、学生は自然と自分の意思で行動するようになるでしょう。
なお、「楽しむ」は学生だけでなく、メンターにとっても大事そうです。学生もメンターも「楽しむ」ことができるコンテンツを目指すとよさそうです。「答えを教えない」という「制限」を加えつつも「あとは自己判断でいい感じにお願いします！」と自由に動いてもらったり、「一緒に開発する」機会を増やすとメンターも楽しめるコンテンツになりそうです。
メンターを集めることは大変
今回は非常に多くの優秀なエンジニアがメンターとして参加しました。2015年のSEゼミでやったやり方は、より多くの学生を集める、という方向には向かえないやり方です。学生の数が増えるほどメンターの数も増える必要があるからです。
企業の方の何人かに「今回のイベントはよかったので、年に2回やりましょうよ」というフィードバックをもらいましたが、これだけのメンターを集めることは難しいため、今回のコンテンツを今回の規模で何度も開催というのは難しそうです。
ただ、多くの複数の企業のエンジニアが同じイベントでメンターをする機会は貴重なので、このようなスタイルが今回よりもカジュアルに実現できる世界は楽しそうです。
まとめ
2015年のSEゼミが終わったので、そこで得られた知見をまとめようと試みました。全体としてキレイにまとめようと試みましたが、全体のまとまり感は作れず、個別の知見を列挙する形になりました。
参加した学生のみなさんはこれからも楽しくOSSの開発に参加してください。メンターのみなさん、また機会があったら楽しく協力してください。
