非機能要件とは｜システム開発で見落とせない品質要件の全体像

要件定義を知る中で「非機能要件」という言葉を耳にしたことがある方は多いのではないでしょうか。機能要件と並んで重要な要素とされていますが、「具体的に何を決めればいいのか」「自社のサービスにはどこまで必要なのか」といった疑問をお持ちの担当者の方もいらっしゃるかと思います。

非機能要件は、システムの使い勝手や安定性を左右する重要な要素です。適切に定義されていないと、機能は実装されているのに「処理が遅くて使えない」「頻繁にエラーが出る」といった問題が後から発覚し、大きな手戻りが発生することもあります。

本記事では、非機能要件の基本的な意味から、具体的な分類項目、そして自社に必要なレベルを判断するためのポイントまで、実務に即して解説します。

非機能要件とは

非機能要件の基本的な定義

非機能要件とは、その名の通り「機能以外の全ての要件」を指します。

システムが「何をするか」ではなく「どのように動作するか」を定義するもので、性能、可用性、セキュリティなど、システムの品質や動作特性に関わる要素が該当します。

例えば、ECサイトを開発する場合、「商品を検索する機能」は機能要件ですが、「検索結果を2秒以内に表示する」「1000人が同時にアクセスしても正常に動作する」といった要素が非機能要件となります。

機能要件との違い

機能要件と非機能要件の違いを、もう少し詳しく見ていきましょう。

機能要件は、システムが提供する具体的な機能を指します。会員登録、決済、商品検索といった、ユーザーが実際に操作する機能のことです。

一方、非機能要件は、それらの機能がどのような品質で動作するかを定義します。処理速度、稼働率、セキュリティレベルなど、機能の「質」に関わる要素です。

もう一つ重要な違いは、定義プロセスです。機能要件は顧客へのヒアリングを通じて明確化されることが多いのに対し、非機能要件は開発側が項目を整理・提示し、顧客と協議しながら定義を進めるというアプローチが一般的です。

具体例で比較してみましょう

このように、機能要件が「何ができるか」を示すのに対し、非機能要件は「どれくらいの品質で動作するか」を示すという関係になっています。

なぜ非機能要件が重要なのか

ビジネスへの影響

非機能要件の品質は、ビジネスの成否に直結します。

ユーザー満足度への影響

処理が遅い、頻繁にエラーが出る、といった問題は、ユーザーの離脱につながります。現代のデジタル社会において、システムの使い勝手や信頼性はユーザー満足度を大きく左右する要素となっています。

契約・信頼性の観点

近年、SLA（サービスレベル合意）の概念が一般化する中で、システムの品質は契約上の重要な要素となっています。月間稼働率や最大応答時間といった基準を達成できない場合、ペナルティの対象となるだけでなく、事業の信頼性や収益に直接的な影響を及ぼす可能性があります。

非機能要件の重要性が高まっている背景

近年、非機能要件の重要性は一層高まっています。その背景には、いくつかの要因があります。

デジタル化の進展によるユーザーの期待値上昇

スマートフォンやクラウドサービスの普及により、ユーザーは快適で安定したシステムを当たり前のものとして期待するようになりました。処理の遅延や頻繁なエラーは、すぐに他サービスへの離脱を招く要因となっています。

SLAの一般化

サービス品質が契約事項として明文化されることが一般的になり、システムの品質基準が事業上の重要事項として位置づけられるようになりました。

システムの複雑化

技術の進化に伴い、システム構成は複雑さを増しています。マイクロサービスやクラウドネイティブ（クラウド環境での運用や管理に最適化されたシステムアーキテクチャ）といったアーキテクチャの採用が進む中で、安定性やセキュリティの確保が一層難しくなっており、品質要件の事前明確化と計画的な対応が必要不可欠となっています。

法規制への対応

個人情報保護法など、新たな法規制への対応が求められるようになっています。セキュリティやデータ保護に関する非機能要件は、法令順守の観点からも重要性を増しています。

非機能要件の6大項目

IPA（情報処理推進機構）の「非機能要求グレード」では、非機能要件を以下の6つの大項目に分類しています。この分類を理解しておくことで、定義すべき項目を漏れなく検討することができます。

1. 可用性

可用性は、システムを継続的に利用可能にするための要件です。

具体的には、以下のような項目を定義します。

1. ・システムの稼働時間（24時間365日稼働、または営業時間のみなど）
2. ・計画停止の扱い（メンテナンス時間の設定）
3. ・障害発生時の復旧方法と目標復旧時間
4. ・目標稼働率（後述する「ナイン」の基準）

システムが止まると業務や顧客にどの程度の影響が出るかを考慮し、適切なレベルを設定することが重要です。

2. 性能・拡張性

性能・拡張性は、システムの処理能力と将来の拡張に関する要件です。

具体的には、以下のような項目を定義します。

1. ・トランザクション数（1日あたりの処理件数など）
2. ・同時アクセス数（ピーク時に何人が同時利用するか）
3. ・レスポンスタイム（処理の応答時間）
4. ・将来のユーザー数やデータ量の増加への対応

特にWebサービスやアプリでは、ユーザー数の増加に応じてスケールできる設計が求められます。

3. 運用・保守性

運用・保守性は、システムのリリース後の運用・保守に関する要件です。

具体的には、以下のような項目を定義します。

1. ・バックアップ計画（取得頻度、保存期間、復旧手順）
2. ・運用監視体制（監視項目、監視間隔、アラート通知）
3. ・保守作業の自動化範囲
4. ・サポート体制（障害対応の連絡先、対応時間）
5. ・内部統制対応

限られた人員で運用する社内システムと、24時間監視が必要な一般公開サービスでは、求められるレベルが大きく異なります。

4. 移行性

移行性は、既存システムから新システムへの切り替えに関する要件です。

具体的には、以下のような項目を定義します。

1. ・移行スケジュール（移行期間、システム停止可能日時）
2. ・移行データの量や形式
3. ・並行稼働の有無（新旧システムを一定期間並行して運用するか）
4. ・移行リハーサルの実施

既存システムからのリプレイスの場合、移行期間中の業務への影響を最小限に抑える計画が重要です。

5. セキュリティ

セキュリティは、情報の安全性を確保するための要件です。

具体的には、以下のような項目を定義します。

1. ・アクセス制限（認証方式、権限管理）
2. ・データの暗号化（伝送時・保存時）
3. ・不正検知・監視
4. ・マルウェア対策
5. ・セキュリティガイドラインや社内規定への準拠

個人情報や決済情報を扱うシステムでは、特に厳格なセキュリティ要件が求められます。

6. システム環境・エコロジー

システム環境・エコロジーは、システムの設置環境に関する要件です。

具体的には、以下のような項目を定義します。

1. ・構築・運用時の制約条件（設置場所、温度・湿度条件など）
2. ・適合規格の取得有無
3. ・環境負荷低減の構成

オンプレミス環境（企業が保有するサーバーやコンピュータをデータセンターや社内に設置して運用する環境）を構築する場合は特に重要な項目となります。

その他の重要項目

上記の6大項目に加えて、以下の項目も考慮しておくと良いでしょう。

ユーザビリティ

システムの使いやすさに関する要件です。操作のしやすさ、画面の見やすさ、学習のしやすさといった要素が含まれます。

アクセシビリティ

多様なユーザー（高齢者、障がい者など）がシステムを利用できるようにするための要件です。近年、Webアクセシビリティへの対応が重視されるようになっています。

自社に必要なレベルをどう判断するか

非機能要件の項目を理解したところで、次に重要なのは「自社のサービスにはどのレベルが必要か」という判断です。

システムの重要度による階層化

すべてのシステム・機能に同じレベルの非機能要件を設定する必要はありません。重要度に応じて階層化し、コストとのバランスを取ることが重要です。

Tier 1（最重要）

対象：決済処理、認証システム、顧客データベースなど、ビジネスの根幹を支える機能

方針：コストよりもパフォーマンスや可用性を優先した設計を行います。高い稼働率、短いレスポンスタイム、厳格なセキュリティ対策が求められます。

Tier 2（中程度）

対象：商品検索、マイページ、レポート機能など、重要ではあるものの一時的な停止が許容できる機能

方針：バランス型の設計を行います。コストと品質のバランスを考慮し、合理的なレベルを設定します。

Tier 3（優先度低）

対象：社内管理画面、参照系システム、ログ閲覧機能など、停止しても業務への影響が限定的な機能

方針：低コストを重視した設計を行います。必要最低限の品質を確保しつつ、コストを抑えます。

このように階層を定義することで、限られた予算の中で効果的にリソースを配分することができます。

稼働率（可用性）の目安

稼働率は「ナイン」という指標で表現されることが一般的です。システムの重要度に応じて、以下のような目安があります。

稼働率が高くなるほど、冗長構成やバックアップ体制の強化が必要となり、コストも増大します。

判断のポイント

「何分・何時間止まると業務や顧客に影響が出るか」を明確にすることが、適切な稼働率を設定する鍵となります。

例えば、社内の勤怠管理システムであれば、深夜にメンテナンスのため数時間停止しても大きな影響はないかもしれません。一方、ECサイトや決済システムでは、数分の停止でも売上損失や顧客の信頼低下につながる可能性があります。

レスポンスタイムの目安

レスポンスタイムもユーザー体験を左右する重要な要素です。

一般的なWebサービスの基準

1. ・数十ms以下：早い
2. ・100ms～500ms：ちょっと遅い
3. ・500ms～1s：もっさり
4. ・1s以上：改善が必要

ただし、モバイルアプリなど非同期処理を活用するサービスでは、ローディング表示などの工夫により、多少レスポンスが遅くてもユーザー体験を維持することは可能です。

業界・サービス別の目標値

サービスの種類によって、求められるレスポンスタイムは異なります。

1. ・ECサイト：ページ読み込み2秒以内（決済ページは1秒以内）
2. ・メディアサイト：ページ読み込み3秒以内（初回訪問のファーストビューは2秒以内）
3. ・SaaSアプリケーション：全体は4秒以内（主要機能・ダッシュボードは1秒以内）
4. ・モバイルアプリ：タップ反応200ミリ秒以内、データ読み込み2秒以内

これらの数値は一つの目安ですが、ユーザーの期待値やビジネスへの影響を考慮して設定することが重要です。

非機能要件を定義する際のポイント

ここまで非機能要件の内容とレベル感について解説してきました。最後に、実際に定義を進める際の実務的なポイントをまとめます。

1. 初期段階から検討する

非機能要件は、プロジェクトの企画・要件定義の段階から検討することが重要です。

後から追加すると、設計の大幅な変更が必要となり、プロジェクトの遅延やコスト増大を招くリスクがあります。機能要件と並行して、非機能要件も初期段階から整理していくことをお勧めします。

2. 定量的な目標を設定する

非機能要件を定義する際は、できる限り具体的な数値で目標を設定することが重要です。

❌ 曖昧な表現

1. ・「処理が速いこと」
2. ・「安定したシステム」
3. ・「使いやすいシステム」

⭕ 具体的な表現

1. ・「商品検索結果を2秒以内に表示すること」
2. ・「同時に1000ユーザーがアクセスしても正常に動作すること」
3. ・「年間稼働率99.9%以上を維持すること」
4. ・「1日1回のフルバックアップを実施すること」

定量的な目標を設定することで、開発チームが何を目指すべきか明確になり、完成後の検証も客観的に行うことができます。

3. “理想”ではなく”必要十分”で決める

非機能要件は、理想を追いすぎないことが重要です。

すべての項目を高グレードに設定すると、コストと運用負荷が大幅に増大します。重要な項目から優先して決める姿勢が求められます。

例えば、決済や認証といった業務の中核となる機能は高グレードに設定し、社内向けの参照系システムは必要最低限に抑える、といった判断が合理的です。

限られたリソースの中で、ビジネスへの影響度を考慮しながら優先順位をつけることが大切です。

4. 運用まで含めて実現可能性を確認する

非機能要件を定義する際は、実際に運用できるかという視点も重要です。

監視、障害対応、バックアップからの復旧といった運用業務を誰が担うのか、実際にその体制で回せるのかを確認する必要があります。

高い稼働率を目標に掲げても、24時間対応できる体制がなければ絵に描いた餅となってしまいます。自社の運用体制を見据えた上で、実現可能なレベルを設定しましょう。

5. トレードオフを見極める

非機能要件を検討する際には、要求間でさまざまなトレードオフが発生します。

1. ・セキュリティ強化 ⇔ ユーザー利便性：多要素認証を導入すればセキュリティは向上しますが、ユーザーの手間が増えます
2. ・可用性向上 ⇔ コスト増大：冗長構成を組めば稼働率は上がりますが、インフラコストが増加します
3. ・性能向上 ⇔ 開発期間・コスト：高速化のための最適化には時間とコストがかかります

こうしたトレードオフを理解した上で、自社のリスク許容度と予算の折り合いをつけることが重要です。単に支出を抑えるのではなく、「価値を最大化すること」を念頭に置いて判断しましょう。

6. 開発会社と協働で定義する

非機能要件は、発注側だけで定義するのは困難です。

どの機能をどう実装するか、技術的実現性の判断には専門知識が必要です。また、「ちょうどいい粒度」で要件を記述するには、システム開発の経験が影響します。

そのため、開発会社に素案を作成してもらい、それをベースに協議を進めるのが効率的です。開発会社は過去の類似プロジェクトでの知見を活かし、見落としがちな要件の指摘や効果的な実装方法の提案を行えます。

また、IPA（情報処理推進機構）の「非機能要求グレード」やJUAS（日本情報システム・ユーザー協会）の「非機能要求仕様定義ガイドライン」といった公的なガイドラインを参照・活用することで、定義漏れを防ぐことができます。

まとめ

非機能要件は、システムの使い勝手や安定性を左右する重要な要素です。機能要件だけに注目しがちですが、非機能要件を適切に定義することで、ユーザー満足度の向上や運用コストの削減につながります。

押さえておきたいポイント

1. ・非機能要件は「機能以外の品質要素」を指し、システムの「どのように動作するか」を定義する
2. ・IPAの6大項目（可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境）で整理すると漏れを防げる
3. ・システムの重要度に応じて階層化し、コストとのバランスを取ることが重要
4. ・稼働率やレスポンスタイムは、業界標準を参考にしつつ自社の状況に合わせて設定する
5. ・定量的な目標設定と、初期段階からの検討が重要
6. ・開発会社と協働で定義を進め、ガイドラインを活用する

自社のサービスに必要なレベルを見極め、適切な非機能要件を定義することが、システム開発成功への第一歩となります。「何分・何時間止まると影響が出るか」「どれくらいの速度が必要か」といった具体的な基準を、ビジネスの観点から検討してみてはいかがでしょうか。