- 更新日 : 2025年2月5日
非機能要件とは？機能要件との違いや定義すべき6大項目などを解説
非機能要件とは、システムの開発における「機能」以外の要件を指します。
システム開発では、システムが実現すべき事項を「要件」として定義します。要件は「機能要件」と「非機能要件」に分けられますが、機能要件は「システムができること」にフォーカスしている一方で、非機能要件は性能やセキュリティなどにフォーカスしている点が特徴です。どれほど優れた機能を持つシステムであっても、性能に問題がある場合、そのシステムは実際に運用できません。
本記事では、非機能要件の概要をはじめ、定義すべき6大項目や検証方法について解説します。
目次
非機能要件とは
はじめに、非機能要件の概要や重要性について解説します。
非機能要件の概要
システム開発では要件定義工程において、システムが実現すべき事項を「要件」としてまとめます。要件は「機能要件」と「非機能要件」の2つに分けられるのが特徴です。
機能要件とは、その名前のとおりシステムの「機能」に関するものであり、非機能要件とは「機能」以外の要件を指します。具体的には、システムの品質や性能に関する事項が中心です。
機能要件との違い
機能要件は「システムができること」にフォーカスしていますが、非機能要件は性能やセキュリティなどにフォーカスしている点が異なります。
例えば、情報の登録・更新・削除・参照などは機能要件に分類されますが「機能の有無」がはっきりしているため、クライアント側も比較的イメージしやすいでしょう。
一方で「画面表示を1秒未満で行えること」や、「障害発生時に1時間以内で再稼働できること」などは非機能要件に分類されますが、システム発注側としてはややイメージがしづらいものが多いのが特徴です。
非機能要件は、システムの特性や発注者の要望などによって大きく異なります。また、システム発注側で定義することが難しいため、ベンダー側が主体となって決定していくことが求められます。
非機能要件の重要性
どれほど優れた機能を持つシステムであっても性能が著しく悪い場合、そのシステムは実運用に耐えられません。また、セキュリティ面に問題があるシステムも同様です。
ところが、多くのシステム開発において非機能要件は後回しにされがちです。しかし、非機能要件を疎かにした状態で開発を進めると、テスト工程やリリース後に問題が発覚するため、大きな手戻りが発生してしまいます。場合によってはリリースができない事態にも陥りかねません。
一方で、あらかじめ非機能要件をしっかり定義しておけば、システムの品質向上はもちろん、顧客満足度向上も実現可能です。
非機能要件で定義すべき6大項目
非機能要件は、主に6つの項目で構成されます。ここでは非機能要件で定義すべき6大項目について解説します。
可用性
可用性とは、システムを継続的に利用可能とするための要件を指します。
- システムの稼働時間
- 計画停止
- 業務停止時や大規模災害発生時の復旧水準（何を、どこまで、どの程度復旧できるか）
- 稼働率
性能・拡張性
性能・拡張性とは、システムの処理性能や拡張しやすさに関する要件を指します。
- 業務処理量 （ユーザー数、同時アクセス数、データ数、処理件数など）
- ピーク時の増大率
- 性能目標
- リソース拡張性 （CPUやメモリなど）
運用・保守性
運用・保守性とは、システムリリース後の運用や保守に関する要件を指します。
- システム運用時間
- バックアップ計画 （対象範囲、自動化範囲、取得間隔、保存期間）
- 運用監視 （監視情報、監視間隔）
- 保守運用 （計画停止有無、保守作業自動化範囲）
- 運用環境 （開発環境の構築有無、試験用環境の構築有無、マニュアル準備範囲）
- サポート体制 （保守契約、ライフサイクル期間）
- 内部統制対応
- サービスデスク設置有無
移行性
移行性とは、現行システムから新システムへの移行に関する要件を指します。
- 移行スケジュール （移行期間、システム停止可能日時、並行稼働有無）
- 移行方式
- 移行対象 （移行データ量、移行データ形式）
セキュリティ
セキュリティとは、システムのセキュリティに関する要件を指します。
- 順守すべき情報セキュリティに関するガイドラインや社内規定の有無
- セキュリティリスク分析
- セキュリティ診断 （ネットワーク診断実施有無、Web診断実施有無）
- データの秘匿 （伝送データの暗号化有無、蓄積データの暗号化有無）
- 不正監視
- マルウェア対策
システム環境・エコロジー
システム環境・エコロジーとは、システムを設置する環境や環境負荷などに関する要件を指します。
- 構築および運用時の制約条件
- 適合規格の取得有無
非機能要件の定義方法
ここでは非機能要件の定義方法について解説します。
ステップ1.システムの特性や機能を整理・決定する
非機能要件はシステム特性や機能によって大きく異なります。同様の機能を持つシステムであっても「社内でのみ利用されるシステム」と「社会的に広く利用されるシステム」の非機能要件は全く異なるのです。
一般的に非機能要件を高い基準に設定するほどコストがかかるため、まずはシステム特性や機能要件の整理が重要です。
ステップ2.ベンダー側で非機能要件の案を作成する
機能要件と異なり非機能要件はイメージしにくいため、発注側のみでは要件定義がうまく進まないことが多々あります。そのため、開発ベンダー側に素案を作成してもらい、素案をもとに個々の項目を議論したほうがスムーズに定義可能です。
また、非機能要件の検討はIPA（独立行政法人情報処理推進機構）やJUAS（一般社団法人日本情報システム・ユーザー協会）などが公開しているガイドラインなどをベースにすれば抜け漏れを防げるため、非機能要件を網羅的に定義できます。
参考： IPA「非機能要求グレード2018」
JUAS「非機能要求仕様定義ガイドライン」
ステップ3.合意形成を図る
最後に開発ベンダーから提示された案を確認し、問題なければ合意となります。なお、合意した非機能要件は、要件定義書にまとめておくことが重要です。
非機能要件の評価指標
非機能要件は目に見えにくいものが多いですが、これを評価するための指標が存在します。ここでは主な評価指標を紹介します。
RASIS
RASISはシステム全般の評価指標であり、下記項目の頭文字をとった単語です。
| 項目名 | 概要 |
|---|---|
| Reliability：信頼性 | 障害・不具合によるシステム停止・性能劣化の発生しにくさを表す。 |
| Availability：可用性 | 稼働率の高さや障害・保守による停止時間の短さを表す。 |
| Serviceability：保守性 | 障害からの復旧およびメンテナンスのしやすさを表す。 |
| Integrity：保全性 | 過負荷や障害をはじめ、データの壊れにくさを表す。 |
| Security：安全性 | 攻撃者やマルウェアなどに対する耐性を表す。 |
SLA/SLO
SLAは「Service Level Agreement」の略語であり、開発（サービス提供）ベンダーとクライアント間で締結される契約です。SLAでは、可用性やセキュリティなどをはじめ、障害発生時の損害賠償などを定義します。
また、SLOは「Service Level Objective」の略語であり、SLAを履行するためのパフォーマンス目標値をサーバーやネットワークごとに表したものです。
非機能要件のテスト方法
非機能要件を満たしているかを確認するためには、各種のテストを行う必要があります。主なテストの種類は次のとおりです。
| テスト種類 | 概要 |
|---|---|
| 性能テスト | 処理速度や処理量などを確認する。 |
| 負荷テスト | 大量アクセス／大量データなどが発生した場合の性能を確認する。 |
| セキュリティテスト | システムが攻撃や脅威に対する耐性を有しているかを確認する。 |
| ユーザビリティテスト | ユーザーの操作性に問題がないかを確認する。 |
| 保守性テスト | システムの保守性に問題がないかを確認する。 |
まとめ
非機能要件とは、システムの品質や性能をはじめ、セキュリティなど「機能そのもの」以外に該当するものを指します。
機能要件と比較すると非機能要件は後回しにされがちですが、テストやリリース後に問題が発覚すると、大きな手戻りが発生したりユーザー満足度が著しく低下する恐れがあるため、注意が必要です。
非機能要件の対象範囲は広くイメージしづらいものが多いですが、前述のIPAやJUASが公開しているガイドラインなどを活用して漏れなく定義しましょう。
この記事をお読みの方におすすめのガイド4選
最後に、この記事をお読みの方によく活用いただいている人気の資料・ガイドを紹介します。すべて無料ですので、ぜひお気軽にご活用ください。
Fit to Standardを実現するための導入ノウハウ
業務プロセスをシステムに合わせて最適化する手法として「Fit to Standard」が注目を集めていますが、従来のFit & Gap方式に慣れた組織では新たなアプローチへの抵抗感もあるのではないでしょうか。
本書では、Fit to Standardの基本概念からメリット、導入の流れ、課題解決のポイントまでを解説します。
経理業務自動化のためのツール選定ガイド
経理業務は限られた人員リソースのなかでこなしていくため、企業の状況に合わせた適切なシステム・ツールを導入し、業務の効率化・自動化やヒューマンエラーの削減を図っていくことが重要です。
本書では、経理業務のよくある課題を整理しながら、クラウド型ERPとRPAを活用した業務改善に注目して解説していきます。
システム保守切れによる3大リスク回避のポイント
「基幹システムやバックオフィスシステムの保守切れが近いけど、次をどう考えたらいいかわからない」とお悩みの中堅企業の方も多いのではないでしょうか。
本資料では、システム保守切れに伴って起こり得るリスクと、システム保守切れの回避方法について解説します。
マネーフォワード クラウドERP サービス資料
マネーフォワード クラウドERPは段階的に導入できるコンポーネント型クラウドERPです。
会計から人事労務まで、バックオフィス全体をシームレスに連携できるため、面倒な手作業を自動化します。SFA/CRM、販売管理、在庫・購買管理などの他社システムとも連携できるため、現在ご利用のシステムを活かしたままシステム全体の最適化が可能です。
※ 掲載している情報は記事更新時点のものです。
※本サイトは、法律的またはその他のアドバイスの提供を目的としたものではありません。当社は本サイトの記載内容（テンプレートを含む）の正確性、妥当性の確保に努めておりますが、ご利用にあたっては、個別の事情を適宜専門家にご相談いただくなど、ご自身の判断でご利用ください。
関連記事
ERPの導入にかかる費用は？ | 相場やクラウド型とオンプレミス型の費用の違いを解説
ERPの導入を検討する際、どのくらい費用がかかるのか分からず、検討が進まないという企業も多いのではないでしょうか。 導入にあたってどのような費用が発生するのか、ERPの種類によって費用の違いがあるのかを理解することができれば、検討も進むこと…
詳しくみるクラウドの安全性とクラウドサービス選定のポイントを解説
クラウドサービスの普及に伴い、セキュリティの重要性はますます高まっています。クラウド環境にはインターネットを介したアクセスが常に発生し、不正アクセスやデータ漏えい、システム障害などの特有のリスクが伴います。さらに、これらのリスクはサイバー攻…
詳しくみるクラウド型ERPへのリプレイスを成功させるための4つのポイント
既存の基幹システムが古くなり、現在の企業の状態や業務にマッチしなくなってきている企業も増えてきています。古い基幹システムを利用したままでは、さまざまなデメリットが生じ、新しい技術やビジネスに対応できなくなってしまいます。それを解決するには、…
詳しくみるFit&Gap（フィットアンドギャップ）分析のステップや注意点を解説
Fit&Gap（フィットアンドギャップ）とは、ERPなどのシステム導入時において、自社の要件を洗い出すための分析手法です。 Fit&Gap分析を実施することで、自社に適したシステムの選定や導入に際するカスタマイズ要否の判断材…
詳しくみるベンダーロックインとは？リスクと対策方法を解説
ソフトウェアの機能改修やバージョンアップなどを、導入を実施してもらったベンダーに依存してしまっていませんか？ ベンダーロックインとは、コストや工数などのさまざまな要因によって、導入時のベンダーから他社への移行が難しくなる状態をいいます。 ベ…
詳しくみるERPの導入を成功させるためのRFPの作り方 | RFPの概要と作成する目的をわかりやすく解説
ERPを導入するときにも、通常のシステム開発と同じように自社に合わせた製品の選択やカスタマイズが必要になります。そのため、ベンダーとの十分な意思疎通が不可欠です。そこで、ベンダーに自社の要望を理解してもらうためのポイントとなるのがRFPです…
詳しくみる