Help us understand the problem. What is going on with this article?

devpostから学ぶハッカソンの作り方

More than 1 year has passed since last update.

最近、ハッカソンもいたるところで行われるようになって、随分と浸透してきたと思います。

自分たちもやりたいけど、どうしたらいいのかよくわからない方は多いのではないでしょうか?

そんな人に参考にすべきおすすめのサイトがあります。
devpost」というサイトです。

スクリーンショット 2017-12-02 7.20.42.png
引用:https://devpost.com/

devpostとは、企業と開発者のマッチングを目的に、ハッカソンや仕事の情報をオープンにしているサイトです。

本記事は、devpostに公開されているハッカソンから、ハッカソンについて学び、ハッカソンを開催するにあたって必要な情報をまとめます

また、ハッカソンの運営サイドの話は多岐に渡りすぎるのでココでは触れませんのでご承知ください。

では、行きます。

ハッカソンを知る

具体例から入るとイメージし易いので、ひとつサンプルを見てみましょう。

以下は、今年のAWS re:Invent2017で開かれた、「Smart Cities Hackathon」というハッカソンです。Alexaを用いて近代社会の問題を解決するようなアイデアを短時間で実装するというものでした。

スクリーンショット 2017-12-02 9.30.43.png
引用:https://smartcities.devpost.com/?ref_content=default&ref_feature=challenge&ref_medium=discover

詳細はリンクを確認していただきたいのですが、ハッカソンの内容についてイメージが湧いてきたでしょうか?

本記事の本題は骨組みなのでコンテンツには触れませんが、興味のある方は参加したつもりで考えてみるのも面白いと思います:grinning:

ハッカソン基本構成を確認していきます。

ハッカソンの構成要素

ハッカソンの要素は、細かく見ると開催コンセプトに依存し多岐に渡りますが、ある程度は抽象化できそうな要素で構成されています

下記、構成要素を抑えておけば大抵の抜け漏れを防げると思います。(たぶんきっと)

ひとつひとつ見ていきます。

内容

最も重要な要素です。内容には、コンセプトや動機、その先に実現したい世界を記述します。開催意図を明確にし、開発者が実装イメージを膨らませ、WhatとHowの部分に集中しやすくするための重要なパートです。

参加方法

どこから、どうやって申し込むのかを、わかりやすく説明します。
ここがめんどくさいと、参加率に影響します。

資格条件

このハッカソンへの参加資格を条件として書きます。
たとえば、年齢制限(20歳以下)や、参加スタイル(個人 or 何人以下のチーム)などなど。

ほかにも、自社の開発者は参加しては駄目など、NG条件もここに書きます。

要求事項

短い時間でアウトプットを出すためには、ある程度のスキルセットを持った人達でないと成り立たないケースがあります。ハッカソンが円滑に進むための要求を決めておきます。

事前準備などもここにいれます。

たとえば、「AmazonとGoogleにアカウントをもっていること」など。

また、事前準備での要求以外にも、アウトプットの提出先・方法や締め切りなども忘れずに書きます。

審査員

審査員は、ハッカソンのコンセプトに精通した方にお願いしましょう。
審査員は、一人よりは複数人のほうが納得感が出ます。また、各審査員のSNSのリンク、簡単なバイオグラフィがあると嬉しいですね。

審査基準

審査基準を明確にしオープンにします。

審査基準が適切に設定されていないと、目的から逸れる結果を引き起こしかねないので、達成したい目的とセットで考えることがおすすめです。

しっかりと吟味しましょう。

賞金・景品

入賞者がどのような賞金や景品がもらえるのかを明確にします。
入賞者のランクと景品が表になっているとわかりやすいと思います。

日本では、景品法に目を通しておくと万が一のトラブルを避けられるかもしれません。
http://www.caa.go.jp/representation/keihyo/keihin/keihingaiyo.html

賞金・景品の受け渡し方

たとえば、賞金が高額になった場合に、受け渡しは現金なのか、銀行振込なのか、受け渡すところまでしっかり考えておきます。

また、受け渡しの方法だけでなく、タイミングも一緒に明記します。
未発売のものを景品にした場合などに、すぐに渡せないことも明記するといいでしょう。

禁止事項

暗黙の良心で成り立つことも多いですが、明確にしておくと、トラブル時の保険になります。
たとえば、オープンソースとして公開するようなハッカソンで、著作権がある画像を使ったりしたらNGです。

免責事項

これも保険です。ハッカソン中の不慮の事故に関して一文入れておくといいと思います。

サポートの連絡先

問い合わせ先って意外と書き忘れるんですよね。ML作って書いておけばいいですが、運営側での対応者は決めておきましょう。

ハッカソン運営からのお知らせ方法

「会場が変わりました」など、全員に何かを知らせないといけないときに、運営サイドからの連絡手段を書いて置きます。メールとかSlackとかですね。

まとめ

以上、つらつらと、ハッカソンの構成要素をまとめました。
自分は今年AWS re:Invent2017に出てハッカソンの楽しさを知りました。

devpostではいろいろなハッカソンの情報が見れるので、自分のやりたいことと似たようなハッカソンを参考に広げていくのもありですね!

ぜひ色んな所で開催されるハッカソンにチャレンジし、弊社でも開催していきたいと思います:smiley:

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした