画面周りチェック後回しの法則・・・

　昨日の日経朝刊（2007/11/1 13版 13面）の記事。トヨタでの「フリーズしないクルマ造り」へのチャレンジの中に以下のような一節があった。

採点の対象は誤字脱字のたぐいの単純ミス。その数があるレベルを超えると、その裏に重大な欠陥が隠れている恐れが急速に高まる。トヨタは膨大なデータを分析し、その境目が百点満点の五十五点であることを突き止めた。一点でも足りなければ即刻やり直し。

　単純なミスの数で大きなエラーを類推していこうというのは、1：29：300の法則（ハインリッヒの法則）の応用だろうし、もしかすると割れ窓理論なんかにも通じるかもしれない。
　ソフトウェアのような見えにくい分野にこうした判りやすい指標を入れていくのは素晴らしい試みだと思う。こうした一歩一歩の積み重ねがソフトウェア全体の品質向上と地位向上につながると期待する。

　オルタナティブ・ブログには、この分野の専門家であるEASEプロジェクトの森崎さんがいらっしゃって既に関連エントリー（これとかこれ）をいくつも書かれているので私がこの辺りの話を書くのはおこがましいのだが、以前にその森崎さんからレクチャーを受けたところによると、ソフトウェア開発現場でソースの改変状況や障害管理票を分析することでいろんな事が見えてくるそうだ。

　例えば設計書や仕様書のレビュー時に指摘事項の種類と割合を分析することで最終成果物の品質予測ができるらしい。レビュー結果には正常系と異常系とその他の処理（性能や環境など）がほどよく含まれていたほうが良く、ここでの指摘が誤字脱字に関するものばかりだと、やはり後半の問題発生数が多くなるそうだ。
　あるいはUIなどの入出力系でのバグはデータアクセスなどのデータベース周りのバグものに比べるとプロジェクト後半でのインパクトが小さいそうで、この面から（もし時間が無いときは）レビュー時に画面周りをチェックする作業を減らしてその分をデータベース周りに注力したほうが良いことなどが考えられるとのこと。
　
　冒頭の記事にあるような「55点ルール」だけでなく、「レビュー指摘　1：1：1の定理」だとか「画面周り後回しの法則」など簡潔でわかりやすい標語？が増えれば、ソフトウェア開発分野の品質やコストが劇的に改善するかもしれない。ソフトウェア開発分野での可視化の研究には、まだまだいっぱい宝が埋まってそうで今後が楽しみだ。