非機能要件とは？機能要件との違いをSG試験向けに整理

まず結論

非機能要件とは、システムが何をするかではなく、どの程度の品質で動くべきかを示す要件です。

SG試験では、次のように切り分けます。

問い合わせを登録する、受付番号を発行する、通知を送る → 機能要件
稼働率を維持する、障害時に一定時間以内に復旧する、応答時間を満たす → 非機能要件

迷ったら、「業務処理そのものか、品質・制約条件か」を先に見ます。

このページで切り分けること（先にここだけ）

このページは、機能要件と非機能要件の違いを中心に整理します。

機能要件：システムが行う処理や業務ルール
非機能要件：性能、可用性、信頼性、使用性、保守性、セキュリティなどの品質条件
SG試験の判断：選択肢の動詞が「処理する」か「品質を満たす」かを見る

迷ったら、 「その条件がなくても業務処理の内容を説明しているか」 を見ます。

直感的な説明

機能要件は、システムのできることです。非機能要件は、システムをどのくらい安心して使えるかです。

たとえば、問い合わせ管理システムで考えると分かりやすいです。

要件の例	分類	理由
問い合わせ内容を登録する	機能要件	システムが行う業務処理そのもの
受付番号を発行する	機能要件	採番という処理内容を示している
回答期限が近い案件を担当者に通知する	機能要件	通知を出すという機能を示している
障害時の復旧目標時間を定める	非機能要件	復旧時間という品質・運用条件を示している
月間可用性の目標値を定める	非機能要件	可用性の水準を示している

「警告する」「入力する」「承認する」という表現があると、セキュリティや品質っぽく見えることがあります。しかし、システムが行う処理内容を表しているなら、基本的には機能要件です。

一方、「速い」「止まりにくい」「復旧が早い」「使いやすい」「保守しやすい」「安全に使える」といった条件は、システムの品質に関するため、非機能要件として判断します。

定義・仕組み

機能要件と非機能要件は、要求定義で整理する代表的な要件です。

種類	見るポイント	代表例
機能要件	システムが何をするか	登録、検索、計算、表示、承認、通知
非機能要件	どの品質・条件で動くか	性能、可用性、信頼性、使用性、保守性、移行性、セキュリティ

情報システムの開発では、業務機能に関する要求だけでなく、非機能要求の認識違いも問題になります。IPAの「非機能要求グレード2018 改訂情報」でも、非機能要求の確認を行うツール群として非機能要求グレードが説明されています。 IPA：非機能要求グレード2018 改訂情報

SG試験では、非機能要件の細かい分類名を深く暗記するより、次の代表例を押さえるのが効果的です。

非機能要件の観点	選択肢で出やすい表現	判断ポイント
性能	応答時間、処理件数、同時接続数	どれくらい速く・多く処理できるか
可用性	稼働率、停止時間、復旧時間	必要なときに使えるか
信頼性	障害が起きにくい、安定して動く	正しく安定して動き続けるか
使用性	分かりやすい画面、操作しやすさ	利用者が迷わず使えるか
保守性	修正しやすい、運用しやすい	変更・保守・運用がしやすいか
セキュリティ	認証、権限管理、ログ、暗号化	安全に利用できるか

特に、稼働率や復旧時間は、可用性に関する非機能要件として出題されやすい表現です。

どんな場面で使う？

非機能要件は、新しいシステムを作るときだけでなく、クラウドサービスの選定、委託先への開発依頼、SLAの検討、既存システムの改善でも使います。

たとえば、社内の問い合わせ管理システムを導入するとき、業務部門は次のような機能を求めます。

問い合わせを登録できること
対応状況を検索できること
回答期限を確認できること
管理者が担当部署を変更できること

これらは、業務を実現するための機能要件です。

一方で、情報システム部門や運用担当者は、次のような条件も確認します。

業務時間中に止まらないこと
障害時に一定時間以内に復旧できること
画面の応答が遅すぎないこと
利用者が操作を間違えにくいこと
権限のない人が問い合わせ情報を見られないこと
運用担当者がログを確認できること

これらは、システムを安全・安定・継続的に使うための非機能要件です。

関連する考え方として、要求を整理する工程は要求定義プロセスとは？企画・開発・保守との違いを整理【SG試験】で確認できます。また、稼働率や復旧時間の考え方は、稼働率とは？可用性の考え方とSLAでの判断基準【SG試験】やSLAとは？サービス品質の合意内容をSG試験向けに整理とつなげて学ぶと判断しやすくなります。

よくある誤解・混同

誤解1：警告メッセージは非機能要件である

これは、問題文の書き方によって注意が必要です。

「期限が近い案件を担当者に通知する」「入力漏れがある項目を警告する」のように、通知や警告を出す処理そのものを求めている場合は、機能要件です。

一方で、警告画面の分かりやすさ、警告表示までの応答時間、障害時にも警告機能を使えることなどは、非機能要件に関係します。

SG試験では、まずその文が業務処理を説明しているかを見ます。

誤解2：セキュリティに関係すればすべて非機能要件である

セキュリティは非機能要件として扱われることが多いですが、選択肢では機能要件として書かれる場合もあります。

表現	判断
利用者IDとパスワードでログインできる	機能要件寄り
権限のない利用者が情報を閲覧できないこと	非機能要件寄り
操作ログを記録する	機能要件寄り
ログを改ざんされにくく保管する	非機能要件寄り

「認証する」「ログを記録する」などの処理は機能として表現されることがあります。「安全性の水準」「権限管理の方針」「監査できる状態」などを求めている場合は、非機能要件として考えます。

誤解3：非機能要件は開発後に考えればよい

非機能要件は、後から付け足すと手戻りが大きくなります。

たとえば、稼働率や復旧時間を後から厳しくすると、システム構成、バックアップ、監視、運用体制まで見直しが必要になることがあります。

そのため、要求定義の段階で、業務機能とあわせて非機能要件も整理しておくことが重要です。

SG試験で選択肢を切る判断軸（非機能要件編）

「計算する」「登録する」「表示する」「承認する」と書かれている → 機能要件を疑います。業務処理そのものを説明しているためです。
「稼働率」「復旧時間」「応答時間」「同時接続数」と書かれている → 非機能要件を疑います。性能や可用性などの品質水準を示しているためです。
「警告メッセージを出す」と書かれている → まずは機能要件を疑います。警告の見やすさや表示速度ではなく、警告を出す処理そのものなら機能です。
「障害時に何時間以内に回復する」と書かれている → 非機能要件です。業務処理ではなく、可用性・回復性の条件を示しています。

確認問題（SG試験対策）

次のうち、問い合わせ管理システムの非機能要件として最も適切なものはどれか。

ア. 利用者が問い合わせ内容を入力すると、受付番号を発行する。
イ. 担当者が回答を登録すると、利用者へ通知メールを送る。
ウ. 通常時の画面応答を3秒以内にし、障害時の復旧目標時間を定める。
エ. 管理者だけが問い合わせの担当部署を変更できる。

▶ クリックして答えと解説を見る（ここを開く）

正解：ウ

解説

ア：不適切。受付番号を発行する処理は、業務機能そのものです。
イ：不適切。通知メールを送る処理は、機能要件として判断します。
ウ：適切。応答時間や復旧目標時間は、性能・可用性に関する非機能要件です。
エ：不適切。権限に基づいて担当部署を変更する処理は、業務機能やアクセス制御の要件として読みます。

👉 判断ポイント「何を処理するか」ではなく、「どの品質・条件で動くか」を求めている選択肢を選びます。

まとめ（試験直前用）

非機能要件は、システムの品質や制約条件に関する要件です。

処理内容なら機能要件
性能・可用性・復旧時間・使いやすさなら非機能要件
「通知や警告を出す」は機能要件、「復旧目標時間を定める」は非機能要件
SG試験では、業務処理そのものか、品質水準かで選択肢を切る

🔗 関連記事

🏠 情報セキュリティマネジメントトップに戻る