なぜソフトウェア論文を書くのは難しいのか？

2010/2/1-1

権藤克彦, 明石修, 伊地知宏, 岩崎英哉, 河野健二, 豊田正史, 上田和紀, "なぜソフトウェア論文を書くのは難しい（と感じる）のか", コンピュータソフトウェア, Vol.26, No.4, pp.17～29, 2009年11月

この論文は、情報系の大学生や研究者にお勧めです。「車輪の再発明」というのは、既存のものを作り直すことを示していますが、ソフトウェアという分野で車輪の再発明を完全に「駄目なもの」として扱うことの危うさもあるのではないかと感じました。「今あるソフトウェアが駄目だから自分で作り直した」ということが、もっと「論文」へと結びつけば、今よりも大学からのイノベーションも増えるのではないかと思います。新しいアイデアは運用の中から生まれたり、ソフトウェアの周縁にコミュニティが形成されることで次の種が発生することもあります。たとえば、「ウェブサービスを作って多くのユーザに提供する」ということが論文になるのであれば、大学から楽しいウェブサービスが無数に生まれることだろうと思います。

自由な発想で色々なものが作れなかったり、そもそも情報系の研究室に行きたいと考える学生が減っているという感想を述べる大学教員が増えているのは、「論文になるかならないか？」という点においてソフトウェアを実装して公開するということがあまり評価されないことも一因だろうと、この論文を読んで思いました。私も学生時代にオープンソースフリーソフトを作っていましたが、フリーソフトの作成と配布そのものは論文にはなりにくいという状況でした(USENIXぐらい？のイメージでした)。

この論文が目指しているように、「ソフトウェア論文」がもっと論文として認められる土壌ができたら面白いのだろうなぁと感じました。

ソフトウェア論文

この論文では、「2.1 ソフトウェア論文とはなにか？」で次のように述べています。

アイデア自体には新規性はなくても良い(ただし設計や実装方法などで有益な経験・知見は必要)

ソフトウェアの公開が強く推奨される(ただし義務ではない)
「ソフトウェア論文」の対象となるソフトウェアには特に指定はない

特に最初の点が大切です. アイデア自体は新しくなくても, それをきちんと作り込むことが困難な場合も多いからです. このため, ソフトウェア論文では(たとえアイデア自体が新しくなくても)積極的に「優れたソフトウェアの開発成果や, ソフトウェア設計・作成上の有益な知見」を評価しています。

さらに、この論文の2.2章は「なぜソフトウェア論文なのか？」というタイトルで、ソフトウェア論文を推進することで次の２点を促進することを目指すと述べています。

ソフトウェアの研究や技術の促進

優れたソフトウェアの開発と普及の促進

前者は研究と開発現場のギャップを埋めることとと, 研究自体の深化の両方を含んでいます.

ソフトウェア実装が非常に大変である反面、成果に対する客観的な測定方法もなく、「きちんと実装しても論文として書きにくい」「業績にならない」という点が論文、及び研究が進まないという点を問題意識として挙げています。

2.3章では「類似の取り組み」としていくつかの取り組みが紹介されていますが、それらは十分に成功していないと述べています。現状の取り組みは、査読基準が研究論文へとドンドン近づいていき、投稿者数が減って社会的な認知が得られないという現象が発生しているという問題点を挙げています。

2.4章では、「ソフトウェア論文はいつでも投稿できます」というタイトルで以下のように書かれています。

今後もソフトウェア論文特集を企画する予定ですが, 特集がないときでもソフトウェア論文はいつでも投稿できます. 登校時に論文種別として「ソフトウェア論文」を選択して下さい.
ソフトウェア論文を書く意義には大きく次の２つがあります.

社会的意義：より優れたソフトウェアの開発・研究・普及に貢献できます. 例えば, 良いアイデアを追試で裏打ちすることで, 悪いアイデアを淘汰することができます.

個人的意義：地道に実装を行っているソフトウェア研究者の努力が報われます. 一般に, 大学や研究所では(ソフトウェア論文を含めた)論文が業績となるからです.

なぜソフトウェア論文は難しいか？

この論文のメインは3章の「なぜソフトウェア論文は難しいか？」です。ソフトウェア論文が、なぜ難しく書き難いのかを例を示しながら述べています。「ハッカーと画家」「Joel on Software」「ビューティフルコード」などの書籍からの引用もあり、非常にわかりやすく納得できる内容でした。

ここでは、各節のタイトルだけを紹介します。論文は日本語でかかれており、PDFも公開されているので是非原文をご覧下さい。個人的には、3.2.5章の「ソフトウェア工学の「できたこと」にする傾向」と、3.4.4の「ネガティブな記述への拒否反応」が非常に共感しました。「この手法ではうまくいかなかった」という論文が無いのは変だし、それを見ることで同じ失敗に陥ることを防げると思うのですが、そういう系統の論文が通りにくいのはあると思います。

ソフトウェア自体の難しさ
ソフトウェアは説明がしにくい
ソフトウェアは測りにくい
ソフトウェアは調査しにくい
ソフトウェアの抽象化は難しい
理想と現実のギャップ：現実のソフトウェアは美しくない
ソフトウェアは再利用しにくい
ソフトウェア工学の難しさ
開発プロセスは記録・分析しにくい
ソフトウェア工学の本質は当たり前のことにある
ソフトウェア工学の原理は定量的ではなく定性的でしかない
ソフトウェア工学の「できたこと」にする傾向
開発における芸術的側面
開発における社会学的側面
著者側の問題
作文が苦手・嫌い
細部へのこだわりが要点を見失わせる
ソフトウェア論文は要点を絞りにくい
現場を知っているので気楽な一般化ができない
開発の成功のために開発方法は保守的になる
査読側の問題
加点法ではなく減点法で査読している
実装経験が浅い査読者が査読している
実装経験が深い査読者が査読している
ネガティブな記述への拒否反応
照会事項で無理難題を要求する
論文は読むが,コードは読まない
「追試」の概念が希薄
「作りました論文」というレッテル貼り
長い論文に対して寛容ではない
社会状況の問題
若いプログラマの労働環境が悪い
「コーディングは単調作業」と考える風潮
検察と裁判官はグルで,しかも弁護士はいない

この論文の最後に「チェック項目」として16項目が示されています。たとえば「有用性や完成度などのアピールポイントを簡潔に示した」や「読者にとって有益な情報を明示的に提供した」「ソフトウェアのソースコード(やバイナリコード)を公開した」などが項目として示されています。

最後に

この論文は非常にお勧めです。共感する部分が多い内容でした。

似たような感じで、ネットワーク等の運用ノウハウ論文というジャンルも出来れば、有意義かもと思いました。バッドノウハウを含めて、様々なノウハウが属人的に受け継がれている現場があると思うのですが、ノウハウを公開する「場」として論文誌などがあると、書く側も読む側もメリットが多いのだろうなぁと、ぼんやり考えました。

ソフトウェア論文が広く認められるようになると、色々大きく変わるだろうと思った今日この頃です。

過去記事

過去記事一覧

超凄いIPv6解説書(488ページ)を無料配布します！

なぜソフトウェア論文を書くのは難しいのか？

ソフトウェア論文

なぜソフトウェア論文は難しいか？

最後に

最近のエントリ

過去記事

YouTubeチャンネルやってます！