ハッカソンの勝ち方

40回以上ハッカソンをしてきた学生エンジニアの教える体系的なハッカソン指南書。ハッカソンで「アイデアは出るのに最後まで走り切れない」「賞を狙う作り方が分からない」と感じているエンジニア向けに、企画立案から発表までの全工程を体系化した実践書。初参加者にも、勝ち筋を磨きたい経験者にも使えます。

Transcript

1. Hackthon やづや ハッカソン資料
2. 対象読者とこのスライドの目的 00 ハッカソンを一回でもしたことがある人 ハッカソンをこれから優勝したいと思っている人 僕とハッカソンをする人 対象読者 目的 ハッカソンで勝つためにはどうすればいいか？を突 き詰めた指南書 学びの多いハッカソンのための指針 勝つためには手段を選ばない人のための指南書
3. 優勝への筋道 00 チームビルディング 作るものの決定 実装準備 ハッカソン開発 スライド・改善 ハッカソンの全体像 チームをどう作るのか？ どうアイデアをつくり決定するか？ 実装のための準備をどう行うか？ 開発はどうすすめるか？ どうプロダクトを見せるのか？
4. 優勝への筋道と目次 00 1.目標共有 2.自己紹介（チームビルディング） 3.アイデア出し　 4.目的整理・MVP整理 5.要件定義・技術要件定義 6.環境構築・技術調査 7.スケジューリングと開発方法 8.作業会の設定 9.技術的検証（MVP実装） ・曳光弾開発 10.ハッカソンのための実装検証 11.ハッカソン開発 12.ヒアリング・トラクション 13.改善・DEMO作成とピッチ準備 14.マーケット検証（MPF検証） 15.ピッチ作成 16.ハッカソンの勝ち方/考え方 17.AI前提の時代のものづくり チームビルディング 　 作るものの決定 実装準備 ハッカソン開発・改善 スライド・改善 1, 2　 3, 4　 5～8 9～12 12～16 ハッカソンの学び方 17～ ハッカソン 準備 ハッカソン 本番 ハッカソン 後
5. 01 チームビルディング 作るものの決定 実装準備 ハッカソン開発 スライド・改善
6. 目標共有 01 ハッカソン優勝！！ 結果としての目標 最大の目標 使えるものを作る！！ ハッカソンで勝つための指南書
7. ハッカソンでは基本的に 「使えるもの・使ってもらえるもの」 が強い ハッカソンで勝利をするには？ 基本方針 目標共有 01 アイデアが実現し、使えるものを実装する！！
8. 目標共有 01 優勝するためには手段を選ばない人のための指南書 手段を選ばないとはどのような手段でも確実に行動するということ 手段を選ばないとは？ 優勝するためには？
9. 自己紹介 02 1.名前 2.何が出来るか？自分の担当領域 3.趣味と興味 4.ハッカソン経験について 5.自分について知ってほしいこと　etc... チームのコミュニケーションを活発にする チームメンバーとは議論する際に心理的な安全性（性格などの個人 攻撃しない）などを持つことがハッカソンでは重要
10. 03 チームビルディング 作るものの決定 実装準備 ハッカソン開発 スライド・改善
11. アイデアだし（発散フェーズ） アイデアだしの方法は何でもOK クレイジー8 なぜなぜ分析 ブレインストーミング KJ法 解決したい課題がある！ 価値創造系(プロダクトアウト） キーワード列挙 やりたいことを列挙する 現在ある技術から考える SF的思考（未来から逆算） アイデアはここでは発散させてOK 03
12. アイデアだし（発散フェーズ） 03 アイデアだしアンチパターン 技術がすでにあるからといって安易に 技術から解決できる課題を考える 抽象的でとらえどころのないアイデア SNSやメモ帳・日記・出会い系アプリはやめよう 素人が安易に手を出すものではない。やるなら専門家を 1. 2. 3.
13. アイデアだし（発散フェーズ） 03 アイデアはいつでも変えていい（ピボットOK） 他人のアイデアは批判せず建設的な議論を 問いを投げかけてみんなで考える 1. 2. 3. アイデアだしで注意すること！
14. アイデアだし 03 アイデアの種類 社会課題・生活の課題を見つけて解決を模索する ＝マーケットイン 1. やりたいことをやる=プロダクトアウト 2. 技術的課題・学術的な課題を解決もしくは提案 =学術研究的側面 3. チームで何がやりたいか？が大事！！ 注）学術的な研究の側面はこの資料では適応範囲外ではあるが研究にフォーカスするならロジックをかなり組み立てる必要がある。そして研究としてそれが実現・わかったら 何がうれしいのか？研究として何が先駆的で面白い要素はどこなのか？について答える必要がある。課題の設定が大まかである場合にはかなり絞り込まなければその面白さを 伝えられない（課題感はかなり踏み込まなければならない） 注)
15. アイデアだし（議論フェーズ） 03 アイデアを深りして議論する 出したアイデアに対して発散からアイデア収束フェーズに入る ここで重要なこと アイデアの掘り下げ 課題の明確化・価値の明確化・何がしたいか？の整理 課題に裏付けはあるか？課題にイメージはつくか？ 仮説はあるか？（検証する方法） 専門家に聞く・メンターに聞く ヒアリングを行う（ドメインの人に聞く）
16. アイデアが出たら次のポイントが評価になる 誰のどんな課題を解決するのかがすぐに言える 解決策が明確・価値・裏付けが明確 具体的に提供するユーザーが見える 解決策の優位性が明確・すでに類似がいないか？ チームがやりたいか？・当事者性があるか？ 説明と具体的イメージが容易か？ これらが明確なら大体いいアイデア アイデアだし（議論フェーズ） 03 アイデアの評価軸 注）説明可能性の優先順位が低いのは基本的に誰もがわかるアイデアがいいアイデアとは限らなくて誰かに刺さっているか？ということが重要にな るため。例として旅行などは説明可能性が高いが特殊な事例は説明可能性が低くなりがちだが価値があればOK 優先度高 優先度低
17. 目的整理・MVP整理 04 ハッカソンで作る機能を選定しよう ハッカソンでは「すべて」は作れない 大前提 ハッカソンでは機能を選ぶ必要がある
18. 目的整理・MVP整理 04 ハッカソンで作る機能の目的を整理しよう 作る目的は何かを明確にする・なぜ作るのか？ 　　 （人の交流を促進したい・動画を作りたい・業務効率化したい） 誰のどんな課題を解決するのか？ どのような価値をそのプロダクトはもたらすのか？ そのプロダクトは少なくとも一人以上には刺さるのか？ 　　 （＝使ってもらえるのか？）
19. 目的整理・MVP整理 04 MVPとして十分な価値があるもの その機能だけで十分新規性があるもの ユーザーにその機能だけで価値を届けられるもの MVP容易なもの？ コアな機能を実現するための基本機能 提供価値の方針がぶれていないか？ チームの合意が取れるか？ コアな機能に付随する余計な機能は作らなくてOK 作る機能の基準
20. 目的整理・MVP整理 04 コアでない機能は作らなくてOK 例：AIメモ帳（AIが書いてくれる機能がコア） 　 　　　　コアを実現するための機能：メモ帳・Markdown記述 　　　　いらない機能：メモの管理機能・メモの共有機能 例：AI動画作成アプリ 　　　　コア機能：自然言語から動画を生成する 　　　　いらない機能：動画を保存する機能・動画の履歴保存
21. 目的整理・MVP整理 04 目的整理をして「微妙だ」と思ったときピボットという手がある ハッカソンでピボットするならアイデアだしの時 ハッカソンでアイデアが化ける（＝よいアイデアになる）時は三回あ りMVP段階・PMF段階・ピボット段階の三回 基本的に長期間でないばあいMVPで化けることを期待できないなら アイディアを考え直すのも手 MVPが作りにくいときもアイディアを変えるとよい アイディアを考え直すとき
22. ハッカソンでアイデアは二回化ける トラクション アイデアが化けるタイミング 04 アイデアだし MVP PMF 技術(PSF) 開発 ・・・・ MVPのタイミングとトラクションを得るタイミングで化ける MVまでで伸びるのはコア技術を開発できた時に化ける（独自ML/DL技術や独自ハードなど） MVP以降で伸びるのはトラクションによるフィードバックを筋がいい形でMVPに実装できると化ける それ以降はマーケティングによる拡散などでより大きくなる。
23. 05 チームビルディング 作るものの決定 実装準備 ハッカソン開発 スライド・改善 要件定義・技術要件定義
24. 要件定義・技術要件定義 05 作る機能が決まったら技術を決めよう 作りたい機能を作るために使える技術をピックアップする どのプラットフォームで作るかを考える iOS/Andoroid・Web・Unity/UnrealEngin ect... どのような言語・フレームワークが適切か？を決める Python, TypeScript, React, Next, Flutter, Unity ect... 選定基準は経験者が一人はいる言語が安心（興味先行の場合は 時間が許せばOK） 最新の言語・フレームワークはそれでしかできないとかでない 限りは使わない方が無難
25. 要件定義・技術要件定義 05 作る機能が決まったら技術を決めよう 技術にはWhy Techが重要 「なぜその体験をつくるためにその技術を使ったのか」が審査 員にわかるよう明示にしないといけない いろいろな方法が取れる中でこれが出来そうだったからとかは あまりよくない
26. 要件定義・技術要件定義 05 要件定義・デザインを決めよう どのような機能が要求されるのか？具体的な実装はどのように 行えばいいのか？を文章として簡単でもいいので書こう UI/UXを決めるにはデザインが大事 デザインが決まるとメンターなどに「何を作るか」が伝わる あとから「何を作ればよかったのか？」という疑問がなくなる とにかく可能な限りどのように実装すればいいか？がわかるよ うにしよう あいまいな言葉は定義しよう（ハッカソンのテーマなど）
27. 環境構築・技術調査 06 作る機能が実装可能かわからないとき 作る機能が実現可能かどうかわからない場合はプロトタイプを 作るための機能実装を行なう必要がある 先行研究・論文やすでに近い実装をしているプロダクトなどを あたってみて技術実装が可能かどうか？を判断する技術調査を おこなう 自力実装が困難な場合にはそのMVPを作るためには本当にその 技術は必要か？を試行する 先行技術がない場合はかなり難しいことをしようとしている
28. 環境構築・技術調査 06 環境を構築しよう ハッカソンでは時間がないため可能な限り環境の差異などで余計 な時間をとられるとプロダクトが完成しない・未完成で提出など の問題になりかねない（Mac/Windows/Linuxの環境差異など） Dockerやmiseなどが使える人がいればそれを使うのが簡単 短期間ならバージョンを一緒にするだけでもOK 長期間になるときには仮想環境は必須級 環境差異が大きい言語・フレームワークは要注意(Flutterなど） DBは使うなら先に用意しておくと吉
29. スケジューリングと開発方法 07 開発方法を設定しよう ハッカソンはハッカソン開発と呼べるほど限界の開発が要求される しかし似ている開発法はありアジャイル開発がある 基本的にハッカソンで開発方法は ウォータフォール開発（完全にやりたいことが決まっている場合） アジャイル開発（機能単位のサイクルで開発を繰り返す） 基本的にアジャイルを選択する。その中で ディリースクラム（アジャイル開発の一種でハッカソン向き） が基本的に選択される
30. スケジューリングと開発方法 07 大まかなスケジュールを設定しよう ハッカソンは時間がないためある程度のスケジュール感を設定する 基本的にハッカソン期間中に「何を目指すか」によってスケジュール が決まる（目標によって変化する） パターン1：MVPを目指す（初心者はここから） パターン2：MVPとトラクションを目指す パターン3：MVPとトラクションからPMFを目指す
31. スケジューリングと開発方法 07 大まかなスケジュールを設定しよう ハッカソンは時間がないためある程度のスケジュール感を設定する 例：三日間のハッカソンの例 １日目 2日目 3日目 アイデアだし・ヒアリング 環境構築・技術調査 デザイン・要件定義 実装 実装 プレゼン準備 プレゼン準備 発表準備 MVP完成・ （デプロイ） トラクション
32. スケジューリングと開発方法 07 大まかなスケジュールを設定しよう ハッカソンは時間がないためある程度のスケジュール感を設定する 例：一週間以上のハッカソンの例（MVP完成を目指す場合） １～2日目 2～6日目 最終日 アイデアだし 課題検証 環境構築・技術調査 デザイン・要件定義 実装 プレゼン準備 プレゼン準備 発表準備 発表 デプロイ ヒアリング
33. 作業会の調整 08 モメンタムを生み出そう ハッカソン期間中はモメンタム（チームの駆動力）が大事 どんな組織もモメンタムがなくなった瞬間に崩壊が始まる モメンタムを出すために 作業会などでプログレスフィードバック（成長を可視化する） 成果を生み出す！成果が出るチームはうまくいくし雰囲気がよくなる 雰囲気は成果が出たときによくなる（雰囲気がいいから成果が出るわけでない） とにかくハックする プロトタイプを他人に見てもらう（トラクション）
34. 作業会の調整 08 時間がある場合作業会を設定しよう ハッカソン期間中はモチベーションを維持するために作業会を設定する と全員が集まらなくても作業が進むかつ相談しやすい 作業会の効果 モメンタムが生まれる（これが一番大事） 全員の進捗を一覧にできる 自然に雑談と対話が生まれやすくチームの雰囲気づくりに有効 同じ目的を共有しやすくなり技術的課題を共有しやすい ミーティングと作業会の時に次の日程を調整すると〇（曜日固定なども〇）
35. 09 チームビルディング 作るものの決定 実装準備 ハッカソン開発 スライド・改善
36. 技術的検証（MVP実装） 09 MVPを作るための技術を獲得し実装する 基本的にMVPを作る場合には知らない技術や触ったことがない技術の場 合MVPを作るためにはどうすればいいのかでやりたいこと志向で技術を 学習するとよい チームのドメインがある場合はそのドメインをフル活用する 知らない技術で実装する場合はハッカソン三日では足りない 曳光弾開発を使うのも効果的 MVP実装のための技術的Tips
37. 技術的検証（MVP実装） 09 曳光弾を打ち上げる 基本的にMVPを作る場合にはある程度詳しい人がいればバックエンドか らフロントエンドまで一貫して先に作りそれを補強する曳光弾開発がか なり有効 簡単な機能が一貫して実装されているフレームワーク（例：APIからフ ロントエンド接続・DB連携済など）がある場合はそれを用いるとデモ・ テスト・進捗が分かりやすい ChatGPTなどでコードの型を生成するか既存のものを使う
38. 技術的検証（MVP実装） 09 MVPを作るときは「ダサいもの」でOK MVPは常に大体「ダサい」ものである ただボタンがあったり、もっと言えばコードすらいらないかもしれない 例： 習慣化のための記録アプリのプロトタイプ ボタン一個だけでその時刻が記録されるだけ キャラクターと一緒に勉強できるMRアプリ 例： ChatGPTにプロンプトを入れてキャラクターになり切って もらって勉強についてタイピングで教えてあげる
39. 10 MVPを作るための実装を行う ハッカソンのための実装検証 基本的に実装は現在使用可能な技術をどう使うか？が大事 実装とはアイデアを実現するための方法論である 要件定義・機能要件が決まった後はその技術が使用可能であるか どうか？そしてコア技術を実装することができるか？ Issueを書いて実装における課題をタスクとして書いていく 要件定義と機能要件をブレイクダウンして詳細設計を行う
40. 11 ハッカソン当日の進め方 ハッカソン開発 すでに技術検証とMVPプロダクト開発を進めておく 当日には手を動かせばよい状態にしておく 基本的にはコア技術などは確実に検証しておきハッカソン当日に はハッカソンでありがちなエラー修正などを行うようにする 基本的な実装などはAIドリブンでもよいがコア技術は明確に書く 必要がある
41. 11 ハッカソン当日の進め方 ハッカソン開発 基本的にディリースクラムを行う（15分以下で） 昼やメンタリングの時間などの区切りのタイミングで現在の進捗と 次のタスクとゴールをはっきりさせる 進捗状況を明確に分ける（エンジニア・ピッチ・アイデア部分） エンジニアに共有すべき情報をリーダーが渡す 問題を抱えている場合はほかの人がサポートする リーダーは全体か？エンジニアだけか？個人に共有か？を判断
42. 11 ハッカソン開発について ハッカソン開発論 ハッカソン開発でやらなければならない必須事項 メンバー全員のgitHubアカウント、figma, メールアドレス、Slide 資料などの共有, google Driveなどの共有（複数メールアドレスも あり） タスクの分割・コーディングの要件（MVPレベル）の決定 スケジュールの確認（タイムマネジメント） タスクを割り振り
43. 11 ハッカソン中にやること一覧 ハッカソン開発論 環境構築（Dockerコンテナ等） コーディング・インフラ整備 バックエンド フロントエンド デプロイ スライド作成・ピッチ準備・動画準備
44. 12 チームビルディング 作るものの決定 実装準備 ハッカソン開発 スライド・改善
45. ヒアリング・トラクション 12 MVPを人に見せに行こう MVPが終わったら次にトラクション（ユーザーの声）を得ることで プロダクトのユーザー価値を評価できる 知っている・仲がいい人・応援してくれる人・一番近くにいる 人・先輩などでOK 専門的な場合は専門の人に見てもらいに行く ハッカソンの場合はメンターに途中でも見せに行くとよい 聞きに行く人
46. ヒアリング 12 課題を見つけるためのヒアリングをおこなう MVPが終わってもまだPMFに向かうために実際に使ってもらう人 の課題感を聞こう 構造化と非構造化の中間 ヒアリングの方法 構造化インタビュー 半構造化インタビュー 非構造化インタビュー 聞きたいことをリストアップする形式 自由に聞きたいことを質問する形式
47. ヒアリング 12 課題を見つけるためのヒアリングをおこなう 半構造化インタビュー 事前にある程度の聞きたい質問を持ってそのあとに潜在的な ニーズを聞く方法そして途中でMVPプロダクトを見せると現 場の課題感を聞いたうえでトラクションも得ることができる 構造化された質問 興味深い質問 課題・その質問を深ぼり 具体例・事例
48. ヒアリング 12 　ヒアリングで注意すべきこと 基本的にプロダクトは後で見せる（見せられたプロダクトが欲しく ないですという人はほとんどいない） 常にヒアリングした人の話が正しいわけではない（課題だと言って いることに対して本当は別の本質的課題があるかもしれない） ドメインに詳しくても知らないふりをしたり相手の課題の推測をし たりすると相手がかなり話してくれる
49. 改善とピッチ準備・DEMO作成 13 改善フェーズ ハッカソンで改善フェーズまで行けることは少ないというかない ただしプロダクトが化けるのは三つ ピボット時・MVP時・トラクション後の改善 それでもMVP後に改善する時間がある場合は MVPであきらめた機能などをつけること 非機能要件を満たすこと リファクタリングにより完成度を高める方向性で改善 トラクションによる改善が最優先事項
50. 改善とピッチ準備・DEMO作成 13 改善フェーズ 改善するのはプロダクトだけではなくアイデアも改善することが できる 現在のMVPが誰のどんな課題にフィットするのかをピッチを作り ながらもう一度考える このプロダクトによってどのような未来を考えられるか？ 裏付けやヒアリングとトラクションの結果を踏まえてさらなる改 善の方策を考える
51. 13 ピッチ作成はMVPが8割できたタイミングで 基本的にモック的なMVPが出来たタイミングでピッチは 整理のために作る 基本的にピッチは誰がどんな課題を持っていてどのよう に解決するのかをピッチ資料として魅せる MVPが8割出来たタイミングくらいで作るのが基本 時間がある場合はMVP出来た以降でもOK アイデアだしのタイミングで作るとピボットが出来なく なる可能性があるためアンチパターン 改善とピッチ準備・DEMO作成
52. 13 勝つためのピッチはすごそうに見せる どのようなハッカソンに出るかによるが、ハッカソンの審査は 誰が投票するのかとどのような基準かが重要になる 誰が審査するのか？ オーディエンス投票 審査員 スポンサー オーディエンス投票は特にデザインとすごそう感がかなり大事になる 改善とピッチ準備・DEMO作成
53. 13 勝つためのピッチはすごそうに見せる 凄そう感が出る部分をまとめておく 課題感（ユーザーが誰でもわかる・思いつかなかった・隙間をつく） 技術（レベルの高い技術・最新技術・独自技術・XR/ハード） デザイン（デザインのクオリティが高い・刺激的・魅力的） 実装量・デプロイ（すでに使える動いているもの） プレゼンスキルとデザイン（プレゼンするキャラクター性と声など） 基本的オーディエンスにイメージをつかせなければ意味がない イメージが出来れば高い評価をつけやすい 改善とピッチ準備・DEMO作成
54. 13 審査基準をピッチに必要十分に載せる 審査基準はいろいろ存在する 課題感（ターゲットユーザーと課題が明確か？） 技術力（どれだけ最新技術を使っているか？） 作りこみ（どれだけユーザーを考えているか？） ビジネス（どれだけマーケットが存在するのか？） デザイン性（プロダクトデザインとスライドデザイン） ピッチのうまさとキャラクター性 すごそうさと基準はかなり一致している 改善とピッチ準備・DEMO作成
55. 13 DEMOを作ろう！ 改善とピッチ準備・DEMO作成 DEMOは基本的に作らないと実際に動作していることが保証されない ハッカソンでは動かないプロダクトは評価が一段と低くなる 超短期間ハッカソンのときはUIだけ・イメージだけでもOK 3日間以上のハッカソンなら動作動画まで欲しい ハードを作るなら具体的な動作をプレゼンで見せられるとよい
56. 13 DEMOを作ろう！ 改善とピッチ準備・DEMO作成 DEMOをどのように見せるか？ 動画で見せる（スライドに乗せる） 展示があるなら展示で見せる 演劇・小芝居などを入れてユーザーイメージをつける 実際にプレゼンで動かす（ハードなど） デプロイしてユーザの手元で動かさせる（リスク高い） リスク低 リスク高
57. 13 DEMOを作ろう！ 改善とピッチ作成・DEMO作成 DEMOを行う際にいい方法 DEMO画面を見せる場合は垂れ流さずカットをいれる メリハリのある動画にする必要がある DEMO動画は編集を少し入れるだけでぐっと伝わりやすくなる ボイスロイドなどの動画編集など声を入れる方法もあり DEMOなどでしっかりユースケースを明確化する
58. 14 実際にMVPを使ってもらう マーケット検証（MPF検証） ここまでくるとMVPは完成している状況 実際にユーザーに使ってもらっての感想と改善案をもらう 基本的にここで得たトラクションや感想はピッチに入れる ピッチはヒアリングからMVPそしてトラクションしてそのMVPの ユーザーからの評価を入れる 表・グラフ・ユーザーの声などの定量・質的データを入れることで よりそのMVPへの説得力を増していく
59. 14 実際にMVPを使ってもらう マーケット検証（MPF検証） ここまでくるとMVPは完成している状況 実際にユーザーに使ってもらっての感想と改善案をもらう ユーザーのトラクションが基本的には第一と考えるべき 基本的に想定ユーザー以上にトラクションとして最適な人はいない ユーザーヒアリングからMVP検証からMPF検証へ持っていくこと が出来る 基本的にピッチにはチャンピオンデータを入れるべき
60. 14 実際にMVPを使ってもらう マーケット検証（MPF検証） ここまでくるとMVPは完成している状況 実際にユーザーに使ってもらっての感想と改善案をもらう 基本的にここで得たトラクションや感想はピッチに入れる ピッチはヒアリングからMVPそしてトラクションしてそのMVPの ユーザーからの評価を入れる 表・グラフ・ユーザーの声などの定量・質的データを入れることで よりそのMVPへの説得力を増していく
61. 15 ピッチ資料作成 ピッチ資料には基本形がある 課題 解決策 プロセス 成果と展望 それぞれ一分づつくらい話すとよい ハッカソンで求められる発表時間は 1分/3分/4分/5分/8分/10分 これを変形することでピッチ資料を作成する
62. 15 ピッチ資料作成 ピッチ資料にはアピールを書く ピッチ資料はなぜあるのか？ 審査員にとっては「アピールされていないもの」 は評価できない 「ピッチで言わない」＝「存在していない」 極論
63. 15 ピッチ資料作成 例外的に言わなくていいこと 「ピッチで言わない」＝「存在していない」の例外 「実際に使ってもらいました」＝「プロダクトの存在証明」 「デモです」＝「技術的に成功していることの証明」 百聞は一見に如かず
64. 15 ピッチ資料作成 ピッチ資料は分かりやすく書く 審査員もピッチを長く聞くと疲れて子細な内容は聞かない場合が多い 特に技術系の話はかなりの技術系審査員でも実は正確な評価は難しい （ドメインが違うため知らない場合がほとんど） そのために「誰でも分かりやすい」 「本質を突いた強い言葉で」 「印象 を残す表現」で表現する 何が課題なのか？そのために「解決策は何で、その解決策は何がすご くてそれはどのくらい解決に役に立つのか？」がプレゼンをかなりの 限界状態でも簡単にわかればそのプレゼンは最高のプレゼンになる
65. 15 ピッチ資料作成 ピッチ資料の意味 ピッチの意味は審査員全員に一斉にプロダクトを紹介できるという機 会である もしピッチ以降でアピールする場合は審査員一人一人にすごさを同じ ように説明しなければならない そのために知ってほしい場所や質問・評価してほしいものは確実に 「ピッチ」で言わなければならない 審査員やスポンサーはプロダクトの「すべて」を見るわけではない、 そのため強調すべきところは厚かましいと感じずに強調すべき評価す るのは審査員側
66. 15 ピッチ資料作成 基本的にオーディエンスや審査員はすべての ピッチを同様に等しく見ていません ピッチに完全な公平性など存在しません 人間は基本的に長く話を聞くと疲れます 特に15チームくらいで限界です 実際審査もかなりいい加減です 何も作っていないチームが評価されたりします すでに競合がありすぎるチームが優勝したりします ありきたりなアイディアのチームが優勝したりします ピッチは同様に正しく見られないものだと思いましょう そのために審査員が分かりやすいように そのために技術を話さないのも手です。 バリューがわかれば十分です 私たちはなぜ作るか？ 使ってもらうため ユーザーにバリューを届けるため
67. 15 発表の準備をしよう ピッチ作成と発表 発表の準備は遅くとも最終日前日までなんなら初日から考えたほうが よく、プロダクトはピッチを考えながら作る ピッチは10回以上は確実に練習する メモは見ないでしゃべれるようになるのが理想 ピッチをする人は発表日前日に睡眠をしっかりとる ピッチを動画と音声にするという方法もある スライド資料はPDFを用意すること
68. 15 発表の準備をしよう ピッチ作成と発表 発表はとにかくプロダクトの魅せ方を意識しよう どのセグメントに対してそのプロダクトを魅せるのか？が大事 基本的にピッチは一人で行うのがよい（複数人は練習と切り替えが 難しい） 漫才・演劇・小芝居を行う場合は複数人でもよい プレゼンがうまい人・やりたい人がやる。プロダクトの開発が滞る 人はやらない方がよい。
69. 15 発表 ピッチ作成と発表 発表では基本的に「スライドの接続などの技術トラブル」を除き 必ずもたもたしない 堂々と自信をもって（自信満々に）自分のプロダクトに対しての愛着 を持って話す（基本おどおどしたプレゼンは誰も聞いてくれない） 基本的に「作ったものがある」ことはすごいこと（９割の人は自分で ものをつくていない） 「作って」 「使ってもらった」ものはさらに強いプロダクトになる
70. 16 ハッカソンは最後は運 ハッカソンの勝ち方と心持ち 人事を尽くして天命を待つとは言うがこれまでのことをすべて 行っても負ける場合はいくらでもある 相手が悪すぎる場合（優れすぎているアイデアと対峙したとき） 審査員が評価できなかった場合 デモが完成しなかったとき 基本的に負けるが基本的に負ける場合はこれまでのどこかに難点が あったと思っておいた方がよい 結局試行回数だったりもする あと強くなるためには手を動かそう
71. 16 これがすべてうまくいくのはほんの一部 ハッカソンの勝ち方と心持ち これまで理想的なハッカソンの勝ち方について語ってきたがこれ が毎回うまくいけばわけないのは当然 ただしすべてうまくいかせる必要はなく筋が通れば確実に圧倒的 な経験を得ることができると考えている 今までの方法論は基本的にすべて体験したものに基づいているが すべてがハッカソン中にできたわけではない そこでハッカソンを一回失敗した人はこれを少しでもいいところ を取り入れるだけで結果は変わってくる
72. ハッカソンの勝ち方と心持ち 16 ハッカソンで完勝するための思考の一つ 生成AIの場合 微妙なアイデア 生成AI =解決策の ドメイン ChatGPTラッパー よいアイデア 解決策の ドメイン + 生成AI シナジー not AIラッパー 独自AI （ML/DL) 独自技術 よいアイデア
73. AI前提の時代のものづくり 17 AIがすべてが出来る時代人間はどこに向かうべきか？ DB設計 AI設計 バックエンド フロントエンド ほとんど無限のメモリー 無尽蔵に「動くもの」を提供 AI 人間 限られた認知リソース クリエイティブが得意
74. AI前提の時代のものづくり 17 人はAIとともに限られたドメインに全力集中する DB設計 AI設計 バックエンド フロントエンド 人間 AI 価値提供に重要な部分と Deepな部分に全力を注ぐ 人間が介入すべき領域を 最小化してそこに人のリソー スを注ぐ AI Enpowerment人間 バックエンドシステム に集中する
75. 最後までご覧いただき、ありがとうございました。 THANK YOU