なぜ品質要件の問題はテスト段階で表面化するのか　― 品質要件（非機能要件）の考え方と定義方法 ―

1．品質要件の問題は、なぜ見過ごされたまま進むのか

組込み・車載ソフトウェア開発では、設計やテストの終盤になってから、

• 応答時間が間に合わない

• 負荷が高すぎて処理が破綻する

• 安全・セキュリティ要求が弱い

• 必要なログがなく原因が追えない

といった問題が表面化することが少なくありません。

実務を見ていると、その背景には大きく 2つのパターンがあります。

パターンA：そもそも「ここで品質要件が必要だ」と気づけていない

機能要求や仕様は要求仕様書に書かれている一方で、

• 応答時間は？

• 負荷条件は？

• 異常時の振る舞いは？

• ログや診断は？

といった品質の話題がほとんど議論されないまま進んでしまうケースです。

これは品質要件を後回しにしたのではなく、「ここで考える必要があることに気づけなかった」状態です。

パターンB：品質要件は「あるが、疑われていない」

過去プロジェクトの品質要求流用や顧客提示の品質要求が、妥当性確認なしにそのまま使われているケースです。

その結果、

• 今回の製品構成でも成り立つのか

• 対象機能や性能レベルに合っているのか

• 環境・負荷条件は変わっていないか

といった確認がされないまま進み、やはりテスト段階で破綻します。

品質要件の問題は、このように「書かなかった」からではなく、「気づけなかった／疑われなかった」ことによって起きているケースが多いと考えます。

2．品質要件とは何か？定義の基本的な考え方

品質要件（非機能要件）とは、製品・システムがどのレベルで振る舞うべきかを定める要求です。

機能要件が「何をするか」を定めるのに対し、品質要件は、

• どの性能で

• どの信頼性で

• どの安全性で

• どの容易さで

動作すべきかを規定します。

問題は、「重要だと分かっていても、どこまで決めれば十分か」が曖昧なまま進んでしまう点にあります。

3．品質要件を具体化するための最小チェック（4点）

実務で効果が高いのが、次の 4点チェックです。

1. 品質特性を選ぶ
   　性能／信頼性／安全性／保守性／セキュリティ など

2. 観点に分解する
   　例：性能 ⇒ 応答時間、CPU負荷、メモリ

3. 数値化する（測定可能にする）
   　例：応答時間 50ms以内

4. 条件を明記する
   　例：モード、温度範囲、車速、通信負荷などの前提条件

この4点を通すだけで、曖昧さ由来の手戻りは大幅に減らせます。

4．それでも問題が残る理由　―「4点チェック」だけでは足りない

4点チェックは、「何を書くか」を整える道具です。
しかし実務では、それだけでは防げない問題があります。

理由は明確で、「それを書くべきか」「それで妥当か」を問えていないからです。

そこで重要になるのが、次の問いです。

「この品質要件は、今回の製品・機能・構成でも成り立つか？」

• そもそも、ここで品質要件を考える必要はないか

• 既存の品質要件は、今回も意味を持つか

• 顧客要求は、システム特性や環境に合っているか

この問いを4点チェックの前に挟むだけで、

• 気づけなかった品質要件

• 疑われなかった品質要件

の多くが表に出てきます。

5．まとめ：品質要件定義を要件分析プロセスにどう組み込むか

品質要件の問題は、後工程で突然起きるわけではありません。

• 必要な場面に気づけなかった

• 既存の要求を疑わなかった

その結果として、テスト段階で表面化します。

実務で意識したいのは、次の3点です。

1. ここで品質要件が必要か？と立ち止まる

2. その品質要件は今回も成り立つか？と疑う

3. 定義するときは、4点チェックで具体化する

これだけで、品質要件の問題はテスト段階で初めて表面化するものではなく、
上流での「問いの立て方」によって防げる問題になります。

品質要件を含めた要求文書の整理や書き方に関するお悩みがあれば、実務に直結する形でのご支援も可能です。
お気軽にご相談ください。

（安部　宏典）