ソフトウェア開発データ白書２００９の効果的な活用法
IPA SEC 主催の「ソフトウェア開発データ白書２００９の効果的な活用法」に参加した。
IPA SEC で収集し、公開しているソフトウェア開発データ（ソフトウェアメトリクス）の効果的な利用方法についてのセミナー。とても人気のセミナーで、募集開始後、30分で満席になったとか。16日の追加開催分も30分で満席になったとか。
「ソフトウェア開発データ白書2009 (SEC BOOKS)」を見たことがある人も多いと思うけど、当白書では、規模、工期、工数、信頼性（不具合件数など）を FP や LOC といった規模、業種などの層やカテゴリに分けて傾向を分析し、自プロジェクトの評価可能な数値として提供している。
本日のセミナーでは、各自のプロジェクトで収集した定量データを白書のデータと同じ軸にプロットして妥当性などを評価し、リスクがあればどのような局面でどのような対策を取るのかについて、事例をもとに分かり易く解説していただいた。局面としては、(1)見積り、(2)計画、(3)コントロール、(4)評価 の４局面で解説いただいた。
ちなみに、IPA SEC が収集したデータや、そのデータを活用したプロジェクト診断ツールは、IPA SEC のサイトで公開されている。白書自体も、PDFで無償で公開されている。
所感
内容をつらつらと書いても仕方ない（それも価値があるけど・・）ので、TIPS と感じたことのみ書く。聴いて考えたことであり、お話いただいた内容そのものではない。
自分の会社やプロジェクトにとってどんな意味をもつかが重要である
数値や傾向自体にはさほど意味がない。自分のプロジェクトの規模に対する工数が一般的な値からどれくらい外れているのか、等は重要ではない。
例えば、規模に対する工数が、自社では常に平均より少ない⇒少ない工数で開発できる強みを持った会社であるとか、
規模の割に少ない工数で開発する計画のプロジェクトはリスクが高いので、モニタリングをしっかりしなくてはいけないとか。
定量データは操作できるデータである
よく言われることですけど。定量データは客観的で絶対なものと思われると大間違いということ。何を ALL とするか、どんな軸で分析するか等は裁量が入るため、定量データ自体も主観を排除できないということ。
とはいうものの、定量データを評価の軸として使用することは大きな意義がある。その場合には、どういう性格のデータかを十分に理解した上で使うべし、ということ。
数字はリスクを検知するためのもの。妄信しない
定量データと比較してある程度機械的に評価がでたとしても、それを鵜呑みにするのは誤り。許容範囲から外れた値を見つければ、アラートを検知できるため、早期にリスクを把握して対策を打ったり、原因を調査したり、重点的にモニタするために用いるのが有効。
例えば、工期が許容範囲よりも短いプロジェクトとか、工程ごとの工数配分が大きくブレていたり、といったことがアラートである。
傾向は平均値でなく、中央値に現われる
分布から大きく外れた値があると平均値は変動するため、平均値で判断するとブレが大きい。中央値が傾向を現す。
開発プロセスや開発手法が異なる場合の比較、評価が難しい
IPAでは、開発工程を (1)基本設計、(2)詳細設計、(3)製作、(4)結合テスト、(5)総合テストの５工程に分けている*1。プロセスは会社により様々な分け方をしているし、反復型の場合にはそのまま適用するわけにはいかない。また、規模を「クラス数」で把握するような場合や、ユースケースポイント*2を使用している場合にはそのまま使えない。自社のプロセスに合わせたデータを収集し、白書のデータはプロセスの読み換えやマッピングを行った上で参考に使うのがよさそう。その場合でも、分析結果から導き出された一般原則は適用できると思われる。たとえば、規模が大きくなると生産性は落ちるとか。
データ提供企業数がなかなか伸びないのは、開発手法の違いのため、そのまま提供できない企業が多い（？）のも一因なんじゃないのかな。
ところで見積りやら品質やらの資料を見るたびに違和感を感じるんだけど、FP や LOC ってまだ使われてるのかー。FP は使われていると思うけど、LOC って・・。ウォーターフォールも普通なのかな？
おまけ
例によってお土産付き。これはすごい。本がもらえることも目当ての一つとしてい人もいるらしい。
- 作者: 情報処理推進機構ソフトウェア・エンジニアリング・センター
- 出版社/メーカー: 日経BP社
- 発売日: 2009/09/10
- メディア: 単行本
- 購入: 1人 クリック: 13回
- この商品を含むブログ (4件) を見る
