品質の定量的評価について

もうね、客先常駐をとにかく悪と認定したいポジショントークなだけとしか見えないけどね。

これね。

【悲報】客先常駐システム開発で今もステップ数によるバグ検出数基準が使用されていることが判明 - 株式会社アクシア

ブコメとかでも何度も書いているけどさ、客先常駐がことさら悪いわけでもない。一括で受注して持ち帰り開発だったとしても、自社の製品開発だったとしても、同じ問題は起きる。クソなプロジェクトはクソなプロジェクトが引き起こす問題なんだよ(当たり前)。

客先常駐が往々にしてクソなのは、客がクソな上にその客と長く付き合わざるを得なくなるから相対的なクソ度が上がるってだけだし、逆に言うとクソじゃない、素晴らしい客先で常駐の仕事をやれるのであればそれはSIerとしては喜ばしいことなんだよ。
持ち帰り開発なんてフロアコスト自己負担だからな!100人月で見積もりだして80人月でやります!儲かります!みたいな話だったら目的を吐き違えているしね。真に有能なSIerは客先常駐をしながら、人月で見積をしながら、投入人数が見積もりの人月を割っていても容認されるのだよ。

で、品質評価の話ね。品質評価ってのは定量的な評価も定性的な評価もやる必要がある。定量的な評価ってのはソフトウェア工学的な観点からある程度指標が作られる(定量的な評価を嫌がる人のうち結構な割合がこういうソフトウェア工学的な考え方を軽視していて、感覚で仕事をしている気がしてならない)。もちろん、それは「指標」にすぎないから、そのプロジェクトの特性を説明していないし、要員のレベルも説明していない。大規模になればなるほど平均的に指標に近づくことが多いんだけど、そういう指標ってわりかし人間の能力を低く見積もっているから、相対的に低い能力が混在しがちな大規模プロジェクトにおいては案外よく状況を洗い出してくれる。

つまり、そういうことなんだよ。

当然だけど、定量評価ってのはそれ以上でもそれ以下でもない。基準値以上にバグが出ないと捏造してでもバグを出せ、みたいな話はもちろん伝説ではない。某ベンダーとか某ベンダーとかは批判されているとおり、管理ぐらいしかできない人を使って下請けにまるっとやらせるクソプロジェクトを組成したりするからね(とは言え、そのプロジェクトがクソになるのがその下請けにスキルが足りないことに起因していることはままある)。でも、その数字通りにならなかったのはなぜか、ということは考える必要はある。(特にウォーターフォールにおける)プロジェクトの品質管理というのは工程ごとにやるべきことを許容されるリスクの範囲に収めて実行できたか、ということに尽きるわけだから、そこがはっきりしていない場合に疑ってかかるべきなのは当然だ。クソなのは、はっきりとした理由付けで問題あるなしの結論を出すのではなく、単に数が足りないからだめだってなっちゃうことね。然るべき理由があるのにそれを評価できないというのはPMOがクソなわけだ。ただ、数字を軽視すべきではない。

この話が難しいのは、こういう管理の結果、数字が合わないと先に進めないみたいな認識が蔓延した結果、数字合わせに終止することがあるってところ。これはプロジェクトの進め方がまずくて、問題に正直に向き合えないパターン。遅れることが許されない、みたいな空気が蔓延すると捏造は日常茶飯事になる。

じゃあ、数字の管理しなければ品質が上がるの?そんなわけないよね。炎上プロジェクトの最大の問題は、正確な情報収集に基づき、正しく判断を下すことができないことだ。その判断をするための重大な指標としての基準をトップレベルできっちり決められないのであれば、プロジェクトなんてろくな結果を産まない。なので、

プログラミングを行わない元請け企業であるSI企業は、プログラムレベルの試験などには介入せずに、もっと上位の結合試験等のフェーズだけ行えば良いと思います。プログラムの試験のバグ検出数のような基準を作るのであれば、実際にプログラムを実装している企業が現場の実情に合わせて基準を作るべきです。

なんていうのは寝言にすぎないと思う。SI企業が実情に合わせた基準を作り、結果を評価できないというのがおかしなことであって、実装する企業にクオリティコントロールを丸投げするプロジェクトなんて事故ったら死人が出るからね。