非機能要件とは何か？機能要件との違いをわかりやすく解説

​2020年3月13日​2023年11月17日

非機能要件とは

非機能要件とは、開発するITシステムの動作以外の部分で求められている要件のことを指します。
例えばソフトウェアの品質であったり、運用の手順などが非機能要件に含まれます。

「機能要件ではない」とはどういうことか

共通フレームによる定義

この非機能要件はITプロジェクトに慣れていない人であればなかなか理解が難しい部分かもしれません。
共通フレームでは非機能要件を「業務要件の定義で明確にした業務要件を実現するために必要なシステムの機能要件以外の要件^[1]共通フレーム2013、134頁。」と定義していますが、 「機能要件以外の要件」と言われてもなかなかピンとこないのではないでしょうか。
ここからはこの非機能要件について解説していきます。

そもそも「機能」とは何か？

「非機能要件とは何か？」を考える前に、まずそもそも「機能」とは何かを考えていきましょう。
ITシステムにおける「機能」とは、そのITシステムが「何をするのか」を表すものであり、動作を表すものです^[2]D.C. ゴーズ（著）、G.M. … Continue reading。
つまり、「非機能」、すなわち「機能以外」というのは、「動作」以外の部分であると言い換えることができるでしょう。

求人に例えると

「機能要件」と「非機能要件」を求人で例えると、「機能要件」とは求められるスキルセットのことで、「Javaが扱える」「マイクロソフトのExcelが使える」という項目が該当します。
一方で、求人における「非機能要件」とはスキル以外の部分であり、「保守性に優れたきれいなコードをかける」という品質にかかわるものや、「長期で働いてくれる」という運用に関するものです。「どのくらいのお給料で働いてくれるのか」も非機能要件に含まれるでしょう。
このように考えると、機能要件というのはITシステムのほんの一部であり、それ以外の非機能要件というのが非常に多岐にわたる内容だということがわかります。

非機能要件一覧

これまで見てきたように、非機能要件というのは機能以外の様々な要件を表しています。そのため、非機能要件についていくつかの定義がありますが、ここでは日本情報システム・ユーザー協会（以下、JUASと略記）が発行した『非機能要件要求仕様定義ガイドライン』で定義している非機能要件の内容を見ていきましょう。
JUASが非機能要件として定義した９つの大項目を列記すると以下のようになります ^[3]非機能要求仕様定義ガイドライン（UVCプロジェクトⅡ　2008報告書） | JUAS 一般社団法人 日本情報システム・ユーザー協会 … Continue reading。

• 機能性
• 信頼性
• 使用性
• 効率性
• 保守性
• 移植性
• 障害抑制性
• 運用性
• 技術要件

ここからは、これら9種類の非機能要件がそれぞれ何を意味しているのか、簡単に見ていきましょう。

機能性

はじめに機能性を見ていきましょう。
「非機能要件の機能性」というと頭が混乱してしまいそうですが、計算の精度であったり、セキュリティの脆弱性がないかという機能の品質に関するものを指します。
簡単に言うと、機能要件にプラスアルファした機能の性質を指しています。
例えば「機能性に優れたスニーカー」といえば、ただ「足の保護」 をしてくれるだけでなく、「疲れにくい」「軽い」というアピールポイントがあります。つまり、「足の保護」という機能要件の他、その機能にプラスアルファする「疲れにくい」「軽い」という非機能がついているということです。
同様に、「機能性に優れた計算システム」というのであれば、「計算する」という機能要件でなく、「計算結果が正確」「セキュリティ面でも問題がない」というようなプラスアルファの性質を指しています。

信頼性

ITシステムでいう信頼性とは単に「どのようなテストを行ってどの程度合格したのか」ということを意味することもありますが、障害や災害が発生しても稼働し続けることができるか、あるいはもし機能が停止したとしてもどのくらいの時間で復旧できるかという程度も表しています。
最近では事業継続マネジメントが叫ばれて久しいですが、例えば、東京で大地震が起きてしまった場合に機能が停止しても120時間以内には復旧できるようにしておくなどは信頼性を高める施策になります。
つまり、「このシステムを信じて使い続けられるか？」というのが、ITシステムの信頼性だと言えるでしょう。

使用性

ITシステムの使用性とは、そのITシステムの機能が使いやすさを意味しています。
例えば何の説明もなくても、そのITシステムを使うことができれば、使用性の高いITシステムだということができます。あるいは、２～３時間の研修を受けただけで、十分に使いこなせるようになるのであれば、それも使用性に優れたITシステムです。
この他に、使用するにあたって疑問がでた時に参照するヘルプページを作ったり、誤った操作をした時に正常な操作に戻しやすくするのも使用性の向上につながります。

効率性

ITシステムの効率性とは、時間や資源をどのくらい効率的に使って稼働しているのかを意味しています。
一番イメージしやすいのが、時間の効率性でしょう。
例えば図書館や本屋さんにあるシステムで蔵書検索をした時に、１秒もかからず結果が返ってきたら時間効率が高いITシステムだと言えますし、１分待ってようやく結果が返ってきたら時間効率が悪いと言わざるを得ません。
ITシステムが使う資源とはCPUやメモリ、電力などを指します。例えばそのITシステムを起動したらブレーカーが落ちてしまえば、電力の使用効率がよくないのかもしれません。
この他、CPUやメモリの使用効率が悪いと、起動しているPCの動きが悪くなってしまったり、他のITシステムに悪影響がでてしまいます。
こうしたことが起こらないよう、ITシステムの効率性にも十分気を付けなければなりません。

保守性

ITシステムの保守性とは、維持や手入れのしやすさの程度を示しています。
例えば、使用されているプログラムコードを開発者以外のプログラマーが見ても読みやすいかというのは、維持のしやすさにつながるため、保守性に影響していきます。
また、障害が発生した時に、そのログを残すようにするのも、修正作業をしやすくするため、保守性を高めてくれます。

移植性（移行性）

ITシステムの移植性（あるいは移行性）とは、異なる環境への移植のしやすさを表しています。
例えば、iPhoneなどのアプリケーションであっても、iPhoneのバージョンによっては正常に起動したり、しなかったりします。
「同じiPhoneなのだから動いて当然ではないか」と思ってしまいますが、似たような環境であっても、異なる環境に移植するというのは難しいことです。
それがオリジナルで開発されたITシステムであればなおのことで、サーバーなどの環境を新しくした際にシステムが動かなくなるのはよくある話です。
こうした移植のしやすさが、ITシステムの移植性です。

障害抑制性

障害抑制性は、その名の通り障害の発生をどのくらい抑制できるかという度合いを表しています。
やや信頼性に近い内容ですが、信頼性は事後対応の色合いが強く、障害抑制性は予防という色合いが強いです。
例えば障害が発生しないようにテスト環境を用意して、テストの確認体制を構築したりしていきます。それだけでなく、二次被害が拡大しないような施策も障害抑制性を高めてくれます。
JUASの定義の中の障害抑制性の面白いところは、 「品質と価格の関係」 「工期と価格の関係」も適切でなければ障害が発生してしまうとしているところです。無理に安く、早くつくったITシステムというのは、障害を防げないということを暗に示しています。

運用性

運用性とは組織としてそのITシステムが運用しやすいかどうかを表しています。
これも信頼性と近い内容で、ITシステムの稼働率やミスが起こった時の対処などが運用性に影響していきます。
注目すべきは運用性が組織としてITシステムの付き合い方を測定していることで、例えば複数人で作業したオペレーションミスを復旧しやすければ運用性が高いITシステムとなります。
この他、障害や災害時の対応を事前に訓練しておくと、運用性が高まります。

技術要件

技術要件とは、「どのような技術を使ってほしいか」という要件のことです。
この技術については、何もプログラミングで使用する言語やハードウェアの種類だけでなく、要件定義書や各種仕様書の作成など、今後の運用を考える上で必要と思われる書類を求められることもあります。
あるいは、所有しているサーバーの種類から「PHPで開発してほしい」と言われる場合もありますし、「セキュリティの観点からXXは使ってほしくない」という要求がでることがあります。このように、技術要件はしばしば「このような技術は使ってほしくない」と言い換えたほうが理解しやすい場合もあります。

この他の非機能要件の定義について

この節の冒頭でお話ししたように、非機能要件についてはいくつかの定義があります。例えば共通フレームの中でも定義がされており、非機能要件を品質要件・技術要件・ 運用、操作要件・移行要件・ 付帯作業 ・その他要件の６つの大項目に分けて定義しています ^[4]共通フレーム2013、134～135頁。 。
また、共通フレームを編集しているIPAが提供している「非機能要求グレード」というものもあります。
「非機能要求グレード」は、「非機能要求」についてのユーザと開発者との認識の行き違いや、互いの意図とは異なる理解を防止することを目的とし、非機能要求項目を網羅的にリストアップして分類するとともに、それぞれの要求レベルを段階的に示したものです^[5]システム構築の上流工程強化（非機能要求グレード）：IPA 独立行政法人 情報処理推進機構 。
以下のWebページより資料をダウンロードすることができるで、あわせてご確認ください。

• システム構築の上流工程強化（非機能要求グレード）：IPA 独立行政法人 情報処理推進機構

プロジェクトでは非機能要件でトラブルが起こる

アプリケーション開発などのITプロジェクトでは、この非機能要件をめぐってのトラブルが多く発生します。
ITシステムの開発を依頼する側（発注者側）は「何をしたいか」までは十分に検討できるものの、「どのくらいのスピードで行わなければならないのか？」「どの程度の保守性を担保して開発を行うのか？」という非機能要件までは専門外であるために、考えが及ばないということがあります。その結果、要望の機能は備わっているものの、１つの処理に半日もかかるITシステムを見て、目の前が真っ暗になってしまうことがあります。
開発を担当したベンダーが修正対応に応じてくれればまだいいものの、クレームをいれても、「その機能の開発はしっかりと依頼されていましたが、この処理に半日かけてはいけないという話なんて聞いていません」とつっぱねられてしまうこともあります。
このようなトラブルを引き起こさないためにも、先ほど紹介した 『非機能要件要求仕様定義ガイドライン』を使い、ベンダー側と協力しながら、必要な非機能要件をシステムの設計に盛り込んでもらえるようにしていきましょう。