SEA関西「エンピリカルソフトウェア工学の実践」(2008)

1. エンピリカルソフトウェア工学の
実践
SRA先端技術研究所
阪井 誠

2. エンピリカルソフトウェア工学
– エンピリカル（Empirical）とは「Experimental + Experienced
」を足し合わせた言葉で、「Experimentalとは実験に基づく」「
Experiencedは経験に富む」という意味である
松本, “【バグ管理の作法】エンピリカルソフトウェア工学に触れる”,
http://www.thinkit.co.jp/free/article/0712/3/1/, Think IT, 2007.
– 実証的なソフトウェア工学ともいわれ、ソフトウェア開発プロ
ジェクトを測定、定量化し、それを分析しフィードバックするこ
とにより、プロジェクトの状態を把握して生産性向上と品質の
改善を実現しようというものである
ソフトウェア・エンジニアリング・センター, "エンピリカルソフトウェアエンジニアリ
ングの勧め", 翔泳社, 2007.
– 1970年代から実践されている
D. R. Jeffery, L. G. Votta, "Guest editor's special section introduction,"
TSE25-4, IEEE, 1999.
2

3. EASEプロジェクトのモデル
(Empirical Approach to Software Engineering)
• ソフトウェア開発の分野において、他の科学、工学分野と同
様に、計測、定量化と評価、そしてフィードバックによる改善
という実証的手法（エンピリカルアプローチ）の実践を目指す
3
収集
改善 分析
http://www.empirical.jp/
Experimental
+
Experienced
メトリクス

4. D. Ross Jefferyらの関係モデル
D. R. Jeffery, L. G. Votta, "Guest editor's special section introduction,"
TSE25-4, IEEE, 1999.
理論
現実世界
（ESE) モデル
研究課題 仮説
研究デザイン
研究結果

5. 目次
• メトリクス
– ソフトウェアメトリクスの歴史
– メトリクスに求められるもの
– メトリクスの分類
• 実験
– モデリング
– 仮説、実験(in vitro/in situ)、結果
• 研究事例
– EPM
– WebTracer
– XPプラクティスの評価
• ふりかえり

6. メトリクスの歴史あるいは光と影(1/2)
1. 1968-1977： 混乱期
• 1968年NATOの会議「ソフトウェアエンジニアリング」と
いう言葉が始めて使われた
• 職人芸からサブルーチンへ
• 工程、品質、コストを制御できず。これに対する危機感
があった
2. 1978-1982： 胎動期
• (絶対零度の) ケルビンの「計測できなければ制御でき
ない」を「計測すれば制御できる」に読み替えた
• ソースコード行数、バグ数のほか、マケイブのサイクロ
マティックナンバー、ハルステッドのソフトウェアサイエ
ンスが提案された「信ずるものは救われる」
山浦,「日本語版に寄せて－10分でわかるメトリクス－", 「初めて学ぶソフトウェアメト
リクス」(Lawrence H. Putnam & Ware Myers著), 日経BP社, 2005.

7. メトリクスの歴史あるいは光と影(2/2)
3. 1983-1987： 活動期
• 実地で適用、相関の研究が盛んになった
• 「即行動派」とは別に「慎重派」はメトリクスの意味を見
直し始めた(根拠、対象、計測時期)
4. 1988-1992： 反抗期
• 費用対効果から幻想が消え、メトリクスを疑問視
• 現実的な考えから、品質そのものを計測しようとした
• ソースコード行数と発生バグ数に回帰した
5. 1993- ： 成熟期
• 世間一般の流行品と同様、一部ではメトリクスが定着
し、効果を上げた
• 行数、バグ数を軸に、各組織で独自のメトリクスを開拓
し、メトリクスの目的、意味、意義を自覚し始めた

8. メトリクスに求められるもの
• 捏造せずに正しい値を申告し、効果的、実践的に使
うには以下の条件を満足する必要がある
– 計測に時間、労力がかからない(自動計測が理想)
– 安く計測できる(ＮＡＳＡでは収集・分析に総コストの3％、
処理と分析に4～6％かかるby Rombach)
– 客観性がある(誰が計っても同じ結果になる)
– ソフトウェア開発の作業、要素と強い相関関係がある
– 個人の査定目的で使わない(開発目的のみ)
山浦,「日本語版に寄せて－10分でわかるメトリクス－", 「初めて学ぶソフトウェ
アメトリクス」(Lawrence H. Putnam & Ware Myers著), 日経BP社, 2005.

9. メトリクスの種類
• 比例尺度(ratio scale)
– 数値の差と共に数値の比にも意味がある
• 間隔尺度(interval scale)
– 数値の差のみに意味がある
• 順序尺度(ordinal scale)
– 順序のみに意味がある
• 名義尺度(nominal scale)
– 観察される変数と数値を対応させる(分類として記号の意味
を持つだけ)
※下位の尺度データに適用できるすべての統計手法は，上位の
尺度データにも適用できる．ただし，逆は成り立たない
楠本, “ソフトウェアメトリクスの研究動向”, 第４回エンピリカルソフトウェア工学研究会,
2004.http://www.empirical.jp/download/past/publicdata/4th_kenkyukai/shiryo2.pdf

10. モデリングの目的
• モデルの基本的な使われ方
– 効果的なコミュニケーションを可能にする
– 再利用を容易にする
– 進化を可能にする
– 管理を容易にする
＝＞対象を「見える化」すること
W. S. Humphrey, M. I. Kellner, "Software process modeling: Principles of
entity process modeles," ICSE89, pp.331-342, ACM, 1989.

11. 仮説・実験・結果
• 仮説が容易に立証できるとは限らない
– 具体的な仮説ほど立証しやすい
– 理論・モデル・仮説を修正しながら繰り返す
– 新しい発見をすることがある
• 結果の評価が必要
– 実験方法(in vitro/in situ)と客観性
– 正しいとは限らない(後述)

12. in vitro法とin situ法
• イン・ビトロ(in vitro)法
– 「試験管(ガラス)内で」
– コントロールされた実験
– ノイズが少なく客観性が高い
• イン・サイチュ(in situ)法
– 「本来の場所にて」
– 現実的な実験
– ノイズが入りやすく客観性が低くなりやすい

13. 実験
• ノイズを避ける
– 評価項目の組み合わせ
– 被験者の組み合わせ
– 統計処理
– 詳細な分析
• 同じソフトウェア開発は2度できない
– 人は学習してしまう
– 試行のコストが高い
＝＞可能な情報はなるべく収集する

14. (XP/TSPが) 結果が正しくない可能性
素晴らしい成功を収める理由
• 本当に銀の弾丸であり、必ず素晴らしい成功を収める
• 人は失敗より成功を報告する傾向にある
• 先駆的プロジェクトは、新しい手法をいち早く取り入れ
る、かなり有能な人々によって実施されている
• 先駆的プロジェクトにはホーソン効果が働いており、注
目を浴びている間は非常に素晴らしい成果をあげるこ
とができる
• これらのプロジェクトは過去の特に効率の悪かったプロ
ジェクトと比較されている
B. Boehm, R. Turner”アジャイルと規律 付録E 経験的な情報” pp.283-284, 日経BP, 2004.

15. 研究事例
• EPM
• WebTracer
• XPプラクティスの評価

16. ふりかえり
• EPM
– 計測に時間、労力がかからない(自動計測可能)
– 計測コストの削減できる
– 仮説の抽象度が高く、多くの検証が必要
• WebTracer
– ユーザビリティとの相関を評価した
– 通常の操作に近く現実的な実験
– ノイズ(個人差)があり、複数の実験が必要
• XPプラクティスの評価
– モデリングによりコミュニケーションが容易になった
– 導入工数に対して比例尺度とは言いきれない
– 仮説と結果が異なる

17. まとめ
• エンピリカルソフトウェア工学とは、科学的に
ソフトウェア工学を行うこと
– データ収集、分析、改善
– 注意すべき点は多い
– 現場での実証が重要
– コミュニケーションのツールになりうる
=>ぜひ、エンピリカルソフトウェア工学を実践し
てください

18. おわり