なぜ品質要件の問題はテスト段階で表面化するのか ― 品質要件（非機能要件）の考え方と定義方法 ―
1．品質要件の問題は、なぜ見過ごされたまま進むのか組込み・車載ソフトウェア開発では、設計やテストの終盤になってから、 応答時間が間に合わない 負荷が高すぎて処理が破綻する 安全・セキュリティ要求が弱い 必要なログがなく原因が追えないといった問題が表面化することが少なくありません。実務を見ていると、その背景には大きく 2つのパターンがあります。パターンA：そもそも「ここで品質要件が必要だ」と気づけていない機能要求や仕様は要求仕様書に書かれている一方で、 応答時間は？ 負荷条件は？ 異常時の振る舞いは？ ログや診断は？といった品質の話題がほとんど議論されないまま進んでしまうケースです。これは品質要件を後回しにしたのではなく、「ここで考える必要があることに気づけなかった」状態です。パターンB：品質要件は「あるが、疑われていない」過去プロジェクトの品質要求流用や顧客提示の品質要求が、妥当性確認なしにそのまま使われているケースです。その結果、 今回の製品構成でも成り立つのか 対象機能や性能レベルに合っているのか 環境・負荷条件は変わっていないかといった確認がされないまま進み、やはりテスト段階で破綻します。品質要件の問題は、このように「書かなかった」からではなく、「気づけなかった／疑われなかった」ことによって起きているケースが多いと考えます。2．品質要件とは何か？定義の基本的な考え方品質要件（非機能要件）とは、製品・システムがどのレベルで振る舞うべきかを定める要求です。機能要件が「何をするか」を定めるのに対し、品質要件は、 どの性能で どの信頼性で どの安全性で どの容易さで動作すべきかを規定します。問題は、「重要だと分かっていても、どこまで決めれば十分か」が曖昧なまま進んでしまう点にあります。3．品質要件を具体化するための最小チェック（4点）実務で効果が高いのが、次の 4点チェックです。 品質特性を選ぶ性能／信頼性／安全性／保守性／セキュリティ など 観点に分解する例：性能 ⇒ 応答時間、CPU負荷、メモリ 数値化する（測定可能にする）例：応答時間 50ms以内 条件を明記する例：モード、温度範囲、車速、通信負荷などの前提条件この4点を通すだけで、曖昧さ由来の手戻りは大幅に減らせます。4．それでも問題が残る理由―「4点チェック」だけでは足りない4点チェックは、「何を書くか」を整える道具です。しかし実務では、それだけでは防げない問題があります。理由は明確で、「それを書くべきか」「それで妥当か」を問えていないからです。そこで重要になるのが、次の問いです。「この品質要件は、今回の製品・機能・構成でも成り立つか？」 そもそも、ここで品質要件を考える必要はないか 既存の品質要件は、今回も意味を持つか 顧客要求は、システム特性や環境に合っているかこの問いを4点チェックの前に挟むだけで、 気づけなかった品質要件 疑われなかった品質要件の多くが表に出てきます。5．まとめ：品質要件定義を要件分析プロセスにどう組み込むか品質要件の問題は、後工程で突然起きるわけではありません。 必要な場面に気づけなかった 既存の要求を疑わなかったその結果として、テスト段階で表面化します。実務で意識したいのは、次の3点です。 ここで品質要件が必要か？と立ち止まる その品質要件は今回も成り立つか？と疑う 定義するときは、4点チェックで具体化するこれだけで、品質要件の問題はテスト段階で初めて表面化するものではなく、上流での「問いの立て方」によって防げる問題になります。要件分析プロセスでどこに組み込むかここまで述べてきた問いとチェックは、特別な工程を追加するものではありません。実務では、要件分析プロセスの中で次のように位置付けることで、無理なく組み込むことができます。要件抽出・整理の段階「ここで品質要件が必要か？」と立ち止まる要求仕様の具体化段階既存の品質要件や流用要求に対して、「今回の製品・構成でも成り立つか？」を確認する要求記述・レビュー段階妥当と判断した品質要件を、4点チェックで具体化・数値化する この流れを要件分析プロセスの中に組み込むことで、品質要件の問題をテスト段階で初めて発見する、という状況を減らすことができます。品質要件を含めた要求文書の整理や書き方に関するお悩みがあれば、実務に直結する形でのご支援も可能です。お気軽にご相談ください。（安部宏典）