まず、コンピューター系の論文の書き方のHow toを示した書き物として、DB分野で有名なJennifer Widomの以下の記事が、良い指針となります:
- Tips for Writing Technical Papers (Jennifer Widom)
- What is the problem? (解いている問題は何?）
- Why is it interesting and important? (なぜその問題が面白くて重要なの？)
- Why is it hard? (その問題のどこが難しいの？ 簡単な方法で解けないの？）
- Why hasn't it been solved before? (なぜ今まで解かれてなかったの？)
- What are the key components of your approach and results? (あなたの仕事のどこが重要なの？）
論文査読では、自分と同じ専門分野の人に巡り会えることは稀です。むしろ専門外の人に読まれるのが通常で、あうんの呼吸で問題が伝わる、なんて信じることに意味はありません。皆がコンピューターに触れるようになって、コンピューターサイエンスの分野も相当広がってきました。それに伴い、論文と同じ研究テーマに洞察の深い専門家に当たる確率も相当低くなっています。XMLの論文だからXMLに興味がある人向けに書く、ではなく、コンピューターサイエンスをかじった程度の人でも、abstractを読んで「XMLにはそういう性質があるのか、なるほど。面白そう！」と思えるように説明するのが大切です。上に挙げた５つの項目がintroductionで綺麗に説明されていない論文は、僕が査読した論文や、自分が過去に書いた論文も含めて、十中八九、いい論文（つまり読みやすい論文）にはなっていません。introduction以降の文章はろくに読まれないか、書いた本人の意図やアイデアがうまく伝わらず、見当違いの評価が返ってくるのが落ちでしょう。
2. コードを練るより先に、伝えるべきことがある
コンピューターサイエンスの分野においては、良いものを作るのはもちろん大事なのですが、そこから「良い論文を書く」までの間には相当な壁があります。日本では、この「良い論文を書ける」域に達している人が、欧米、さらにアジア圏内で見ても、圧倒的に不足しています。DB分野では既にシンガポールの方が論文を書く力は日本より優れているようです。技術的には、日本人でも、アルファギークと呼ばれるプログラマが多くいたり、未踏ソフトウェアでスーパープログラマと認定される優秀な人がいますが、必ずしも彼らが研究の世界でプレゼンス（存在感）を発揮しているわけではありません。(DBLPから氏名を検索すると活躍の度合いがわかると思います）
この壁の正体は何か？ コードを書ける人が陥りがちなのが、文書よりもコードを改善してしまうという罠です。作りあげたコードには、いろいろなノウハウや、論文に書ききれないくらいたくさんの最適化のための改良が施されていることでしょう。うまくいけば、決して他の人には作れないユニークなものが出来上がります。でも、ちょっと待って！論文は人に技術、アイデアを伝えるために書くもの。そんな人が真似できないものを作ってどうするの？
システムが複雑で、性能評価にいろんな要素が入ってくるほど、他の人が利用できない（つまり後続が現れない）研究になります。オープンソースの世界と同じで、研究の世界でも、人に面白い問題、アイデアを提起してあげると、あとは周りが勝手に問題を読み取って、後続研究が広がります。そんな動きを触発するには、コードを練るのと同じか、あるいはそれ以上に文章を練ることが大切です。アイデアを一番伝えられるのは、何よりもまず文章です。
３. 良い文章とは、悪い文章を書き直したものだ
最初から良い文章を書くことの難しさは、物書きなら誰もが直面する課題ではないでしょうか。良い文章がすらすらでてくる人が天才なら、そうでない自分は物書きには向いていない。そのような思考に陥りがちだった僕を十二分に救ってくれたのがこのフレーズです。
引用元のGood Writing by Marc H. Raibert には、文章を書くテクニックというよりは、書くために必要な心構えが記されています。kunishi先生のブログでも紹介されていますが、そもそもRaibertの文章そのものが、"Good writing is a bad writing that was rewritten (良い文章とは悪い文章を書き直したものだ)"の実例となっているのですね。
４. 書いた文に振り回されるくらいなら、思い切って捨てなさい
これも上のRaibertの記事から。文章を書いていると、とても良い文が書けたと思うことがあります。ただ、書き進めていくうちに、その文が周囲の文章と合わなくなったり、伝えたいことと内容が離れてしまうことがあります。でも、せっかく書いた名文は生かしたいというのが人情。
そんな文章の断片があちらこちらにでてくると、頭の中では文章という複雑なパズルのピースを組み合わせる作業が始まってしまいます。文章のニュアンスであり、既に説明した情報であり、いろんな要素を頭の中で組み合わせて文章を書くことになります。プログラムを組み立てるときも似たようなことが起こりますが、文の与える印象の方がより抽象的な部品なので、相当難しいパズルを解くことになります。
そういうトラップにはまったなと感じたら、その名文の部分を思い切って捨てます。さすがに、ただ消し去るというのでは忍びないので、PRIZE_WINNING_STUFF.txt （これは賞を獲れる！）というファイルに貼付けて保存して置きます。パズルのピースが減って、伝えたいことに絞って文章を書くだけでよくなるので、驚くほどの効果があります。必要なら、あとで「賞を獲れる名文」を戻してもいいでしょうが、僕自身の経験で、ここから復活したフレーズはありません…。
PRIZE_WINNING_STUFF.txtは、最終的にほとんど役に立たないにも関わらず、論文を書くときにこれほど役に立つ道具はありません。
5. 良い研究でもシンプルなアイデアでできている
難しい研究に見えても、根本的にはシンプルなアイデアでできていることがほとんどです。論文の格を上げるために、式の定義を小難しく見せる必要はありません。問題解決のアプローチがシンプルであっても構いません。問題を解くことで分野の研究を一歩進める、そしてその成果をわかりやすく伝えることが何よりも大事です。
これを説明するのには教科書が良い例だと思います。教科書というのは、その分野をよく理解した人が、技術の内容を噛み砕いて、わかりやすく説明したものです。その最たる例として、DB分野には、現在のトランザクション管理には欠かせない技術であるARIES (WAL: Write-ahead logging)の論文があります。この論文は、分量も多くDBをよく知っている人でも読みこなすのは大変なのですが、教科書になると１ページで、アイデア自体もとても平易にまとめられる内容です。教科書というのは、元は論文であった知識を短く、かつ、技術を再現するのに十分な情報を持っている文章です。簡単だからといって、重要でないわけではありません。
では、噛み砕けばシンプルなアイデアをいかに論文として仕上げるか？ 重要なのは、シンプルなアイデアを素直に説明できる力にあると考えます。
先ほども述べましたが、日本ではプログラミング能力はあるけど、PhDをまだ取っていない（あるいは取る意思のない）若手が注目を集める一方、グーグルでは、PhDを取得した人を積極的に採用しています。プログラムの力量という意味ではPhD自体は意味を持ちませんが、PhDが示すのは、論文を読んで最新技術の詳細を理解でき、その上で、「新しいものを作り上げる力」を持っているという証です。過去を知らずして「新しいもの」は説明できないし、意図的に「新しいもの」の開発もできないでしょう。「新しい」は常に過去の技術との比較です。過去の論文で、問題がどのように定式化されているかを知っていることも、アイデアを簡単に伝えるためには必要です。
また、アイデアやアプローチがシンプルであっても、対象としている問題が重要で、解くこと、調べることに価値があれば、それは立派に「研究」として成立します。そして、この対象とする問題の重要性を考えることが、冒頭に挙げたintroductionに書くべきこと（問題設定、なぜ重要か、問題の難しさ、過去の研究との比較）に反映されていきますし、introductionを書いたときに、不足している実験が見えてくることもあります。このサイクルが研究の進める上で非常に大切です。
ACMのSIGに代表されるコンピュータ系のトップ会議に論文を通すためには、五十嵐先生の記事にあるように、もう少し努力や工夫が必要なようです。喜連川先生もインタビュー記事で語っていますが、そのようなトップの国際会議では３回くらいrejectされるのは当たり前で、落とされたからといって、がっかりしすぎてもいけないようです。さらに、いい研究ならば２番手の会議はスキップして、トップの会議に出すまで１年くらいsubmitを控える（！）なんてこともあるようです。
最後に、大前提として再びGood Writing by Marc H. Raibert から。
良い論文を書こうと思うこと、そして、書けると信じること
これがなくては、先に進めません。書く力は年をとっても伸び続けると聞きます。あきらめないことが肝心です。
