まつもとさん、ネタにさせていただいてありがとうございます!

前回、Rubyのまつもとゆきひろ氏の英語のプレゼンテーションを取り上げましたが、読者の皆様はYouTubeで公開されている映像をご覧になったでしょうか。前回は、英語のネイティブスピーカにわかってもらえるプレゼンテーションにするためにはどうすればいいかを解説しましたが、これだけで実践するのは難しいかと思います。今回、もう一度、まつもと氏のプレゼンテーションを題材にして、どのように直せばいいかを具体的に見ていきたいと思います。なお、プレゼンテーションの本連載への利用に関してはまつもと氏の承諾をいただけましたので、心置きなく修正させていただきたいと思います。承諾していただいたまつもと氏に感謝いたします。

Thesisは必ず最初にもってくる

まずは、最も重要なthesisをどのようにして考え出すかです。これはたとえ英語ネイティブスピーカであっても簡単ではないのです。私が今勉強している英文ライティングのクラスでは、1人ずつ自分が書こうとしているエッセイのthesis statement(文章)を発表して、それが妥当かどうかをディスカッションする時間がありました。評価項目としては

  • 知的興味をそそるような質問に答えているか
  • ひとつの話題に集中しているか
  • 明確であるか

などがありますが、すべての用件をそろえたthesisはすぐには作れないものです。そのためにディスカッションをしてthesisそのものを修正できる時間を設けているのです。ちなみに私は、"In those days, money changed people's lives more than these days."を考えたのですが、これを聞いた米人は???という顔でした。どうやら、明確ではないthesis statementだったらしく、私が何を言いたいのか理解できなかったようです。ようやく、"more influential"と言ったほうがいいのではないかとのコメントをひとついただきました。

このようなthesis検討の場もなく、自分で考えないといけない場合は、とりあえず作ってみて、見直して、revisingを行う方法で進めるといいでしょう。そのためには、ただプレゼンテーションとその原稿を眺めていても進まないので、前回紹介した、mappingという方法を試してみます。

たとえば、まつもと氏のプレゼンテーションのスライドを元に図に書いてみると、図1のようになるでしょう。まつもと氏が3枚目のスライドを見せながら「Rubyの一般的な話と1.9の話をします」と言っているように、2つの大きなトピックがあり、ツリー構造のルートが2つあるのですが、これ以外はほぼきれいにツリーに収まっています。ただ、?マークをつけた2つのトピックは話が出てきた順番を考慮すると、うまくマッピングできる場所がありません。たとえば、YARVのperformance chartですが、Ruby 1.9のNew Implementationの流れで出てきたはずなのですが、chartが表しているのはRuby 1.8でのベンチマークです。Ruby 1.9のツリー構造の中にはマッピングできません。

マッピングした図を眺めると、やはりこのプレゼンテーションはRuby 1.9の話に集中するべきで、一般的なRubyのトピックはいさぎよく捨てるべきでることがわかるのではないでしょうか。ただし、有名な誰かの言葉を引用する方法はconclusionで使えるので、Communityのところ(40番目のスライド)で引用したMartin Fowler氏の言葉はとっておくといいかもしれません。ほかにも修正した方がいいところなどを書き込んだのが図2です。

図1

図2

それでは、残ったRuby 1.9を中心とするスライド構成を改めて眺めながら、thesis、つまりこのプレゼンテーションで主張したいことは何かを考えてみましょう。無視できないincompatibilitiesの問題が発生するにもかかわらず大きな仕様変更を行い、実装についてもYARVにしぼってパフォーマンス向上を果たしていることを考慮すると……「進化したRuby 1.9はプログラミングを楽にしてくれる」ことを主張するのがひとつのthesisとして考えられるのではないかと思われます。

これを聞いて、どこかで見たような内容だとお気づきでしょうか。そうです、最後のスライド、つまりconclusion(結末)でそのような内容の話をしています。実はこれはconclusionではなくthesisにするべき内容だったです。このように、thesisにして最初に言うべきだった内容がconclusionで現れるのは日本人にありがちな、"これこれしかじかだからこうだ"という流れが出ているところですが、英語ではこれをやってはいけません。一番言いたい「こうだ!」という内容がthesisになるはずで、最初に言うべきことなのです。まつもと氏は"selfish(利己的)"だとsarcastic(皮肉っぽく)に言っていますが、英語ではこれをselfishと片付けないでassertive(断固とした)な主張にするべきです。

トピック(main ideas)は、思い切って削る勇気も必要

次に、各トピックを眺めてみましょう。各トピックはthesisをreinforce、強固にするものでなければいけませんが、どうでしょうか。これをチェックするためにはマッピング図のRuby 1.9の丸に直接つながっている各トピックについて、次のような質問を考えてみるとわかりやすいかもしれません。

  1. クリスマスにリリースしたことによって進化したRuby 1.9はプログラミングを楽にしてくれる?
  2. New Features によって進化したRuby 1.9はプログラミングを楽にしてくれる?
  3. Incompatibilities によって進化したRuby 1.9はプログラミングを楽にしてくれる?
  4. New Implementation によって進化したRuby 1.9はプログラミングを楽にしてくれる?

2つめと4つめはthesisをreinforceしていますが、1つめは明らかに間違いです。3つめは字面からは間違いのような感じですが、その部分木にマッピングされているサブトピックや例などを眺めると必ずしも間違いでもなさそうな様子です。ただし、New Featuresとして紹介するべきだったのではないかと思われるものも多々見受けられます。Incompatibilitiesという単語にはnegativeなイメージがあるので、positiveなincompatibilitiesはNew Featuresにできるだけ動かして、pros and consのconsとして小さくまとめた方がいいかもしれません。

さて、実はひとつとてももったいないトピックが抜けています。6番目のスライド、Ruby 1.9 = Bleeding Edgeのところで、「design flaw(s)を直した」と、ほんとうにひとことしか言っていないのですが、この質問はどうでしょうか。

Design flaw(s)を修正したことによって進化したRuby 1.9はプログラミングを楽にしてくれる?

答えはもちろん"yes"ですね。これはひとつのトピックを設けて詳しく説明してもよかったところではないかと思います。

細かいところですが、33番目のYARVの実行速度は実際には50倍速くなっていないというnegativeな話がでています。事実かもしれませんが、パフォーマンスが向上したというポイントをサポートしていないので、英語という観点からすると、この話は削除するべきでしょう。また、34番目にFeelingという言葉を使って感覚的に速くなった話をしていますが、まつもと氏以外の人が同じように感じるかどうかわかりませんので、これは logical fallacy(論理の欠如)です。「常識では…」は有名なlogical fallacyですが、「感覚的には…」も英語では通用しないので止めましょう。

今回はまつもと氏のプレゼンテーションを題材にthesisを導きだして、内容をrevisingする話をしましたがいかがでしょうか。自分が作ったプレゼンテーションの問題点はなかなか見つけられないものです。一方、他人が作ったものは客観的に見られる分、悪い点に気がつきやすいので、誰かに見てもらうといいのではと思います。