バグがなければ品質はよいのか

一般的なソフトウェアの品質事故の背景はこういったものだと思います．

急速な，機能増大，大規模化，複雑化
開発期間短縮化(それもかなり無謀な)
レビュー，テストの省略化(コストや納期のため)
手戻り多発(ウォーターフォールの場合)
納期遅延，赤字プロジェクト，品質事故

私が数年前に関わったプロジェクトで，市場出荷後の品質問題をおこしてしまいました．上記に補足すると下記も原因にありました．

システムソリューソン，ミドルウェアの総入れ替え
システム問題(パフォーマンス)発生
未経験者が多かった
システム基礎検討不足

これを機会に，品質について改めて考えるようになりました．

いろいろな定義/標準

ソフトウェア品質の定義といえばまずはこれをベースに話されること多いです．

ソフトウェア品質特性 (JIS-X0129，ISO/IEC9126) (JISC http://www.jisc.go.jp/ からpdfを閲覧可能)

外部品質として，使用性，機能性，信頼性，内部品質として，保守性，移植性，効率性と分類されている．
『ソフトウェア解発 55の真実と10のウソ』でRobert L. Glassは，

品質とは，属性の集合である．

とし，これらは品質の定義ではないとしている．

他にもさまざまな視点が，『組み込みプレス Vol.2, 5』『ソフトウェア品質保証の考え方と実際』などで紹介されている．参考にされたい．

SQuBok ソフトウェア品質の知識体系 (http://www.juse.or.jp/software/topics060605.html)
プロセス品質/プロダクト品質
利用品質
設計品質/実装品質

前述した事例では，市場問題を引き起こす(ユーザダメージの大きな)バグが問題視されました．ならばバグがないソフトウェアは高品質と言えるでしょうか．

「ノー」です．ソフトウェアエンジニアからみればそれも確かに一理あります．しかし，製品やサービスといった観点ではどうでしょう．バグはない(ハングはしない)けど，死ぬほど使いづらい，または全く使えない製品なんてあり得ませんよね．世界にいままでなかったような全く新しくそしてすばらしい価値をもたらす製品やサービスにユーザはお金を払うわけです(必ずしもではないですけど)．もっと言うと，多少バグなんてあっても，圧倒的価値をもたらしてくれる製品があれば，むしろそれのほうが魅力的に違いありません．ちょっと話が逸れてしまいましたが…．

言いたいことは，バグをなくすことももちろん大事だが，圧倒的価値を生み出す事はそれ以上にもっと大事だということです．

『ソフトウェア解発 55の真実と10のウソ』でRobert L. Glass は，品質はユーザーの満足度の4つの要素の1つにすぎないと述べている．

ソフトウェアの品質とは，ユーザーを満足させることではない．仕様を満足させることもなければ，コストとスケジュールを満足させること，信頼性でもない．
ユーザーの満足度＝仕様の実現度＋スケジュール通りの出荷＋適正なコスト＋高品質の製品

企画＞仕様＞設計

外圧に屈することなく，上流に注力する(させてもらう)ことが高品質への近道です．品質は上流で作りこむ．これです．企画＞仕様＞設計により重心をおくことです．テスト(下流工程)に人と時間をかけて一気にバグを出し切ればなんとかなるだろうなんて決して考えないことです．しつこいですが｢外圧に屈することなく｣です．

品質をみせてくれ

品質を問題視するのは，決まってソフトウェアというものをほとんど理解していない人である場合が多い．ソフトウェア上級マネージャ，企画/マーケット担当者，プロダクト責任者(ハード屋である場合が多い)．言われることは決まって，｢どれくらいの品質かみせてくれ｣だ．ハードウェアと違って，定量的に品質を表すのは，まだまだ難しいのが現実です．メトリクス(品質尺度/測定)については別途書きたいと思います．