はじめに（本記事の目的）

12/8（土）、12/9（日）の週末にハッカソンを開催しました。

自分自身初めてのイベント主催で色々学ぶことなどがあったので、今後似たようなイベントを開催する人へ感想、反省などをまとめておこうかと思います。

特に、

• 初心者の参加も歓迎した
• オンライン参加を可能にした
  
• 主催者も１参加者としてチームメンバーとして参加した

という面では少し特殊だったと思いますので、似たような状況のハッカソンを考えている人の助けにはなるかなと思っております。
（ちなみに自分は、ハッカソンに参加したことすらありません。）

概要

普段一緒に活動しているエンジニア仲間たちと「そろそろハッカソンみたいなのやりたいよね」という話が上がり、テーマ「クリスマス」使用技術「Watson API」という縛りの元16人でのハッカソンをやることを決定しました。

参加者の募集はイベント3週間前に始め、1週間前には定員の16名になりました。
そのうちオフライン参加者が11人、オンライン参加者が5人でした。
言語はPythonで統一し、チームは技術レベルが均等になるように分けようと思ったのですが、Ruby on Railsしかできない人が2人いたので急遽Ruby on Railsチームを１つ作りました。他4チームはPythonチームとなりました。

会場は、サポーターズ（渋谷）さんの会場を無料で２日間借りることができたのでそこを使わせていただきました。

当日の流れ

１週間前に参加者が揃った段階で、参加者用のLINEグループを作りそこで事務連絡は済ませておいたので、当日新たに説明するような事務連絡はほとんどなかったです。

知的財産権に関する規約はハッカソン／メイカソン参加同意書および終了後の確認書を元に作成しました。

具体的には、

初日
9:30：現地集合（オンライン組はDescordでビデオ電話開始）
9:40：自己紹介、知的財産権等に関する再確認、テーマの確認、チームの確認、タイムスケジュールの確認
10:00：各チーム作業の開始
23:00：会場締め出し
翌日
9:00：会場使用可能（各チーム好きな時間から集まって作業
18:00：作業終了。プレゼンの開始
19:00：審査員総評、結果発表
19:30：懇親会
21:00：解散

という流れで、それぞれの時間配分的には十分だったかなと思います。
（懇親会の時間もこれくらいでちょうど良かったと思っています。）

自分のチームの流れ

全体の「良かった点」「反省点」を述べる前に自分のチームの開発の流れを整理しておくと、自分のチームでは、

初日
午前：それぞれアイデア出し（合計20個くらい）、メンバー投票（5個抽出）、リサーチして優先度決め
12:00：ランチ
14:00：優先度の１番高いものの開発開始
18:00：無理そうだと判断して、優先度の低いアイデアに変更、開発開始
22:00：明日の予定確認して解散
2日目
午前：おのおの作業
14:00：branchをマージ（色々トラブル発生）
15:00：修正作業
17:30：動くものの完成、デザインの磨き
18:00：発表

結果、見事自分のチームは投票の結果１位を獲得し、見事賞品を得ることができました！
（自分で開催しているのですごい自作自演感出てしまいましたが。。。）

良かった点

それでは、運営者として参加者として含め、全体的に感じた良かった点をまず列挙していきます

事前に重要なことは整理して公開してたのよかった

イベント一週間前に、知的財産権に関する取り扱いについてや、テーマなどに関する発表をして質問を受け付けていたので、当日参加者から質問が出ることなくスムーズに進んだのが良かったと思います。

チーム発表についても、会場で発表するのではなく当日の朝にLINEグループ内で発表しており、チームリーダーも決めていました。

本番まで情報を焦らしておくと、結構重要なことを伝え忘れたりしたときに取り返し月無くなったりするので、チーム以外は焦らさずどんどん公開していくが良いと思います。

オンライン参加可能にした

今回はオンラインでの参加を可能にしまいした。

後日ヒアリングをすると、ハッカソンや勉強会のイベントはだいたいオフラインのみなので地方組的にはこういったイベントは嬉しかったという声をいただけました。
自分のチームにも１人オンライン参加者がいましたが、作業を一緒に進める上で特に致命的なトラブルなどはなかったかと思います。（初心者がオンライン参加になるとすぐ質問できなくて辛いかも、、）

アイデアの撤退スピード

次は、参加者としてですが、アイデアを撤退するスピードが自分のチームは早くてこれがよかったかなと思っています。
1,2時間リサーチをした結果、どこにも学習データがない or 軽く作ってみた結果思ってたのと違ったなど、が発覚した時はすぐに会議して、「じゃあ諦めて変えるか」と２回ほどアイデアを変えました。

変にこだわって、最後に詰まることがなかったので良かったです。

iPadPro活躍

自分は普段iPad Proをもっているものの移動中にKindleを読むために使えば良い方という使い方だったのですが今回はめちゃめちゃ活躍しました。
まずは、オンライン組とのやりとりなのですが、基本ipadを横に立てておいていつでもDiscordで（ビデオ）電話ができるようにしていました。
PCで電話繋げると、作業スピードが遅くなったりしてしまうので、電話用のデバイスと作業用のデバイスを分けられたのは良かったかと思います。

それと、なかなか全体の作業の流れや感性イメージを言葉で伝えるのが難しい時に、ipadに絵を書いて伝えるなどができたので良かったです。

反省点

次は、反省点です。

Railsチームの不服感

今回は参加者の中にPythonよりRuby on Railsの方が得意という方が何名かいたので、Ruby on Railsチームを１つ作ったのですが、「Watson API」を使うという技術制限とかなり相性が悪かったようです。

加えて、実際実務レベルの参加者はそのうち1人のみで、ほとんどその人が開発をしたらしいです。。

言語ができるできないだけでわけてしまうと、できるの中でもレベル差があることを考慮できないので、それなら即興でつくるよりもきちんとレベル選定をするかもうPython統一にしてレベル均等にした方がよかったと反省しています。

運営が全くできずゲストさんに迷惑をかけてしまった

主催者が参加者として参加する場合、プレゼン前の会場設備や外部からのゲスト（審査員）さんたちへの対応ができません。
せっかくお呼びしてきていただいたのに、直前まで自分のチームの開発の方をやり、全然対応できなかったのは反省です。

部屋が狭かった

今回は、10人部屋と8人部屋をそれぞれ借りることができたのですが、10人部屋に3チームとかで作業していたので、アイデア出しの時には近くで作業しているチームにアイデアがめちゃめちゃバレてました。笑

理想は、各チームごとに小さい部屋を使用できれば良かったなと思っています。
それか、BGMでも会場に流せば良かったのかもしれません。
(他のハッカソン会場ってどうなってるんですかね。。。。)

最初からSlackで全体グループ作ればよかった

なんとなく、今回参加者のグループはLINEで作ったのですが、それぞれのチームごとのprivateチャンネルをその場で簡単に作れるSlackで最初から参加者全体グループを作れば良かったなと思いました。
（有料版じゃないとグループ電話はできないので、そこまでできれば良かったのですが）

おしゃべり要素は重要だった

前述した通り、オンライン参加者も開発を進める分には大丈夫だったそうなのですが、やはり開発しながらおしゃべりができないのが結構辛いらしかったです。

自分のチームは発表直前の4時間くらいはずっと電話を繋ぎっぱなしで作業したのですが、最初からずっと電話は繋ぎっぱなしで一緒にオンラインの人ともおしゃべりをしながら作業をすれば良かったなと思いました。

一番最初にそれぞれの環境を共有するべきだった

プログラムはすべてGitHubで管理していましたが、人によってクローンをしてもライブラリが入ってなくて動かなかったりそもそもWindowsとMacが混在していたりという状況をプログラムを動かし始めてから発覚し、ちょっと手間取ったので、一番最初にこういった確認をしておくべきだったなと思いました。

プレゼンがぐだぐたになった

だいたい質問合わせて1チーム10分くらいと言ってはいたものの、特にタイマーなどを使用していなく、どのタイミングで終了すれば良いかわからずなんとなくそれぞれ終了していくというプレゼンになってしまいました。
プレゼン5分、Q&A5分でそれぞれタイマーを鳴らして強制終了させた方が締まってよかったなと反省しています。

おわりに

ハッカソンに参加したことすらなかったので、うまくいくか結構不安だったのですが、なんだかんだ参加者にも喜んでもらえてうまくいったかなと思っております。

ただ、もっと快適な環境にできたり、プレゼンなどを盛り上げられたりはできたと思うので、そういったところは外部のハッカソンに参加して吸収してこないとなと思いました！

WEでは今後もこういったイベントを開催していこうと思っていますので、もし興味のある方は連絡ください！

それでは！