今日のプレゼンテーション

今日は Java Hot Topics Seminar。鈴木さんの JBI/OpenESB と、さぼてんくんの Hudson です。

OpenESB はあまり興味がないので (すいません、鈴木さん)、目当ては Hudson。さぼてんくんはヴァーチャルでは java-ja 関連でつながりがあるのですが、リアルに会うのははじめて。

でも、2 人ともプレゼンに慣れていないせいか、構成がイマイチだと思ったわけです。

どうすればいいかをちょっと考えてみました。

いちおういっておきますが、彼らを責めているわけではなくて、あくまでもプレゼンの技術論として書きます。

プレゼンって技術なんです。だから、技術を極めれば上手なプレゼンが誰でも絶対できるはずです。

プレゼンの技術には、プレゼンをするときの姿勢や動作などから、プレゼンの構成、資料の作りかたなど多岐に渡りますが、今日は特に構成について書きます。

何か新しいことを知るときには、抽象的なところからだんだんと具体的(具象的)なことを説明することが理解を早めると思いませんか。マクロ的な視点からミクロな視点といってもいいかもしれません。

ここでいう抽象的とか具体的といっているのは次のような項目にあたります。

抽象	一言でいうとそれが何なのか 背景、経緯 ユーザに対するメリット 既存に対する差別化要因 同様なものに対する位置づけ et al.
中間	全体の構成 動作原理 アーキテクチャ et al.
具象	使い方 書き方 コード例 応用例

もちろん、これだけではないのですが、だいたいどういうことなのかは分かっていただけるはずです。

プレゼンテーションではこの抽象から具象のバランスが非常に重要だということです。

特に抽象的な話題は重要です。ここが理解できるかどうかで理解度がずいぶん違うはず。

とはいっても、単に抽象と中間と具象で時間を 3 分割すればいいというわけではありません。ターゲットによって配分を変える必要があります。

たとえば...

• 技術の導入を決めるだけで、実際にコードを書くわけではない人に対しては、抽象的な話題を多くし、残りは中間的な話題、具象はほとんどいらない。
• 実際にコードを書く開発者であっても、そのものをほとんど知らない人であれば、中間的な話題を多くし、抽象と具象は少なめ。
• だいたいどういうものかは分かっている人であれば、具象をほとんどにする。

ターゲットがマネージャー層なのか、開発者層なのかは、セミナーなりイベントなりの趣旨でだいたい分かります。難しいのはそのものを知っている人が多いのか、少ないのかということです。

これはその場にいかないと分からないことが多々。

しかたないので、資料は抽象を少し、中間の話題と具象の話題を半々にしておいて、実際に説明する時間を調整するようにします。

実をいうと、活字媒体とプレゼンテーションではこのバランスは大きく変ります。ぶっちゃけ、活字媒体では具象的な話題が多いはずです。

抽象から具象まで十分に説明すると、実際には具象的な話題が一番多くなります。

活字媒体ではある程度分量があるので、より多く具象を説明できるのです。

その一方、プレゼンテーションでは時間が限られているので、なかなか具象の細かいところまで説明する時間がないはずです。しかも、プレゼンテーションでは、たとえばサンプルコードを提示されたとしても、読みにくかったりして、なかなか細かいところまで理解するのは難しいのです。

ところが、ところが、話す側からすると具象が一番準備がしやすいのです。普段、使っているときはあまり抽象的なことを考えないですからね。そして、ここに一種のミスマッチが発生してしまうわけです。

ターゲットに適合しない抽象から具象のバランスだと、結局分かってもらえません。

具象ばかりで中間や具象がないと、なんとなく分かったけど、結局なんだか分からないという結果になります。

逆に具象ばかりだと、全然分からないとなりがち。

今回のセミナでは 2 人とも抽象と具象しかなくて、中間的なところがほとんどありませんでした。抽象からいきなり具象に入ってしまうと、途中からついて来られなくなってしまいがち。

一般的に、抽象なればなるほど、図の重要性は上がります。抽象的な話題であれば、なるべく図を多くしたほうが、理解を早めます。また抽象的な時には、メタファを使うことも有効ですね。

難しいのはデモの位置づけです。デモというと、具象のような感じがしますが、そんなことはありません。抽象的なデモも可能だし、具象的なデモも可能です。

ターゲットに対して有効なデモが何なのかを考えるのはとても重要です。

少なくとも、デモで何を提示したいのかをはっきりさせなくてはダメです。

 

たとえば、今回のセミナで考えてみましょう。このセミナのターゲットは開発者。でも、ESB や JBI、そして Hudson に関して知っている人はほとんどいません。

だとすると具象は少なめにし、抽象的な話題をやや多めにするのがいいと思います。

たとえば、OpenESB で考えてみます。いちおう、いっておきますけど鈴木さんを非難しているのではなくて、私だったらこうするという例です。

重要なのは ESB という概念を理解できるかどうかだと思います。

そのために、今までの背景として、今までの直接メソッドコール、インタフェースを会したメソッドコール、JMS などのメッセージングと依存度が減少していく流れを説明します。

とはいうものの、メッセージングにはいろいろと欠点があるはずです。だからこそ、ESB が出てきたわけですから。

ここで、メッセージングの欠点がどのように ESB で克服されているのかの説明は欠かせません。これは ESB にすることでどのようなメリットがあるかを十分に説明できませんから。

問題の共有をスピーカと参加者で、できるかどうかということはとても重要です。「そうなんだよね、ここが問題なんだよね」と共感してくれれば、後はスピーカの思うつぼというか、とてもやりやすくなるはずです。

でも、その問題だけ提示して、それに対する解決がなされていなければ、「結局、その問題はどうなったの?」と聞いている人を惑わしてしまうだけです。

ここは十分に時間をとって丁寧に説明するべきです。

そして、ESB を実現するものとして JBI/OpenESB を紹介します。ここからが中間的な話題ですね。

重要なのは OpenESB でどのように ESB を構築しているのかということだと思うんです。そして、他の ESB、たとえば SCA との差別化要因などを説明します。

ここまでちゃんと説明できれば、あまり具象的な話題はいらないと思います。

デモをするとしたら、すでにサービスがいくつか存在していて、それを ESB で結びつけるデモを櫻庭だったらやると思います。サービスから作ると、どうしてもサービスの粒度が低くなってしまい、ESB の概念からすると外れたものになってしまうような気がします。また、サービスを作る手順がどうしても煩雑になってしまい、見せたいところが十分に示せなくなってしまうと思うのです。

プレゼンテーションの構成以外にもいろいろと考えなくてはいけないことはありますが、長くなったので、その他はまた別の機会に。