Transcript slide - POSL

世界を目指す論文の書き方
〜 不採録コメントに学ぶ 〜
九州大学大学院システム情報科学研究院
鵜林 尚靖
ICSE
RE
SIGSOFT/FSE
TSE
ASE
TOSEM
概要 〜 ひとことで言うと。。。
不採録通知
採録通知
ICSE 2010 Paper Notification [121]
Dear Naoyasu, XXX, XXX, and XXX,
Dear Naoyasu, Jun and Tetsuo,
Thank you for your submission to the 200?
International Conference on Software Engineering.
We regret to inform you that your submission entitled
Thank you for your submission to ICSE 2010. The program
committee met on December 4-5 to consider the
submissions to the Research Paper track. We are
pleased to inform you that your paper,
”投稿論文のタイトル“（内緒）
was not accepted for presentation at the conference.
We received XXX submissions this year and were able
to accept only XXX % of them.
続く
がっくり。。orz
"Archface: A Contract Place Where Architectural
Design and Code Meet Together”
has been accepted for presentation in the technical
program and for publication in the conference
proceedings. The competition was strong: only 52 of
the 380 submissions were accepted, giving an
acceptance rate of 13.7%.
失敗から何を学ぶべきか？
(不採録コメントの読み方)
やったー
2
このような認識に至った過程を
不採録コメントの実例を通じて紹介
不採録コメントに対する認識の変化
 昔「査読者が悪い」→
 読んで面白くなければ（査読者の共感を得なければ）、必然的に評
価は低くなる。
 面白くないのは、研究の真の貢献を「明確に論文として切り取って
いない」からだと考えるべき。［本当の問題はこちら！］
 昔「査読者は内容を理解していない」→
 分かるように論文を書いていない。分かり易いと思うのは著者だけ。
 査読者は論文に記載されていること以上は分かりようがない。
 昔「査読者は著者の努力を理解していない」→
 「努力≠研究の貢献」である
 やったこと（実装など）をそのまま論文として書いても駄目。
 論文では苦労は見せない（クールに）。苦労の内２割が研究の真の
貢献であれば、そこに論文はフォーカスすべき。
3
７つの助言
素直に「面白い」と共感させるものを持たせる
 助言１： 研究の貢献は最も魅力的な側面で切り取る
 助言２： 課題設定型論文はMotivating Exampleが命
 助言３： アイデアは明確に！ そして魅力的な名前を！
 助言４： Evaluation は必須
 助言５： 論文はクールに！ 苦労の足跡は残さない！
 助言６： これからの発展を予感させる
 助言７： 論文作成は「下ごしらえ」と「味付け」の２段階で
 番外編： 研究開始前に論文を書こう！
4
本日のお話
 自己紹介
 ソフトウェア工学の研究動向とトップカンファレンス
 ソフトウェア工学におけるトップカンファレンス
 論文査読ステップ （ICSEを例に）
 トップカンファレンスに論文を通すには？
 ７つの助言と不採録コメントからの教訓
 海外の研究グループの事例: Queen’s 大学 SAIL by 亀井 靖高（九大）
 まとめ 〜 日本からの研究発信を広げよう 〜
 付録
5
自己紹介
私の研究分野
 プログラミング言語、モジュラリティ
 AOP（Aspect-Oriented Programming）
 COP（Context-Oriented Programming）
 Role Model
 拡張メカニズム
 モデリング言語、MDD（Model-Driven Development）
 ソフトウェアアーキテクチャ
 ソフトウェア検証（実はあまり強くない）
7
トップカンファレンスへの採録状況
年
会議名
論文タイトル
2002
AOSD 2002 *
Aspect-Oriented Programming with Model Checking
2004
2005
AOSD 2004
ICSE 2005
ASE 2005 *
2007
ASE 2007 *
2009
2010
CAiSE 2009 *
ICSE 2010 *
2011
RE 2011 *
* 第一著者論文
AOP
Association Aspects
Role
An Adaptive Object Model with Dynamic Role Binding
A Parameterized Interpreter for Modeling Different AOP Mechanisms
An Aspect-oriented Weaving Mechanism
Based on Component and Connector Architecture
AOP
MDD
An Extensible Aspect-oriented Modeling Environment
Archface: A Contract Place Where Architectural Design
and Code Meet Together
AOP
アーキテクチャ
A Context Analysis Method for Embedded Systems
---Exploring a Requirement Boundary between a System and Its Context
要求工学
8
研究パフォーマンスの「ものさし」
採択率
ICSE 2005
ASE 2005
ASE 2007
CAiSE 2009
ICSE 2010
RE 2011
（14% = 44/313）
（10% = 28/291）
（12% = 37/312）
（16% = 36/230）
（14% = 54/380）
（17% = 23/138）
引用率
•採択率だけでは研究内容の良さは判断できない
（最近、プログラミング系のトップカンファレン
スでは出来るだけ多く論文を採録する方向へ）
•G-Index, H-Index
http://academic.research.microsoft.com/
自分のを確かめてみよう！
9
私の経験（失敗の連続）
 トップカンファレンスには何度も投稿し、何度も落ちた。
 論文が通り出したのは２００５年くらいから。それまでは、
ほぼ全滅の状況。
 １回の投稿でトップカンファレンスに採録されたことは残念
ながら無い。数回チャレンジして採録された。
 私の場合、「トップカンファレンスへの投稿と不採録コメン
トにより論文の書き方を学んだ」という側面が強い。
10
本チュートリアルの内容について
 本チュートリアルでは、私の経験を少し一般化して紹介する。
 紹介内容は、すべての人と場合に当てはまる訳ではない。
 他の専門（実証的ソフトウェア工学や理論系）の人とは、考え方
が異なるかもしれない。
 一つの事例として参考にしていただけると幸いである。
 学生や若い研究者がつまずいたとき、参照して貰えると幸い
である。共通する想いが見つかるかもしれない。
11
ソフトウェア工学の研究動向と
トップカンファレンス
どのような国際会議があるのか？
主な国際会議とその採択率の一覧
http://people.engr.ncsu.edu/txie/seconferences.ht
m
主な国際会議とその開催地・日程
http://research.csc.ncsu.edu/ase/semap/
Tao Xie (North Carolina State University) が公開
13
トップカンファレンスとは？
国際会議のランキング（A，B，Cランク）
ソフトウェア工学関係
トップカンファレンス（Aランク）
AOSD
ASE
CAiSE
CAV
CBSE
ECOOP
ESEM
FME
FSE
ICSE
ICSM
ISSRE
ISSTA
OOPSLA
RE
結構たくさんある！
http://www.core.edu.au/
The Computing Research and Education Association of Australasia, CORE
14
ICSE 2011 における論文採録
採録数 62/441
まずは、PCミーティン
ングの議論に残ることが
重要！
査読プロセス
投稿 441
第3査読者: 169
議論: 112
採録: 62
不採録: 272
不採録: 57
不採録: 50
石尾 隆, 吉村 健太郎: 第33回ソフトウェア工学国際会議(ICSE2011)
参加報告, IPSJ-SE11173012, 2011.
15
論文採録に向けての留意点
 トップカンファレンスは、投稿数が非常に多いが、採録され
る論文はごく少数。
 したがって、ほとんどの論文は不採録となる（多少内容が良
くても採録に達するのは困難）。査読者の立場に立つと、ほ
とんどの論文は落とさざるを得ない。
 まずはPCミーティングの議論の俎上に上る論文を書くことが
重要！
16
ICSE 2011に見る採録論文の傾向
トピック別の採録状況
石尾 隆, 吉村 健太郎: 第33回ソフトウェア工学国際会議(ICSE2011)
参加報告, IPSJ-SE11173012, 2011.
17
ICSEに見るソフトウェア工学の研究動向
 全体的に、定量的評価が可能な研究分野、理論的な取り扱い
が可能な分野にシフト
 ICSE以外でも同様の傾向
 採録されやすい研究分野
 オープンソースを対象とした実証的ソフトウェア工学
 テスト、形式検証、自動化
 採録が容易ではない研究分野
 上流（アーキテクチャ等）や方法論（ただし、要求工学には
REがある）
 その一方で、過度の定量化指向への反省も見られる
 今年のECOOPではコンセプト論文（モジュラリティに関するも
のなど）も採録されていた
18
トップカンファレンスに
論文を通すには？
論文作成のための助言
 トップカンファレンスに論文を通すには、当たり前のことで
あるが、優れた研究成果がなければならない。
 ただし、優れた研究成果があっても、論文の書き方で損をし
ているのなら、それは非常にもったいない。
 以下では、優れた研究成果を論文化する際の助言を示す。
20
論文作成時の一般的な留意事項
 論理の鎖
 例題中心の論理展開
 「タイトル」ー「概要」ー「イントロ」ー「トピックセンテ
ンス」の構造遵守
本チュートリアルでは、時間の都合上、上記のような一般的な留意事
項は省略する。これらに関する解説は、書籍やWebサイトを参照さ
れたい。
千葉 滋: 論文の書き方
http://www.csg.is.titech.ac.jp/~chiba/writing/
21
７つの助言
素直に「面白い」と共感させるものを持たせる
 助言１： 研究の貢献は最も魅力的な側面で切り取る
 助言２： 課題設定型論文はMotivating Exampleが命
 助言３： アイデアは明確に！ そして魅力的な名前を！
 助言４： Evaluation は必須
 助言５： 論文はクールに！ 苦労の足跡は残さない！
 助言６： これからの発展を予感させる
 助言７： 論文作成は「下ごしらえ」と「味付け」の２段階で
 番外編： 研究開始前に論文を書こう！
22
７つの助言と
不採録コメントからの教訓
23
助言１： 研究の貢献は最も魅力的な側面
で切り取る
 研究成果には様々な側面がある。どの側面で切り取れば（ど
の側面に光をあてれば）最も研究として魅力的か判断するこ
とが大切！
 どう切り取るかを考えることは、研究の真の貢献が何かを考
えること。論文が面白いか、読者の共感を得られるかは、こ
の切り取り方で決まると言っても過言ではない。
 論文の著者は、案外、自分の真の貢献を理解していないこと
が多い。不採録コメントの中には、「真の貢献（切り取り
方）」を示唆している場合がある。
 同一の成果（理論や支援ツール）でも、切り取り方を誤ると
凡庸な論文になってしまう。同じケーキでも、切り取り方を
誤ると美味しくなそうに見えるのと同じ。
24
最初の洗礼！
1999年
査読者１
One day this will be a great paper. But it isn't quite there yet.
The paper needs to be streamlined and clarified. You need to make
it more clear why this is a good idea.
査読者２
The paper is badly written. There might be good ideas that might be
hidden somewhere, but so far as I can read, the paper fails to be a
technical paper that crystallizes new ideas.
最終的には ICSE 2005 へ
25
不採録コメントにより真の研究の貢献に
気づく！
前半はボロクソ
The combination of technically inaccurate characterizations of
others' work, of great overclaiming, and of incomplete discussion of
a potentially serious weakness in the proposed approach overwhelm
what is otherwise a nice attempt to provide language support for
aspect-oriented programming through architectural connection.
実はこの当時気づいていなかった！
最終的には
ASE 2007, ICSE 2010 へ
26
切り口を間違えると凡庸、時代遅れの研
究に。。。
The application of AOP to mobile agents is intriguing. The overview on
agent applications is most interesting.
（中略）
Unfortunately, the paper is too similar to XXX’s paper at 同時期に開催さ
れたトップカンファレンス.
アイデアは良かったけど、残念だったね。
ちょっと遅かった。
しかし、貢献の切り口を変えると。。。
最終的には ICSE 2005 へ
27
助言２： 課題設定型論文はMotivating
Exampleが命
 論文には「自然科学型論文」と「課題設定型論文」の２種類がある。
前者は物理現象や生命現象の発見や理論に関するもの、後者は人間
社会における課題の設定とその解決方法に関するものである。
 ソフトウェア工学関係の論文は、理論系のものを除き、大半は「課
題設定型論文」である。
 論文の読者（査読者を含む）の共感を得るには、研究として取り組
む価値のある重要な課題であることを具体的に示すことが重要であ
る。そのための Motivating Example が重要となる。Motivating
Example が設定できれば、研究の半分は終わったと言ってもよい。
 ただし、理論系の論文、既存研究の問題点を解決する論文の場合は、
必ずしも Motivating Example は必要とされない。その代わり、
既存の研究、関連研究を引用し、課題の重要性を読者に納得させな
ければならない。
28
論文のベストな目次構成は？
1.
2.
3.
4.
5.
6.
7.
Introduction
Motivating Example
XXX の提案
Evaluation
Discussion
Related Work
Conclusions
問題提起型論文
1.
2.
3.
4.
5.
6.
Introduction
Related Work
XXX の提案
Evaluation
Discussion
Conclusions
問題解決型論文
29
例題がしょぼい。。。
An implementation is described, but the approach is validated
only with conceptual examples, no real case studies.
If the paper included a compelling case study and solved the
presentation issue, I would be convinced to advocate for it; as it
is, the paper is premature.
最終的には ASE 2007 へ
30
助言３：アイデアは明確に！
そして魅力的な名前を！
 アイデアやコンセプトは、シンプルかつ明確にモデル化する。
 アイデアには魅力的な名前を付ける。研究成果の普及に大き
な影響を及ぼす。名前が魅力的であるには、「名称が単純」
であり「研究の本質を言い表している」ことが重要である。
 アイデアに名前を付けると、論文の記述が引き締まる。同じ
ような説明を繰り返さずに済むからである。また、アイデア
に名前を付けることにより、研究の貢献が特定化され分かり
易くなる。一つの論文で複数のアイデアを提示したり、それ
に名前を付けるのは避けるべきである。何が研究の貢献かが
不明瞭になる。
31
つづき
 アイデアを説明するのに未定義用語を使用しない。「未定義
用語か否か」「どこまで詳細に説明すべきか」は研究コミュ
ニティにおける認知度にも依存する。そのため、研究の初心
者は未定義用語の問題に陥りやすい（判断基準が分からない
ため）。
 未定義用語の問題を避ける最も効果的な方法は、丹念に既存
研究を引用し、個々の研究で定義された用語を用いて、自ら
のアイデアやモデルを説明することである。アイデア名以外
は既存用語（参考文献の引用つき）を用いることを徹底する
と良い。アイデアを説明するのに新たな用語を定義するのは
避けること。アイデアが複雑になるだけでなく、何が本当の
貢献か分からなくなる。また、未定義用語の問題を引き起こ
す誘因にもなる。
32
最初の洗礼！
1999年（再掲）
査読者１
One day this will be a great paper. But it isn't quite there yet.
The paper needs to be streamlined and clarified. You need to
make it more clear why this is a good idea.
査読者２
The paper is badly written. There might be good ideas that might
be hidden somewhere, but so far as I can read, the paper fails to
be a technical paper that crystallizes new ideas.
最終的には ICSE 2005 へ
33
ストライクでない。。。
While the issue targeted by this paper is interesting, there are some
problems with this paper.
Originality unclear.
XXX is, of course, a new language, but the features it provides don't
strike me as original.
最終的には ASE 2005 へ
34
必ずしもフォーマルでなくても良い
The biggest problem I have with the paper is that its model of
computing is not properly clarified.
I don't mean to say give the whole formal semantics, but
terminologies such as roles, collaboration, strategies,
evolution, etc. remain ill-defined, other than to give a sketchy
description using some code fragments in an unfamiliar
programming language.
最終的には ICSE 2005 へ
35
安易な用語使用は禁物！
The paper makes one potentially dangerous redefinition of the
term ”XXX.”
I
think the software community needs another definition.
While I understand the temptation for this new definition, I suggest
the authors adopt the standard definition, and find a new name
for the new concept added here.
最終的には ASE 2007 へ
36
助言４： Evaluation は必須
 ソフトウェア工学の研究成果を論文化する際に、避けて通れない
のが評価。評価には定量的評価と定性的評価の２種類がある。読
者（査読者を含む）が納得しやすいのは定量的評価がきちんとし
ている論文。定性的評価のみでは厳しい場合が多い。
 オープンソースを対象とした実証実験、テスト、検証等は、定量
的評価が可能。したがって、ICSEでも論文が採録されやすい。
 上記以外の研究分野は残念ながら定量的評価が困難な場合が多い。
特に方法論関係は難しい（数名の被験者で評価実験しても妥当性
に乏しい）。しかし、査読者を納得させる評価が論文に含まれて
いなければ、よほど運が良くない限り（優しい査読者に恵まれな
い限り）、トップカンファレンスに採録されない。「プラクティ
カルな評価がない」の一言で不採録になる場合も少なくない。
37
つづき
 何らかの形で定量化へのアプローチを工夫すること
 オープンソースが使えるのなら使用する（メールの履歴は上流の
研究評価に利用できるかもしれない）。
 GQM（Goal, Question, Metric）の枠組みを魅力あるものとす
る。評価へのアプローチが興味深いものであれば、定性的評価で
も、十分納得のいく結果が得られる。
 対象データ（ドキュメント、ソース、要求変更）を要素に分解し
たり、項目化することにより定量評価が可能になる場合がある。
 定量化できないと諦めないこと。定量化への「こだわり」が
研究の真の貢献を見直すきっかけになる場合も多い。
38
納得できる評価は難しい。。。
This paper presents some interesting ideas for structuring aspect
specifications.
However, further elaboration is needed towards the evaluation of
these ideas.
最終的には ASE 2007 へ
39
助言５： 論文はクールに！
苦労の足跡は残さない！
 論文は研究成果を発表する場である。研究過程を述べる場で
はない。したがって、研究のために費やした労力の比率と論
文中の記載の比率は対応しない。
 研究の初心者は苦労した部分を一所懸命論文に書こうとする
傾向が強いが、これは誤りである。研究の貢献に紙面を割か
なければならない。仮に労力が２割でも、それが研究上最も
重要であれば、それを中心に論理展開しなければならない。
 論文を書く際は、苦労を一旦脇に置いて、それを微塵も見せ
ずにクールに、新規性やオリジナリティなどを述べると良い。
40
実装の苦労話は書かなくて良い
I think the details of the implementation in terms of XXX add
little to this paper.
That material probably wants to go in another.
最終的には ICSE 2005 へ
41
助言６： これからの発展を予感させる
 通常、Future Work は論文本体の付け足しのように扱われる
ことが多い。中には後ろめたい言い訳（「本当は重要なのだ
が、今回の研究の範囲外にした」等）も散見される。著者は
範囲外とすることにより免罪符を得たと思うかもしれないが、
査読者は必ずしもそのようには受け取らない。
 Future Work も研究の貢献の一部と考えるべきである。その
研究に今後どのような発展が見込めるのか、道しるべを示す
ことは重要な貢献である。発展の方向が魅力的であればある
ほど、読者の満足度も高くなる。免罪符的な言い訳を聞いて
も読者は面白くないのである。
42
つづき
 良い研究とは、その研究自身が内容的に優れたものであるだ
けでなく、その後の研究の発展に大きく寄与するものである
（cf. ICSE influence paper）。Future Workには、「これか
らの発展を予感させる」ものがあると良い。その裏付けとな
る参考文献を引用すると説得力が増す。
 Future Work をきちんと書くことは、著者自身の次のステッ
プの研究について真剣に考えることでもある。Future Workが
単なる機能改善や適用事例の拡大のみでは、上記の免罪符と
あまり変わらない。
43
助言７： 論文作成は「下ごしらえ」と
「味付け」の２段階で
 この助言は、講師流のやり方。あまり一般的ではないかもしれな
いが、参考になると思い、掲げた。
 以下の２段階から成る。
 下ごしらえ：
 通常の論文作成。論文として述べることを一通り記述したもの
（分量的にもほぼ投稿時のページ数）。投稿の少なくとも１週間
前に完成させる。
 「味付け」がないので、読んでも必ずしも面白くない。料理に例
えると、素材のままなので食べてもあまり美味しくない。ただし、
素材の良さは重要。素材が悪ければいくら味付けしても無駄。
 この段階のままトップカンファレンスに出しても、採録の見込み
はない。多くの論文投稿はこのレベルで終わっていると思われる。
44
つづき
 論文は「研究成果のプレゼン」である。読者（同じ研究者、査読
者）への贈り物である。贈り物である以上、読者に喜んで貰う必
要がある。研究内容の面白さを伝え、できれば読者に共感して貰
うことが大切である。
 そのためには、論文の魅力度を向上させるための「味付け」が必
要となる。味付けには、特に、助言１「研究の貢献は最も魅力的
な側面で切り取る」、助言３「アイデアは明確に！そして魅力的
な名前を！ 」、助言４「Evaluation は必須」、助言６「 これか
らの発展を予感させる」が重要となる。
 一言でいうと、「アイデアが斬新で将来の発展が見込まれる研
究」であることを読者に感じさせることである。
 この段階で助言１の「切り取り方」を変更する場合もある。投稿
直前での変更はリスクを伴うが（締切までに終わるか心配にな
る）、勇気を持って決断することも重要である。実際には「下ご
しらえ」がしっかりしていれば、貢献を主張するための論理展開
を修正すれば済むことも多い。少なくとも、投稿者本人が読んで、
素直に面白いと思うような「切り取り方」をしなければ、「下ご
しらえ」にかけた労力が無駄になってしまう。
45
番外編： 研究開始前に論文を書こう！
 普通、これは一体何を言っているのかと思うであろう。論文
は、通常、研究が終了して、それをまとめるものだからであ
る。
 しかし、研究が終わってしまってからでは論文を書けない場
合が多い。助言１「研究の貢献は最も魅力的な側面で切り取
る」に従おうとしても、その側面にしたがって、アイデアを
考案したり評価実験を行ったりしないと、肝心のデータが無
いという結果になる。そのため、出来た範囲で論文をまとめ
ることになり、魅力度に乏しいものにしかならないことが
多々ある。
46
つづき
 「研究開始前に論文を書く」の真意は、論文テンプレートにしたがって、
どのようなアイデアにすれば良いか、そのアイデアを実証するにはどの
ような実験が必要なのか、アイデアのオリジナリティを説得力よく説明
するにはどのような関連研究を提示する必要があるのか、を書き下すこ
とである。これは、論文テンプレートという道具を用いて、研究計画書
を作成するようなものである。このようにすれば、研究が終わった後に
肝心の評価データが無いなどの事態に陥ることを避けることができる。
 論文テンプレートは「不特定多数の人を納得させる」ための西洋流のロ
ジックと考えることができる。論文は研究成果を見ず知らずの人々に伝
えなければならない。また、研究の中心はまだまだ欧米中心である。し
たがって、西洋流のロジックを身につける必要がある。東洋人の論文は
何を書いているのか分からないという声をよく耳にするが、多くの場合、
これは英語の問題でなく、論理展開がおかしいからである。世界共通言
語は英語ではなく、「ロジック」である。英語だけが原因で論文が不採
録になることはない。論文テンプレートにしたがって「研究開始前に論
文を書く」ことにより、意識的に西洋流の論理展開を身につけることが
大切である。少なくとも論文を書くという行為においては。
47
海外の研究グループの事例:
Queen’s 大学 SAIL
By 亀井 靖高（九大）
48
SAIL@Queen’sの論文作成スタイル
 査読者が論文をフォローしやすいという観点（Make happy reviewers!!）
 必ずResearch Questionを2 or 3つ掲げる．
→ 時間のない査読者は，RQが十分な動機を持ち，妥当なアプローチによって，
正しく有効性／有用性が評価されているかという観点でレビューする
 RQに対して，[動機] [アプローチ] [結果] [考察]をまとめて記述する
 例）
1. Introduction
 RQの紹介とそれらの結果を1行程度
2. Related work
3. Experiment Setting
4. Results
4.1 RQ1.
 動機，アプローチ，結果，考察
4.2 RQ2.
 動機，アプローチ，結果，考察
49
SAIL@Queen’sで感じたこと
 投稿することが当たり前 & 計画的．
 例えばICSE2011の場合，5月上旬（締め切り4ヶ月前）に原稿のア
ウトラインを6月上旬（3ヶ月前）までに送るようラボ全体にメー
ルが流れた．
→ タイトル，アブスト，メインアイデア，実験計画を含むこと
 6月上旬にアウトラインを送るようリマインダが流れた．
 6本の原稿が投稿されている（Posdoc:2 PhD:6 Msc: 2）
 採択率は常に劇的に高いというわけではない．
→ 多くの投稿が実を結んでいる
 ICSE2011: 14.4% (=1/6)
会議全体:14.1% (=62/441)
 ICSM2010: 22.5% (=2/8)
会議全体: 27.1% (=36/133)
50
まとめ
日本からの研究発信を広げよう
51
日本からの投稿を増やそう！
 トップカンファレンスに論文を通すのは正直難しい。努力し
ても報われないことの方が圧倒的に多い。
 しかし、投稿しないことには採録もされない。
 まずは、投稿することから始めよう！
 落ち続けても、粘ることが重要！
52
付録
53
参考文献
 ICSE's Most Influential Paper
Award:http://www.sigsoft.org/awards/mostInfPapAwd.htm.
 Show, M.: Writing Good Software Engineering Research, Proceedings
of the 25th International Conference on Software Engineering, IEEE
Computer Society, 2003, pp. 726-736.
http://www-2.cs.cmu.edu/%7ECompose/shaw-icse03.pdf
 石尾 隆, 吉村 健太郎: 第33回ソフトウェア工学国際会議(ICSE2011)参加報告,
IPSJ-SE11173012, 2011.
 千葉 滋: 論文の書き方 http://www.csg.is.titech.ac.jp/~chiba/writing/
 権藤 克彦, 他: なぜソフトウェア論文を書くのは難しい（と感じる）のか,
コンピュータソフトウェア, Vol.26, No.4, pp.17-29, 2009.
54