COVID-19 期間中の在宅勤務がソフトウェア開発業務に与える影響のアンケート調査結果（速報版）

COVID-19 パンデミックによって、世界中のソフトウェア開発者が在宅勤務に移行しています。COVID-19期間中の在宅勤務がソフトウェア開発者のウェルビーイング、すなわち身体的、精神的、社会的に良好な状態にあることと生産性に与える影響を明らかにすることは、この未曾有の危機への対応を考えるとともに、記録としても重要であると考えられます。

カナダ・ダルハウジー大学のポール・ラルフ教授が、この影響を分析するための国際的なアンケート調査を実施しました。日本においては、奈良先端大ソフトウェア工学研究室の畑秀明先生がこのアンケートの実施を担当しておりました。まず、アンケートの配布にご協力いただいた皆様、ご回答いただいた皆様に、この場を借りてお礼申し上げます。

本研究結果の速報について、畑先生に日本語版を作っていただきましたので、以下、ご紹介します。

このアンケート調査は、各国のソフトウェア工学研究者によって、アラビア語・中国語・英語・フランス語・イタリア語・日本語・韓国語・ペルシャ語・ポルトガル語・スペイン語・ロシア語・トルコ語の12言語で用意され、COVID-19の影響でオフィスから在宅勤務に変更した2,225人の有効回答を得ました。回答は53カ国から寄せられており，ドイツ・ロシア・ブラジル・イタリア・米国・韓国・ベルギー・中国・トルコ・インド・日本・スペインからはそれぞれ50人以上の有効回答がありました。

アンケートの回答から、以下のような影響が出ていることが分かりました。

• ソフトウェア開発者のウェルビーイングと生産性に悪影響が出ている。
• ウェルビーイングと生産性に密接な関係がある。
• 人間工学的に好ましい在宅勤務環境はウェルビーイングと生産性の改善に役立つ。
• 女性・子を持つ親・障害を持つ人々が特に大きな影響を受けており、一律でないサポートが必要である。

これらの分析結果から、ソフトウェア企業の行動としては、

• COVID-19期間中に在宅勤務する従業員のウェルビーイングを支援すること、
• 機器やサービスなど何を必要としているかを従業員に尋ねること、
• 在宅勤務環境をよりよくする支援をすること、
• これまでと同レベルの生産性を求めないこと、
• COVID-19期間中の生産性によって解雇や人事異動などの決定をしないよう配慮すること、

が重要であると思われます。

本研究結果の速報については、プレプリント・サーバーのarXiv.orgに公開されております。

arxiv.org

また、得られたデータなどはポール・ラルフ教授のWebページで公開されています。

https://paulralph.name/2020/03/27/pandemic-programming-questionnaire/

情報処理学会論文誌「ソフトウェア工学」特集

筆者が編集委員長を担当していた「ソフトウェア工学」特集が収録された情報処理学会論文誌 Vol.61, No.4 が無事発行されました。目次は 情報学広場：情報処理学会電子図書館 から閲覧することが可能です。この号は２つの特集が相乗りしているので見つけにくいかもしれませんが、少しスクロールしたところにある "特集「ソフトウェア工学」の編集にあたって" という原稿に続く１２編が特集号に採録された論文です。

これらの論文は昨年の８月に投稿された研究ですので、内容的には国際会議の最先端には一歩遅れてしまいますが、情報処理学会論文誌は「投稿 → 査読 → 査読に基づく修正 → 再度の査読 → 査読に基づく修正をして最終版」という流れになる論文が多く、文章としては洗練されているものが多い傾向にあります。これからソフトウェア工学を勉強する人には一通り（タイトルと概要だけでも）読んでもらって、最先端の研究を調査するためのキーワードを知る素材として活用してもらえると嬉しいです。

開発者数が増えたときのソースコードの書き方のばらつきの増減

2019年の春から夏にかけてインターンシップでソフトウェア工学研究室に来てくれた学生が2019年末のワークショップで発表を行いました．

How Do Contributors  Impact Code Naturalness An Exploratory Study of 50 Python Projects [ResearchGate.net]

Code Naturalness というのは言語モデル（N-gram など）を使ってどのぐらいプログラムの中身が予測できるか，つまり「よくあるコード」か，というのを計測しようという考えです．OSS プロジェクトにおいて，人が集まっている度合いと Naturalness に相関のような関係があるのかを，開発がそれなりに長い Python プロジェクト50個で調査したものが以下の図になります．

論文 Fig.4 より引用．縦軸が予測のしにくさ．開発者数が多い(high)，中間(medium)，少ない(low) 3つのプロジェクト群のコードで，多いプロジェクトのコードのほうが内容が予測がしにくいという傾向が出ています．

　図を見ると，実は上から順に Hgih / Low / Medium と並んでいて，増えれば増えるほどばらつきが増えるというわけではないようでした．たとえば人数がある程度増えるとコーディング規約などが整備されて予測しやすくなるとか，大人数で開発するようなプロジェクトだと多様な機能を実装していくので（他にない独自の機能を作っていくので）予測しにくくなるとか，などの可能性があります．

　論文ではこれに加えて開発者の Python プロジェクトでの経験（GitHub上で見える活動量）との関係も調べてみたのですが，やはり単純に経験が増えれば予測しやすくなるというわけでもないようでした．

　ソフトウェアの機能や熟練度，開発体制など，ソースコードの内容に絡んでいそうな要因を切り分けていくこと，そして Naturalness という指標自体の性質を調べることが，今後の課題となっています．

コードレビューのコメント量はプロジェクトによる

コードレビューで開発者はどのぐらいコメントをしているのか、私たちの研究室で調べた論文が電子情報通信学会の英文誌に掲載されました。J-STAGEからどなたでもダウンロードすることができます。

www.jstage.jst.go.jp

この論文では、Chromium、AOSP、Qt、Eclipse、LibreOffice という大手プロジェクトでのコードレビューにおいて、コメントの数と、コメントの長さ（単語数）が時間経過・レビュアーの経験によって変化するかを調べました。論文の調査結果から言えること（Implications）としては、以下のようなものがあります。

• コードレビューのコメント数は平均すると3～13。１コメントは平均22単語。プロジェクトによっても大きく異なる。
• コメントの数や長さは時間によって変動する。システムが成長するにしたがって増えていく傾向はあるようだが、開発者もレビュアーも相手のコメントのうち必要なもの・興味のあるものにだけ反応するので、必ずしもそうとは言えない。
• 上記２つの結果から、「このぐらいコメントをしたからレビューもそろそろ終わりだろう」というような予断はできないということになる。
• 開発者は経験が少ないと、レビュアーは経験が多いと、コメントをたくさん書く傾向にある。もちろんパッチの長さもコメントの量に影響する。パッチに関する議論を短く済ませたい場合は、経験とパッチの長さの両方に気を付ける必要がある。論文には明記されていないが、議論が短くてもバグを見逃したら意味がないし、開発者が経験を積むにも時間が必要なので、たとえば開発者は経験を積むまでは小さなパッチ投稿（で済みそうな Issue の解決）からやっていくというのが良いのかもしれない。

　 本当は「このぐらいレビューコメントを書くのが基本ですよ」というようなガイドラインが出ればよかったのでしょうが、残念ながらプロジェクトによる、時期にもよるで、そういう話にはなっていません。この研究はコメント量の話だけで、検出されたバグの数に関しても考慮していないので、活動量に対する効果まで議論できるようになるにはまだ研究が必要なのだろうと思います。

　ちなみに、論文ではプロジェクトに投稿されたパッチ数（Workload）とコメント数の関係も調べていて、影響が小さいことが図表に出ています。プロジェクトが忙しくとも、レビューの活動量に影響が出ていないということは、「忙しいからレビューを簡略化してしまってバグを見逃す」ということはないのかもしれません。こちらも、バグの検出数などをうまく調べることができるようになれば、今後、細かい議論ができるようになるかもしれません。

ソースコードの類似度計測ツールの利用例を Jupyter Notebook として公開しました

Google Colaboratory を使って、ソフトウェア工学研究室で開発しているソースコード類似度計測ツールの利用方法を Jupyter Notebook 化してみました（シェルコマンドを並べているだけなので Python 要素は皆無ですが）。

grep 的に類似ソースコードの断片を検索する NCDSearch の利用方法がこちら。

ファイル単位で類似度を計算するためのハッシュ値を求めるツールの利用方法がこちら。

どちらも Notebook 内部に実行例が保存されているので、リンク先を見に行くだけで Google のホスト上での実行結果を確認することができます。また、Jupyter Notebook 的な良さとして、その場でオプションを書き換えて実行しなおすことができ、結果の変化もすぐに確認することができます。

ソースコードの類似度計測はコードクローン検出という名前でも知られる技術の１つですが、具体的にどんな入力からどんな出力を出すものなのか、ちょっと結果を見てみたいという人はぜひご覧ください。各 Notebook とも、末尾には対応する論文や資料へのリンクも用意してあります。

プログラミング言語処理の練習課題

研究ではプログラミング言語で書かれたソースファイルの中身を調べることが多くありますが、そのような処理をどのようにプログラムで記述するかまでを入学時点で知っている学生は、ほとんどいません。各研究課題に合わせて、プログラミング言語の字句解析や、構文解析といった技術について勉強をしてもらっています。

そのための資料の一部は SlideShare、GitHub で公開しています。どのような感じの技術であるか知りたい人はご覧ください。

www.slideshare.net

スライドに書かれた演習問題（Java プログラムの中に定義されたメソッド宣言の一覧を取ってくるなど）は、この手の研究を始めるにあたってよくある処理の代表のつもりで選んでいます。スライド内で参照されているリポジトリ（GitHub - takashi-ishio/ParserExample）に、Java で記述された構文解析の実装および実行例を収録しています。自分で作らずに回答だけを見たい人は "implemented" ブランチのソースコードをチェックアウトして実行してみてください。実行をコンソールで行う手順を Google Colaboratory を使って作ってみたものがこちらにあります。

プログラミング言語処理には馴染みがない人も多いかもしれませんが、こういうものから簡単に触れてもらって、興味を持ってもらえると幸いです。

ソースコード差分を集めるための git diff では --histogram を使うべき

当研究室博士後期課程の Yusuf Sulistyo Nugroho さんが発表した、言いたいことは論文のサブタイトル（"Use --histogram for code changes"）で終わっている論文です。オープンアクセスとなっているので、どなたでも全文をダウンロードできます。

link.springer.com

git diff では使用するアルゴリズムをいくつかから選ぶことができます（参考：Git のオプションをまとめられている方の記事）。この論文では、アルゴリズムを histogram にした場合としない場合でどちらが良いか、また、そのような差が、diff をベースにしてバグが最初に導入された原因コミットを特定する技術（を使った各種研究）に影響する可能性を議論しています。

研究のアプローチは、21,590件の変更に対して、母集団を代表できるよう377件をサンプリングして、それらを手作業で調査する、という方式での調査となっています。画期的な方法があったわけではなく、地道な調査です。

結果として、diff アルゴリズムの結果は劇的に違うわけではないが、histogram のほうが良い、と報告しています。この報告の影響で、git の Windows Explorer への統合等の UI を提供している gitextensions プロジェクトでも histogram をサポートされるようになりました。以下の issue として論文（の著者最終版）が引用されています。

github.com

Git のオプション自体はこの研究を行う前から存在していたので、やったことだけを見ると「オプション機能１つの効果を調べた」という一風変わった論文となりました。様々なソフトウェア工学の研究で Git が基盤ツールとして使われるから、重要性を査読者に高く評価してもらえたのだと思います。

[修正履歴] 記事タイトル「Git の diff では」を「ソースコード差分を集めるための git diff では」と変更しました。この研究はリポジトリマイニング技術の適用場面に関するものであって、状況によって他のオプションが優れている可能性までは否定していないためです。