非機能要件 ひきのうようけん
簡単に言うとこんな感じ!
「何ができるか」じゃなくて「どれだけ速く・安全に・安定して動くか」を決めるのが非機能要件だよ!レストランで例えると、メニュー(何を出すか)が機能要件で、「席数・回転率・衛生基準・営業時間」みたいな裏側の条件が非機能要件ってこと!
非機能要件とは
システム開発の要件定義では、「このシステムで何ができるか」を定める機能要件と、「そのシステムがどのような品質・特性で動作するか」を定める非機能要件の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推進・個人情報保護法改正を背景に、セキュリティ要件が非機能要件の中で特に重要視される傾向に
機能要件との違いと関係
非機能要件と機能要件は、どちらも要件定義書に必ず含まれる車の両輪です。両者の違いを整理しましょう。
機能要件は「何をするか(What)」を定義し、非機能要件はそれを「どのレベルで実現するか(How well)」を定義します。機能要件だけを完璧に満たしても、性能・可用性・セキュリティが不十分なら実務では使い物になりません。
また、SLA(サービスレベル合意書) はクラウドサービスやシステム運用契約において、非機能要件を契約として明文化したものです。たとえばAWSやAzureのSLAでは可用性(稼働率)が数値で保証されており、未達の場合は返金対応があります。
関連する規格・RFC
| 規格番号 | 内容 |
|---|---|
| ISO/IEC 25010:2011 | ソフトウェア製品品質モデル(SQuaRE)。機能適合性・性能効率性・互換性・使用性・信頼性・セキュリティ・保守性・移植性の8特性を定義 |
| IPA 非機能要求グレード 2018 | 日本語で非機能要件を6項目に体系化した実務ガイドライン。発注側・受注側の共通言語として広く活用される |
関連用語
- 要件定義 — システム開発の最初期に行う「何を作るか」を決めるプロセス
- 機能要件 — システムが「何をするか」を定義する要件。非機能要件と対になる概念
- SLA(サービスレベル合意書) — 非機能要件を契約として数値で明文化したもの
- 可用性 — システムが止まらずに使い続けられる度合いを示す指標
- RTO・RPO — 障害発生時の「復旧目標時間」「復旧目標時点」を表す非機能要件の代表的指標
- セキュリティ要件 — 不正アクセス・情報漏えいに対する対策を定めた非機能要件の一分野
- WBS(作業分解構成図) — 要件定義後の開発作業を細分化・管理するための図
- スコープ管理 — プロジェクトで「何をやるか・やらないか」を管理するプロセス