シリーズ: 要件定義とはそもそも何か
- 要件定義の目的とゴールとは
- 要件定義の重要ポイント〜要望・要求・要件を見極める
- 事業・業務・システムの3階層で要件を捉える
- 業務フロー図で見える化する業務プロセスからシステム要件への道筋
- ユースケースとロバストネス図によるシステム要件定義
- システム要件定義の成果物〜設計へのインプットを作成する
- 要件定義とソフトウェアアーキテクチャ設計
- 要件定義とクラス設計
- 要件定義とデータベース設計
- 要件定義と画面設計
- 要件定義とAPI設計
- 要件定義とバッチ処理設計
- 要件とは何か
- 非機能要件とは何か（本記事）
- 要件定義を学ぶ人におすすめの書籍まとめ
- 移行要件とは何か
- 要件定義のプロセスと成果物を体系的に理解する【全体像まとめ】
- 要件定義と設計の関係を体系的に理解する【全体像まとめ】
TRACERYプロダクトマネージャーの haru です。
非機能要件とは、機能要件以外でシステムが備えるべき品質や制約条件を示す要件です。具体的には、性能や可用性、セキュリティ、保守性などが該当します。
機能要件が各機能単位で定義されるのに対し、非機能要件はシステム全体に共通する特性としてまとめられるのが一般的です。
本記事では、非機能要件について説明します。
非機能要件の定義
非機能要件の定義には、日本語のものでは、IPA*1の非機能要求グレードやJUAS*2の非機能要求仕様定義ガイドラインなどがありますが、本連載では REBOK第1版（Requirements Engineering Body of Knowledge：要求工学知識体系）を基準に、下図のとおり整理しました。
ここでは、機能適合性を機能要件と位置づけ、それ以外をすべて非機能要件として扱います。
非機能要件の重要性
機能要件だけを満たした状態とは、プログラムが一応動いているに過ぎません（下図）。
非機能要件が欠落すると、システムはたとえば次のような深刻な問題を招きます。
- 性能効率：画面表示や処理が遅く、ユーザー体験や業務効率を損なう
- ユーザビリティ：操作性が低く、入力ミスや業務の停滞を引き起こす
- セキュリティ：不正アクセスやデータ漏えいにより、法的責任を負い、社会的信用が失墜する
- 保守性：ソースコードが読みにくく、障害対応や機能追加に過大なコストがかかる
- データ品質：不整合や欠損により、意思決定やサービス品質に重大な影響を及ぼす
- 法令遵守：法規制に違反し、行政指導や罰則を受ける
- 制約：クラウドのシステム利用料が予算を超過する
このような状態では、安定したシステム運用や持続的なビジネス価値の創出は極めて難しくなります。
システムは、単に機能が動作するだけでは不十分です。非機能要件を満たしてこそ、プロフェッショナルが構築したと認められる品質水準に達します。
非機能要件のアーキテクチャへの反映
非機能要件はシステム全体に共通する特性としてまとめられるのが一般的です。
その内容は、システムアーキテクチャやソフトウェアアーキテクチャに、多くが反映されます。
非機能要件のシステムアーキテクチャへの反映
システムアーキテクチャとは、ハードウェアやソフトウェアの主要コンポーネント、それらの相互関係、通信方式や配置などを含め、システム全体の構造と設計方針を定義したものです。
システムアーキテクチャに反映される非機能要件とその具体例を、以下にまとめました。
利用品質
| 非機能要件 | 反映されるアーキテクチャ上の要素 | 具体的な反映例 |
|---|---|---|
| 有効性*3 | サブシステム分割 | 業務単位／フローに即してサブシステムを分割、配置し、現場の業務変更や手順の見直しにシステムを追随しやすくする。 |
| 効率性*4 | ユーザーやAPIクライアントの操作／処理が最小の時間で達成できるような技術／基盤選択 | SPA*5の採用。フロント側キャッシュ。メッセージキューで非同期処理。 |
| 満足性*6 | UX改善のための分析基盤 | ユーザー行動ログ分析基盤を用意する。 |
| リスク緩和*7 | 監視・障害検知、自動復旧機構 | 障害検知アラート連携、自動フェイルオーバー |
| コンテキストカバレージ*8 | 複数環境対応設計、マルチリージョン構成 | 海外リージョン冗長化、各国規格対応の環境構築 |
プロダクト品質
| 非機能要件 | 反映されるアーキテクチャ上の要素 | 具体的な反映例 |
|---|---|---|
| 性能効率*9 | 限られたリソースで高い処理性能を発揮するためのサーバーや機器の構成 | - CDN*10によるコンテンツ配信高速化 - Webサーバ群をオートスケール対応 - DBリードレプリカで並列読み取りを実現 |
| 信頼性*11 | 冗長構成、クラスタリング | マルチAZ*12での冗長化 |
| フェイルオーバー | 障害時の自動切替 | |
| セキュリティ*13 | ネットワーク分離 | DMZ構成 |
| 認証・認可機構 | APIゲートウェイ／認可サーバ（OAuth2, OpenID Connect*14など） | |
| 通信の暗号化 | TLS通信 | |
| 保守性*15 | 監視基盤 | 専用監視サーバ配置 |
| ログ収集構成 | 集中ログ収集 | |
| コンテナ化 | Docker/Kubernetes による環境標準化 | |
| CI/CDパイプライン整備 | GitHub Actionsによる自動ビルド・テスト・デプロイ | |
| 移植性*16 | コンテナオーケストレーション | Kubernetes活用による他クラウド移行 |
| 互換性*17 | 標準プロトコル対応 | REST/GraphQLによる外部連携 |
| ユーザビリティ*18 | UI層設計 | SPA/MPA構成 |
| マルチデバイス対応 | PC・タブレット・スマートフォンそれぞれに最適化されたレスポンシブWebデザインのフレームワークの採用 |
データ品質、法令遵守、制約
| 非機能要件 | 反映されるアーキテクチャ上の要素 | 具体的な反映例 |
|---|---|---|
| データ品質*19 | データ検証・整合性制御 | トランザクション整合性を保証するリレーショナルデータベース（RDBMS）の採用 |
| 法令遵守*20 | データ配置制御 | 個人情報を国内データセンターに限定 |
| 制約*21 | ネットワーク帯域、予算枠 | 使用可能リソース上限を前提とした構成設計 |
非機能要件のソフトウェアアーキテクチャへの反映
ソフトウェアアーキテクチャは、ソフトウェアシステムの全体構造と主要な設計上の決定を体系的に示したものです。
システムアーキテクチャがハードウェア・ネットワークを含むシステム全体の構成を指すのに対し、ソフトウェアアーキテクチャはソフトウェア部分の構造や相互作用を対象にします。
以下では、ソフトウェアアーキテクチャへの非機能要件の反映ポイントと設計上の具体例を整理しました。
利用品質
| 非機能要件 | 反映されるアーキテクチャ上の要素 | 具体的な反映例 |
|---|---|---|
| 有効性 | ドメインモデル設計 | DDDでユースケースを分離、業務ルールをドメイン層に集約 |
| 効率性 | 非同期処理 | バルクI/O・ストリーミング処理 |
| アプリ内キャッシュ | コネクションプール | |
| 満足性 | テレメトリ計測 | ユーザ行動ログの埋め込み |
| リスク緩和 | エラーハンドリングと再試行戦略 | タイムアウト・リトライの設計 |
| コンテキストカバレージ | i18n*22/l10n*23 | - 翻訳リソースを外部化して動的に切り替え（例：gettext、i18next） - タイムゾーン対応のためサーバ側でUTC管理＋クライアント側でローカル変換 |
| オフライン対応 | オフラインファースト*24の設計。 |
プロダクト品質
| 非機能要件 | 反映されるアーキテクチャ上の要素 | 具体的な反映例 |
|---|---|---|
| 性能効率 | 計算量削減 | N+1抑止、バルク処理・ストリーミング処理 |
| 信頼性 | 冗長化・イベント駆動アーキテクチャ | キューイング／メッセージブローカー（Kafka, RabbitMQなど）の使用。 |
| セキュリティ | フレームワーク提供の認証・認可機構 | Webフレームワーク標準の OAuth2/OIDC サポートを利用してトークン認可を実装／フレームワーク内蔵の RBAC*25・ABAC*26 設定でアクセス制御を集中管理 |
| データ保護機能、入力検証・サニタイズ機能 | テンプレートエンジンの自動エスケープや ORM のプレースホルダ機能を活用して XSS や SQL インジェクションを防止／暗号鍵は専用ストア（Hardware Security Module*27・Key Management Service*28 など）で安全に管理 | |
| 保守性 | レイヤリング／依存関係制御 | クリーンアーキテクチャ／依存性の注入（DI*29） |
| 移植性 | 設定分離 | 環境差分（開発・テスト・本番など）は設定で吸収 |
| 互換性 | バージョニング | APIバージョニング（URL/ヘッダ）／後方互換のためのAPIスキーマ進化（例：nullable追加→必須化は段階移行） |
| ユーザビリティ | UI層アーキテクチャ | MVVM*30やRedux*31による一貫した状態遷移／デザインシステム（コンポーネント化） |
データ品質、法令遵守、制約
| 非機能要件 | 反映されるアーキテクチャ上の要素 | 具体的な反映例 |
|---|---|---|
| データ品質 | データ検証・整合性制御 | 外部キーやCHECK制約によるスキーマ整合性保証 |
| 法令遵守 | データ保持ポリシー、監査ログ基盤 | 個人情報保護法やGDPR対応のためのデータ削除／監査証跡をイベントストリームで永続化 |
| 制約 | リソース上限を考慮した構成 | ハードウェア性能制限を前提としたキューイングとバッチ処理設計 |
非機能要件のトレードオフ
非機能要件が重要だとはいっても、すべての要素の質を高めると、オーバースペックになることもあります。
IPAの非機能要求グレードでは、対象システムの社会への影響度に基づいて分類し、その分類に応じて求める要件レベルを定めることを推奨しています。
| 分類 | 説明 |
|---|---|
| 社会的影響がほとんど無いシステム | 障害や停止が発生しても、社会全体や公共の活動にほとんど影響を及ぼさないシステム。社内業務の補助ツールや一部の小規模な情報提供サイトなど、限られた利用者や内部利用にとどまるサービスが該当する。 |
| 社会的影響が限定されるシステム | 障害が起きると一定範囲の利用者や関連業務に支障が出るが、社会全体には大きな混乱をもたらさないシステム。例えば企業の基幹業務システムや地域限定の行政サービス、商用ECサイトなど、特定組織やコミュニティに影響が限定されるもの。 |
| 社会的影響が極めて大きいシステム | 障害や停止が発生すると、公共の安全や社会的基盤に深刻な影響を与えるシステム。金融決済、交通管制、電力・水道などの社会インフラ、全国規模の行政・防災システムなど、広範な国民生活や経済活動に重大な支障を及ぼすもの。 |
まとめ
非機能要件は、システムが長く価値を生み続けるための土台です。
性能・可用性・セキュリティ・保守性などの品質特性は、後から付け足すことが難しく、最初のアーキテクチャ設計に織り込むことが不可欠です。
その際、システム全体の構成を決めるシステムアーキテクチャと、内部の構造を設計するソフトウェアアーキテクチャの双方で、非機能要件を具体的に反映させる必要があります。
さらに、IPAが示す「非機能要求グレード」のように、社会的影響度に応じて求める品質レベルを調整する視点も欠かせません。
機能が動くだけのシステムでは、利用者からの信頼もビジネス価値も長続きしません。
非機能要件を早期に定義し、設計・開発プロセス全体で継続的に見直すことこそが、持続可能で信頼されるシステムを実現する第一歩です。
次回は、要件定義を学ぶ人におすすめの書籍を紹介します。
*1:独立行政法人 情報処理推進機構。https://www.ipa.go.jp/
*2:一般社団法人 日本情報システムユーザー協会。https://juas.or.jp/
*3:ユーザーが目的のタスクを正確かつ完全に達成できる度合い
*4:ユーザーがタスクを最小限の時間・労力で達成できる度合い
*5:Single Page Applicatioin
*6:利用によって安心感・快適さ・好ましい体験を得られる度合い
*7:システム利用が健康・財務・個人情報などのリスクを最小化している度合い。
*8:想定される利用環境・条件下で期待どおりの成果を維持できる範囲
*9:リソースを適切に使い、高い処理性能を維持できるか
*10:Content Delivery Network（コンテンツ配信ネットワーク）の略称。Webサイトで利用される画像や動画などの大容量データを、ユーザーの利用する場所の最も近い場所に配置されたサーバーから配信することで、高速化と安定化を図るネットワークシステム
*11:障害時にも安定して稼働し続けるか
*12:アベイラビリティーゾーン（Availability Zone)。複数の「データセンター（DC）」から構成されるインフラ設備の単位です。同じAZ内のデータセンター群は冗長的で高速なネットワークで結ばれており、あたかも同じ場所にある設備であるかのように利用することができる。
*13:不正アクセスやデータ漏えいを防止できるか
*14:インターネット上でユーザーのID情報を安全に交換するための認証プロトコル。OAuth 2.0 を基盤として、シングルサインオン（SSO）を実現し、ユーザーが複数のサービスに1つのIDでログインできるようにする。
*15:修正・拡張・テストが容易か
*16:異なる環境へ容易に移行できるか
*17:他のシステムや製品と共存・連携できるか
*18:製品が理解しやすく、学びやすく、操作しやすいか
*19:システムが扱うデータの正確性・一貫性・完全性・最新性などを保証するための要件
*20:システムが関連法規・規制・業界基準を順守して運用されることを保証する要件
*21:システム設計・開発・運用において外部条件や前提として課せられる制限事項を明示した要件
*22:「Internationalization（国際化）」の略称。アプリケーションやシステムを特定の言語や文化に依存しない汎用的なものに設計・開発すること
*23:Localization（ローカリゼーション）の略称。ローカリゼーションは、特定の製品やサービスを、特有の地域や文化に合わせて調整または適応させる一連のプロセス
*24:ネットワークが不安定または切断された状態でもアプリが問題なく使え、オンラインに復帰した際にデータを自動的に同期することを前提に設計するアーキテクチャ思想。
*25:ロールベースアクセス制御（Role Based Access Control）。ユーザーの役割（ロール）に基づいてシステムやデータへのアクセスを管理するセキュリティ手法
*26:属性ベースのアクセス制御（Attribute Based Access Control）。ロールではなく属性（特性）を評価してアクセスを決定する認可モデル
*27:専用のハードウェア機器。鍵を物理的に保護し、機器外に秘密鍵を出さずに暗号化・署名を実行。高い改ざん耐性を持つ。Thales Luna HSM、AWS CloudHSMなど
*28:クラウドベースの鍵管理サービス。API経由で鍵を生成・保管・ローテーション。HSMをバックエンドに持つことが多い。AWS KMS、Azure Key Vault、Google Cloud KMSなど
*29:Dependency Injectionの略称。クラスが他のクラスを直接生成するのではなく、外部から渡してもらうようにするデザインパターン。
*30:Model–View–ViewModelの略称。ユーザーインターフェースを持つアプリケーションの設計パターンの一つで、表示（View）とデータ・ロジック（Model）を疎結合に保ちながら、状態管理をシンプルにすることを目的としている。
*31:Webフロントエンドを中心に使われる 状態管理（State Management）ライブラリ／アーキテクチャパターン 。特に React と組み合わせて利用されることが多く、アプリ全体の状態を一元的に管理し、状態変化を予測可能にする。
