hitode909の日記

以前はプログラミング日記でしたが、今は子育て日記です

プレゼンテーション

プレゼン自分ではすべったことないから得意だと思ってるのでいつも気をつけてることをシェアします。これさえ守ればすべらないのだから楽。

目次

最初にめちゃくちゃおもしろい話をする

聴衆は懇親会のことしか考えてないので、とりあえず最初におもしろい話をして、注意を引きつけるとよい。つかみはこれでオッケーだって言えればよいくらいの面白い話をしましょう。よくある技術ブログとか、技術雑誌だと、こんにちは、最近温泉に行って心身共にリフレッシュしました、ヒトデです、とか書いてあるけど、そんなの読んで喜ぶ人が本人と家族と親類以外にこの世にいたらおかしいから、そういうのじゃないとよい。

箇条書きせず一行ずつページを分ける

箇条書きはださいからやめろという人はよくいるけど、どうするべきかまでは述べていない。一行につき一枚スライドを割り当てる。そうすると、迫力が出る。こうなったときに、話すことなかったら、おかしいので構成を見直すチャンス。アジェンダとか目次とか言って先に箇条書き出す人いるけど、そうすると、最後の章まで寝てていいことになる。全ての章がすばらしいから前に出てしゃべってるはずなので、目次は隠した方がいい。アジェンダだけ見て知ってる内容なら帰って行く人の時間を無駄にするかもしれないから先にアジェンダを発表するとかして気にする必要はなくて、死ぬほどおもしろい話をすればよい。

絵をでかくする

スライドの端で絵が切れてるとださいので、限界まででかくする。そうすると迫力が出る。そこで気後れしたら本来は要らない絵に違いない。プレゼンテーションZEN読むと丸々一冊かけて絵をでかくしろって教えてくれる。絵と背景のつなぎ目がみえるとださいので、だいたいの絵が白背景なら、スライドも白背景にするとつながってよい、というはなしもある。

プレゼンテーションZEN 第2版

プレゼンテーションZEN 第2版

新しいページ作ったらデフォルトのパーツを全部消す

新しいページ作ると、箇条書きテンプレートが出て、いらっしゃいませっていう感じでおもてなししてくれる。おもてなしに従うと死ぬほどださくなるので、おもてなし全部消して毎回手作業で組み立てる。マスタースライドを白紙にすると効率いいけど、そうなると、俺はこのようなテンプレートは無視するという気持ちを忘れがちになるので、僕は毎回箇条書きが出るようにしてる。

先に言う

プレゼンテーション聞いてる人はあなたの話を聞きたいのだから、スライドより先に話すべき。スライド変わったときに聴衆と同時に見てるようなら、聴衆だけで勉強会でもするほうがまし。話したいことがあって、スライドが後からついてくると、人間が主体的になれる。スライド見てから話すとスライドに合わせてしゃべってるだけ。

意見や疑問を述べる

事実だけ述べるならWikipediaで済む。こういうことをしたところ、こう思ったとか、こうじゃないですか、みたいな、自分のセクションを設けないと、聴衆の代わりに調べてあげただけで終わってしまう。発表者が聴衆からフィードバックを得てお互いに高められる発表をしないと、発表するモチベーションを得られないと思う。

スターウォーズエピソード4を見る

スターウォーズエピソード4、作戦を説明するときに、3Dアニメーションで作戦の全容が語られる。ここでPowerPointで箇条書きの説明してたら映画として成り立たない。デススター突入も会社員の今日の仕事みたいになる。仕事終わりに発泡酒飲むことになる。プレゼンテーション資料は話の背景の資料でないといけない。話すのが主で、話を補完したり、根拠を示すのに使われないといけない。スライド流すだけで、あとは当日スライドに合わせて話すだけで済む、というようでは、聴衆も当日は家でゴロゴロして後日SpeakerDeckで見るのと変わらない。後日スライド見たら意味不明というのが理想的。
このエントリいいこと書いてある。
遠い昔、パワポ死がなかった頃


これくらい気をつけたらいい感じになると思う。スライドの色とかフォントなどは小手先の問題であって、話が面白くないといけないと思う。Twitter Bootstrapを使えば良いUIができるということはなくて、使う人のことを考えたおもてなしをしないと、妙にツヤツヤしたボタンの使いにくいウェブサービスができる。


追記。おもしろい話というのは受けを狙って変な話をするということではなくて、興味深い話をするということで、アニメの絵とか貼ればよいというものではない。

https://twitter.com/AntiBayesian/status/454978456078409728


どうやったらおもしろい話できるのかという問題があるけど、わざわざ発表するに足りる内容かどうか考えるとよいと思う。調べてまとめただけくらいなら、発表する価値なくて、自分で何かやってこういうことが分かったとか、こういうものを作ったとか、そういう話なら知ってる人いないのでおもしろい話ができると思う。

■

夢日記

夢、なんか東北の祭りみたいなのを見てる。山車みたいなのが順番にやってくる。自動販売機でオレンジジュース買ったらカップ酒が出てきた。
夢、ヤマハかなんかの楽器屋に居て、楽譜を見てる。電子ギターとか電子ベースとか置いてある。10万円の電子ピアノ、ボタンがごちゃごちゃついてて、タモリっていうボタンもある。タモリは、笑っていいともオープニングテーマを弾く専用の音色で、うまく弾くとタモリの歌声が流れる。
夢、母が車を運転してて、山道を曲がろうとして、前の車にぶつけてしまう。その人の家に詫びに行くことになって、行ったらお墓についてのクイズが始まって、正解したらルームシューズもらえる。祖母も出現して、こんなにルームシューズは要らんって言う。気に入らないなら自分で買いに行けばいいじゃんって言う。
夢、好きなガンダムはなんとかですかっていう話で、黒とオレンジの地味なガンダムで、それは高さが900メートルくらいある。そういうガンダムのアニメが始まるので見る。壁の内側で爆発して、しまったとか言って終わり。

二日酔いでずっと寝てたら変な夢見続けて得だった。

■

suzuriで注文したiPhoneケースが届いた．1週間くらいで届いた．印刷がめっちゃきれい．こんなにきれいな必要ないと思う．インターネットで何かすると実際に物が届くのはおもしろい．

ここから買えるのでみんな買ったほうがいいと思う．→ kentaroの微笑みあんちぽiPhoneケース ∞ SUZURI

 

http://instagram.com/p/mot9S9xGrb/

【朗報】あんちぽiPhoneケース届いた

設定のクラスを作るとすっきりしそう

設定のテストを書くとよいって言ってる人がいた．

テストされてるのはよいと思う．名前のついてないデータ構造をがんばってテストするよりは，設定のクラスを作るとすっきりしそうと思った．
こういう構造のHash，として見るよりかは，設定クラスのインスタンスとして見るほうがイメージしやすい．


個々のブログの設定のURLはユニークであるというのを，どこかのクラスの責任にする．BlogConfigRepositoryというクラスのインスタンスが，設定の集合を持ってるとか．

like exception {
    BlogConfigRepository->new([
        {
            "url" : "http://blog.example.com/",
            "permission" : "public",
            "members" : [ "example-user" ],
        },
        {
            "url" : "http://blog.example.com/",
            "permission" : "public",
            "members" : [ "example-user" ],
        },
    ]);
}, qw/url duplicated/;

クラス作っておくと，データと対応した操作も作れるので，指定したURLの設定を取ってくるメソッドなども作れる．$config->{$url}とか書くより，find($url)って書けるほうが読みやすい．

my $repository = BlogConfigRepository->new([
    {
        "url" : "http://blog1.example.com/",
        "permission" : "public",
        "members" : [ "example-user" ],
    },
    {
        "url" : "http://blog2.example.com/",
        "permission" : "public",
        "members" : [ "example-user" ],
    },
]);

isa_ok $repository->find("http://blog1.example.com/"), 'BlogConfig';
is $repository->find("http://blog1.example.com/")->url, 'http://blog1.example.com/';
ok ! $repository->find("http://undefined.example.com/");

設定1個のクラスも作っておくと，個々の設定のバリデーションさせることができる．

like exception {
    BlogConfig->new({ permission => 'public', members => ['example-user']});
}, qw/url required/;

like exception {
    BlogConfig->new({ url => 'http://blog.example.com/]', members => ['example-user']});
}, qw/permission required/;

like exception {
    BlogConfig->new({ url => 'http://blog.example.com/]', permission => 'public'});
}, qw/members required/;

like exception {
    BlogConfig->new({ url => 'http://blog.example.com/]', permission => 'undefined', members => ['example-user']});
}, qw/invalid permission/;


BlogConfigはハードコードされたHashを読み込むだけじゃなくて，アプリケーション内で動的に作るかもしれないので，permissionはこれかこれに限るとか，インスタンス作る前に，妥当なpermissionか知る手段があると便利そう．

cmp_deeply BlogConfig->valid_permissions, ['public', 'private'];
ok BlogConfig->is_valid_permission('public');
ok BlogConfig->is_valid_permission('private');
ok ! BlogConfig->is_valid_permission('invalid);


個々の設定を表すクラスに，publicかどうかとか，この人は編集できますかとか，アプリケーション的に必要になりそうなロジックを置ける．

my $blog_config = BlogConfig->new({
    "url" : "http://blog.example.com/",
    "permission" : "public",
    "members" : [ "example-user" ],
});

is $blog_config->url, "http://blog.example.com/", 'BlogConfigはurlを持つ';
ok $blog_config->is_public, 'publicである';
ok ! $blog_config->is_private, 'privateではない';
cmp_deeply $blog_config->members, ['example-user'], 'メンバーを取得できる';
ok $blog_config->can_be_edited_by('example-user'), 'メンバーは編集できる';
ok ! $blog_config->can_be_edited_by('another-user'), 'メンバーは編集できる';


こんな感じにすると設定のデータの仕様とその操作が一体化して便利だと思った．
コードの例は架空のブログの設定であり，実在するブログの設定とは関係ありません．


書き忘れてたので追記．便利とかすっきりする以上のメリットもあって，設定に対応するクラスを作ることで，データの整合性についての知識が，上のエントリではテストだけに書かれていたのが，このエントリのコードではアプリケーション本体のドメインに移ったのがよい．ドメイン層のロジックが充実するのは一般的にめでたいこととされている．外から釘を打ちつけて固定してたところに柱が入ったような安定感がある．

■

汎用的な物を設計するのは難しい，特定の用途に特化した物のほうが簡単．
日付クラスを汎用的に作ろうとすると，世界各国のタイムゾーンとか，サマータイムとか，うるう秒とか，そういうのを作ることになる．そういうクラスは日付を正しくモデリングしているけど，サマータイムで存在しない時刻作ると例外出たりして，扱いにくくなったりする．アプリケーションによっては，そこまで精密な機能は要らないかもしれない．たとえば，日記書いた時刻を表示したいだけなら，数字を何個か持つだけのクラスで済むかもしれない．それくらいのほうが，日記を高速に配信できて便利かもしれない．
このクラスは汎用的であるとか，汎用的でないとか，一概に述べることもできなくて，解決したい課題と比べて，スコープ外にあるとか，単純すぎるとか，そういう関係で決まると思う．クラスの責任を明確にしておくことで，なんだこのクラス，全然使えないじゃん，みたいな批判を避けることができる．どのクラスも，解決したい課題と解法を持っているけど，それが正しく利用者に伝わらないときに悲しいことになる．