日本語文章表現の留意事項
- 文章作法
- トピックセンテンス(段落の主張)をできるだけ各段落の先頭に配置。
- 論理的な繋がりを心掛ける。
- 図表、例を中心に説明を進める。参考: 千葉滋, “論文の書き方”(特に「文章技術」), https://chibash.github.io/writing/index.htm
- 読みやすさ、分かりやすさ
- 文の途中で主語を変えない。
- 主語が曖昧となりがちな受動態・受け身の表現を多用しない。
- 「それを」「これについて」といった指示語を多用しない。
- 冗長な日本語表現の排除
- 「~について・・・」を極力排除。「~は・・・」「~の・・・」のような言い換え。
- 「する」「こと」「行う」を極力排除。
「~をする」-> 「~する」。「~をした」-> 「~した」。「~をして」->「~して」。
「~することができる」-> 「~できる」。「使うことができる」->「使える」。
「~するために」-> 「~に」。例えば「確認するために必要な」->「確認に必要な」。
「~こと」-> 「~」。例えば「従うことよりも」->「従うよりも」。
「~を行う」-> 「~する」 - 「~かを・・・」を極力排除。
whether「~できるかどうかを」 -> 「~の可否(条件など)を」
where「どこに~かを」->「~の場所(位置)を」
when「いつ~かを」->「~のタイミング(場合、時間など)を」
why「なぜ~かを」->「~の理由を」
who「誰が~かを」->「~の実施者(扱う人など)を」
to whom「誰にとって~かを」->「~の対象者を」
how to「どのように~かを」->「~の方法(仕組みなど)を」
how much「いくら~かを」->「~の費用(労力など)を」
共通の指摘
- 卒論、修論は個人の提出物であるため、共著としないこと。ただし、ベースとなる対外発表論文の共著者に対して謝辞などで感謝することは良し(それが望ましい)。
- 他人の著作物(特に我々の研究グループ以外の第三者の著作物)を勝手に掲載しないこと。例えば図表を、他人の PDF からキャプチャして勝手に貼り付けないこと。ただし、出典を明記するのであれば、同じ図表を新たに書き起こして掲載することは、引用の範囲内として通常許容される。
- 図表について、第三者が正しく解釈できることを確認すること。例えば、線やアイコンの意味を解釈できるかどうか、一貫して描かれているかどうか(例: 点線を、複数の異なる意味をもってもちいていないか)。色を一貫して用いているかどうか、使いすぎていないかどうか(カラフルな図表はしばしば読みにくく、かつ、同じ色で意味が場所により異なるなど一貫していない)。
- 各研究課題 RQ への回答を議論するにあたり、同じ段落内で得られた事実と考察を混ぜないこと。少なくとも段落は分けること。
- データを取得したら、平均や総数のみで議論するのではなく、検定などの統計解析を適用すること。
- 参考文献数の目安は、卒論 15以上、修論 20以上。
- 卒論概要書のフォーマットは学科として定めていない。修論概要書を流用してかまわないが、不要な欄は適宜削除などすること。
- 自身の発表成果がある場合は、末尾に記すこと。
- オフィスソフトウェアやオンラインマニュアルのキャプチャの貼り付けは一般に許容されるが、出典としてソフトウェア提供元のURLを参考文献あるいは注釈として参照すること。
Here are some tips on thesis defense you need to consider:
- You must finish your presentation within the given time frame. 時間厳守
- You need to practice several times in prior. Better to get checked by some others, especially senior students. 練習必須。他者に見てもらうとよい。
- Make background introduction as short as possible, but not shorter. 背景説明を必要最小にすること。しかし必要以上に省略しないこと。
- Highlight your idea. アイディアを明確にすることを心掛けること。
- Show the problem and corresponding solution clearly by example. 例を用いて問題や解決を明確に示すこと。
- Show research questions and corresponding answers as evaluation or case study results. 研究課題とその回答の形で、評価やケーススタディの結果を明示すること。
- Use images and diagrams rather than text. テキストよりも図や画像を用いること。
- You should mention your publication/presentation achievements in the last slide. 研究発表の実績を最後のスライドで言及すること。
- Enjoy!
Some other useful tips are:
http://matt.might.net/articles/academic-presentation-tips/
https://jographies.wordpress.com/2015/02/28/20-tips-for-top-academic-presentations/
書き方全般
・鷲崎弘宜, SQiP研究会2017 ミニ講座「論文の書き方入門」 2017年
https://www2.slideshare.net/hironoriwashizaki/2017-80777238
・大島勇人, “学術論文作成の基本 “: 研究の進め方も含めて大いに参考となります。https://www.elsevier.com/__data/promis_misc/job-author-workshop.pdf
・鵜林尚靖, “世界を目指す論文の書き方 ~ 不採録コメントに学ぶ ~”: 実体験に基づいた具体的な助言として大いに参考となります。
http://ws.cs.kobe-u.ac.jp/~masa-n/ses2011/ses2011_tutorial2.pdf
・千葉滋, “論文の書き方”: 論文の構成など基本的な点について大いに参考となります。
http://www.csg.is.titech.ac.jp/~chiba/writing/
・奥村有紀子, “レビューの前にできること”, JaSST’09 北海道: 論文その他文章一般の執筆における留意点の分かりやすい解説です。
http://www.jasst.jp/archives/jasst09s/pdf/S5-4.pdf
・Mary Shaw, Writing Good Software Engineering Research Papers, ICSE’03, mini tutorial: RQの書き方や種別など詳細が解説されています。10年ほど前の論文採択の傾向も参考になります。 http://www.cs.cmu.edu/~Compose/shaw-icse03.pdf
論文構成(問題提起型の場合)
参考PDF: ASE2o13前澤、SEKE2013 西浦、SPLC2013 土屋
1. Introduction はじめに
Background 背景
Problem statement 問題提起
Ideas for solving the problem! 解決のアイディア!
・RQ1 ~
・RQ2 ~
Contributions 貢献
・~(Contribution 1 貢献1)
・~(Contribution 2 貢献2)
2. Background 背景
2.1 ~
2.2 Motivating example 動機付けの例
3. Proposal of … ~の提案
Including application result targeting the motivating example 動機付けの例への適用を含む
4. Evaluation 評価
(・RQ1 ~)
(・RQ2 ~)
4.1 Evaluation (experiment) design and result 評価実験内容と結果
4.2 Discussion 考察
RQ1 ~
RQ2 ~
4.3 Limitation 制限
Including threats to validity
妥当性への脅威を含む
5. Related work 関連研究
6. Conclusion and future work おわりに(まとめと展望)
■提起
「1. はじめに」において、背景および問題提起の後に、解決の核となる着想・アイディアを明示します。そのうえで、扱う研究課題(Research Questions)を、RQ1, RQ2 という具合に箇条書きにします。大きな RQ を立てるのではなく、小分けにしてそれぞれ妥当性や重要性、達成度合いを確認しやすくします。つまり査読者は、ここに注目します。RQは、評価が主目的となる実証系の研究論文では、1節などの早い段階で提示します。対して、新たな手法や仕組みを提案する研究論文では、そうした提案を終えた後の評価の節で初めて提示すると座りがよいです。
<NG な RQの例>
RQ: 拡張可能な~により・・・を支援できるか?
<OK な RQの例>
RQ1: ~を自動的に得られるか?
RQ2: ~は拡張可能か?
RQ3: ~は実用的な時間内で実行可能か?
そして同じく「1. はじめに」において、大抵は全 RQ に応えられているはずの貢献(Contributions)を、箇条書きにします。これも大きな貢献をただ一つ述べるのではなく、 How を中心として小分けにします。貢献には大抵、評価結果も含めます。
<NG な 貢献の例>
本論文の貢献は~を実現する手法の提案および実装である。
<OK な 貢献の例>
本論文の貢献を以下に示す。
・~する手法の提案
・~手法を自動化するツールの実装
・~を題材とした検証結果
■評価
まずは評価実験の結果を事務的に述べ、続いて、各 RQ に対して応えられたかどうかを考察します。上記の論文原稿を参考にしてください。
■妥当性への脅威
・内的妥当性への脅威(Threats to Internal Validity)
因果関係の確かさに影響を与える事柄を議論します。例えば実験により、「提案手法を用いれば(ない場合と比較して)作業が効率的」と結論付けたいのであれば、提案手法の利用と作業効率
向上の間の因果関係について、被験者の慣れ、経験や環境の相違、などが影響を与える可能性があります。
例: 実験において~なので、・・・が~に影響した可能性がある。これは内的妥当性への脅威である。今後、・・・により影響の有無を確認したい。
・外的妥当性への脅威(Threats to External Validity)
一般化の可能性に影響を与える事柄を議論します。例えば利用者の違い、組織の違い、ドメインの違いなどが提案手法やツールの有効性に影響を与える可能性があります。
例: 実験は一つの企業における一つの・・・ドメインに限定して実施したものであり、これは外的妥当性への脅威である。ただし、提案手法は・・・ドメインに特化して設計されたものではなく、~という特徴を有するドメインであれば同様に有効な可能性がある。今後、・・・により他のドメインや企業における有効性を検証したい。
下記も参考とするとよいでしょう。
http://sotsurontaro2.seesaa.net/article/22851854.html