で、どんな規則性がみつかったか？
前にどのようなデータを対象として規則性をみつけるか対象データ例を述べた。今回は、どういう規則性がみつかってどういうことがわかったかを述べる。ここを読まれている方には手法についてあまり細かく書いても退屈なのではないかと思うので割愛する。興味がある方はここをご覧いただきたい。本エントリは上下巻の「下」の位置づけなので、「上」部分についてはここをご覧いただければと思う。
これまでの適用事例は以下のとおりである。
- 出荷後の障害対応日数に関するデータ
日立システムアンドサービス十九川氏の講演資料がここにある。 - プロジェクト毎の品質データ（各開発工程での問題指摘密度（設計等）不具合密度（製造工程以降）、試験密度（各試験工程以降））の記録
日立システムアンドサービス十九川氏の講演資料がここにある。 - プロジェクトデータ（プロジェクトプロファイル、規模、工数）から抽出したルールに関する論文（日本ユニシス様のプロジェクトデータ）
- 国内大手ベンダによるマルチベンダ開発時のバグ票（各バグについて修正工数の記録を含む）のワークショップ報告
- ソースコードメトリクスとバグの関係（NASA公開データ）
現在公開にむけて準備中
1, 2でわかった規則性とそれをもとに得られた知見をピックアップしたものが以下である。3, 4については10/25(木)のエンピリカルソフトウェア工学研究会で講演する予定である。5は11/9「ソフトウェア工学の基礎ワークショップ」で亀井氏が発表する予定である。
- 特定の原因での発生障害（SE作業や特定部署のプログラム不良）が即日解決される傾向がある。（出典: 十九川氏の資料8ページ）
- 早い段階のテスト工程（単体テスト）で検出不具合密度が非常に大きかったものは全体の不具合密度が大きくなる傾向がある。（出典: 十九川氏の資料11ページ）
たとえば、1.をもとに、クリティカルな部分への作業アサインやリスク評価、運用フロー、SLAの精査が可能になるだろう。2.では、試験の早い段階で、ソースコードレビューの実施判断や不具合予測、分割リリース等の検討をするための材料となりうるだろう。（この部分は個人的な見解である）
こういう話をすると「データだけみてもしょうがない」という話をいただくことが多い。言い訳がましいのだが、当然私もデータだけみてればよいと思っているのではなく「何らかのプロセス改善を試みようとする際に、データ収集だけで何かを語るのは不十分である。データは品質を問わなければ（実態を表していようがいまいが）それなりに集めることができるし、可視化したり何らかの数学的手法を用いればそれなりの結果が出ているように思えてしまう。まずは根本原因やまずいことが起こっている状況を様々な観点からつぶさに分析する必要があるだろう。」という意図があること付け加えておく。
ではなぜデータを中心としたエンピリカルな分析をするかというと、上述は確かに正しいし、スジが通っているのだが、実際にそういうことをやろうとすると、観点がばらばらすぎて意見がまとまらなかったり、特定の声の大きな人の意見になったりして、仮に結論が出たとしても、みんなのものという実感が薄く定着していかないのが現実ではないだろうか。今回紹介した話は、根本原因やまずいことが起こっている状況を比較的客観的規則として提示でき、議論が集中しやすかったり、定量的な話がやりやすかったりすることがポイントであり、挙げたような制約を比較的スムーズに解決できるのではないかと考えている。