スライドを3時間で作るテクニック
いつも登壇資料は当日に作ってますshokai.icon
最近の例
リハーサル日の11時ごろ作り始めて、14時すぎに完成した
新横浜→京都行きの新幹線で作った
このprojectにある全ての発表資料が、当日の朝起きてから作り始めている 記事も2〜3時間で書く
社内レビュー日の朝8時に作り始めて、11時に提出
これは1時間遅刻した。すみません
3時間ぐらいで書いた
書き始めるのが1日遅れました。誠に申し訳ございませんでした
どうやるか
ポンポンと発表アイテムを並べる
例
関連ページとは？
関連ページスタック
mongodbのqueryのテクニック
shokai.iconはアプリケーション開発者なので、アプリケーションの各機能が、プレゼン内の「発表アイテム」となる
並べた発表アイテム1つずつ、個別にストーリーがある
pros / cons
問題 / 解決
試行錯誤
採用しなかった解決方法
全部入れると収拾つかないかもしれないけど、とりあえずメモ書きしておく
不要な物は後で削る
並べたアイテムをまたがった大きなストーリーを作る
最初に並べたアイテムをソートしたり、取捨選択したりする
いい感じの流れがピーンと来るまで混ぜ混ぜし続ける
「処理対象の広がりと、実際に処理できるか」について
人間が
システムが
を色々述べる感じでいくと良さそうだ！と急にわかる
完成
並べたアイテムそれぞれが面白くないはずがない
そこには色々な試行錯誤がある
それぞれ面白さが言語化されている
面白いアイテムを並べてるのだから、全体としても面白いはずだ
構成が支離滅裂ではない限り
並べたアイテムをまたがった大きなストーリーが作れないはずがない
アプリケーション開発者は、機能群をまとめて1つのアプリケーションにしている
機能を貫く考えがある
機能同士の連動、関係性、相互作用がある
それをそのまま話せばいい
ネタが足りない、説得力が足りないと思った時どうするか
開発者は開発をするべき
スライドを作るな
調査
計測
プロトタイピング
ユーザーテスト
もしどうしても「スライドが面白くない」と感じたら、開発をしましょう
開発してプロダクトに面白ポイントを発生させてから、スライドを作る
読者や来場者に感動してほしいポイントとかは考えてない
ユーザーはアプリケーションを使って感動する
開発者なのでそっちに自分の軸足を置く方針
良いアプリケーション・サービスがあって、それをただ説明するだけでいい
それで面白くならなければアプリがダメなので、開発の時間を増やすべき
おもしろ素材を揃えてから後で辻褄合わせればいい
辻褄が合わないはずがない
合わないとしたらプロダクトが1つのアプリケーションとして成立していないはず
つまり実は開発の時点で、スライド作ったり、他人に説明するような切り口を複数想定しているという事ですshokai.icon