システム開発は、クライアント（顧客）の要求（実現したいこと）から始まり、それを具体的な要件（システムが備えるべき機能や性能）に落とし込みます。このプロセスでは、目に見えて分かりやすい画面や機能といった「機能要件」に目が向きがちです。
一方で、性能やセキュリティなどの「非機能要件」は完成形を想像しづらく、後回しにされやすい傾向があります。しかし、非機能要件をないがしろにしてしまうと、開発中の大幅な手戻り、リリース後のトラブルなどが発生しかねません。
こうした事態を防ぐために有効となるのが、IPA（情報処理推進機構）が公開している「非機能要求グレード」です。本記事では「非機能要求グレードとは何か」という基礎知識から、その概要や6つのカテゴリ、実務での使い方と活用ポイントまで解説します。
- もくじ
1. IPAの非機能要求グレードとは？
非機能要求グレードとは、システムに求められる「非機能要求」を体系的に整理し、「非機能要件」を抜け漏れなく・現実的なレベルで固めるための指針です。IPA（情報処理推進機構）が公開しており、公式サイトから無償でダウンロードして利用できます。
ここで、「非機能要求」と「非機能要件」という2つのキーワードが出てきました。非機能要求グレードの役割を理解するために、まずはこれらの違いについて整理しましょう。
非機能要求と非機能要件の違い
簡単にいえば「非機能要求をもとに定義するのが非機能要件」という関係性にあります。
システム開発の出発点は、クライアントがシステムで実現したいことを具体化した「要求」です。この要求は、「（システムで）何をしたいか」を言語化した「機能要求」、「どう振る舞ってほしいか」を言語化した「非機能要求」に大別されます。
非機能要求は、たとえば「待たされずに使いたい」「すぐに復旧してほしい」といったものです。これらは主観的な要望であり、そのままでは開発側の設計や実装に必要な情報が足りず、開発を進められません。
そこで、「応答時間は3秒以内とする」「障害停止は3時間以内とする」のように、設計可能な基準へ整理したものが「非機能要件」です。非機能要求はクライアント視点にもとづいた概念ですが、非機能要件は開発者の視点にもとづきます。
このように、非機能要件は非機能要求をもとに整理していくことが基本となります。この作業において、ものさしとして役立つのが「非機能要求グレード」です。
非機能要件の分類手法には「ISO/IEC 25010（システム及びソフトウェア品質モデル）」などの国際規格をはじめ複数の定義が存在しますが、日本のシステム開発現場においては、IPAが策定した非機能要求グレードが広く利用されています。本記事では、この定義に沿って解説していきます。
なお、要件を定義するための分類でありながら「要求」という言葉が使われているのは、発注者の要望（要求）を可視化・段階づけし、開発側と合意可能な形（要件）へと落とし込むためのツールであるためです。
非機能要求グレードの目的
非機能要求グレードを利用する主な目的は、次の3つです。
・受発注間の共通理解の促進
非機能要求は、発注者と受注者が協議しながら整理していきます。この過程では「言ったつもり」「分かったつもり」による認識ズレが生じがちです。非機能要求グレードは、双方が使える枠組みを提供することで共通理解を促進し、こうした認識ズレを防ぎます。
・非機能要件の定義漏れ防止
非機能要求項目を洗い出す際、体系だった整理軸やチェックリストがないと、重要な観点が抜け落ち、最終的な非機能要件の定義にも漏れが生じてしまいます。非機能要求グレードには、代表的な非機能要求項目が網羅的に整理されているため、検討漏れを防ぐためのチェックリストとして有用です。
・要求レベルの具体化
非機能要求項目を列挙できても、「どの程度まで求めるのか」があいまいなままでは、開発後の認識違いやトラブルにつながりかねません。非機能要求グレードでは実現レベルの目安が示されているため、要求レベルを具体化するのにも役立ちます。
このように非機能要求グレードは、非機能要求を整理・具体化し、発注者と受注者の合意を支えるための指針です。
2. 非機能要求グレード6つのカテゴリ
IPAが公開している「非機能要求グレード2018」には、非機能要求として検討すべき項目が整理されています。非常に多くの項目があるため、ここでは大項目として定義されている6つのカテゴリについて、その概要と定義に不備があった際のリスクをご紹介します。
①可用性
②性能・拡張性
③運用・保守性
④移行性
⑤セキュリティ
⑥システム環境・エコロジー
①可用性
「可用性」は、システムサービスを継続的に利用可能とするための要求です。具体的には、次のような項目を含みます。
・運用時間（例：24時間無停止、夜間のみ停止）
・目標復旧時間（例：2時間以内、1営業日以内）
・稼働率（例：99.99％、95％）
可用性が十分に検討されないと、頻繁な停止や長時間のサービス中断が発生し、利用したいときに使えない状況を招きます。業務への影響が大きいシステムほど、慎重に検討すべき項目です。
②性能・拡張性
「性能・拡張性」は、システムの性能と将来のシステム拡張に関する要求です。具体的には、次のような項目を含みます。
・レスポンス順守率（例：99％以上、80％）
・同時アクセス数（例：不特定多数のアクセス有り、特定利用者の限られたアクセスのみ）
・CPU拡張性（例：8倍以上の拡張が可能、1.5倍の拡張が可能）
性能・拡張性が十分に検討されないと、アクセス集中時に画面が固まったり、将来のリソース増強が困難となったりしかねません。快適なシステムの実現はもちろん、システム改修のコスト増大を防ぐためにも重要な項目です。
③運用・保守性
「運用・保守性」は、システムの運用管理やメンテナンスのしやすさに関する要求です。具体的には、次のような項目を含みます。
・監視間隔（例：分間隔のリアルタイム監視、手動による不定期監視）
・データ復旧範囲（例：システム内の全データを復旧、復旧不要）
・マニュアル準備レベル（例：システムの通常運用のマニュアルを提供する）
・バックアップ取得間隔（例：日次で取得、週次で取得）
運用・保守性が十分に検討されないと、日々の運用負荷が高まりコストが肥大化したり、トラブル発生時の原因究明に時間がかかったりします。システムを継続的に稼働させるうえで検討が欠かせない項目です。
④移行性
「移行性」は、現行システムから新システムへ、あるいは将来的な別環境への移行に関する要求です。具体的には、次のような項目を含みます。
・システム移行期間（例：2年未満、3ヶ月未満）
・移行データ量（例：1PB以上、1TB未満）
・リハーサル回数（例：1回、2回）
移行性が十分に検討されないと、作業工数の増大や移行スケジュールの遅延、データ不整合といったリスクにつながります。将来のシステム刷新やクラウド移行なども見据え、早い段階から検討しておくことが重要な項目です。
⑤セキュリティ
「セキュリティ」は、情報システムの安全性を確保するための要求です。具体的には、次のような項目を含みます。
・伝送データの暗号化の有無（例：重要情報を暗号化、認証情報のみ暗号化）
・セキュリティインシデントの対応体制（例：有り、無し）
・ネットワーク診断実施の有無（例：有り、無し）
セキュリティが十分に検討されないと、セキュリティインシデント発生時に双方の認識が食い違ったり、対応責任の所在があいまいになったりするリスクがあります。守るべき資産とコストのバランスを考慮し、必要な対策レベルを明確にしておくことが重要な項目です。
⑥システム環境・エコロジー
「システム環境・エコロジー」は、システムの設置環境や環境負荷への配慮に関する要求です。具体的には、次のような項目を含みます。
・システム利用範囲（例：BtoC、社内のみ）
・環境保護に関する規格取得の有無（例：RoHS指令相当取得）
・耐震震度（例：震度6弱相当）
システム環境・エコロジーが十分に検討されないと、災害時に物理的な損壊が発生したり、関連する法令やガイドラインへの対応が不十分になったりするリスクがあります。企業のコンプライアンスや事業継続の観点からも確認が求められる項目です。
3. 非機能要求グレードの使い方・3ステップ
非機能要求グレードを活用する際は、大まかに次の3ステップで進めていきます。
①モデルシステムの選定
②重要項目のレベル決定
③重要項目以外のレベル決定
①モデルシステムの選定
まずは、非機能要求を整理するための基準となるモデルシステムを選定しましょう。非機能要求グレードでは、システムが停止した際の影響度合い（社会的影響）に応じて、3種類のモデルシステムが定義されています。
・社会的影響がほとんどないシステム（小規模なWebシステムなど）
・社会的影響が限定されるシステム（企業専用の基幹システムなど）
・社会的影響が極めて大きいシステム（不特定多数が利用するインフラシステム）
各モデルシステムには、非機能要求項目ごとの推奨値が定義されているため、非機能要求を検討する際の参考になります。たとえば「社会的影響が限定されるシステム」の場合、稼働率は99.99％（年間停止許容時間1時間未満）、被災時は1週間以内で復旧、というレベルが設定されています。
自社のシステムに最も近いものを選び、それをベースに発注者と受注者で前提条件を共有しながら認識を合わせましょう。
②重要項目のレベル決定
続いて、非機能要求の中でも優先度が高い「重要項目」のレベルを決定します。各非機能要求項目には最大6段階（0～5）のレベルが設定されており、プロジェクトの裁量で最終決定できます。
モデルシステムの推奨値はあくまで参考であり、全てを記載どおりに適用する必要はありません。そのため、各重要項目について推奨値とプロジェクトの実情を照らして検討し、必要に応じてレベルを調整しましょう。
たとえば、モデルシステムどおりだと稼働率が99.99％と設定されている箇所に対し、そこまでのレベルが必要なければ引き下げるなどの調整を行います。どの項目もレベルが上がるほどコストがかかります。クライアントの予算感も把握したうえで、双方が納得できるレベル調整を行いましょう。
③重要項目以外のレベル決定
最後に、重要項目以外の詳細な非機能要求項目に対し、前ステップと同様にレベルを決定していきます。項目数が多いため、図示するなどしてクライアントにイメージを共有しながら進めるとスムーズです。
こうして全項目についてレベル（目標値）を合意することで、発注者の「非機能要求」が、システムが満たすべき具体的な「非機能要件」として確定します。
非機能要件は、システム全体の品質を左右する重要な項目です。事業責任者などクライアントのキーマンの承認を得ながら定義を明確にしていきましょう。
4. 非機能要求グレードを有効活用するポイント
非機能要求グレードをシステムの成功につなげるためのポイントとして、次の2つを押さえておきましょう。
・発注者・受注者の双方が協力する
・コストと品質のバランスを考慮する
発注者・受注者の双方が協力する
非機能要件は、発注者・受注者の双方が協力して固めていきましょう。
非機能要件は技術的な内容を含むため、受注者（開発）任せになりがちです。しかし、ビジネスへの影響やリスクは、発注者でなければ判断できません。
一方的な要求や拒絶の材料にするのではなく、認識のズレを埋めるための共通言語として扱いましょう。受注者はもちろん、発注者も自社のビジネス要件を決めるための作業と認識し、主体的に判断へ参加することが大切です。
コストと品質のバランスを考慮する
コストと品質のバランスを考慮し、現実的なレベルを選びましょう。全項目で高レベルな品質を目指すと、システム構成が複雑になりコストも肥大化してしまいます。非機能要件のハードルを引き上げるあまり、機能要件の検討が不十分になるのでは本末転倒です。
「あれば安心」という過剰品質は避け、業務上の必要性にもとづきメリハリをつけることが大切です。予算内で最大の効果を得るため、優先度に応じたレベル調整を行いましょう。
まとめ
非機能要件の定義は実体が見えず難しいと思われがちですが、非機能要求グレードを活用すれば恐れることはありません。非機能要求グレードによって検討すべき観点やレベルが整理され、非機能要件を体系的かつ現実的に固められます。
非機能要件についてイメージできない発注者や受注者の方も、まずは非機能要求グレードを見て全体像を掴んでみてはいかがでしょうか。
