ひとことで表すことの難しさ

私事ですが、9月2日の日曜日にDetroit Riverの中州のような島 Belle Isleで行われたIndy Grand Prixを見にいってきました。日本人ドライバー 松浦孝亮が5位と健闘していましたが、なんといっても一番人気だったのは女性ドライバーのDanica Patrickです。観客の声援も一番大きかったDanicaは、2度もアクシデントに見舞われながら、途中1位を走り、最終的には自己最高の2位という成績を残しました。これについて、"Career-best finish"という記事に

"It was a bit of an up-and-down day," Patrick summarized.

と報告されています。2時間以上にわたるレースの内容を短いながらもうまく要約している言葉です。今回はこの要約についてお話しましょう。もちろん対象は自動車レースではなくソフトウェア関連の文書です。

「要約のための要約」にならないために - annotatingの重要性

ソフトウェア関連の英文を要約することになった場合、何か目的があって要約するのではないでしょうか。つまり、要約すること自体が目的ではなく、要約した文章から他の誰かが何かを判断したい、あるいは何かを知りたいという目的があるのではないかと思います。もちろん、自分のために忘れないように要約しておくケースもあるでしょうが、やはり、要約そのものが目的ではないはずです。英文を読みはじめると、英語に振り回されて本来の目的を忘れがちになるので、あらかじめその目的を書き出しておくといいでしょう。

要約する場合、書き出した目的に合う内容になっていれば、英文の最初から最後まですべてをきちんと要約する必要はないといえます。英文ライティングのクラスでは、エッセイを読んで要約を交えてリアクションのエッセイを書く課題が出されますが、すべての内容を含む要約を書いているクラスメートはいませんでした。というのも、要約の目的は自分が書きたいリアクションが原文のどこに対してなのかの説明するためだからです。最良の要約サンプルはもちろん文章すべてに触れていますが、この場合は最良の要約を作ることが目的であり、リアクションエッセイを書くための要約とは違ってきます。

目的を書き出して、英文を読みはじめたら、ぜひ第18回で話をしたannotatingをしてください。Thesisが書かれている部分、各paragraphのmain ideaとなっている部分にはアンダーラインを引いたり、 で囲んだりしておきましょう。空いている部分に自分の言葉でparagraphのまとめを書き込めば理解も深まるのでなおいいのですが、目印をつけておくだけでも十分です。そして、セオリーどおりにいけば、thesisと各paragraphのまとめをつなぎ合わせれば要約ができ上がります。

ただし、実際にはセオリーどおりとはいかないでしょう。著者が必ずしも理想的な英文を書いていないことや、detailが多すぎてmain ideaを見失いがちになるなど、理由はいくつか考えられます。とくにソフトウェア関連の文書はサンプルコードなどのdetailが多く、その部分の理解に振り回されがちです。場合によってはサンプルコードを中心に見て、自分の知識と照らし合わせて評価を下してはいないでしょうか。通常、著者は自分の意見やアイディアをdetailで補強しているので、サンプルコードを見たら、そのコードが必要だった理由を見つけ出してください。それがmain ideaのひとつになっているでしょう。

実例でannotating - thesisとmain ideasを探し出す

このように説明だけだとわかりにくいと思いますので、"An Introduction to Groovy Grails"を例に、annotatingしながら、thesisとmain ideasを見つけていきましょう。

この文章の場合、"Abstract"の部分がイントロダクション相当で、最後のparagraphにthesisがあります。

"In this article/essay, I will ..."

という書き出しは「これからthesisを言いますよ」と書いてあるのと同じで、このシグナルワードを見たら、ここにthesisが書いてあると考えて差し支えないでしょう。私がアンダーラインを引いたのは

  • "I will look at the Web development capabilities of Groovy,"
  • "I will develop a sample Grails Web application and look at the various features of the framework."

の2文です。つまり、著者はこの記事で、

  1. GroovyがWebアプリケーション開発に適していることを説明する
  2. Grailsを使ってWebアプリケーションのサンプルを作ってみる
  3. Grailsのさまざまな機能を説明する

の3つを解説しようとしていることがわかります。

Abstractに続く、"What is Groovy?"と"Web Development with Groovy"は1つめのthesisに関連付けられる部分です。まず、"What is Groovy?"の中でアンダーラインを引いたのは1つめのparagraphの最初の文章

"Groovy is a language that has a syntax that's similar to, yet simpler than, Java."

と、2つめのparagraphの最初の文章

"Groovy has a lot fewer rules than Java."

と、2つめのサンプルコードの直前にある

"the simplicity of Groovy and its capacity to leverage the power of Java"

の部分です。ここまでをまとめると、「GroovyはJavaによく似たシンタックスになっていますが、簡略化してあってJavaよりもかなり少ないルールで済みます。このシンプルさはJavaの持つパワーすら越える能力があるといえるでしょう」となり、これをサンプルコードを使って補強説明しています。

さて、この部分ではGroovyをコンパイルするとJavaのバイトコードになる話にも触れられていますが、あえてここは取り上げませんでした。というのは、ここはGroovyのシンプルさを訴えるべきところで、バイトコード関連の話題は別途取り上げるべきトピックだったからです。一般に技術文書の書き手は詳しい機能、能力までもよく知っているのでつい色々と書いてしまいがちですが、トピックからそれる話題は読み手を混乱させ、一番言いたかったところがぼやけてしまう結果になりかねません。そのような部分を読み飛ばすと同時に文章を書くときには注意したい点です。

今回は、要約するときの心構えとannotating、そしてまとめの例を挙げましたが、参考になったでしょうか。例に取り上げた文章はかなり長く、続きがあるので、次回は実際にどのようにannotatingとまとめを行い、要約を作るのかを取り上げたいと思います。