スコープ管理

非機能要件 ひきのうようけん

要件定義性能要件可用性セキュリティ要件保守性SLA
非機能要件について教えて

簡単に言うとこんな感じ!

「何ができるか」じゃなくて「どれだけ速く・安全に・安定して動くか」を決めるのが非機能要件だよ!レストランで例えると、メニュー(何を出すか)が機能要件で、「席数・回転率・衛生基準・営業時間」みたいな裏側の条件が非機能要件ってこと!


非機能要件とは

システム開発の要件定義では、「このシステムで何ができるか」を定める機能要件と、「そのシステムがどのような品質・特性で動作するか」を定める非機能要件の2種類があります。非機能要件は、ユーザーが直接操作する画面や機能とは別に、システム全体の「品質・信頼性・制約」を規定するものです。

たとえば「注文ボタンを押したら注文が完了する」は機能要件ですが、「注文処理は2秒以内に完了すること」「年間稼働率99.9%以上を保証すること」「不正アクセスを検知・遮断する仕組みを持つこと」などは非機能要件にあたります。システムが”使いものになるか”を左右する、見えないけれど重要な条件です。

非機能要件は発注時に曖昧にされがちですが、後から「重くて使えない」「夜中に止まる」「情報漏えいが心配」といった問題が発覚すると、追加費用や手戻りが膨大になります。発注前・要件定義段階で必ず数値で明記することが、発注側にとって最大のポイントです。


非機能要件の主な分類と具体例

IPAが公開している「非機能要求グレード」では、非機能要件を6つの大項目に分類しています。それぞれの意味と、発注時に確認すべき具体例を以下に示します。

大項目意味発注時の確認例
可用性システムがどれだけ止まらずに動き続けるか年間稼働率・計画停止の頻度・障害復旧時間(RTO)
性能・拡張性処理の速さ・同時接続数・将来の増加への対応レスポンスタイム・同時アクセス数上限・データ増加時の対応
運用・保守性日常的な運用のしやすさ・障害対応・バージョンアップバックアップ方法・監視体制・バージョンアップ対応
移行性既存システムからのデータ移行・切り替え方法データ移行手順・並行稼働期間・切り戻し計画
セキュリティ情報漏えい・不正アクセスへの対策認証方式・暗号化・ログ取得・脆弱性診断
システム環境・エコロジー設置場所・電力・法規制対応など設置場所の条件・消費電力・法令対応(個人情報保護法など)

覚え方:「か・せ・う・い・せ・え」

6項目の頭文字をとると「可・性・運・移・セ・環(か・せ・う・い・せ・え)」。「かせうい、せえ(稼ぜ言えないよ)」と覚えると発注時のチェックリストとして使えます!

数値で書かないと意味がない

非機能要件で最も多い失敗が「高い可用性を確保すること」「十分な性能を持つこと」など数値のない曖昧な表現です。これはベンダーに解釈の余地を与え、後々トラブルになります。

悪い例(曖昧)良い例(数値明記)
高速に動作すること画面遷移は3秒以内に完了すること
高可用性を確保すること年間稼働率99.9%以上(年間停止8.7時間以内)
セキュリティに配慮すること通信はTLS 1.2以上で暗号化し、年1回脆弱性診断を実施すること

歴史と背景

  • 1990年代: システム開発が複雑化するにつれ、「動く」だけでは不十分な事例が増加。性能・信頼性の欠如によるシステム障害が社会問題化
  • 2000年代前半: ISO/IEC 9126(ソフトウェア品質モデル)が整備され、「機能性・信頼性・使用性・効率性・保守性・移植性」という品質特性の国際標準が確立
  • 2010年: IPA(情報処理推進機構)が「非機能要求グレード」を公開。発注側と受注側が共通言語で非機能要件を議論できるガイドラインとして普及
  • 2011年: 東日本大震災後、システムの事業継続性(BCP)への意識が高まり、可用性・災害対策の非機能要件が重視されるように
  • 2015年〜: クラウド普及により、SLA(サービスレベル合意書)として非機能要件が契約に明記されるケースが標準化
  • 2020年代: DX推進・個人情報保護法改正を背景に、セキュリティ要件が非機能要件の中で特に重要視される傾向に

機能要件との違いと関係

非機能要件と機能要件は、どちらも要件定義書に必ず含まれる車の両輪です。両者の違いを整理しましょう。

機能要件 vs 非機能要件 機能要件 「何ができるか」 ログイン機能がある 注文を確定できる 在庫を検索できる 帳票を出力できる メール通知が届く 非機能要件 「どれだけ良く動くか」 ログインは1秒以内に完了 年間稼働率99.9%以上 同時1000件検索に対応 通信はTLS1.2以上で暗号化 障害復旧は4時間以内 品質を 規定

機能要件は「何をするか(What)」を定義し、非機能要件はそれを「どのレベルで実現するか(How well)」を定義します。機能要件だけを完璧に満たしても、性能・可用性・セキュリティが不十分なら実務では使い物になりません。

また、SLA(サービスレベル合意書) はクラウドサービスやシステム運用契約において、非機能要件を契約として明文化したものです。たとえばAWSやAzureのSLAでは可用性(稼働率)が数値で保証されており、未達の場合は返金対応があります。


関連する規格・RFC

規格番号内容
ISO/IEC 25010:2011ソフトウェア製品品質モデル(SQuaRE)。機能適合性・性能効率性・互換性・使用性・信頼性・セキュリティ・保守性・移植性の8特性を定義
IPA 非機能要求グレード 2018日本語で非機能要件を6項目に体系化した実務ガイドライン。発注側・受注側の共通言語として広く活用される

関連用語