バグ票の公開範囲を広げると何が起こるか

テストの一部を委託し委託先から1週間単位でレポートを提出してもらっていたものを、バグを見つけ次第委託元のバグ管理システムに直接入力してもらい、結合テストやシステムテストの間に委託元が蓄積していたバグ票も参照できるようにした事例がある。これをソフトウェア開発の透明化の1つと位置づけている。同一プロジェクト（同一サブシステム）の単体テストの終盤以降、委託元で入力されたバグ票も全て委託先からもみれるようにする。

公開前までは「あんなバグがまだとれてない。。未熟だ。」「こんなのをコーディングのときにとれていないなんて。。悲しい。」というようなネガティブな面ばかりが明らかになってしまったらどうしようという懸念が多数あったが、実際やってみると「余計なコミュニケーションが減り、スピードアップにつながる」「逐次入力されていることがわかるので、お互いゴールにむかってがんばっている様子が伝わってくる。」「過去のバグ票から傾向がわかったり弱い部分がみえてくるので回帰テスト選択の判断基準とできる」「未修正かどうかがわかるのでテストの順番を状況にあわせて変更できる」等のポジティブな意見と「今後も続けたい」という話があがったそうだ。現場担当者からは一体感が出るので続けたいという話も出た。

何でも公開すればよいというものではないが、可能なものはなるべく透明化、共有することでリーダやマネージャだけがすべてを判断するのではなく、個々の状況把握と判断を促すことができるだろう。また、透明化による一体感の側面も注目すべき点の1つだ。

ソフトウェア開発の透明化は今後のソフトウェア開発の方向性の1つとして検討が進んでいる。たとえば、ドイツではフラウンホッファーのSoftPITプロジェクト（ここで書いた）、日本では文部科学省「次世代IT基盤構築のための研究開発」の1つとして採択された「エンピリカルデータに基づくソフトウェアタグ技術の開発と普及」（研究代表者 松本 健一（国立大学法人奈良先端科学技術大学院大学）がある。