日本科学技術連盟機関紙に「定量データ収集のインセンティブ」を寄稿した

2009/09/25

ソフトウェア開発状況を把握するために計測をしても見返りが少ないという問題はソフトウェア開発に携わっていれば、一度は聞いたことがある話ではないだろうか。ここでの定量データは、不具合密度や開発規模のような数値データを指す。

定量データの目的の多くは進捗把握、リスク検出であり、データの利用者はプロジェクトマネージャやプロジェクト支援部門といった組織であることが多い。いっぽう、データを収集するのは多くの場合、開発担当者だ。

表題のインセンティブは、データを収集する側にとってのインセンティブを指している。本来これらの定量データは、兆候を発見したり、潜在的問題がないかをスクリーニングするためのものであり、このデータさえモニタしておけば大丈夫、という類のものではない。

しかしながら、数値化された結果、数字がひとり歩きしてしまうことが多い。たとえば、不具合検出密度は事前に設定した上限値、下限値、目標値等と実績値を比較して、テストの良しあしを推測することを目的としている。あくまで推測なのだが、いったん数値になってしまうと、数値のみにとらわれてしまうことが往々にして起こる。

「不具合検出密度（一定規模あたりの発見不具合数）が下限値に達してないなんて、いい加減にテストをやっているからだ。見直してこい。」、「上限値を超えてるなんて、成果物の品質が低すぎる。全部再レビュー」のように、中身を精査することなく判断されたりする。

こうなるとインセンティブがないどころか、つるし上げの材料になってしまう。本当は、そう指摘されても問題がないことをきちんと示したり、数値ではわからない問題を挙げて、プロジェクトマネージャや支援部門と相談すべきだが、結果として、データ収集する側が、報告の際に数字合わせをしてしまったり、解釈を変えたりして、そもそも指摘をされないようにしてしまうことがある。虚偽の報告は収集の意味自体をなくしてしまうのだが。。

記事では、これを回避することを目指した一事例として、以下を実施したプロジェクトを紹介している。

数字合わせが難しいデータの収集（虚偽の報告の防止）
データから異常が検出されなかった場合には定例の進捗報告の一部を省略（収集側のインセンティブ）

日本科学技術連盟の機関紙の情報はこちら。

森崎

2009/09/25 8:28:00

Comment(1)

trackback(0)

Special

- PR -

最新の投稿

コメント

のりぶー

2009/09/26 17:55

不具合検出密度が上限/下限閾値から逸脱すると確かにPMOから指摘が来ます。
その都度状況を説明（ex.　下限値を下回った場合は、上位（先行）プロセスで十分なエラー検出済み。上限値を上回った場合はソフトウェアの構造上LOCよりも試験ケースが大きい、等々）と説明し、その後の再指摘/確認もなく終わってしまっています。
一部で、指摘を恐れて不具合数を「調整」した、という話を聞いたことも有ります。。
そもそも不具合検出密度の上限/下限閾値には一般的な根拠が有るものなのでしょうか。
分母のソフトウエア規模も未だにLOCを使っていたりしますし。FPやFPに類似する測定値の方が良いのでしょうが、これらの手法は結局のところ経験的な回帰係数が必要なため、それらの経験値の蓄積が無いと使えない、使えないからLOC、だから蓄積しない・・・という実情が有るような気がします。

コメントを投稿する