導入

　初めてのAdventCalender企画も残りあと2日です。
　読んだ方も、書き手として参加した方も、楽しんでいただけたでしょうか。
　今回は、箸休め的にハッカソン参加＆運営の経験者としてノウハウを伝えたいと思います。

自己紹介

　前提として、自分自身の経験値としてはこんな素性になります。

システム業界経験　→10年以上
社内のハッカソン参加　→2回
ハッカソン、アイデアソン運営　→4回
デザインシンキング研修講師　→多数
オープンなハッカソンイベントは参加経験無し
エンジニアスキル的にはオンプレのインフラ歴が長くフルスタックには至らず、ローコード使えば何とか
AIスピーカーなどIoT機器や新しいWebサービスは一通り手を出す方
最近のマイブームは家の光回線を解約し、遊んでた格安SIM＋据え置きLTEルーター
でスマートホームの回線を確保しつつ、クラウドSIMを採用したどんなときもWiFiのモバイルWiFiで通信費削減＆アウトドアのネット環境を強化したこと

どうすれば勝つか

まず、ハッカソンで勝利するための条件を確認します。
多くのイベントでは、オーディエンスや複数の審査員による投票方式を採ります。
なので得票数で1位になったら勝ちです。
どういう作品に票が集まるかと言えば、審査基準はいろいろ書いてるかもしれませんが、要は

欲しいね（実用性がある）
楽しいね（ネタ感がいい）

と思わせることです。
更に、票を投じる人の属性によっては違った観点も必要です。
例えば企業が自社のサービス、製品を使ってというレギュレーションの元に開催している場合は、企業が審査員を立てることになるでしょう。
その場合は製品が主役になる、「お手本のような使い方」が出来ているかもファクターになります。

何が難しいか

次に、勝利へ近づくために障壁となるポイントを纏めてみます。
この辺りをリスクマネジメントできるのが強いチームです。

時限
- 与えられる時間は、非常に短時間であることが多いです。（Yahoo! HackDayは24時間）
- 限られた時間内にサービスを形にすることが求められます。
実装スキル
- 作るものが決まってから技術を習得し始めては遅れを取ってしまいます。
- あまり背伸びして技術を入れ込みすぎても未完成になるリスクもあります。
- 作りあげるのがゴールの状況においては、広く/浅くより、狭く/深く攻めた方が成功するでしょう。技術の数よりも、使い込みで魅せるということです。
- 勝負はイベントの前から始まっていると心得て、日頃から使える武器（技術）を集めておくと強いでしょう。
基盤スキル
- 基本的にIaaSはお金、構築の手間もかかるので、SaaSを中心にサーバレスで構築出来ると低負荷です。
- また、IaaS,PaaSを使うとしても、AWSよりもIBM Cloud、Microsoft Azureの方が無償で使える範囲が広いです。
- AWSは無償枠超えても青天井ですが、Azureは打ち止めの仕組みもあって親切です。
- 他にもIFTTTやGoogleドキュメント、SNSのAPIなど既存のSaaSを活用するとサービスに厚みが出たりコード量が削減できて生産性が格段に上がります。
アイデア
- 「それ、既にあります」なサービスを自信満々に紹介されても、がっかりですね。開発した側からしてみれば、SanSanのCMよろしく、「それ、早く言ってよぉ〜」かもしれませんが、後の祭りです。
- がっかりだけでなく、既存のサービスの方がクオリティ高いです。
  - これを「車輪の再発明」と言います：「重いものめっちゃ簡単に運ぶ方法思いついた」　→「それ車輪だよね」
- 新しいITサービスについて、日頃から情報収集はしておきましょう。何かネットサーフィンしてる時に情報をキャッチしたらどんなサービスなのか確認するとか、例えば直近だとYhoo！とLINEが統合してどんなサービス始めようとしてるかなど、メジャーどころだけでも十分です。
- 練っている間に、意図せず既存のサービスに寄っていってしまう場合もあります。時々立ち止まってチェックしましょう。
- Googleドキュメントの機能など、思わぬメジャーどころに強力なライバルが潜んでいます。こんな機能ないの？に対して、思わぬ方法で実現できてないかググりましょう。もし既にあるけど少し足りてないなら、それを利用して新しい価値を生み出すというのもアリかもしれません。
  - 例：コメント弾幕
  - PCでプレゼンテーションのスライド再生中、聴講者が質問やコメントを投げて、同一スクリーン上に重ねて表示する、ニコニコ動画の弾幕みたいなものが欲しいケース。順当に考えるとクライアントアプリとして動作して表示させるところ、スライドをWebアプリであるGoogleスライドを使用する前提で、ChromeブラウザのChrome拡張機能でHTMLを改変できることを確認。拡張ツールとしてスライドのHTMLにコメントの情報を追加してWebアプリとして持ち合わせのスキルセットで簡単に実装する事に成功。

何をすべきか

各ステップごと、何に気をつけて進めるべきか纏めてみます。

1. チームビルディング

通常は複数人で臨む場合が多いと思います。
チームを組んでから申し込む場合、申し込んでからその場で決める場合、まちまちと思いますが一般的な話として考えてみます。

Oneチーム
目標、価値観のすり合わせをすることが重要です。
技術に長けた人がどれだけいるか、よりもチームワークを発揮することの方が、遥かに生産性に寄与します。作れる人がたくさんいたところで同じ目標を共有できていなければ、船頭多くして船は山に登ります。
そのためには、「否定しないこと」、「ポジティブなムード」が、特にアイデアのブレスト段階で重要です。
「なぜ出来ないか」でなく「どうしたらできるか」を考えましょう。人が挙げたアイデアに乗っかり、捻り、新しいアイデアを生み出しましょう。
良いサービスは、良い雰囲気の中で生まれます。
多様性
仲良しグループで構成する事によるメリットもありますが、初めましての人同士で組んでも、大きなメリットがあります。まず、旧知の仲でなければお互い敬意を持って接するはずなので、お互い肯定してポジティブな雰囲気が作りやすいです。
また、アイデアは色々な所に転がっているので、異なるクラスタの人の方が、自分が持っていない知見を持っている可能性が高く、よりアイデアの幅が広がります。案外、固定概念のない素人から新しいアイデアが出てきたりするものです。

2. サービス設計

ここのアウトプットが、優勝できる可能性の大部分を左右します。

3. システム設計・実装

さあ、どのようにユーザーを満足させるか決まったら、形にしていきましょう。

技術選定
上に挙げたように、スキルエリアについて力量と相談して適切に選択し、必要以上に手を広げないように狭く/深く、を意識して進めてみてください。
プロジェクト管理
ここでは開発の進捗管理や問題の解決能力が勝敗を左右します。
ここがハッカソンのソン（マラソンのソン）たる所以で、ユーザー満足度への欲求、言い換えると勝利への欲求を原動力としてスタミナを維持しましょう。そして、チームワークを発揮して駆動力を推進力に換え、効率的に進めたいところです。Gitでソースを共有したり、NetlifyやGitHub Actionsでデプロイの負担を軽減したり、Tarelloでタスク管理したり、便利なツールを活用しましょう。
MVP
「必要最小限の構成」です。
サービスのメリットを感じてもらうため、ユーザーの満足を得るために、最低限どのユースケースが必要か見極め、何よりもまずそれを実現させましょう。あれもこれも中途半端に手を出した挙句、何も完成してないでは、サービスの価値を評価しようがありません。
UIへの偏り
良くある落とし穴が、UIばかり綺麗に作り上げて、裏側の処理は空っぽ、という事態です。UIが出来ると華があり作った感が出ますが、UI部分だけで新鮮味を出せるのはIoTやAR、ゲームなど限られたケースだけです。一般的なWebアプリやモバイルアプリの場合は、綺麗なUIはMVPに含まれないので程々にして、まずはビジネスロジックを組み立てましょう。
俳優、阿部寛のWebページは高速にロードされることで有名です。最近は動画コンテンツなどで重いサイトも多いですが、シンプルな構成で圧倒的なユーザビリティを提供しています。UIに拘り始めてしまったら、阿部寛を思い出しましょう。ちなみに阿部寛のサイトをPageSpeed Insightsで分析すると、「計測不能」になります。
変化への対応
メンバーで議論を重ねる中、サービス設計に影響するような変更が出てきて、いつの間にか変な方向に走ってしまうケースがあります。サービスの哲学はブレていないか、都度チェックしましょう。
技術を活かして新しい価値を生み出す
色気を出して新しい技術を取り込みたくなるギークな気持ち、わかりますが、ほどほどにしましょう。技術オリエンテッドでなく、サービスオリエンテッドで考えることです。技術に踊らされることなく、技術を使いこなしましょう。
ご参考
エンジニアが作るネットサービスのアイデアがしょぼいワケ

4. 発表

デモは難しい

過去に発表の場でデモをしようとしたことがありました。見事に動かず大コケした痛い思い出です。非常に短い時間で発表を纏めるため、発表者がリアルタイムでデモすべきでありません。
大抵は細かいレスポンスの悪さであったり粗が目立ちやすい上、発表のテンポも崩れ、伝えるべきことも伝えそびれてしまいます。
発表者は、アプリケーションの画面は動画に撮っておき、適宜ステージ上でデモンストレーションも交えて伝えましょう。
リアルに、使えるもの作った感じを伝えるにはアプリを聴講者に公開して触ってもらうのが良いでしょう。
目的に忠実に、シンプルに

プレゼンテーションの目的を意識して、シンプルに纏めましょう。
あなたがプレゼンする目的は、サービスを紹介することではないはずです。そのサービスが欲しいと思わせ、投票させる必要があります。サービスの世界観を丁寧に作り上げ、聴衆を引き込み、共感させます。
その為にも、サービスの哲学が明確で、それを叶える機能が整っていることが重要です。
この記事を書いていたら、PDD/プレゼン駆動開発という言葉を見つけました。
開発者として押し出したいポイントを強調するのではなく、プレゼンのストーリーを重視しましょう。発表がゴールのハッカソンにおいては、ストーリーを組み立てる為に必要なもの、プレゼンウケするものに注力して開発を進めます。

ヒラメキの源泉

短期間でそれっぽい新たなビジネスモデルを考え出すのは、そう簡単なことではありません。日頃の鍛錬が実を結びます。
例えば私が新しいサービスを目にした時、こんなことを考えます。

どういうビジネスモデルか
何が新しいか、二番煎じならどう差別化してるか
なぜ、今リリースしたか、背後に法改正があるのか、技術が成熟してきたからか
自分の組織に応用できないか
世の中はどういうトレンドにあるのか

ブルーオーシャンを作り出すことをアドバイスしましたが、Facebookは世界初のSNSではありません。Googleも、Youtubeも同じくその業界の第一号ではありません。
ちょっとしたことで差別化し、他の追従を許さない圧倒的なサービス品質で登り詰めたわけです。
スティーブ・ジョブズやイーロン・マスクみたいに、自己流のセンスを押し出して世に受け入れられたケースもありますが、そんな芸当は一部の天才にしかできません。
一般人はとにかく他のサービスを分析して、真似しながら、新しいサービスを練っていきましょう。きっと他のサービスも似たような経緯を辿っていると思います。

締め

如何だったでしょうか。
どうこう言っても、参加してやってみるのが一番です。
参加して初めて、このサービスを作る為にはこんなスキルが必要だ、とか、
触ったことがある技術を使ってみたけど、使いこなせるレベルになくて苦労した、とか、色々気づきがあります。

そろそろ来年の抱負を決める時期ですが、来年はハッカソン参戦、で決まりですね。
そして終わった後に、チームで美味い酒を飲みましょう。

それでは神のご加護を。
Merry Christmas🎄