スッパ村
スーパーハッカソン2013に参加した。
http://super-hackathon.net/
賞を貰えたりはしなかったが、非常に面白かった。
なんというか人狼BBS系のゲームを思い出した。
別にチームメンバーが一人ずつ処刑されたり人狼に食われたりとかはしないけど、
- 「一人参加の場合、チームメンバーは基本、知らない人と組む」
- 「チームメンバーがそれぞれ持つ能力で役割分担」
- 「平日の深夜にネット経由でみんなで方針相談」
- 「期間が一週間ぐらいに限られており、その間はチーム内で行動」
- 「胃に悪い」
- 「終わったらみんなでエピローグ/懇親会して騒ぐ」(残念ながら自分は他予定の為、今回の懇親会は不参加だったが)
といったあたりが人狼BBS系のゲームをやってた頃の感覚に非常に近かった。
しかし一番大きい要素は、自分が所属させていただいたチームjsdokushoのgoogle docs上のドキュメントの一番上に「スッパ村」と書いてあった事(多分チームリーダーの横田さんが書いたんじゃないかと思う)。これを見て「ああ、村なんだな」と自分は認識した。
で、スケジュールが合えば次回も参加したいと思うので、今回やってみて得られた進行の流れやら、攻略ポイントとかを忘れない内にまとめとこうと思う。
どのアプリがよかったとか、Twilioすげーとか、その辺もびっしりメモに書いてるけど、そのあたりはきっと他の人も書くと思うので自分の分は省略。
以下は山田の個人的な感想、うろおぼえ記憶、妄想なので、実際には役に立たなかったり、実際とは違っていたりする可能性があります。何もかも無保証です。
↓
最初にまとめ：
- 人狼BBS系ゲーム好きのエンジニア/デザイナー/プランナーはスッパ村やらないか？次回は夏にやるらしい
- 一人参加者はエンジニア多数なので、一人参加者のデザイナー/プランナーはきっとモテる！
- 「スーパーハッカソン」はいわゆる普通のハッカソンと比べると、プログラミング系のイベントというよりはスタートアップ系のイベントの性質が強いので、デザイナー/プランナーの能力は重要。どういう風に重要かは本文参照。
- 会社通勤のある社会人参加者は時間的に超不利。学生参加者はそれなり(多分)。無職/仕事のないフリーランス参加者は時間的に超有利！しかし時間的に有利なのが必ずしも勝利につながる訳ではなく、おそらくアイデアが最重要。
基本情報：
- 2-5人でチームを組む。チームは知人同士で事前に組んでもいいし、開始前に一人参加者同士でチームを作ったり、既存のチームに追加参加させてもらってもいい。これの詳細についてはまた後述。
- 参加者種別は「エンジニア」「デザイナー」「プランナー」の三種、となっている。しかし普通に兼任可能だし、アイデア出し等は普通に全員でやるので、チームが決定してイベントが開始したらこの種別分けはそんなに意味はない。
- 作成するものは基本的に(というか第一回、第二回では)「web上で体験できるもの、もしくはスマホアプリ(iPhone / android / windows phone)」であり、これに対して何個かの「お題」と「制約」が提示され、それを満たすものを一週間で作る、という形となる。よって最低でもエンジニアはwebアプリもしくはスマホアプリを開発できる技術がないといけない。
- 「お題」「制約」は、協賛企業/審査員に関連したものが出る傾向があるようだ？
- プレゼン内容も評価対象であり、またマネタイズ要素の解説等のような、スタートアップでの出資者向けプレゼン的な性質が求められる。この為、何を作るかが決まった後はプランナーはやる事がない、というような事はないようだ。
- というか今回の上位入賞チームは、普通にスタートアップ的に運営していけるレベルの成果物が出来上がってると思う。レベル高い。
- この要素によって、いわゆる普通のハッカソンとはかなり性質が違ってきてると思う。
- 基本的に、初日と最終日はチーム全員での現地参加が必要
参加前準備：
- facebookアカウントを取っておく。
- 自分が普段使用している開発環境/処理系/ライブラリ/アプリ/ツール等のメンテをしておく。要は得物を研いでおく。
- 可能であれば、先にチーム用のwebサーバ、reverse proxy、jenkinsでの自動ビルド環境の用意を事前に行っておくとよい。
- 自分の名刺をたくさん用意しておく。
一人参加：
- 一人チームは許可されていないので、一人参加者は以下のどれかを行う必要がある
- 他の一人参加者と組んで新しいチーム作成
- 既存のチームに追加参加させてもらう
- 以下が運営サイドより提供される
- 初日の数日前〜前日ぐらいに、チームメンバー未決定者の為の「仲間をさがす会」が開催される。
- 名刺を忘れずに持っていく事。また自己紹介もするので内容も簡単に考えておいた方がよい。簡単に人に見せられる過去の作成物とかもあればそれも用意。堅苦しいイベントでは全くない(というか軽く酒飲みながら他の人と話をするだけ)が、初対面の人と話をする必要はある。
- 今回の会場はTAMコワーキングスペースだった。facebook登録の地図は微妙に座標がずれてるので注意(道に迷った)。参加費無料でソフトドリンクと缶ビール類とおつまみを出していただいた。
- 今回の「仲間をさがす会」の参加者はエンジニア6人ぐらい、デザイナー1人、プランナー0人。エンジニア以外ももっと参加しる！
- 初日の開会前に、まだあぶれてる人でのチーム組み、もしくは既存チームへの追加参加募集がある。
- 今回はうまく回避できたが、下手するとエンジニアだけのチームとかができる可能性があった。
- 初日の数日前〜前日ぐらいに、チームメンバー未決定者の為の「仲間をさがす会」が開催される。
- なお、今回の閉会式にて「次回の仲間をさがす会は、熟練者と若手が組めるようにしたい」的な話があったので(うろおぼえ)、次回はこの部分が変化する可能性は高い。
初日の流れ：
- 会場到着前にペットボトル飲み物とか買っておいた方がよい
- 受付登録、参加費用支払い
- 挨拶など
- あぶれた一人参加者のチーム組み
- お題の発表
- アイデアソン
- 一旦解散
- (optional)チームメンバーだけで飲み会、兼、うちあわせ
アイデアソン：
- みんなで何を作るか考える。
- 必ずしもこのタイミングで確定させる必要はないが、早く確定させないと開発等に使える時間に影響が出る
- この段階で運営サイドによる簡単な評価がある。これは別に優劣を付ける為のものではなく、「このアイデアで本当にできそう？」「これあんまり面白くないんじゃないか」「既に類似サービスあるけど差別化できる？」とかの評価。場合によってはアドヴァイスもいただける。基本的に運営サイドはチームの味方なので(すごい成果物ができるのは運営サイドにとってもプラス)、アイデアソンに限らず、何か困った事があったら気軽に運営の方に相談していいようだ。他のチームに対して不公平になるようなレベルのお願いとかだったらNOと言われるとは思うが。
開発開始：
- 役割分担
- 開発期間が一週間であり、極普通に平日を含んでいる為、チームメンバーによって、このイベントに費せる時間にはかなり大きな差がある。その部分を考慮した方がいいと思う
- エンジニア複数構成の場合、誰がどの部分を行うか大体決めておく。
- ただし最終日目前でまだ完成してない場合、役割分担がどうとか言ってられないので手伝えるところは手伝える体制を作っておく。この為、ソースファイル類はgit系ツールで管理するの推奨。
- コミュニケーション
- 期間中はコワーキングスペース等の提供があるが、正直なところ、チームメンバー全員が近くに住んでたりでもしない限り、物理的に集まるのは時間的に厳しいと思う。よってネットをフル活用する。
- 時間に余裕があるチームは、運営サイドが行う、スーパーハッカソンイベント自体のプロモの為のインタビューや写真/動画撮影に協力してもよい(これは成果物の評価には影響しない)。余裕がなければしなくても問題ない。
- ツール類
- 知人同士でチームを組んでない場合、どのツールを使うかは一番最初に相談しておいた方がいいと思う。
- グループ機能の使えるインスタントメッセンジャー系の何かで、チームメンバーと会話。
- google docs系の何かでドキュメント共有。人狼BBS系のように、現在の状態のまとめをたまに行っておくと方針の整理等がしやすい
- dropbox系の何かで、成果物を構成するアセットのファイル類、およびチーム内でやりとりする各種ファイルを共有。linuxサーバとか使うなら、linuxクライアントのあるものを選ぶ事。
- ソース管理は前述の通り、git系推奨。しかしアセット類はdropbox系の方が良い。
- 開発環境の構築
- webアプリを作る場合、なるべく早い段階でサーバとか用意した方がいいと思う
- セキュリティ
- 最終日の成果物の発表は「プロジェクタ使ってプレゼン10分」「審査員に5分ぐらい実演/さわってもらう」の部分までが評価対象。なので基本的にはセキュリティがまずくても問題はない。
- ただし、「審査員による審査時間中に、他のチームにさわってもらう」時間があり、そこで「他チームにさわってもらえるようにする」(optional)場合は、それなりにしておいた方がいいかも。
- webサービスを作って、「期間中に独自ドメインを取得してサービスに使用」するのはどうも評価に良い影響を与えるようだ。が、その場合もセキュリティをそれなりにする必要があると思う。
- 成果物の出来が良ければ良い程、どっかのセキュリティ研究者やらこんにちわこんにちわの人やらがやってくるかもしれないよ！
- ペース配分
- 期間中は睡眠時間が激減する為、日程の後半になると目に見えて思考能力やコーディング能力の低下、ミスの増加が発生する。最終日はほんとひどい。よって「後半は作業速度が低下する事を見越したスケジュールを考えておく」「ミスするとやばい部分は先に終わらせておく」「ミスしにくくなる/ミスしても致命的ダメージにならない工夫やら手順やら」とかを事前に工夫しておく価値があるようだ。
- プレゼン
- このイベントは「成果物を作っておしまい」ではなく、最終日にプレゼンを行う必要がある。このプレゼン作成の為の時間も忘れずに確保しておく事。
- プレゼン超重要。どんなに良い成果物を作ってもここで失敗してその良さが伝えられなかったらいい評価は得られない。要工夫。
- 「このアプリを公開する事でどれだけ利益が得られるのか」「それはどのような収益モデルなのか」「ターゲット層は誰で、どれぐらいの規模を想定しているか」みたいな部分も重視されるので、プレゼン内容にもそこを盛り込んでおく事
- つまり、ここで作る成果物には、スタートアップ的な方向性が求められているという事。
- 成果物の種類にもよるが、プレゼンではその場では実演せずに、事前に実演した動画を作っておいて、それを流すだけにした方がいいかも。プレゼン中に実際に実演しようとして上手く操作できなかったり、何らかのトラブルが発生するとプレゼン者の精神的にやばい。審査員に見せる時に結局実演は行うので、プレゼンの途中で行う必要性はそんなにないと思う。
- 審査員の前での実演時には、審査員からの質問が来るので、事前にある程度、質問されそうな内容を想定し、それに対する答えを用意しておく
- 動作確認
- 上記の実演時に行う部分の動作確認は徹底的に行っておく事。実演しない部分については余裕があればでいいと思う
- お題やアイデア選択によっては、従量課金制の外部サービスを使う事になるかもしれないが、これはアキレス腱になりうる！料金を気にして充分なテストができなかったり、残り利用残高が尽きて本番直前に動かなくなったりしうる。要注意。何らかの工夫か対策をしときたいところ。
発表日の流れ：
- いざという時に会場で修正やビルド等やサービスメンテができるようにPC類を持っていく事
- やはり会場到着前にペットボトル飲み物とか買っておいた方がよい
- 受付登録
- 運営サイドによる、極簡単な、アプリの事前動作確認(本当に完成しているかの確認)
- チーム毎に、プレゼンの為のプロジェクタ接続テスト等の事前チェック
- 挨拶など
- くじびきで発表順を決める
- 順番にプレゼンと審査員前での実演
- 「プロジェクタ使ってプレゼン10分」
- 「審査員に5分ぐらい実演/さわってもらう」
- 審査員による審議タイム / 他チームの成果物をさわってみる＆他チームに成果物をさわってもらうタイム
- 参加者による、どのアプリがよかったかの投票(審査には影響しない)
- 結果発表、いろいろ告知、挨拶など
- 懇親会(optional)
最後になりましたが、チームjsdokushoの皆様おつかれさまでした＆ありがとうございました。
一週間とても楽しかったです。
またの機会があったら、その時もまたどうかよろしくおねがいします。
