本コラムの読者のみなさまなら、おそらくオンラインのニュースサイトをまめに読んでいるのではないかと思います。そのニュースサイトには要約(summary)が書いてあることが多いのですが、これはsummaryであると、意識して読んでいる方はあまり多くないのではないでしょうか。たとえば、マイコミジャーナルのエンタープライズのトップページに掲載されている紹介文ですが、これもsummaryの一種とみなしていいと思います。近頃はブログを要約して、コメントを付けて紹介するInfoQのようなサイトもあります。今回はsummaryの書き方について話をしましょう。
Summaryの書き方"summarization"については、本コラムの第21回、第22回で取り上げていますが、このときには各パラグラフの最初の文章だけ見ていけばいいような、ある程度きちんとしたスタイルがあるドキュメントを要約する方法を紹介しました。今回は、第39回、第40回で取り上げたような講演などを中心に見ていきます。内容は英文ライティングのための要約手法なので、日本語で書くスタイルとは若干合わないことがあるかもしれません。しかし、英語の場合、要約術のようなノウハウが確立しているので日本語の場合も参考になると思います。
要約の4つのタイプ - 読む人に合わせたレポートを
読者の方々はおそらく何かの要約を一度くらいは書いたことがあると思うのですが、要約を書き始める前に、自分は何のためにこれを書くのかといった目的を考えたことがあるでしょうか。英文ライティングの場合、「何のために書くか」といった観点から、一般に要約のタイプが次の4種類に分類されています。
- Executive Summaries
- Evaluative Summaries
- Descriptive Abstracts
- Informative Abstracts
そして、どのタイプかによってどのような要素を盛りこむかが違ってきます。
1つめの"Executive Summaries"というのは忙しいボスが読む、つまり、executiveに分類される多忙な人達が読むために作成する要約なのでこのような名前が付けられています。"Executive Summary"をキーワードにしてインターネットで検索すると、いろいろな定義や書き方の注意などを説明しているサイトが見つかります。これらの説明を見ると、重要なポイントのみを凝縮した短いレポートを書くのがこのタイプの要約ですが、盛りこむ要素はdetailsではなく、big picture(全体像)を書くようにします。note-takingを行ったものからこのタイプの要約を書く場合は、特に木ではなく森を見るように、できれば"森の将来の姿"を見るようにするといいのではないでしょうか。
2つめの"Evaluative Summaries"はソフトウェア関係の記事やブログなどでよく見かけるものですが、いわゆる"critique"と呼ばれるタイプの要約です。InfoQのブログを元にした記事などはこのタイプになっていることがあります。これも要約ですから短くしていきますが、目安としてはオリジナルのドキュメントや講演の5 - 10%程度にすると言われています。第39回および第40回で取り上げたNeal Gafter氏の講演は100分くらいなので、5 - 10分話せば終わるような要約ということになるでしょう。盛りこむ内容としては、意見を述べたい部分を説明できるような短い要約と、自分の見解の組合せをいくつか作り、全体を構成するような書き方になります。この要約を書く場合は、詳細にnote-takingを行うよりも、疑問点や感想などを書き込むことに集中するといいかもしれません。
3つめの"Descriptive Abstracts"はとても短い要約で、記事全体を読む、あるいは講演すべてを聞くかどうかを判断できるようにするために書くものです。マイコミジャーナル｜エンタープライズのトップページにはこのタイプの要約になっているものがいくつかあります。文章の数は多くても4つくらいで、詳細や結論を省いて、何について書いてあるのかのみをまとめます。前回、最後の部分で「なお、Gafter氏の講演の場合、概略だけをレポートにするとしたら、最初の数分を聞けば十分なのはわかるでしょうか」と言ったのですが、Descriptive Abstractsがこれにあたります。
4つめの"Informative Abstracts"はいわゆる報告書で、Executive Summariesのようにこれを読んで何かの判断材料にすることこもなければ、Evaluative Summariesのように意見を述べるものでもありません。このような要約を書く場合には、解説"Writing Summaries"や"Standard Summaries"が参考になるのではないかと思います。
レポート作成実践編
では、前回までにnote-takingした内容から4つ目のスタイルで要約を書いてみましょう。最初の文章では誰が何という講演を行ったかを書き、この講演のthesisへと繋げます。その後は講演者であるGafter氏が説明したOutlineにしたがってnote-takingした内容を並べてゆき、最後にConclusionを書けば報告書ができあがるはずです。
以下は前回、note-takingの例を示したSpecificationとExamplesのところまでで要約を行った例です。
Neal Gafter氏は2007年1月17日にGoogle Tech Talksにおいて、"Closures for Java"というタイトルで講演を行い、現在のJava言語が持つ問題を解決するためにクロージャと呼ばれる新APIの提案を行った。
Gafter氏はまず、"Control Abstraction APIs"と呼んでいる新APIを導入することで、もっと簡単にJavaのコードを記述できるようにすることが目的であると説明した。このAPIは関数を書けるようにするもので、既存のAPIともスムーズに接続できる。同時に、このAPIの要素であるクロージャ、関数、フリー変数についての定義も行い、Control Abstraction APIsがビルトインされる関数になる点についても簡単に説明も加えた。
次に、Gafter氏は現在のJavaでよく目にするコードを紹介して問題点を列挙した。Gafter氏によると、現状ではJavaはforループなどで、同じコードを何度も大勢のプログラマが繰り返し書くことになる、コード量が一般的に長く、複雑になりがちな問題があるということだ。また、クロージャの代替として利用されているanonymous classでは親クラスのメソッドの利用に注意が必要であるほか、例外を投げられない、ローカル変数の使用に注意を要するといった問題点もあげた。さらに、複数のスレッドが同じように動けるようにプログラミングするのが難しい点にも触れた。
以上の問題点を考慮すると新APIに要求されるのは、Control Abstraction APIsを追加して、シンプルに、簡単に、しかも既存のAPIを修正せずにコード書けるようにすることであるとGafter氏は強調している。
続いて、新APIに提案している関数型、クロージャ、Control Abstraction APIsの仕様について、どのように記述できるかの具体例をあげながら、シンタックスや機能、特徴について詳細に説明した。関数型は通常のJavaのインタフェース型なので、実装や継承など、これまでのインタフェースに出来ることは関数にもできるということである。また、関数とは違い、クロージャの使用にはやや制限があるようだ。Control Abstraction APIsとしてはスレッドのロック/アンロックを簡単にするwithLock関数の例をあげてControl Invocationの仕様を、また、クロージャを使うとどれだけ簡単に記述できるかの例をあげながらControl Abstracionの仕様を説明した。さらに、Aggregate Operationsといった仕様についても触れている。
3回にわたり、note-takingから要約作成までを行ってみましたが、いかがでしょうか。実際に試してみると、理論どおりにはいかないと思いますが、やみくもにメモをとってレポートを作成するよりは楽になったのではないでしょうか。また、誰が読むのか、どのような要約を書くのか、といったところまで考えてnote-takingできるようになるとさらに楽になるでしょう。
