クフでダローバルな日記

タフでもグローバルもない

学科内bot作成ハッカソンを開催したので知見を共有します

「学科内 bot作成 ハッカソン」季語: ハッカソン(夏)

学科の希望者を募ってTwitter botを作るハッカソン的なものを開催しました。 ハッカソンと言っても参加者の多くは授業でプログラミングをしているくらいなので大層なものではないのですが、企画者として色々と学びや反省点があったのでノウハウの共有も兼ねてまとめます。

個人的にこれは大事だと思ったことは強調しておくので、参考にしていただければ幸いです。

企画するまで

僕の所属する電子情報工学科では、一応情報系の名を冠する学科ということもあり、学科に配属された当時から「みんなでハッカソンとかしてみたいな」的な話が一部でありました。 が、そもそも全員が実際に開発した経験があるわけではないなどの理由から特に実現することもなくその話は流れて行きました。

しかし、先学期に転機が訪れました。というのもこの学科では、実験の一環として6~7月に学科全員が2人1チームでそれぞれ独自のIP電話を(C言語で)作って発表するという恒例行事があるため、全員が一応開発経験を積むことになります。 作ったものを人前で発表するという経験は僕もなかったのですがとても楽しく、皆も楽しんでいたようなのでまたやってみようと思い、ハッカソンを企画・開催することにしました。

企画段階

参加者はtwitterや学科のslack上で募り、ある程度の人数が集まりそうだということで開催を決定しました。

googleからハッカソン 運営ガイドというものが公開されており、これを読み込むことで企画側としてのイメージを固めていきました。 ハッカソン開催を考えている人は是非読んでみることをオススメします。

教室を借りるための書類が必要だったりしてちょっと面倒だったのですが、お世話になっている先生のご協力を賜ったため割とスムーズに進みました。 開催場所は先述の運営ガイドに則り、

  • プロジェクター有り
  • 十分なコンセント有り
  • 机同士が向かい合った会議室のような部屋ではなく、一つの机に2,3人の教室のような部屋

としました。 チームで開発するハッカソンではこれらが必須条件なのではないかと思います。

準備段階

実際に準備を始めた段階で想定された主な困難は以下のようなものでした。

  1. 一日で完成させる自信のある人が少ない
  2. アイディア出しが大変そう
  3. メンターの数が少ない
  4. そもそも企画者の僕がハッカソンに参加したことがない

それぞれどう解決したかをまとめます。

一日で完成させる自信のある人が少ない

授業でC言語使った経験しかない人も多かったのですが、とにかく全員が作ってみるのが大事だと思ったので全員に完成を目指してもらうことにしました。 そのために、

  • 作るものをtwitter botに限定する
  • 言語もrubyに限定する
  • 動かすのはheroku上とする

細かい限定をかけることで、全員の足並みをそろえることにしました。 この条件は実は普段僕がbotを作る際にやっているものであり、実際に参加者が作り始める前に僕からノウハウを教えることで、スムーズに開発を開始できたのではないかと思います。

アイディア出しが大変そう

botを作ったことがあればtwitter APIを使って何ができて何ができないのかわかるので作りたいものの困難さも大雑把にイメージできますが、初めてbotを作る際には大変だろうということで、参加者への事前アンケートでアイディアを聞いておくことにしました。

その上で、回答として出てきたアイディアそれぞれに対して「自分だったらこんな感じで作る」「これはちょっと難しいかも」といったアドバイスをこちらから供給してみました。 どれほど参加者の役に立ったのかは分かりませんが、企画者が開発を始める前にアドバイスをすると開発を始めるのが楽になるのではないかと思います。

メンターの数が少ない

僕一人でメンターをするつもりだったのですが、さすがにキツそうなのでB4の先輩に手伝っていただくことにしました。圧倒的感謝。

参加人数が14人だったのでメンターは二人で何とかなりましたが、だいたい5,6人に一人くらいはメンターがいた方が良いのではないかと思います。まだ一回しか開催していないので印象でしかありませんが。

そもそも企画者の僕がハッカソンに参加したことがない

ハッカソンに参加したことがなくても、ハッカソンは開催できるという前例を作ったのでみなさん気軽に開催してみてください。先述のハッカソン運営ガイドは素晴らしいです。読み込みましょう。

開催直前〜当日

事前課題

さすがに当日だけでは間に合わなさそうなので全員に以下の事前課題を課しました。

  • 最低限の環境構築(UNIX環境)
  • herokuへの登録
  • rubyの基礎の勉強

環境構築段階ではやはり人によってはエラーが出まくっていたようなのでサポートが必須だなと感じました。 だからといって全員揃ってやっているとエラーの出た人が律速段階になってしまいがちなので難しいところです。 今回の場合はslackでエラーコードを貼ってもらいながら解決できたので、そういったコミュニケーションツールの選択も重要だと思います

herokuへの登録はまぁスムーズだったのですが、最近herokuの無料プランの使用が変更されてしまったので僕も勝手がわからないところがありました。 開催者側は最新の情報にキャッチアップしておくべきであると思います。今回の 反省点の 一つです。

rubyの基礎の勉強についてですが、やはりこれが一番の負担になっていたように感じます。全員に書籍を買わせるわけにも行かなかったのでとりあえずドットインストールを紹介したのですが、後でよく考えてみるとオブジェクト指向プログラミング等は今回のハッカソンにはオーバースペックなところがあったかもしれません。 紹介する教材選びももっと慎重にすべきでした

スライド・テンプレート・メンタリング

先述したとおり、今回のハッカソンでは僕のノウハウを伝えるべくスライドを作成したのですが、なかなか時間が取れなかったために、メンタリング段階で質問されるまで後回しにしたものも有りました。 当然ですがスライド作成は早めにやりましょう。

スライドを作る際に意識したことは

  • 難しそうという意識を取り除く
  • 皆が使いそうなものは具体的に教えてしまう(ツイートする方法など)
  • 調べ方を教える

です。伝わったかは分かりませんが。 特に3つ目の「調べ方」についてはハッカソンにかぎらず開発の仕方を教えるのであれば必須ですね。すべてを教えることはできません。

ちなみに「難しそうという意識を取り除く」ために、今回僕は「twitter botとはinput/outputのいずれかもしくは両方がtwitterであるプログラムにすぎない」という名言を生み出しました。どうぞ使ってください。

twitter botの場合は特に顕著ですが、認証部分・定期的実行などは誰でもほぼ一致するので、githubでテンプレートとなるものを公開してみんなにpullして貰う形で進めました。 自分でもこれは良い選択だったと思っています。

実際に開発が始まるとやはり同じような質問が頻繁に出てくるので、FAQをタイムリーに更新して共有したほうが良かったかもしれません。

発表

みんな時間がなさそうなので口頭での発表で済ませましたが、後々のことを考えるとその場で終わってしまうのではなく、webとかで公開できるようにスライドを必須にすべきだったかもしれません。 参加者は全員僕が想像していたよりもすごいものを作ってきたので、ただ「楽しかった」で終わるのではなく、その後に繋がるような処置をしておくべきでした。

終了後

Google先生曰く、ハッカソン後の飲み会は必須とのことです。お互いを讃え合いましょう。ちなみに僕は疲れでめっちゃ酔いました。

終了後も質問は受け付けていました。どうやらその後もbot作成を続けてくれている人も多いらしく、嬉しい限りです。

ただ、開催者側に対するフィードバックを得るのを忘れていたので、開催後すぐにでも事後アンケートを行うべきだったと反省しています。 普段授業後のアンケートとか答えるの面倒くさいと思っていましたが、開催側へのフィードバックも大切なんですね。

まとめ

  • 参加者のレベルに合わせた準備を行う
  • 開催する以上は責任をもって教える
  • 双方のフィードバックを大切にする
  • 開催するのは楽しい

参加してくれた人達と手伝ってくれた方々、ありがとうございました(o_ _)o