はじめに
「このシステムは品質が高い」「品質に問題がある」——プロジェクトの現場では「品質」という言葉がよく使われます。しかし、その中身を具体的に説明できる人は意外と多くありません。多くの場合、品質は「バグが少ないこと」とほぼ同じ意味で使われています。
もちろん、バグが少ないことは品質の重要な要素です。ただ、それだけを品質と考えていると、「バグはほとんどないのに、現場からは使えないと言われる」という事態が起こります。
QCD（品質・コスト・納期）のバランスとはでは、QCDのどれか一つを犠牲にしてはいけない理由を整理しました。今回はそのうちの「Q」、品質とは具体的に何を指すのかを、発注側の視点で分解します。
品質は「どの水準で」と「どこまでの範囲を」の2つで決まる
プロジェクトにおける品質は、大きく2つの軸で捉えると整理しやすくなります。
- 水準の軸：作ったものが、求められる基準をどの程度満たしているか（バグの少なさ、性能、使いやすさなど）
- 範囲の軸：求められている要求を、どれだけ漏れなく実現しているか（要求仕様の数・網羅性）
一般的に「品質」というと前者の水準の軸だけが語られがちですが、発注側にとっては後者の範囲の軸も同じくらい重要です。順に見ていきます。
水準の軸：求める基準を満たしているか
水準の軸は、作られたものが「どれだけきちんと動くか」に関わる品質です。代表的なものを挙げます。
不具合の少なさ
最も分かりやすいのが、不具合（バグ）の少なさです。プロジェクトでは、テストで見つかった不具合の件数をプログラムの規模で割った「バグ密度」などの指標で管理されることが多くあります。
ただし、不具合の件数は少なければよいというものでもありません。テストが十分に行われていないために見つかっていないだけ、というケースもあるためです。件数と合わせて、どのような観点でテストしたのかを確認することが大切です。
性能・可用性
画面の応答時間、夜間バッチの処理時間、同時に利用できる人数、システムが止まらずに動き続けられる時間なども品質の一部です。これらは「非機能要件」と呼ばれ、要件定義で数値として決めておかないと、テストの段階で合否を判断できません。
性能や可用性の目標は、運用フェーズに入ってからはベンダーとのSLAとして管理されることも多くなります。考え方はベンダーとのSLA（サービスレベル合意）、何を数値で握っておくべきかで整理しています。
使いやすさ・保守のしやすさ
画面が業務の流れに沿っているか、入力ミスが起きにくいかといった使いやすさも品質です。また、利用者からは見えませんが、将来の改修のしやすさ（設計書が整っているか、プログラムの構造が分かりやすいか）も、長く使うシステムでは重要な品質になります。
範囲の軸：要求を漏れなく実現しているか
ここからが、見落とされやすいもう一つの軸です。
要求仕様の数・網羅性も品質の一部
どれだけ不具合が少なく、性能が良くても、業務に必要な機能が実装されていなければ、そのシステムは「品質が高い」とは言えません。求められている要求仕様をどれだけの数、どれだけ網羅して実現しているか——つまりスコープの広さも、品質を構成する要素です。
たとえば、受注管理システムを刷新したとします。
- 通常の受注処理は問題なく動く
- しかし、返品・キャンセル・分納といった例外的な処理が要件から漏れていた
この場合、テストで見つかる不具合は少ないかもしれません。そもそも作っていない機能はテストされないからです。それでも現場から見れば、「業務の一部が新システムで回らない」という明らかな品質問題です。
範囲の品質は、要件定義の段階でほぼ決まる
範囲の軸の品質は、テスト工程で作り込むことはできません。要件定義の段階で、業務に必要な要求をどれだけ網羅的に洗い出せたかで、ほぼ決まってしまいます。
これは、要件定義を主導する発注側の責任が大きい領域です。要件定義ワークショップを成功させる進め方で触れたように、業務部門を巻き込んで例外処理や月末・期末の業務まで洗い出しておくことが、範囲の品質を高めることにつながります。
「範囲を広げる」ことと「品質を上げる」ことの関係
一方で、範囲の軸を意識しすぎて要求を際限なく増やすと、コストと納期を圧迫します。また、プロジェクトの途中で要求が少しずつ追加されると、スコープクリープとは？で解説したように、計画が崩れる原因にもなります。
大切なのは、「必要な要求を漏れなく」と「不要な要求を入れない」の両立です。要求ごとに優先度をつけ、今回のスコープに含めるもの・含めないものを明確に合意しておくことで、範囲の品質をコントロールできます。
発注側が「品質」を定義するためにやるべきこと
品質の定義を言葉にして合意する
プロジェクトの初期に、「このプロジェクトにおける品質とは何か」を、水準と範囲の両面から言葉にしておくことをお勧めします。
- 水準：許容する不具合の基準、性能目標、使いやすさの確認方法
- 範囲：対象とする業務の範囲、要求一覧、今回は対象外とする要求
これらをプロジェクトの品質管理計画の品質目標として明文化し、ベンダーと合意しておくことで、「品質が良い・悪い」の議論が感覚論にならずに済みます。
要求一覧を「品質の物差し」として使う
範囲の品質を確認するには、要件定義で作成した要求一覧が物差しになります。テスト計画を立てる際に、要求一覧の各項目がどのテストで確認されるのかを対応づけておくと、「作り忘れ」「テストし忘れ」を防げます。
テスト観点の考え方はテスト計画の立て方｜品質を担保する3つの観点で、受け入れテストでの確認は受け入れテストの設計で解説しています。
検収基準に両方の軸を入れる
最終的に成果物を受け取るかどうかを判断する検収の基準にも、水準と範囲の両方を入れておきます。不具合の件数や性能だけでなく、「要求一覧のすべての項目が実装され、受け入れテストで確認されていること」を基準に含めておけば、範囲の漏れを検収前に発見できます。検収基準を曖昧にするリスクは検収基準を曖昧にすると起きることでも整理しています。
まとめ
プロジェクトにおける品質は、「バグが少ない」ことだけを意味するものではありません。不具合の少なさ・性能・使いやすさといった水準の軸に加え、要求仕様の数・網羅性という範囲の軸（スコープの広さ）も、品質の一部です。
特に範囲の品質は要件定義の段階でほぼ決まり、テスト工程で取り戻すことはできません。発注側は、品質の定義を両方の軸から言葉にしてベンダーと合意し、要求一覧を物差しとしてテスト・検収まで一貫して確認することで、「バグはないのに使えない」システムを防ぐことができます。
執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。
コメント