Zenn
💬

SAが思う、スライド資料作成の観点と手順 - 準備編 -

2021/01/04に公開
スライド
プレゼン
idea

まえがき

IT技術者ってコーディングだけが仕事ではないですよね。もちろん正確にきれいなコードを書いて、適切なコメントを残せることも重要な能力ですが。

自分の取り組みを発信する、技術的知見を広めることも技術者の大切な仕事だと私は思います(特許制度の目的も産業の発達ですよね)。最近では技術系イベントが多く開かれ、技術者が講演するというケースも多くなってきました。そこで欠かせないのはスライド資料です。

ただ、スライド資料がめちゃめちゃになってしまい、聞き手に伝えきれていない人が意外と多いです。とりあげているトピックはよいものなのに、それが聴衆に伝わらないのはもったいないことだと感じていました。
そこで、筆者の経験則ですが、スライド資料や講演の作り方の一例を記事にして公開します。他に良い方法があるとか、改善案があればコメントお願いします。

前提

筆者は何者か

とあるSIerのR&D部門でビッグデータに関するソリューション開発に従事していました。その傍ら、顧客への提案と技術支援(マネージャー職だけでなく技術者とのディスカッション、レクチャーを含む)をすることもありました。特定の顧客を担当せず、製品や技術を担当しており、SA(Solutions Architect)みたいなもの、と言うとわかりやすいかもしれません。

この記事で言う資料とは

イベントで講演するとき、投影して見せるスライド資料を想定します。配布資料ではありません。配布資料をスライド形式で作成する場合には、別な観点がありますのでいずれ別エントリーで書きます。

資料作成の準備

まずはテキストエディタを開く

テキストエディタはメモ帳やサクラエディタ、viでも何でも構いません。

スライド資料を作るというと、文字を小さくしすぎないとか、1ページで触れるトピックは1個だけとか、主にスライド1枚の中の話に着目しがちです。それも大切ですが、そもそも伝えるべきコンテンツが全体を通して固まっていない状態では、あまり効果は期待できません。したがって、まずは話す内容を「テキストで」整理しましょう。

箇条書きは原則しない
論理を整理するときは、時制や主述関係を明らかにし、誰が読んでも同じ理解ができる文面にしなければならないからです。箇条書きでそれをできる人は多くありません。したがってこの段階では、Markdownもおすすめはしません。

講演の目的や聞き手の能力水準を整理する

スライド資料に直接書くものではないからか、ここをすっ飛ばしている人は非常に多い印象があります。慣れないうちは面倒でも意識して文字に起こすようにしましょう。

  • 「講演の本当の目的」を決める。
    いわゆる裏テーマです。公表するものではないので野心的なもので構いません。例えば
    ・新規顧客獲得のために自社の取り組みの目新しさをアピールする
    ・他社から顧客が乗り換えることを狙って、競合の弱点を自社は克服できていることを暗に示す
    ・自分の名前を売って転職に有利になるようにする

  • 「講演の目標」を決める。
    これを達成できるように後ほど講演や資料を作り込みます。例えば
    ・技術検証で得たノウハウを公開して技術の普及に貢献する
    ・トラブルシュートの知見を公表して顧客の自己解決を促す
    ・よくある導入パターン(ベストプラクティス)を公開して受注につなげる

  • 聞き手はどのような人なのか想定する。
    技術系イベントであれば聴講者の技術的能力水準を想定します。ビジネスカンファレンスであればターゲット層のPosition(Responsibility)も考慮します。例えば
    ・とある技術領域の初学者が勉強のために聴講している
    ・Amazon Elastic MapReduceの運用で困っている技術者が成功事例や改善策を探している
    ・オンプレシステムをクラウドへ移行することを考えている経営職が使えそうなベンダを探している

期待する結果を決める

講演が終わったとき、聞き手はどのような状態になっていれば「講演の目標」を達成できたといえるのかを考えます。例えば
・技術的な内容で講演者に質問したいことが思いついている
・困りごとを解決できそうな案を思いついた
・講演者名や自社名でWEB検索をしている

最低限聴講者に提示すべき情報を検討する

聞き手がどのような人であるかは既に想定しました。聞き手が「期待する結果」にたどり着くためには何が足りていないのか、どんな情報を提供するとたどり着けるのかを考えます。もちろん聞き手の能力水準から達成できるものでなければなりません。
例えば
・OAuth2.0という認可のリクエストとレスポンスの仕組みを定めたものであること、いくつかの認可フロー(パターン)があること、加えてそれを実現する方式を紹介する
・S3とのデータ転送のタイミングや利用するインスタンスの数とサイズの運用、アプリの作りで課金を抑制できた方式を紹介する
・クラウドリフトの実績、コンサルティングや技術支援サービスの紹介を盛り込む

まとめ

この記事ではスライド資料を作るための事前準備をしました。この準備をしておくと行きあたりばったりになったり、やり直しを繰り返すような事態はかなり回避できるようになります。

次回投稿では、ストーリー展開やロジックの観点で要点を挙げたいと思います。

Discussion