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

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

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

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

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ページ）
Structure
(conferen
ce paper)

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

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

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

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

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

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

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

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

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

28. Structure • アブストラクト（4つの文）
• イントロダクション（1ページ）
• 問題（1ページ）
• 私のアイデア（2ページ）
• 詳細（5ページ）
• 関連研究
• 結論と今後の研究（0.5ページ）
ここ！

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

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

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...
34 tests were run
These properties were thought
desirable
It might be thought that this
would be a type error
We can see that...
We ran 34 tests
We wanted to retain these
properties
You might think this would be a type
error

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