非機能要求とは？検討に役立つガイドラインとあわせて分かりやすく解説！
システム導入の計画が決まり、非機能要求仕様を策定することになった際、非機能要求としてどのような内容を検討すれば良いのでしょうか。また、いくつかあるガイドラインの内、どのガイドラインを参照すれば良いのでしょうか。
機能要求は「システムの機能」と言う表現にするとイメージしやすいのですが、非機能要求は、「システムの非機能」という表現には矛盾を含んでいるような感覚があります。また、実業務にどれだけ影響するものかも、わかりにくいように思います。
この記事では、非機能要求とは何かを解説し、システムの発注者が非機能要求仕様を策定する際に参考になるガイドラインの特徴や活用方法について解説します。
目次
1. 非機能要求とは
システムを開発するために必要不可欠な「要求定義」と「要件定義」ですが、前者は、発注者が実現したい希望を発注先の候補となるシステム開発会社に伝えるためのものであり、後者は、発注が確定したシステム開発会社と発注者が協力して作成し、システムの仕様やプロジェクトの進め方を決めるものです。
用語として言葉の響きも意味合いも似ているため、混同することがありますが、この記事では要求定義の中の非機能要求仕様の策定に焦点を当てています。
要求定義で検討する事項は、要件定義で検討する項目と対応していますので、非機能要件として定義される項目を例にして整理します。
機能要件は、システムが実現する処理機能や、画面、帳票、データ、外部インタフェースに関する機能を指します(詳しくは、用語集「機能要件」をご参照ください)。それに対して非機能要件は、システム要件のうち機能要件以外のもの（情報システムの非機能要件）とプロジェクトの進め方に関する要件（プロジェクト要件）があります。
デジタル庁の「デジタル・ガバメント推進標準ガイドライン」では非機能要件として17項目挙げており、弊社ではこれらの内、「アクセシビリティ」「継続性」「上位互換性」などを含めた11項目を情報システムの非機能要件として、「テスト」「移行」「教育」等の6項目をプロジェクト要件として分類しています。
この説明からお分かりいただけるように、非機能要件は、範囲が広く、定義が抽象的になりがちですし、見落とされることも多いものです。また、システム基盤に関する要件は、専門的な知識が必要になるため、親しみにくいイメージがありますが、システム運用を正常に行うためには、しっかり定義して、システム開発に臨むことが必要です。
以上が、非機能要件の概略説明になりますが、非機能要求も同様の項目に対して定義されます。
では、具体的に非機能要求仕様を策定するためにはどうすればいいのでしょうか。また、何を参考にすれば良いのでしょうか。次の章では、参考となるガイドラインをいくつかご紹介します。
2. 非機能要求仕様を策定する際に役立つガイドライン
非機能要求仕様を策定する際に参考になるガイドラインはさまざまな組織から提示されています。本記事で紹介する３つのガイドラインは、その代表例と呼んでもいいものです。
2-1. 非機能要求グレード
非機能要求グレードは、情報処理推進機構(IPA)が2018年に最新版を出したガイドラインです。
IPAは経済産業省が管轄する独立行政法人で「デジタル基盤の提供」「デジタル⼈材の育成」「サイバーセキュリティの確保」を柱として事業を運営しています。日本における情報システム関連組織の中軸とも言えるでしょう。
非機能要求グレードは、利用ガイド、システム基盤の非機能要求に関するグレード表、システム基盤の非機能要求に関する項目一覧、システム基盤の非機能要求に関する樹系図の４点から構成されています。
特徴としては以下が挙げられます。
- ガイドラインを「グレード」と名付けているのは、システム間の差を、そのシステムが社会へ与える影響をもとにして、「グレード」として示しているためです。グレードに応じて非機能要求項目のレベルを設定することで、非機能要求の検討を行いやすくしています。
- システム基盤で実現される要求を主な対象範囲とし、内容を「可用性」、「性能・拡張性」、「運用・保守性」、「移行性」、「セキュリティ」、「システム環境・エコロジー」の6つの大項目に分類し、その上で詳細な項目に細分化しています。
- 詳細な項目ごとに、定量的に表現できる指標で表すことを重視している点が参考になります。
利用方法案
非機能要求レベルを要求項目ごとに決めるガイドが存在するという点が特徴です。非機能要求として定義すべき事項をすべて網羅しているわけではないので、他のガイドラインで網羅性を担保しつつ、本ガイドラインでカバーしている範囲は本ガイドラインで検討するのが良いでしょう。ただ、グレードの定義が「社会的影響」を基準としているため、業種・業態・対象システムが対応する業務によっては、自社の価値観をベースにした基準の考え方にカスタマイズする必要があります。
非機能要求グレードを用いた、非機能要求の効率的な検討と管理のプロセスについては、こちらの記事に記載しています。
2-2. デジタル・ガバメント推進標準ガイドライン
デジタル・ガバメント推進標準ガイドラインは、政府デジタル庁が策定した「デジタル社会推進標準ガイドライン群」の構成の一部として2023年に最新版が作成されたもので、その中の第３編第５章で非機能要件の考え方が述べられています。
また、これは、デジタル庁が各省庁のデジタル化を進めるためのガイドラインとして作成されたものなので、「中立性」や「引継ぎ」のような民間企業ではあまり検討されない非機能要件が含まれますが、網羅性が高いので民間企業にとっても有用な参考資料になります。
特徴は以下の通りです。
- 非機能要件を17項目に分類しています（弊社の用語集ではこの分類を参考にしています）
- デジタル・ガバメント推進標準ガイドラインの非機能要件定義書テンプレート例は、非機能要求を検討する上でもとても参考になります。
- このガイドラインを応用した例として、経済産業省の2022 年度産業保安システム更改に係る要件定義書があります。こちらは、非機能要件を具体的に定義した内容が記されていて、良い参考情報になります。
利用方法案
情報システムの非機能要件だけでなくプロジェクトの進め方に関する要件についても網羅的に記載されており、非機能要求を抜け漏れなく検討する上で有用です。資料の形式をドキュメントにする場合には、このガイドラインが提供するドキュメント形式のテンプレートが役に立つでしょう。
2-3. 非機能要求仕様定義ガイドライン
非機能要求仕様定義ガイドラインは、一般社団法人である日本情報システム・ユーザー協会（JUAS）が2008年に発行したガイドラインです。
特徴は以下の通りです。
- 非機能要求の項目として、機能性、信頼性、使用性、効率性、保守性、移植性、障害抑制性、効果性、運用性、技術要件の10項目を大分類としています。
- ユーザー、つまり、発注者の視点に立ち、大分類を230項目に詳細化し、それぞれの「確認すべき項目」「確認すべきプロセス」「検証方法」「必要なドキュメント」について解説し、非機能要求仕様の策定方法、受入検証の仕方、評価方法などを定義しています。
- このガイドラインの作成は2008年ですので、クラウド・サービスの隆盛やセキュリティインシデントの多様化等、情報システムの激しい変化に伴う現在のシステムの考え方やシステム開発のアプローチに追いついていません。
利用方法案
非機能要件の到達レベルを定量的に計測し、評価するというコンセプトを取り入れることはとても重要ですので、その点では参考になるガイドラインです。他の2つのガイドラインとは違い、ソフトウェアを中心に焦点を当てているため、ソフトウェアを開発する際に役立つでしょう。また、計測方法がシステム導入後に行う定義になっているものが多いため、システム構築後の評価のために利用しても良いでしょう。
この章では非機能要求仕様を策定するために参考となる３つのガイドラインをご紹介しました。
ただ、残念ながら、一般の企業がどれかひとつのガイドラインを選んで、そのまま利用できるというものはありません。それぞれのガイドラインには長所も短所もありますし、自社のシステム導入にうまくあてはまるかどうかは、システムの種類や業種によって変わってきます。
複数のガイドラインを併用する場合は、使っているよう用語にやや違いがあるので、漏れや重複に注意しましょう。
次章では、非機能要求を具体的に考える上でのいくつかのポイントを紹介します。
非機能要求仕様を策定する際に留意するポイント
非機能要求を検討する際、前章に示したガイドラインを参照することはとても有意義です。この章では、それ以外の留意点について説明いたします。
システム部門、利用部門の関与度
非機能要求仕様の策定は発注側企業のシステム部門と業務部門が協力して行うものです。
ただ、情報システムの非機能はセキュリティやバックアップ等、情報システムの基盤部分に関係し、業務部門が気付きにくい点も多くあります。そのため、システム部門に検討を任せようと考えるかもしれません。しかし、実際の業務でどの程度のセキュリティや稼働率が求められるかは業務部門にしか分かりません。
必要十分なシステムを検討するために、業務部門の方は非機能要求仕様の策定にも積極的に参加しましょう。
優先順位付け
すべての非機能要求を実現することが出来るとは限りません。どの非機能要求を実現させるかを検討するうえで、優先順位付けはとても重要です。
システムの機能と投入するコストはトレードオフの関係にあるので、優先すべきポイントに効率的に投資すべきです。業務に対する影響度やシステムに対する影響度やステークホルダーへの影響度を考えて、優先順位を検討しましょう。
既存の業務システムと共通で利用するシステム基盤への要求であるため実現が困難な場合もあります。一旦、すべての非機能要求を並べて、優先順位を決めましょう。
非機能に影響のあるトレンド
情報システムの進歩・変化は著しく、それに影響される非機能も多くあります。
特に現在では、クラウドサービスの利用が盛んになり、発注者がコントロールできない非機能も増えてきました。また、システムにアクセスする方法として、モバイルデバイスの利用も一般的になってきました。そのため、従来では考える必要のなかったデバイスのバージョンアップ対応などの非機能を検討する必要が出てきています。
加えて、セキュリティの脅威も多様になり、顕在化すれば、システムの停止にとどまらず、業務の停止や企業の信用の失墜にまで影響が及びますので、非機能要求としても重視するべきです。
最後に
非機能要求はシステム基盤に関係することが多く、業務部門からは見えにくい部分でもあります。ただ、非機能要求の検討を疎かにすると、いくら機能要求が実現できていても、システム全体の品質が確保されないことになってしまいます。
業務部門と情報システム部門が協力して非機能要求を十分に検討し、システムの品質向上を目指しましょう。
IT調達ナビの運営会社である株式会社グローバル・パートナーズ・テクノロジー（GPTech）は、システム導入における、「システム発注側」の支援に特化したコンサルティングファームです。
システム導入・刷新に向けて、進め方や体制等でお困りの場合は、ぜひ一度弊社までご相談ください。
あわせてこの記事をチェック
この記事の編集者
藤﨑 碩人
大学・大学院では数学を専攻し、IT調達ナビの運営会社である、（株）グローバル・パートナーズ・テクノロジーに新卒で入社した。 公共組織のITガバナンス、マネジメント支援業務に従事し、同社のメディア運営業務にも携わる。応用情報技術者。
