S-tierデモを作るためのヒント

• デモはプロジェクトのリリース可否やスタートアップの資金調達の成否を左右する決定的な要素だが、ほとんどの開発者は発表より制作を好むため、デモ力の向上に投資しない
• 多くのデモを観察した結果、上位クラスのデモに共通して現れるパターンを見つけ、それを24のヒントとして整理
• 記憶に残したいたった1つの核となるメッセージを決め、すべての要素をそこに集中させ、プロダクトツアーではなく**ピッチ（pitch）**として捉えるのが基本構成
• 聴衆全員が共感する共通の不便さから始め、"you"話法と従来方式との比較デモで没入感を生む
• エネルギー・実データ・可視化・面白さの要素を活用し、**能動的なデモ（active demo）**として仕上げることが核心

---

基本構成 (The basic structure)

• 1. 記憶に残したい1つの核となるメッセージを決め、デモのあらゆる要素をその周囲に配置する。通常は解決したい問題と、その解決方法が核になる
• 2. 核心にできるだけ早く入る。アイデアの背景説明は不要で、文脈が必要でも1〜2文に制限する
• 3. デモをプロダクトツアーではなくピッチとして扱うこと。目標は立派な成果物を見せびらかすことではなく、聴衆をワクワクさせること
• 4. すぐに行動に移せる締めで終える。QRコードのように直接的でもよく、コントリビューター募集や質問の促しという形でもよい
  • メッセージングアプリでPostHogと連携するシステムを作ったチームは、最後のスライドに電話番号を表示した
  • MCP Analyticsチームは、プロジェクトがすでにPostHogユーザーの25%に展開済みだと発表した。デモ前にリリース（shipping）しておくと大きな「wow」効果が生まれる

ストーリーテリング戦術 (Storytelling tactics)

• 5. 聴衆全員が理解できる共通の不便さから始める
  • イラストを自動タグ付け・インデックス化するWebアプリを作ったデザイナーチームは、雑然とした「Hoggies」のFigmaファイルから特定のハリネズミを見つける難しさを問いかけ、全員が手を挙げた
• 6. よく知られた概念を借りて新しい概念を説明する。PostHog Codeの中にClaude Coworkを実装したチームは、そのプロジェクトを「PostHog Work」と名付けた
• 7. とくに開発ツールをデモするときは別のデモアプリを作る
  • UIを手動テストするエージェントをデプロイするツールは、「OnlyHogs」という別のデモアプリで見せて初めて理解された
• 8. "you"話法で聴衆を適切な視点に置く。「サポートチケット管理アプリを作りました」ではなく、「あなたがオンコール中で、6件の障害を同時に解決しようとしていると想像してほしい」と表現する
• 9. 代替手段との比較デモを行う。つらい6段階の従来ワークフローと1段階のバージョンを並べて見せ、比較の基準を与える
• 10. 仕組みの説明は後回しにする。マジシャンがトリックをすぐ明かさないように、実装方法は最初に明かさず、解説動画やブログへのリンクは優れた締めのCTAになる

準備と伝え方 (Setup and delivery)

• 11. Steve Ballmerのように強いエネルギーを放つ。優れたデモは、しばしばエネルギッシュな人によるまあまあのデモにすぎない
• 12. 謝らない。「まだ粗くてすみません」と言うと、見せる前から期待値を下げてしまうので、そのまま始める
• 13. 終わったことを明確に示す。拍手のタイミングの気まずさを避けるため、締めの一文・下げるイントネーション・祝賀感のあるビジュアルで終える
• 14. デモの神々のためのデモ準備チェックリストを使う
  • 顧客データのある実アカウントではなくデモ用プロジェクトを使う
  • ノートPCの通知を無効化し、スマートフォンを消音にする
  • デモURLはその場で入力せずブックマークしておく
  • WiFi障害に備えた対策を用意する（バックアップ用スクリーンショットなど）
  • 後方の席からでも読めるよう、ブラウザを125〜150%に拡大する
  • 人が来る前にプロジェクターをテストする
• 15. できるだけ実データを使う。いかにも偽物のデータは貧相に見える
  • HogNetチームは、hackathon-in-a-boxレンタルサービスをデモする際に、価格や配送ロジスティクスを含むWebサイトを作り、lorem ipsumより現実味のある演出にした
• 16. できるだけ多くを事前ロード・キャッシュしておく。テレビの料理人が材料を先に用意するように進め、エージェントの応答・長いクエリ・遅いビルドによる待ち時間をなくす
• 17. 少なくとも一度は声に出して練習する。自信がつき、自然に伝えられるようになる
• 18. 完璧主義がデモを妨げないようにする。ハッカソンでは進行中の作業もすべて発表されるし、デモはもともと未完成の作業のためのものだ

楽しくする (Make it fun)

• 19. ありふれたコードを見せない。UIがなくてもビジュアルを省く言い訳にはならず、アーキテクチャ図は数秒で生成できる
• 20. ありふれたスライドだけを見せるのも避ける。能動的なデモが常に勝ち、デモの核心は実際に作って見せることだ
• 21. 標準の画面録画ツールは弱いので、Screen Studioのようにズームやアニメーションを加えられるアプリを活用する
• 22. ビジュアルは美しくある必要はない。重要な部分を強調できればよく、シンプルなグラフィックでも各コールアウトが有用な情報を与えられる
• 23. 音声は過小評価されている。あるチームはsea shantyのボイスオーバーを生成し、AIによるユーザーリサーチ通話のプロジェクトはデモを完全に音声専用で作った
• 24. もっと変にやる（Do more weird）。PostHog Codeモバイルアプリのチームは、頼まれてもいないピニャ・コラーダの映像を背景に入れ、そのデモが最も記憶に残った

[aliveornot]

内容が良いですね