まだ生きているようです

スポンサーサイト

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

MSDNブログが変わってしまいました

以前書いていたブログなんですけど、、、
MSを退職する直前に、ブログが変わるかもしれないと聞いていたのですが、
今日見たら変わっていてビックリです。

http://blogs.msdn.com/b/tarok/

レイアウトの変更もしたいのですが、もう手を出してはいけないようなので、埋もれてしまったページのリンクをこのブログに張ろうかなと思っています。

古い記事は良いと思うのですが、WindowsMobile用のフリーソフト2本のページと、WCF Data Servicesの新機能の連載辺りは、PageViewも比較的よいので意味があるかなと。

まぁでも、消えてしまわないでよかったです。
バッサリ行く事も覚悟していましたので。

スポンサーサイト

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

tag : お知らせ

2010-05-26 : お知らせ : コメント : 2 : トラックバック : 0
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

CodeZine 連載 第5回 Silverlightで実装するデータ処理の応用

CodeZine連載5回目が公開されました。
今回が最終回と言うことになります。最後ですので多少応用的な内容になっています。

http://codezine.jp/article/detail/5145
http://codezine.jp/article/detail/5145

データの入力検証、データの追加、ストアドプロシージャの実行あたりの話をしています。
実際のところ、ストアドプロシージャに関しては、スカラ値での戻り値のRetuenが上手く行かない為、使いどころを選ぶ傾向にある事は確かです。(EF4でも治っていなかったですね。)
エンティティの形で戻す場合は問題なかったハズです。

本来的な意味で言えば、ドメインモデルのみを意識して開発できる点がEFの売りでもありますので、ERモデルを意識しなければならないストアドプロシージャの使用はやめておきたいところです。

とはいいつつも現実的にはあるからしょうがない。と言った形で現場での意向のようなものを想像しています。

================

これで、MSの冠が付いたタスクは本当に終了です。
思えば長いようで短かったですねー
そして、僕に真の実力が付き、言葉に魂が入れられるようになったら、自信を持って復活Gigをしたいと思っています。

ちなみに転職先では、現状、全く使えないダメな子になっておりますので、早く自分の理想に近づけるように頑張りたいと思います。(先は長いですが。)
とにかく目の前の一歩一歩を着実にすすむしかありませんよね。


2010-05-21 : お知らせ : コメント : 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
ホーム  次のページ »

カレンダー

プルダウン 降順 昇順 年別

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