エンジニアの登壇資料作成メソッド完全ガイド｜論理構造・視覚設計・聴衆分析の三本柱

はじめに：なぜエンジニアの登壇資料は「伝わらない」のか

技術カンファレンスや社内勉強会で登壇したとき、「話した内容は正しいはずなのに、聴衆の反応がいまひとつだった」という経験はないでしょうか。エンジニアが作るスライドは、情報量が多く技術的に正確であるにもかかわらず、なぜか「刺さらない」ことがあります。

情報量は多いのに刺さらないスライドの正体

刺さらないスライドに共通するのは、「情報の多さ」ではなく「伝達の順序と構造」の問題です。コードと同様に、スライドにも「読み手（聴衆）が処理できる順序」があります。知識がない状態で突然専門用語が出てきたり、結論が最後にしか現れなかったりすると、聴衆は内容を追うだけで精一杯になり、メッセージが届く前に疲弊してしまいます。

デザインセンスの問題ではなく「設計」の問題である

「デザインが苦手だからスライドが下手なんだ」と思っているエンジニアは少なくありません。しかし実際の開発現場では、センスの問題ではなく設計（エンジニアリング）の問題として捉え直すことで、劇的に改善できます。「認知負荷をいかに下げるか」という工学的基準に基づけば、美的センスがなくても伝わるスライドは作れます。

この記事で得られること

この記事では、エンジニアが登壇資料を効率的に作るための三本柱——論理構造・視覚設計・聴衆分析——を体系的に解説します。読み終わるころには、次の登壇に向けてすぐ実践できる具体的なフレームワークを手にしていただけます。

登壇資料作成の全体像：3つの柱で考える

伝わるプレゼン資料は、次の3つの柱で成り立っています。

柱	役割
論理構造（情報設計）	理解の順序を設計する
視覚設計（デザイン原則）	認知負荷を最小化する
聴衆分析	誰に何を届けるかを逆算する

着手する順番は「聴衆分析 → 論理構造 → 視覚設計」です。誰に届けるかが明確でなければ、どんなに美しいスライドも的外れになります。まず聴衆を定め、次に構造を作り、最後に視覚的に整える——この順序がベストプラクティスとして定着しています。

【準備編】ネタ探しと聴衆分析から始める

登壇ネタは「内圧」から生まれる

優れた登壇ネタの多くは、日々の業務の中で感じる「これは外に広げたい」という内圧から生まれます。チームで解決した課題、試行錯誤の末にたどり着いた設計判断、他のエンジニアが同じ罠にはまらないようにしたいという思い——そういった感情を感じた瞬間をメモしておく習慣が、登壇ネタの源泉になります。

「野球場でサッカーをするな」：場の性質を見極める

登壇ネタが決まったら、次に「どの場に持ち込むか」を見極めます。アーキテクチャの深い話をLT（ライトニングトーク）でやろうとするのは、野球場でサッカーをするようなものです。場の性質（聴衆の期待・技術レベル・時間配分）とネタのスコープが合致しているかを事前に確認しましょう。

話したいことがある → 刺さる聴衆がいる場所を探す（逆算思考）

ネタが先に決まっている場合は、「このネタが刺さる聴衆はどこにいるか」を逆算して登壇先を探す方法も有効です。多くのカンファレンスはCFP（Call for Proposals）を公開しています。ネタのターゲットと場の聴衆が一致する機会を狙い打ちにしましょう。

聴衆の前提知識レベルを3段階で仮定する

準備段階で聴衆の前提知識を「初級・中級・上級」の3段階で仮定し、どのレベルに向けて話すかを明確にします。一般的な技術カンファレンスでは「中級者の下位」を基準とすると、最大多数に届く内容になりやすいです。

登壇時間別のゴール設定

LT（5分）：1つのメッセージを残すことだけを目標にする
15分：問題提起・解決策・まとめの3点セットを完結させる
20分以上：背景・課題・解決・展望の起承転結で、文脈から丁寧に積み上げる

【情報設計編】伝わる論理構造の作り方

ピラミッド原則：結論先出し→根拠→展望

情報設計の基本はピラミッド原則です。「結論（何を言いたいか）→ 根拠（なぜそう言えるか）→ 展望（だからどうすべきか）」の順で構成すると、聴衆は最初から「何の話か」が分かるため、内容を理解しやすくなります。エンジニアが陥りがちな「経緯から話して結論が最後」という構成は、発表者には自然でも聴衆には負担が大きい形式です。

「知らない情報が突然出てくる」を避ける依存関係の整理

スライドの依存関係を整理することも重要です。「この用語はスライド5で初めて登場するが、スライド3ですでに使っている」といった状況は、コードでいえば未定義変数の参照と同じです。図にする、あるいはスライドの順序を入れ替えることで解決できます。

発表時間別の構成テンプレート

LT（5分）：1点突破型

「問題提起（30秒）→ 解決策・発見（3分）→ まとめと一言メッセージ（1分30秒）」の構成が鉄板です。1つのメッセージに絞ることが命です。

15分：序破急型

「導入・文脈（3分）→ 本題・解決策（9分）→ まとめ・次のアクション（3分）」。序で場をつかみ、破で深く潜り、急でスッキリ着地させます。

20分以上：起承転結型

「背景と問題意識（5分）→ 既存アプローチの限界（4分）→ 自分たちの解決策（8分）→ 成果と展望（3分）」。時間があるぶん文脈を丁寧に積み上げられます。

スライドより先に「ブログ記事」を書くべき理由

段階的に理解を深めていきましょう。多くのエンジニアが最初にスライドを開いてしまいますが、実は先にブログ記事として文章化するほうが効率的です。文章を書くことで、話の抜け漏れや論理の飛躍が明確になります。また、音読することで実際の発表時間の感覚もつかめます。

文章をスライドへ「コミカライズ」する変換手順

ブログ記事が書けたら、それをスライドに変換します。この作業を「コミカライズ」と呼ぶと分かりやすいです。1段落＝1スライドを基準に、文章から「キーワードと補足図」だけを抽出します。詳細はすべて話し言葉でカバーするイメージです。

【スライド設計編】デザイン原則で認知負荷を最小化する

鉄則：1スライド＝1メッセージ

スライド設計の絶対原則は「1スライド＝1メッセージ」です。1枚のスライドに複数のメッセージを詰め込むと、聴衆はどれが重要かを判断するコストを強いられます。伝えたいことが多い場合は、スライドを分けましょう。

スライドは主役ではなく「話の補完役」である

スライドは登壇者の話を補完するための道具であり、それ自体が主役ではありません。スライドだけを読んで完全に理解できる資料は、プレゼンではなく「ドキュメント」です。登壇中のスライドには、キーワード・図・数字だけを置き、詳細は口頭で届けるのが理想です。

文字量を削るための実践テクニック

箇条書きは3項目以内に絞る
接続詞・修飾語を省いてキーワードだけ残す
本文フォントサイズは最小24pt以上を守る（後方からでも読める）
「文章→センテンス→フレーズ→キーワード」の順で削る

色は3色以内：配色ルールの決め方

使用する色はメインカラー・アクセントカラー・テキストカラーの3色以内に絞ります。配色に迷うなら、自社・チームのブランドカラーをメインに採用するのが最も無難で再現性があります。強調したい箇所のみアクセントカラーを使い、それ以外はモノトーンで統一するだけでグッと引き締まります。

レイアウト4原則の使いどころ

デザインの基本であるレイアウト4原則は、スライドにも直接応用できます。

近接：関連する要素はグループ化して近づける
整列：要素を一定のグリッドに沿わせる（揃えるだけで整って見える）
反復：タイトルのスタイル・アイコンの形・余白サイズを全スライドで統一する
コントラスト：重要な情報とそうでない情報の差を明確にする

ゲシュタルト原則と余白の活用

人間の脳は「近いものを同じグループとみなす」「余白で区切られたものを別グループとみなす」という傾向（ゲシュタルト原則）を持っています。余白は「何もない空間」ではなく「情報を整理する道具」として積極的に使いましょう。スライドの上下左右に意図的にマージンを設けるだけで、視認性が大きく向上します。

図解の作り方：システム構成図の方法論を転用する

エンジニアが得意なシステム構成図の作り方は、スライドの図解にそのまま転用できます。「登場する要素（ノード）を洗い出す→関係性（エッジ）を定義する→情報の流れに沿って左から右（または上から下）に並べる」という手順です。フローチャートやシーケンス図の感覚でスライドの図を作ると、論理的で分かりやすい図解が生まれます。

やってはいけない典型例

過剰なアニメーション：視線を奪い、内容への集中を妨げる
詰め込みスライド：1枚で5つ以上の要素を説明しようとしない
全文読み上げ型スライド：台本をスライドに貼っても資料にもプレゼンにもならない

【ツール編】エンジニアならではの資料作成環境

GUIツール vs コードベースツールの選び方

PowerPointやKeynote、Google SlidesといったGUIツールは操作が直感的で、デザインテンプレートも豊富です。一方、エンジニアにとってはコードベースのツールを使うことで、バージョン管理・再利用・自動化が可能になります。チームで共有するなら、どちらのアプローチが合っているかを検討しましょう。

Marp：Markdownでスライドをバージョン管理する

MarpはMarkdownからスライドを生成するツールです。テキストベースなのでGitでバージョン管理でき、差分レビューも容易です。シンプルなCSSテーマで見た目を統一し、CLI経由でPDF/HTML出力できるため、CI/CDに組み込むことも可能です。

---
marp: true
theme: default
---

# スライドタイトル

ここにキーメッセージを1文で

Reveal.js：Web技術で表現力を確保する

Reveal.jsはHTML/CSS/JavaScriptでスライドを作るフレームワークです。コードハイライトやインタラクティブなデモをスライド内に埋め込めるため、ライブコーディングを伴う技術登壇に特に向いています。

Tailwind CSSでデザインの再現性を担保する

MarpやReveal.jsと組み合わせてTailwind CSSを使うと、ユーティリティクラスベースでデザインを再現性高く管理できます。スライドのデザインコンポーネントを設計するアプローチと相性が良く、2026年現在では多くのエンジニア登壇者が採用しているスタックです。

【AI活用編】2026年の効率化アプローチ

Claude + Marp + Tailwind CSSで作成期間を1〜2日へ短縮

2026年現在、Claude・Marp・Tailwind CSSを組み合わせたワークフローが、エンジニアの登壇資料作成における有力な選択肢になっています。従来は週単位かかっていた作業が、うまくワークフローを設計すれば1〜2日に短縮できるケースが報告されています。

AIに任せられる領域・人間が担うべき領域

AIに任せる	人間が担う
構成案の生成	内容の真実性確認
図表・テンプレートの生成	ブログ記事との整合性検証
リサーチと情報収集	登壇ストーリーの最終判断
Markdown/コードへの変換	聴衆体験のシミュレーション

AIは優れた補助者ですが、「この情報は正しいか」「この流れで聴衆は理解できるか」という判断は人間が必ず担う必要があります。ハイブリッドワークフローが2026年のベストプラクティスです。

AI生成スライドにありがちな失敗と回避策

失敗①：内容が当たり障りなく、具体性がない → 自分の経験・数値・失敗談を必ず加える
失敗②：スライドが多すぎる → AIに枚数上限を明示的に指示する
失敗③：デザインが均一すぎて単調 → ハイライトスライドのみ手動で強調を加える

【実践編】登壇資料作成6ステップ

Step1：ネタ出しと聴衆設定

日々のメモからテーマを選び、「誰に届けるか」「何を持ち帰ってほしいか」を1文で定義します。この1文がスライド全体のコンパスになります。

Step2：ブログ記事として文章化

スライドを開く前に、話したい内容を1000〜2000字のブログ記事として書き出します。論理の粗が見えやすくなり、話す時間の感覚も養えます。

Step3：構成骨子（アウトライン）への分解

ブログ記事をH2・H3レベルの見出しに分解してアウトラインを作ります。このアウトラインがそのままスライドの目次になります。

Step4：スライドへの図解変換

各セクションをスライド1枚に対応させ、文章をキーワード＋図に変換します。1スライド＝1メッセージの原則を守りながら進めます。

Step5：デザイン統一とブラッシュアップ

配色・フォント・レイアウトをテンプレートに沿って統一します。余白を確保し、不要なテキストを削ぎ落とします。

Step6：リハーサルと時間調整

実際に声に出して発表し、時間を測ります。余ったら内容を減らし、足りなければスライドを統合します。本番と同じ環境（プロジェクター解像度・スライドモード）でも確認しましょう。

よくある疑問Q&A

Q. デザインセンスがなくても良いスライドは作れる？

A. はい、作れます。 デザインを「美的センス」ではなく「認知負荷の最小化」という工学的課題として捉え直しましょう。レイアウト4原則（近接・整列・反復・コントラスト）を守り、色を3色以内に絞るだけで、プロらしい見た目になります。センスは後から磨けますが、原則は今日から使えます。

Q. 何から手をつければいい？

A. スライドより先に文章を書きましょう。 最初にスライドを開くと、見た目の細部に引きずられて内容が迷子になりがちです。まずブログ記事を書き、次にアウトライン化し、最後にスライドへ変換する順序が最も効率的です。

Q. スライド枚数の目安は？

A. 1分あたり1〜2枚が目安です。 LT（5分）なら5〜8枚、15分なら15〜20枚、20分なら20〜30枚が一般的な範囲です。ただし枚数よりも「1スライド1メッセージ」の原則を優先してください。

Q. 話す内容とスライドが被ってしまう場合は？

A. スライドの文字を削りましょう。 スライドが「台本の転記」になっているサインです。スライドにはキーワードと図だけを残し、説明は話し言葉で行います。聴衆はスライドを「読む」のではなく「見る」ものです。

Q. AIはどこまで使っていい？

A. 構成・図表・変換作業はフル活用して構いません。 ただし「内容が正しいか」「自分の経験と一致しているか」「登壇ストーリーとして筋が通っているか」の検証は必ず人間が行ってください。AIはドラフトを高速に生み出せますが、登壇の信頼性はあなた自身の判断で担保されます。

まとめ：伝わる資料は「工学」で作れる

三本柱の振り返り

この記事では、伝わるプレゼン資料を作るための三本柱を解説しました。

論理構造（情報設計）：ピラミッド原則で結論を先出しし、依存関係のない順序で情報を並べる
視覚設計（デザイン原則）：1スライド1メッセージを守り、レイアウト4原則と余白で認知負荷を下げる
聴衆分析：「誰に・何を・どの場で」を逆算し、ネタと場を正確に合わせる

次の登壇に向けた最初の一歩

まず今日、次の登壇で伝えたい「1文のメッセージ」を書いてみてください。それが固まれば、アウトラインを作り、ブログ記事を書き、スライドへ変換する流れが自然と動き始めます。デザインセンスや経験年数は関係ありません。伝わる資料は、工学的なアプローチで確実に作れます。