現在の研究テーマ的にシステム・ソフトウェア開発論文を読んだり書いたりする機会が多い。指南文献などもいろいろ読み、以前よりは書くポイントがだいぶわかってきたつもりだが、それでもやっぱりあまり得意ではない。むしろ書くポイントが分かってきたからこそ、その難しさを実感するようになったのかもしれない。なお、ソフトウェア開発論文の執筆の難しさについて書かれた、『なぜソフトウェア論文を書くのは難しい(と感じる)のか』という非常に有名な文章がある。執筆の難しさについて客観的かつとても網羅的に書かれているので、未読の方は、こちらを先に読むと良いだろう。
システム・ソフトウェア開発論文では、導入部で「なぜいままでだれもやっていないのか」「どのような難しさがあったのか」を説明することが重要だと実感している。論文としてまとめる際に、開発する難しさ、そしてその難しさを乗り越えるアイデアがあたかも初めからあったように書かないといけない。システム・ソフトウェア開発以外の分野の論文でも最初から課題があるとしてシンプルなストーリーに構成し直すことはよくあることなのだが、例えば、自然科学の論文では「なぜいままで誰もやっていなかったのか」を説明することはあまりないだろう。システム・ソフトウェア開発論文では、そこに客観的な説得力を持たせて書かないと読者(要は査読者)を納得させられない。しかし、これが難しい。
先日見た以下の記事で
私は、モノづくりというのは「課題がある！ →解決策を苦労して探した！ →完成！」というシンプルな生い立ちを持つことがむしろ不自然、あるいはとても窮屈、ひいてはもったいないことなのではないかと疑っています。
という記述があったのだが、これがまさにシステム・ソフトウェア開発論文の導入部を書く難しさを表していると思う。開発過程を振り返り構成を整理すればシンプルなストーリーに仕上がるという単純な話ではない。頑張って文章を書けば、複数の理由を上手くまとめることはできるであろう。しかし、論文である以上、導入と結論の一貫性が大事であり、開発したシステム・ソフトウェアは目的に沿って評価される必要があり、複数の理由が絡まった軸で評価することは極めて大変になる。
システム・ソフトウェア開発研究に着手する際に「ここが難しいからいままで誰もやっていないだろう、しかしこのアイデアがあればできるぜ！」と考えて始めることは稀*1で、本当のきっかけというのは「面白そうだから」「できそうだから」「まだ誰もやってないから」等という、登山家が「そこに山があるから」と言うのに近いものがある。業務や組織の都合で開発し始めることも多いだろう。しかし、そこで開き直って正直に書いても、読者は納得させられない。
また、「どのような難しさがあったのか」を書くのも難しく、「難しい手段を使わずに簡単に解決できるならそれに越したことはないのでは🤔」と思ってしまう。ただ、これはシステム・ソフトウェア論文の執筆スキルを上げることで解決できるのではないかと思っている。客観的に難しさを示すパターンがいくつかあって（「分散並列処理の制御の困難さ」「特定のボトルネックの指摘」等）、そのレパートリーを増やしていくことで、いろんな切り口から難しさを客観的に説明できるようになる。
このように、システム・ソフトウェア開発を書くのはすごく難しい(と感じる)。特に、自分はハッカータイプではなく、コードは何かの目的を実現するための手段でしかないと考えているタイプの情報系研究者なので、この形式で論文を量産していくのは難しそうな気がしている。考えるより先にコードを書くようなハッカータイプの研究者なら、こういう形式で知見を残して論文を量産できるのかもしれない。
参考
*1:人によっては結構あるのかな？
