CodeMonkeyイノベーションのジレンマ

2007年06月16日

CMMと品質

このエントリーをはてなブックマークに追加

最近、こんな本を読みました。

ソフトウェア開発のためのプロジェクトマネジメント入門―CMM導入の手引き

この本はソフトウェアのオフシェア開発を主に行っているインドの企業 Infosysが実際に行っているソフトウェア開発のマネジメントプロセスを紹介した本です。

InfosysはCMM(CMMI)レベル5に達していると評価されている企業だそうです。

CMMやCMMIは主にソフトウェア開発の組織の成熟度を示すモデルとしてよく聞く言葉ですが、ISOみたいな認定があるわけではないそうです。
ここでいう、Infosysが評価されたというのは、モデル導入の評価者に評価されたという事らしいです。[参考]

CMMIのモデルを提案したSEIという組織のレポートには、国ごとに導入・評価した組織の数が載っています。(ここのp15)
その数では日本は、インドや中国に負けているみたいです。orz。ちょっと悲しいですね。

日本ではレベル2や3の評価を受けたSIerが多いようですが、ここのモデルの説明を見ると、4以上でないとあまり自慢できるものではない気がするのは気のせいでしょうか?

それはさておき、そんなすごい企業がどんな管理を行っているのかと気になって読んでみましたが、規模の見積り方法、品質管理、進捗管理、要求変更の管理、構成管理のやり方など、おおむね自分が経験した現場で行っている事と変わりませんでした。

しかし、ここが違うなと、大きく関心をもったところは、

1.管理の方法を組織として、統一して実施する。
2.管理方法の効果について、逐次評価を行う。
3.過去のプロジェクトの結果をデータとして蓄積し、次の計画に生かす。

というところです。

開発の現場では管理が行えていても、組織全体、つまり会社として統一した管理がはたして行えている会社がどれだけあるか?
そしてその管理方法について逐次、評価し、結果をデータ化して利用できている組織がどれだけあるのか?とよく疑問に思います。

よく新規顧客のSI案件がデスマーチ化するのは、新しい現場で、プロセスが十分に出来上がらないまま、開発を進める事になってしまう事がひとつの原因ではないでしょうか?

同じ開発現場の二次案件がうまくいくケースが多いのは、現場でのプロセスや、ノウハウが成熟したからだと考えます。

しかし、新規顧客の案件といえども、毎回毎回案件ごとに管理の方法を1から作りだすのはなんて効率が悪いのかと思います。そして、下請けSIベンダなどで、現場や上位SIベンダの管理方法に甘んじて、自らの組織としてのプロセス管理手法を作ろうとせず、結局、人出ししかできないベンダも多そうに思えます。

統一された開発のプロセスやナレッジという物は組織の資産です。

特に、過去のプロジェクトのデータを蓄積し、生かすことは、見積など、計画の予測を立てるのに非常に役に立つはずです。

それがないのに現場任せにして、現場にいるSEが潰れていく・・・というのは悲惨な状況に思えます。(そういう会社はSIベンダではなく、ただの派遣屋さんだと思う・・・。)


さて。では素晴らしい管理方法があれば、じゃあ素晴らしい品質のシステムを作るんだね、という話になりますが、それはそれで違う話なのかもしれません。

システムの品質を示す尺度には、性能、信頼性、保守性、可用性、安全性、そして顧客の満足度やユーザビリティなど、いろいろあると思います。

プロセスの管理さえしっかりしておけば、これら品質もすべてOK。とは単純にはいかないように思えます。

インターフェースのデザインや、いろんなケースを想定したエラーハンドリング、ソフトウェアの性能を上げるアイデアなどマニュアル化した「管理」のプロセスだけでは生み出せない、クリエイティブなものです。

なので、品質をつぶしたバグのカウントなど定型化した分析だけで測定しても、品質の実現を妨げる問題がすべて洗い出せ、ユーザが満足する物が常にできるとも限らないはずです。

とは言え、その中でも出来る限り人に依存しないプロセスを作り、無駄を省くことは、コストを意識する組織にとっては有益な事です。

クリエイティブな作業と思われる部分をマニュアル化してしまうと、新しい事は出来なくなりますし、嫌がる技術者もいるでしょう。

しかし、既にどこかにあるような物を作るのに、毎回、同じようにクリエイティブする「車輪の再発明」のような作業は、楽しい時もあるのですが、やはり無駄に思えて仕方ありません。

車輪の作り方のマニュアルがない自動車屋で「車輪の再発明」作業ばかりで食いぶちを稼ぐ生活は終わりにしたいものです。

 



zeroaka at 18:56│Comments(0)TrackBack(0) このエントリーを含むはてなブックマーク │システム開発 

トラックバックURL

コメントする

名前
 
  絵文字
 
 
CodeMonkeyイノベーションのジレンマ