[#TiDD] 良いソフトウェアを作るためのメトリクス

私は駆け出しのプログラマーだった頃に結婚しました。式の最中に、司会をお願いした友人から「どのような仕事がしたいか？」と突然質問されました。ふと出た言葉が「だれもが使いたくなるようなプログラムが作りたい」でした。ソフトウェア開発は「超マシン誕生」のように無から有を作り出すセクシーな仕事だと思いますし、今も良いソフトウェアを作りたいと思っています。

昨日の記事「リスクベーステストを考える」を書きながらも変なことを書いている気がしていました。今日になってJSTQBのサイトなどを眺めながら思ったのは、

「テストは品質保証という管理行為であり、(今のところ)信頼性の底上げに重点が置かれている」

ということでした。これは、私の学んだソフトウェア工学にも感じていた違和感です。

もちろん、ユーザビリティテスティングもありますし、各種レビューによって良いソフトウェアを作る努力はされていますが、フィードバックでなくフィードフォワード、つまり作りこむことが大切だと思うのです。

テストやソフトウェア工学の技術は重要ですし、間違っているとも思いません。しかし、現場で作りこむ技術がどうも少ないように思います。これは、製造を外注していることや、そもそもソフトウェアの価値はユーザにとっての価値であることによるのでしょう。

もちろん、やっているところではきちんと作りこみが行われているのでしょうけど、その技術があまり出てこない。ノウハウとして隠しているのなら良いのですが、標準プロセスで定めれたゴールを目指して汲々としているのが現状ではないでしょうか？

製品としての品質や、リスクベースの合理的な品質も大切です。しかし、開発者に必要なのは、自分の開発結果を明らかにする見える化です。その意味でfailure(障害、結果)ではなくfault(欠陥、原因)のデータで管理がしたいと思ったわけです。

さて、昨日はこのfaultのデータを収集するには、試験項目の結果に対して、マージや分割が必要だと書きました。しかし、構成管理上の更新(バージョン)を、仕様変更と障害に分けることができればよいことに気付きました。チケット駆動開発を行っていれば、チケットの簡単なルールを定めるだけで、簡単に集められそうです。