段階と粒度

今回からエンピリカルソフトウェア工学の最新の研究成果を紹介していく。取り上げる例は「マルチベンダー開発における障害修正工数の要因分析」と「オープンソースコミュニティのコミュニケーション構造分析」だ。

エンピリカルアプローチは具体的な目標、対象、技術、ツール、成果は非常に多岐にわたるため、「段階」と「粒度」の2つの軸で整理しよう。

3つの段階

エンピリカルアプローチには「観察（Empirical observations）の実施」「法則（Laws）の発見」「理論（Theories）の確立」の3つの段階がある（A. Endres、D. Rombach著、吉舗紀子訳、EASEプロジェクト監修、ソフトウェア工学・システム工学ハンドブック：エンピリカルアプローチによる法則とその理論、コンピュータ・エージ社刊、2005）。

しかし、ソフトウェア開発は人間を含む数多くの要素で構成されており、第3段階の「理論の確立」には「観察の実施」と「法則の発見」に多くの時間と労力が必要となる。「産」の立場から実用的なアプローチとして、発見された法則を「開発支援に利用する」ことを考えていこう。

例えばソフトウェア開発プロジェクトにおいて、開発規模と開発工数のデータを収集し、統計的に処理することで「開発工数（人月）＝3.0×開発規模（KLOC）^1.12」といった式が得られたとする。これは観察の実施であり、法則の発見である。

こうした式が示されると、理論が確立されたかのように考えがちになる。しかし、それは早合点である。「y＝a×x^b」という式で規模と工数の実績値の関係があらされるとすれば、a=3.0、b=1.12とするのが統計的にもっともらしいというだけのことである。

では、この式が役に立たないかといえば、そんなことはない。プロジェクトの計画段階において、何らかの方法で開発規模が1,000KLOCと見積もられたとすれば、この式を用いて、開発工数はおよそ521人月であると予測することができる。

このようにエンピリカルアプローチによって理論の確立まではいたらなかったとしても、支援の実現は十分可能なのである。次にもう1つの軸であるデータ収集や分析対象の「粒度」を解説する。

3つの粒度

粒度には「インプロセス」「プロダクトライン」「リポジトリ」の3つがある。

インプロセスは、単一プロジェクトにおける時系列での観察や法則発見と、開発リスクや進行状況の見える化・予測である。プロダクトラインは同一ソフトウェアの異なるバージョン間での観察や法則発見と、品質リスクや保守リスクの見える化・予測である。リポジトリは終了した多数のプロジェクトでの法則発見と、開発組織としての傾向や規則性の見える化・見積りである。これはソフトウェア開発の「見える化」の粒度だ。

インプロセスは粒度が細かく、時系列を含めた詳細な分析が可能となるが、分析結果の適用可能範囲は一般に狭い。プロダクトライン、リポジトリと進むに従って分析対象や範囲は広くなり、分析結果も広く適用できるが、データ収集のコストや制約が大きくなるため、収集されるデータは多くの場合限定される。また、「サンプリング」や「はずれ値除去」などデータや分析結果の均一性を保つ技術も必要となる。

どの粒度でデータ収集や分析を行うかは、その目的によって決まるが、用いるデータ収集・分析技術は粒度によって異なる場合があり注意が必要だ。では、「段階」と「粒度」の軸を念頭におきながら、具体的な研究成果をみていこう。 次のページ