Last Update: 2015/09/10
- Q:
ソフトウェア論文の説明
中の「ソフトウェアの進化」とは何ですか?
バグ取り，機能の拡張，使い勝手の改良，移植，文書の整備，など
ソフトウェアを本当に使えるようにするための様々な保守作業のことです．
大学や研究機関が開発したソフトウェアは，アイデアとしては新しくて
新規性があっても，ソフトウェア工学的な品質(性能，機能，使い勝手，
保守性，移植性，読解性，信頼性など)が悪いことが往々にしてあります．
ソフトウェア進化の実践・経験はソフトウェア論文でのセールスポイントに
なります．
- Q: 主なアイデアは研究論文として既発表ですが，ソフトウェア論文として
投稿可能でしょうか?
はい．ただし，研究論文として発表した主な成果以外の部分を
セールスポイントとして記述下さい．
従来の研究論文の成果として記述しにくい成果の記述を検討して下さい．
研究論文発表後に，ソフトウェアの改良等があれば，その部分はソフトウェア
論文の記述対象の候補になります．
- Q: 小さな工夫が数多くあって，論文としてまとにくいのですが．
まずはまとめる工夫・努力をして下さい．
正確さや網羅性を多少犠牲にして，短く分かりやすい説明を心がけてください．
一番難しいところに説明をフォーカスしてください．
分かりやすい例を使うことを心がけてください．
どうしても論文に入りきらない成果，あるいは正確で網羅的な説明は，
ソースコードの公開場所やテクニカルペーパーで別途公開して，
それを論文中で参照することも可能です．
「小さな工夫が数多くあるため，短く説明するのは難しい」という旨を
論文中に記述して頂いても構いません．(私はそういう論文を見たことが
何度かあります．)
- Q: 私のソフトウェアの何をセールスポイントとすればいいでしょうか?
例えば，以下はセールスポイントの候補になります．
- バグの少なさ，作りこみ．
- 使い勝手の良さ．(ユーザ数，ダウンロード数．)
- デザインや実装の妥当性．
- 実装で得られた経験．
しかしソフトウェアの価値は多様であり，一概には言えません．
ソフトウェア論文の説明
に
「どのようなソフトウェアについてどのような観点から論文を執筆すれば
学術論文として認められるかに関して十分な社会的合意があるわけではなく，」
とあるのはこのためです．
不明な点はぜひ，このページトップに記載の問い合わせ先まで，
お問い合わせ下さい．
- Q: 関連研究との比較は必要でしょうか?
ケースバイケースです．ソフトウェア論文には新規性は必須ではないので，
新規性を主張するための関連研究は必ずしも必要ではありません．
しかし，類似の機能をもつソフトウェア(の開発)がある場合は，それらとの
比較・分析があることが望ましいでしょう．
- Q: ユーザ数やダウンロード数はセールスポイントになるでしょうか?
なります．なぜユーザ数が増えたのか，使い勝手やユーザサポートの
工夫などの説明や分析もして下さい．
- Q: 苦労話や失敗談はセールスポイントになるでしょうか?
なります．経験論文もソフトウェア論文となります．
ただし，単なるエッセイではなく，
読者の役に立つように，事実の記述と分析もして下さい．
- Q: 研究論文かソフトウェア論文かのカテゴリの選択は重要でしょうか?
はい．評価基準が大きく異なりますので，執筆前に十分にご検討下さい．
カテゴリを途中で変更することは可能ですが，評価基準の違いのため，
論文内容の大きな変更が必要となるおそれがあります．
(なお，カテゴリの選択は著者の権利であって，義務ではありません．)
- Q: 研究論文とソフトウェア論文の両方の性格を持ち合わせる論文は
どうすればいいでしょうか?
研究論文，ソフトウェア論文，のどちらへも投稿可能です．
- Q: 評価ではなく，いわゆる予備評価でもよいのか?
網羅的な評価が難しい場合は，予備評価でもかまいません．
評価が困難な理由，予備評価の妥当性の主張も記述してください．
- Q: いわゆる「作りました論文」でよいのか?
いいえ．
単なるマニュアルや機能の説明だけではソフトウェア論文になりません．
ただし，ソフトウェア論文としての価値を含む場合でも，「作りました
論文」という悪いレッテル貼りをされることがあります．
微妙なケースについてはぜひ，
このページトップに記載の問い合わせ先まで，お問い合わせ下さい．
- Q: 開発がうまくいった秘訣といわれても困る．何を書けばよいのか?
例えば，単に地道な努力をしただけでも，何をどのように行ったかを
簡潔に具体的に説明してください．(例えば，メーリングリストによる
プロジェクト管理と言っても，様々な運営形態がありえます．)
なるべく頑張って書いて頂きたいのですが，
秘訣を無理に書く弊害もありますので，
分からない場合は「分からない」と書くことも OK です．
- Q: (一部を)外注で作成したソフトウェアでも，ソフトウェア論文として
投稿可能か?
可能です．
全てを外注した場合でも，
自作したプロトタイプや要求仕様書・設計書などと併せて
セールスポイントとすることで，ソフトウェア論文として投稿可能です．
- Q: 設計上の取捨選択(design alternatives)や判断(design decision)は
書くべきでしょうか?
その判断の正しさは客観的に示す必要があるでしょうか?
なるべく記述してください．
客観的に示せればベストですが，
一般的に難しいため，主観的な主張でも構いません．
- Q: 仮定や制限は明示すべきでしょうか?
はい．重要な仮定や制限は(簡潔に)明示することが望ましいです．
- Q: ソフトウェアライセンスの選び方が分からず，
ソフトウェアの公開に躊躇しています．
申し訳ありませんが，確定的なお答えをすることができません．
様々なライセンスがあり，それらが複雑である事や，
ライセンスに関する判例が少ないことが理由です．
参考までに，以下にWikipediaのソフトウェアライセンスへのリンクを示します．
主なライセンスと特徴などが載っています．
- Q: 大学センターなどにおけるシステム管理・保守業務の経験も
ソフトウェア論文となりうるでしょうか?
はい，ソフトウェア論文になりえます．
システムのソフトウェア部分に焦点を絞り，
何が難しいのか，
何がセールスポイントなのか，
何をどこまで達成したのか，
他のシステム管理・保守業務と何が異なる（と考える）のか，
などを要領よく明確にするようにして下さい．
インパクトのある，コンパクトにまとめた実データも明示してください．
システム導入時の仕様書，運用時の議事録・日誌・バグ記録などは
この実データの候補になります．
(単なる管理・保守エッセイにならないように十分留意ください．)
- Q: ソフトウェア論文は論文賞の対象になるのでしょうか?
ソフトウェア論文は「ソフトウェア論文賞」の対象となります．
「ソフトウェア論文賞」は２００８年１１月２７日に制定されました．
詳しくは以下をご覧下さい．