まだ生きているようです

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
-------- : スポンサー広告 :
Pagetop

Dr.こだかの"俺用"プレゼン メソッド~その6~

■目次
その1 ~ 構成を考えるには、細かいところから ~
その2 ~ キーとなるメッセージを見つけてみる ~
その3 ~ スライドを作成するときのポイントを考えてみる ~
その4 ~ デモとデモラーを系統分類してみる ~
その5 ~ タイムマネジメントを考えてみる ~
その6 ~ 話し方を考えてみる ~

■初めに
今回で最終回のつもりです。最後は話し方のポイントについて書きたいと思います。
と言っても、実は確固たる何かや、いわゆる銀の弾丸があるわけではないんですね。
完全に自分仕様ですが、メモとして残しておきます。

■(※)ただし・・・に限る
正直言って話し方がヘタならば、その先のシナリオ云々がどんなに良くても、そのプレゼンは正規に判別してもらえないでしょう。
例えば、「話は良いのかもしれないけど、眠くなるんだよねー」なんて事は、言ったことありませんか?

そうなんです、プレゼンも「(※)ただしイケメンに限る」と同じ世界なんです(笑)
中身がどんなに良くても、表面に見えている(聞こえている)ところが、まず最初のハードルと言う訳ですよ。

では、皆さんが聞く立場だったとき、(※)の判断(笑)を下すのは、どのような状況でしょうか?
・声が小さい
・お経のように抑揚がない
・難しい、意味が分からない

だいたいこんなところだと思います。
僕はこの内、表面に見えている(聞こえている)ところのハードルは、上2つでほぼクリアなんじゃないかと思います。
例えば、駅前の選挙演説。
まぁうるさいく感じる事もあるわけですけど、話の途中からでも聞いて見ようかと思うこともありません?
大きな声で、主張が明確な場合は、意味が分からなくても、そんなに不快ではないと言うのが僕の持論です。

抑揚は結果
ですので、最初に上2つについて考えてみましょう。

まず、声が小さいのは簡単です、大きく話してください。
これにコツも何もありません。常識の範囲で背筋を伸ばして、顔を上にあげて・・・ってもういいですよね。

問題は抑揚です。
話し手に抑揚がなければないほど、僕のお休みモード移行時間は早いです。
お経はまだいいんです、特に正座が睡眠を許さない(笑)
しかし、パシフィコ横浜のホールは、薄暗いし、座席もフカフカだし、横浜遠くて朝は早いし、パンは食べ放題だし(TechEdです)で、条件が良すぎます(笑)

パシフィコ

横道にそれました。
皆さん、これまでの社会人経験の中で、プレゼンのフィードバックを受けた事は1度ぐらいはあると思います。
そして、「抑揚がない」と言われた事のある方、きっと居るのではないでしょうか?
僕も言われましたし、他人にフィードバックしたこともあります。

しかし、じゃあ抑揚をつけましょう!と言ったとしても、どうするのが良いのか?
特に対策しなければ、こうなりがちです。
は、れから、ADO.NET EntityFramweworkの、を説明します。」
そして、大抵数分すれば元に戻ってしまいます。
これ、ヤル意味0です。
抑揚をつける決意なんて、ちょっとテンパったり、時間がたてば、どこかに消えてしまいますよ。

では、僕はどう考えているか?
僕は、「主張するべき点を明確にする」これが結果的に抑揚につながる。と考えています。
この為に、キーメッセージを明確に(その2参照)して、スライド1枚の責務(言うべきこと)(その3参照)を考慮してきたとも言えるわけです。

つまり、言葉として抑揚をつけるのではなく、言うべき内容によって(結果的に)抑揚がついてしまう
そのスライドの言いたいポイントが明確なわけですから、そこを強めて言わないで、どこを強調するのか?と言うことなんです。
具体的には、例えば細かい話ですが、「ここが、超便利なんですよー」などと言った、ちょっとした口語表現を使ってみたり、「もう一度言いますね・・・」のように何度も繰り返したりですとか、まぁその場で何とでもなる工夫などが相当します。

抑揚と言うのは、結果がそう見えているだけであって、本来の目的ではないと言うのが僕の持論になります。

また、その5に書いた「一言一句覚えているわけではない」の理由の一部もここにあります。
主張を明確にしているため、大筋があっていれば細かくはどうとでもなると言うことですね。

■難しい、意味がわからない対策
では最後に、「難しい、意味がわからない」の対策を考えてみましょう。
これも、絶対解なんてあるわけではないと思うのですが、まぁ自分なりの考え方としてです。

僕が思うポイントは以下3点です。
1)話は大きなところから小さなところへ、かつシーケンシャルに
2)ラベルを意識する
3)共感を大切にする

まず、1)です。
あたりまえと言えばそれまでなのですが、かなり出来ていない人が多いような気がします。
プレゼンでも、デモでも、いきなり細かい話をされても意味が分からない事が多いです。
その細かい話をする背景⇒手段⇒結果と言った形で、大きなところから少しずつ細かい説明をしない事には、話の筋を見失ってしまいますよね。

そして、ポンポン色々な話に飛ばないこと。
話をしている人の中では繋がっているのかも知れませんが、聞いている人は、先ほどまでの話とどう繋がっているのか分かりませんからね。

次に2)です。
まぁこれも当然なんですが、話をするときに、これから何の話をするのか?それが大きく何点あるのか?と言った情報を短く分かりやすいラベルとして、初めに宣言してあげると良いかと思います。
例えば、チープな例ですが「○○の背景として、大きく3点ご紹介します。」などと言った感じですね。

ここまでは、どこにでも書いてあるのことなので、あえて言う必要もないのかも知れません。
まとめれば、聞き手を迷子にさせない考慮が1)と2)になります。

最後に3)になります。
僕はここが一番大切だと考えています。

これは、聞き手に「あぁーあるある」と思って(共感して)もらうこと。
これを意識すれば、「お前○○って言いたいだけちゃうん?」と言った自己満足的な表現の抑制(いますよね、やたら難しい表現や不必要な英単語を使う人)や、一般的な例え話を心がけること(例えて言ったせいでますます意味不明)などを考慮することになるはずです。

つまり、相手を見て、そのボリュームゾーンに一番響くであろう話をすることなんですけども、これは結構むずかしいです。
バランス感覚が大切というか、、、自分が普通と思っても、他者にとってはそうではない事も、ままあります。
これには、常日頃から沢山の人と接して自分の考えが極端にブレていない事を確認していくのが一番かなと思います。
とにかく、独りよがりにならない事が重要です。

■最後に 百見は一動にしかず
先日週刊少年ジャンプにて、ヘタッピマンガ研究所Rという漫画を読みました。
作者が色々な漫画家に取材を行い、漫画を書くときののコツのようなもの聞きだして読者に伝えると言う内容です。
最終回だったのですが、そこで印象的な話がありました。

それは、「今まで聞いた話は全部忘れてください」と言うものでした。
「いくら言葉で聞いても、真の意味は理解できないはず。
自分がやってみて、それこそ真っ暗闇を自分の力で進んでいく中で、これまで聞いた金言を実感する時が来たときに、初めて自分の進んでいる方向が間違っていない事がわかる。
それまで聞いた話は、その参考情報にしなさい。」という内容でした。

僕はエバンジェリストになったとき、まさに真っ暗闇でした。
口下手な僕が数百人の前でプレゼン!、技術力の劣る僕の話をだれが喜んで聞いてくれるのだろうかと。
周りのエバンジェリストの方は、色々な情報をくれましたし、セッションも見学させてくれました。
もちろん、これも有効なのだと思います。しかし、実際に血肉になったのは、「自分でやってみて自分なりの方法を見つける」ことでした。そして、ある程度山を登って初めて、以前聞いた同僚エバの金言の真の意味を理解できたと思いました。

「百聞は一見にしかず」の次のフェーズ、「百見は一動にしかず」(こんな言葉があるかは知りませんが)を実感したのです。
スポンサーサイト

テーマ : なんとなく書きたいこと。。
ジャンル : 日記

tag : 自分メモ プレゼンテーション

2010-05-23 : 自分メモ : コメント : 1 : トラックバック : 0
Pagetop

Dr.こだかの"俺用"プレゼン メソッド~その5~

■目次
その1 ~ 構成を考えるには、細かいところから ~
その2 ~ キーとなるメッセージを見つけてみる ~
その3 ~ スライドを作成するときのポイントを考えてみる ~
その4 ~ デモとデモラーを系統分類してみる ~
その5 ~ タイムマネジメントを考えてみる ~
その6 ~ 話し方を考えてみる ~

■初めに

はい、読者を置いてきぼりにして独走中のこの企画、今回はタイムマネジメントについて紹介します。

なんだか、書き急いでいるような気もしますが、これには理由があって、急激にエバンジェリスト脳が薄れてきているからです。まぁ当たり前ですよね。

転職して、僕は今アーキテクト見習いのようなポジションなんですけど、悩んだり、考えたり、とにかく脳みその余裕なんてないのですから。

忘れないうちに早く書かなきゃってことです。

 

■プレゼンテーターは罪を背負っている

僕は人と話をするのが苦手だというのは、その2に書きましたが、その根底にあるのが、この「プレゼンテーターは罪を背負っている」という意識なんです。

 

プレゼンテーターは、その場にいるだけで罪深き存在です。なぜなら、聞く人の貴重な時間と理解してもらう苦労を掛けるからです。ですので、その贖罪の為には、発信する内容は、短く、分かりやすく、そして、綿密な計画が必要不可欠だと思うのです。

 

この意識が、通常のコミュニケーションにも働くので苦手意識があるんですよね。とっさにできないですもん。飲み会の場とかで。事前に計画できるプレゼンは、そうした意味では楽なんです、僕にとっては。

 

話が前後しますが、もちろん最大のタブーは「タイムオーバー」です。僕は自慢ではありませんが、1分以上オーバーしたことは(基本的に)ありません。

一度、技術ひろばさんに登壇したときに、代表の瀬尾さんにOKをもらってオーバーしたことはあったのですが、例外中の例外でして、この時も話していて申し訳なくなってきました。

 

本当に、人前で話すことに苦手意識があるんです・・・

 

■タイムスケジュール表を付けてみる

僕は大体、短く、分かりやすくを条件に、それまで作ってきた本番プレゼンの構成を、改めて表にして、タイムスケジュールの指針としています。

 

このフォーマットは、別に適当でいいんですけど、下図のようにやっていました。

20100522_Timemanage

上記は、TechDays2010で僕が登壇したセッション「WCF Data Services の新機能と  Open Data Protocol」で使用した実際のスケジュール表の一部です、各スライドで言いたいことや、注意しなければならないこと、そして、大体どれくらいの時間で話をするべきかを決定するためにも使っています。

 

デモに関しても、軽くまとめています。

 20100522_Demo

この辺りは議論の分かれるところなのですが、スライド1枚1枚に対して必要な時間を書いても意味がないと言われることもあります。もちろん僕もすべてのスライドに対してやっているわけではなく、言いたいことのまとまりとして、必要な時間を考えています。

しかし、その3でも書いたように、僕は1枚のスライドにしても、責務があると思っていますので、それを達成するために必要な時間を必然的に考慮することが多いです。

 

ただ、これを付けていると、「ここは何分で話さなければならない」という浅はかな思考にとらわれやすくなります。指定された時間内に詰め込んでしまうわけですね。

本来は「ここを説明するには何分必要である」と考えるのが正しいはずです。

そうした見積もりも行う必要があります。

 

■見積もりのつもり

みなさん、70分のセッションを依頼されたらどう思いますか?

きっと、「そんなに長く話せない」と考える人もいると思います。

では、30分ならどうですか?

「それぐらいなら」と思うかもしれませんし、「まだちょっと」と思うかもしれません。

でも15分なら出来そうじゃありません?

数百人の前のセッションでも、それくらいなら何とかなりそうですよね。


そうなんです、実際にやってみるとわかりますが、15分のミニセッションを4回行うと、大体70分のセッションになります。

 長いと思うセッション時間も、こうして分割して考えてしまうと、実は思ったより大したことではなく、見積もりを比較的簡単に行うことができます。


つまり見積もりとして、1つの言いたいことのまとまり(説明+デモ)で15分~20分を基準としてしまえばよく、僕はそれをベースに時間を決めていました。(って全然本来の見積もりの話になっていませんね・・・だから見積もりのつもりなんですけど 笑)

■エアセッションをやってみる

しかしながら、見積もりと実績は大抵乖離するものです(今ドキッとした方がいるでしょう 笑)

そこで、本番さながらのエアセッションを行うことになります。

と言っても、そんなに大したことではありません。
僕の場合は、自宅の部屋に鍵をかけて、家族には「なにがあっても開けないこと」を言い聞かせて、自分の世界を作り、そこで一人でグフフ、じゃなくて(笑)練習を行うだけです。

そうすると、かなり実績に近いデータが取れますし、スムーズな話し方の練習にもなります。

それにより、カットしなければならない部分や、もう少しふくらませてもよい部分、あるいは順番を変えた方が説明しやすいところなどが明確になるわけです。


ちなみに、僕はエアセッションを通しで最低3回は行ってました。

そうじゃないと、口が回らないんです。元来口下手な僕が話をするためには、多くの練習が必要となるのです。(ですので、僕はパネルディスカッションやQAが大の苦手なんです、アドリブで話を構成しなければならないからです。あと自己紹介で笑いを取ったり、、、練習しなくても面白い話ができる人が本当にうらやましいです。)

しかしもちろん、一言一句を覚えるわけではないですよ。

そのあたり、実際の話をするときの、自分なりのポイントを次回書こうと思います。

で、それが最終回ですね。

テーマ : なんとなく書きたいこと。。
ジャンル : 日記

tag : 自分メモ プレゼンテーション

2010-05-22 : 自分メモ : コメント : 0 : トラックバック : 0
Pagetop

Dr.こだかの"俺用"プレゼン メソッド~その4~

■目次
その1 ~ 構成を考えるには、細かいところから ~
その2 ~ キーとなるメッセージを見つけてみる ~
その3 ~ スライドを作成するときのポイントを考えてみる ~
その4 ~ デモとデモラーを系統分類してみる ~
その5 ~ タイムマネジメントを考えてみる ~
その6 ~ 話し方を考えてみる ~

■初めに
えー、もう皆さんいい加減にしろと思われているかもしれませんが、心の師匠高添さんの以下の記事にインスパイアされたこの企画、最後まで突っ走る気満々でございます。

Dr.高添の”誰でも”プレゼン 8 TIPS ~その1~
http://blogs.technet.com/osamut/archive/2010/01/24/3307930.aspx


今回はデモのお話をしたいと思います。
一般的なプレゼンテーションではあまり関係ないと思いますが、テクニカルセッションや勉強会では付き物ですね。

エバンジェリストにとってデモンストレーションは、腕の見せ所のような側面があります。ギタリストにとってのギターソロみたいな物に近いです(?)
しかしながら、やはりデモ一つ一つに何かしらの意味があり、単に実行すればよい、訳ではないはずです。

■水見式かよっ!
HxHではありませんが(笑)、僕はデモとデモラーを以下の6種類の系統で分類していました。

解説 アプリケーション自体、機能、コーディングの持つフィーチャーを実際に動かすことによって端的に解説する。日本でごく一般的に行われるデモの殆どがこのタイプ、「見ていただいた方が早い」がキーワード。
証明 実際に1から手順を踏むことで機能やコーディングの過程と結果両方を理解してもらう。
コーディング職人タイプの人が行うことが多い、資料もなく、証明デモに終始してしまうこともある、また、USではこのタイプは比較的多い。
事例 お客様事例や開発事例の一部を紹介する、美しい見た目や、見栄えのする結果が必要。
マーケティングの担当社員やキーノートなどで行うことが多い、内部の細かい情報ではなく、そのものの成果を前面にだす。
参考 プレゼンの本流に付け加える情報や、よりアドバンストな説明を行う。
時間が余ったときに行うデモであったり、お客様の期待値に対してコントロールする場合でも行う。「知っている人が多いので、もう少し難しいデモを・・・」といった場合など。
「ちなみに」とか「説明していませんが」などがキーワード。師匠である松崎さんが上手い。
Wow 見た目や結果が楽しく、見ている人を驚かせたり、注目を集める目的で行う。アイスブレイクもこの一種。
エンターテイメント性を前面に出し、受けや滑りなどの意識も必要。MSではなんといってもジニアス平井さん。
その他 見ている人に実際に操作してもらうなど、通常のプレゼンの範疇に入らないタイプのデモ。
MSではTechFieldersセミナーの道場スタイルという形で実際に行われています。心の師匠高添さんのフィールド。

で、僕はと言うと、やはり解説型なんだと思います。レーダーチャートで表すと自分の能力は以下のようになると分析しています。

Demo

このレーダーチャートの上下に並んだ関係の系統は「苦手分野」、両隣の系統は「準得意分野」と考えてください。
つまり、解説型の僕は、事例型デモは苦手で、参考型と、証明型のデモは、そこそここなすと言った感じです。

自分の系統を知るには、グラスに水を入れ、浮かべた葉に対してデモを行い・・・嘘です、すみません調子に乗ってしまいました。
(注)系統とか、こだかが適当に考えたものなので、真に受けないでくださいね。(笑)
(MS現役のエバンジェリストの方、賛同頂ける場合は、ご自身や他のエバのチャートを考えてみてください。)

真面目な話、こうしたデモの種類を意識して、何のためにこのデモを行うのか?と言った目的意識を明確にすることが非常に重要と考えています。

■何事もバランスが大切だよね

どういったデモをどのタイミングで行うべきか?は、スライドの構成(その3参照)と同じく、キーメッセージが決まれば、必然的に決定されると考えます。
しかし、そうは言っても、ある程度のバランスは必要なはずです。

・結果が分かりやすい、「解説」
・手順を踏むので、過程も見せられる「証明」
・てこ入れで「Wow」

僕は基本的に、この3つの系統を6:3:1ぐらいの割合でミックスすることが多かったです。
もちろん、証明デモの手順スピードを上げるために、コードスニペットを用いたり、デザインされているFormモジュールを使用したりと工夫はしています。
杓子定規も良くないですからね。

■デモがもたついたら悪即斬!
と言った形で、特に強い決まりを考えたわけではありませんが、絶対的なタブーもありました。

それが「もたつき」です。
自分がオーディエンスだった時、デモの途中でビルドエラーが起きれば、高い確率で手元の資料の別の部分を見たりと、セッションへの集中が切れてしまいました。
その結果、本来見なければならない所を見逃して、分からなくなる事が多くあったのです。

ですので、ビルドエラー、デバッグ、バックスペース、手順のド忘れなどは、絶対に起こさないように、もし起きてしまったら、完成品をそのまま見せるなどのリカバリが必要になります。
(自分はバックスペースやdeleteキーもNGでした。)

デモは流れるように、ミスは絶対に起こさないように、念入りに準備します。
「えーっと」「あれどこいったかな?」「おかしいですねー」となるセッションは、自分的には悪即斬ですね。

■リファクタリング?なにそれ?おいしいの?

開発者ならば、美しいコードは、3度の飯より美味しいわけではありませんが、ある程度要求されますよね。
しかし、ことデモのコードは、なるべくベタに書いた方が良いというのが持論です。

同じロジックがあるから、関数にして・・・って同じロジックを何度も説明するわけではありませんからね。
返って、イベントプロシージャにベタ書きの方が、やっていることが分かりますので自分は好きでした。

他にも、コメントですとか、フォントサイズですとか、拡大ツール(ZoomITお勧め!)ですとか、注意するポイントはいくつかありますが、常識の範囲で調整していました。

まぁ、この辺は書く必要もないでしょう。

さて、次回は・・・って、読者を無視して暴走しているような気もしますが、いいんです、個人Blogなのですから(笑)
タイムマネジメントとタイムスケジュール表について書こうかと考え中です。

テーマ : なんとなく書きたいこと。。
ジャンル : 日記

tag : 自分メモ プレゼンテーション

2010-05-19 : 自分メモ : コメント : 0 : トラックバック : 0
Pagetop

Dr.こだかの"俺用"プレゼン メソッド~その3~

■目次
その1 ~ 構成を考えるには、細かいところから ~
その2 ~ キーとなるメッセージを見つけてみる ~
その3 ~ スライドを作成するときのポイントを考えてみる ~
その4 ~ デモとデモラーを系統分類してみる ~
その5 ~ タイムマネジメントを考えてみる ~
その6 ~ 話し方を考えてみる ~

■初めに
今回はスライドを作成するときのポイントを書きたいと思います。
ポイントと言っても、起承転結や序破急、あるいは演繹法や帰納法といった、構成手法に関してどうこう言うつもりはありません。
キーメッセージ(その2参照)が確立さえしていれば、こうした構成は自然に決まってくると言うのが自分の考え方です。(ここでも細かいところから大きなところになっていますね、偏っています。)

よく小説家や漫画家が、キャラクターが勝手に動いてストーリーを作った、などと言うことがあります。
もちろん、これは比喩なわけで、ストーリー前後の状況やキャラの性格が確立しているので、必然的にそうしたストーリーになってしまった。と言うのが自分の解釈です。
自分のプレゼンもこの感覚に近いのかも知れません、キーメッセージと、各スライドが確立していれば、と言う条件の元ですけどね。

■スライド一枚に宿る何か

では、各スライドが確立しているとは一体どのような事を指すのでしょうか?
僕は「スライドに対する責務が明確である事」と考えます。

理由なく存在するスライドはあり得ないわけです。
各スライドは一枚一枚に必ず役割があり、その責任範囲がおのずと決定されていると思うのです。

つまり、スライドを作るときは、このスライドは○○するために必要だから、この順番でここに配置されている。
と言った理由を必ず意識して、(このスライドは)要するに○○が言いたいことである、と第3者に説明することが出来るようにしなければなりません。

具体例を見てみましょう。

例


これは、心の師匠MS高添さんの「Dr.高添の”誰でも”プレゼン 8 TIPS ~その4 拡大ツールを活用しようの巻~」から拝借したものです。

このスライドは、もう何がなにやらわけがわかりません。これでお客様に説明するのは一見不可能のように思えます。
高添さんが、このスライドをどのように使用するかは分かりませんが、僕なら以下のような目的として使います。

「こんなに沢山考えなければいけない事がありますが、MSなら全方位的にカバーすることができます」
と言うことを印象付ける

如何でしょうか?
実際のプレゼンのときにも、このスライドの文字を逐一説明することはないはずです。
とにかく要素が沢山あって、全部カバー出来ているよ、と言うことを主張することが、このスライドの目的となるわけです。
その為に、あえてゴチャゴチャ書いているのですね。


■すっきり箇条書き

前の図は高添さんも書いていますが、ちょっと極端かつトリっキーな例ですね。
僕はスライドの基本は、その1枚で主張したいことを箇条書きで明確にすることだと考えます。

時折、箇条書きのようで、実質は長文の文章が書いてあるだけのスライドも見受けられるのですが、そうしたスライドは(僕には)ちょっといただけない。
短くすっきり箇条書き、それも3つぐらいの要素に留めたいものです。
もちろん、文字の大きさもできるだけ大きく見せたいですよね。

また、確かにスライドに資料の要素を持たせたいという話は時折出ます。
その場合、どうしても厳密な記述が必要になってしまい、文字は小さく文章は長くなりがちです。
僕ならそれはAppendix行きですね。
参考資料や付録なら、好きなように書いても良いと自分の中では決めています。


■図表、そしてアニメーションの功罪

体系立てて、しかも少ないスペースで伝える為には、図表は必須です。
しかし図表は、プレゼンテーターがどこを話しているかが分かりにくくなってしまいます。

そこでアニメーションを使用して強調してあげます。僕はアニメーションはその為にあると考えます。
あとは、流れなどを示す場合ぐらいですかね。反対にそれ以外の殆どのアニメーションは、僕には必要ありません。
と言うより、アニメーションがあると、印刷資料は分かり難くなりますし、プレゼンにも工夫が必要になってくるなど、返って存在自体が邪魔な事が大半です。

■ソースコードは鬼門
僕にとって一番難しいのが、ソースコードの取り扱いです。
ここは、自分としても明確な回答を持っておらず、いつも悩んでいます。

問題点は以下の4つにあると考えています。
・どこを説明しているのか分かりにくい。
・実行結果が分かりにくい
・コードの一部しか載せられない(スペースの関係)
・文字が小さくなってしまう

ソースコードの色や枠線を用いて説明箇所を目立たせるようにしていますが、なかなか難しいものです。
したがって、完全に反対派ではありませんが、実質は好きではない表現方法です。
こういうのはAppendix行きか、デモ自体で説明する方がいいと考えています。

さて次回はデモについて書いてみたいと思います。
イベントでのデモは各エバンジェリストの腕の見せ所だったりします。
僕がどう考えているのかをお話させてください。

テーマ : なんとなく書きたいこと。。
ジャンル : 日記

tag : 自分メモ プレゼンテーション

2010-05-17 : 自分メモ : コメント : 0 : トラックバック : 0
Pagetop

Dr.こだかの"俺用"プレゼン メソッド~その2~

■目次
その1 ~ 構成を考えるには、細かいところから ~
その2 ~ キーとなるメッセージを見つけてみる ~
その3 ~ スライドを作成するときのポイントを考えてみる ~
その4 ~ デモとデモラーを系統分類してみる ~
その5 ~ タイムマネジメントを考えてみる ~
その6 ~ 話し方を考えてみる ~

性懲りもなく、その2です。

■ちょっと一言

僕は別にプレゼンが得意なわけではありません。

これは謙遜とかではなく、正直僕は人と話すことが非常に苦手なんです。と言うより苦痛に近い。

そんな僕がエバンジェリストとしてやっていくには自分なりのメソッドを確立するしかなかったという、そんなシリーズがこの記事です。

 

もう少し、僕の苦手な部分をドリルダウンすると、大きく以下の3点がダメです。

1)会話のイニシアチブをとる

2)自分のことを話す(しかも"おち"をつける)

3)相手から話を引き出す

多人数の前のプレゼンでは、1)は保障されていて、さらに3)は関係ありません。

したがって2)だけを意識すればよいことになります。

つまり、僕がプレゼンを行うためには、2)をまかなうため、綿密な計画が必要となるわけです。
(まぁ"おち"はないんですけどね。)

 

■キーメッセージ(抽象度を下げた目的)を発見する!

前置きが長くなりました。

前回は、自分の好き嫌いや感性で、目的もなくプレゼンを固めていくところを紹介しました。

下記のようなサイクルで行う話でしたよね。


ポイント


さて、このサイクルを何度も繰り返していくうちに、自分なりのキーとなるメッセージが自然に見えてきます。

このキーメッセージの発見が、自分の中では一番重要です。プレゼンテーションのすべてのよりどころが、ここにあると思うからです。

逆にこれが明確でないプレゼンテーションは、自分には話すことは出来ません。

 

もう少し具体的に書きます。

例えば、TechDays2010というイベントで僕が担当したのは、

「WCF Data Services の新機能と  Open Data Protocol」

というタイトルのセッションでした。(上記のサイトからビデオとPPTの入手が可能。)

 

ちなみに、このセッションはUSでおこなった以下のセッションの日本版の位置づけです。

http://microsoftpdc.com/Sessions/FT12

 

USのPPTを見ると以下のような感じです。

(高橋メソッドかのような潔さ!)これをどうしろと・・・と正直その時は思いました(笑)

image

これも含めた(これまで集めた)素材から、自分のメッセージを見つける必要があります。

 

色々と眺めているうちに、僕が気が付いたのは、小粒なデモが大量に可能であることでした。それも同じ切り口の物です。

それは何故か?もちろん、単に似たようなものを沢山作ることができるということもあるでしょう。
しかし、僕が考えたのは、、、「多様性があるから」です。

そして、それこそが(自分なりの)キーメッセージだと思うことにしました。

 

つまり、このセッションは、「WCF Data Services の新機能と  Open Data Protocol」を、多様性という切り口で紹介すればよい。これが一段抽象度を下げた目的になります。

 

これが明確になればしめたのものです。あとは芋づる式に決めることができるでしょう。

 

もう一度書きますが、このキーメッセージを見つけることが、僕のプレゼンでは一番大切なよりどころです。

 

■残りのファクターは勝手に決まるよね

本当にあとは残りです、「誰に」と言う対象と、「どうやって」と言う手段です。

キーメッセージが決まった以上、これらは簡単に決められるでしょう。

 

「誰に」:もちろん、開発者ですが、多様性を示すと言う事は、もう少し上流の方向けにした方が、より浸透すると思われます。

「どうやって」:多様性を示すのですから、とにかく同じ切り口の色々なデモや話をするべきです。そして、そこにほとんどの時間を充てるべきで、あまり他に時間をかけない方がよさそうです。

 

そうすると、自然にスライドの順番や修正方法、どのようなデモを行うべきかが見えてきます。

そうですね、本来ここからが本当のプレゼンの資料作成とデモ作成なんですよね。

 

こうして、本番プレゼンの精度をドンドンあげていきます。

もちろん、イテレーションサイクルは回したままですので、新しい情報があれば、本番に結合してもよいでしょう。

 

イメージ的には以下のような感じです。

 KeyMessage

 

実は、この時点で初めて、本来のセッションタイトルと概要、ターゲットオーディエンスが確定します。しかし、集客の関係で、もっと以前に充てで提出してしまっていますので、そことのバランスをとる必要が出ます。

 

前回書いたように、大きいところを決めて、そこから落とし込んでいくのではなく、細かいところの作業をしていくうちに、より上位のレイヤーをねん出するイメージで、そして、大きなところを明確にすることにより、細かいところをよりハッキリとさせるのが、自分の手法ということになります。

 

改めて見ると確かに偏ってますね。僕は典型的な「やってみなければわからない」タイプなんでしょうね。想像力がないというか。

 

■参考までに

僕が行ったイベントのキーメッセージを幾つか書いておきます。

「ADO.NET EntityFrameworkのアーキテクチャとストラテジ」

このセッションでは「再認識」がメッセージでした。Level400セッションでしたので、みなさんが持っている知識の中に、EFはマップしますよ!ということを訴えたかった。

 

「Silverlight4データ駆動アプリケーション開発」

この時は「普通のことが普通にできる」にしました。逆にSilverlight4のカッコいいところは見せるつもりはなかったです。

 

「データアクセスは次の時代へ LINQを活用した効率的アプリケーション開発術」

これは「コーディングの楽しさ」を前面に訴えたかったので、楽しくテンポよくを心がけましたね。

 

「あなたの身近な Office 開発」

珍しくキーメッセージがタイトルに入っているパターンです。

とにかく「身近」であることを紹介したかったのですね。Officeドキュメントを用いた開発って以前からよく行われており、今でも需要があるはずです。それが(良し悪しは別にして)Office開発と言えばSharePoint Server開発と言ったメッセージが多すぎだったのが、個人的には不満だったからです。

 

次回はどうしようかな・・・スライドを作るときのポイント(と言う名前の好き嫌い)を書こうかなと思い始めています。

テーマ : なんとなく書きたいこと。。
ジャンル : 日記

tag : 自分メモ プレゼンテーション

2010-05-16 : 自分メモ : コメント : 0 : トラックバック : 0
Pagetop
ホーム  次のページ »

カレンダー

プルダウン 降順 昇順 年別

07月 | 2017年08月 | 09月
- - 1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31 - -


カテゴリ

openclose

タグクラウドとサーチ

メールフォーム

名前:
メール:
件名:
本文:

プロフィール

こだかたろう

元MSの小高と申します。
(↓こんな人です。)
こんな見た目です

ずっとエバンジェリストをしていましたが、この度転身いたしました。
よろしくどうぞ。

Select Template

RSSリンクの表示

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。