読者です 読者をやめる 読者になる 読者になる

やまぐ雑記。

SIerからこんにちは

一次請け・二次請けSIerに「技術力」が足りない気がする (品質分析編)

配属されたプロジェクトが炎上していく過程を見ていくと、弊社や親会社(広く言うと一次請け・二次請けSIer)に「技術力」が足りないように思います。

いくつかテーマがありそうですが、まずは品質分析を考えてみようと思います。

バグの根本原因に辿り着かない品質分析

正しい根本原因に辿り着いていない品質分析、とても多いです。

私が観測した範囲では、2パターンありました。

パターン1: 品質分析を下請けに丸投げ

この場合、立場の問題などもあって反省文じみた空気感が強くなります。

となると、もれなく「レビューでの見落としでした。今後レビューを強化します」といった、根本原因に辿り着いていない内容が出来上がってしまうのです。これでは改善は見込めません。

バグの根本原因は、開発プロセスにあることがほとんどです。つまり、開発プロセスがバグを生み出してしまっていて、だから開発プロセスを改善して防ぐ、という考え方が必要なのです。

まずは、お互いがこの認識をしっかり持たなくてはなりません。 …とは言っても、本来は開発プロセスを作った会社がきちんと品質分析をすべきだと思います。

パターン2: アーキテクチャ開発プロセスを知らずに品質分析

それでもバグ票の必須入力欄は埋まる。最低だ。

残念なことに、 ”開発プロセスを作った会社” つまり我々や親会社が品質分析しようとすると、このパターンに陥ることが多いです。なぜか? 管理ばかりしていて、アーキテクチャ開発プロセスなんて知らない人ばかりだからです。

channel9.msdn.com

「作れなくてもよいが、勘所は知らないとダメ」

これが実践できている人は、ほとんどいません。管理ばかりしている場合ではありません。


形骸化する品質分析

「品質報告会(偉い人を説得させる会)があるから」とか「バグ票に必要だから」とか、形だけを義務的にこなして、品質分析が形骸化してしまっているように感じます。

形式的に品質分析をこなしている状態を放置するのではなく、品質分析・品質管理の体系的な知識・技術を持って「どんな品質分析をすべきか」「どこまでなら出来るか」を考える機会がないと、品質分析はお荷物のままなんだろうな… と思います。