概要
RUNTEQというプログラミングスクールに通っている有志メンバー4人（途中からRUNTEQ校長もjoin）で、東京都主催のハッカソンに参加してきました！！
チームメンバー全員ほぼ開発未経験のなか
なんと、、、
約60チームの中でファイナルステージに進出！
そしてファイナルステージでは
オーディエンス賞を受賞することができました！！！！！！！！！！
嬉しかったですね〜〜〜
小池百合子 都知事とも写真が撮れました！！ 
戦略的に戦うことで、つよつよなエンジニアさんと互角に戦えることができました(はず...)
優勝までは手が届きませんでしたが、ほぼ未経験者の私たちが、オーディエンス賞を勝ち取る
までのお話をまとめてみました。
都知事杯オープンデータ・ハッカソン2022とは
今回私たちが参加したのは東京都庁が主催しているオープンデータハッカソンです。
ハッカソンという言葉はハック(hack)とマラソン(marathon)を合わせた混成語のことです。
簡潔にまとめると、東京都の公開しているオープンデータを用いて、東京都民のQOLをあげるサービスを作るという感じのものでした。
興味のある方は、下記リンクを参照ください。
都知事杯 オープンデータハッカソン
サービス概要
「Pluspo」
都内の公共スポーツの横断検索が簡単にできるサービスです。
都内の公共スポーツ施設がそれぞれの市区町村で管理されているため、HPがバラバラで欲しい情報にアクセスしづらいという点に着目しました。
そこで、各HPに点在するスポーツ施設の情報をデータキュレーションし、一元化することで、
- やりたいスポーツ
- 日時
- 場所
上記3つから利用者の望む組み合わせでスポーツ施設を検索することができるサービスを提案しました。
（2022年12月現在、開発中です）
勝ち残るために必要だった３つの要素
その1：いちばん大事なアイデア出し
ハッカソンは、アイデア出しで全てが決まると言っても過言ではないです。
圧倒的に大事！！！です。
時間をかけるべきところなので、チームメンバーとしっかり話し合いをして全員が納得のいくものに決めました。
募集要項を読み込む
今回のハッカソンは参加者に「何を求めているのか」、募集要項にはメッセージ（評価基準）が書いてあります。
ついつい流し読みしてしまうこともあると思いますが、読み込むことは非常に大事です。
評価者たちの望むポイントを仕留められるサービスを作りましょう！！
今回の場合は、様々な評価軸がある中で、「サービスの実現可能性」を強く見られているなと感じました。
そこで、「マネタイズをどうしていくか」をしっかりプレゼンに入れ込みました。
プレゼンは下記から観れるのでよかったら見てください。
小さなものでもいい、身近な課題を考える
実を言うと、最初はPluspoではなく、震災系のアプリを作りたいと考えていました。しかし、既存のサービスを調べていると、あることに気づきました。
「LINEが作っているサービスが素晴らしすぎて逆立ちしても敵わない。。」
へっぽこ未経験エンジニアでは、金銭面でも技術力でも到底敵いません。
そこで、企業じゃなくで私たち個人がサービスを作る意義というのを考えて、
「痒い所に手が届くサービス」 を作ろうと考え直しました。
普段生活している中での不便を洗い出し、
次項とも被ってしまいますが、幾度となく話し合いを重ねました。
その結果、ハッカソンのライブを試聴していた皆様の心に刺さり、
いちばん使ってみたいサービスということでオーディエンス賞をいただけたんだと思います。
たくさんディスカッションをする
「大学生の頃、テニスコートの予約を取る時に現地に赴かないと行けなくて面倒だったんだよね」
この一言から話が膨らみ、Pluspoは生まれました。
一人で考えているだけだと、なかなか考えが固執してしまってひらめきは生まれません。
チームメンバーとのディスカッションだけでなく、
家族や友人、恋人、色々な人に「こういうサービスあったら便利かな〜？」って話してみるのもいいと思います。
その2：プレゼンがすべて
新しいサービスを作ったとしても、そのサービスの素晴らしさを分かってもらわないと、そもそも利用してもらえず、良し悪しの評価もできないですよね。
もちろんサービスの実装することも大事です！
しかし、同じくらいピッチの内容を考えることも大事でした！
ピッチを制して、運営のハートを鷲掴みしにいきましょう。
プレゼンは時間内に収める
今回のハッカソンでは、時間内にプレゼンが終わらず、最後まで思いを伝えきれていないチームがいくつかありました。せっかく素晴らしいサービスを作ったのに、思いを伝えきれないなんて非常にもったいないです。「●分で発表してください」と事前に伝えられると思うので、原稿は時間に余裕がある量にしましょう。一般的に、1分間では300文字くらいが丁度良いとされているみたいです。人によって丁度良いと感じる原稿量は異なるので調整しながら、たくさん練習して本番に臨みましょう。
最初の掴みは大事、キャッチーにいく
「人の第一印象は最初の3秒〜5秒くらいで決まる。」
FirstStageでは、ピッチの制限時間が2分と短く、発表するチームが約60とたくさんいました。
そのため、とにかく「印象に残すこと」を考えました。
いろいろなピッチをYoutubeで見て勉強したのですが、SmartHRさんのピッチの構成がとても好きでした。
「労務手続きの書類で、性別を選ぶ欄が6択あります。
１つ目は普通の男性、２つ目は普通の女性、３つ目はなんでしょうか？
・・・答えは炭鉱で働く男性です。当然わかりましたよね？（分かるわけない）」
↑ここがすごく好きでした。思わずクスッと笑ってしまいますよね。
審査員も人間なので、単調なピッチをずっと聴き続けていると段々飽きてきてしまいます。
ちょっと小ネタを挟んで会場の雰囲気を引き込む作戦は大アリです。
さて、Pluspoではどんなふうにみなさんの心を掴んだのでしょうか？
※First Stageの動画が削除されてしまったため、省略させていただきます
人は感情に動かされる
我々の反省点でもあります。
Pluspoが優勝できなかった理由として、熱い思いがプレゼンから感じることができず、緊張しすぎて、淡々と原稿を読んでしまった部分があります。
「プレゼンには、サービスへの熱い情熱を入れましょう。」
みなさんは、3人のレンガ職人の童話をご存知ですか？
ある旅人が中世のヨーロッパを歩いていると、重たいレンガを汗水流しながら運んでいる3人のレンガ職人に出会いました。
旅人はそれぞれのレンガ職人に、「ここで何をしているのですか？」と尋ねるのですが、
1人目「親方に命じられたから仕方なくレンガを運んでいます。だるいな、早く帰りたい。」
2人目「壁を作っています。力仕事で大変だけど、お給料がいいからこの仕事を選びました。」
3人目「みんなが喜ぶ大聖堂を作っています。自分がここからいなくなった後も、ここにたくさんの人が集まることを考えると光栄な仕事です。」
3人目のレンガ職人にだけ、今回作っているサービス（大聖堂）に対する熱い思いがあります。
同じ質問に対する回答ですが、全然印象が違いますよね。
サービスへの熱い思いを、実現したい未来を伝えるのが大事です。
みなさんはレンガ職人と違って生活のためではなく、意志を持ってハッカソンに参加しているはずです。
たくさんディスカッションを重ねたので、実現したい未来があるからこそサービスが決まっています。
熱い思いをピッチにライドオンしましょう!
そして、本番は自信を持って感情に訴えていきましょう！
「自分は国を救った英雄、はたまた自分はアイドルで今日のオーディエンスはみんな自分のファン」
それくらいの強い気持ちで臨みましょう。なんとかなります。
その3：積極的にイベントに参加する
今回のハッカソンでは、最初のタームで開催されていたイベントの参加は自由でした。
また、イベントの種類によってはコロナの関係もあり、リモートでの参加もOKでした。
参加自由でも全参加！そして現地に行けるなら現地に行くべき！です。
運営の生の声が聞けることもあるだろうし、他のチームがどんなサービスを作ろうとしているのかとても参考になります。
チーム開発の時に役立ったもの
今までは精神論みたいなものが多かったですが、、、
チーム開発をするなかで便利だったものを2つだけ紹介します。
その1:コミュニケーションツールとコード管理ツールを連携する
チーム開発でのコミュニケーションツールは主にDiscordでした。
GitHubと連携させて変更履歴の通知を送る機能を設定したのですが、とても便利だったので紹介します。
私たちはpushするたびにBot通知がいくように設定しました。
下記画像のようにDiscordの通知が来ます。
簡単に設定できるのでおすすめです。
GitHub Docs - webhook について
Webhook Resource - Execute GitHub-Compatible Webhook
その2：GitHubにテンプレート登録をする
GitHubにイシューとプルリクのテンプレートを登録しておいたのが非常に便利でした。
1.チェックリストを作ることで、それぞれ書くべきことの抜け漏れ防止になる
2.人によって書き方が異なるので、テンプレートを作っておくことで見やすくなる
２つの観点からとてもおすすめです。
テンプレートの登録方法はGitHubの画面からもできるみたいですが、我々はターミナルから登録・編集していました。
初期の段階で雛形に何を書くのか話し合いをしておくと、後から悩まずに便利です。
公式のドキュメントにテンプレートの利用方法があるので、下記リンク先を参考にカスタマイズしてみてください。
GitHub Docs - Issue & PR templates
未経験者こそハッカソンに参加するべき
最後に、考察とは関係ないですが、一言述べさせてください。
ハッカソンじゃなくてもいい、未経験者こそチーム開発に参加するべきです！！！
実際に、実務に入ると、一人で開発することなんてほぼないですよね。
嬉しい瞬間やイライラする瞬間で自分の性格がわかったり、
役割分担で得意なこと不得意なことが見つかったり、
自分よりつよつよな人に便利なコマンドやツールを教えてもらえることもありました。
全然プログラミング出来ないしチームの人に迷惑をかけるの怖いな〜〜〜って気持ちは凄く分かりますが、業務で本番やらかすほうが絶対きついです。
Rails newの数だけ強くなれる、コンフリクトの数だけ強くなれます。
いちばん最初は、タスクを振り分けるために、gemを入れる作業をそれぞれに割り振ったことで、コンフリクトのオンパレードでした。
初歩的なミスでお恥ずかしいですが、No Newline at End of Fileで怒られたりもしました。
チーム開発を経験した今、少しだけ、GitHubとお友達になれたような気がします。
チーム開発はGitHubの操作にも慣れるし、新たな発見もあるし、本当にいいことしかないです。
勇気を出して一歩踏み込んでみましょう！！！！
最後までお読みいただきありがとうございました。
少しでも参考になれば幸いです。