Life is beautiful

「偶然ですよ、偶然。たまたま（今、何をやるべきか）分かっている人たちがそこにいただけ。」

　水曜日の夜にひろゆき氏と対談したのだが、ニコニコ動画の成功に関して私が質問したときの彼の答えがこれ。

１０行の
　エントリーなのに
　　あとで読む
by 和蓮和尚

　プレゼンの初心者にありがちな失敗は、

・自分の未熟なプレゼンのテクニックを気にしすぎてあがってしまう
・情報は多い方が良いと勘違いして、スライドをたくさんの文字で埋め尽くしてしまう
・その結果、観客に話しかけるのではなく、観客に背中を見せてスライドを読んでしまう
・結局何が言いたいのか全く伝わって来ない

など。今日はそんな人に覚えてほしい三つのポイント。

１. 観客は「未熟なプレゼン」には寛大だが、「何を伝えたいのか分からないプレゼン」には厳しい

　「自分はプレゼンが不得意」と思い込んでいる（もしくは悩んでいる）人はたくさんいると思うが、そんな人がまず覚えておくべきことは、観客が「未熟なプレゼン」にはけっこう寛大であること。小中学生ならいざしらず、社会に出てから「プレゼンターの未熟さ」笑う人はまずいないので、心配しなくても良い。逆に、観客が許してくれないのは「何を伝えたいのかが分からないプレゼン」。ここだけは、絶対にはずしてはならない。

２. 「自分が伝いたいポイント」を意識して、それを伝えることにだけ注力する

　それを防止するためには、プレゼンの準備をする前に、まずは「自分が伝えたいポイント（できれば１つ、多くても３つ）」をはっきりと決め、「絶対にそのポイントだけは伝える」ようにスライドを作ること。基本としては、

・冒頭のスライド一枚にそのポイントをまとめておき、「これが今日私が伝えたいことです」と宣言する
・そして、その伝えたいポイントを何枚かのスライドを使って丁寧に説明する
・最後に、「今日、私が言いたかったポイントはこれです」とまとめのスライドで繰り返す

　この形を意識すれば、プレゼンの仕方が多少下手でも、少なくとも何が伝えたいのかだけは分かってもらえる。

3. スライドの文字は極力少なくし、観客の注意は自分の方に引きつける

　スライドの文字の大きさとして適切なのは３０ポイント。行数でいえば６〜７行が限度だ。それ以上の文字を詰め込むことは大きな間違い。たくさんのデータに基づいたプレゼンの場合でも、スライドに書くのは大まかなデータだけにしておき、細かな表とかは、別途紙に印刷したものを渡すこと。スライドには、文章ではなくキーワードや図だけ置いておき、それを自分の言葉にして、観客の方を見てしゃべる。

　◇　◇　◇

　ものすごくあたり前のことを書いただけだが、実際には多くのプレゼンが「文字だらけのスライドを読むだけで、結局何が言いたいのか全く伝わってこない」というのが現状。スライドを読むだけで良いのならば、プレゼンなどしないでメールでスライドを送ってくればお互いに時間が節約できる。「なぜ互いに貴重な時間を使ってプレゼンをするのか」を良く考えて、上の三つのポイントを意識してプレゼンをすれば誰でも「そこそこのプレゼン」はできる。

【追記】最後におまけだが、悪いプレゼンをネタにしたコメディ（一人漫才）の紹介。

　University Washington での Executive MBA プログラムの集中授業が始まった。予想通り、授業は基本的に講義ではなく、ディスカッション形式。予習を十分にしていかなければ、発言できないどころか、他の人が何を話しているのか分からず、全くついて行けない。

　最初の「Teamwork & Managerial Effectiveness」はまだたいしたことはなかったが、午後の「General Management & Strategy」は、まさに「消防車のホースに口を付けて水を飲む」という表現がぴったりの授業。常に脳みそを全開状態にしておかないと話についていけないし、次々に質問を投げかけられるので、まったく気を緩められない。

　会議にしろ授業にしろ、出席するのであれば最大限に参加しなければ損というポリシーの私にはピッタリのスタイル。アドレナリンを上げっぱなしの３時間というのは、なかなかできない体験。

　授業の最後の方に、「企業が持つことのできる最も価値の高い差別化要因は、パテントとか商品・サービスそのものではなくて、そういったものを組織だって作り出す能力そのものにある」という話に及んだ時に、私がポケットからiPhoneを取り出して、「アップルがこんなにすばらしいものを作れるのは、本当に組織の力か？ジョブズがいるからこそ作れるんじゃないのか」という質問をしてしばし討論に。

　最終的には、「ジョブズが本当に偉大なCEOであれば、（ジャック・ウェルチのように）彼がいなくなっても引き続きすばらしいデバイスを作り続けることができる組織を作ってから引退するはず」という結論で決着。まさに期待していた通りの刺激的な授業であった。

　仕入れたばかりのジョークを一つ。ちょっとブラック・ジョークなので、要注意。

　...

　事故でぐしゃぐしゃに潰れたBMWから、血まみれの男が出てくる。

　通行人が心配して駆け寄ると、

　「俺のBMWが...。俺のBMWが...。買ったばかりの新車なのに！」

と嘆いている。

　駆け寄った女の人が、

　「それどころじゃないわよ。道のあっち側を見なさいよ。あれ、あなたの左手じゃないの！」

と指をさす。

　さされた指の先を見た男が言う。

　「俺のローレックスが...。俺のローレックスが...。」

　昨日の「日本語の進化について、一つの実験をしてみる」というエントリー。皆さんからたくさんのフィードバックをいただいた（現時点でコメント７０個、はてなブックマーク６７個）。ご協力に感謝、感謝である。ブログがリアルタイムで双方向なコミュニケーションツールであるからこそ可能なこんな遊び。ネットがある時代に生きていてつくづく良かったと思う。

　そこで本題だが、私が一番知りたかったのは「そこのコンビニでおでんが売っている」という、私ぐらいの世代の人にとっては「違和感」どころか「明らかな文法的な誤り」を含んだ文が若い人たちの間ではすでに市民権を持っているのか（何の違和感も持たずに受け入れられるものになっているのか）、という点であった。

　しかし単にそれだけを書いて「この文は文法的におかしいと思いますか？」と尋ねたところで有効なデータは集まりそうにない。そこで、他の５つの例文を追加し、それぞれに小さなツッコミどころを用意しておき、皆さんがどこに一番反応してくるかを調べたしだいである（だから「調査」ではなく「実験」。ただし、本文の方の「違和感を感じる」というツッコミどころは本物のミス^^;）。

　よせられたコメントを読む限り、かなりの人がこの「文法的な誤り（『おでんが売られている』もしくは『おでんを売っている』が正しい）」に気がついたようだが、全く疑問すら抱かなかった人もたくさんいることが確認できた。先のエントリーにも書いたように、言葉は生きていて日々変化している。多くの人が誤用に気がつかずに使い、それがなんの違和感もなく人々に受け入れられるようになったとき、それは市民権を得て「正しい日本語」になってしまうのだ。

　だからといって、この「そこのコンビニでおでんが売っている」という言葉がこのまま日本語として定着するとは限らないが、少なくともすでに一方的に「間違っている」と決めつけられる段階は突破してしまっているように思える。

　そもそも「主語が省略されている文」どころか「主語がない文」が許されている日本語において、「おでんが売られている」状態を、まどろっこしくて言いにくい「売られている」という受け身でしか表現できない状況が進化圧となって、本来なら文法的に間違っているはずの「おでんが売っている」という表現を許容する結果となっているのではないか、というのが私の解釈である。

　ひょっとすると、既に「正しい日本語」としての市民権を得ている「ジャズがかかってる喫茶店」という表現も、一昔前には「ジャズを『かける』のは喫茶店のオヤジ。だから、『ジャズをかけている喫茶店』が文法的には正しい」という批判されていたのでは、と想像が膨らんでしまう。

　そう言えば、NTTに入社したての時に、誤って研究室の花瓶を割ってしまい、上司に「申し訳ありません、花瓶が割れてしまいました」と誤り謝りに行ったところ、「花瓶は勝手には割れないだろう。そういうときは「花瓶を割ってしまいました』という表現が正しい」と叱られたのを思い出した。わざとじゃないんだから「花瓶が割れた」で良いと思うんだが、どうなんだろう。

【追記】この表現に関する、日本語の研究者による考察を発見した。

「イチゴが売っている」という表現　又平恵美子

日本語母語話者の会話で「イチゴが売っている」というような表現が使われることがある。商品が「ガ」で示されるのは、単なる言い誤りによる格の誤用として処理してしまうには出現の頻度が高く、一つの定型構文として成立してしまっているものであると考えられる。 　動作主ではなく対象が「ガ」によって表示されていること、必ず「売っている」などテイル形で現れるということ、商品の所有権が移動しないという状況に限定されているということがその構文が成立可能となる特徴としてあげられる。このような表現が存在し得る理由は、「商品として物が存在している」ということだけを表現するためには、冗長的でない規範的な言い方では言い表しにくいということが考えられる。

【『筑波日本語研究』第六号　要旨より引用】

　この表現の面白さに気がついたのは私が初めてではないようだ。

　年配の人が「最近の若者の言葉はめちゃくちゃだ」と言うのは、言葉が進化しているから。誤用する人が増えて来て、多くの人に通じるようになれば、りっぱな日本語だ。その過程で年配の人が「わかもの言葉」に違和感を持つのは当然。そんな「新しい日本語」を発掘してみるというのも楽しそうなので、一つ実験をしてみる。

　下の６つの文を、あまり深く考えずにさらっと読んで欲しい。そして違和感を感じたかどうかをコメント欄なり、ブックマークコメントでいただきたい。「最初に読んだ時は違和感を感じなかったけど、もう一度読み直してみたらどれが変なのか気がついた」、「どれに問題があるかは言われれば分かるけど、別に通じるからいいじゃん」、「普通に使ってたけど、これって間違ってたの？」という返事もOK。

・そこの公園で子供が遊んでいる
・そこのクラブで彼女が踊っている
・そこのコンビニでおでんが売っている
・そこの畑でキュウリがなっている
・そこの校庭で桜が咲いている
・そこの河川敷で花火大会が開かれている

Thanks in advance,
Satoshi

　思いっきり周回遅れでやっと映画「ゲド戦記」を見たわけだが、感想は多くの人と同じ。これではジブリ作品の将来があやぶまれる。今まで、ナウシカ・トトロ・宅急便・ラピュタなどの超一流作品を宮崎駿監督の指揮のもとに出して来たスタジオジブリ。優秀なスタッフを抱えていても、監督が違うだけでこんなにも出来が違うとは。結局は監督なんだな、と。

　「ゲド戦記」を見てあらためて認識したのは、宮崎駿が作る「世界観」の説得力のすごさ。子供にしか見えないネコバス、毒をまき散らす腐海、飛行石、神様たちの銭湯ーそんな、本来ありえないものを題材にしながら、わずか最初の五分間で彼が作り出した世界が妙に納得できてしまい、あとはワクワクドキドキしながらストーリーを楽しむだけ。それが宮崎マジックである。

　映画「ゲド戦記」の一番の問題は、この「観客に映画の中の世界観を瞬時に納得させる力」の欠如である。あんなに「入って行けない」映画は久しぶりであった。映画が作り出す世界観が納得できないままでは、主人公の気持ちも伝わって来ないし、ワクワクドキドキもしない。Wikipediaのスタジオジブリの項目に書かれている「宮崎（駿）と高畑の2人が引退したらジブリも終わる」という言葉も納得できる。少し寂しい気もするが、これだけ映画が産業として成熟しているにも関わらず、良い作品を作る力が一個人に属しているというのは、なんだかそれはそれでうれしいような気もする。

　404 Blog Not Found の「LiveCoding に学ぶプログラミングの三原則」を読んでいたらどうしても書きたくなったので。あくまで私のスタイルなので、参考にするもしないもご自由に。

1. スタードダッシュでできるだけはやくめどをつける

　学生時代から夏休みの宿題は７月中に終わらせていた私とすれば、ラストスパートよりはスタートダッシュで勝負する。どのみち、どこかで思いっきり頑張らなければならないのであれば、締め切り間際ではなく、スタート間際に頑張るべきというのが私のポリシー。十週間のプロジェクトであれば、最初の二週間が勝負。そこで八割がたのめどをつけておき、後は流す。最初の二週間がめどが立てられなければ、十週間で完成できる可能性は低いと考える。常にそういう姿勢でいれば、締め切りぎりぎりになって致命的な欠陥が見つかって痛いめにあったり、本当は大幅な設計変更をすべきなのに応急処置ですます、などの可能性が減らせる。

　このスタードダッシュ型の仕事スタイルを実現するには、「締め切りに迫られて」ではなく、「自分から進んで」スパートをかける必要がある。以下はそのための手法。

2. 仕事を「タスク」に細分化する

　プログラマーである私にとって、一ヶ月は「気の遠くなるような先」。そんな先を目指していてはすぐに息切れしてしまって走ることができない。そこで、仕事を細分化する。ここでの仕事の一つの単位（便宜上「タスク」と呼ぼう）は半日から三日ぐらいで出来るもの。最初にすべきものほど明確に定義し、後でやるものはある程度曖昧にしておく（どのみち設計変更はするので、あまり先のことまで綿密に計画を立てるのは時間の無駄）。

3. 一日の始めに、「今日やるマイクロタスク」のリストを作る

　これはすなわち、当面取りかかるべきタスクのさらなる細分化（マイクロタスク化）である。大切なことは、各マイクロタスクが独立した作業で、それが達成できたかどうかが（テストプログラムなので）明確に確認でき、かつ、それを一塊のものとして（ソースコードを管理しているサーバーに）チェックインしてもサイド・エフェクトがないこと。大きさとしては、うまく行けば１５分ぐらいで、なかなかうまく行かなくても二時間ぐらいで完成できると思えるぐらいが適切。ちなみに、サイド・エフェクトの考慮は大切。相互に依存するモジュールAとBに同時に変更をかけなければ問題が生じるのであれば、モジュールAへの変更だけを独立したマイクロタスクとして定義することは不可能。

　そんなマイクロタスクを数個から十数個並べたリストを机の上に書いて、それぞれにチェックボックスを添えた上で、例えば「今日は昼飯までには最初の４つ、家に帰るまでには残りの７つを絶対終える。余裕があったら、次の２つもこなす。」と自分で宣言する。

4. それぞれのマイクロタスクは「割り込み禁止状態」でこなす

　大切なことはマイクロタスク一つ一つを「決して他の仕事を間に挟んでは出来ない仕事」と覚悟して、全力疾走でこなすこと。その間はメールのチェックはしないのはもちろん、電話がかかって来ても取らない。トイレにも行かないし、席から立ち上がりもしない。誰かが机に来ても、「今はだめ」という。脳を１００％そのマイクロタスクに集中し、一気に書き上げる。つまり、マイクロタスクを処理している時にコンテキスト・スイッチをしてはいけないのだ（割り込み禁止状態）。

　大切なことは、この「割り込み禁止状態」と「割り込み可能状態」をはっきりと区別して一日を過ごすこと。「割り込み禁止状態」におけるプロダクティビティを最大化できれば、その比率は４：６（つまりプログラミングをしている時間が４割）ぐらいでもものすごく仕事がはかどる。逆に常に割り込み可能状態でプログラムを書くと効率の悪さ故に、残業しても、一日の９０％の時間をプログラミングに費やしても大して仕事がはかどらない。この割り込み禁止状態でマイクロタスクをひとつづつこなすという仕事のスタイルに体が慣れていれば、どうしても仕事量を増やさなければならない時には、その比率を８：２ぐらいまで増やした上で仕事時間を長くすれば良いだけのこと。何日も続けると体が持たないし、周りの人に迷惑をかけるが、２〜３日ぐらいのダッシュなら二週間に一度ぐらいはかけられる。

5. マイクロタスク単位に丁寧にテストした上でチェックインする

　順調に書き上げることができれば、自分なりのテストをして、それが確実に動いていることを確認した上でチェックイン（「１つ書いては動かせ」というやつ）。それから休憩するなり、メールのチェックをする（割り込み可能状態）。チェックインする単位ごとでのテストは手を抜いてはいけない。このレベルでのバグを発見するのは、プログラムを書いた本人の役目。テスターの役目ではない。テスターの役目は、どうしても生じるプログラマーが見つけ損なってしまったバグを見つけること。「たぶん動くだろうけど、バグがあったらテスターが見つけてくれるからいいや」という考えでチェックインするのは犯罪行為。

6. うまく動かないマイクロタスクは、一度最後にチェックインしたところまで戻って書き直す

　そんなマイクロタスクを実行中に、ある部分のソースコードを大きく書き直したくなることがあるが、そこは躊躇せずに思い切ってする。万が一そのためにプログラムがぐちゃぐちゃになってしまったら、ケチケチせずに、最後にチェックインしたところまで一気に戻ってやり直す。マイクロタスクが十分に細分化されていれば、そこで「捨てるコード」に費やした時間は高々１〜２時間。一度ぐちゃぐちゃになったコードを直す方がよっぽど時間がかかる。

　変更した箇所が思った通りに動かない時も同じ。デバッグしてすぐに問題点が見つかるのであれば直せば良いが、なかなかデバッグしてもうまく動かないときは、思い切って変更を切り捨てて、最後にチェックインしたところにまで戻る。特にこれが必要なのが、新しい機能を追加した時に、今まで動いていたものが動かなくなってしまった場合。「なぜ動かなくなったか」を解析している時間と、ゼロからもう一度書き直す時間とどちらが大切なのかを考えると、ゼロから書き直した方が早い場合が多い。これは私の経験だが、動くはずのプログラムが思った通りに動かないときの一番の原因はつまらないケアレスミス。セミコロンの入れそこないだとか、x と y が逆になっていたりとかだ。そんなケアレスミスがなかなか見つからずに煮詰まってしまうことは良くある。そんなときは、躊躇せずに変更を全部捨て、最後にチェックインしたところまで戻って、ゼロから書き直す。

　これを読んでも分かるように、私のプログラミング・スタイルには、ソースコードのバージョン管理をしてくれるシステムが必須。たとえ一人でプログラムを書いていてもこれは同じ。そして、イメージとしては、階段を一段一段踏みしめながら登るように、チェックインのたびにテストを繰り返しながら、丁寧に丁寧に一段づつ仕事を積み重ねて行く。積み上げかけた段がうまく形にならなければ、一度その段は完全に取り除き、再びゼロから新しい段を作り直す。ただし、一度作った段を出来るだけ確固としたものにするために、各段ごとのテストは怠らない。「何となく動いている段」「ふにゃふにゃしている段」の上に次の段は作れない。そして、「今日は七段登る」と決めたらよほどのことがない限り七段登れるまでは家に帰らない。そのかわり、予定よりはやく七段が作れてしまえば、さっさと家に帰る。どうしても煮詰まったら、一度家に帰ってゆっくりと頭を休めて、フレッシュな頭で再度チェレンジする。とにかくマイクロタスク単位での自分のプロダクティビティを最大化するには何をしたら良いかを常に意識して仕事をする。

　今日はたまたま「ユーザーからのフィードバックを集めることの難しさ」が話題になったので、それに関連するエントリー。

　もの作りにおいて、「ユーザーが何を必要としているか」を知ることは大切だが、だからと言ってユーザーに尋ねれば正しい答えが返ってくる訳ではないところが難しいところ。具体的な例としては、こんなものがある。

1. サイレント・マジョリティの声は聞こえてこない

　これはMicrosoftで実際にあったことだが、Outlookのチームではユーザーから寄せられる機能追加のリクエストに従って色々な機能を足していた時期があったが、その結果不必要な機能ばかり増えて、単純な作業が逆にやりにくくなってしまった（たとえばカスタム・フォームが良い例）。このケースでは、ごく一部のヘビー・ユーザーばかりが声がでかく、「今の機能で十分、これ以上複雑にしないで欲しい」というユーザーは何も言ってこない（こういう人たちのことをサイレント・マジョリティ）という状況にあったからこんなことになってしまったのだ。「使い方が分からないのは自分が勉強不足だからだ」と勝手に思い込んでしまって文句も言わないというユーザーも結構いる。

2. ユーザーは既存の考えに捕われているだけかも知れない

　以前このブログでも取り上げた話だが、ユーザーは必ずしも本当に必要とするそのものをリクエストせずに、それを得るために必要だとユーザーが思い込んでいるものをリクエストしてくるケースがしばしばある。「もっと早く走る馬が欲しい」と言っているユーザーは、実は単に「より早い移動手段が欲しい」だけなのかも知れないし、「電気ドリルが欲しい」言っているユーザーは、単に「穴が欲しい」だけなのかも知れない。

3. ユーザーは理想に浸っているだけかも知れない

　「こんな機能が欲しい」と言ってくるユーザーは、本当はそんな機能が欲しいのではなく、そんな機能を使いこなしている自分を想像して満足に浸っているだけかも知れない。心理学の実験で有名な話が、黄色い帽子と白い帽子の実験。被験者の女性に、黄色と白の二色のつばの広い帽子を見せ、「どちらかの帽子がもらえるとしたらどちらが欲しいですか？」と尋ねると「黄色の帽子」を選んだ人が多かった。しかし、そのインタビューの最後に「どちらの帽子でも良いので持って帰ってください」と言うと白い帽子を持って帰った人の方が多かったという。最初の質問に黄色と答える人が多いのは「はでな色の帽子を着こなしている自分」に憧れているからであり、持って帰るとなると白い帽子を選ぶのは、実際に自分が持つとなると、どの服にも合いやすく無難な白の方が扱いやすいからだという。

　私が尊敬するIDEO（「発想する会社」参照）では、こんな勘違いをしないように、とにかく「ユーザーを徹底的に観察すること」に重点を置いているという。ユーザーを丁寧に観察して、彼らが本当に必要としているものを見つけ出す。それがIDEOなりのもの作りの仕方だ。