ハッカソンというイベントの目的とは何だったのか
おそらく僕がハッカソンを主催しだしたのは、2007年頃です。その時は、ハッカソンという言葉自体がまだほとんど知られていなくて、本当に珍しいことを始めたって感じだったのを記憶してます。そしてそれから8年以上が経過して、ハッカソンという言葉は広く認知されたのと同時に、その言葉が指すイベントがどのようなものなのかが「人によって認識が違う」状況となってしまいました。もちろん、好きに定義して良いことなんだけど、そもそも僕がハッカソンをデベロッパーコミュニティとやり始めたときにどんな認識でいたのか、今一度ここで再確認しておきたいな、と。
下記の内容は、ここで当時一緒にハッカソンを主催していた方々との会話から、僕が個人的に改めて当時の認識を言葉にしてみた文章です。
ハッカソンの目的
まず、ハッカソンの本来の目的がなんだったのか、ですが、これは以下でした。
- 普段の仕事では作らない/作れない何かを「試しで」作る機会を得る/提供する。
- 普段とは違う人と一緒にコードを書いて、新しいスキルや刺激を得るための機会を得る/提供する。
前者は、まさにハッカソンに参加するモチベーションの主要要素になることであって、主催側が何らかの技術をテーマにして、それに興味を持った開発者が参加する、という関係となります。僕が当時関わっていたのは「OpenSocialを使ってソーシャルアプリを作る」というものでした。当時はソーシャルアプリを作っている会社なんて皆無だったわけで、普段の仕事でそんなことをしてる人はいなかったわけです。それがどんなものなのか、どうやって作ればいいのか、既に僕はOpenSocialに詳しかったわけで、つまり主催側は技術的にそれに詳しい人がやってたわけです。そして、1日という短い時間の中で「（いつでもすぐに質問が可能な状況で）試しに作ってみる」という場でした。
ここで当時の主催側だった僕ら（少なくとも僕）は、「完成度の高いアプリが開発されること」、または「素晴らしいアイディアが登場すること」は特に目的にしていませんでした。その代わり、ちゃんとAPIをアプリ内で使ってくれること、を期待していたし、求めていました。
後者については、現在でもこれを明確に説明しているハッカソンはほとんどないのかな、と思ってます。でも、僕は「知らない人と一緒に開発をする経験」がとても大事だと認識していました。つまり、「隣の知らない開発者が持っているスキルやテクニックをお互いに触れ合って、結果としてみんなが刺激を受け合ってスキルアップのきっかけになること」がハッカソンのもう一つの大きな目的でした。
ものすごく大事なチーム分け
これを満たすために、たまに「一人で作りたい」と言ってくる参加者がいたのですが、許可しませんでした。必ず3人〜5人程度のチームを組み、チームで開発をして一つのアプリを作るようにしていました。つまり、ハッカソンの最初（もしくはアイディアソン）で行うチーム分けは、僕ら主催側はものすごく気を使ったし、工夫したし、場合によっては時間をかけたり、事前にチーム分けに必要な情報を参加者から得たりしながら、この2つ目の目的を参加者全員が達成するようにうまくナビゲートしていたわけです。基本的に最初のチームのまま最後まで進むのですが、場合によっては途中で別のチームに移動することも許容したこともありました。もちろん、それが本当に妥当かどうか、かなり深く話を聞きながら判断してたわけですが。
当時参加してくれていた方々はもちろん今でも知らないことだと思うけど、時には事前のアンケート内容から、参加者の技術レベルを推測して、偏りがないようにうまく参加者を各チームに配置したり、過去数回参加してくれた人をうまく分散したりしながら、本当にチーム分けは大事に考えていました。
ノウハウが詰まった運営ガイド
ハッカソンの目的、それは本当にそれら2点に全て集約されています。これが満たせた時、参加者はとても大きな利益（お金じゃない）を得て帰って行くはずなんです。本当に、まさに「貴重な体験」を得て、家路についていたはずなんです。当時の僕や同じようにハッカソンを主催していた仲間は、それを達成するためにはどのようにハッカソンというイベントを運営すべきなのか、ハッカソンを開催する度に反省をし、問題点を他の主催者と共有し、改善策を考え、そして次に活かしていく、これを繰り返していました。
その結果できあがったのが、以下のドキュメントです。
この運営ガイドは、当時のGoogle API Expert達と、グーグル社の担当社員達で、何度も修正しながら仕上げていったものです。僕らのノウハウが全てこのドキュメントに詰まっていますので、ぜひ一度目を通してみて下さい。
この運営ガイドには、あくまで運営のための手順が載っていて、ハッカソンの目的などについての言及はありません。しかし、このドキュメントに書かれている内容は、上記の目的を達成するためにはどのように運営していったらより良いのか、それを模索した結果が詰まっています。言い換えると、上記の目的を逸脱した「ハッカソンとよく似たイベント」を行いたいと考えた場合、この運営ガイドの通りにやってもうまくいかず、いろいろ違うことをすることになってしまうと思います。
絶対的なデモ発表会
上記2つの目的を達成するために、さらにいくつかの工夫が運営手順に入っているのですが、まず一つ目としては「ハッカソンの開発時間が終わった後に各チームがデモを行うこと」があります。これは「絶対」です。「作り終わってないのでデモしません」は許可しません。絶対にデモをしてもらいます。プレゼン資料だけで終わることも基本的には許しません（どうしても事情があって無理、っていうチームも出ますが、それはそれで仕方ないことです）。テーマとなっているAPIを使った機能が動く姿をデモすることが理想ですが、そうじゃなくても、何らか「動いているもの」を必ず発表する、ということが本当に重要です。
これは、ハッカソン開催前に必ず参加者全員に伝えます。そして、主催側は、開発時間終了の2時間前くらいから、「仕上げに入って下さいー」「デモをする準備にそろそろ取りかかりましょう」と促していきます。全員開発に没頭しているので、デモの準備という意識は普通であればどっかに吹っ飛んでます。これを主催側が補正して、意識の変化を促していきます。
やはり、プレゼンが抜群にうまい人っているんです。でも、目的は「うまいプレゼンして人気や共感を得ること」ではないんです。先ほどの2つの目的を読み返せば、これが全く的外れなことであることはわかってもらえると思います。限られた時間の中で、ちゃんと動作するプログラムを開発すること、その過程においては「ソフトウェア開発」の全てが凝縮されています。そして、その手順は人それぞれであり、参加者がそれぞれ持ってるテクニックを寄せ集めて「今まで未知だったテーマを盛り込んだ上で」何とかデモが可能な状態までコードを作り上げていく作業を経験すること、これは本当に参加者のレベルを一気に引き上げてくれます。
僕もハッカソンに参加した経験は何度もあって、あの何ともいえない緊張感、全員がそれぞれゾーンに入っていて、仕上げていくためにいろんな調整を会話していきながら素早く決めていく時のテンポの良さ、もうこれらは本当に快感だし、後日仕事に戻った時にも絶対に生きてきます。主催側に回ったとき、参加者がそんな状況下で懸命に開発している姿を見ると、涙が出てくるほど素晴らしい時間が流れていることを実感します。
参加者全員がそういった同じ経験をした後に、他チームのデモを見た時、全く同じ苦労を他チームもしていたことが完全にわかっているので、デモがうまくいったチームに対してはそのすごさが本当に理解できるし、どんなにデモに失敗したとしても、その難しさをわかっているので、失敗したことに対しても尊敬の念を持って見れるはずです。その中で、例えばあるチームがプレゼンでデモをごまかそうとしたとしたら・・・参加者全員がそのことを見抜きます。「いや、そこじゃなくてね・・・」って内心みんな思ってるんじゃないかと僕は推測しますが、どうでしょうか。
以前Google Developer Dayで「百聞は1デモにしかず」とKeynoteで聞いたことがありますが、まさにそれです。
投票と表彰
ハッカソンの最後は、参加者全員が1票持って、デモを見たあとに「最も良かった」と思うチームに投票して、最も投票数を得たチームを称える、ということをしていました。僕がハッカソンを主催していた当時は、毎回1位のチームのメンバーに何らかの「ご褒美」を準備していました。たぶんサービスのグッズだったり、普段もらえないものや入手困難なもの、を準備していたと思います（非売品のTシャツとか）。それとは別に、参加者全員に景品も渡していました。ボールペン1本、とか。
投票＆表彰は、実はなくても構わないのですが、実際に「みんなから良い成果だと思われたい」という欲求は皆さん持っていると思いますし、それを励みにして開発を頑張ることも素敵なことだとも思います。何よりも「投票すること・されること」も楽しみの一つになるので、毎回投票＆表彰は欠かさずにやってました。
度々「どういったチームが【良い】と考えれば良いですか？」と質問を受けたことがあるのですが、僕個人は明確に回答したことはありません。「良いとあなたが思ったものを素直に投票してください」と答えていました。自分のチームが最も良かったと自負できれば、自分のチームに投票することもありです。
上記のデモの発表のことについての話の通り、参加者はハッカソンというイベントに真剣に参加した開発者達であり、苦労をくぐり抜けてきた人達です。その方々は、たぶん主催側が何も言わなくても、投票に値するデモだったチームはどこか？って、直感的にわかるだろうと思ってます。もちろん、多くの投票を得ることができた要因は、デモの出来が良い、技術的に凄い、プレゼン自体が楽しい、とかいろんな要素があったと思います。厳密にその要因を揃えることはできないけど、共通の経験をしてきた人達なのでその要因はある程度揃ってしかるべきかな、ということと、投票者が多ければ多いほうが、どこに優秀さを感じたか、その要因はバラけると思うので、一層公平さが増して、結果として「納得感がある（=納得せざるを得ない）優劣」を提供できていたのかな、と僕は考えています。
追加要素として、あとで投票しないといけない、という認識は、他チームのデモをちゃんと見なくちゃ！、という意識を作ってくれます。
この「参加者全員で投票する」ということがポイントです。参加していない人達【だけ】で「○○チームが優勝です！」とか決めたことは一度もないです。本当に一度もない。そうしようと考えたことすらないです。それは、参加者の方々を尊敬し、尊重しているからであり、最初に説明した2つの目的において、主催側だけで「あなたのチームが優勝」だなんて決められないと思っているからです。
たまに「よういちろう賞」とか勝手に作ったことが何回かありましたが、それは景品が余ったからです。ちゃんとそのことを説明した上で、勝手にやってました。皆さん笑ってたので、おまけであることはわかってくれてたと思います。
現状の「ハッカソン」という言葉の使われ方への違和感
長々と書いてきましたが、ハッカソンというイベントを開催するときに僕らが持っていた共通の目的をもう一度ここで書きます。
- 普段の仕事では作らない/作れない何かを「試しで」作る機会を得る/提供する。
- 普段とは違う人と一緒にコードを書いて、新しいスキルや刺激を得るための機会を得る/提供する。
しかし、単に「エンジニアを集めて何かを作ってもらう」場のことを何でもハッカソンって呼んでしまうことが現在では増えている気がします。もちろん、上記の目的の元にハッカソンを今も行っている方々も大勢いらっしゃると思いますが、そうではないイベントに「ハッカソン」という名前を付けているケースも多いようです。特に、最後の表彰の根拠となる優劣の付け方について、参加者全員の投票ではなく、「主催側が審査員を別途用意して、審査員【のみ】で優劣を決定する」ということが行われているイベントをハッカソンと名付けているのを良く目にするようになりました。
特別に準備された審査員のみで1位を決めて表彰するようなイベントは、僕の認識においては、
「それ、ハッカソンじゃないから！単なるコンテストだから！」
だと思ってしまいます。
審査員がいるということは、その審査員は当然開発には参加してないわけで、上記で説明した公平性はそこにはありません。主催側の論理が強力に作用します。また、1位のチームへの商品も高額なものであることもあるっぽいですね。ますます主催者側の論理を強く感じます。この場合、参加者の目的は「商品をゲットすること」「1位になること」となるでしょう。個人的には、そういったイベントの場合、主催者側の目的は、上記のような参加者のための目的ではなく、例えば「企業がアイディアを手っ取り早く集める」ことが重要視されたものになるのかな、と想像できます。もう、それはハッカソンではなく、別のイベントなのかな、と考えてしまいます。
この傾向は、どうやら日本だけではなく、アメリカでもそうみたいで、企業が主催するハッカソンと、ユーザコミュニティが主催するハッカソンで、その目的が大きく異なってしまっているという現実があるそうです。そして、主に企業が主催するハッカソンという言葉を含むイベントは、どうやら僕が大事に思ってきた目的とは違ってしまっているようです。
もちろん、そういうイベントがあることには全く問題ありません。ただ、同じハッカソンという名前が使われてしまうことに、大きな違和感を感じてしまいます。
参加者にこれから求められること
もはや「ハッカソン」という言葉が指すイベントは、複数の目的を含むようになってしまいました。人によって、ハッカソンという言葉を聞いて連想するイベントの内容は様々でしょうし、ハッカソンという名前が付いたイベントの主催者側の目的も、その言葉から連想することは難しくなりました。
僕個人としては、Hack+a+thonという「ハック」という言葉の意味が、当初の2つの目的を指しているんだと信じて止まないのですが、異なる目的を持っている主催者側、そして異なる目的を持って参加する人、そういった方々が増えていることを認めるしかなさそうです。これから大事なことは、参加したいと思ったイベントがどういった目的で行われようとしているのか、それは自分がそのイベントに参加して達成しようとしている目的を満たしてくれるのかどうか、十分に確認してから参加申し込みをするということだと思います。そうすれば、参加した後に「がっかりしたなぁ」という感想を持ってしまうことを避けられるのではないかと思います。
