ソフトウェア工学研究の日々

ソフトウェア工学の学術研究を紹介しています。ソフトウェア開発に関する調査と実験が大好きです。

習熟度の高いプログラマは、瞬間的にプログラムの内容を把握する

 ソフトウェア工学研究室の幾谷吉晴さんがプログラム理解に関する実験結果を論文として発表しました。論文自体は英語ですが、内容の概略を日本語プレスリリースとして出してもらいました。

www.naist.jp 実験は、1画面に収まる程度の長さの Javaソースコードを10秒間読んで、それが何をしているか(数学のアルゴリズムか、文字列処理か、など)おおよその当たりを付けるという作業を、習熟度= AtCoder rate が異なる30人のプログラマたちに実施してもらうというものです。プログラマたちの脳活動をfMRIを使って計測した結果、レートの高い人と低い人では、脳の異なる領域が活動していることが確認されました。

 プレスリリースではレートと正解率に相関があったとだけ書かれていますが、レートが高い人の中には、4択問題として出された分類問題を90%以上正解するような人も目立っていました。競技プログラミングの訓練を積んだプログラマは、画面に映ったプログラムを素早く、しかも正確に認識する能力に長けている、ということになります。計測方法の都合上、ファイルの選択や画面のスクロールなどを伴う一般的なプログラム読解の状況とはだいぶ離れてしまう実験ではありますが、熟練者が、プログラムを眺めただけでその内容を素早く把握できるのは、それまでの経験の蓄積によるものだといえそうです。

 

ソフトウェア開発者は徹夜してはいけない

睡眠は大切とよく言われますが、睡眠不足が開発者に与える影響をまじめに調べた面白い論文が、ソフトウェア工学のトップ論文誌 IEEE Transactions on Software Engineering に掲載されていました。ソフトウェア工学研究室助教の Raula 先生から教えてもらいました。

Need for Sleep: The Impact of a Night of Sleep Deprivation on Novice Developers’ Performance - IEEE Journals & Magazine

 この論文での被験者はイタリアの大学生 45人。Test-First 開発でプログラムを書かせるタスクを行ってもらっています。23人には実験前日に睡眠を控えてもらい、平均で直近20時間程度は寝てない状態になっています。対照群は、前日に平均で6.5時間、通常通り寝た人です。

 これらの人たちに、90分でのプログラミングタスクを実行し、所定の機能を実装してもらい、その作業の成果物や作業自体の質を比較します。評価指標は以下の3つです。

  1. Percentage of acceptance asserts passed (PAAP)、自動受け入れテストにおける全 assert 文のうち、通過できた assert 文の割合。これを開発者が書いたコードの機能の正確さ(functional correctness)として計測します。
  2. #episodes、作業エピソードの数。テスト駆動開発単体テスト作成をして、コードを書いてからテストを実行して pass することを確認する)やテストを最後に実行する開発(コードを書いてからテストを作って pass することを確認する)などの一連の作業順序を、時間内に何回こなしたか、作業量を計測します。
  3. %conformance、指示の遵守率として、開発者が実行した全エピソードのうちテスト駆動開発の割合を評価します。

 PAAP の値の分布は以下の通りです。左端が通常通り睡眠した人々、右端が睡眠不足の23人です。中央が23人のうち本当に睡眠不足と思われる15人を PVT で抽出したものとなっています。

f:id:ishiotakashi:20200730131710p:plain

Fig. 4(a) in Fucci et al. Need for Sleep: The Impact of a Night of Sleep Deprivation on Novice Developers’ Performance, IEEE TSE 2020

 睡眠不足のグループのほうが下側に分布が移動していることが分かります。睡眠不足の23人は、睡眠をとった人に比べてテスト通過率がおよそ半分(平均値 28.57% → 14.36%、中央値 38.46% → 15.38%、第3四分位点 38.46% → 15.38%、最大値は 53.85% で変わらず)になっていました(論文 Table 6)。Mann-Whitney の U 検定で p 値が 5% を下回り、有意差があるという結果になっています。

 ほかの数値についての図は省略しますが、睡眠不足の人は #episodes もおよそ半分に低下しています(平均値 7.5 → 4.2、中央値 9 → 4、最大値 16 → 13)。Assert が通っていないのは、そもそもこなせた作業量自体が下がっていたせいである可能性もあります。さらに %conformance も低下しています(平均値 45% → 25%、中央値 50% → 0%、第3四分位点 73 → 55、最大値は 100% で変わらず)ので、作業手順も守れなくなっていたようです。これらも Mann-Whitney の U 検定で有意差が出ています。

 さらに追加分析として、睡眠不足の人たちは、構文誤りの修正作業が54%増加したとも書かれています。まとめると、睡眠不足だとコードを書くとき構文誤りのような単純なミスも多くなるし、書いてもちゃんと動かないし作業量も減るし手順も守れないと、いいことがまったくない結果となっています。

 結論としては、論文のタイトル通り、開発者はきちんと寝ることが大事であるということになります。この結果は、被験者実験を考えている研究者にとって重要な話で、被験者の睡眠状況の差による影響のほうが、下手をすると開発支援技術などの効果を上回る可能性があります。何かの被験者実験をするときは、被験者には前日にしっかり寝ておいてもらうよう伝えておく必要があるようです。

 

Python は C よりもプログラミング教育に適しているかもしれない

プログラミング言語を C から Python に変えた効果を報告した論文

 プログラミング言語として何を使うと良いのかは重要な問題です。生のコンピュータの挙動が直接見えるC言語と、人気の高い Python ではどちらがよいか、実際にプログラミングの授業で使う言語を切り替えてみた結果を分析した論文 「A Controlled Experiment on Python vs C for an Introductory Programming Course: Students’ Outcomes」 が2018年の ACM Transactions on Computer Education に掲載されていました。

 論文中 Table 1 に授業内容が書いてありますが、全30回の授業で、代入、数式、入出力、条件分岐やループ、配列(Pythonではリスト)、ソーティングなどはまったく同じように教えています。C言語ではポインタとメモリアクセスを扱っていたところが、Pythonでは正規表現と辞書型に置き換わっていますが、全体からみると30回中3回程度なので、大きな内容の変更はありません。

 論文中 Table 2 に詳しい数字と、Table 3 に統計的な有意差の分析があります。それらをまとめると結果は以下の通りです。

  • 途中でドロップアウトする学生の数は変わらない。
  • 合格点(10段階評価で5点)に足りなかった学生 (Fail) の数は、Python のほうが少ないが、統計的に有意な差ではない。
  • 中間試験の平均成績は10段階評価で C言語 6.41 に対してPython 7.08 で有意に上がっている。
  • 期末試験の成績も同様で、C言語 6.72 に対して Python は 7.55 と有意に上がっている。
  • 合格者が提出した宿題(プログラム)のうち、自動テストを通過したものの割合 (Proportion of completed labs) は C言語 76.0% に対して Python 82.3% で有意に上がっている。
  • 合格者が提出した宿題のうち、自動テストを通過するまでに提出した平均回数は C言語 2.91 に対して Pyhon 2.46 で有意に下がっている。

 以上の結果から、Pythonを使うほうがC言語よりも、学生への教育効果が高いのではないかと結論づけられています。毎年、受講している学生の数や試験問題の内容などは異なるので、偶然内容が簡単になってしまった可能性などのリスクはあります(そうでない証拠は出せないと論文中でも記述があります)が、Python を使ったほうが実際に学生は誤りの少ないプログラムを記述でき、学習効果が上がったと考えたほうが自然です。

 開発支援ツールの導入などの被験者実験では、通常、このような大きな違いが明確に出ることは少ないので、言語の切り替えでここまで明確な違いが出ている点は非常に驚きでした。

プログラミング言語の構文の違いは初心者にとって重要である

 Python のどこが良いのか?というのはこの論文単独で明確になっているわけではありませんが、C言語系のプログラムの構文が RubyPython よりも初心者にとっては難しいという指摘が「An Empirical Investigation into Programming Language Syntax」という2013年の論文で出されています。

 こちらの論文では、予約語としてすべて記号を使う人為的な言語 Randomo を導入し、複数の見本プログラム(内容に関する説明なし)を見ながらの一連のプログラミング作業(たとえば変数 x を定義して 175.3 を代入せよ、など)の正確さを評価しています。

 プログラムの見本は、たとえば Javaであれば

public static void main(String[] args) {

    double  x = z(1, 100, 3);

}

となるところが、PythonRuby ならば

x = z(1, 100, 3)

となります。Randomo は、構文自体はC言語系を採用していて、

^ Main {

  ~ x \ z (1, 100, 3)

}

となります(論文 Fig.3 より。~ が変数宣言、\ が代入です)。

 Ruby, Python, Quorum, Perl, Java, Randomo という6つの言語で学生がどのぐらい正しく作業できるかを調べた結果(論文中 Table XXIII)、

  • Ruby, Python, Quorum の3つは Randomo と有意差あり。
  • PerlJava は Randomo と有意差がない。
  • RubyJava とも有意差あり。

という結果になりました。Randomo では、記号の意味も通常とは異なっているにもかかわらず、学生たちは JavaPerl と違わない程度に作業をこなせていたことから、予約語の選び方よりも、初心者にとっては構文の違いが重要であると結論付けています。RubyPython の構文は初心者に優しい、というわけです。

 論文では、プログラミングのどこで間違うのか、構文エラーなしに正しく書けた確率を Token Accuracy Map という名前で可視化して分析しています。Ruby は正確さは一番高かったものの、 for 文における「in」や、数値の範囲を表す「..」の記述を半分以上の人が間違っていると報告されています(論文中 Fig.6)。また、Java における変数の型宣言は、既存研究でプログラマの作業に良い効果があると示されているのに、初心者には優しくない可能性があると指摘されています。

 プログラミング言語が変わっても概念は共通というふうに考えていましたが、この論文の結果からすると、初心者にとって分かるような教え方、どこに重点を置くべきかは、言語によって変えていく必要もあるのかもしれません。

 

文献管理ソフトウェアを使いましょう

文献管理ソフトウェアが必要な理由

研究成果を論文にまとめるとき、研究の動機の説明や、既存技術との比較を行うために、参考文献の引用が不可欠です。ソフトウェア工学研究室で修士論文を書く場合、少ない人で10件、多い人だと40件ぐらい、文献の引用を行うことになります。

 参考文献は、研究を進めるにつれて増えていきます。指導教員が知っている最新の研究や、研究室の先輩の過去の発表を最初の手がかりとして、それらの研究に至るまでの過去の経緯を調べたり、国際会議で新しく発表された論文や、検索して見つけた関連技術の情報などを集めていくことになります。

 ここで重要となるのが、参考文献の既読管理です。ソフトウェア工学界隈に限らないのかもしれませんが、最近は論文誌への投稿と同時に投稿版原稿を公開したり、国際会議の開催前にプレプリントとして採録済み原稿を配布する人が多くなっています。そうすると、論文を検索エンジンで見つけてから1年後に実際の論文誌の出版が行われ、その内容をさらに国際会議での発表(Journal-First 発表と呼ばれます)として再発見する、といったことが起こります。自分が読んだものをきちんと記録していないと、論文を読んでいる途中でようやく過去に読んだ論文と同じであることに気づくといった時間の無駄が発生します。また、文献を引用するときになって、実際の記述がどうだったかを再確認したくなることもしばしばありますから、自分が確認した PDF をきちんと保管していなければ、論文誌などの Web サイトからダウンロードしてくるところからやり直しとなってしまいます。

 文献管理ソフトウェアは、自分が集めた論文の PDF と文献引用のための書誌情報を管理し、上記のような作業の負荷を軽減してくれるツールです。本格的に論文を読み進める必要があると感じたら、ぜひ使ってほしいツールでもあります。世の中には複数の文献管理ソフトウェアがありますが、学生が修士論文で集める程度の利用規模であれば、無償で使えるものも多くあります。

おすすめは Zotero と Mendeley

 ツールの利用には、かなり好みが入りますが、筆者は Zotero を使っています。他に勧められるものとしては Mendeley を挙げます。これら2つのソフトウェア、Windows 版での話ですが、共通してできることは以下の通りです。

  • Web ブラウザ用のプラグインを使うと、ACMIEEE などの Digital Library を開いた状態から、直接 PDF と引用のための情報をデータベースに取り込めます。
  • 文献の出自(DOIなど)が分かる PDF をドラッグ&ドロップで放り込んでも、書誌情報を自動で探して取り込んでくれます。
  • 取り込んだ文献をダブルクリックすれば PDF を開くことができます。
  • 取り込んだ文献を選択して「BibTeX としてコピー」といった名前の操作をメニューから選ぶだけで、引用のための文献情報を取り出すことができます。
  • PDF などのデータをクラウドサーバ上に保管し、PC間で同期してくれます(DropboxEvernote などと同様です)。

 これらの機能だけで文献の PDF をいつでも参照できるようになりますし、引用するときに必要な BibTeX も簡単に取り出せるようになります。Zotero には、これに加えて、以下のような便利機能があります。

  • 1つの文献情報に、複数のファイルをドラッグ&ドロップで簡単に関連付けられます。たとえば発表スライドを一緒に保存しておけます。
  • ファイルの関連付けと同じ仕組みで、テキストメモを論文に付けることができます。このメモは、 文献情報(BibTeX 形式)の一部としていつでもツール外に取り出すことができます。
  • 文献に子要素としてテキストメモやファイルがぶらさがっているので、それらをドラッグ&ドロップだけで別の文献情報に移動できます。そのため、たとえばプレプリントに対応する出版された版を発見したときに、論文のテキストメモだけを移動して付け替えるといった編集操作が容易です。
  • ドラッグ&ドロップで PDF を簡単にファイルとして取り出せます。

 研究室では Slack で参考文献の PDF ファイルをやり取りすることが多いため、筆者の場合は、このドラッグ&ドロップでの操作が非常に便利であると感じます。Mendeley は、どちらかというとファイルを取り込んだら Mendeley 利用者間でのみ共有することを想定しているようで、ファイルの取り出しにはエクスポート機能をわざわざ呼びだす必要がありました。

 筆者の場合、Mendeley を使い始めてそれほど時間が経つ前に Zotero を見つけてしまったので使い込むには至りませんでしたが、Mendeley にも特有の強力な機能があります。

  • PDF を全文検索することが可能です。キーワード列を入れると、各 PDF ファイルのどこにマッチしたのか、その文章の内容まで論文一覧画面に一緒に表示してくれるます。これが、蓄えた文献の中から必要なものを探すときだけでなく、英語で論文を書いているときの文例の確認にも使えます(Zotero では書誌情報に書かれた Abstract やテキストメモの検索まではできますが、PDF 内の本文は検索できません)。
  • PDF 内部に注釈を簡単に書き込むことができるので、後から論文を読み直すときに注目すべき場所などにマークをしておくことができます(この注釈は検索の対象外という制限はありますが)。

 Zotero と Mendeley を比べてどちらが良いかというと、どの機能を重視するかによります。また、機能的な違いに加えて、ツールのユーザインタフェースにもかなりの違いがあります。2つのソフトウェアは1つのPCに共存できるので、いくつか手持ちの PDF ファイルをこれら2つに実際に登録してみて、その挙動を確認してみると良いのではないかと思います。個人的には、Zotero のほうが、同期機能でどこに何が保存されるか、データのバックアップをどのように行えばよいかなど、システムとしての挙動が把握しやすいという印象ですが、そういうところまで含めて好みがあるので、自分の判断でしっかり選んでみてください。

 

 

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 が無事発行されました。目次は 情報学広場:情報処理学会電子図書館 から閲覧することが可能です。この号は2つの特集が相乗りしているので見つけにくいかもしれませんが、少しスクロールしたところにある "特集「ソフトウェア工学」の編集にあたって" という原稿に続く12編が特集号に採録された論文です。

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

 

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

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個で調査したものが以下の図になります.

f:id:ishiotakashi:20200131113113p:plain

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


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

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

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