非機能要件とは？機能要件との違いや設計方法、設計のポイントについて解説

  • ソフトウェアテスト・品質保証

  • DX

非機能要件とは？機能要件との違いや設計方法、設計のポイントについて解説

株式会社SHIFT　マーケティンググループ
著者 株式会社SHIFT　マーケティンググループ

お役立ち資料

Introduction

システム開発において、プロジェクト初期に要求を明らかにし、「どのような機能を実現するか（いわゆる機能要件）」を集中的に議論している現場は多いでしょう。アジャイルのような小さなイテレーションで機能を実装していく現場においては、特に機能要件を重視する傾向があります。
それに比べて、メンテナンス性や処理性能、拡張性などの非機能要件を明確化し、機能要件と同等のプロセスで定義・実装している現場は少ないように感じます。

なぜなら、機能要件の基となる顧客要求は明らかになりやすく、また目に見える形で達成度合いを表現することができるため、議論するモチベーションをもちやすいのですが、その反面、非機能要件は明確なニーズや要求がないことが多く、定義も難しいので、時間や専門性を要することが多くなり、敬遠されがちになります。

ただし、類似システムが多い昨今において、機能要件はもはや必須条件かつ最低条件となっており、競合優位性を示す要素には成り得ません。むしろ、非機能要件の質こそがシステムの質となり、競合優位性を示す要素であるといえます。特に、事業が継続する限り運用されるWebサービスが多い現IT市場においては、必然的に長いシステムライフサイクルを意識した非機能要件の検討が必要となるでしょう。
また、非機能要件に関連する検討事項は、アーキテクチャ設計のようなプロジェクト中期～後期に変更すると手戻りが膨大になってしまうものがほとんどであるため、プロジェクト初期に検討をしておくことが、プロジェクトの成否にも大きな影響を及ぼします。

すなわち、システム開発において、非機能要件への関心度と重要度は、以前より増しているのです。
そこで今回は、非機能要件に焦点を当て、機能要件との違いや、非機能要件で定義すべき項目、そのポイントについて説明いたします。

目次

非機能要件（non-functional requirement）とは？

非機能要件とは、システムの主目的となる機能面の要件以外すべてを指します。ユーザビリティ、性能、拡張性、セキュリティなど、システムにとって不可欠な「質」の部分になります。

例えば、使い勝手が悪くユーザーから不満が出ている、パフォーマンスが悪くて作業効率が悪化した、セキュリティに欠陥があり情報漏洩した、システムが不安定で時々落ちる、拡張性がなくて我慢して使っている、などの問題はどれも非機能要件が満たされていないために起こる問題です。

これらからもわかるとおり、非機能要件で定義する項目は多岐にわたりますし、何を定義すればよいかが不明瞭で、きちんと定義せずにシステムをつくってしまうと、稼働してから大きなトラブルになりやすい特徴をもっています。

株式会社SHIFTでは、ソフトウェアテストに関して豊富な実績とテストナレッジを保有しており、あらゆるお客様のニーズを満たしたテスト・品質保証を上流～下流（テスト計画・テスト設計・テスト実行・テスト品質管理）まで一気通貫でご依頼いただけます。

ソフトウェアテストのことならSHIFT
「3分で知るSHIFTのテストサービス」の資料ダウンロードページへ

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ

非機能要件（non-functional requirement）とは？

非機能要件と機能要件の違い

機能要件と非機能要件は、要件定義工程にて定義されますが、どちらもバランスよく兼ね備えることで、はじめてシステムの品質が担保されます。
機能要件とは、クライアントやユーザーから求められている「必ず搭載すべき機能」を指します。機能要件は、望まれている事項であるため、比較的容易に定義することができます。

例えば「現行システムでいま利用している機能は必ず盛り込んでほしい」、「今回は◯◯ができることが開発の目玉であるため、できないと困る」など、達成しなければならない基本となる部分が機能要件です。
そのため、システム開発のプロジェクトにおいて、機能要件の実装は当たり前であり、最低限必要な機能なので、搭載されているからといって、クライアントやユーザーの満足度が大きく高まることはありません。

一方、非機能要件はクライアントやユーザーから確実な要望があるわけではなく、利用者の視点に立って、開発側が考える要件です。これらはシステムにとって不可欠な「質」の部分になりますので、非機能要件が高品質な状態で定められれば、顧客満足度のアップにつながります。

このような違いから、システム開発においては機能要件と同様に、非機能要件も重視し、検討すべき事項と理解いただけると思います。

機能要件とは

・クライアントやユーザーからの要望としてある『機能』を満たすこと
・満たされていることが最低条件

非機能要件とは

・主目的となる機能面の要件以外すべて
・システムにとって不可欠な「質」の部分
・確実な要望はなく、利用者の視点に立って、開発側が考える要件
・高品質な状態で定められれば、顧客満足度のアップにつながる

非機能要件で定義すべき項目

非機能要件で定義する項目は多岐にわたります。そのため、何を定義すればよいかが不明瞭で、きちんと定義せずにシステムをつくってしまうと、稼働してから大きなトラブルになりやすく、非機能要件が難しいポイントになります。

ここでは、非機能要件で定義すべき項目について、参考とすべき２つの文献を用いて紹介をします。

①非機能要求グレード

独立行政法人情報処理推進機構（IPA）が6つのカテゴリに分類しています。このカテゴリを満たす形で定義すれば、クライアントを満足させるシステムを開発することができるとされています。

可用性

運用スケジュールや障害発生時の復旧などに関する要求。
バックアップ体制や障害発生時の回復方法を確立させることを定義。

性能／拡張性

ピーク時の負荷や業務量増加の対応などに関する要求。
ソフトウェア内部の処理を効率化したり、ネットワーク機器の配置に配慮したりして、処理速度や機器の新規設置を定義。

運用／保守性

システム運用時の稼働率や問題発生時の対応などに関する要求。
正常運用のための監視の充実や、運用マニュアルの拡充を定義。

移行性

新システム移行に関する要求。
移行までのスケジュール調整や、リハーサルの実施を定義。

セキュリティ

利用者の制限や不正アクセスの防止などに関する要求。
アクセスの制限や不正利用者の監視、社員への情報セキュリティ教育を定義。

システム環境／エコロジー

システムの設置環境や消費エネルギー量などに関する要求。
設備に適した機器の選定や、環境負荷を低減させるシステムの構成を定義。

出典：独立行政法人情報処理推進機構 （IPA:Information-technology Promotion Agency, Japan）　システム構築の上流工程強化（非機能要求グレード）紹介ページ

②非機能要求仕様ガイドライン

一般社団法人日本情報システム・ユーザー協会(JUAS)が「非機能要求仕様ガイドライン」として出版しています。
「機能性」「信頼性」「使用性」「効率性」「保守性」「移植性」「障害抑制性」「効果性」「運用性」「技術要件」の10種類に分類し、どのように定義、検証するか書かれています。

このように、代表的な２つを例にとって説明しましたが、重要とされているポイントが異なることがわかります。
これは、システムによっては項目が該当しないものもありますし、すべて明確に定義しなければならないものではないからです。あえて要件を記述しなくても、一定の水準を満たしたシステムができあがることもあると思います。

しかし、大事な非機能要件が漏れていたために、システムが完成してから大きな問題として発覚することも少なくありません。
よって、システム開発を行う際には、①②などを参考にしながら、システムの特性に合った非機能要件を定義することを強く推奨します。

以下に、①②の文献でうたわれている内容を要約しますので、参考にしていただければ幸いです。
※「要点」は限りなく簡略化して記載しています。詳細は各文献をご確認ください。

分類 要点 ①非機能グレード ②非機能要件ガイドライン

可用性

バックアップ体制や障害発生時の回復方法

●

 
性能・拡張性

レスポンス、スループット、追加、改善のしやすさ

●

 
運用・保守性

運用、保守のしやすさ

●

●
移行性（移植性）

多環境への移行のしやすさ

●

●
セキュリティ

アクセスの制限や不正利用者の監視、社員への情報セキュリティ教育

●

 
システム環境

システムの設置環境や消費エネルギー量

●

 
機能性

必要な機能の実装度合い

 

●
信頼性

システムの安定供給

 

●
使用性

ユーザビリティ

 

●
効率性

リソースの効率利用

 

●
障害抑制性

障害発生、問題拡大のしにくさ

 

●
効果性

投資対効果

 

●
技術要件

技術に関する要件

 

●

出典：非機能要求仕様定義ガイドライン（UVCプロジェクトⅡ　2008報告書）より加工・編集_（編著：社団法人 日本情報システム・ユーザー協会）

設計指標（RASIS）と評価基準（SLA/SLO）

ここまでは、非機能要件とは何か、どのような項目を定義すべきかについて説明してきましたが、次に具体的に各項目をどのような指標値で表現、評価したらよいのかについて、「RASIS」と「SLA」「SLO」を用いて説明します。

前途の通り、非機能要件は、暗黙的になりやすく、明確なニーズもないことが多いです。よって「非機能要件」の設計・評価を行うにあたり、これら指標や基準を理解し、定義づくりしていくよう心がけましょう。

RASIS

「RASIS」とは、非機能要件に特化した指標ではなく、コンピュータシステムのサービス全般に関する指標基準のひとつです。定義される５項目について、概要と代表的な指標例を以下にまとめます。

項目 略称 概要 代表的な指標例

Reliability

信頼性

障害や不具合による故障が起きにくい安定したシステムであるか

システムが安定稼働し続ける平均時間である 平均故障間隔（Mean Time Between Failures、MTBF）など
Availability

可用性

システムが継続して稼働できる度合い

稼働が期待される時間に対する実際の稼働時間の割合を示す「稼働率」など
Serviceability

保守性

障害復旧やメンテナンスのしやすさ

システムを修復するのにかかる平均時間である平均修理時間（Mean Time To Repair、MTTR）など
Integrity

完全性

データの完全性が保たれているか
過負荷や障害、誤操作などによってデータの破壊や喪失、不整合などが起こりにくいか

定性的な評価によるもの。評価指標はない。
Security

安全性

不正利用に対してシステムが安全に保護されているか

定性的な評価によるもの。評価指標はない。

SLA

「SLA」とは、「サービスレベル契約」のことです。サービスを提供する事業者と契約者の間で交わされる契約であり、事業者が提供するサービスの内容や性能基準を、どの程度のレベルまで保証するかについて、明文化したものとなります。
これらは、サービス提供において守るべき約束ごとであり、違反すればペナルティが課せられる場合もあるため、ペナルティの条件や内容についても、両者合意のうえ「SLA」に記載する必要があります。

サービスを提供する事業者は、「SLA」を策定することによって、顧客の期待を明示的に管理できると共に、サービス障害や性能低下に関する免責事項についても明示することができます。
一方、契約者としての顧客も、サービス障害発生時の損害賠償などについて、契約として明示化できるというメリットがあります。

SLO

「SLO」とは「サービスレベル項目(目標)」のことです。「サービスレベル項目(目標)」は、「SLA」で顧客と合意した契約内容に対して、それを達成するための具体的な評価基準や指標値や目標を示します。

SHIFTが考える非機能要件のポイント

最後に、繰り返しになる部分もありますが、非機能要件定義を行う際のポイントを、筆者なりに整理します。要件定義時の参考にしていただければ幸いです。

後回しにしない

非機能要件は、定性的な評価項目も存在しているため、暗黙的になりやすく、機能要件に比べると、検討や議論のモチベーションをもちづらいものです。『どういった機能を搭載するか』のような議論のほうが、「システム開発をしている」という自覚ももちやすく、楽しいのも事実です。

ただし検討を怠れば、システムが完成してから大きな問題として発覚することも少なくありません。ものによってはペナルティが発生してしまう問題にもつながります。そのため、機能要件と同様に、必ず要件定義工程にて検討を開始し、機能実装と同じように非機能実装も進行するようなプロジェクト運営を強く推奨します。

明確な顧客要求がないことを強く意識する

非機能要件は、顧客からの確実な要望はなく、利用者の視点に立って、システム提供側である開発部隊が考えなければならない項目です。システム知見を有している開発部隊が、定義すべき項目やその内容に関してしっかりオーナーシップをもって、推進していかなければならないことを前提に、プロジェクトを進めてください。

文字文字しない

これまで説明をしてきた内容からもわかる通り、非機能要件で定義すべき項目や、その内容は、システム知見や経験則を多分に要するため、システム用語や専門技術の説明は避けて通れません。ただし、多くの顧客や利用者は、システム知見に長けていない場合が多く、せっかく優れた非機能要件を定義しても、または誤った内容にて非機能要件を定義してしまっても、顧客や利用者にはその内容を判断することが困難です。

そのため、なるべく図や表で内容を表現し、視覚的に理解しやすい定義表現を心がけるようにしましょう。

まとめ

いかがでしたでしょうか。

本コラムにて、非機能要件の定義項目やその判断指標、定義時のポイントについて説明してきましたが、非機能要件とは、専門性の高い内容であり、評価指標も定めづらいものですから、暗黙的になりやすいことがご理解いただけたかと思います。だからこそ、適切な非機能要件をすることで、他社との優位性を示しやすく、クライアントやユーザーからの満足度につながりやすい重要項目であるとも考えられます。

システム開発において、非機能要件への関心度と重要度は以前より増しています。本コラムを参考に、ぜひ上質な非機能要件定義を実現してください。

弊社SHIFTにおいても、非機能要件の定義やその評価に関するソリューションを多数取り揃えております。自社体制への不安や、弊社ソリューションへの興味がありましたら、ぜひお近くの弊社メンバーへの声がけや、Webからのお問い合わせをお待ちしております。

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ

ソフトウェアテストの悩みはSHIFTが解決できます！

Eeasyバナー

「自社で効率よくソフトウェアテストを実施できない…。」
「どうしてもテスト工数が膨らんでしまう…。」
「期日に間に合わない…。」
「リリース後に不具合が発生してしまっている…。」

といった悩みを抱えている企業は多いでしょう。

質の高いソフトウェアテストを効率よく行うためには、多くの知識や経験が必要です。社内に経験豊富なIT人材が不足していると、質の高いテストを実施するのがむずかしく、かといって一からIT人材を集めるためには膨大な時間とコストがかかってしまいます。

そのような悩みは、SHIFTのソフトウェアテスト・第三者検証のサービスを利用いただくことで解決できます。

＼おすすめの資料／　※すべて無料でダウンロードいただけます。
・3分で知るSHIFTのテストサービス
・テスト効率が大幅アップ、人手不足解消の切り札に ＜理由＆メリット＞
・ソフトウェアテストを外注すべき5つの理由とは！？
・サービス導入事例集

これまで導入いただいた企業様は3,000社以上。その豊富な専門知識と経験を活かして、高品質のソフトウェアテストを効率よく行い、開発のサポートをいたします。

ぜひSHIFTのソフトウェアテスト・第三者検証をご利用ください。

ご相談はこちらから。
＞＞お問い合わせ
＞＞料金について

資料ダウンロード／動画視聴

3分で知るSHIFTのテストサービス
サービス導入事例集
非機能テスト 講座

この記事を書いた人

株式会社SHIFT　マーケティンググループ
著者 株式会社SHIFT　マーケティンググループ

SHIFTは「売れるサービスづくり」を得意とし、お客様の事業成長を全力で支援します。無駄のないスマートな社会の実現に向けて、ITの総合ソリューションを提供する会社です。

サービスサイト：https://service.shiftinc.jp/
コーポレートサイト：https://www.shiftinc.jp/
X（旧Twitter）：https://twitter.com/SHIFT_cp

ご支援業種

  • 製造、金融（銀行・証券・保険・決済）、情報・通信・メディア、流通・EC・運輸、ゲーム・エンターテイメント

など多数

前のページへ

次のページへ

コラム一覧に戻る

関連コラム

関連するサービス

Top
オペレーターアイコン

お電話でのお問い合わせ

TEL 0120-142-117

受付時間　平日9:00 - 18:00

※ フリーダイヤルをご利用できない場合は、TEL 03-6809-2979におかけください。