FC2ブログ
まだ生きているようです

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
-------- : スポンサー広告 :
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
コメントの投稿
非公開コメント

Pagetop
« next  ホーム  prev »

カレンダー

プルダウン 降順 昇順 年別

09月 | 2018年10月 | 11月
- 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ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。