自分なりの論文の書き方
これは何か
- これまで3本(日本語2本,英語1本)論文を書いた経験を元に自分なりに手順をまとめておく.
- あくまで手順を書き下すのみで,細かいテクニックについては触れない. 合わせて読みたいに参考になりそうな文献をまとめておく.
前提事項
- 筆者はM2の学生.
- 筆者は査読なしの研究会(日本語)と査読付き国際会議(英語)での口頭発表の経験がある
- 筆者は一度国際会議(BDCAT 2019)にshort paperとしてギリギリacceptされた経験を持つ
- 筆者はHPC分野の研究室の人間
- 筆者は深層学習におけるストレージ周りに関する研究が専門
関連研究を読む
- Google scholarとかでキーワード入れて検索する
- 対象のジャーナルや国際会議が絞れるなら過去のproceedingsを直接探す
- 自分の場合,読む論文の優先順位は大体以下の通り
- abstract,conclusionを読んで関連してそうなものを探す
- 見つけた論文はMendeleyとかで管理しておき,いつでもどこでも参照できるようにしておく
- 暇な時に読もう
- 良い論文が見つからないときは素直に指導教官にヘルプを求める
スケジュールを立てる
- 出す会議の締め切りから逆算してスケジュールを立てる
- 24時間作業できるわけがねぇだろ.1日に作業できるのはせいぜい6時間ぐらいで見積もる.
- 人間は見積もりが下手くそないきものである.「自分が直感で立てたスケジュールの2倍が実際にかかる工数である」ぐらいに安全率を取っておくのが無難.
- 土日は休むスケジュールを立てる
- 逆に平日は決めた作業時間は死守する気持ちが重要
研究する
- 研究は基本孤独との戦い
- 他の学生と適度にダベりながらやる
- 孤独を避けるためにも研究室に来て作業する
- 一番の敵は己の心の弱さ
- メンタルを壊さない程度にがんばる
- 毎日日報ををつけると進捗出ている感が出るのでおすすめ
- 淡々と進捗を出し続ける事が重要なので,毎日決まった時間に始め,決まった時間に帰るリズムをキープする
- 深夜に作業するのはテンション上がるけどおすすめしない.体調を崩しやすくなるし,人間は昼間に活動する前提でこの社会はできている.
- 実装について
- バグってて間違った結果を論文に書いてしまうと大変ヤバいので,できればテストを書く
- テスト書いてる暇がない場合でも,動作確認する方法を最初に十分に検討し常に結果が正しいことを確認する
- 仕事と違って人に読ませるコードではないのでコードのメンテナビリティはそこまで重要じゃない.自分が読めれば十分,ということで妥協しつつどんどん進める.
- 仕事と違って研究における実装は「評価結果とセットで初めて価値が生まれる」ぐらいに思っておいた方がいい
- OSSにするのは後からでもできるので,その時に思う存分リファクタしよう
- コードは必ずGitHubかBitbucketなどの外部サービスを利用して管理する
- 性能評価するときのコツ
- 闇雲に計測せず,「何が示せれば自分の主張の裏付けになるか?」をまずしっかり考える
- 自前のtimerコードを挿入して計測してもいいが,profilerが使える場合はprofilerの方がより正確な情報が取れるし変なミスは起きづらい
- print文はできるだけ入れない.性能に与える影響が結構バカにならない(体験談)
- 計測に使うログのフォーマットは後で集計しやすいように最初から整形された状態で出力されるようにしておく
- 自分はログの集計にRを使う事が多いのでCSVにしておくことが多い
- 計測に使ったログは日付,タイムスタンプをファイル名に入れて全部残す
- 計測に使ったログは必ずバックアップを取る
- きびしくなったら素直に指導教官にヘルプを求める
論文を書く
- texのテンプレが指定されている場合はなるべく早く自分の手元でビルドできるかを検証しておく
- 本文は
Motivation
から書き始め,次にMethodology
,Evaluation
,Discussion
を書く- 間違っても
Abstract
,Introduction
,Background
,Conclusion
といったsectionからは書かない.この辺は書いてるうちにどんどん内容が変わっていくぞ.
- 間違っても
Conclusion
は締めなのでちょっとかっこいい事を書いても許される気がする- Contributionを論文序盤で箇条書きで書き出す.
- 最近の国際会議通ってるfull paperは大体1ページ目後半か2ページ目の冒頭ぐらいでContributionに関する言及がある気がする.
- Contributionを箇条書きで書き出してしまえば,あとはその根拠を説明するための文章を書けば論文になるのでそれ以降の文章が書きやすくなる.
- 論文を書くのは実装したり実験したりするのに比べて相当つらい
- とにかく淡々と書き続ける
- 書き続ければ,いつかは終わる
- 筆が止まったら違う章を進めるなどしてスループットを一定に保つ
- 1日中座ってると体調を壊すため適当に体を動かす.筆者は昼食を食べたあとに30分ぐらい学内を散歩するようにしている.
- 用語の表記ゆれは最悪なので避けるようにしたいが,イマイチ筆者も良い方法がわかっていない
- グラフはgnuplotかR + ggplot2で書けばいいと思う*2
- 軸名や軸の数値のフォントサイズはどの論文も小さくて読みづらいものが多いので,大きめのフォントサイズを指定して読みやすくしてやる心遣いをしてやると喜ばれる*3
- グレースケール印刷前提でカラースキームを選ぶ
- グラフは十分な解像度でpdfで出力する
- 図は筆者はフォトショを買う金がないのでdraw.ioを使っている.UMLのテンプレもあるので何かと便利.
- 言葉で説明するのがしんどいな〜と少しでも思ったら図を入れるようにしている
図が少ないと怒られたことはあるが図が多すぎると怒られたことはない- こないだ査読で「こんな図は無くても分かるので不要」と初めて怒られた.そういう査読者もいるようだ.
- 図は十分な解像度でpdfで出力する
- 基本,論文執筆は根性でがんばる
- きびしくなったら素直に指導教官にヘルプを求める
論文を推敲する
- 一通り書き終わったと思った直後の論文というのは,一度もコンパイルも実行もしていないコードみたいなものである
- 必ず間違いや書き漏れがあるので注意して読み直す
- 一変に色々なことをチェックすると漏れるので,以下のようにチェックする内容別に何回も繰り返すのが効率が良い
- 1回目の推敲で文章の前後のつながりがおかしくないかどうかをざっとチェックする.大体は接続詞がおかしい文が見つかる.
- 2回目の推敲で内容に関して過不足をチェックする
- 3回目の推敲でグラフ/図のキャプション,軸名,単位,数値,凡例に誤りがないかをチェックし,文中で正しいグラフ/図を指定しているかをチェックする
- 4回目の推敲で誤字脱字をチェックする
- 5回目の推敲で句読点の位置の正当性,文献番号の前にスペースが入ってるかどうか,カッコの前後にスペースが入っているか,などの細かい点をチェックする
- 6回目の推敲でこれまで書いた内容を何もかも忘れた気持ちで全体を読み直す
- ここまでやっても2,3日寝かせてから読み直すと新たに直したい箇所が見つかる
- 永遠に直したくなるのでどうすりゃいいんだろうなこれ
共著者にチェックしてもらう
- 大体は指導教官になる
- 教授というのは出張がめちゃくちゃ多いため,教授のスケジュールを事前に確認し余裕を持ってチェックを依頼する
その他のコツ
- 無理なスケジュールは立てない
- ちゃんと寝る
- ちゃんと休む
- 規則正しい習慣を達成するために平日は朝から全力で研究する
- 大学院生なんだろ
- ご飯はちゃんと食べる
- つい研究室にカップ麺を買い込んで修羅場感出したくなるけど,よほどヤバくならない限りはやらない.すぐ太るぞ(特に30代は).
- 困ったら指導教官に頼る
- そのために年間535,800円(国立大学の場合)の学費を払って大学院に在籍している