優れた研究論文の書き方

6.2K Views

March 14, 22

スライド概要

オリジナル: https://www.microsoft.com/en-us/research/academic-program/write-great-research-paper/

シェア

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
4.

論文の 書き方: モデル1 アイデア 研究 論文執筆

5.

論文の 書き方: モデル2 アイデア 研究 論文執筆 アイデア 論文執筆 研究

6.

論文の 書き方: モデル2 アイデア Your idea 論文執筆 研究 • 明快になり、集中できる • 理解していないことが明確になる • 誰かと話す可能性が高まる (現実性の確認、批評、協力)

7.

論文の 書き方: モデル2 アイデア Your idea 論文執筆 研究 論文執筆は研究するための重要な過程 (研究の報告のためだけではない)

9.

ゴール: 有益かつ 再利用可能 なアイデア を届ける • 読者の心にあなたのアイデアを (ウィルスのように)感染させたい • 論文はプログラムよりも長持ちする (モーツァルトを考えてみよう) 優れたアイデアを自分にとどめておく ことは(まさに)無価値である

10.

怖がらない ウソ 論文を執筆する前に素晴らしいアイデ アを思いつく必要がある(みんなそう している) 論文を書こう。発表しよう。どんなア イデアでも構わない。どんなにつまら ないダメなアイデアだと思えてもだ。

11.

怖がらない • 最初から論文を執筆することでアイ デアが作られていく • 最初はつまらないと思っていても、 いずれおもしろくてやりがいのある ものになる 論文を書こう。発表しよう。どんなア イデアでも構わない。どんなにつまら ないダメなアイデアだと思えてもだ。

12.

アイデア アイデア: 再利用可能な知見、 読者の役に立つもの • 論文にはたった1つの「ping」 (明快で鋭いアイデア)が必要 • 論文を書き始めたときには、pingが 何であるかは正確にはわからないか もしれないが、書き終わる頃にはわ かっていなければいけない • アイデアがたくさんあれば、たくさ ん論文を書けばいい

13.

「ping」が 聞こえる? • 多くの論文には優れたアイデアが含 まれているが、それが何かを明確に していない。 • アイデアが読者に確実に伝わるよう にしよう。100%明確に。 Joe Touchの「one ping」に感謝

15.

あなたの 物語の 流れ ホワイトボードを使って説明していると ころを想像しよう • これが問題です • これは興味深い問題です • これは未解決の問題です • これが私のアイデアです • 私のアイデアは有効です (詳細、データ) • 他の人の手法との比較です

16.

構成 (カンファ レンスペー パー) • • • • • • • • タイトル(読者1000人) アブストラクト(4つの文、読者100人) イントロダクション(1ページ、読者100人) 問題(1ページ、読者10人) 私のアイデア(2ページ、読者10人) 詳細(5ページ、読者3人) 関連研究(1〜2ページ、読者10人) 結論と今後の研究(0.5ページ)

18.

イントロ ダクション (1ページ) • 問題を記述する • 貢献を提示する ...それだけ 1ページでいい!

19.

問題を 記述する 問題の 紹介には 例を使う

20.

山脈よりも 小さな山を 例:「コンピュータプログラムにはバグがつきも のである。バグを排除することは極めて重要だ [1,2]。これまでに多くの研究者たちが尽力して いる [3,4,5,6]。非常に重要な問題である。」 退屈! 例:「このプログラムには興味深いバグがある。 <簡単な説明>。我々はこうしたバグを自動的に 特定および排除する技法を紹介する。」 すげえ!

21.

貢献を 提示する • 最初に貢献を一覧にしよう • 貢献の一覧が論文全体を駆動する: 論文はあなたの主張を立証するもの • 読者は「おっ、これが本当に実現で きるならすごいぞ。読まなきゃいけ ないな」と考える

22.

貢献を 提示する 読者にあなたの貢献 を推測させない! 貢献の一覧

23.

貢献を 反証可能に する No! Yes! 我々はWizWozシステムについ て説明する。これが本当にすご い。 我々は並行プロセスをサポートす る言語の構文と意味論を提示する (セクション3)。これは革新的 な機能で…… 我々はその特性を調査する。 我々は型システムの健全性と型 チェックの決定可能性を証明する (セクション4) 我々は実際にWizWozを使用し た。 WizWozでGUIツールキットを構 築した。それを用いてテキストエ ディタを実装した(セクション 5)。結果は、Javaバージョンの 半分の長さになった。

24.

エビデンス • イントロダクションで主張する • 論文の本文はそれぞれの主張をサ ポートするエビデンスを提供する • イントロダクションのそれぞれの主 張を確認し、エビデンスを特定して、 主張のところから前方参照する • 「エビデンス」には、分析や比較、 定理、測定結果、ケーススタディな どが含まれる

25.

「本論文の 構成は…」 をやめる • これはダメ: 「本論文の構成は以下のとおりである。セクショ ン2では問題を指摘する。セクション3では……最 後のセクション8では結論を述べる。」 • その代わり、イントロダクションの物 語から前方参照しよう。イントロダク ション(貢献も含まれる)は論文全体 の概説であり、すべての重要なところ を前方参照するものである。

27.

構成 • • • • • • • アブストラクト(4つの文) イントロダクション(1ページ) 関連研究 ダメ! 問題(1ページ) 私のアイデア(2ページ) 詳細(5ページ) 結論と今後の研究(0.5ページ)

28.

構成 • • • • • • • アブストラクト(4つの文) イントロダクション(1ページ) 問題(1ページ) 私のアイデア(2ページ) 詳細(5ページ) 関連研究 ここ! 結論と今後の研究(0.5ページ)

29.

関連研究 関連研究は まだ いらない! 読者 あなたの アイデア 我々は、Brown [1]のトランザクションの考えに、White [2]による分散システムのための修正を加え、Green [3] の4フェーズ補間アルゴリズムを使用している。我々の研 究は、応用的な廃止プロトコルにおいて、Yellow [4]によ る優先順位の逆転のケースを扱っているため、Whiteの研 究とは異なる。

30.

関連研究は まだ いらない! z zz • 問題1: 読者は問題についてまだ何 も知らない。したがって、さまざま な技術的トレードオフに関するあな たの(簡潔すぎる)説明は何も理解 できない。 • 問題2: 代替となる手法の説明は読 者とあなたのアイデアの間にある

31.

クレジット ウソ (言及と評価) 私の研究をよく見せるには、他人の研 究を悪く見せなければいけない

32.

真実:クレ ジットはお 金ではない • 助けてくれた人たちに心から感謝し よう • 競争相手に対して寛容になろう 「刺激的な論文[Foo98]においてFoogleは…… 我々は彼の論拠を以下の方法で発展させた……」 • あなたの手法の弱さを認めよう 他者の論文に言及することで、あなた の論文の評価が低下することはない

34.

構成 • • • • • • • アブストラクト(4つの文) イントロダクション(1ページ) 問題(1ページ) 私のアイデア(2ページ) 詳細(5ページ) 関連研究(1〜2ページ) 結論と今後の研究(0.5ページ)

35.

構成 3. アイデア ハイパーモジュールシグニチャS上に二分セミラティスD があるとする。piはDの要素である。このときすべてのpi がエピモジュラスjであれば pj < piとなる。 • なんかすごそう……だが • 読者は眠くなるし、自分の頭が悪い んじゃなかと思ってしまう

36.

アイデアの 提示 • ホワイトボードを使って話している かのように説明しよう • 勘所を伝えることが第一、第二では ない • 読者に勘所が伝われば、詳細を理解 してもらえる(逆は真ではない) • 詳細を飛ばしても、何か価値のある ことを持ち帰ってもらえる

37.

勘所を 伝える 問題とあなたのアイデアを紹介 するには例を使い、それから 一般的なケースを提示する • 忘れないで:ホワイトボードを使っ て話しているかのように説明しよう

38.

例を使う Simon PJの気持ち: どこかにタイプライ ターフォントはない かな? すぐに 例を使う

39.

読者を 第一に • あなたが歩んできた発見の旅を繰り 返してはいけない。その道は血塗ら れたものだったかもしれないが、読 者がおもしろいと思うものではない。 • その代わり、アイデアに直接つなが るような道を選択しよう。

41.

協力を 求める • 専門家がよい • 非専門家でもよい • 1人の読者がはじめて論文を読むの は、一度限りである!大切に扱おう • 協力してほしいことを丁寧に説明し よう( 「Jarvaはスペルミスだ」よ りも「ここがわかりにくかった」の ほうがはるかに重要である) 論文はできるだけ多くの友好的なモル モットに読んでもらおう

42.

専門家の 協力を 求める • うまいやり方:書き終わったと思っ たら「君の研究のことを公正に説明 してあるかな?」と言って、競争相 手に草稿を送ってみよう。 • おそらく役に立つ批評を返してくれ るはずだ(彼らもその分野に興味を 持っている)。 • 彼らは被参照者になりたいと思って いるだろうから、事前に彼らのコメ ントや批評を取り上げると大変よい。

43.

レビューアに 耳を傾ける すべてのレビューを砂金のように扱おう 批判も称賛も(心の底から)感謝しよう これは、本当に、本当に、本当に、難しい だが、本当に、本当に、本当に、本当に、 本当に、本当に、本当に、本当に、本当に、 本当に、重要だ

44.

レビューアに 耳を傾ける • すべての批評は、あなたの説明を明 確にするための肯定的な提案だと受 け取ろう。 • 「それはあなたの頭が悪いからで あって、ここはXという意味で…」 と答えるのは絶対にダメ。 • 頭の悪い読者にもXが明らかになる ように論文を修正しよう。 • レビューアには心の底から感謝しよ う。あなたのために時間を使ってく れたのだ。

45.

まとめ 1. 2. 3. 4. 5. 6. 7. とにかく書く 鍵となるアイデアを見つける 物語を伝える 貢献を明らかにする 関連研究はあとまわし 読者を第一に(例を使う) 読者に耳を傾ける 詳細:www.microsoft.com/research/people/simonpj

47.

基本事項 • 締め切り前に投稿する • 分量制限を守る 6ポイントのフォント • 常にスペルチェッカーを使う

48.

見た目の 構造 • 以下を使用して、論文の見た目の構 造を作り出そう • 図の描き方を調べて、実際に使おう

49.

見た目の 構造

50.

能動態を 使用する 受動態は「立派」に 見えるが、論文が薄 まる。ぜひとも避け たい。 No! Yes! It can be seen that... We can see that... 34 tests were run We ran 34 tests These properties were thought desirable We wanted to retain these properties It might be thought that this would be a type error You might think this would be a type error

51.

シンプルで 直接的な No! Yes! 言葉づかい The object under study was displaced horizontally The ball moved sideways On an annual basis Yearly Endeavour to ascertain Find out It could be considered that the speed of storage reclamation left something to be desired The garbage collector was really slow