ハッカソン運営におけるGitHub/Slack活用のメリットとデメリット ~エンジニアにとってより良いハッカソンの運営を目指して~


## はじめに
弊社が運営事務局を務めさせていただいている[JPHACKS2015](http://jphacks.com/)が先日終わりました。
昨年と大きく異なり、全国での5拠点同時開催・オンラインでの中間審査などに対応するために、今回我々が運営するハッカソンで初めて、 **[GitHub](https://github.com/),[Slack](https://slack.com/),[Devpost](http://devpost.com/)の利用を必須** にしてハッカソンを実施をしてみました。この取り組みを通じて得られた事や、まだまだ改善しなければならないことも沢山みえてきましたので、今後のハッカソン運営や、更に今国内に数が増えつつある外部のハッカソン運営業者や、開催企業の皆様にも参考になればと思い、まとめてみようと思います。

## 導入目的
### **"全国5拠点で同時"** に開催し、 **"参加者が開発に出来る限り多くの時間を割く"** 事ができ、 **"公平性を担保"** した **"オンライン"** での **"技術にフォーカスした審査"** を実施するハッカソンを開催したい

全国に展開をしているハッカソンは私が関わったハッカソンでは、[Angelhack](http://angelhack.com/)や[SPAJAM](http://spajam.jp/2015/)等がございますが、基本的に全国や世界での予選は別日程で開催されます。しかし今回のJPHACKS2015では **ハッカソンで作成した製品をFinalで最終審査する** 形になっていたので、時系列に差が出てしまうとブラッシュアップ期間に差がうまれてしまい、早い開催の会場が有利になってしまいます。そもため、なんとしてでも全国で同時に開催する必要があり、そのためにWeb上で全国の参加者に効率的にコミュニケーションをとる手段が必要でした。

また、JPHACKS2015では、より技術的な視点にフォーカスをしており、技術視点での審査を実施し、 **アイディアだけでなく、開発力をもった学生が競い合う場所** を提供する必要がありました。


## ハッカソンで実施した内容
これらの目的を達成するために、今回GitHub、Slack、Devpostの3つのサービスを組み合わせることで解決しようと挑戦してみました。具体的にこれらのサービスを活用しておこなった施策は以下のようになります。

また、それぞれのサービスの利用用途は[こちら](https://github.com/jphacks/jphacks-guideline/blob/master/guidelines/tools.md)に記載しています。

### 1.開発ガイドライン等をGitHub上に全て公開
ハッカソンへの事前準備や、テーマ、全体の流れ、スポンサー様のご紹介、製品のご案内など、日々アップデートのある情報を毎回ワードやPDFにしてこれほどまでの多くの参加者にメール配布するのは大変厳しかったため、[ガイドライン用のリポジトリ](https://github.com/jphacks/jphacks-guideline)を作成し、そちらに情報を公開していきました。これにより、参加者は常にそのURLにアクセスをすることで、最新のハッカソン情報を取得していただき、情報に差異がなくなるようにつとめました。

### 2.ツール利用方法をガイドライン及び、Youtube上に動画で公開

[![JPHACKS2015 プロダクト提出方法 補足動画](https://i.ytimg.com/vi/6_RDpa41YiE/maxresdefault.jpg)](https://www.youtube.com/watch?v=6_RDpa41YiE)

[作品の提出方法](https://github.com/jphacks/jphacks-guideline/blob/master/guidelines/how-to-submit.md)や、ツールの登録方法等をガイドラインに記載して、参加者が事前にハッカソンに向けて準備ができる体勢を構築しました。また、作品の提出方法の動画はハッカソン当日にもガイダンスとして再生し、当日でも提出方法を試せるような形を取りました。また、提出方法に関する質疑も適宜Slack上で展開をしていきました。

### 3.GitHubリポジトリの配布
全てのチームに固有のIDを割りあて、GitHub Organizationのチームとリポジトリ作成を実施しました。また、今回GitHub様に後援をしていただくことができ、希望するチームには無料でPrivateリポジトリの配布を致しました。

### 4.Slack上での情報案内・参加者とのコミュニケーション
![jphacks3.png](https://qiita-image-store.s3.amazonaws.com/0/6702/e65fb912-ded7-6d51-6c85-b3a71c2a707b.png "jphacks3.png")

ハッカソン事前の段階のアナウンスから、当日の質疑応答までのSlack上にチャンネルをつくることで対応しました。チャンネルはそれぞれの会場毎のものから、全体向けのもの、製品（APIやデバイス）に対する質疑応答版、またチームごとのプライベートグループも作成し、コミュニケーションロスが発生しないように努めました。

### 5.Devpostでの製品提出
GitHubのリポジトリにデフォルトで製品概要の記入してもらいたい内容を記入した[README.md](https://github.com/jphacks/sample/blob/master/README.md)のフォーマットを作成して、参加者全員が同じ内容を記入してもらうことを目指しました。
また、作成・編集したGitHubリポジトリをそのままDevpostにインポートして提出できるようにすることで、

- 提出内容の統一
- プレゼン資料・説明資料などの作成時間を削り、製品開発時間を最大限にする

ことを目指しました。

## 実施して良かった事
### 1.全国での一体感が生まれた

![jphacks1.png](https://qiita-image-store.s3.amazonaws.com/0/6702/cb401bb9-be95-7b0e-ed7c-d6187d1aafd7.png "jphacks1.png")

通常のハッカソンでは、チーム外の参加者が交流する機会は交流会ぐらいなのではないかと思うのですが、Slackを導入することで、事前の参加者の自己紹介や、各会場の状況を共有することで参加者全体の一体感が生まれました。

また更に驚いたのが、「○○の使い方分かる人〜？」というような参加者同士がハッカソン中に助けを求めるような投稿などもあり、通常のハッカソンではあまりないようなコミュニケーションも生まれていました。


### 2.全国からの質問に同時に対応が出来た
![jphacks2.png](https://qiita-image-store.s3.amazonaws.com/0/6702/7ed6e327-f342-80f6-9dab-453ee58deeeb.png "jphacks2.png")

今回APIや製品を提供してくださった企業様にもSlackに登録していただいて、専用のチャンネルで質疑応答に対応していただきました。
これにより、全国各地へサポートに赴かなくても、ある程度の質問や不具合に対応することが出来ました。

### 3.開発の進捗状況を把握することが出来た

![Screen Shot 0027-12-29 at 1.56.20 PM.png](https://qiita-image-store.s3.amazonaws.com/0/6702/6bea8f50-5315-55bb-d955-e9ba6de3b6bf.png "Screen Shot 0027-12-29 at 1.56.20 PM.png")

開発に集中しているチームに対して、「今どんなものを作っているのですか？」と直接聞くのは難しいことだと思うのですが、GitHubを導入することで、どのような作品をどのように参加者がつくっているのかを把握することが出来ました。


### 4.製品や企画のライセンス問題をGitHub側に委託
今回、基本的に制作した製品のライセンスは製作者に帰属するものとし([ガイドラインに記載](https://github.com/jphacks/jphacks-guideline/blob/master/guidelines/rule.md))、Publicリポジトリを活用しているチームには[MITライセンス](https://ja.wikipedia.org/wiki/MIT_License)を適用し、デフォルトでライセンスファイルを設置しました。そのため、オープンソースで開発した場合の製品のライセンス等も簡単に適切に管理することが出来ました。

### 5.技術視点を含めた審査が出来た
昨年はPPT等での作品情報提出でしたが、今回は全てのチームが共通の内容になっているリポジトリのREADME.mdを編集してもらってDevpostに提出するだけで、全てのチームの製品概要を整理することが出来たため、参加者は開発に集中しながらもフォーマットに従って簡単に製品概要を提出をすることが出来ました。

ある程度審査基準に則った必要事項を記入してもらうことで、オンライン審査での比較検討をしやすいようにしました。

それによって、何人かの審査員はソースコードレベルで作品を審査してくださり、「具体的にどのように実装したのか」といったような”技術視点”の審査を実施することが出来ました。

## 改善しなくてはいけないこと
これらの多くの良かった点はあったものの、まだまだ改善しなければならない課題も同時にありましたので、合わせて共有致します。

### 1.サービス登録などの事前準備が面倒

参加者全員（最低でもチームひとり）に対して、外部サービスへの登録を必須にするのはかなりハードルが高く、導入アナウンスをする上での非常に面倒を強いてしまったような形でもありました。

また、今回ガイドラインの整備や動画の撮影などを全て私が担当させていただいたのですが、全てをつくりあげるのに正直想定よりもかなりの工数がかかってしまい、通常のハッカソン運営の何倍も準備に時間がかかってしまいました。

### 2.GitHub(Git自体も含め)の予備知識の有無による不公平さ
Gitを導入することに対するハードルに対してある程度事前調査をアンケート等にてヒアリングさせていただいてからの導入でしたが、それでも尚、そもそもGitやGitHub自体に触れたことのない参加者も中にはいらっしゃったため、バージョン管理の予備知識の有無による不公平さが若干生まれてしまったのではないかと思います。こちらはやり方自体を変える必要はないのかもしれませんが、バージョン管理やチーム開発スキルを事前に補うための教育要素をより充実させることで改善していかねばならないと改めて認識をいたしました。

### 3.ネット環境に依存してしまう
今回の外部製品利用は全てにおいてインターネット環境下であることが前提の進め方でした。その中で、会場によってはインターネット回線の影響で、作品提出に想定よりも時間がかかってしまったり、コミュニケーションがとれないような時間帯が発生してしまいました。

### 4.ハードウェア面の評価が難しい
GitHubでのソースコード管理はソフトウェアの開発の評価の指標にはなるのですが、今回多くのチームが外部デバイスの活用をしており、それだけでなく、オリジナルデバイスの作成などもハッカソン中におこなっておりました。（例えば専用の鍵を作成したり、服を作成したり等）

これらのハードウェアの開発においては、デモ動画以外でクオリティを測ることは難しかったのですが、今後は3Dプリンタの活用等でよりこのような周辺機器の作成がハッカソン中におこなわれることが増えて来るのではないかと推測できます。こういったものづくりの技術をどのようにして評価していくのかが今後のハッカソン運営側でも重要になってくるのではないかと思います。

## 最後に
参加者やスポンサー、関わる方々に短期間でのものづくりを通じてこれまでにない新しい出会いや機会を創造するという意味で、私個人としてもハッカソンの取り組みはとても推奨していますし、応用的な教育やオープンイノベーションとしての位置づけも非常に面白いと考えております。

しかし、ハッカソンは今ある意味日本国内においてもかなりのムーブメントになりつつあり、多くの企業や業者が導入をしている一方で、数の増加に伴い

- アイディアや製品のライセンス問題
- 審査・評価方法の問題

等など、質の高いハッカソンを提供していくには解決していかなければならない課題も山積みです。

そのため私自身、[ハッカソン研究会](https://www.colabory.com/groups/group/238/)という研究会の立ち上げ発起人を務めさせていただいていることもあり、これらの課題とこのような取り組みを通じて向きあっていければと考えております。

ハッカソンの参加者・開催者の双方にとって快適なハッカソン文化を構築していくために、当記事が少しでもお役に立てば幸いです。