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

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

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

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

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

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

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

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

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

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