論文を書いて「査読付き国際ジャーナル」に通すために心がけるべきこと（時系列）
査読ありの論文媒体（国際ジャーナル、国際会議）に論文を通すまでの一連のプロセスの中で「気をつけたほうがいいこと」や「心がけるといいこと」を、箇条書きにしてまとめました。
対象読者:
・大学院生（修士課程1年〜博士課程前半）
・1本目か2本目の主著論文を書こうとしている人
・研究の進め方について迷走している人
（私自身がこれまで指導教員をはじめとする周囲の大人たち (senior people) からもらったアドバイスが主です。初心に立ち返るための備忘録でもあります。分野としては情報科学、特に理論寄りの研究を念頭に置いて書いていますが、多かれ少なかれ、どの分野にも当てはまるのではと思います。）
1. 研究を進めるうえで常に大事なこと
大原則: 他の人の論文を見て（体裁や構成や書き方などを）真似る。
他の論文と、似た見た目になるように書く。他の人の論文を横に置きながら、自分の論文に足りないところがないかを確認する。
「どうすればいいか困ったときにヒントを求めて他人を真似る」だけでなく、「そもそもやるべきことに気づけていない」ケースも十分ありうるので、他人のものと並べて違いがないかどうかをチェックする。
研究の進め方: 探索 (exploration) と活用 (exploitation) のバランスをとる。
「深さ」と「幅」、両方のバランスを取ろう、という話。（元ネタは、機械学習で知られている「多腕バンディット問題」(multi-armed bandit problem) の考え方。）
具体的には: （研究を始めたての頃であれば）論文を書き進めながら、関連する論文（あるいは「関連するかもしれないが関連しないかもしれない論文」くらいがもっとよい）も読む。
研究サイクルを回す速度について
修士課程の1年目なんて「研究アイデアを出す速度」は人生最高速度のうちの100分の1とか1000分の1くらいしかないので、これからどんどん出せるようになればいいし、最初のうちはゆっくりでいいから、とにかく考えた過程をたくさん書き留めてひとつひとつじっくり進めていくのがいい。
研究の大原則: できるだけ研究室に出勤するのがおすすめ。
他人の顔を見るのは力。
昼夜逆転していても、オフィスで寝る気で来る。
研究の進め方のコツ: とにかく TeX を書く。
(理由1) プロとしては、output を出してなんぼ。
…… という意識を、実際の作業に落とし込む。(理由2) 論文らしきものが育っていくと気持ちが良い。
研究者の QoL には、モチベーションと報酬感が大切。
特に理論研究者の場合、研究成果（論文）だけをモチベーションに据えて研究すると、だいたい目立った成果は数年に1回しか来ない・いつ来るかわからないので、QoLが下がりがちだし病みやすい。もっと短いスパンで、毎日の収穫をちゃんと噛み締めて、やりがいを見つけるとよい。
(理由3) 書いたものがあると議論が早い。
これがないと「相手の脳内から情報を引っ張り出す」ことに時間がたくさんかかってしまう。
定義を書き下す、アイデアを書き出す、など、小さなこと・書きやすいところから始めればよいので、書いて蓄積する習慣をつくる。そして、「これを見れば何でも書いてある・他人が見てもわかる」くらいの self-contained なドキュメントを育てていく。
Write more than less.（分量はあまり気にせず、たくさん書くのがいい。とにかく全部吐き出す。後から削るのは簡単だが、後から増やすのは大変。）
少しでも何かわかったら、未来の自分向けにメモを残す。「このメモを見たら他人が理解できる（よって未来の自分も理解できる）」が理想。
こういう、他人に渡しても誰でも読めば理解できる（それゆえ数ヶ月後の自分が読んでもちゃんとわかる）self-contained なドキュメント（いわゆる「手離れがいいドキュメント」）を作ることは、理論研究者にとって重要。人に説明するときに役に立つ。
加えて、TeX で書いておけば後々 bibtex などの手間も省けて後々楽。
手持ちの材料が散逸しないように、常に整理するよう心がける。
新しいサーベイも大事だが、「散らばっている材料を一箇所に集める」にも重点を置いて、材料集めをする。
たとえば以下の材料（URL等）を整理する（普段ミーティングの記録をつけている Google ドキュメント内の目立つところに集約して貼っておくのがよい）:
論文 draft の GitHub レポジトリへのリンク、投稿先の論文媒体の Call For Papers へのリンク、これまでの議論のログ（Google ドキュメント、ウェブ上のホワイトボード、読んだ論文のメモ、etc.）、関連する以前の論文・スライド・報告書、……など。古いものも含めて、完全に内容が override されたわけでなければ、すべて一箇所に集めて貼っておく。
一日一回（最後か最初）に、一日やったことをまとめて work log を書く習慣をつくるといい。やったことの詳細を書き出す。
例: 「どこまで読んだ、勉強したキーワードはこれ」
例: 「nLab のこのページを読んだ、わかったことはこれ」
2. 準備段階でやるべきこと
最重要事項: authorship order で揉めない！
コンピューターサイエンスの場合、authorship の並び順は、貢献度合いを表すなど、重要。（他の分野だとアルファベット順のこともあるらしいが。）ここで揉めるといちばん大変なので絶対に避けたい。
揉めないためには、共著者たちに早い段階で、「このアイデアを思いついたのは私です。なので、今回は私が主著で論文を書きます。もし今後、共著者の中で他の人がより良いアイデアを思いついたとしても、それは次の論文の題材にしましょう。今回の論文に関しては、私が主著であることを覆さないことに決めましょう。」と宣言しておく。
加えて、日頃からミーティングログにすべての内容を記録しておき、「ここに書いてあるものだけがすべてです、ここに書いていないことは言っていないものとみなします」とするのもあり。（理論研究における「実験ノート」のようなもの。）
著者・役割分担を決める。
メイン著者: 実働（理論・実験）
共著者1: 専門性を活かした助言（理論）
共著者2: 専門性を活かした助言（実験）
……など
Target venue を決める。
参考: 論文のランク（コンピューターサイエンスの場合）
Etienne Andre さんのリスト
https://www.conferences-computer.science/
CORE ranking
https://portal.core.edu.au/conf-ranks/A, A*: いわゆるトップ会議
論文の構成（章立て）を、わかる範囲で書き出す。
章立てを作る意義: 「進んでいる実感があると頑張れる」「残り作業量が見えないと不安」
章立て:
To-do を並べるイメージ。何をやったら終わりかがわかる。（章立てがないと、「残り作業項目が8個ある」→「8は人間の短期記憶の容量を超えている」→「よって残り作業項目が無限個あるのと同じ」→「不安で寝込む」ということになる恐れがある。）
参考: 「パラレルに取り組むタスク数は 2〜3 まで」…… これを超えてマルチタスクしようとすると処理能力が低下する。
To-do の優先度付けをする。
GitHubリポジトリの管理・運用のしかた
フォルダの整理をする。（数年後に見たときに、どれが本物で、どれが trial なのか、などがわからなくならないように。）
.gitignore を使う（.aux, .bbl などの一時ファイルは格納しない。）
ちなみに、生成される .pdf も一時ファイルと見なす考え方もあるようだが、数年後に見返すときのことを考えると .pdf は ignore しないほうがいい。
3. 書く過程での工夫や注意点
論文を書く順番について:
まずは、書きやすいところから書いていく。
たとえば、理論の基礎的定義 (Preliminaries) など。
書き進めていくうちにわかることがある。
章構成を練り直すのは、割と後から考えればいい。
イントロは、基本的に最後に書く。
あるいは、「技術的なところを6割くらい書いた ⇒ イントロでストーリーをつくる（テンションを上げて頑張って書く） ⇒ 残りの技術的内容をそのストーリーに基づいて書く」もあり。（経験者向け）
最初の1段落を書き始めるのが一番大変。
対処法: 他人を使う。
（例）「今から書くので、横で見ていてください」
（例）「今から書くので、見ていなくて良いので、横で仕事していてください」
Write more than less. 分量はあまり気にせず、たくさん書く。
（理由1）後から削るのは簡単だが、後から増やすのは大変。
（理由2）そもそもはじめのうちは、学生が書いたものは基本的にそのままでは使い物にならない（これは優秀な学生でもみんなそう）。シニア（料理人）が取捨選択できるように、とにかく材料を並べることに専念する。（これをしておかないと「指導教員が学生の頭の中に分け入る」「脳内から情報を引っ張り出す」時間が必要になってしまい大変。）
書くごとにこまめに自分の書いたものを読み直す。（1文書いたら読み返す、1行書いたら読み返す、1パラグラフ書いたら読み返す）
自分が書いた文章を書きっぱなしにせず、常に「他人の目」のつもりでチェックする。
「書く → 記憶を消す → 他人の目で見直す → 書き直す → …」のループを回す。
単に誤字脱字やタイポに気をつけるだけでなく、「これを定義する前に、先にこれを定義しておかないといけない」「先にこの話を説明しておかないといけない」「先にこの notation を導入しておかなきゃいけない」などに気づく。
添削 (senior check) について
最初の論文は、writing メンターを1人つけてもらい、一語一句を一緒に直すのがよい。
「直してもらってよかった」でなく、博士号をとる頃までには同じことが自分1人でできないといけないので、ルール・原則を自分で抽出して、身につける。
コツ: 論文の中に出てくる主要な登場人物（概念など）には名前をつける。（そうすれば、長々といちいち説明しなくて済み、説明が短くなる。）ちゃんと名前をつけて、その名前で呼び続ける。
例えば、「〜 principle」、「〜 argument」、「〜 statement」「〜 case」など、考えたいものに対して名前を与える。
うまい名前をつけるためには、その対象がどんなものであるかについてちゃんと本質を掴んでいる必要がある。なので、名前をつけるのはけっこう難しい。
考え方: proof-search と proof-check について
読み手からすれば、proof-check さえできればOK。
他方、3ヶ月後に自分が書いたものを自分で読み直す際に、どういうことだったかわからなくなってしまわないように、自分用のメモを残すことも大事。
auxproof 環境などを使ってメモを残しておくとよい。
Preliminaries の書き方
とりあえず、後で必要になりそうな定義（と補題・命題など）を並べていく。
必要に応じて追加で書く。「あとの Section を書いているときに place holder を足す」ということがたくさん発生するはず。
Structuring （「なにが subsection？」みたいな）は、後で考える。
「ここで言うべきか、あとで言うべきか」も、後で考える。
細かい点
LNCS スタイル（コンピューターサイエンスの論文のLaTeXスタイル）
DBLP（コンピューターサイエンスの参考文献データベース）文献の pdf や bibtex は、ここから取ってくるとよい。
定義するものは \emph で書く。
such that は、論文の本文中では s.t. と省略するのはダメ。
「〜と同様に」は much like 〜 を使う。(as well as 〜 は and と同じ「並列」の意味なのでダメ。)
関係代名詞は基本的には which 〜 よりも that 〜 を使うほうがいい。
Conclusions and Future Work（conclusion は可算名詞なので -s をつけるが、future work は不可算名詞なので -s をつけない。）
参照は \cref を使う。
図表は tbp にする！（この tbp は呪文のようなものなので、気になったら自分で調べるとよい。）
\begin{figure}[tbp]
\centering
\includegraphics[width=\textwidth]{fig/〜〜〜.pdf}
\caption{〜〜〜〜〜〜〜〜}
\label{fig:〜〜〜〜〜}
\end{figure}よく使う記法は \newcommand で定義してしまうとだいぶ楽。
\newcommand{\Coalg}{\ensuremath{\mathrm{Coalg}}}
ひとまずの目標は「即死回避版」をつくることを目指す。
「即死回避版」とは、完成度・細部の推敲などはともかくとして、とりあえず中身と体裁は一通り揃っていて、即死にはならない程度の draft のこと。
徐々に完成に近づいてきたら、論文進捗状況を表にして可視化する。
縦軸: sections
横軸: technical material, draft, senior check
各セルに、緑、オレンジ、赤、などで進捗状況に応じて色を塗る。セルの中に「あと何をやればいいか」を書き出す。
締め切りに向けて
直前まで溜めてしまう「締切駆動型」の人のコツは、「マイ締め切り」を設定すること。「いったんこの期日までに完成させる」という自分なりの締め切りを作る。
論文は、締め切り1ヶ月前に「締切だと思ってやる1週間」を作るとだいぶラク。
たとえば「本当の締め切り前の〇〇日までに原稿を書くのでチェックをお願いします！」と言う。
「他人のためにやる」が力になる。
とはいえ、ギリギリまで粘り続けて、できるだけクオリティを上げようとすることも大事。（国際ジャーナルや国際カンファレンスの論文提出の締め切りはだいたい AoE で定められていることが多いので、日本時間だと 21時。締め切りまで粘って無事に投稿し終えたら、同じ締め切りを乗り越えた仲間たちと一緒に酒を飲みに行くとよい。）
ページ数オーバーへの対処
投稿直前は、これまで "Write more than less"（上述）の精神でたくさん書いて規定のページ数をオーバーしたぶんを、とにかく削る作業。どうにかページ数に収める。
（図を小さくする、定理の証明などを Appendix に移してポインターを貼る、最終手段: 2〜3単語だけはみ出ている行があれば書き方を変えて行を減らす。）
4. 論文投稿後の rebuttal をどう書けば採択率が上がるか
大原則: レビュアーと戦わない。レビュアーが点数を上げるための材料をこちらが提示する。
「口喧嘩」ではなく「採点の再検討を促す」。強い言葉・皮肉・責める口調は、内容が正しくても逆効果になりやすい。丁寧に・控えめに・でも明確に。
例: 「あなたのレビューは間違いだ」ではなく、「こちらの説明不足で誤解が生じた」という形に変換して提示する。
コツ: （質問を順番に全部処理するのではなく）最初に主要なポイントをまとめて書く。
レビュアーは短時間で全体の印象を更新するので、序盤で「誤解が解けた」「核心が分かった」と思わせるようにする。
細かいQAをダラダラ並べると、「結局どこが大事なのか？」と思わせてしまう。
コツ: 点数を上げるためのコメントとして、レビュアーがそのまま使えるような（コピペ可能な・具体的で明確な）文章を、レビュアーに渡す。
例: 「新規性はAであり、既存のBとはCが違う」
例: 「最終版では評価Eを追加し、主張Xを実験で裏付ける」
レビュアーの労力に対して「論文が良くなった」という形で応える。
小さなこと: 直す。
大きなこと: 直しようがないこともあるが、それでも「コメントを受けて何らかの形で良くする」。（ここは経験が役立つ場面なので、共著者に「どう対処しましょうか」と聞くとよい。）
5. もしも reject されてしまったら
まずは、次に向けて気持ちを切り替える。
「1週間寝込む」ことがないように、できるだけ外に出る・他人と会う、などをする。
「論文としての価値はちゃんとあるが、たまたま出した媒体が合っていなかった、うまく評価されなかった」というケースもあるので、気にしすぎない。（低い評価をつけた査読者の中にも、良いところは部分的に評価してくれていることもある。）
ちなみに、後にたくさん引用される重要論文は、最初は新しすぎるために査読者からあまり高く評価されずトップ国際会議には通らず、2番手の国際会議くらいで発表されることも割と多い。
次に出す締切・媒体を決めて、それまでにできるだけ良くする。
ワンランク下げてでもなるべく早めに通すか、材料をもっと補強して同等レベルのカンファレンスに再チャレンジするか、決める。
6. 査読後・提出前の仕上げ・camera-ready
Appendix のさばき方。提出版とArXiV版を両方作る。（ただし Appendix への \cref が残っているとエラーが生じるので消す。）
1つの TeX ファイルで、提出版とArXiV版をすぐにスイッチできるようなコードをプリアンブルに書いて自動化する。（提出版からArXivに飛べるように。これも自動化。）
例）\FinalOrArxivVersion{投稿版}{ArXiv版} でスイッチする仕組み。
ArXiVの公開には時間がかかる（だいたい2日くらい）ので、いったん仮で出しておいて、後で最新版をアップするのがよい。
ArXiv 版と提出版の両方を見比べて差分をチェック。
著者たちの grant 情報を集める。
共著者にメールを送って確認する。（たたき台があると良い。著者それぞれの最近の論文を見て funding 情報を抽出し、「これとこれがあると思うのですが、他にはありますか。もしあれば教えてください。」という言い方をすると、共著者の負担が減る。）
グラント情報が集まったら、最終確認のためのメールを送る。
おまけ: 1つのTeXファイルで提出版とArXiv版をすぐにスイッチできるプリアンブル
以下に書いた通りにやれば、誰でもできます。（おすすめ）
ステップ1: 本文中の細かい箇所の扱い方
まずは、プリアンブルに以下のコードをそのまま貼り付けましょう。
% UNCOMMENT THE LINE BELOW TO GET THE FINAL VERSION
\def\VersionFinal{} % ここをコメントアウトするとArxiv版に切り替わる
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% FINAL/NOT FINAL (ArXiv) VERSION
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\ifdefined\VersionFinal%
\newcommand{\FinalVersion}[1]{#1}
\newcommand{\ArxivVersion}[1]{}
\newcommand{\FinalOrArxivVersion}[2]{#1}
\else
\newcommand{\FinalVersion}[1]{}
\newcommand{\ArxivVersion}[1]{#1}
\newcommand{\FinalOrArxivVersion}[2]{#2}
\fiそして、論文の本文中で、投稿版とArXiv版で差分をつけたい場所では、以下のコマンドを使って書きましょう。
\FinalOrArxivVersion{投稿版に書きたい内容}{ArXiv版に書きたい内容}ステップ2: Appendixのさばき方
まずは、プリアンブルに、先ほどの「ステップ1」のすぐ下のあたりに、以下のコードをそのまま貼り付けましょう。
\usepackage{comment}
\ifdefined\VersionFinal%
\excludecomment{ArxivBlock}
\else
\includecomment{ArxivBlock}
\fiそして、論文の Appendix 全体を、以下のコマンドで囲みましょう。
\begin{ArxivBlock}
... Appendix
\end{ArxivBlock}ステップ3: 提出版とArXiv版の切り替え方
先ほどのプリアンブル中の \def\VersionFinal{} の行をコメントアウトしてから .tex ファイルを保存し、再度コンパイルすると、いっせいにArxiv版に切り替わります。
以上です。
コメント