ハッカソンへの思いを綴ってみる。

今回は、私がプログラマーとして活動し始めてから何度も関わっている
「ハッカソン」について思いを綴ってみようと思います。

ハッカソンとは何か

ハッカソンは、
Hack と Marathon を掛け合わせた造語です。

Hack とは、物事をハックする、つまりなにか現在ある物事を便利にしたり、世の中の事象をもっと楽しくするようなことを工夫して作り出すという意味があります。

Marathon はもちろん走るマラソンであり、ランナーは長い道のりを休むことなくゴールを目指してそれぞれのペースで完走を目指すスポーツのことです。

ハッカソンは、この何かのサービスを、短期間で完成させることを目指すスポーツのようなものです。

ハッカソンは競技大会

参加者は、自分達が考えたサービス（多くの場合はソフトウェアサービスのことが多いですが、ハードウェアを用いたハッカソンもあります。）
を完成させることを目標に、チームもしくは個人で24時間等の短時間での開発に挑みます。

制限時間内に作られたデモ作品は開発終了後に発表され、審査員によって審査、優秀だったチームには賞金や賞品が送られます。

開催者やスポンサーにもよりますが、開発場所は提供され、参加者は当日はそこにチームで集まり開発に挑みます。

制限時間は２４時間だったり厳しいことが多いので、チームの多くは夜通しで開発を実行しサービスの完成を目指します。

チームによっていろいろな強みがあったり、作るサービスの色があり、開発のやり方もそれぞれですが、それぞれのチームが一致団結して短時間でサービスの完成に向けて切磋琢磨するのはハッカソンの醍醐味です。

私のハッカソン出場歴

私は今まで３回ハッカソンにプレイヤーとして出場し、
２回は運営サイドとして、共催の審査員、技術提供の審査員を務めたことがあります。

３回も出場しているのですが、賞などを今まで取ったことはありません。
一度受賞してみたいという気持ちはもちろんあり、また出てチャレンジしてみたいと思っています。

こんな私が、なぜハッカソンをこんなに好きなのか、ということに関して、いくつかの理由を挙げながらお話ししたいと考えています。

ハッカソンは学びの爆発

この言葉の通り、ハッカソンに出場して開発することで、学びのエクスプロージョンを体験できます。
これは具体的にはどういうことか、というのを一つ一つ説明します。

新しい技術を学ぶ

ハッカソンでは多くの場合作りたいサービスを先に考案し、それが実際にどのような技術で作成可能なのか、ということを思案するところから競技がスタートします。

作りたいサービスが先にあり、それを実現するための技術を勘案した時、そこに登場する全ての技術に精通している人はいないことがほとんどです。

モバイルアプリ、ウェブアプリ、機械学習、クラウドインフラなどいろいろな分野がソフトウェアエンジニアにはありますが、それぞれの分野でも多くの開発言語やツール、プロバイダやインフラ構成などがあり、それぞれに専門家がいるくらいですから、サービスを一つ作ろうとするとそれらの総合的な知識が必要になります。

例えばお医者さんを想像すれば、内科、外科、胃腸科など全ての専門性を深く持っているお医者さんはとても少ないと考えられるのと同じです。

このようにサービスを実際に作ろうとした時のソフトウェアエンジニアの技術範囲は広く、一人でカバーするのはとても難しくなります。

必然的に、ハッカソンの中でサービスを作ろうとすると、自分がカバーしたことのない分野の技術や、歴の浅い分野の技術をその場で勉強する必要が出てきます。

また、エンジニアリングの技術のみならず、サービスを考えるときの課題を考えたり、ビジネス性を見出したり、UIUXについて考えたりするビジネスやデザイン、マーケティングのような専門性もサービスづくりには必要です。

サービスをきちんと作るということは、それらについても一定の理解をしようとする努力が必要となり、新しいことを学ぶことになります。

普段業務で使っていたり、自分が趣味で使ったことのある技術以外の技術について学習し、サービスを実際に作れるレベルまで向上させるという意味で、新しい技術を学ぶきっかけとなること、これはハッカソンの醍醐味です。

短時間で学ぶ

新しい技術や、あまり使ったことのない技術を学ぶ必要があるのに加えて、それらを普通に仕事で行うよりもはるかに短い時間で学習しなければならない、そのスピード感もハッカソンの醍醐味です。

多くのハッカソンでは、ハッカソンで使う予定の技術の前準備や学習は前もって行うことができますが、それでも多くのチームは１、２週間程度の準備で本番に挑むことがほとんどだと思います。

もし時間が取れなかったり、本番直前に出場を決めたとすると、本番の２４時間の中で学習を１から行う、ということもあります。

仕事でももちろん新しい技術を日々勉強することもありますが、ハッカソンほど短期間で学ぶ機会というのはないでしょう。

そういう意味で、厳しめの時間制約の中で新しい技術について学習することをハッカソンを通じて学び、それを楽しむことができれば本当にいい機会になります。

動くものを作り披露する

ハッカソンは基本的には２４時間（たまに１、２週間程度の時間制限のあるハッカソンもありますが）などの時間制限を持った大会で、目的はその制限時間内に成果物を作成し発表することです。

発表の際には、パワーポイントなどの資料だけではなく、ハッカソン内に作った実際に動くモックアップをみんなの前で動かして披露する必要があります。

この「実際に動くもの」を作るというのは実は非常に難しく、チャレンジングです。短期間の中であまり使ったことのない技術を使い、実際にサービスとして動くものを作ることにはプレッシャーがかかります。

最後に人の前で披露するので、チートするとこともできませんし、見た目にも少しはこだわることになります。

動くものを作るというのはエンジニアリングの1番最低限の仕事であり、簡単なことではないわけですが、それを短期間でやり遂げるところに大きなやりがいを感じる人も多いのではないかと思います。

臨機応変に対応する

ハッカソンとい競技の目標は、制限時間内に動くものを作り他人に対して披露することであり、制限時間は厳しいものとなっていますから、作業の進捗具合によっては臨機応変にサービスの内容をピボットさせたり削ったりして軌道修正する必要があります。

始める前はかなり余裕をもった計画を組んでいたつもりでも、開発してみると想定外のバグに悩まされることはとても多く、その時は開発項目の修正を余儀なくされることも多いです。

このように、臨機応変に開発の進捗を見ながらそれ以降の開発項目を修正することは非常に大変ですがとても大事な能力であり、個人やチームの力量が試されるところです。

また、サービスのコア機能をしっかりと理解し、必ず実装しなくてはいけない部分と、プラスアルファで時間があれば取り組みたい部分を切り分けて、その場その場で判断していくという経験はとてもチャレンジングであり、面白いところです。

ハッカソンは群れない

先程はハッカソンは学びの機会である、という観点からお話ししましたが、
私がハッカソンを好きな理由の二つ目は、ハッカソンは自分が好きなように、群れずに自由に開発していい、という観点です。

ハッカソンでは孤独な開発を楽しめ

ハッカソンはチーム競技ですが、一人で参加することももちろん可能です。

また、チームで参加したとしても、手分けしてタスクを実行することになり、実際の作業は孤独に行うことになります。

チームとして新しい技術スタックに取り組んでいる時はチームのメンバーは誰もその技術について詳しくないため、デバッグなどの作業は一人で行うことになります。

制限時間のある中での孤独なデバッグはとても大変な作業ですが、公式マニュアルを読み込んだり、深くチュートリアルを理解しようとする経験は必ずプラスとなります。

もちろん、一人で解決が困難であればチームのメンバーに頼るべきですし、みんなで助け合いながら解決するべきです。

しかしながら、基本的には開発は孤独である、ということを理解しておくと、エンジニアとしては良い経験になるのではないかと思います。

自分のために作っていい

ハッカソンを通して何を作るか、ということですが、基本的には自分や自分のチームが作りたいものを自由に作って大丈夫です。

もちろんハッカソンにはお題があったり、使うべき技術がいくつかあらかじめ選定されていたり、シナリオが決まっていたりすることもありますが、原則作るものは自由です。

なにか自分達が生活する上で課題だと思っていることをプロダクトにしてもいいですし、自分達の信念に合っているもの、好きなものを自由に、ウケ狙いでもビジネス的に真面目なものでもなんでも作っていい、その自由さがハッカソンの醍醐味だと思います。

自分があったらいいなと思うものを作るのがやはり一番いいと思います。後述のリリースまで実際に開発するという観点からも、一番モチベーションが続きやすく、思い出にも残りやすいと思うからです。

他人に評価されてもされなくてもいい

もちろん誰かのペインを解決するようなプロダクトを開発して、課題ドリブンなサービスを発表することは素晴らしいと思います。

実際、賞を取ることを目標にしているなら、このように解決したい課題を明確にしたプロダクトを作るべきだと考えます。

しかし、ハッカソンのコンセプト自体はとても自由な開発の場であるので、自分が作りたいように作っていいんです。

最終的に誰からも評価されなかったとしても、自分が作りたいものを作れたのならいい経験になります。

賞を目指していたが評価が思わしくなく、悔しい思いをしたのであれば、他の優秀だったチームがどのような開発をしていたのか次回に活かして、もっと評価されるサービスを目指すのも素晴らしいと思います。

ですが、繰り返しになりますが、究極的には自分の作りたいものを自由に作って自由に発表する、それがハッカソンだと自分は思います。

追加で開発してリリースしてもいい

ハッカソンは刹那的なイベントです。

２４時間で開発は終わり（長いものだと２週間とか１ヶ月のハッカソンもあるにはあります）、賞が発表された後はみんなそれぞれ解散します。

賞をもらったチーム、そうでなかったチームがその後それぞれ作ったプロダクトを実際に世の中にリリースするために開発するかどうかは自由です。

私は一度実際にハッカソンで作ったアプリケーションをモバイルアプリとしてリリースするためにそのあと数ヶ月の追加開発を個人的に行いましたが、そこまで実際に行うようなチームはかなり少ないように思います。

これはハッカソンの一つの課題であると言えるでしょう。

もちろんリリースすることがハッカソンの目的ではないのですが、持続的な開発ができるような環境や資金的なサポートがハッカソン運営から提供され、ハッカソンでの開発がハッカソン内だけで完結してしまわないような工夫もこれから必要だと考えます。

複数のハッカソンに参加している私としては、それぞれのハッカソンで素晴らしいアイディアの種が産まれているのを目の当たりにしているため、それをより強く感じています。

ハッカソンは青春

今までハッカソンは学びのいい機会であり、自由に開発してよく、エンジニアとして開発経験を積むことができる、というような観点でお話ししていました。

最後にお話しするのは、私がハッカソンを好きな一番の理由であり、それはある意味「思い出作り」です。

ハッカソンは刹那的なイベントであり、短期間でエンジニア達がチームを作り、自分達の考えるプロダクトを開発するためにパワーを注ぎ込む競技大会です。その過程はクリエイティブで、熱量があり、様々なことを学ぶ「青春」なイベントだと自分は思います。

文化祭効果で絆が深まる

学生の時に、なんとなく団結力が欠けているように感じていたクラスが、文化祭というイベントを通して一致団結し、最高のクラスになった、そういうような経験はなかったでしょうか？

これはなにか一つの目標をクラスメイト達が共有し、短期間の中で準備や練習を文化祭のために共同で行ったという「体験の共有」によって産まれたものだと解釈していますが、ハッカソンはまさに「エンジニア達の文化祭」です。

学生や社会人のいろんな年齢の人たちが制限時間内に開発を行い、切磋琢磨する、そんなイベントがたまにはあってもいいんじゃないかと思います。

特に、チームで参加しなんとか発表にこぎつけた開発経験は、チームの最高の思い出になります。

プレッシャーの中でぶつかり合う

ハッカソンはエンジニアの青春だと書きましたが、実際の開発中は苦しいことが多いです。

新しい技術を制限時間の中で駆使ししてプロダクトを開発するわけで、その過程ではバグが解決できずにフラストレーションが溜まってしまうことも少なくありません。

そんな中でチームの中で嫌なムードになったり、本当に開発が最後まで完了できるのか、という負の雰囲気になったりすることもあります。

このような時はチームとしての団結力の見せ所です。

困っているメンバーがいれば集中的にサポートし、少しでも開発が前に進むようにお互いに助け合います。

開発中のプレッシャーは大きいですが、それらを乗り越えてみんなでなにか動くものをつくったときの喜びはさらに大きいです。

賞は取れても取れなくてもいい

自分達が作りたいものを作ってそれらを披露し、それらがその場で評価されなかったとしても、別に気にする必要はありません。

もちろん他のチームから学べることはたくさんありますし、あっと驚くような着眼点や技術の使い方を他のチームから学ぶこともハッカソンの醍醐味ですが、自分達が作ったプロダクトは世の中で唯一無二のものです。

ハッカソンというなんてことのないただのイベントですが、そこでみんなで作ったプロダクトは、自分達が納得していればそれでいいんです。

私の経験上、ハッカソンで一番悔しい思いをするのは、賞を取れなかったときではなく、自分達の作りたいものを途中で曲げてしまったり、途中で妥協して本来作りたいものが作れなかったり、技術不足で不完全燃焼に終わってしまった時です。

もし自分のチームの開発に悔いがないのであれば、それが一番だと思います。

思い出が1番の宝物

結局のところ、ハッカソンはただのイベントです。

たしかに賞金をもらったり、賞をもらってインタビューを受けたりすることは目立ってかっこいいですが、だれがどんな賞をもらってどんなコメントをしていたのか、というのは１週間もすればみんな忘れてしまいます。

自分達のチームがどんな思いでサービスのアイディアを思いつき、どんな技術を使って、どんな困難を乗り越えてなんとか動くものを作ったのか、その「思い出」こそがチームメンバーにはずっと残ります。

やはり最後は、自分達がどれだけやり切ったか、自分達のサービスを好きになれたか、これからもそのサービスをメンテナンスしたり、改良したいと思えるか、だと思います。

また、ハッカソンを通じて友達が増えたり、開発の楽しさを再認識させてくれたり、そのような思い出を残してくれるのがハッカソンのいいところです。

まとめ

長くなりましたが、ハッカソンは素晴らしいイベントである、ということを熱量をもって伝えられたらいいなと思いながらこの記事を書きました。

ハッカソンの課題

もちろん、ハッカソンというイベントについては課題も少なからずあると考えています。

まずは、ハッカソンがその場限りの開発になってしまい、せっかくの素晴らしいアイディアを継続開発する率があまり高くないということ。

次に、評価の軸を決めるのが難しいということ。

ハッカソンはビジネスコンテストではなく、自由なアイディアに基づいて（仮にそれがビジネス的に成り立たないものだとしても）開発が行われるもの、とされることが多いですが、賞をとるのはやはりビジネス的に面白いものが多かったりするからです。

ここは運営側としても難しいところだなあと思います。

また、参加のハードルが少し高いように感じることも一つの課題かなと考えています。

このようにいろいろ楽しいことが盛りだくさんのハッカソンですが、結構ヘビーなところと、オタクっぽい雰囲気も少なからずあることからそこまで参加者が増えないことも多いと感じています。

あとは、賞金や賞品の設定の難しさです。

賞金はもちろんあった方がいいと思う一方で、それだけが目的で参加するのも何か違う気もするし、何が一番最適なのか、というのは自分の中でもよくわからないです。

終わりに

このようにいろいろと考えるべきこともありますが、
トータルで見るとハッカソンはエンジニアとって（また、なにかアイディアを出すのが好きなアイディアマンにとって）最高の機会であると考えています。

ビジネスに紐つけてもいいし、ビジネス関係なしに作りたいものを作ってもいいし、その辺のグラデーションをうまく設定できることもハッカソンのいいところだと思います。

この記事に偶然辿り着いていただいたあなたも、なにか参加してみてはいかがでしょうか。

ハッカソンに出場して楽しかった思い出、得た技術、仲間がこれからのあなたにとってかけがえのないものとなったら最高です。

最後に、これから私はハッカソンを運営する活動もまずはスモールスタートで行っていければと思っています。

もしハッカソンが好きで、そのような運営に興味がある方がいらっしゃいましたら、気軽にお声がけください！お待ちしています！

今回はこの辺で。

kenmaro