この記事は、PD-S（システム）試験（仮称）科目B 第1章の3節目、小項目1-3「システム要件における非機能要件の定義（性能，品質，セキュリティなど）」の教科書です。1-1で業務要件、1-2で機能要件と来て、いよいよ要件定義の総仕上げ＝「どれだけうまく動くか」を決める工程です。非機能要件は利用者が自分から語らない（暗黙の期待になりやすい）という厄介な性質があり、システム障害・性能トラブルの多くはここの見落としから生まれます。シラバス案の技能3つを全展開し、5カテゴリの中身と「稼働率99.9%」の読み方まで、前提知識ゼロから解説します。
この節の全体像 — なぜ非機能要件だけ「別の小項目」なのか
シラバス案は小項目1-3に「目標とする技能の例」を3つ挙げています。最初の2つ（収集・調整）は1-2と全く同じ文面で、3つ目が非機能要件の中身です。
わざわざ機能要件（1-2）と小項目を分けているのは、両者で失敗のしかたが違うからです。機能要件の漏れは開発中・受入テストで「この機能がない」と発覚しやすいのに対し、非機能要件の漏れは本番稼働後に「遅い」「落ちる」「復旧できない」という形で爆発します。後から直すには設計そのものの見直し（アーキテクチャ変更）が必要になることが多く、手戻りコストが桁違いに大きい——だから独立した小項目として、定義スキルが問われるのです。
入口：非機能要件の収集・調整は何が難しいか（技能1・技能2）
関係者から情報を収集し，整理して，要求をシステム要件として定義するスキル／
矛盾する要求を調整し，個々の要求を総合的に取りまとめるスキル
難しさ①：非機能の要求は「言われない」
利用者は「見積書をPDF出力したい」（機能）は語りますが、「画面は3秒以内に開いてほしい」「年に数時間しか止まらないでほしい」とは、まず言いません。速い・安全・止まらないことは当たり前の暗黙の期待だからです。そこで非機能要件の収集は、聞き取りを待つのではなく、こちらから枠組みを当てて引き出すのが定石です。
- カテゴリのチェックリストで総当たりする：後述の5カテゴリを1つずつ確認し、「決めていない項目」を潰す。
- 現行システムの実績値から導く：「今の画面は平均2秒で開いている」なら、新システムがそれより遅ければ確実に不満が出る。現行実績が事実上の下限になる。
- 業務特性から導く：「月末3日間に処理が集中する」「深夜はほぼ使われない」といった業務の形が、性能・稼働時間帯の要件を決める。
そして集めた要求は、1-2で学んだとおり検証可能な文（数値）にします。「十分速く」ではなく「通常時の画面応答は3秒以内、月末ピーク時でも5秒以内」。数値にできない非機能要件は、達成したかどうかを誰も判定できません。
難しさ②：非機能要件はトレードオフの塊
非機能要件の調整（技能2）が機能要件より難しいのは、要件同士とコストが正面からぶつかるからです。性能を上げればサーバ費用が上がる。セキュリティを固めれば利便性が下がる（ログイン手順が増える）。可用性を99.9%から99.99%に上げるだけで、冗長構成の追加により費用が跳ね上がる——。
中身：非機能要件の5カテゴリを全部おさえる（技能3）
対象業務の業務内容を踏まえ，対象業務の業務要件を実現するために必要な，性能要件，品質要件，セキュリティ要件，運用・保守要件，移行要件など，機能要件以外の要件を明確化し，定義するスキル
シラバス案が列挙する5カテゴリを、1つずつ「何を決めるのか・代表的な項目・具体例」で展開します。
図1：非機能要件の5カテゴリ（シラバス案・技能の例③の分解）
① 性能要件 — 速さと量
システムの「速さ」と「さばける量」を定義します。代表的な指標は次の2つで、混同しやすいので注意してください。
重要なのはピーク特性とセットで決めることです。平均値だけ決めても、月末・セール日・始業直後などの集中時に破綻します。「通常時◯秒、ピーク時（通常の3倍の同時利用）でも◯秒」のように条件付きで定義します。
② 品質要件 — 止まらないこと・壊れないこと・直せること
システムの「質」に関する要件で、中心になるのが可用性です。
稼働率の数字は直感が利きにくいので、年間の停止時間に換算して感覚を持っておきましょう（24時間365日運転＝年間8,760時間として単純計算）。
図2：稼働率と年間停止時間の目安（24時間365日運転での単純計算）
「9」が1つ増えるたびに許される停止時間は10分の1になり、実現コスト（冗長構成・自動フェイルオーバー等）は大きく跳ね上がります。ほかに品質要件には、障害の起きにくさ（信頼性）、直しやすさ・変更しやすさ（保守性・拡張性）などが含まれます。
③ セキュリティ要件 — 守り方を決める
「誰が・何に・どこまでアクセスできるか」を軸に定義します。代表項目：利用者の本人確認の方式（認証）、権限に応じた機能・データの制限（アクセス制御）、操作記録（ログ）の取得と保存期間、通信・保存データの暗号化、個人情報保護など関連法令への対応。業務で扱う情報の機密度が高いほど要件は厳しくなります。詳細な設計・技術は第2章（ネットワーク）や運用（2-3）でも扱うため、この段階では「何をどの水準で守るか」の要件化が仕事です。
④ 運用・保守要件 — 動かし続ける仕組み
稼働後の日常を定義します。代表項目：稼働時間帯（24時間365日か、平日日中のみか）、監視（何を監視し、異常時に誰へ通知するか）、バックアップ（頻度・保存世代・復旧手順）、障害対応の体制と目標復旧時間、定期メンテナンスの枠。1-1の技能6で決めた運用・保守の基本方針を、ここで検証可能な要件に具体化する関係です。
⑤ 移行要件 — 切り替えそのものの要件
忘れられがちですが、シラバス案は移行要件を明記しています。代表項目：移行に許される期間と業務停止の許容時間（「切替は連休中の48時間以内」）、データ移行の範囲と精度（「過去5年分の取引データを100%移行、それ以前は参照用アーカイブ」）、失敗時の切り戻し条件。1-1で選んだ移行方式（一斉・段階・並行）を、数値の要件に落とし込みます。
混同しやすい概念の整理
| 紛らわしいペア | 違いの核心 |
|---|---|
| 機能要件 ⇔ 非機能要件 | 機能＝システムが何をするか（1-2）。非機能＝どれだけうまく動くか（本節）。「ログイン機能がある」は機能、「ログインは2秒以内・二要素認証」は非機能 |
| 応答時間 ⇔ スループット | 応答時間＝1回の操作の速さ（利用者の体感）。スループット＝単位時間の処理量（システムの能力）。片方だけ良くても成立しない |
| 稼働率 ⇔ 目標復旧時間 | 稼働率＝動いている割合（結果の指標）。目標復旧時間＝止まってから復旧までの許容時間。稼働率が高くても1回の長時間停止で業務が致命傷なら復旧時間の要件が別に要る |
| 運用・保守要件 ⇔ 移行要件 | 運用・保守＝稼働後ずっと続く日常の要件。移行＝切り替え時だけの一時的な要件。どちらも「稼働後・稼働前は決めなくていい」という誤解が事故のもと |
| 要求の調整（機能） ⇔ 要求の調整（非機能） | 文面は同じ技能でも、非機能の調整は水準とコストの均衡点探し。「業務影響がいくらか」が判断軸になる |
確認クイズ（4問）
この節の理解度チェックです（当サイト独自の予想問題。公式の出題ではありません）。
次の要件のうち、非機能要件に該当しないものはどれか。
24時間365日運転のシステムで稼働率99.9%を要件とした場合、年間に許容される停止時間の目安はどれか（1年＝8,760時間として単純計算）。
「1時間あたりに処理できる注文件数」を表す性能指標として、最も適切なものはどれか。
非機能要件の収集の進め方として、最も適切なものはどれか。
まとめ：小項目1-3で身につけること
- 非機能要件＝「どれだけうまく動くか」。漏れは本番稼働後に爆発し、手戻りコストが機能の漏れより桁違いに大きい。
- 非機能の要求は言われない（暗黙の期待）。カテゴリの総当たり・現行実績値・業務特性でこちらから引き出し、検証可能な数値で定義する（技能1）。
- 調整の軸は業務影響とコストの均衡。全項目最高水準は誤り。業務要件に照らした必要十分な水準を合意する（技能2）。
- 5カテゴリ＝性能（応答時間・スループット＋ピーク特性）／品質（可用性＝稼働率など）／セキュリティ（認証・アクセス制御・ログ）／運用・保守（監視・バックアップ・体制）／移行（期間・停止許容・データ移行）（技能3）。
- 稼働率の感覚：99%＝年約88時間、99.9%＝年約8.8時間、99.99%＝年約53分の停止。9が増えるほどコストは跳ね上がる。
関連記事・次に読む
出典（一次情報）
- IPA「プロフェッショナルデジタルスキル（システム）試験（仮称）科目B シラバス（案 Ver0.2）」大項目1・小項目1-3（2026年7月31日更新）[link]。本文中の「技能の例」引用は同シラバス案からの原文引用です。
- IPA「情報処理技術者試験・情報処理安全確保支援士試験 出題範囲等の改定案 Ver.1.0」（2026年3月）
※試験名は仮称、内容は検討段階の案です。試験の形式・時間・配点・合格基準は未公表のため本記事では扱いません。技術解説（性能指標、稼働率の換算、収集の進め方など）は一般に確立した知識に基づく当サイトの解説で、シラバスの記載そのものではありません。稼働率の換算値は24時間365日運転（年8,760時間）での単純計算です。確認クイズは当サイト独自の予想問題です。正式シラバス公開時に内容を更新します。
