ハッカソンの要素分解
- ハッカソンを10月に控えており、かなり開催が近づいてきている
- 前回、『我々が創ってきたもの、そしてこれから』において、チームの持つ思想性や哲学の整理、そしてその実現に向けた反省を行った
- 今回はもう少し実務的な部分として、ハッカソンのプロセスを分解し、それぞれのプロセスにおける整理を行いたい
これまでの反省
Section titled “これまでの反省”- 技術の真新しさや、見た目の衝撃というところにばかり着眼していた
- せいぜいやっていたこととすれば、事前の技術検証や開催後の簡易的なKPTぐらい
- それによって、チームが持つ思想性や哲学を磨くことや、ハッカソンの各プロセスでの立ち周りの練度が蔑ろになっていた
- 睡眠不足のストレスもあるが、個人主義的な状況になりがちで、「チームで作っている」という意識がなくなりがちだった
- 結果的に、「何がしたいのか分からなくなった」「動くところまで持っていけなかった」「上手く伝わらなかった」「ハッカソン外での開発まで繋がらなかった」ということが起きていた
- 今回からはそういうことをなくしていきたい
- なお、技術的な観点での整理や反省については次週以降、詳しく行う予定
ハッカソンの目的
Section titled “ハッカソンの目的”- ハッカソンをプロセスとして分解する前に、まずは自分たちがハッカソンで目指す方向性について定義する
- なぜかというと、プロセスというのはゴールありきのため
- ハッカソンは「お題」「テーマ」という制約に合致した作品を作り上げることが前提
- ※ 一部、お題やテーマが用意されていないハッカソンもあるが、その場合でも自分たちで定めるべき
- その制約の中で、いかにユーザの問題を解決したり、もしくは心を動かすような作品として形にするか
- 作品は実際に動作するプロトタイプを発表によって齟齬なく魅力的に伝える
- 究極的には、その作品で一番伝えたい機能が動作していれば良い
- ハッカソンの規模感やレギュレーションに依存する部分ではあるが、動作を担保するテストコード、スケールを意識したアーキテクチャ、セキュリティ的に堅牢な実装等は基本的に不要
- これをMVP(Minimum Viable Product: 実用最小限の製品)と呼んだりする
プロセスの全体像
Section titled “プロセスの全体像”- 仕事で行っている開発を１日に押し潰したもの、と言えるかも
- 事前準備
- ハッカソン当日を迎えるまでに、各自できることをやっておく段階
- アイデア発散
- アイデアをどんどん出し、押し広げていく段階
- アイデア収束
- 出てきたアイデアを結びつけたり洗練させたりして、まとめていく段階
- 設計
- どんな機能をどんな技術で誰が実現するか、を決める段階
- 実装
- 実際に動作する作品を作り込んでいく段階
- 発表
- 作った作品を齟齬なく魅力的に伝え、理解してもらう段階
- 振り返り
- 各プロセスでどんな課題が生じ、どうしたらそれを解決できるかを考える段階
- ということでここからは各プロセスの詳細を見ていく
- 準備がそれなりに面倒で、必要になる蓋然性が高い部分の準備
- デプロイフローの準備、認証機能の開発、フロントエンドから疎通できるかの確認
- 不確実性が高く、必要になる蓋然性が比較的高い部分の調査・準備
- 特定のWebAPIやライブラリ、センサーAPI等の取り扱い
- チームビルディング
- 特に顔なじみでないメンバーがいる場合には顔合わせを実施してお互いについて知っておく
- 担当・役割の仮決め
- 実際には横断的に動いたりすることもあるため仮決め
- プランナー、ファシリテーター、デザイナー、フロントエンド、バックエンド、プレゼンター、etc …
- 各メンバーの環境構築
- 最低限、自分がメインで担当する範囲
アイデア発散
Section titled “アイデア発散”- アイデアの作り方
- ジェームス・W・ヤングの書籍
- 「アイデアとは「既存の要素の新しい組み合わせ」である」と言っており、これは重要な視点
- ブレインストーミング
- メンバー同士の相互作用を通じてアイデアの量をとにかく出す
- 批判厳禁、自由奔放、量を重視、結合改善
- オズボーンのチェックリスト
- ブレインストーミングする上で使える問いの視点
- 転用できないか？、応用できないか？、修正できないか？、拡大できないか？、縮小できないか？、代用できないか？、置換できないか？、逆転できないか？、結合できないか？
- これを整理したものとして、SCAMPERという手法も存在する
- マインドマップ
- 脳内に出てきた言葉を連想ゲーム的に書き出し、言葉同士の関連性を探っていくことができる
- 書き出し方は基本的には真ん中にキーワードを書き、そこから枝を広げていく方式
- 出力がボトルネックになり、思考が止まりがちなので以下に気をつける
- マインドマップ固有の書き出し方に必ずしも囚われなくて良い
- 紙とペンという使い慣れた道具で自由に(そして雑に)書き出す
アイデア収束
Section titled “アイデア収束”- KJ法
- アイデアを意味の近さや関連性に基づいてグルーピングする
- ほぼ同じだが、QC七つ道具のひとつとして整理された「親和図法」と呼ばれる手法もある
- 批判的思考
- アイデア発散とは異なり、この段階では、ある程度の批判的なものの見方が必要になる
- 批判的、というのは人格否定や荒々しい口調を肯定するものではなく、物事を多角的に吟味して妥当性を判断するということなので注意する
- どういう課題を解決するのか？どういう問題を提起するのか？課題解決や問題提起に対して良いストーリーを描けているか？お題にマッチしているか？新規性はあるか？に論理的に答えられているか
- ※ Web開発が前提になっていることに留意
- 機能の分割
- １つのゴール(≒体験)に対して、どんな機能群が必要となるか
- 機能の優先順位付け
- 絶対にやりたいもの、できればやりたいもの、やらないものを分類する
- 技術選定
- ここに関しては次週以降に深堀りする予定
- より多くのメンバーが触れる言語やフレームワークを採用すべきで、技術的な挑戦は避けられるに越したことはない
- UIデザイン、画面遷移図
- Figma等のサービス上で構築する
- どんな操作・フローでユーザが体験を得られるのか、に対する共通認識を持つ
- ハッカソンでは厳密に定義する必要はなく、フォームやボタンの配置、トンマナが伝われば良い
- 残りは実装でカバー
- ドメインモデリング
- 用語に対する共通認識を持つ(DDDにおけるユビキタス言語)
- 概念(エンティティ/値オブジェクト)とそれらの関係性の整理
- ユースケースの整理
- 重要な状態遷移の整理
- 不変条件の整理
- マークダウン等の形でドキュメント化されているのが望ましい
- API設計
- UIデザインに対してどんなエンドポイントが必要になるか
- それぞれのエンドポイントではどんなリクエストとレスポンスが必要か
- OpenAPI(SwaggerやReDoc等)の形でドキュメント化されているのが望ましい
- DB設計
- テーブルとして起こしたいもの≒永続化して扱いたいもの
- エンティティがテーブルに対応することが多い
- バックエンドエンジニアしか基本的に見ないので、コード上でマイグレーションファイルやモデルとして表現されていれば必ずしもドキュメントは必要ではない
- タスク洗い出し
- GitHub上にissueとして作成する
- タスクのアサイン
- メンバーそれぞれの持ち味を活かす
- 常に「ここまでは動く」という状態を作ることで、完成しなかったとしても途中までは見せられる状態にする
- デプロイを後回しにしない
- フロントエンドとAPIの繋ぎこみを後回しにしない
- AI時代を前提にする
- Vibe Coding/Agentic Codingの習得
- AIチャット(ChatGPTやClaude、Gemini)が使えるだけでは時代に取り残されている
- 主要なAIエージェント(Claude Code、Cursor、Cline、Gemini CLI、Codex CLI)をどれかひとつでも使える状態になっておくのはマスト
- 頑張って作っても、それが伝わらなければあまり意味がない
- 発表資料の作成
- スライドであることが多い
- ユーザはどんな体験ができ、どんな価値が得られるか？が伝わるか
- 何がどうなるものなのか？が伝わるか
- どこにユニークなポイントがあるか伝わるか
- 聞き手の処理能力を高く見積もって、あれもこれも伝えたいと詰め込みすぎない
- 分かりやすい構成を心がける
- タイトル -> テーマの振り返り -> 課題の提起 -> アイデアの提示 -> デモ -> 技術的なポイント -> 将来の展望 -> まとめ
- デモでは基本的なユースケースを見せる
- 心に刺さる魅力的なメッセージ(レトリック)
- リハーサル
- 時間内に収まるか
- 客観的に見て伝わっているか
- 本番
- 「間」と緩急を大事にする
- 思っている以上にゆっくり話す
- 話し手は内容を知り尽くしているが、聴衆はその場で初めて聞くという非対称性がある
- KPT
- 続けたいこと、問題だったこと、次に試したいことの整理
- 具体的で小さいアクションを作ることを心がける
- ハッカソンだけでなく、日々の開発等にも還元できると尚良し
プロセス全体を通して
Section titled “プロセス全体を通して”- みんなで作るという意識を持つ
- 積極的にペアプロ・モブプロを活用する
- 実装段階だけではなく、全てのプロセスにおいて、みんなでやるということを意識する
- 困ったらすぐ相談、困ったらみんなで解決
- マイクロマネジメントはしない
- 自分の担当領域を責任を持って遂行する
- ただし、メンバー全員が同じ方向を向けているかの確認は重要
- 寝る
- 入念な事前準備や確立されたプロセスによって、無駄な時間を圧縮することで、睡眠のための余白を生み出す
- 健康的に楽しんで終えられるのが理想
プロセスを整理してみて
Section titled “プロセスを整理してみて”- いくつか実行できそうな良いアイデアが思い浮かんだ
- 各プロセスをチェックシートにまとめる
- 今、自分たちがどこにいるのか？というのを、いつでも客観的に見れるようにする
- ブレストをサポートするツールを作る
- アイデア発散段階で疲れ果てることが多いので、それを補助するツールを作る
- Word2Vecを使ってベクトル値が遠い単語同士を結合し、それを生成AIでオズボーンのチェックリストベースで複数案出してもらう
- 一人日くらいあれば実装できそうなのでやってみる予定
- スライドの雛形を事前に準備しておく