「少人数のチームの方がソフトウェアの品質は高い」実証的ソフトウェア工学の研究会が開催
統計や実証を通してソフトウェア工学を研究していく、それが「エンピリカルソフトウェア工学」（Empirical Software Engineering、実証的ソフトウェア工学）です。「第一回エンピリカルソフトウェア工学研究会」が、12月10日に都内で開催されました。
基調講演では、マイクロソフトリサーチで研究をしているDr. Thomas Zimmermann氏が登壇。開発組織の構造がソフトウェアにどう影響するのか、バグ報告書やバグ報告者と修正されるバグの優先順位の関係、そしてエンピリカルソフトウェア工学という「データ指向のソフトウェア工学」を、どのようにソフトウェア開発における意志決定に役立ていくのか、といった内容の講演でした。
開発組織の構造がソフトウェア品質に及ぼす影響は？
マイクロソフトリサーチのDr. Thomas Zimmermann氏。
今日はいくつかのテーマについて紹介したいが、1つ目に紹介するのは、組織の構造がソフトウェアの品質にどのような影響を与えるか。彼らの論文を紹介したい。
ソフトウェア開発の世界では、次のような法則があると言われている。
コンウェイの法則： 組織の構造が、システムの設計にも大きな影響を与える。
ブルックスの人月の神話： 組織の構造がプロダクトの品質に大きな影響を与える。
しかし組織が実際にどれくらいソフトウェアの品質や構造に影響を与えるかは分かっていなかった。それを研究したものだ。
ソフトウェアの品質に与える要因を数値化したメトリクスには以下のものがある。
- 変更の回数
- 変更を行った開発者の人数
- 会社を辞めた人数
- 関係者のまとまり
4つ目の要因を詳しく説明すると、あるコンポーネントの変更を行うチームがそのコンポーネントを所有しているかどうか、また、どれくらいの数のチームがあるコンポーネントの変更に関わっているか、ということ。
組織に関する事柄を数値（メトリクス）で表すための例を示そう。ここにあるプロダクトに関わる7人のエンジニア（E1～E7）がいて、その上に複数レイヤにわたるマネージャ（M）がいる。
オレンジの数字はプロダクトへの変更回数を表しており、マネージャの横の数字はそのマネージャの管理下にあるエンジニアの変更回数の合計である。トップレベルのマネージャの配下には合計で30人のエンジニアがいて200回の変更を行った。
また、ほかにもトップレベルのマネージャがいて、そこに40人のエンジニアがいて40回の変更が、また別に30人のエンジニアを抱えるトップレベルのマネージャがいて、そこからは10回の変更が行われていた。
あるコンポーネントをどのチームが所有しているかは、そのコンポーネントの変更に75％以上関わっているチームがそのコンポーネントを所有しているとみなした。この75％には経験から得られた数値だ。
そして実証の結果、いくつかの結論を得た。
組織構造の縦方向が短い方がソフトウェア品質がいい。マイクロソフトなら、トップレベルにビルやスティーブが入ると縦方向に伸びるのであまりよくないだろう（笑）。
多くの人がコードに関わると品質は下がる。またオーナーとなるチームもコンウェイの法則で言うとおり、少人数や、結束力の高いチームで開発した方が品質が向上することも確かめられた。
また、こうしたソフトウェアの複雑さ、変更された行数、依存関係、組織の複雑さなさまざまなメトリクスを用いて、あるモデルを用いてソフトウェアのバグの発生率を予測した結果、よい予測精度を得ることができた。
少し分かりやすい例を示す。
1つ目はバグが発生するリスクの低い例。青い色が組織、緑の輪が1つのバイナリ、赤が新機能、星が変更を示す。
この図では、赤い丸の新機能を追加するときに3カ所の変更が行われたことを示している。これが1つの組織の中ですべて行われていれば、バグが発生するリスクは低い。
次はリスクの高いパターン。組織をまたがってバイナリが存在し、新機能も変更部分も散らばっている。これは問題が発生する典型的なパターンだ。
3つ目は、潜在的なリスクを含んでいるパターン。複数の組織によってあるバイナリに対して新機能の追加なしに変更が行われる。こういうときには、お互いの変更に気付かず、いつの間にかバグを抱えてしまうという可能性が高いのだ。
分散拠点の開発は品質にどう影響するか？
もう1つ、分散した拠点による開発がソフトウェアの品質に与える影響についての論文を紹介しよう。「Does Distributed Development Affect Quality？」という論文で、Christian Bird、Nachi Nagappan、Prem Devanbu、Harald Gall、Brendan MurphyがICSE 2009で発表したものだ。
最近では分散した拠点での開発が一般化してきている。それに対して多くの研究も行われたが、ここでは品質に対する影響を紹介する。対象は、マイクロソフトのWindows Vistaの開発である。開発中にさまざまなメトリクスを収集し、リリースから6カ月後の品質結果と照合した。
これが集めたメトリクスのデータを示している。あるコード（cmroute.dll）に対して、そのソースコードを編集したエンジニアが、どのビル、どの拠点、どの大陸にいるのかの図だ。
いちばん望ましいのは、同じビルの中にいるメンバーでコードへの変更が行われていることであり、大陸をまたがって変更するのはあまりよくないと言える。この例は比較的よい方で、コードへの変更の68％が同じビル内のメンバーである。
そしてこの研究目的は、こうした分散した開発の情報から、ソフトウェアの欠陥がどれだけあるのか、を予測することだ。
結果、エンジニア同士の距離がどれくらい離れると、どれくらいバグが増えるかは、ビルが異なると2.6％増加、カフェテリアが異なると3.9％増加、キャンパスが異なると6.3％増加、地域が異なると8.3％増加、大陸が異なると -3.9％となった。
こうしたグローバルな開発でWindows Vistaの開発がなぜうまくいったか？ 推測される理由は、アウトソーシングではなく同じ会社の中で分散開発したから。また、顔を見ながらのミーティングができる環境があり、レドモンド（マイクロソフト本社）で最初に教育を受けたエンジニアがそれぞれの国に帰って分散開発をするという形をとったから、などが挙げられる。
さらに、コードに対する所有など、クリアな構造とコミュニケーション手段を持っていることも特徴の1つだと言える。
エンピリカルソフトウェア工学はどうなるか？
エンピリカルソフトウェア工学（実証的ソフトウェア工学）はこの先どうなるか、について。
2つの研究分野。ソフトウェアリポジトリからのマイニングと、エンピリカルソフトウェア工学、この2つが1つの「ソフトウェア開発分析」（ソフトウェアデベロップメントアナリティクス）へ統合されていくと考えている。
分析（アナリティクス）は、金融、小売り、製造といったさまざまな分野において意志決定のために使われている。
以前、Webサイトの分析と言えばページビューを計測する程度のものだったが、いまでは顧客の振る舞い、嗜好、注目しているものなど、多くのことを知ることができるようになった。ソフトウェア開発分析もこのように進化していくことができるだろう。
この図は、ソフトウェア開発分析の研究者と開発者の典型的な関係をあらわしている。研究者はデータを分析するが、開発者は「で、それでどうすればいいの？」と疑問を投げかける。
研究者は分析方法を知っているが、それを用いて判断するにはプロジェクトごとの背景や現状を知る必要があり、その知識はプロジェクトメンバーが持っている。
それぞれのプロジェクトは異なっていて、画一的な知見や手法を提供する訳にはなかなかいかない。研究者は分析手法などについて知っているし、開発者はプロジェクトの背景についてはよく分かっている。
そこで、両者の間を取り持つ人が必要だと私は考えている。データ分析についても、プロジェクトの背景についても理解できる人だ。
しかも正しい判断を下すために必要な情報を得るには1つのツールでは不十分で、この局面ではこういうやり方、この局面では別のやり方。例えば定性的なアンケートや定量データ分析など、さまざまな方法が必要だろう。
公開されたプレゼンテーション
Zimmermann氏は大学での研究者から、最近になってマイクロソフトリサーチへ移籍したとのこと。エンピリカルソフトウェア工学では多くの実証データが必要ですが、世界最大のソフトウェア企業であるマイクロソフトの開発リポジトリへ自由にアクセスできる立場は、実証研究にとって非常によい立場（もしかしたら世界でもっともよい立場）なのだろうと想像できます。
下記が、この講演のスライドです。記事で割愛した部分も含まれていますので、ぜひ参照してみてください。
関連記事
Publickeyではこれまでにも興味深く優れたソフトウェア分野の講演を記事にしてきました。その中でも以下の記事は特に面白いと思うので、あわせてぜひお読みください。
あわせて読みたい
