エンジニアリングが弱い組織のプロセス改善

Jenga round 2 / Off Kilter

ソフト開発のエンジニアリングプロセスが弱く、ろくすっぽソフト要件が決まらないうちにいきなりコードを書きはじめるような組織に対して、”CMMI”だとか”Project　Management”だとか”ISO9001″などのプロセスアプローチを持ち込むとびっくりするほどの拒否反応が現れます。

やれ、自分の開発テーマは特殊なので適用は無理だとか、今の開発プロセスは何ら問題はないとか、もっともらしい理由を並べはじめます。ちょっと強引に改善にとりかかると、現場はやらされ感でいっぱいになります。（だいたい他の会社の開発プロセスを知らないのに、なぜ自分の開発テーマだけは特殊だとわかるんだと言いたいところでありますが）

じゃ”CMMI”や”Project Management”という少しブームが過ぎたモデルじゃなく、”アジャイル” や “SCRUM” を取り入れようとしても、とてもこれらの手法で要求される組織の自律性があるわけじゃないので、さらに厳しい試練となってしまいます。

これらのプロセス改善に踏み出せない大きな理由はモデルの問題ではなく、自分たちが改善をやらなければならないという問題に対して合意できていないことと、課題に立ち向かうことができる基礎体力(基本スキル)が不足していることです。

プロセス改善を仕掛ける側としては、いろいろ目新しい手法に走るんじゃなく、まずは基礎体力をつけるという時間のかかる課題にしっかり対峙していく覚悟が必要となります。