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

ソフトウェア工学の学術研究を紹介しています。ここではソースコードなどのプロダクトが研究の主役です。

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 という指標自体の性質を調べることが,今後の課題となっています.

 

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

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

www.jstage.jst.go.jp

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

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

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

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

 

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

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

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

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

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

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