Stanford大学流科学技術論文の書き方

研究論文の書き方は重要にも関わらず研究室で体系的に教えられることはほとんどない（と予想される）．従って個々人で情報を集める，書籍を購入するなどして論文執筆能力を向上させるしかない． 論文の書き方に関するウェブページ，書籍などは探せば色々見つかる．以下に僕が実際に参考にしているものをピックアップしておく：

以下は，Stanford大学InfoLabのJennifer Widom氏が公開している”Tips for Writing Technical Papers“の日本語訳である．日本語は稚拙であるし誤訳も散見されると思うが，いつか役立つだろうということで掲載しておこうと思う．

 

科学技術論文を書くためのTips

2006年1月 Jennifer Widom

これは2006年1月27日に スタンフォード大学のInfoLabの金曜日ランチで行ったプレゼンテーションのメモであり、2009年12月4日に同じ内容を話したときに付け加えたメモも含まれている．プレゼンテーションの内容は以下の通りである：

  • 論文のタイトル
  • アブストラクト
  • イントロダクション
  • 関連研究
  • 本文
  • 評価実験
  • 結論
  • 今後の課題
  • 謝辞
  • 参考文献
  • 付録
  • 文法と細かい表現方法に関して
  • 技巧
  • 編集履歴と配布方法

説明に用いる例題

ここでは説明に用いる（架空の）例題として，あなたはExternal multipassマージソートに関する新しいアルゴリズムを開発して評価実験を行った，と仮定してみよう．提案アルゴリズムは結果中にある正しく並べられていない箇所があることをある程度許容するという前提を置くと，計算量をO(n log n)からO(n)に押さえることができる．今からあなたは結果をまとめて主要国際会議に投稿する計画を立てる．

注意: この例題は生講演中に使った例題であるが，メモ中では詳しく触れなかった．それゆえ，読者のために練習問題をいくつか添付しておいた．

論文のタイトル

タイトルの書き方として考えられるのは…まず長くて説明的なタイトル：

  • Linear-Time External Multipass Sorting with Approximation Guarantees

もしくは短くて簡潔なタイトル：

  • Approximate External Sort

以下で示したのは中間くらいの長さで頭に残るような格好いい名前が添えられたタイトル：

  • Floosh: A Linear-Time Algorithm for Approximate External Sort

アブストラクト

取り組む課題，それに対するアプローチと解決策，論文の主要な貢献を述べること．研究の背景や動機はほとんど書かないようにすること．事実に忠実にかつ分かりやすく書くように心がけること．アブストラクトで使った表現を論文の本文中でそのまま繰り返して用いるべきではない．

（練習問題： Multiwayソートの例でアブストラクトを書いてみよう）

イントロダクション

イントロダクションは極めて重要である．査読者はイントロダクションを読み終えるまでには、論文を受理するか否か最初の判断をたぶん行っている——その判断を固めるための証拠探しという意味で査読者は残りの章を読むものだ．一般の論文読者の場合は，緒言を読んで面白いと思えば論文を読み続けるし、面白くなかったら論文を読み終えるものだ。念を押して言っておくが、緒言は極めて重要だ。

ここではStanford InfoLab流のイントロダクションを構成する5つの骨子について記す．これに反論する十分な理由が無いのであれば、イントロダクションは以下の5つの質問に答えるように5つの段落で構成すること：

  1. 問題は何か？
  2. なぜその問題が興味深くかつ重要なのか？
  3. なぜその問題を解くのが困難なのか？ （例：なぜ単純なアプローチではうまく解けないのか？）
  4. なぜ今までその問題は解決されてこなかったのか？ （もしくは，既存手法の何が悪いのか？提案手法と既存手法との差異は何か？）
  5. 提案アプローチの重要な要素は何か？それを用いた結果はどうだったのか？ 特定の制約条件についても全て述べるようにすること．

（練習問題：Multiwayソートの例題に関して上の質問に答えてみよう． ）

これを書いた後に，最後の段落もしくは最後のサブセクションとして「論文の貢献のまとめ（Summary of Contributions）」を書く．このパラグラフでは論文の主要な貢献をについて箇条書きでまとめること．そして各内容について記述した章番号も添えておくこと．この箇条書きリストは論文の構成を示す役割も兼ねているので，スペースの削減や冗長性の排除にもなる．

（練習問題： Mutiwayソートの例題に関して貢献のまとめリストを書いてみよう．）

関連研究

いつもされる質問：関連研究の章は論文の始めの方に書くべきですか？それとも終わりの方で書くべきですか？

始めの方に書くケース：

短いが十分詳しく関連研究を書くことができるケース，もしくは既存研究に対する優位性をすぐに示しておくことが重要ななケース． このようなケースでは，関連研究はイントロダクションの章の終わりにサブセクションを設けて書くか，第2章に関連研究の章を設けて書くことができる．

終わりの方に書くケース：

関連研究について（イントロダクションや導入の章で）早い段階でさっと簡単にまとめられる場合，もしくは提案手法と関連研究を比較するのに論文中で述べている技術的な内容を理解する必要があるケース．このようなケースでは，関連研究は結論の章の直前に章を設けて書くべき．章のタイトルとしては「考察と関連研究（Discussion and Related Work）」というより一般的なタイトルを付けることもありえる．

本文

ガイドライン#1： 3ページ毎に新しい重要な技術的貢献を明示すること（つまり，ページ総数がNページの論文の場合N/4ページ毎に）.

ガイドライン#2： 論文中の全セクションで”語る”ようにすること（しかし決して結果に至った全過程を語ってしまうというありがちな落とし穴にはまってはいけない．結果のみを語るようにすること）．お話には一連の流れを持たせ，どの章でも読者を惹き込むようにし，話の続きが読みたくなるように心がけること．読み進めるのに大きな支障になるようなものは本文中に書くべきではない——そういうものは付録に回せる．付録に関しては下を見ること．

このガイドラインはあらゆる論文に使えるのだが，それはさておき，本文の骨組みは論文の内容によって大きく変わる．以下に重要な要素を挙げる：

  • 例題：可能ならば，本文を通じて用いる例題を一つ用意すること．例題はイントロダクションの最後にサブセクションを設けるか，もしくは2章または3章（関連研究の章に依存）を設けて導入するかが考えられる
  • 導入：導入の章はイントロダクションの後か場合によっては関連研究/例題の章の後に設ける．導入の章では，論文の技術的貢献にはあたらない表記方法や専門用語に関する定義を行う．この章の重要な役割は，提案事項ではないが論文を通じて必要となる項目を詳細に説明することにある．簡潔に書くこと——重要な経験則として覚えておくこと．
  • 内容：論文の要点にはアルゴリズム，システムの説明，新しい言語の設計，分析等が含まれる．可能であるなら常に”トップダウン”に内容を書くこと：読者が話がどういう風に展開されるかが分かるようにすること．また読者が論文を読み飛ばしても内容が理解できるようにすること．

評価実験

このトピックによってのみこそ完全な論文というのが成立すると言えるのだが．私が評価実験の専門家ではないのは確かだ．以下に個人的な考えを適当に並べてみた：

  • 多くの学会で実験の章が求められている．
  • “ホッケー”や意味のない実験をやってみるのは簡単だ．大抵の論文がそうしている．
  • 提案手法がうまく機能しているように見せかける実験をすることも簡単である．大抵の論文がそうしている．
  • 評価実験ではどんな項目を評価すべきか？候補は以下の通り：
    • 実行時間
    • 重要なパラメータの感度
    • データの大きさ，問題の複雑さ（計算量）など様々な観点に関するスケーラビリティ
    • その他？
  • 評価実験ではどうやって結果を見せるべきか？候補は以下の通り：
    • 絶対的な性能（例：許容可能性，有用性）
    • 単純な手法と比較した場合の相対的な性能
    • 既存手法と比較した場合の相対的な性能
    • 複数の手法を提案して各手法を比較した場合の相対的な性能
    • その他？

結論

一般的に，結論の章では論文の内容を一段落で短くまとめるものであるが，結論の章では必ずアブストラクトやイントロダクションで用いた内容を単純に反復するすべきである．場合によっては、例えば定量的な実験結果を書くなどして，アブストラクトやイントロダクションで書いた主張をもっと具体的に書くことも考えられる．

今後の課題

今後の課題の章は重要である——提案内容によって新しい研究の方向性がどのように定められるのかを提示することも論文の意義の一部である．ここでは私の好きな箇条書きを使って説明する． （実際いつでも私は箇条書きを好んで使う．）留意点は以下の通り：

もし積極的に研究を継続しているのであれば，例えば次のように述べておく．例：「我々は現在提案したアルゴリズムを拡張して○○しようとしており，予備実験では良好な結果が得られている．」こういう記述をすることで自分の研究領域に唾をつけておくことができる．

逆に，一部の研究者が研究ネタを探すために”今後の課題の章”を見ていることも意識しておくこと．個人的な意見としては，そうやってネタを探すことは悪いことではない——補足事項として考えておくこと．

謝辞

謝辞の章は忘れてはいけない．忘れた場合，傷つく人々が出てくるだろう。どんな形であれ論文に貢献した人には謝辞を送るべきである．例えば，議論に参加してくれた人，論文の原稿にコメントをくれた人，実装をしてくれた人などである．謝辞に入れるべきか迷う人がいる場合は入れておきなさい．

参考文献

引用した参考文献リストは完全な情報を載せ，誤りがないように手間をかけろ．でたらめで不完全なBibTexテキストをウェブから引っ張ってきて貼り付けて終わりにするな．最終的な参考文献リストは綿密にチェックして，全参考文献に間違いがないかを確認しろ．

付録

付録の章には詳細な証明とアルゴリズムのみを書くようにすること．付録を付け加えることでページ数の上限を超えてしまう可能性があるが，それでも付録は有用である．付録とは隠れていた細かくて嫌なことを直接的に明記してあげる章だと思いなさい．以下に経験則を記す：

  • 論文の提案内容を理解するための必要事項は付録に含まれていないようにすること
  • 読み手の大半が興味がない事柄は全て付録に含めるようにすること

文法と細かい表現方法に関して

論文を書く皆さんにはStrunkとWhiteが書いた”The Elements of Style”を読んでみることを強くお奨めしておく．この本は短いけれども非常に有用な本だ．イライラの種となる事項を以下に適当に並べておく．

  • プログラムと同じように，論文中で登場する全ての”変数”（新たに定義した言葉や表記方法）はそれが使われる前に定義しておくこと．定義するのは一度のみにしておくこと．（例外：だいぶ間が開く場合には，読者に定義を再度示してやることが有効なこともある．）論文全体を通じて使用する定義については導入の章で説明しておくべきである．他の定義に関しては最初に使う時に定義用にすること．
  • 列挙する項目が分かりきっているのであれば「等（など）」という表現は使わないこと．
    • 良いケース: 我々は1, 3, 5, 7…の位相に番号を割り振ることにする．
    • ダメなケース: 我々は不安定さやスケーラビリティなどのような要因を測定する．
  • 「様々な理由のために」という言葉を絶対に使わないこと．（例：我々は様々な理由のために代替案を考えないことに決めた．）理由はきちんと読者に伝えるようにしろ！
  • 「これ」「あれ」「これら」「それ」などの指示代名詞を使わないようにすること（Ullman先生のイライラの種）．論文を明快に書くには「これ」という言葉が指す内容を明示して書くことが必要．「これ」という指示代名詞に参照しているものがない典型例を挙げる： 実験では幾つかの異なる環境下で行われ，提案アルゴリズムは全ての環境下ではうまく機能しなかったが，一部の環境ではうまく機能した． これは非常に重要なことだ．なぜなら…

（練習問題： 上で述べたルールがこのメモ中で少なくとも一回無視されている．それを見つけなさい． ）

  • イタリック体は定義，引用に用いること．強調用途に用いないこと（Gries先生のイライラの種）．（装飾技巧を使わず）コンテキストだけで十分な強調効果が得られるように論文を構成すべきだ．

（練習問題： 上で述べたルールがこのメモ中で少なくとも一回無視されている．それを見つけなさい． ）

  • 関係詞”that”を用いるべきなのに”which”が誤って用いられることが度々ある．関係詞”that”は限定的用法として用いるのに対し，”which”は非制限的用法として用いる．正しい用法の例を以下に挙げる：
    • The algorithms that are easy to implement all run in linear time（実装が簡単なアルゴリズムは全て線形時間で動く）.
    • The algorithms, which are easy to implement, all run in linear time（それらのアルゴリズムは容易に実装でき，全て線形時間で動く）.

技巧

  • とにかく最終原稿では常にスペルチェック機能を走らせておくこと．
  • 原稿や技術報告レポートではフォントのサイズは11ポイントを使い，スペースも多めに取り，行間も1行余分取って，1カラムフォーマットで書くこと．最近の論文フォーマットのフォントは小さいしスペースも狭いが，それをそのままを使って論文をチェックしてくれる人を苦労させる必要はない．
  • 原稿や最終的なカメラレディでは，図中のフォントが本文中のフォントよりも小さい，ということは無いようにすること．
  • 表，図，グラフ，アルゴリズム（の擬似コード）は常にページの上部に配置すること．どんなに小さくものでも，論文からはみ出てしまうものでも，本文中に配置しないようにすること．
  • テーブル，図，グラフ，アルゴリズム（の擬似コード）はそれを参照しているページ内もしくはその次のページに載せるようにすること（LaTex様次第だが…）．
  • 最終バージョンを投稿する前もしくは論文が出版される前には，一度執筆したものを印刷し実物を見てみること——（最後のLatexコマンドを実行した後にわざわざ印刷してみてみると…）PCの画面上と紙面上で見えるものとの違いにびっくり！ということもあるかも．

変種履歴と配布方法

多くの論文には，最終的にウェブで公開される”フルペーパー”と呼ばれる技術報告書に加えて，国際会議に投稿する段階（その後のカメラレディを提出する段階）のバージョンが存在する．論文の編集履歴を丁寧に管理しておくことは内容を更新する上でも論文を普及させる上でも重要である．私が推奨する方法は，可能なら常に会議投稿時の原稿と付録のみからフルペーパーを構成するようにすることである．フルペーパーは国際会議の論文集から独立させて公開しておき．論文は最新（最終）投稿バージョンと同期（連携）するようにしておき，フルペーパーへの修正が常に公開されている旧バージョン全てに反映されるようにしておくべきだ．

私の考えでは論文を書き終えたらすぐにウェブに置いてみれるようにすべきだ．このような論文には日付を付けるようにすること．そうすれば技術報告書（テクニカルレポート）として引用できる——アップロードする論文は実際に技術報告書としてIDを持っている必要はない．ただし，絶対にウェブにアップロードするときに会議のコピーライトは消しておくこと．また「国際会議Xに投稿した」というような記述も絶対に載せないこと．1，2年後最終的に国際会議Yに論文を投稿するときにきまりが悪くなるだけだ．

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。