「品質保証（QA）」「品質管理（QC）」から「品質フィードバック（QF）」へ
これまでの品質管理
プロジェクト管理やプロセス改善において、品質向上のための活動として必ず使われるのが「品質保証」と「品質管理」という用語です。
これらを同じものと思っている人も多いかもしれませんが、正確に言えば、異なる活動を指しています。
- 品質保証（Quality assurance、QA）
- 製品が利用者の要求（ニーズ）を十分に満たすかどうかを保証すること。
- コストをかければ効果が上がりやすいが、どの程度コストをかけて行うかバランスが重要となる。
- CMMIでは、PPQA（プロセスと成果物の品質保証）のPAが該当する。
- 品質管理（Quality Control、QC）
- 適切な品質目標を定め、それを達成するためのマネジメントを行うこと。
- 品質のばらつきを減らし、生産性向上／原価低減を目指す。
- CMMIでは、VER（検証）／VAL（妥当性確認）／QPM（定量的プロジェクト管理）などのPAが深く関係する。
製造業などでは、上記の手法を確立・発展させた、TQC（Total Quality Control）やTQM（Quality Management）といった活動も生まれ、品質向上に大きく寄与したのだと思います。
ただ、ソフトウェア開発では、不確定要素や属人性が高く、上記のような活動が必要だと頭では分かっていても、納期と予算を厳守する必要があり、結局は品質を担保できないまま、プロジェクトがデスマーチ化しまうことが多いと感じます。
これからの品質管理
プロジェクト管理では、昔からQCD（品質／コスト／納期）が重要視されてきましたが、開発を請け負う側ではC／Dを変更することは難しく、Qを犠牲にする傾向にあります。
これは、頭で分かっていても、常に短納期／低予算が求められる現場では、なかなかコントロールしにくい課題です。
そのため、
- 工程毎に品質分析を行い、問題をチェックする。
- リリース前に品証部が試験を行い、出荷判定を行う。
というような、後から品質をチェックするスタイルは、手戻りが大きいために、結局はリスク／問題があるまま先進むことになる場合が多いでしょう。
したがって、QA／QCという言葉・活動は、現代のソフトウェア開発には向いておらず、
- QF（Quality Feedback）
という言葉・活動を考えていく必要があると感じています。
QFとは、品質を向上させるのではなく、品質の作り込みを実現するための活動と定義しています。
ツールや指標等を積極的に活用し、開発者にリアルタイムにフィードバックされることで、（開発の途中で劣化した）品質を向上させるのではなく、予め品質を作り込んでいかなければ、最終的に利用者の要求（ニーズ）を満たす品質は担保できないと考えています。
例えば、最近のJava開発を例に取れば、以下の方法が直ぐに実践でき、かつ、効果の高い方法だと思っています。
- Checkstyle／FindBugsといったツールを、開発者が利用するEclipseの環境に導入し、リアルタイムで静的解析の問題を修正していく。
- JUnitによるマイクロテスト*1を行っていくことで、「動作する」ソースコードを開発する。
- HudsonやMaven2を利用した継続的インテグレーション環境を構築し、常にソースコードのビルドを行って、モジュールの結合や試験を実施する。
プロジェクトでルール化していても、設定ミスや手法を知らないために、きちんと導入されていない場合も目にしますが、上記は、品質のベースアップを図るには有効な方法です。
コーディング工程は、比較的品質の作り込みが行いやすい工程ですが、現状では人依存性が高い作業である、レビューや試験といった作業についても、単にレビューの指摘や試験で検出したバグを管理するのではなく、それらのデータから自動的に品質分析をフィードバックすることによって、設計途中でも問題を早期発見しやすくなります。
今後のソフトウェア開発では、品質状況が開発者自身に常にフィードバックされ、開発者自身が品質を作り込んでいける仕組みが重要となってくるでしょう。
