💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

はじめに — なぜ今デモなのか

最近、PostHogのニュースレターに掲載された「How to demo」という記事がHacker NewsとGeekNewsで大きな話題になりました。要旨はシンプルです。「良いプロダクトを作る能力と、それを上手くデモする能力は別物であり、後者がなければ前者は世の中に存在しないのと同じだ」というものです。

この記事が2026年に特に共感を集めたのには理由があります。AIコーディングエージェントが普及し、「作ること」自体のコストが急激に下がりました。Claude CodeやCodexのようなツールで週末にプロトタイプを作ることは当たり前になり、社内ハッカソンやdemo dayに登場する成果物の数は何倍にも増えました。成果物がありふれたものになるほど希少になるのは、「これがなぜ重要なのかを3分以内に納得させる能力」です。

私にも似た経験があります。数ヶ月かけた社内プラットフォーム改善の仕事が、経営陣レビューでの「で、何が良くなったんですか?」という一言で崩れるのを見たことがありますし、逆に技術的には平凡なプロジェクトが、よく練られた5分のデモひとつで四半期ロードマップの中心に躍り出るのも見ました。デモは公平ではありません。しかし、それがゲームのルールなら、ルールを学ぶのが合理的です。

この記事はPostHogの論旨を出発点に、デモを「才能」ではなく「エンジニアリング可能な手順」として扱います。構造、スクリプト、リハーサル、環境準備、聴衆別の調整、失敗からのリカバリーまで — コード例とチェックリストを中心にまとめました。

デモが採用・投資・昇進を分ける理由

まず冷静な現実認識から始めましょう。デモが重要なのは、3つの非対称性のためです。

1. 情報の非対称性

あなたはそのプロジェクトについて数週間から数ヶ月考え続けてきました。聴衆は初めて聞きます。あなたの頭の中では自明なコンテキストが、聴衆には存在しません。デモはこのギャップを数分で埋める圧縮行為です。圧縮に失敗すれば、聴衆はプロジェクトではなく自分の混乱を記憶します。

2. 時間の非対称性

意思決定者の時間は常に足りません。四半期レビューで1つのプロジェクトに割り当てられる時間は通常5分から10分です。6ヶ月の仕事が5分で評価されるのは不条理ですが、その5分を設計できるということはチャンスでもあります。

3. 記憶の非対称性

人は論理ではなく場面を記憶します。「APIレスポンス速度を40パーセント改善しました」という文は忘れられますが、遅い画面と速い画面を並べて見せる10秒は会議が終わった後も残ります。昇進審査で「ああ、あのデモをやった人ね」と記憶されることの価値は、思った以上に大きいのです。

PostHogの記事の核心的な洞察もここにあります。デモは情報伝達ではなく「確信の転移(transfer of conviction)」です。あなたの持つ確信を聴衆に移すことに成功すれば採用と投資がついてきますし、失敗すればどんなに良いコードもマージされなかったブランチのように消えていきます。

Sランクデモの構造 — フック15秒、問題、実演、インパクト

良いデモはほぼ常に同じ骨格を持っています。4幕構成で整理するとこうなります。

+------------+-----------------+----------------------+-----------------+

| 1. フック | 2. 問題 | 3. 実演 | 4. インパクト |

| (15秒) | (30〜60秒) | (2〜4分) | (30秒) |

+------------+-----------------+----------------------+-----------------+

| 見せる | (共感の形成) | (ハッピーパス) | (CTA) |

+------------+-----------------+----------------------+-----------------+

第1幕: フック — 最初の15秒で結果を見せる

最もよくある失敗は、背景説明から始めることです。「このプロジェクトは昨年のQ3に始まりまして、当時のアーキテクチャが…」と始めた瞬間、15秒以内に聴衆の半分はSlackを見始めます。

Sランクデモは結論から見せます。映画の予告編が最高のシーンから始まるのと同じ原理です。

悪い始め方:「本日はデプロイパイプライン改善の取り組みを共有させていただきます。まず既存の構造をご説明しますと…」

良い始め方:「昨日までデプロイに40分かかっていました。今からリアルタイムで90秒でデプロイするところをお見せします。タイマー、スタートします。」

第2幕: 問題 — 聴衆の痛みとつなげる

フックで注意を引いたら、これがなぜ聴衆の問題なのかを30秒から60秒以内につなげます。核心は「自分の苦労」ではなく「あなたの痛み」を語ることです。技術的負債を返済した話ではなく、その負債のせいで聴衆が被っていた不便(リリース遅延、オンコールのアラート、顧客離脱)を語るべきです。

第3幕: 実演 — ハッピーパスをひとつだけ、しかし完璧に

実演パートの黄金律は「ひとつの経路を最後まで」です。機能10個を1分ずつ見せるより、最も印象的なシナリオひとつを4分間よどみなく見せる方が圧倒的に効果的です。枝葉の機能は「これ以外にXとYもできます」と一文で済ませれば十分です。

第4幕: インパクト — 数字で締め、要請で終える

最後の30秒では2つのことをします。第一に、定量的インパクトを一文で:「この変更により、週あたりのデプロイ回数が3回から25回になりました。」第二に、明確な要請(Call to Action):「来四半期に全社ロールアウトするには、インフラチーム1名の2週間が必要です。承認をお願いします。」要請のないデモは拍手をもらって忘れられます。

ライブデモ vs 録画 — 選択基準

「ライブにするか、録画にするか」はデモ準備で最初に決めるべき事項です。判断基準を表に整理すると次のようになります。

| 基準 | ライブデモ | 録画デモ |

| --- | --- | --- |

| 信頼感・インパクト | 最高(本物である証拠) | 中程度(編集を疑われうる) |

| 失敗リスク | 高い | なし |

| 外部依存(ネットワーク、サードパーティAPI) | 致命的な弱点 | 無関係 |

| 質疑応答中の即興デモ | 可能 | 不可能 |

| タイミング・ペース制御 | 難しい | 完璧 |

| 準備コスト | 複数回のリハーサルが必要 | 編集時間が必要 |

| 非同期共有・再利用 | 難しい | 優秀 |

実務上の推奨基準はこうです。

1. **ライブをデフォルトに**しつつ、次のいずれかに該当する場合は録画を混ぜます。

2. 実演経路に外部API、決済、メール送信など**制御不能な依存**がある → その区間だけ録画

3. 1回の実演に**3分以上かかる非同期処理**(ビルド、学習、マイグレーション)を含む → 開始はライブ、結果は事前に実行しておいた画面に切り替え(料理番組の「先に焼いておいたパン」テクニック)

4. 聴衆が**外部投資家や大口顧客**で、失敗コストが回復不能 → 録画本編 + ライブ質疑応答

5. どの場合でも**バックアップ録画は必ず準備**します。ライブが崩れたときに「録画を用意してありますので、こちらでご覧ください」と切り替えられるのと、デモがそのまま終わるのとでは大違いです。

デモシナリオスクリプトの書き方

デモはアドリブではなく、台本のある公演です。スクリプトは「話す内容」と「操作する内容」を分けて書くのが核心です。実際に使っている形式を例としてお見せします。

デモスクリプト: デプロイパイプライン v2 (計6分、聴衆: エンジニアリングリーダー陣)

[0:00-0:15] フック

話: 「昨日までデプロイに40分かかっていました。今から90秒で

デプロイするところをお見せします。タイマー、つけます。」

手: ストップウォッチアプリ開始。ターミナルのタブ1に切り替え。

[0:15-1:00] 問題

話: 「先四半期、私たちのチームのリリースは平均2日ずつ遅れました。

原因の70パーセントがデプロイ待ち行列でした。

金曜午後にデプロイ枠を取ろうとSlackで

駆け引きしていたこと、皆さん覚えていると思います。」

手: 何もしない(画面切り替え禁止、顔/スライドを維持)

[1:00-4:30] 実演(ハッピーパス)

話: 「たった今バグ修正PRがマージされたと仮定します。」

手: ターミナルでdeployコマンド実行 → CIダッシュボードのタブへ

話: 「カナリアに自動デプロイされ、エラー率を5分間観察します。

デモのため観察区間は30秒に短縮してあります。」

手: ダッシュボードでカナリアのトラフィックグラフを拡大(ズーム200パーセント)

話: 「エラー率正常。自動で全体にロールアウトされます。」

手: 本番URLをリロード → 変更を確認

話: 「タイマーをご覧ください。87秒です。」

[4:30-5:00] インパクト

話: 「パイロット2週間で、デプロイ回数は週3回から25回に、

ロールバック平均時間は22分から40秒になりました。」

[5:00-5:30] 要請

話: 「全社ロールアウトにはインフラチーム1名の2週間が必要です。

今スプリントでの承認をお願いします。」

[予備] 想定質問3つと回答一行ずつを別カードに準備

スクリプト作成時に守るルールは次の通りです。

1. **「話」と「手」を分けて書く。** 話しながら操作して両方とも台無しにするのが最もよくある事故です。操作している間は沈黙するか、操作と無関係なセリフ(事前に暗記したもの)を話します。

2. **タイムボックスを明示する。** 区間ごとのタイムスタンプがないと実演が間延びし、インパクトと要請が切られます。最も重要な最後の1分を守るために前を削ります。

3. **数字は事前に埋め込んでおく。** 「かなり速くなりました」ではなく「40分から87秒へ」です。正確な数字はスクリプトに書いておかないと本番で蒸発します。

4. **最初の文と最後の文は丸ごと暗記する。** 中間はキーワードを見ながら話してもかまいませんが、始めと終わりがつかえると全体の印象が崩れます。

リハーサル — 3回の法則と失敗ポイントリスト

PostHogの記事でも強調されている通り、デモが上手い人たちの共通点は才能ではなくリハーサルの回数です。実務的には「3回の法則」をおすすめします。

1. **1回目 — ひとりで、止めずに。** 最初から最後まで実際に話し、実際に操作します。頭の中のシミュレーションはリハーサルではありません。この段階で、所要時間が常に予想より30〜50パーセント超過することを発見するはずです。削ってください。

2. **2回目 — 同僚1人の前で。** コンテキストのない同僚に見せて「どこで混乱したか」だけを聞きます。褒め言葉は聞かないでください。混乱ポイントだけを収集します。

3. **3回目 — 実際の環境、実際の機材で。** 発表するその会議室(またはそのビデオ会議ツール)、そのノートPC、そのネットワークで行います。オフィスのモニターではよく見えていた文字がプロジェクターでは見えない問題、社内VPNからしかアクセスできないダッシュボードの問題は、この段階でしか発見できません。

リハーサルをしながら**失敗ポイントリスト(failure inventory)**を作成します。形式はシンプルです。

失敗ポイントリスト: デプロイパイプラインデモ

| ポイント | 症状 | プランB |

|------------------------|-----------------------|------------------------------|

| CIダッシュボード読込 | 初回ロード8秒の遅延 | 事前にタブを開きリロードのみ |

| カナリアグラフ | データ0件の可能性 | シードスクリプトを10分前実行 |

| 会議室のWi-Fi | 社内網が不安定 | スマホテザリングを事前接続 |

| 本番URL | キャッシュで旧版表示 | シークレットウィンドウ使用 |

| ライブ全体の失敗 | 回復不能 | バックアップ録画(タブ5番) |

このリストの価値は事故を防ぐことではなく、事故が起きたときに**慌てずに済む**ようにしてくれる点にあります。プランBが文書として存在すれば、リカバリーは3秒で済みます。

デモ環境の準備 — コードで解決する

デモの信頼性は精神力ではなくエンジニアリングで確保します。3つの実践テクニックをコードとともに見ていきます。

1. データシーディング — 空の画面でデモをしない

空のダッシュボード、ユーザー0人、グラフなしの状態で行うデモには説得力がありません。デモ用データを再現可能な形でシードするスクリプトを作っておきましょう。

// scripts/seed-demo.ts

// デモ直前に1回実行: pnpm tsx scripts/seed-demo.ts

const DEMO_ORG = 'acme-demo'

async function seedDemo() {

// 冪等性の保証: 既存のデモデータを削除してから再生成

await db.event.deleteMany({ where: { orgId: DEMO_ORG } })

// グラフが「見栄え良く」なるよう、トレンドのあるデータを生成

const events = []

for (let day = 30; day >= 0; day--) {

const base = 120 + (30 - day) * 18 // 右肩上がりのトレンド

const count = base + Math.floor(Math.random() * 25)

for (let i = 0; i < count; i++) {

events.push({

orgId: DEMO_ORG,

type: 'deploy_completed',

durationSec: 60 + Math.floor(Math.random() * 40),

createdAt: subMinutes(subDays(new Date(), day), i * 3),

})

}

await db.event.createMany({ data: events })

console.log(`Seeded ${events.length} events for ${DEMO_ORG}`)

}

seedDemo()

ポイントは3つです。冪等性(何度実行しても同じ状態になる)、トレンド(グラフが右肩上がりで「ストーリー」を持つように)、そして現実感(名前と数字がそれらしく見えること — 「test1, test2, asdf」が画面に映った瞬間、デモの格が下がります)。

2. デモモードフラグ — 不確実性をコードで除去する

ライブデモで最も怖いのは外部依存です。決済APIのタイムアウト、メール送信の遅延、LLMレスポンスの非決定性といったものです。デモモードフラグで、リスクの高い区間だけを決定的(deterministic)に変えます。

// src/lib/demo-mode.ts

export const isDemoMode = (): boolean =>

process.env.DEMO_MODE === '1'

// src/services/payment.ts

export async function chargeCard(amountCents: number) {

if (isDemoMode()) {

// 外部決済会社の呼び出しの代わりに0.8秒後に成功を返す

await new Promise((r) => setTimeout(r, 800))

return { status: 'succeeded', id: 'demo_ch_001' }

}

return await realPaymentGateway.charge(amountCents)

}

注意点もあります。第一に、デモモードは**リスク区間だけに最小限**適用します。全部モックに置き換えたら、それはデモではなくアニメーションです(そして質疑応答でバレます)。第二に、デモモードを使っている事実を隠さないでください。「決済はサンドボックスモードです」と一言伝えても信頼は減りません。バレた嘘だけが信頼を削ります。第三に、フラグが本番に漏れ出さないよう、デプロイパイプラインでガードをかけます。

.github/workflows/deploy.yml の一部

- name: Guard against demo mode in production

run: |

if [ "$DEMO_MODE" = "1" ]; then

echo "DEMO_MODE must not be enabled in production"

exit 1

3. ネットワークのプランB

チェック項目は3つです。スマホのテザリングを**デモ開始前にあらかじめ接続**しておくこと(事故後に接続すると2分が飛びます)、デモ対象がローカルで動かせるなら**ローカルフォールバック**を準備すること、そして会議室のゲストWi-Fiから社内ダッシュボードにアクセスできるかを**事前に確認**すること。3つ目が意外にも最も頻繁に問題になります。

聴衆別の調整 — 同じデモ、異なる強調点

デモの骨格は同じでも、強調点は聴衆によって変えるべきです。

| 項目 | 経営陣 | エンジニア | 顧客 |

| --- | --- | --- | --- |

| 適正時間 | 5分以内 | 10〜15分 | 15〜20分 |

特に経営陣向けデモで覚えておくべきこと: 彼らが買うのは技術ではなく**意思決定**です。「この技術がどれほどエレガントか」ではなく「承認したら何が良くなり、しなければ何を失うか」がすべてです。逆に、エンジニアの聴衆に誇張されたマーケティングトーンを使うと即座に信頼を失います。エンジニアに対しては、限界とトレードオフを先に話す方がむしろ説得力を高めます。

よくある失敗10選とリカバリーフレーズ

失敗は防ぐことよりリカバリーが重要です。現場でよく見る失敗10選と、その瞬間に使えるリカバリーフレーズです。

1. **アプリが落ちた** → 「良いニュースは、こういう状況に備えて録画を準備してあることです。続きをご覧ください。」(バックアップ録画に切り替え、5秒以内)

2. **ロードが延々と長い** → 沈黙しないこと。「ロードされている間にひとつ補足しますと…」と準備しておいた一文(インパクトの数字)を話します。10秒を超えたら「これは回しておいて、先に次の画面を見ましょう。」

3. **デモデータが空** → 「シードデータが初期化されてしまったようです。準備したスクリーンショットでお見せして、終わった後にライブでもう一度お見せします。」

4. **間違ったボタンを押した** → 慌てた素振りを見せず、ただ戻ります。謝罪を長くするとミスが2倍に見えます。「戻りましょう」の一言で十分です。

5. **予期しないエラートーストが出た** → エンジニアの聴衆なら正直が最善:「お、本物のエラーですね。Issueに登録しておいて続けます。」むしろ本当にライブである証拠になります。

6. **質問が実演の途中に割り込んでくる** → 「良い質問です。2分後にその画面が出てくるので、そこでお答えします。」流れのコントロール権を取り戻すことが核心です。

7. **時間が半分しか残っていないと告げられた** → 実演を切り、インパクトと要請にジャンプします。スクリプトに「短縮経路」を事前にマークしておけば可能です。

8. **画面共有ができない** → 「権限設定を確認している間に、今日お見せする結論からお話ししますと…」フックを先に口頭で行います。技術的トラブル解決と発表を並列化します。

9. **数字への挑戦的な質問**(「その40パーセント、どう測ったんですか?」) → 「測定方法論は付録にまとめてあります。終わった後にリンクを共有します。」その場で防戦して時間を使い果たすのが最悪です。ただし、付録は本当に存在しなければなりません。

10. **完全なブラックアウト(ノートPC死亡など)** → 機材なしで口頭で行う60秒バージョンを事前に準備しておきましょう。「機材が協力してくれないので、核心だけお伝えします。デプロイが40分から90秒になり、承認が必要なのは2週間のタスクです。」これができる人はほとんどいないので、できればむしろ強く記憶に残ります。

社内デモ文化を作る — Demo Dayの運営

個人技を超えてチームの能力にするには、定期的なdemo dayが効果的です。PostHogをはじめ多くの会社が週次デモを制度化した理由は明確です。デモが日常になると「見せられる単位に仕事を切り分ける」習慣が生まれ、それはそのまま小さなPR、速いフィードバックループにつながります。

運営ルールの例は次の通りです。

1. **周期と長さを固定**: 隔週金曜30分。長くなると死にます。

2. **1人あたり5分のハードリミット**: タイマーを公開で表示します。5分で見せられないものはデモではなく発表です。

3. **スライド禁止、画面のみ**: demo dayの目的は「動くもの」を見ることです。スライドを許可した瞬間、すべてがスライドになります。

4. **未完成歓迎の原則を明文化**: 「恥ずかしい段階で見せるのが正常」というルールを文書に刻んでおきます。心理的安全性がなければ完成品しか上がってこなくなり、それではdemo dayではなく四半期報告になります。

5. **録画とアーカイブ**: すべてのデモを録画してチャンネルに蓄積します。新入社員のオンボーディング資料として、また昇進審査のエビデンスとして再利用されます。

6. **リアクションの義務化**: 発表ごとに質問1つまたは称賛1つを義務にします。沈黙のうちに終わるデモが繰り返されると、誰も登壇しなくなります。

運営が健全かどうかを判断する指標も決めておくとよいでしょう。

1. **参加率**: 四半期ごとのdemo dayあたり平均発表数。減っていれば、心理的安全性か時間負担に問題が生じています。

2. **未完成比率**: 発表のうち「進行中の仕事」の割合。これがゼロに収束したら、demo dayが報告会に変質したシグナルです。

3. **後続転換率**: デモから始まったコラボレーション、採用、イシュー報告の数。demo dayの本当のROIは拍手ではなくこの数字です。

最後に、demo dayの最初の発表者は常にリーダーが務めることをおすすめします。リーダーが不格好なプロトタイプを笑顔で見せる姿一度の方が、「未完成歓迎」という文書10枚より強力です。

リモートデモのコツ

2026年のデモの半分はビデオ会議です。リモート特化のコツをまとめます。

1. **ズームレベルを200パーセントに**: あなたの画面は聴衆には半分のサイズで見えています。ブラウザは200パーセントズーム、ターミナルとエディタはフォント18pt以上。「見えていますか?」と聞かず、最初から大きく始めてください(聞いた瞬間、3人が「もう少し大きく」と答えて1分が消えます)。

2. **単一ウィンドウではなく仮想デスクトップを共有**: 単一ウィンドウ共有は、タブ切り替えのたびに共有を取り直す事故を生みます。デモ専用の仮想デスクトップを作り、必要なウィンドウだけを配置してデスクトップ全体を共有するのが安全です。Slackと通知は必ずおやすみモードに。

3. **マウスで語る**: リモートでは視線誘導ができないので、カーソルを大きくし(OS設定)、クリックの前に「ここの、このボタンを押すと」と位置を口頭で指し示します。

4. **沈黙区間をなくす**: 対面では5秒の沈黙は問題ありませんが、リモートでは「固まった?」になります。ロード中は常に口を動かします。

5. **開始直後に録画ボタン**: リモートデモはタダで録画資産になります。うまくいったライブデモの録画が次のデモのバックアップ映像になる好循環を作りましょう。

場面別のバリエーション — ハッカソン、四半期レビュー、採用面接

同じ4幕構成でも、舞台によって時間配分と強調点が変わります。代表的な3つの舞台のバリエーションを整理します。

時間配分ガイド (4幕構成のバリエーション)

フック問題実演インパクト/要請

ハッカソン 10秒 20秒 2分 30秒

四半期レビュー 15秒 1分 3分 2分

採用面接 15秒 30秒 4分 1分 (質問を誘導)

ハッカソンデモ (3分)

審査員は1日に数十のデモを見ます。彼らの頭の中には「これは何が違うのか?」という問いひとつしかありません。差別化ポイントひとつに全部を賭けてください。技術スタックの羅列は最悪の時間の浪費です — 「ReactとFastAPIで作りました」を審査員は記憶しません。動く瞬間ひとつが記憶のすべてです。そしてハッカソンはネットワークが最も不安定な環境なので、ローカルフォールバックとバックアップ録画は選択ではなく義務です。

四半期レビューデモ (5〜10分)

四半期レビューの特殊性は「前回の約束」との接続です。先四半期に語った目標を最初のスライドに再掲し、今回のデモがその約束の履行であることを見せれば、信頼残高が複利で積み上がります。インパクトパートの比重を2倍にし、次の四半期の約束(測定可能な形で)で締めてください。経営陣はデモ自体より「約束と履行のサイクルが回るチーム」というシグナルを買うのです。

採用面接でのポートフォリオデモ

面接でサイドプロジェクトを見せる機会があったら、実演の後に必ず**面接官に直接触ってもらって**ください。コントロールを手放すことは自信のシグナルであり、面接官の手の中で生き残るプロダクトはどんな言葉より強いのです。そして失敗談をひとつ準備してください — 「この部分は最初Xで設計しましたが、Yの問題で作り直しました」は、完璧な成功談よりシニアらしさをよく証明します。

デモ直前のメンタルルーティン

舞台が何であれ、直前の5分は同じです。最初の文を3回声に出して言い(頭の中での朗読は効果が半分です)、水を一口飲み、「デモが死んでも自分にはリカバリーフレーズがある」という事実を思い出してください。準備された人の余裕は、聴衆にそのまま伝染します。

デモの後の仕事 — モメンタムを資産に

デモが終わる瞬間こそが本当の始まりです。拍手の有効期限は48時間で、その間にモメンタムを資産に変えなければなりません。

1. **24時間以内のフォローアップメッセージ**: 録画リンク、核心の数字3つ、そしてデモで行った要請(CTA)をもう一度書いて送ります。意思決定者の受信箱に「決めるべきこと」として再登録させる行為です。

2. **質問ログの資産化**: デモ中に受けた質問は、聴衆が何を懸念しているかについての無料の市場調査です。質問リストを整理してFAQドキュメントにすれば、次のデモの想定質問カードがそのまま完成します。

3. **拒絶もデータ**: 要請が断られたら「何が満たされれば再協議できるか」をその場で聞いて記録します。「今ではない」と「永遠にない」を区別することが、次の四半期の戦略を決めます。

落とし穴と反論 — デモ至上主義への警戒

バランスのために反対側の論理も扱います。

「デモが上手い人だけが報われるなら、静かなビルダーが損をする」という批判は妥当です。デモ能力とエンジニアリング能力の相関は完璧ではなく、華やかなデモが脆弱な基盤作業を覆い隠す「デモ駆動開発(demo-driven development)」の弊害も実在します。インフラ、セキュリティ、リファクタリングのような本質的に「見せにくい」仕事が、demo day文化の中で体系的に過小評価されるリスクもあります。

対応は2方向です。組織レベルでは、デモ以外の評価チャネル(設計ドキュメント、運用指標、ピアレビュー)を併せて維持すべきです。個人レベルでは、見せにくい仕事ほど見せる技術がより必要になるという逆説を受け入れるのが現実的です。レイテンシグラフのビフォー/アフター、オンコールアラート数の減少トレンド、脆弱性スキャン結果の変化 — インフラの仕事も「場面」にすることができます。

もうひとつの落とし穴は**過剰最適化されたデモ**です。デモモードとシーディングで磨き上げすぎると、実際のプロダクトとのギャップが採用後に露呈し、信頼を大きく失います。デモはプロダクトの最高の姿であるべきで、プロダクトに存在しない姿であってはなりません。

デモチェックリスト

デモ前日と直前に使うチェックリストです。

前日まで:

1. スクリプト作成完了(話/手の分離、タイムボックス、最初/最後の文の暗記)

2. リハーサル3回完了(ひとり → 同僚 → 実環境)

3. 失敗ポイントリストとプランBの作成

4. バックアップ録画の準備、再生位置の確認

5. デモデータシードスクリプトの検証

6. 短縮バージョン(時間半分)の経路をマーク

直前30分:

1. シードスクリプト実行、画面状態の確認

2. 通知の全面ブロック(OSおやすみモード + Slack + メール)

3. デモ用仮想デスクトップに必要なタブだけを順番に配置

4. ブラウザズーム200パーセント、ターミナルフォント拡大

5. テザリング事前接続、バックアップ録画タブを開いておく

6. 水一杯、タイマー準備

終了後:

1. 答えられなかった質問に24時間以内にフォローアップ

2. 要請(CTA)に対する意思決定者の回答を確認

3. 録画をアーカイブし、次のデモのバックアップとして登録

おわりに

デモは才能ではなく手順です。フック15秒、ハッピーパスひとつ、数字で締め、要請で終える。リハーサル3回と失敗ポイントリスト、シードスクリプトとデモモードフラグ。この記事のどれも話術のトレーニングではありません。すべてエンジニアリングです。

作るコストが崩壊した時代に、見せる能力は開発者の第二のコンパイラです。コードが機械に意図を伝える言語だとすれば、デモは人に価値を伝える言語です。どちらも使えなければ、半分だけの開発者ということになります。

参考資料

- PostHog Newsletter — How to demo: https://newsletter.posthog.com/p/how-to-demo

- GeekNews 議論 — デモのやり方: https://news.hada.io/topic?id=30265

- Hacker News — PostHog How to demo 議論: https://news.ycombinator.com/

- PostHog Handbook — 全社ハンドブック公開文化: https://posthog.com/handbook

- Kapwing — デモ動画制作ガイド: https://www.kapwing.com/resources/

- Stripe Docs — テストモードとサンドボックス設計の参考例: https://docs.stripe.com/testing

- GitHub Actions 公式ドキュメント — 環境変数とガード: https://docs.github.com/en/actions

- Zoom 公式ドキュメント — 画面共有のベストプラクティス: https://support.zoom.com/hc/en

- date-fns 公式ドキュメント(シードスクリプト例のライブラリ): https://date-fns.org/

- 37signals — Shape Up、デモ可能な単位への仕事の分割: https://basecamp.com/shapeup