1.4非機能要件の定義

非機能要件は「性能が良いこと」「セキュリティが高いこと」といった曖昧な言葉のまま合意されると、開発が進んでから「思っていたのと違う」という認識の齟齬が発覚し、大きな手戻りを招きます。システムアーキテクトには、曖昧な非機能要件の兆候を見抜き、測定可能な指標（具体的な数値・達成基準）に落とし込んでステークホルダ間で合意を形成する力が求められます。

1.4.1非機能要求グレード

• 非機能要求グレード＝IPAが公開している、非機能要件を可用性・性能/拡張性・運用/保守性・移行性・セキュリティ・システム環境/エコロジーなどの大項目に体系化し、項目ごとに達成レベル（グレード）を選択できるようにしたツール・考え方。ステークホルダとの非機能要件の合意形成を漏れなく・効率的に行うために活用する。
• 非機能要求グレードを使う最大の利点は、利用者が意識しにくい項目（災害対策・セキュリティの詳細水準等）まで漏れなく検討対象に含められること。ただし、グレードを機械的に埋めるだけでは不十分で、業務上の重要度・コスト・実現可能性を踏まえてグレードを選び、その根拠をステークホルダに説明できることがシステムアーキテクトの役割。

1.4.2性能・信頼性・可用性・セキュリティ要件の測定可能な合意

• 性能要件は「応答時間◯秒以内」「ピーク時◯件/秒のトランザクションを処理」など具体的な数値と測定条件（平常時かピーク時か等）まで合意する。信頼性・可用性要件は「稼働率◯％」「RTO（目標復旧時間）◯時間以内」「RPO（目標復旧時点）◯分以内」など障害時の許容範囲を数値化する。
• セキュリティ要件は「セキュリティを高くする」という曖昧な表現ではなく、求める認証方式・アクセス制御の粒度・監査ログの保存期間・脆弱性診断の頻度など具体的な達成基準に落とし込む。いずれの非機能要件も、数値化しただけで終わらせず、その数値の根拠（業務影響・コスト妥当性）をステークホルダに説明し合意を得ることが手戻り防止の鍵となる。

あなたはあるオンライン予約サービスの刷新プロジェクトのシステムアーキテクトで、要件定義の場でステークホルダから「システムはできるだけ落ちないようにしてほしい」「セキュリティはしっかりしてほしい」という要望を受けたとします。この要望をそのまま「高可用性」「高セキュリティ」という言葉のまま要件定義書に記載して合意とするのは危険です。曖昧な表現のまま合意すると、開発が進んでから「思っていた水準と違う」という認識の齟齬が発覚し、設計のやり直しという大きな手戻りを招くからです。適切な進め方は、まず非機能要求グレードの可用性・セキュリティの項目に沿って、ステークホルダに「サービス停止時、業務にどの程度の影響があるか（例：予約の受付ができないと機会損失がいくら発生するか）」「復旧までどれくらいの時間なら許容できるか」を具体的に問いかけることです。その回答から、例えば「稼働率99.9%以上、障害発生時のRTO（目標復旧時間）は1時間以内」という測定可能な数値の合意へと落とし込みます。セキュリティについても同様に、「決済情報を扱うため、PCI DSS相当の基準に準拠し、多要素認証を必須とする」といった具体的な達成基準まで合意します。この際、稼働率99.99%のような過剰に高い目標を安易に設定すると、冗長構成のコストが跳ね上がるため、要求されている可用性の水準が本当にその業務影響に見合うものかをコストとの兼ね合いで検証し、根拠をステークホルダに説明することも欠かせません。「非機能要件は概念的な言葉のまま合意しても後で困らない」のではなく、曖昧な要望を測定可能な数値と達成基準に翻訳し、コストとの妥当性を含めて合意形成することが、非機能要件定義の核心です。

1.4.3この節のまとめ

• 非機能要求グレードを使い、利用者が意識しにくい項目まで漏れなく非機能要件を検討する
• 性能・可用性（RTO/RPO）・セキュリティは曖昧な言葉でなく測定可能な数値・達成基準として合意する
• 目標水準は業務影響とコストの兼ね合いを検証し根拠を説明することで手戻りと過剰品質の両方を防ぐ