非機能要件とは？6分類の一覧と定義の進め方【非機能要求グレード対応】

2026 8/08

2026年8月8日

システム開発の要件定義で、機能の一覧は作り込んだのに、「レスポンスは速く」「止まらないこと」という曖昧な一文で片づけられてしまう領域があります。それが非機能要件です。

非機能要件は、リリース直前やリリース後になって牙をむきます。「想定の10倍のアクセスで落ちた」「障害時に誰も復旧できない」「監査で指摘されて作り直し」といった形です。

この記事では、非機能要件の定義と機能要件との違いから始めます。IPA（独立行政法人情報処理推進機構）が公開している『非機能要求グレード』の6大分類を軸に、何を・どのレベルで決めるべきかを一覧表で網羅します。

続いて次の3点を、実務でそのまま使える形で解説します。

ISO/IEC 25010の品質特性との対応
曖昧な要求を測定可能な数値に落とす書き方
定義した非機能要件をどうテストで検証するか

要件定義の担当者、プロジェクトマネージャー、QA・テスト担当者。いずれの立場でも、非機能要件の抜け漏れはプロジェクト全体のリスクになります。最後まで読めば、自社のシステムで「決めるべきなのに決めていない項目」が具体的に見えるはずです。

非機能要件とは？「どのように動くか」を定める要件のこと

非機能要件の定義

非機能要件（Non-Functional Requirements／NFR）とは、システムが備えるべき「機能以外のすべての要件」を指します。具体的には、性能、可用性、拡張性、運用・保守のしやすさ、セキュリティ、移行のしやすさ、稼働環境の制約などです。

ひとことで整理します。機能要件が「システムが何をするか（What）」を定めるのに対し、非機能要件は「システムがどのように動くか（How well）」を定めます。

たとえばECサイトで「商品を検索できる」は機能要件です。次の3つは、すべて非機能要件です。

検索結果は同時アクセス1,000セッションの状態でも2秒以内に返る
検索機能は年間稼働率99.9%以上
検索ログは1年間保管する

機能としては同じ「検索」でも、非機能要件のレベル設定次第で結果は変わります。必要なインフラ構成も開発工数もコストも、桁違いに変わります。

機能要件と非機能要件の違い（比較表）

両者の違いを、要件定義の実務で効いてくる観点で整理すると次のようになります。

観点	機能要件	非機能要件
問いの形	システムは何をするか（What）	システムはどのように動くか（How well）
具体例	会員登録、検索、決済、帳票出力	応答時間、稼働率、同時接続数、暗号化方式
発注者からの出方	業務要件として自然に出てくる	ほとんど出てこない。開発側からの提案が必須
合意のしやすさ	画面イメージで合意しやすい	数値化しないと合意できない
問題の発覚時期	結合テスト〜受入テストで発覚	負荷テスト・本番稼働後に発覚しやすい
手戻りコスト	比較的小さい（該当機能の修正）	非常に大きい（アーキテクチャからの再設計）
主な検証方法	機能テスト、シナリオテスト	性能テスト、障害試験、セキュリティ診断など

とくに重要なのが最後の2行です。機能要件のバグは「その機能を直す」ことで解決しますが、非機能要件の未達はアーキテクチャそのものが原因であることが多く、局所的な修正では解決しません。ここが非機能要件を軽視できない最大の理由です。

なぜ非機能要件は後回しにされるのか

非機能要件が抜け落ちる原因は、担当者の怠慢ではなく構造的なものです。主に次の3つが重なります。

発注者は非機能要件を言語化できない：業務担当者は「業務でやりたいこと」は語れますが、「秒間何リクエストまで耐えるべきか」は語れません。専門知識が必要なため、発注者から自発的に出てくることはほぼありません。
目に見えず、デモできない：画面のモックアップは見せられますが、「稼働率99.99%」は見せられません。関係者の関心が集まりにくく、レビューでも素通りしがちです。
コストと直結するため議論が先送りされる：可用性を1段階上げるだけで冗長構成や災害対策サイトが必要になり、費用が跳ね上がります。決められないまま「あとで詰める」となり、そのまま忘れられます。

有効なのは、チェックリストとして体系化されたフレームワークに沿って機械的に洗い出すアプローチです。その決定版が、次に解説するIPAの『非機能要求グレード』です。

非機能要件が抜けたときに起きる事故

抽象論ではイメージしにくいので、実際に起こりがちな失敗パターンを挙げます。いずれも「機能テストは全件パスしていた」という点が共通しています。

パターン1：リリース初日に性能問題が発覚し、作り直しになる

もっとも典型的な事故です。開発環境ではデータ件数が数百件しかなく、すべての操作が瞬時に返っていた。ところが本番は数百万件で、一覧画面が30秒返ってこない。

調査すると、テーブル設計とSQLがそもそも大量データを想定していませんでした。インデックス追加程度では解決しない、というケースです。

この場合、修正はデータモデルの見直しから始まるため、実質的な作り直しになります。要件定義の時点で「本番想定データ量は3年後で500万件」「一覧表示は3秒以内」と決めて設計に反映していれば、まったく違う設計になっていたはずです。詳しい決め方はシステム性能要件の定義方法で解説しています。

パターン2：障害は起きたが、誰も復旧手順を知らない

冗長構成にはなっていた。実際にプライマリDBが落ちたとき、フェイルオーバーが想定どおり動かなかった。手動切替の手順書も存在しなかった。

結果、復旧までに8時間かかった、というケースです。

可用性の要件を「冗長構成にする」で終わらせ、RTO（目標復旧時間）・RPO（目標復旧時点）を数値で決めず、障害試験も実施しなかったことが原因です。冗長化は「してあること」ではなく「切り替わることを確認済みであること」に価値があります。

パターン3：セキュリティ監査で指摘され、リリースが止まる

受入テスト直前に実施した脆弱性診断で、認証・認可の設計不備やログ保全の不足が指摘され、リリースが3か月延期になるケースです。ログ出力の設計やアクセス制御の粒度は、後付けするとアプリケーション全体に手が入るため、影響範囲が広くなります。

非機能要件の失敗は「バグ」ではなく「設計の前提の誤り」として現れる。だから修正コストが桁違いに大きい。

IPA『非機能要求グレード』とは

『非機能要求グレード』は、IPA（独立行政法人情報処理推進機構）が公開している非機能要件定義のための公的なフレームワークです。もともとは大手SIer6社の共同検討から生まれ、現在は「非機能要求グレード2018」が最新版として公開されています。

このフレームワークの価値は、非機能要件を6つの大分類に整理し、その下に具体的な要求項目とメトリクス（測定指標）、そしてレベル選択肢まで用意している点にあります。ゼロから項目を考える必要がなく、「この項目についてレベル何を選ぶか」という形で発注者と会話できます。

6大分類の全体像

まず全体像を押さえます。以下が非機能要求グレードの6大分類です。

大分類	何を決めるか	代表的な指標	主な検証手段
可用性	システムをどれだけ止めずに動かすか	稼働率、RTO、RPO、計画停止時間	障害試験、フェイルオーバーテスト
性能・拡張性	どれだけの処理量をどの速さで捌くか	応答時間、スループット、CPU使用率	性能テスト、負荷テスト
運用・保守性	誰がどう運用し、障害時にどう動くか	監視間隔、バックアップ世代数、対応時間帯	運用テスト、リハーサル
移行性	既存システムからどう移行するか	移行対象データ量、移行時間、並行稼働期間	移行リハーサル、データ検証
セキュリティ	どう守り、どう検知・追跡するか	認証方式、暗号化強度、ログ保管期間	脆弱性診断、ペネトレーションテスト
システム環境・エコロジー	どんな環境制約のもとで動かすか	設置スペース、消費電力、耐震性能	設置検証、環境試験

「重要項目」と「モデルシステム」という考え方

非機能要求グレードには、全体で200以上のメトリクスが定義されています。すべてを議論するのは現実的ではありません。用意されているのが、以下の2つの仕組みです。

重要項目：コストや品質に与える影響が特に大きい項目が絞り込まれています。時間が限られている場合は、まずここだけでも発注者と合意しておくべきという優先順位が示されています。
モデルシステム：「社会的影響が殆ど無いシステム」「社会的影響が限定されるシステム」「社会的影響が極めて大きいシステム」の3類型ごとに、推奨されるレベルの雛形が用意されています。自社システムがどの類型かを決めれば、そこを出発点に議論を始められます。

実務では、モデルシステムで叩き台を作り、重要項目から順に発注者と合意していくのが最短ルートです。ゼロから作るのではなく「デフォルト値を修正していく」形にすることで、議論のスピードが変わります。

非機能要件6大分類の一覧と要件記述サンプル

ここからが本記事の中核です。6大分類それぞれについて、中分類（要求項目）と、実際の要件定義書にそのまま書ける記述サンプルを一覧化します。自社のプロジェクトでチェックリストとして使ってください。

1. 可用性（Availability）

システムを「継続して動かし続ける」ための要件群です。止まらない設計と、止まったときに素早く戻す設計の両面を扱います。

中分類	代表的な要求項目	要件の記述サンプル
継続性	運用スケジュール、稼働率、目標復旧水準、大規模障害時の対応	「サービス提供時間は24時間365日。年間稼働率99.9%以上（計画停止を除く）」
継続性	業務継続性、目標復旧時間（RTO）	「重大障害発生時のRTOは4時間以内、RPOは15分以内とする」
耐障害性	サーバ冗長化、コンポーネント冗長化	「アプリケーションサーバは2台以上のActive-Active構成とし、1台停止時も業務を継続できること」
耐障害性	ストレージ／ネットワーク／データの冗長化	「DBはプライマリ／スタンバイ構成とし、同期レプリケーションによりデータ損失を発生させないこと」
災害対策	復旧方針、バックアップサイト、外部保管	「東日本／西日本の2リージョンにバックアップサイトを構え、被災時は24時間以内に切替可能とする」
回復性	復旧作業、リストア時間	「フルバックアップからのリストアは6時間以内に完了できること。四半期に1回リストア試験を実施する」

可用性でもっとも揉めるのが稼働率です。99.9%と99.99%は数字上は0.09%の差ですが、年間停止許容時間は約8.8時間と約53分で、必要な構成も費用もまったく異なります。「稼働率○%」だけで合意せず、必ず年間停止許容時間に換算して発注者と確認してください。

2. 性能・拡張性（Performance / Scalability）

処理量と処理速度、そして将来の増加に対する備えを定めます。非機能要件の中で、もっとも数値化しやすい領域です。同時に、もっとも未達が発覚しやすい領域でもあります。

中分類	代表的な要求項目	要件の記述サンプル
業務処理量	通常時／ピーク時のユーザ数、同時アクセス数	「登録ユーザ5万人、通常時同時接続300、ピーク時同時接続1,500を想定する」
業務処理量	データ量、蓄積件数と増加率	「取引データは初期100万件、年間300万件増、5年後1,600万件を上限とする」
性能目標値	オンライン応答時間	「主要画面はピーク時においても95パーセンタイルで3秒以内に応答すること」
性能目標値	スループット、バッチ処理時間	「日次バッチは深夜1時開始・4時完了。ピーク時1,000リクエスト/秒を処理できること」
リソース拡張性	CPU／メモリ／ディスク拡張性	「CPU平均使用率は定常時50%以下、ピーク時80%以下に収めること」
性能品質保証	帯域増強、スケールアウト方式	「アプリケーションサーバは無停止で台数を追加でき、10台までスケールアウト可能であること」

性能要件を書くときのポイントは、「いつの・どの処理が・どの負荷条件で・どれだけの速さか」の4点セットを必ず揃えることです。「レスポンス3秒以内」だけでは、平均値なのか最悪値なのか、通常時なのかピーク時なのかが決まらず、テストで合否判定ができません。パーセンタイル値で書くのが実務上のおすすめです。

3. 運用・保守性（Operability / Maintainability）

「作った後、誰がどう回すか」を定めます。開発側の関心が薄くなりがちですが、システムのライフサイクル全体で見たコストに、もっとも影響する領域です。

中分類	代表的な要求項目	要件の記述サンプル
通常運用	運用時間、バックアップ、運用監視	「日次フルバックアップを取得し7世代保管。監視は1分間隔とする」
通常運用	ジョブ管理、時刻同期	「全サーバはNTPにより時刻同期し、ずれは1秒以内に保つこと」
保守運用	計画停止、パッチ適用方針、定期保守	「セキュリティパッチは公開から30日以内に適用。計画停止は月1回・最大4時間まで」
障害時運用	復旧作業、代替手段、エスカレーション	「重大障害は検知から15分以内に一次窓口へ通報し、30分以内に責任者へエスカレーションする」
運用環境	開発／検証環境の設置、試験環境の維持	「本番同等構成の検証環境を常設し、性能試験に利用可能とする」
サポート体制	保守契約、問い合わせ窓口、教育	「サポートは平日9〜18時。重大障害は24時間365日で一次対応する」
その他運用	内部統制対応、ログ管理	「操作ログ・アクセスログは1年間オンライン保持、3年間アーカイブ保管とする」

4. 移行性（Migratability）

既存システムからの切り替えについての要件です。新規開発では軽視されがちですが、リプレース案件ではプロジェクトの成否を分ける最大のリスク要因になります。

中分類	代表的な要求項目	要件の記述サンプル
移行時期	システム停止可能時間、移行期間	「移行はサービス停止8時間以内で完了すること。実施は年末年始の連休中とする」
移行方式	一括移行／段階移行、並行稼働の要否	「拠点単位の段階移行とし、移行期間中は新旧システムを2か月間並行稼働させる」
移行対象（設備）	移行対象機器、設置作業	「既存サーバ12台をクラウドへ移行し、オンプレ機器は移行完了後に撤去する」
移行対象（データ）	移行データ量、文字コード変換、検証方法	「過去5年分・約2,000万件を移行。文字コードはShift_JISからUTF-8へ変換し、全件突合により検証する」
移行計画	移行リハーサル、切り戻し手順	「本番同等データでリハーサルを2回実施。切り戻し判断は移行開始から6時間経過時点で行う」

移行性で必ず決めておくべきなのが切り戻し（ロールバック）の判断基準と手順です。「うまくいかなかったら戻す」という曖昧な合意のまま当日を迎えると、判断できずにずるずると停止時間が延びます。「何時までに何が完了していなければ切り戻す」を事前に文書化してください。

5. セキュリティ（Security）

6大分類の中で、もっとも項目数が多い領域です。「守る」だけでなく「検知する」「追跡する」まで含めて設計する必要があります。

中分類	代表的な要求項目	要件の記述サンプル
前提条件・制約	順守すべき法令・ガイドライン・社内規程	「個人情報保護法およびPCI DSS v4.0の該当要件を満たすこと」
セキュリティリスク分析	資産の特定、脅威分析、対策方針	「保護対象資産を特定し、設計フェーズで脅威モデリングを実施する」
セキュリティ診断	脆弱性診断、ペネトレーションテスト	「リリース前に第三者による脆弱性診断を実施し、High以上の指摘はゼロとする」
アクセス・利用制限	認証方式、権限管理、特権ID管理	「管理者操作は多要素認証を必須とし、権限は職務分掌に基づくロールで管理する」
データの秘匿	通信・保存データの暗号化	「通信はTLS1.2以上。個人情報はAES-256で暗号化して保存する」
不正追跡・監視	操作ログ、アクセスログ、証跡保全	「特権操作の証跡を改ざん不可能な形で取得し、1年間保管する」
ネットワーク対策	セグメント分離、ファイアウォール、IDS/IPS	「DMZと内部セグメントを分離し、DBサーバへの直接インターネット接続を禁止する」
マルウェア対策	ウイルス対策、パターン更新	「全サーバにEDRを導入し、定義ファイルを日次で自動更新する」
Web対策	WAF、入力値検証、セキュアコーディング	「WAFを導入し、OWASP Top 10に該当する攻撃を検知・遮断する」

6. システム環境・エコロジー（System Environment / Ecology）

システムを設置・稼働させる、物理的・制度的な環境についての要件です。クラウド化により重要度が下がったと思われがちですが、法令順守や環境配慮の観点では依然として必要な領域です。

中分類	代表的な要求項目	要件の記述サンプル
システム制約	設置場所、設置スペース、重量・耐荷重	「機器はデータセンター内の指定ラック2本以内に収めること」
システム制約	使用可能な電源容量、空調条件	「ラックあたりの消費電力は6kVA以内とする」
システム特性	ユーザ数、拠点数、利用端末の種類	「利用拠点は国内30拠点。端末はWindows PCおよび業務用タブレットを対象とする」
システム特性	特定製品指定、他システム連携の制約	「既存の認証基盤（SAML 2.0）と連携できること」
環境マネジメント	環境負荷対策、消費電力削減、リサイクル	「省電力基準に適合した機器を選定し、廃棄時は認定業者によるリサイクルを行う」
環境マネジメント	耐震・免震、電磁波対策	「震度6強に耐える免震ラックに設置すること」

ISO/IEC 25010（品質特性）との対応関係

非機能要求グレードは「発注者と受注者が合意するためのチェックリスト」です。ISO/IEC 25010は「ソフトウェア製品の品質をどう捉えるか」を定めた国際規格です。

テスト設計の観点では、後者のほうが直接的に役立ちます。両者を対応づけて理解しておくと、要件定義からテスト設計への橋渡しがスムーズになります。

ISO/IEC 25010の品質特性	意味	非機能要求グレードの対応分類
機能適合性	必要な機能を過不足なく正確に提供するか	（主に機能要件の領域）
性能効率性	時間効率・資源効率・容量が適切か	性能・拡張性
互換性	他システムと共存・連携できるか	システム環境、移行性
使用性（ユーザビリティ）	学習しやすく、操作しやすく、誤りにくいか	システム環境（システム特性）
信頼性	成熟性・可用性・障害許容性・回復性	可用性
セキュリティ	機密性・完全性・否認防止・責任追跡性・真正性	セキュリティ
保守性	モジュール性・再利用性・解析性・修正性・試験性	運用・保守性
移植性	環境適応性・設置性・置換性	移行性、システム環境

実務上の使い分けは明快です。発注者との合意形成には非機能要求グレード、テスト観点の網羅性チェックにはISO/IEC 25010を使います。

要件定義書の項目立ては、非機能要求グレードに沿わせます。テスト計画を作る段階で25010の品質特性を使い、「この特性を検証するテストがあるか」を確認します。この流れが効率的です。

旧規格のISO/IEC 9126では、品質特性は6つ（機能性・信頼性・使用性・効率性・保守性・移植性）でした。25010ではここに互換性とセキュリティが独立した特性として加わっています。古い資料を参照する際は注意してください。

非機能要件の書き方：曖昧な言葉を測定可能な数値に落とす

項目を洗い出せても、書き方が曖昧では意味がありません。非機能要件の品質は「テストで合否判定できるかどうか」で決まります。判定できない要件は、要件ではなく願望です。

悪い書き方・良い書き方の対比

悪い書き方（判定不能）	良い書き方（判定可能）	何を足したか
レスポンスが速いこと	ピーク時1,000リクエスト/秒の負荷下で、商品検索画面の応答時間が95パーセンタイルで3秒以内であること	対象処理・負荷条件・統計値・閾値
システムが安定して動くこと	計画停止を除く年間稼働率99.9%以上（年間停止許容時間8時間45分以内）であること	測定式・除外条件・許容時間への換算
大量データに耐えられること	取引明細1,600万件を格納した状態で、月次集計バッチが2時間以内に完了すること	データ件数・対象処理・完了時間
セキュリティを確保すること	第三者による脆弱性診断でCVSS 7.0以上の指摘が0件であること	評価者・評価基準・受入基準
障害からすぐ復旧できること	プライマリDB障害時、自動フェイルオーバーにより5分以内にサービスを再開すること（RPO 0）	障害シナリオ・復旧手段・RTO/RPO
運用しやすいこと	サーバ再起動を伴わずにアプリケーションをデプロイでき、デプロイ作業は30分以内で完了すること	具体的な運用操作・制約・所要時間
将来の拡張に対応できること	アプリケーションサーバを無停止で追加でき、4台構成時にスループットが2台構成比1.8倍以上になること	拡張方法・停止可否・スケール効率

測定可能な要件にするための5原則

対象を特定する：「システム全体」ではなく「どの画面・どのバッチ・どのAPI」まで絞ります。全画面一律の性能要件は、多くの場合過剰な要求になりコストを押し上げます。
条件を明記する：どの時間帯・どの負荷・どのデータ量での話かを書きます。条件のない性能値は、テストのときに必ず「その前提が違う」という争いになります。
統計値を指定する：平均値なのか、95パーセンタイルなのか、最大値なのかを決めます。平均値だけで合意すると、一部ユーザだけ極端に遅い状態を許容してしまいます。
測定方法を決める：どこからどこまでを測るか（ブラウザ描画完了までか、サーバ応答までか）を定義します。ここが曖昧だと、同じシステムで測定結果が2倍違うこともあります。
根拠を残す：なぜその数値なのかを一行でよいので記録します。「業務上、朝礼前の9時台に全社員がアクセスするため」といった根拠があれば、後の見直しで判断できます。

非機能要件定義の進め方（5ステップ）

実際の進め方を、発注者・受注者双方の動きを含めて整理します。

システムの位置づけを決める：まず「このシステムが止まったとき、誰にどんな影響が出るか」を発注者と確認します。社内の一部門だけが困るのか、顧客のサービスが止まるのか、社会インフラに影響するのか。ここで非機能要求グレードのモデルシステム類型が決まります。
機能要件と業務量を固める：非機能要件は機能要件の上に乗るものです。どんな業務がどれくらいの頻度・件数で発生するかが分からないと、性能要件は書けません。業務フローと業務量調査を先に済ませます。
受注者側が叩き台を作る：発注者から非機能要件は出てきません。モデルシステムの推奨レベルをベースに、受注者側が全項目に仮の値を入れた案を作ります。この「埋まった状態」から始めるのが重要です。
レベルとコストをセットで提示し合意する：重要項目については「レベル2ならこの構成でこの費用、レベル3ならこう変わる」という形で選択肢を提示します。非機能要件の議論は、実質的にコストの議論です。トレードオフを見せることで初めて発注者が判断できます。
受入基準とテスト方法まで書き切る：合意した数値を、誰がいつどうやって検証するかまで決めます。ここを飛ばすと「要件は書いてあるが誰もテストしていない」状態になります。要件定義とテスト計画を対応づける考え方はVモデルの基本と実践的な活用方法で詳しく解説しています。

非機能要件をどうテストするか

要件定義の記事の多くはここで終わりますが、非機能要件は検証されて初めて意味を持ちます。定義した6分類それぞれを、どのテストで検証するのかを整理します。

検証対象の分類	テストの種類	何を確認するか	実施時期の目安
性能・拡張性	性能テスト	想定負荷での応答時間・スループットが目標値を満たすか	システムテスト期
性能・拡張性	負荷テスト／ストレステスト	ピーク負荷・限界負荷での挙動、ボトルネックの特定	システムテスト期
性能・拡張性	耐久テスト（ロングランテスト）	長時間稼働でのメモリリーク・性能劣化の有無	システムテスト期〜受入前
可用性	障害試験（フェイルオーバーテスト）	機器・プロセス停止時に切替が働き、RTO/RPOを満たすか	システムテスト期
可用性	バックアップ／リストア試験	取得したバックアップから所定時間内に復旧できるか	システムテスト期・運用開始後も定期実施
セキュリティ	脆弱性診断	既知の脆弱性・設定不備が残っていないか	結合テスト後〜リリース前
セキュリティ	ペネトレーションテスト	実際の攻撃手法で侵入・権限昇格が可能か	リリース前
運用・保守性	運用テスト	監視・通報・エスカレーション・定常作業が手順どおり回るか	受入テスト期
移行性	移行リハーサル／データ検証	制限時間内に移行が完了し、データが欠落・変質しないか	受入テスト期
システム環境	設置・環境試験	設置制約・電源・連携先条件を満たすか	環境構築時

性能テストと負荷テスト

非機能テストの中心となるのが性能・負荷テストです。ポイントは「本番相当のデータ量」と「本番相当のシナリオ」を再現できるかに尽きます。データが空のDBに対して負荷をかけても、本番で問題になる遅いクエリは表面化しません。

単一のAPIを連打するだけのテストでは、実態を測れません。実際のユーザは「ログイン→検索→詳細閲覧→カート投入→決済」という一連の流れで動きます。その比率も時間帯によって変わります。

この比率を含めたシナリオ設計の考え方は、負荷テストシナリオの設計手順にまとめています。

性能テストで測るべき指標は、応答時間だけではありません。スループット、エラー率、サーバ側のCPU・メモリ・ディスクI/O・コネクション数を同時に取得します。これがないと、「遅い」という事実は分かってもボトルネックを特定できません。

障害試験（フェイルオーバーテスト）

可用性要件の検証には、意図的に障害を発生させる試験が必要です。代表的なシナリオは次のとおりです。

アプリケーションサーバ1台の電源断（切替時間と、処理中リクエストの扱いを確認）
DBプライマリの停止（自動フェイルオーバーの成否とデータ損失の有無を確認）
ネットワーク断・遅延の注入（タイムアウト設定とリトライ挙動を確認）
ディスク容量枯渇（ログ書き込み失敗時の挙動と、アラートが上がるかを確認）
外部連携先の応答停止（サーキットブレーカーや縮退運転が働くかを確認）

障害試験で見るべきは「切り替わったか」だけではありません。監視が正しく検知して通報したか、運用担当者が手順書どおりに動けたかまで含めて評価してこそ、可用性要件を満たしたと言えます。

セキュリティテスト

脆弱性診断は、ツールによる自動スキャンと専門家による手動診断を組み合わせるのが基本です。自動スキャンは既知パターンの検出には強い一方、業務ロジックに依存する脆弱性は見つけられません。認可制御の不備（他人のIDを指定すると他人のデータが見えてしまう類の欠陥）などです。

診断のタイミングも重要です。リリース直前に実施すると、指摘が出たときにスケジュールを守れません。結合テスト完了時点で一度診断を行い、修正期間を確保したうえでリリース前に最終確認する二段構えが安全です。

運用テストと移行リハーサル

運用テストは、システムそのものではなく「運用の仕組みが回るか」を検証するテストです。監視アラートが正しい相手に届くか、手順書だけを見て復旧作業ができるか、バックアップからのリストアが本当に成功するか。これらは受入テストの一部として実施されることが多く、位置づけは受入テストの基本と実践で整理しています。

移行リハーサルは、本番と同じデータ量・同じ手順で時間を計測することが目的です。1回目で必ず想定を超える時間がかかります。最低2回の実施を計画に織り込んでおくべきです。

非機能テストを含む各テストの全体像は、システムテストの種類一覧で俯瞰できます。

非機能テストは外部の専門チームに任せるという選択肢

ここまで読んで、非機能テストの実施ハードルが高いと感じた方も多いはずです。実際、非機能テストは機能テストとは必要なものが大きく異なります。

本番相当の環境が要る：スペックの違う環境で測った性能値には意味がありません。しかし本番同等の環境を常設するコストは小さくありません。
専用ツールと使いこなすスキルが要る：負荷生成ツール、APM、脆弱性診断ツールなどの選定・構築・結果の読み解きには経験が必要です。
実施期間が短期集中になる：性能テストや診断はプロジェクト終盤の限られた期間に集中します。そのために専任者を通年で抱えるのは非効率です。
開発チームによる自己検証には限界がある：設計した本人が測ると、無意識に「うまくいく条件」で測ってしまいがちです。第三者の目が入ることで初めて見つかる問題があります。

こうした事情から、非機能テストは外部の専門チームに委託する合理性が特に高い領域です。

ソフトウェアテスト代行サービス『テスター10』では、非機能要件の検証をまとめてお引き受けしています。性能テスト・負荷テストのシナリオ設計から実行・ボトルネック分析、障害試験、セキュリティ診断、運用テストまでが対象です。

「非機能要件は定義したものの、どう測ればよいか分からない」「そもそも定義した数値が妥当か自信がない」といった段階からのご相談も可能です。要件定義のレビューから入り、テスト計画・実施・報告まで一貫して支援します。

非機能要件に関するよくある質問（FAQ）

Q. 非機能要件は誰が書くべきですか？

叩き台は受注者（開発ベンダー）側が作り、決定は発注者が行うのが原則です。技術的な選択肢とコストへの影響を提示できるのは受注者側ですが、「どのリスクをいくらで買うか」を判断できるのは発注者だけだからです。受注者が勝手に決めると過剰品質か品質不足のどちらかになり、発注者に丸投げすると項目が埋まりません。

Q. 小規模なシステムでも6大分類すべてを定義すべきですか？

すべての項目を埋める必要はありませんが、6大分類すべてに目を通し「この分類は今回は要件なしと判断した」と記録することは推奨します。「検討した結果、不要と判断した」と「そもそも検討していない」はまったく違います。前者なら後で問題が起きても判断の経緯を追えますが、後者は原因も責任も曖昧になります。

Q. クラウド（AWS・Azureなど）を使えば非機能要件は不要になりませんか？

いいえ、むしろ選択肢が増える分、決めるべきことは増えます。マルチAZにするか、オートスケールの閾値をいくつにするか、どのバックアップ方式を選ぶか。これらはすべて非機能要件から導かれる設計判断です。

クラウドは「実現手段が簡単になった」だけです。「何を実現すべきか」を決める必要はなくなりません。クラウド利用料は構成で変わるため、非機能要件の設定がランニングコストに直結します。

Q. アジャイル開発では非機能要件をどう扱いますか？

アジャイルでも非機能要件は必要です。扱い方は主に2通りあります。

性能や可用性の目標値のように全体に関わるものは、「制約条件」としてプロダクト全体に適用する
個別に検証できるものは、「完了の定義（Definition of Done）」に組み込むか、独立したバックログアイテムとして積む

重要なのは、非機能要件の検証を最終スプリントにまとめて先送りしないことです。アーキテクチャに関わる要件ほど、早い段階で実測して確かめる必要があります。

Q. RASISやSLAとの関係は？

RASIS（Reliability／Availability／Serviceability／Integrity／Security）は、システムの信頼性を評価する古典的な観点セットです。非機能要求グレードの可用性・運用保守性・セキュリティと、おおむね重なります。

SLA（Service Level Agreement）は、合意した非機能要件のうちサービス提供者が対外的に約束する部分を契約書に落としたものです。

関係を整理すると「非機能要件で決めた値のうち、契約上の約束にする範囲がSLA」となります。SLAを結ぶ前提として、非機能要件の数値化が必須になります。

Q. 非機能要件は途中で見直してもよいですか？

見直すべきです。ただし「テストで達成できなかったから基準を下げる」という後付けの緩和は避けなければなりません。

見直しの正しいトリガーは次の3つです。

業務量の前提が変わったとき
法令や社内規程が変わったとき
設計が進んで当初の想定が非現実的だと判明したとき

いずれの場合も、変更理由と承認者を記録に残してください。

まとめ

非機能要件は「システムがどのように動くか」を定める要件です。機能要件と違って、発注者からは自発的に出てきません。体系化されたフレームワークに沿って、機械的に洗い出す必要があります。

洗い出しはIPA『非機能要求グレード』の6大分類で：可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジー。モデルシステムの推奨値を叩き台にして、重要項目から合意していきます。
テスト観点の網羅チェックはISO/IEC 25010で：8つの品質特性それぞれに対応するテストがあるかを確認します。
書き方は「テストで合否判定できるか」が基準：対象・条件・統計値・閾値・測定方法の5点を揃えます。
定義した要件は必ず検証する：性能テスト、負荷テスト、障害試験、脆弱性診断、運用テスト、移行リハーサル。定義しただけで検証しない非機能要件は、存在しないのと同じです。

非機能要件の失敗は、リリース後に「設計の前提の誤り」として顕在化し、局所修正では解決できません。逆に言えば、要件定義の段階で数値化し、テストで確かめておくだけで、プロジェクト最大級のリスクを潰せるということです。

非機能テストの実施環境やノウハウにお困りの場合は、ソフトウェアテスト代行サービス『テスター10』までお気軽にご相談ください。要件のレビューからテスト計画・実施・報告まで、貴社の体制に合わせて支援します。