知っていることを全部話したくなる症候群

何年も前のことだけれど「お客さんが、製品の話を聞きたいと言っているから、同席してくれ」と営業に言われたことがある。顧客の興味の範囲は大きくて、自社と他社のセンサから取得したデータをブラウザで閲覧できる、とかそんなのだったはずだ。普段なら要件を絞ってからにしてくれ、と言うところだけど、上得意だったのと、顧客が大雑把にしか考えてないっぽかったので、調べてから対応することにした。

さて、顧客と話してみると、準備した知識や情報のごく一部でできそうだったので、必要十分な情報と方法、質問への回答をした。打ち合わせ後「あれだけ時間をかけて準備してたのに、よくぞ喋らずにいられたな」と営業に言われた。

という話を思い出した。これだけだらだら書いておいてナニだけれど、必要以上に（あるいは不必要な）情報を提供する人はなんなんだろうと、ふと思ったのだ。ついさっき。

時間や労力をかけたとき、工夫をしたとき、話したくなる気持ちはすごく分かる。準備の課程で発見や発明があったらなおさらだ。私も冒頭で2段落も使って書いているわけだ。で、棚に上げるけど、「相手が知りたいこと、知るべきことなのか」には気をつけるようにしている。

外食に行って「今朝入荷した、新鮮な明石の真鯛を〇〇したカルパッチョです」くらいなら、ほほーって気分になる。けど、その真鯛を手に入れるためにどんな人脈をつかったか、〇〇するためにどれだけ苦労したか、今日はバイトが休んだから仕込みが大変だった、みたいな話をされるとげんなりするだろう。きいてねーし、付加価値ゼロだし、知りたかったらこっちが聞くし、って思う。

と思いながら、聞いていることがある。全部話したいのは分かる。だって知ってるんだし、知らないと思われたくないし。けど、汝は5分しか話してはならぬ、みたいな状況でもない限り、相手の質問に答えればいい。それよりも、相手にとって不要な情報を話すことによって「そんなこと関係ないだろ、こいつ分かってないだろ」と認識される方が、やっかいな気がする。話を真面目に聞いてもらえなくなりそうだからだ。

そんなわけで、よっぽどかこの文章を消そうと思ったんだけど、がんばって書いたので公開する。

※ 一応追記しておくと、その作業がどれだけ大変だったか、を伝える必要があるとき/伝えることに価値があるときは、なんとしてでも伝えるほうがよい。

プレゼンとマジック - 森博嗣「タカイ×タカイ」

森博嗣の X シリーズ 3 作目「タカイ×タカイ」の文庫が出ていたので、読んだ。

マジックって、たしかに、観客に何かが起こっていると見せかけるけれど、それって、実際に起こっていることを隠すためのものですよね。

真鍋瞬市が、高いポールの上に死体があったことに対して、死体を見せたいからではなくて、別のことから目を逸らしたいからでは、と、疑問を投げるセリフだ。実際がどうたったかは、読んでのお楽しみ。



ここから我田引水。プレゼンをするときにも、この手法は使えるだろう仮説。少なくとも私は今まで使ってきたし、これからも使うと思う。

場合によるけれ聴衆に何かアクションを起こして欲しいとき、何か変化を起こさせたいとき、伝える側がフォーカスして欲しいことに、聞き手にフォーカスさせたいことがある。そんなとき、嘘じゃないけど、注意の引き方を工夫する。

たとえば新製品や新サービスを発表をするとき。当然だけど、競合できて、自社製品にできないことや劣っていることがある。おそらくそれは戦略上、優先順位が低いから落とした機能だろう。けど、状況によっては（メディアや顧客は大事だと思い込んでいるかも知れないけど、こちらは重要ではないと思っているとか）、めんどくさい形で突っ込まれるかも知れない。そんなときには、100項目もある新機能ぜんぶではなくて、ポイントになる数機能にフォーカスさせるようなストーリィの組み立て方をする。うまくいっているのか、うまくいってないのか分からない。

ところで、そうやって推理小説にうまく騙されたときは気持ちいい。

Presentation Zen: The Video

Presentation Zen のビデオが出ました。ブログや本に書かれている内容とかなり重複しているので、特に新しい知見があるわけではないです。

YouTube: Presentation Zen: The Video

ですが、このプレゼンがうまいです。いやまあ、こんなかっこいい状態でプレゼンする機会なんて、私にはないのですが、それにしてもうまいです。あと、トピックが後ろにぽわーんと出てきて、ぽわーんと消えていくエフェクトもかっこいいです。

夏頃にちょっと気合いの入ったプレゼンをする機会がありそうなので、参考にしてみます。

俺の話を聞け - プレゼンを聞いてもらうには

Python Code Reading も 10 回目があるようで、わくわくです。前回の 08 で、私にとって最大の難関は、勉強会とは言えども、非職業プログラマがプログラマ相手にプログラミング言語の話をする、という状況をどう克服するか、でした。実績が明確な人や有名な人であれば、こんなこと気にしなくてよいです。プログラマではなくても Tim O'Reilly だったりね。

そんなわけで、自己紹介の段階でなんとしてでも、話くらいは聞いてやってもいいか、という内容を入れておかねばと思ったわけです。内容に異論や批判はあってもよいのです。めげますけど。けど聞いてもらえないと議論のテーブルにもあげてもらえません。わざわざ平日の夜に集まってもらったのに、ぼーっとしてただけ、というのは申し訳なさすぎます。せめて「聞いてたけど、それは違うんじゃあ」と思ってもらいたい。というわけで、２つの内容を自己紹介に入れておきました。

ひとつめは Python 1.x → 2.x への移行らしきものを見たことがある、ということです。オライリーの Python 本を読んだとき、1.x と 2.x の違いについても触れられていましたし、大学のサーバにも 1.6 と 2.1 の両方が入っていましたし、Python 2.x 非対応のライブラリなんかに遭遇してソースをいじったこともあります。日本で Python が流行りだしたのはもっと後の時期だったので、時期（時間ではない）という点だけを見ると、ちと話を聞いてもらえそうな気がしました。実際、1.x から 2.x への移行は初心者の私にも大した問題ではなかったです。

もうひとつは「ソフトウェアの機能ではなく、ユーザのベネフィットを伝える」という仕事をしている（ことがある）、ということです。Python 3.0 の新機能リストや変更点は python.org あたりにいけばすぐに分かりますし、個々の新機能の使いどころは PEP や雑誌にも載っていました。で、じゃあ、ユーザにとって総合的に何が嬉しいのか？というは意外となかったりするわけです。一方、仕事ではそれを伝えることを求められるのですね。伝えられているかは別にして。で、それを Python でやってみました、という話です。

という前振りのあとで、「Python 3.0 のベネフィットは読みやすさと書きやすさ」である、という乱暴なテーマで話したわけでした。ちゃんちゃん。

教育目的のプレゼンテーション

相手に何かしてもらうことを目的にしたプレゼンテーションの解説というのはたくさんあります。実際、そういう場合にこそ、プレゼンテーションが必要になることが多いわけですし。ですので、あなたがプレゼンテーションなのだ、とか、心に響かせないと、みたいな話になります。

それとは別に、教育目的のプレゼンテーションがあります。知ってもらうこと自体が重要な場合です。実際、そういう状況においてプレゼンテーションという形式がよいのか分かりませんが、まあ、そういう機会があります。Python Code Reading なんか、そういう例です。別に、私は Python 2.x から 3.0 に乗り換えて欲しいと思っているわけではないのです。

で、そういうときって、話が細かくなりがちで、かつ、細かい話が本質的に重要だったりします。なので、スライドの作り方や、話し方や、スタイルなんかも、一般的なプレゼンテーションとは異なるアプローチが必要なんではないかと、最近思い始めています。

とは言え、プレゼンテーションが始まった段階では「オレの話を聞け」という目的があるので、最初の方は一般的なプレゼンテーションのノウハウが適用できると考えています。