オルタナティブ・ブログ > 森崎修司の「どうやってはかるの?」 >

計測できそうでできない多くのこと。エンピリカル(実証的)アプローチで。

エンジニアのためのソフトウェア工学論文の見つけかたと読みかた

»

研究としての価値はいったんおいておいて、エンジニアの方が実務で使えそうな方法を調べたりどのくらい研究が進んでいるかをおおまかに把握したりすることを主眼としてブログエントリにしました。このブログエントリを書いたきっかけはSammyさんとのVoicyでの対談です。具体例をもとに話をしているので聞いてみてください。

ここで紹介する内容は研究者が読むスタンスとは別なので私はこのブログエントリのような読み方はしていませんが、エンジニア視点では効率的になっていると思います。私が担当する現役の学生は(担当しない学生の皆さんも)、ここで読むのをやめて指導教員が教える文献調査の方法に従ってください。自分で研究を進めるためには新規性が必要なので、ここで紹介する読み方では不足があるためです。

エンジニアの目的は「目の前の課題を解決する手段」や「技術の全体像の把握」と想定しています。そのため、論文は最初から最後まで一言一句丁寧に読む必要はありません。このブログエントリは、自分が必要な部分のみを効率よく読み取れればよいというスタンスで書いています。熟読するとそれはそれで新たな知見は得られると思います。

もう一つ、英語論文を読むことを想定しています。日本語論文の場合には、一般的な検索とあまり変わらないと思いますので、後で説明するGoogle scholarで気になる日本語の単語を指定して検索したり、生成AIに指示するとおおよその結果は得られると思います。

前提の最後ですが、あるソフトウェア工学の研究成果は他のどういう開発でも通用するわけではなく、理論として積み上がっていくものばかりではありません。一事例を示しているだけにとどまる場合もあるので、「自分の開発には当てはまらないな」となることもあります。

では、本題に。エンジニアのかたが研究論文を読むとき、大きく2つのパターンに分かれると思います。多いのは領域の全体像を把握したいというパターンではないかと思います。もう1つのパターンは具体的な論文が決まっているときです。全体像を把握すると読みたい論文が具体的に決まることもあるので、1つめのパターンの後、2つめのパターンになることもあります。

論文をさがすツールは使い慣れた生成AIに調べてもらうのがよいでしょう。網羅的に調べたいときや具体的なキーワードがわかっている場合には、Google scholarという文献や特許のみを対象とした検索エンジンを使うほうがお勧めです。このほかにも、一般情報を対象とした検索エンジンを使ってもかまいません。

領域の全体像の把握

領域の全体像を把握したいときは、「この分野ではどんな手法があるのか?」「手法、課題、概念はどのような用語で説明され、その定義は何か?」を調べます。このようなときにはSystematic Literature Review (SLR) やサーベイ論文を読みます。このタイプの論文は一般的な論文とは異なり、オリジナルな手法を提案したり現象などを調査して報告したりするのではなく、既発表の論文にどのようなものがあるかを網羅的に調査したものです。特定のテーマに関する過去の論文を数十〜数百本を分類、まとめたものです。

論文タイトルに"Systematic Literature Review", "A Survey"とついていることがほとんどです。ですので、ソフトウェア工学の生成AI活用が気になれば、"software engineering" " systematic literature review" surveyといったキーワードで検索すると見つかります。ここでのダブルクォートはこの並びで出現するキーワードを含む文献に限定して検索するために指定することを意味します。たとえば、ソフトウェア開発でAIエージェントを使ったときの手法であれば、AI Agentic "systematic literature review"といったキーワードを与えます。

Google scholarの検索結果には、論文PDFへのリンクが表示されますので、これをたどって論文の内容を読みます。ただし、無料で公開されていないものもあり、そのときにはリンクが表示されないので購入するか別の論文を探します。

SLR、サーベイ論文を読む際のコツは以下の通りです。

  • SLR論文やサーベイ論文には「どこにいつごろ掲載されたか」といった情報やどういうキーワードでどういう検索サイトを使ったかを説明しているものが多いですが、エンジニアとしては読み飛ばして問題ありません。偏りのない調査であることを示すためのものなので査読や研究としては大事です。

  • SLR論文やサーベイ論文には「この論文で調査する項目(RQ:Research Question)」が明記されていることがほとんどで、これが章や節タイトルになっていることも多いです。RQは複数挙げられていることがほとんどなので、「XXの手法にはどのような課題があるか?」「どのような開発ドメインで使われているか?」といったRQの中から、自分の興味がある項目だけを選んで、その結果(RQへの回答)が書かれた章や節のみ選んで読みましょう。生成AIや機械翻訳で日本語に訳して読んでもおおよその意味はとれると思いますので、忙しければそうした方法も使ってください。

  • RQへの回答となる部分に具体的にどのような論文があるかを示しているSLR, サーベイ論文は多いです。[15]といった文献番号が示してあれば、論文末尾にある文献一覧を参照すると具体的な著者、タイトル、掲載誌が書かれています。

RQの回答にある論文の中で具体的に内容を確かめたいものが出てきたり、読みたい論文や手法が明らかな場合には、2つめのパターンで読みます。

特定の手法や論文を読む
2つめのパターンは、具体的な論文や手法がわかっているときです。一般的な論文はこのタイプの論文で、アルゴリズムや実装方針やその評価を報告した論文です。こうした論文にもエンジニア視点で効率的に読む方法があります。

  • 関連研究(Related Work)や背景(Background)は、必要がなければスキップして構いません。提案手法や評価を集中して読みます。

  • こうした論文は大別すると2種類に分けられます。一つは手法を提案している論文です。もう一つは調査結果を報告する論文です。

  • 手法を提案する論文の読みかた

    • 提案手法の章には、実施手順や処理手順が詳しく書かれていることがほとんどです。Pseudo code(疑似コード)やフローチャートが図として掲載されていることが多いので、本文を読むよりも先にこれらに注目すれば短時間で読み解けます。

    • 評価の章には、手法の効果や効率を評価した方法と結果が掲載されています。どういう対象をどういう方法で評価し、どういう結果であったかを確かめます。ここで、自分の担当するソフトウェアと大きく違いがあったり、注目していない視点での評価があれば、読み飛ばしてください。また、学生プロジェクトを対象としている場合もありますので、そのことを前提に解釈します。

  • 調査結果を報告する論文の読みかた

    • 章、節で調査対象、調査方法、調査結果に分かれているのが通常です。調査対象や調査方法が自分の担当するソフトウェアと大きく違いがあるようであれば、注意が必要です。学生を対象としている場合もありますので、そのことを前提に解釈する必要があります。具体的には、異常系にはあまり目が向いていない、ユーザー視点が薄い、メンテナンスの経験はほとんどない等です。

自分の担当するソフトウェアと大きく違いがあるかという判断について少し詳細に説明します。たとえば、セーフティクリティカル(車載、医療機器、宇宙航空など)のソフトウェアを開発している場合、リリーススピード優先のスマートフォンアプリを前提とした手法や調査は、信頼性の面で参考にならないことがあります。

エンジニアの立場から論文を読むときに注意すべきことが2点あります。一つは、手法のコストパフォーマンスです。論文では、コストがかなり増えても既存手法より精度が少しでも向上する点で優れていれば、新しい手法として提案されることがあります。しかし、実務では、精度は最高でなくていいのでコストがそれほど増えないほうがよいということもあります。精度が最高でなくても既存手法のほうがコストが小さければ、そちらを選ぶことが適切になることもあります。たとえば、過去の膨大なデータによる事前学習が必要になるけれど少し精度が高い提案手法よりも、精度は少し劣るが学習不要でシンプルに導入できる既存手法の方が、実際に使うときには優れているケースも多々あります。

注意しないといけないもう一つは、単一の調査結果が一般的な事実につながるとは限らないことです。「主語が大きい」とされるものです。特に自分も信じたいことや普段から感じていることの場合には注意が必要です。あくまで1つの調査結果であり、これが一般化できるかどうかはわかりません。一般化できるかもしれないですし、そうでないかもしれません。これは、その論文が誤っているということではなく、その論文の調査結果が他でもあてはまるかどうかはわからないということを意味します。架空の例を挙げると、XXという有名なソフトウェア開発会社で、優秀な技術者を調査したらスキルだけでなく性格もいい人ばかりだった、というような調査結果です。やっぱりXXの優秀な技術者はいい人なんだろうなという思いがあれば、ついつい別の会社や一般的に優秀な技術者はそうなんだろうな(けど、自社は違う)と思ってしまうような場合です。

このような場合、ソフトウェア工学の論文では多くないのですが、複数の論文の結果を統計的に合成するメタアナリシスというタイプの論文もあり、そうした結果を見てから一般化できそうだと判断するほうが適切な解釈ができます。

Comment(0)