筆者が編集委員長を担当していた「ソフトウェア工学」特集が収録された情報処理学会論文誌 Vol.61, No.4 が無事発行されました。目次は 情報学広場：情報処理学会電子図書館 から閲覧することが可能です。この号は２つの特集が相乗りしているので見つけにくいかもしれませんが、少しスクロールしたところにある "特集「ソフトウェア工学」の編集にあたって" という原稿に続く１２編が特集号に採録された論文です。
これらの論文は昨年の８月に投稿された研究ですので、内容的には国際会議の最先端には一歩遅れてしまいますが、情報処理学会論文誌は「投稿 → 査読 → 査読に基づく修正 → 再度の査読 → 査読に基づく修正をして最終版」という流れになる論文が多く、文章としては洗練されているものが多い傾向にあります。これからソフトウェア工学を勉強する人には一通り（タイトルと概要だけでも）読んでもらって、最先端の研究を調査するためのキーワードを知る素材として活用してもらえると嬉しいです。
2019年の春から夏にかけてインターンシップでソフトウェア工学研究室に来てくれた学生が2019年末のワークショップで発表を行いました．
Code Naturalness というのは言語モデル（N-gram など）を使ってどのぐらいプログラムの中身が予測できるか，つまり「よくあるコード」か，というのを計測しようという考えです．OSS プロジェクトにおいて，人が集まっている度合いと Naturalness に相関のような関係があるのかを，開発がそれなりに長い Python プロジェクト50個で調査したものが以下の図になります．
図を見ると，実は上から順に Hgih / Low / Medium と並んでいて，増えれば増えるほどばらつきが増えるというわけではないようでした．たとえば人数がある程度増えるとコーディング規約などが整備されて予測しやすくなるとか，大人数で開発するようなプロジェクトだと多様な機能を実装していくので（他にない独自の機能を作っていくので）予測しにくくなるとか，などの可能性があります．
論文ではこれに加えて開発者の Python プロジェクトでの経験（GitHub上で見える活動量）との関係も調べてみたのですが，やはり単純に経験が増えれば予測しやすくなるというわけでもないようでした．
ソフトウェアの機能や熟練度，開発体制など，ソースコードの内容に絡んでいそうな要因を切り分けていくこと，そして Naturalness という指標自体の性質を調べることが，今後の課題となっています．
コードレビューで開発者はどのぐらいコメントをしているのか、私たちの研究室で調べた論文が電子情報通信学会の英文誌に掲載されました。J-STAGEからどなたでもダウンロードすることができます。
この論文では、Chromium、AOSP、Qt、Eclipse、LibreOffice という大手プロジェクトでのコードレビューにおいて、コメントの数と、コメントの長さ（単語数）が時間経過・レビュアーの経験によって変化するかを調べました。論文の調査結果から言えること（Implications）としては、以下のようなものがあります。
本当は「このぐらいレビューコメントを書くのが基本ですよ」というようなガイドラインが出ればよかったのでしょうが、残念ながらプロジェクトによる、時期にもよるで、そういう話にはなっていません。この研究はコメント量の話だけで、検出されたバグの数に関しても考慮していないので、活動量に対する効果まで議論できるようになるにはまだ研究が必要なのだろうと思います。
ちなみに、論文ではプロジェクトに投稿されたパッチ数（Workload）とコメント数の関係も調べていて、影響が小さいことが図表に出ています。プロジェクトが忙しくとも、レビューの活動量に影響が出ていないということは、「忙しいからレビューを簡略化してしまってバグを見逃す」ということはないのかもしれません。こちらも、バグの検出数などをうまく調べることができるようになれば、今後、細かい議論ができるようになるかもしれません。
Google Colaboratory を使って、ソフトウェア工学研究室で開発しているソースコード類似度計測ツールの利用方法を Jupyter Notebook 化してみました（シェルコマンドを並べているだけなので Python 要素は皆無ですが）。
grep 的に類似ソースコードの断片を検索する NCDSearch の利用方法がこちら。
ファイル単位で類似度を計算するためのハッシュ値を求めるツールの利用方法がこちら。
どちらも Notebook 内部に実行例が保存されているので、リンク先を見に行くだけで Google のホスト上での実行結果を確認することができます。また、Jupyter Notebook 的な良さとして、その場でオプションを書き換えて実行しなおすことができ、結果の変化もすぐに確認することができます。
ソースコードの類似度計測はコードクローン検出という名前でも知られる技術の１つですが、具体的にどんな入力からどんな出力を出すものなのか、ちょっと結果を見てみたいという人はぜひご覧ください。各 Notebook とも、末尾には対応する論文や資料へのリンクも用意してあります。
研究ではプログラミング言語で書かれたソースファイルの中身を調べることが多くありますが、そのような処理をどのようにプログラムで記述するかまでを入学時点で知っている学生は、ほとんどいません。各研究課題に合わせて、プログラミング言語の字句解析や、構文解析といった技術について勉強をしてもらっています。
そのための資料の一部は SlideShare、GitHub で公開しています。どのような感じの技術であるか知りたい人はご覧ください。
スライドに書かれた演習問題（Java プログラムの中に定義されたメソッド宣言の一覧を取ってくるなど）は、この手の研究を始めるにあたってよくある処理の代表のつもりで選んでいます。スライド内で参照されているリポジトリ（GitHub - takashi-ishio/ParserExample）に、Java で記述された構文解析の実装および実行例を収録しています。自分で作らずに回答だけを見たい人は "implemented" ブランチのソースコードをチェックアウトして実行してみてください。実行をコンソールで行う手順を Google Colaboratory を使って作ってみたものがこちらにあります。
プログラミング言語処理には馴染みがない人も多いかもしれませんが、こういうものから簡単に触れてもらって、興味を持ってもらえると幸いです。
当研究室博士後期課程の さんが発表した、言いたいことは論文のサブタイトル（"Use --histogram for code changes"）で終わっている論文です。オープンアクセスとなっているので、どなたでも全文をダウンロードできます。
git diff では使用するアルゴリズムをいくつかから選ぶことができます（参考：Git のオプションをまとめられている方の記事）。この論文では、アルゴリズムを histogram にした場合としない場合でどちらが良いか、また、そのような差が、diff をベースにしてバグが最初に導入された原因コミットを特定する技術（を使った各種研究）に影響する可能性を議論しています。
研究のアプローチは、21,590件の変更に対して、母集団を代表できるよう377件をサンプリングして、それらを手作業で調査する、という方式での調査となっています。画期的な方法があったわけではなく、地道な調査です。
結果として、diff アルゴリズムの結果は劇的に違うわけではないが、histogram のほうが良い、と報告しています。この報告の影響で、git の Windows Explorer への統合等の UI を提供している gitextensions プロジェクトでも histogram をサポートされるようになりました。以下の issue として論文（の著者最終版）が引用されています。
Git のオプション自体はこの研究を行う前から存在していたので、やったことだけを見ると「オプション機能１つの効果を調べた」という一風変わった論文となりました。様々なソフトウェア工学の研究で Git が基盤ツールとして使われるから、重要性を査読者に高く評価してもらえたのだと思います。
[修正履歴] 記事タイトル「Git の diff では」を「ソースコード差分を集めるための git diff では」と変更しました。この研究はリポジトリマイニング技術の適用場面に関するものであって、状況によって他のオプションが優れている可能性までは否定していないためです。
2019年9月30日から10月4日まで、アメリカ・クリーブランドで開催されたソフトウェア保守と進化に関する国際会議 35th IEEE International Conference on Software Maintenance and Evolution に参加してきました。
筆者の研究室と直接関係する発表は、筆者と大阪大学の共著による Near-Omniscient Debugging for Java Using Size-Limited Execution Trace というツール発表です。Omniscient Debugging （全知デバッグ、またの名を Time-Travel Debugging, Reversible Debugging）を本気で実装すると実行トレースとして 10 MB/s ぐらいのデータ量を保存する必要があるのに対し、各命令に対して最大 k 回までとデータ量を限って情報を保存すれば、1％以下のデータ容量で、８～９割程度のデータフローが追跡できるようになる、といったコンセプトを示しました。発表資料はこちら（大阪大学ソフトウェア工学研究室のページ）からダウンロードできます。
同会議および併設イベントでは、このほか、先日ソフトウェア設計学研究室で博士課程を修了した Md. Rejaul Karim さん筆頭の Identifying and Predicting Key Features to Support Bug Reporting という論文のほか、東京工業大学、早稲田大学、広島市立大学、大阪大学、日立製作所からの研究が発表されていました。
本会議１日目の基調講演は Laurie Williams による「Software Engineering Research: Beyond Impacting Practitioners」。研究者が追及する State of Art もよいが、それが実務者や社会に対してどのような意味があるのか、State of Practice、State of Society を考えるように、という内容でした。例としてセキュリティの研究者が議論している高度な攻撃・防御方法のほとんどは、きちんとパッチ当てる、適切なパスワードを設定するといった普通の人が日常的に遭遇する問題の解決には役に立たないこと、たくさんのシステムに確実にパッチを当てるのは新規性のある研究にはならないが非常に難しいことを引き合いにして、研究と社会の関係を改めて見直すことを提案していました。
基調講演では、紹介された研究の価値を考えるためのテンプレートとして、以下の文章が示されていました。
The goal of this research is to aid [stakeholder] to [solve problem] through [research technique].
ICSMEに採録された論文から実際にこの文章を作ってみると、多くの論文は開発者に対する技術であり、また研究者やユーザのための技術もあるが、一部論文にはこれが書かれていないと指摘していました。そして、Academia には研究のためのデータはないが頭脳がある、Industry には課題とデータはあるが時間がない、だから産学連携が重要であり、「できるからやる」研究をするのではなく、世の中を良くするための研究をする意識を持つように、そして OSS は世界全体ではないと、安易に OSS のデータ解析に流れがちな研究者に対して釘を刺しつつ、話を締めくくっていました。上記のテンプレートは、簡単で任意の研究で使える、分かりやすいものだと思います。
本会議ではたくさんの論文が発表されていましたが、筆者にとって今回印象的だったのは Keith Gallagher らによる「Teaching Software Maintenance」です。チームで既存のソースコードを調べ、修正すべき場所を特定し、影響を予測するといったソフトウェア保守の活動をどのように授業（演習）として行ったかを報告した論文でした。学生にとっては非常に大変な思いをするが、同時に満足度も高い授業の基本的なやり方と、その結果得られた経験について説明されています。
また、Industry Abstract として論文自体は非常に短い（詳細が書かれていない）ですが、Hyrum Wright による「Lessons Learned from Large-Scale Refactoring」というタイトルの発表も非常に個性的でした。Google では全員が20億行のコードベースを共有しており、コンパイラやライブラリの更新など、システム全体に影響を与える大規模更新が行われること、そしてそれを自動的に適用するには自動テストが重要であることと、勝手にコードを変更されるのを許容する文化が必要であることを説明していました。さらに、API に対してたくさんの利用者がいると、動作に関する取り決めは意味がなく、観測できるあらゆる振る舞いに誰かは依存してくる（With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.）ということを Hyrum's Law と言いたい、と述べていました。たとえばハッシュ辞書というデータ構造の中に格納されたデータは、イテレータを使った取り出しに対して順序を保証しませんが、たまたま社内で最初に使っていた実装では特定の決まった順序（登録順）で出てきていたために、コードの一部はそれを前提にしたものとなっていて、あとでセキュリティ的な理由で順序をランダムにしたとたん、たくさんのコードが壊れてしまったそうです。言い換えるなら、どんな変更を加えても振る舞いが少しでも変われば誰かは影響を受ける、そしてその影響は変更をした人が悪いわけではない、ということでもあります。この話の細かい主張については 詳細が書かれた Web サイト（Hyrum's Law）をご覧ください（この記事を執筆中の現時点では、残念ながら上記のような具体例は掲載されていませんが）。
なお、全体的な傾向としては、研究対象ソフトウェアのドメインとしてマイクロサービスとモバイルアプリの話題が増加していました。技術的な側面はコードクローンや技術的負債、継続的インテグレーションなど、昨年と大きな変化はないように思いましたが、たとえば Etherium のスマートコントラクトに対するコードクローン検出など、今ある技術を新しいソフトウェアに適用するものが目立ったように思います。
