ソフトウェアの品質管理

「貴方が一日コードを書くと、いくつバグが入りますか？」という問いに簡単に答えられるほどプログラミングは単純ではない、と書いてみるテスト。
そういえば、標準化と開発現場の統制についての記事（↓）を見かけた。
[id:JavaBlack:20051215:p1]
ドキュメントに関する考察（↓）も。
[id:w_o:20051209]
最近、仕事をしながら思ったのだけれど、ソフトウェアの品質管理や開発者の説明責任とかをやかましく言い始めると、規約を決めたりドキュメントを作成したり申請手続きを決めたりを、管理しやすいところから始めがちなのだけれど、ソフトウェア開発の性質というものへの本質的な考察を欠かしてただ規則だけを増やしてしまうことで、一番管理しにくくて品質に影響を与えるところに十分なリソースをかけられなくなることがあるのではないかと思う。
まあ、直感的な話しかできないのだけれど、ソフトウェア開発のクリティカルな部分は、計数管理の難しい部分も結構あるのではないかと思う（例を挙げると、適切なモジュール化や可読性の高いコーディングなどは、計数管理しにくいのではないか）が、そういう計数管理の難しい部分は、目に見えにくいために、管理項目から外れがちなのではないかと思う。でも、そういう部分を管理するためのリソースを無視してしまうと、重要な部分の品質が低下してしまうことに気づかないかもしれない。