こんにちは。デザイナーのひのたん @featherplain です。2018年6月12日 ~ 13日の2日間に渡って開催された、GitHub Satellite Tokyo の Community セッションに登壇させていただきました。
私は人前で話すのはニガテな方です。でも、ステージの上でプレゼンをするのと、ただ話すのとでは大きな差があります。 プレゼンは準備と練習ができるので、やり方しだいでは「伝わるプレゼン」ができるようになります。過去に何回か登壇する機会があったものの、実に2年ぶりの登壇 & しかも主催が GitHub の大舞台！！ということでかなり入念に準備をして臨みました。そのおかげで登壇に向けたノウハウがかなり溜まってきたので、プレゼンに向けて、どんな準備をしたのかをご紹介したいと思います。スライドは記事の最後に掲載しているので、よかったら見てみてくださいね。
目次
- 準備編 1: 何を伝えるか
- ブレないコンセプトを決める: 他の登壇者にはない、私だけの唯一性は何か
- ポストイットで材料を洗い出す
- 材料の取捨選択をする
- 与えたいイメージを意識しながらアウトラインを考える
- 準備編 2: どう伝えるか
- シナリオを作る
- 全体の構成
- 自己紹介は簡潔にする
- 「つかみ」を入れて、問いを立てる
- 伝えたいメッセージを一言で表現
- シナリオを作る
- 練習とリハーサルのすすめ
- リハーサルをやってよかったこと
- 成功体験を得ることで、本番前の余裕につながった
- 客観的なフィードバックがもらえた
- 自分のプレゼンが意図したように伝わっているかが確認できた
- 自分の話し方のクセを把握して、本番前に改善できた
- リハーサルをやってよかったこと
- 本番どうだったか？
- スライド
- 参考
準備編 1: 何を伝えるか
スライド作成の前に、「何を伝えるか」を決めます。どうしてもスライド作成に力を入れてしまいがちですが、自分がどんなメッセージを伝えたいのかをまずは明確にしましょう。
ブレないコンセプトを決める
「OSS や GitHub にまつわる私のストーリーを共有すること」
アウトラインや伝えたいメッセージを考える前の段階として、まずはブレない方針を決めました。最初に方針をしっかり決めておくことで、プレゼンの内容を考える上で迷いが生じなくなります。逆に、万が一迷いが生じたとしても、コンセプトがあることで立ち返ることができます。
他の登壇者にはない、私だけの唯一性は何か
GitHub Satellite においては、登壇依頼内容である「デザイナーという立場で OSS と関わりつつ GitHub で成果物を公開している話」そのものが、他の登壇者にはない唯一性でした。セッション登壇者の中で、デザイナーは私だけ。私の「デザイナー」というマイノリティな立場を全面的に活かす内容にすることで、私にしか言えないメッセージがあるはずだと考えました。
今回はたまたま登壇者の中で自分がイレギュラーな存在だったので、方針をすぐに決めることができました。もし登壇のテーマのイメージが湧きにくい場合は、依頼者にヒアリングをしてみましょう。自分がどんなプレゼンを期待されているのかを事前に確認できると方針が決めやすいです。
ポストイットで材料を洗い出す
方針が決まったら、OSS や GitHub にまつわる体験・考え・エピソードなど、思いつく限りのことをプレゼンの要素としてすべて洗い出しました。ポストイット化のプロセスは、そやさんのポストイットを使えば、プレゼンを作るのめちゃカンタンだよっていうの図解するという記事を参考にしました。
このプロセスで大事なのは、単語レベルで区切って書き出すことです。ひとつの付箋に書いてある情報が少ない方が、後で並べ替えやすいので、洗い出したあとのグルーピングの作業の効率がよくなります。
アナログの作業は一見非効率で時間のかかるやり方に思うかもしれません。一方でデジタルで文章化されたものは並び替えや取捨選択がしにくいため、アナログなポストイットの方がアイデア拡散やエッセンスの整理のフェーズでは効率がいいのです。
材料の取捨選択をする
膨大な数のポストイットをグルーピングして、取捨選択していきます。なかなか根気のいる作業で大変だったのですが、ざっと数えて70枚くらいに落ち着きました。グルーピングされたポストイットの大部分が、スライドやシナリオのキーワードとして実際に反映されていきました。
与えたいイメージを意識しながらアウトラインを考える
抽出したポストイットのキーワードもとに、ベースとなるアウトラインを考えました。
| 与えたい | 与えたくない |
|---|---|
| 親しみやすい | ハードル・敷居が高い |
| 発見・気づき | 憧れ |
こんにちは、はのめぐみです。GitHub に Amethyst と feathericon を公開しています。 「OSS 活動しているよ」と人に言うと「エンジニア？」と言われます。 GitHub には「Built for Developers」って書いているけれど、本当に Developers のため*だけ*のものでしょうか？ OSS コミュニティとの出会い = 原体験エピソード プログラミングができる人以外でも、多様な人が活動しています。彼らに共通するのは、OSS の理念に共感していること。社会的属性や国籍、居住地に関わらず誰もが対等に活動できる世界でした。 OSS を公開 Amethyst の公開を通して得られた体験: 所属や国籍、居住地の違う人との、オープンな活動ができるステージ feathericon の公開を通して得られた実感: プログラマーが作った技術の上で、私のプロダクトは成り立っていること GitHub は OSS は、私がやりたいことを実現するにあたって、とても助けになっています。 OSS コミュニティや GitHub は、本来は多くの人にひらかれているものです。 なので、 `Built for Developers` ではなく `Built for People` ではないでしょうか？
準備編 2: どう伝えるか
シナリオを作る
アウトライン化ができたら、シナリオを詰めていきます。私は「こういうことを言おう」と考えながら実際にスライドを作りながら進める方法をとりました。
スライド作成後の次のステップである練習やリハーサルを通して「やっぱりここはこうした方がいいな」「ここはこういう展開の方がいいな」など直したいポイントが結構でてきます。実際はシナリオ・スライド作成と練習のサイクルを何回かまわすことで内容を洗練させていきました。
そのため、シナリオとして文章化はしつつも、台本のように一言一句暗記するということはしていません。
わたしがシナリオを考えるときに意識したこと
話全体の流れや展開など全体の構成に重点を置いてシナリオを考えました。話の流れをスッキリさせておくと、本番でも話しやすくなります。
- 全体の構成
- 自己紹介は簡潔にする
- 「つかみ」を入れて、問いを立てる
- 伝えたいメッセージを一言で表現
全体の構成
アウトラインをベースに、次のような全体の構成を考え、プレゼンの骨組みをつくりました。 常に「今この話をします ( しています ) よ」「次はこの話をしますよ」と聞いている人に伝えながら話をするよう意識をします。人は忘れてしまう生き物です。特にプレゼンにおいては、自分の話はほとんど理解されてもらえないくらいの心持ちで挑むのがベターです。
ちなみに、図は Sketch のキャプチャです。登壇資料はいつも Sketch で作成しているのですが、縦軸を全体のアウトライン、横軸をセクションごとにスライドを並べています。 全体を俯瞰しつつセクションごとのボリュームがひと目でわかるのでおすすめです。
- プレゼンタイトル
- 自己紹介
- 「つかみ」エピソード
- 結論: 問いかけ
- GitHub: Built for Developers
- "Built for Developers" に対する問いを投げる
- アジェンダ
- 事例・エピソード紹介
- 導入
- トピック その1
- トピックタイトル → トピックテーマ紹介 → エピソード・事例 → トピックテーマ再掲
- トピック その2
- トピックタイトル → トピックテーマ紹介 → エピソード・事例 → トピックテーマ再掲
- トピック その3
- トピックタイトル → トピックテーマ紹介 → エピソード ・事例→ トピックテーマ再掲
- まとめ
- 各トピックの総集
- 結論: 問いに対する答え ( メッセージ ) : Built for People
自己紹介は簡潔にする
自己紹介は必要最低限の情報に絞り、長くならないようにしました。必要以上に自分のことを話してしまうと、聞いている人は退屈してしまうので注意しましょう。30秒~1分程度におさめるのがちょうどいいです。
- 自分の名前
- SNS アカウント
- セッション内容に関係する自分の OSS プロダクト
わたしはこの3つを簡潔に紹介しました。
「つかみ」を入れて、問いを立てる
自己紹介を簡素化した代わりに、つかみを入れました。今回の GitHub Satellite においては私の職業である「デザイナー」と「OSS」が重要なキーワードであり、プレゼンのタイトルにもなっています。そこで、「デザイナー × OSS」の具体的なエピソードをつかみとして紹介し、結論である問いへとつなげました。デザイナーによるプレゼンであることを聞いている人に意識付けられるのもメリットです。
わたしはデザイナーなんですけれども、普段なにしてるの？と人に聞かれて OSS 活動してるよ、というと、びっくりされて「エンジニアなんですか？」って言われます。
☝️「OSS 活動 = エンジニア」というイメージを持たれがちだけど...
みなさんは GitHub のトップページをご覧になったことがありますか？ GitHub には Built for Developers とかかれています。 日本語にすると、開発者のためのプラットフォームですよね。 開発者っていうと、どうしてもエンジニアのイメージが強くなってしまうんですけれども、 GitHub や OSS は、エンジニアだけでなくより多くの人にひらかれているんじゃないか？というのが、今日みなさんにお伝えしたいテーマです。
☝️ GitHub サイトを引用して、「OSS や GitHub は多くの人にひらかれているものでは？」という問いかけをする
こうすることで、「デザイナー」という単語をキーワードにして自己紹介の流れから結論を伝える、という展開にしました。早い段階で結論を伝えることで、「このプレゼンはこういうテーマで進んでいくんだな」と安心感をもって聞いてもらえます。逆に、何の話をしているのかわからないままセッションが進んでいくのは、聞いている人にとってはストレスになってしまいます。
伝えたいメッセージを一言で表現
自分が一番伝えたいメッセージを考えるにあたって、一言で言い表せるキャッチーな表現を用意しておきます。キャッチコピーを考えるのはそんなに得意ではないので、今回は既存のものを引用してもじる方法をとりました。
- GitHub の "Built for Developers": OSS や GitHub は「エンジニア」のイメージが強い
- 私の "Built for People": GitHub / OSS は、本来はエンジニアも含んだ多様な人達のためのもの。より多くの人にひらかれていてほしい、という希望
ゼロから考えるよりは手間が省けますし、対比させることでメッセージが際立つのでおすすめです。
練習とリハーサルのすすめ
あまり練習時間はとれなかったものの、1週間ほどかけて個人練とリハーサルを行いました。 練習は、すればするほど内容に磨きがかかるので絶対にやったほうがいいです。
おすすめなのが、プレゼンを録音してリハーサルをやること。聞いてもらう人数はあまり多くなくても大丈夫です。身近な人で構わないので、自分以外の誰かにプレゼンを聞いてもらって、客観的なフィードバックをもらうようにします。私は社内の開発チームに協力してもらって、リハーサルを行いました。
リハーサルをやってよかったこと
- 成功体験を得ることで、本番前の余裕につながった
- 客観的なフィードバックをもらえた
- 自分のプレゼンが意図したように伝わっているかが確認できた
- 自分の話し方のクセを把握して、本番前に改善できた
成功体験を得ることで、本番前の余裕につながった
本番は緊張するので、「失敗したらどうしよう」「ちゃんと言えるかな」などネガティブな気持ちになりがちです。でも、事前のリハーサルで人前で通しでプレゼンできたという成功体験を持っておけば、「あのときちゃんとプレゼンできたんだから、本番も大丈夫！」とポジティブな気持ちで本番を迎えることができます。いわば心の保険ですね。この時点では、多少言葉につっかえたりしても大丈夫です。完璧なプレゼンをする必要はありません。大事なのは通しでプレゼンをする体験です。
会場での本番前リハーサルの機会がもしあれば、そちらも併せてやっておきましょう。本番前リハーサルで、会場の雰囲気・ステージでの立ち位置の把握・スライドの見え方・登壇の流れなどを事前に把握できたので本番で焦らずにすみました。
客観的なフィードバックがもらえた
下記は社員エンジニアやインターンエンジニアを含んだ、開発チームから実際にもらったフィードバックのメモです。全体的な感想・フィードバックの他にも、スライドごとの細かなフィードバックももらえたので、わかりにくい部分は修正しました。
OSSっていいなと感じられる内容だった。OSSに親近感がわいた。
スライドがかわいい。コラボレーションまでの流れがわかりやすい、イメージしやすい。
独学 + WordCamp 活動でここまできてすごい尊敬する
私は Google に頼りがち。わからないことを GitHub で調べてすごい。前向きになれる。そうやってやればいいんだと思えた。
巨人の肩に乗る、そういう世界が OSS にあるということを感じた。多くの人に開いてほしい。
具体的な話があってこれからのハードルが下げられそう。GitHub への希望があってよかった。同じような考えを持っている人へのアクションの提案、メッセージがあったら刺さるのではと思った。
失敗談や不安だった感情も織り込まれていて、単純なサクセスストーリーではなくしていて良い。
今回の発表の聞く人の視点としては、OSSに現在コミットしたことが「ある人」「ない人」のふたつに大きく分かれると思う。OSSにコミットしたことがある人、現在している人の視点だと、どう聞けば良いのかなーと迷わせちゃいそうな気がする。
自分のプレゼンが意図したように伝わっているかが確認できた
キーワード抽出・アウトライン・シナリオ作成のプロセスを通して、プレゼンの内容はかなり入念に準備したつもりです。どんなに準備しても、意図したように伝わっていなければもったいないですよね。
| 与えたい | 与えたくない |
|---|---|
| 親しみやすい | ハードル・敷居が高い |
| 発見・気づき | 憧れ |
上記はアウトライン化の時点で整理した、与えたい・与えたくないイメージです。概ね狙った通りの反応がもらえたので自信がつきました。スライドがかわいい・分かりやすいと言ってもらえたのは純粋に嬉しかったです。( 別の機会に、スライドのデザインテクニックの記事を書こうかな... ) もし、意図したような反応が得られない場合はプレゼン内容を見直す必要があります。
自分の話し方のクセを把握して、本番前に改善できた
録音した音源を、リハーサル後に何回も聞き直して自分の話し方のクセを研究しました。
気がついた口癖:
- やっぱ、やっぱり
- えっと
- あの
- ほんとに
話し方が冗長気味:
- 〇〇なんですけど、... 〇〇 っていうと ... 〇〇があって、...〇〇というか、を繰り返して一文が長くなりがち
リハーサル後の練習や本番では、多少言葉を選んでもいいので、なるべく口癖がでないように意識しました。冗長気味な話し方は、一文を短くして「です/ます」で言い切るようにしました。例えばこんな感じです。
Before:
スライドに Door と書いてみました。 OSS の入り口って多分ほんとにいろいろあって、ホントに人によって様々だと思うんですけど、 わたしの場合は人との出会いがほんとにきっかけというか、入り口だったんですね。
After:
スライドに Door と書いてみました。 OSS には、人によっていろいろな入り口やきっかけがあると思います。 みなさんの中には、OSS にコミットした方もいらっしゃいますよね。最初に OSS にコミットしてみたときのことを思い出してみてください。どんなきっかけだったでしょうか。 わたしの場合は、人との出会いがきっかけでした。
( 意識していたとはいえ、本当にできていたのかどうかはセッション動画が公開されるまでわかりません...😱 )
本番どうだったか？
事前のリハーサル効果がとても効いていたので、落ち着いて話すことができました。「魅力的なプレゼン」でなくとも、準備と練習をしっかりしておけば「伝わるプレゼン」にすることができます。
GitHub 社員の方からも、「面白かったよ！」と言っていただけてとても嬉しかったです。
Designer Hano Megumi didn't have a background in programming but that couldn't stop her from becoming a passionate open source community member and speaker at #GitHubSatelliteTokyo. She shared her challenges and insights with Day One attendees. https://t.co/UT1PPyXK8c
— GitHub (@github) 2018年6月12日
スライド
参考
今回のプレゼンの準備で参考にした記事です。事前に読んでいたおかげで、とても助けになりました✨🎉
いっしょに開発しませんか？
キッチハイクでは、フロントエンドエンジニア・React Nativeエンジニア・Railsエンジニア・インターンエンジニアを募集中です！
