ハッカソンのアイデア出しで使ったフレームワーク

ハッカソンでは、限られた時間のなかで課題を見つけ、実装できる形までアイデアを絞り込む必要があります。思いつきをたくさん出すだけでは、開発の途中で目的が曖昧になりやすいため、チームで考えを整理する仕組みが重要です。

今回は、私がハッカソンの企画段階で使った発想法や整理の手順をまとめます。Webデザインやスマートフォンアプリの制作経験を活かしながら、ユーザー視点と実現可能性の両方を確認することを意識しました。

テーマを自分の言葉に置き換える

最初に行ったのは、ハッカソンから提示されたテーマを短い言葉に置き換える作業です。「地域活性化」や「働き方」のような大きなテーマは、そのままだと解釈の幅が広すぎます。

そこで、「誰の」「どんな場面で」「何に困っているのか」を書き出します。テーマを生活の具体的な場面へ落とし込むと、解決したい課題を見つけやすくなります。

次に、想定ユーザーを一人の人物として設定しました。年齢や職業だけでなく、普段使っているサービス、行動する時間帯、感じている不満まで考えると、機能の優先順位が見えてきます。

ペルソナは細かく作り込みすぎず、チーム内で共通認識を持つための道具として使います。「この人なら本当に使うか」と問いかけることで、開発者の思い込みを減らせました。

アイデアを広げる段階では、中心にテーマを書き、関連する言葉を枝のようにつなげるマインドマップを使いました。課題、場所、感情、既存サービス、使えそうな技術など、視点を変えながら単語を追加します。

この段階では、実現できるかどうかをすぐに判断しません。突飛に見える案も残しておくと、複数の要素を組み合わせた新しい企画が生まれます。

出てきた言葉や課題は、付箋に一つずつ書いて分類しました。「困っていること」「すでにある解決策」「使えそうなデータ」「技術的な制約」といったグループに分けると、情報の偏りが分かります。

オンラインのホワイトボードを使えば、離れた場所にいるメンバーも同時に編集できます。付箋を動かしながら話すことで、発言の少ない人の視点も拾いやすくなりました。

表面的な要望に対して、「なぜそれが必要なのか」を何度か繰り返して確認しました。たとえば「情報をまとめたい」という要望の背景には、「比較する時間がない」「信頼できる情報が分からない」といった別の課題が隠れているかもしれません。

原因を深掘りすると、単なる便利機能ではなく、利用者の負担を減らす体験として企画を考えられます。画面を作る前にこの確認を行うことで、不要な機能を減らせました。

候補が増えたら、面白さだけでなく、課題の強さ、ユーザーへの効果、実装可能性、発表時の分かりやすさで評価します。各項目を五段階で採点すると、感覚だけに頼らず比較できます。

技術選定に迷ったときは、実装経験のあるメンバーの意見を早めに聞くことも大切です。SwiftUIとUIKitの使い分けを考えた経験については、SwiftとUIKitの比較も判断材料になりました。

最終候補が決まったら、いきなり完成版を作らず、紙や簡単な画面モックで利用の流れを確認します。「最初に何を見るか」「次に何を操作するか」を追うだけでも、分かりにくい導線が見つかります。

チーム内で説明する際は、機能一覧ではなく、利用者の一日の場面に沿ってデモを組み立てると伝わりやすくなります。発表資料を作る前に、他の人へ質問で深める勉強法を参考にした確認を行うと、説明の弱点も見つけられます。

以下の手順を組み合わせると、発想を広げる時間と、企画を絞り込む時間を分けて進行できます。

ハッカソンのアイデア出しで使ったフレームワークは、企画をきれいに見せるためだけのものではありません。チームの認識をそろえ、限られた時間で作るべきものを判断するための補助線です。

次回のハッカソンや個人開発では、まず身近な課題を一つ選び、今回の手順を小さく試してみてください。考えた過程やプロトタイプを記録しておくと、次の制作や発表にも活かせる材料になります。