品質管理は誰がどうやる?

プロジェクトマネジメントの勉強を(ちょっと)すると、「品質保証」とか「品質管理」とかいうことを学習することになる。もちろんソフトウェア・エンジニアリングの勉強を(ちょっと)しても、すぐに出会う。
この「品質管理」、どうも「プロジェクトマネージャの仕事」「定量的な品質基準」...のようにとらえてしまっていて、なんとなく違和感があった*1
プロジェクトマネージャが(もちろん遠くから眺めているだけの品質保証チームもだが)、「レビュー指摘数/ステップ数」などで、ソースコードの品質が測れるとも、管理できるとも思えない*2。それより、技術者が、1時間ソースの書きっぷりを眺めたほうが、よっぽどかよくわかる気がする。


この違和感の発端は、とあるプロジェクトでの経験*3かもしれない。
そのプロジェクトでは、委託先が作成したソースコードは、手分けをしてすべて見る計画だったし、実際に見た(よい品質にしたかった)。レビューについては、厳密な定義をしていなかったが、実装のかなり早い段階で、教育レビュー*4を実施した(これにより、ピアレビューにより発生するだろう多くの指摘を事前につぶすことができたと思っている)。その後のピアレビューのやり方は、基本的にはアドホックレビュー。指摘の種類と内容を記録し、担当者に直接指示した。担当者や対象機能により、指摘内容がまるで異なった。結局、「大変素晴らしいコード」にはならなかったが、「どうしようもないコード」にもならなかった。まずまず、よく書けている。動作もするだろうし、メンテナンスもできるだろう。
これらの作業も作業結果も知らずに、担当者の言葉も信じられず、ステップ数とレビュー指摘数のみがほしいの*5


しかし、先日読んだソフトウエア開発 55の真実と10のウソ」における第3章の冒頭と、ウソ2「ソフトウエア製品の品質は、管理できる」によって、この違和感が少し解消された。
そこには『品質の責任は誰が負うのか?』という問いに対して、『ソフトウエアの品質には技術的要素がきわめて多いため、管理者一人に押し付けることはできない』とある。
やっぱり、技術者にも責任があるのだ*6。技術者こそが、アプリケーション全体の品質を見て、プロジェクトマネージャと共有し*7、リソースの配分などをお願いし、品質をコントロールしなければならない。プロジェクトマネージャは、間接的に品質を管理するイメージだ。


指標を集め、定量化することは重要だと思う(規模が大きくなれば特に)。システムの内容がわかっている技術者であれば、効果的な指標集めもできるだろう(そしてしなければならない)。しかし、まるで知りもしない人が、通り一遍の数値を見たって、それだけで何かが判断できるものか(ましてそれだけで責任をとろうなど、賭けに等しい)。

2010/07/17追記

あまり整理される前に、だらだら書いてしまった(しかも、愚痴っぽくなっている)。このあたりで思うことについては、もう少し整理して、別途書くことにする。

*1:ここはおそらく、きちんと理解していないのだと思う。これからちゃんと勉強する。

*2:毎回、同じ枠組み、同じ観点で、インスペクションができていれば話は別なのかもしれないが、、そんなプロジェクトに携わったことがない。

*3:これは、プロジェクトマネージャではなく、品質保証チーム(?)とのやりとりなのだが。

*4:教育レビューとピアレビューの明確な切り分けはなかったのだが。

*5:少なくとも、どういう状況で、どうしてそういう数値になっているのかくらいは、確認してほしい。

*6:もちろん、そう思っていた。違和感の元凶は、こんなことだったのか。。

*7:この時、品質の根拠として、定量評価が必要になる。プロジェクトマネージャは、客観的に判断しなければならないからだ。