事前の準備とスピーチの最初がポイント - 英語でnote-takingのコツ その2

前回は英語の講演を聞いてレポートを書くためには、どのようにしてnote-takingをすればいいかの話をしたので、今回は実際に試してみようと思います。レポート作成のために聞くのはNeal Gafter氏による講演"Closures For Java"です。JDK 7で追加される予定のJavaの新機能Closuresについての話題で、言語そのものの仕様がテーマなので、若干難しい内容かもしれません。講演は質疑応答まで入れると115分もあり、とても長いので、本記事では途中まで取り上げることにします。では、前回の理論編を見ながら、今回の実践編に取り組んでみましょう。

まずは、予備知識を身につけておきます。概念を理解しておくだけなら、日本語で解説されている記事などのほうが簡単ですから、日本語で検索してよさそうなものを探すといいでしょう。今回取り上げるClosuresについては「ついにJavaにもクロージャ? - James Gosling氏らJDK7へ導入提案」をはじめ、いくつか見つかるはずなのでざっと眺めておくといいでしょう。

英語の講演の場合は、日本語だけではなく英語の資料にもぜひ目を通しておいてください。というのは、用語とその発音を確認しておかないと、連発される英単語の中に埋もれている用語を認識できないことがあるからです。今回のClosuresに関しては、仕様などが公開されているWebサイトが適当だと思いますが、ここで紹介されているすべてのドキュメントに目を通す時間がなければ、このトップページに表示されている用語を頭にいれておくだけでも、内容理解に役立つはずです。

では、講演を聞きはじめますが、実際の講演では聞き漏らしがあったり、瞬時に理解できないこともありますので、忘れず録音したいものです。ただ、録音してあるからと安心せずに、できるだけ手元のノートだけでレポートをかけるようにする心掛けも大切です。講演は短くても30分くらいはあるはずです。それを最初から聞き直すのは時間の無駄ですし、アクティブに聞く気持ちが薄れて理解の程度も低くなってしまいます。ノートの内容の間違いを修正するために録音したものを聞くくらいのつもりがちょうどいいのではないでしょうか。

講演が始まったら、最初の概要説明の部分はとくにしっかり聞くようにしましょう。通常、スピーカは最初にどのような内容の話をするか、またはアジェンダなどから始めます。ここからノートを取り始められるかどうかで、その後のnote-takingがうまくいくかどうかが影響されるからです。たとえば、Gafter氏は"Outline"というタイトルのスライドで概要を説明しています。このようなページを見たときに余裕があったら、ノートの1ページに1つずつタイトルを書いておきます。わかっていたつもりでも、話を聞くことに集中してしまうと、どこで話が次のテーマに移ったのかを見失いがちです。迷ったときに、ノートの1行目に書いておいたテーマを見れば、今どのあたりの話をしているのかを追いかけやすいはずです。残念ながらGafter氏の講演ではそれほど時間に余裕はなかったので、最初のページにひととおり書き留めておきました(図1)。

もう1つ、この概要説明で掴んでおきたいのがどのようなタイプのスピーチなのかです。わずかの言葉のみですがGafter氏が"problem"と言っていることがわかるでしょうか。つまり、この講演はproblem-solving型のスピーチである可能性が高いのです。ということは、問題点が提示されて、その解決策がディスカッションされるはずです。そのような心構えで聞いておくと、話の流れやメインアイディアを掴みやすくなります。

参考までに、informative型のスピーチがどのように始まっているかを簡単に見ておきましょう。"Advanced Python or Understanding Python"のビデオですが、講演を行っているThomas Wouters氏は冒頭で、"cover basically everything"と言っています。つまり、このスピーチは概要的な内容で、informative型である可能性が高いと判断できます。その場合は、どのような特徴があるのかに注意するとメインアイディアが何かを見つけやすくなります。

講演が最初のテーマに移ったら、さっそくノートをとっていきますが、スピーカは何か特徴的なフレーズを使っているでしょうか? Gafter氏は"What is/are ...?" "Point is ..." "That's important."といったフレーズを使っています。そして、Gafter氏の講演では特徴的な"but"があります。このような言葉が出てきたらとくに注意して聞きます。たとえば、Gafter氏は"Goalsは何か"を問いかけて、"Control Abstraction APIsで何かを可能にすることである"と答えています。これが最初のメインアイディアになります。

以下、最初のテーマについてGafter氏の講演のnote-takingを行った例が図2なので、参考にしてください。Outliningのための数字まで付けることはできませんでしたが、インデントを行ったり、言葉の代わりに記号を使ったり、自分にはわかる略記を利用しています。疑問点には"?"マークも付けました。

このようなノートをとるときはできるだけスペースを空けて、あとから書き込めるようにしておくのもnote-takingのコツです。レポート作成にあたり、録音した講演を再度聞いたとき、Webサイトで調べたときに書き込むためのスペースが必要です。また、テーマが変わったと思ったときには次の紙を使うようにしておくのもコツの1つです。講演のどのパートだったかを勘違いしていたときにも修正するのが楽になります。

さらに講演が進んでいくとGafter氏のスライドは何かのExampleになっています。これは冒頭の概要をきちんと聞いていれば"Existing Solutions"の話題であり、また、解決策ではなくて、"problems"の説明をしていることもわかります。"Existing Solutions"と書かれたスライドは登場していないので、どこの話をしているのか迷子になりそうなところですが、話を聞くことに集中していれば大丈夫ですね。

"Existing Solutions"のパートをnote-takingした例が図3、図4です。ここは問題点が何なのかを掴むことが目的ですから、その点に集中しました。また、最初に右側に書いていき、後でわかりやすいように問題点を左側にも簡単に書き足していきました。

さて、3つめの例をあげたときに、Gafter氏は大きな声で"but"と強調していたり、"Point is..."というフレーズを使っています。ノートには並列に問題点を書き連ねましたが、もし、レポートで例を1つだけ選ぶとしたら、これを取り上げるべきでしょう。既存の問題点をまとめた後で、さらに2つの例を引き合いに出していますが、こちらはプログラムの説明がとても長いので、そちらに注意が行きがちです。ただ、このパートのメインアイディアは「問題点は何か」ですから、あくまでそこを聞き取ることに集中します。Gafter氏がコードの一部に色を使って、問題点をわかりやすくしてくれていることにも注意したいですね。

もうひとつ、note-takingの例(図5)を見てみましょう。これは"Specification"のパートをメモしたものです。"Specification"の名前が出てきたスライドにはこのパートの概要があります。これを見たら、まず、ノートを3等分してfunction、closures、control abstraction APIsの項目を間をあけて書き込みます。そして、その後の話をスペースに書き込んでいきますが、おそらくハンドアウトなど資料はなんらかの方法で手に入ると予想されるので、詳細ではなく、どのように話が進んだかのメモで十分でしょう。後で振り返ってみると、概要説明にあった"Specification"と"Examples"はいっしょに話が進んでいたことがわかります。

できあがったノートはGafter氏が話をした内容と比べるとかなり簡略化されていますが、それでもレポートを書くには多すぎるくらいあるはずです。書きすぎず、ポイントを抑えるように心がけたいところです。なお、Gafter氏の講演の場合、概略だけをレポートにするとしたら、最初の数分を聞けば十分なのはわかるでしょうか。きちんと話すスピーカほどこの傾向があるので、最初の部分は神経を集中させて聞き取りたいものです。