非機能要件要件とは？「クライアントから引き出す」ためのポイントを合わせて解説

非機能要件とは？

非機能要件とは、開発要件におけるシステム機能以外の要件全般をさします。非機能要件を的確に定義することで、顧客の求める成果を高いレベルで提供できるようになります。

まずは、非機能要件の基本的な特徴について紹介します。

開発要件の分類

開発要件は顧客の課題やニーズを踏まえて、そのプロジェクトの成果物がもたらす効果についてまとめたものです。一般的に機能要件、非機能要件に分類されます。

機能要件

システムに実装したい機能に関するポイントをまとめます。要件定義後に進められる開発フェーズにおいては、機能要件をより高いレベルで実現することを目指して開発がおこなわれます。

非機能要件

機能要件以外の要件が非機能要件にあたります。例えば、システムが動作するまでの速度や、システムの日時切り替えの基準をどのように設定するか、などといった内容が考えられます。システムの機能がいかにスムーズに、快適に運用できるかを示す要件と考えるととらえやすいでしょう。

クライアントの非機能要件とは？

顧客の開発要件は不明瞭であることが多い

コンサルプロジェクトは多くの場合クライアントのニーズをヒアリングするところから始まります。その際、ほとんどのケースでクライアントは機能要件・非機能要件に当たる内容が混ざった状態で課題やニーズを打ち出してきます。

クライアントからのヒアリングや現状分析などの調査をふまえて、要件定義において機能要件・非機能要件を的確に切り分けることが、質の高い成果の提供に繋がっていくのです。

クライアントの満足度は非機能要件の充足度合いに左右される

システムの機能に関するニーズについては、多くの場合クライアントでも既に課題意識を持っており、また機能を実装させる・させないかの二者択一になることが多いため、比較的スムーズに定義できるのが一般的です。

対して、非機能要件について、まずクライアントはどのような要素を充足すれば成果に対してより満足できるのか自覚していないことが多く、コンサルタントは顧客のヒアリングや現状分析を通じて、クライアント自身も自覚していない要素を的確に要件としていかなければなりません。

また、非機能要件は「どれくらいの速度で立ち上がればよいか」「業務量がどの程度削減されるか」など、二者択一で表現できるものにならないことが多いです。そのためクライアントがどの程度の水準を満たせば満足するかもわかりにくいのが特徴です。

以上のような特徴があるからこそ、クライアントにとってプラスとなる適切な非機能要件を定義し、それを充足することが、クライアントのプロジェクトに対する高い満足度の獲得につながります。

6種類の非機能要件設計項目

非機能要件はその要件の範囲が漠然としており、検討すべき項目はややもすると多岐にわたります。その中でスムーズに要件定義を進めていくうえでは、IPA（独立行政法人情報処理推進機構）が公開している「非機能要求グレード」における6つの項目をもとに定義していくと良いでしょう。

ここからは各項目を詳しく解説していきます。

可用性

開発したシステムを継続的に利用していくうえでの要件。クライアントがシステムを使い続けるうえで、利便性や効率性が高まる要因をまとめていきます。

例えば次のような要件が考えられます。
システムのメンテナンス頻度を少なく稼働し続けられる、災害などにおける耐久性

性能・拡張性

システムに期待する動作が、より早く、少ない負担で実現する、より多くのデータを一挙に処理できる、故障・エラーが少ないことなどが性能の高さにあたります。また、将来機能をグレードアップする、他のツールやシステムと連携するときなどに柔軟にカスタマイズができるかどうかなど、機能の拡張性も非機能要件の一項目です。

具体的には次のような要件が考えられます。
システム動作にかかる時間・一度に処理できるデータ量、他のツールやシステムとの連携が柔軟におこなえる、将来の機能追加・アップグレードの容易性

運用・保守性

運用や保守のしやすさに関する要件です。システム運用時に必要となる工数の削減や効率的なシステム監視方法、バックアップ方法などが評価項目となっていきます。

具体的には次のような要件が考えられます。
運用工程の効率性や要員数、システムメンテナンスの頻度、メンテナンス時の稼働レベルや稼働が低下する期間の長さ

移行性

現行システムから成果物へ移行に関する要件です。準備や移行期間が少なくスムーズに移行したうえで、短期間のうちに新システムをフル稼働させられるのが最良で、いかにそれに近づけていくかが、非機能要件の項目となります。

具体的には次のような要件が考えられます。
移行までに必要な準備・準備にかかる工数、移行期間にどの程度システム稼働を維持できるか、新システムをフル稼働させるまでどのくらいの期間を要するか

セキュリティ

新システムを運用させていくうえでのセキュリティ全般に関する項目です。システム自体のセキュリティ関連の機能（機能ではありますが、システムに主として求められる機能ではないので非機能要件に属します）やセキュリティ確保のための体制構築などが含まれます。

具体的には次のような要件が考えられます。
アクセス制限、不正利用防止などのセキュリティシステム、セキュリティ維持のためのスキーム作り、システム運用者へのセキュリティ教育

環境・エコロジー

システムを運用するうえでの環境負荷の小ささを定義します。現代では多くの企業がESGの観点からあらゆるプロセスにおいて環境負荷の抑制が求められているため、システム案件においても重要な非機能要件となります。

・具体的には次のような要件が考えられます。
CO2排出量、消費エネルギー量、騒音・温度上昇などオフィスや周辺環境に与える影響

非機能要件の指標と評価基準

非機能要件は機能要件と比較して範囲が広く、また漠然としているため、次のような指標や基準を導入して評価し、可能な限り非機能要件を高いレベルで充足できるようにシステム開発やプロジェクト推進をおこないます。

「RASIS」

RASISはシステムが期待した機能を果たすかどうかを把握するときの評価項目の基準です。次の5項目それぞれに関連する評価項目を定めていけば、開発したシステムの非機能要件の充足度合を把握できます。

「R」（Reliability）：「信頼性」と訳され、障害や不具合などの発生しにくさを示します。稼働時間当たりの障害発生回数（MTBF：Mean Time Between Failures）などが代表的な指標です。

「A」（Availability）：「可用性」と訳され、稼働率の高さ、保守における停止時間の短さ、稼働低下度合の小ささなどが該当します。運用期間に対する実稼働時間の割合（稼働率）などが指標として活用されます。

「S」（Serviceability）：「保守性」/「運用性」と訳され、復旧やメンテナンスのしやすさなどを示します。障害発生から復旧までの平均時間を意味するMTTR（Mean Time To Repair）が指標として導入されます。

「I」（Integrity）：「保全性」/「完全性」と訳され、障害・誤作動などによるデータ・システムの破壊・喪失などの起こりにくさを意味します。

「S」（Security）：「機密性」と訳され、不正侵入や遠隔操作によるデータ・プログラムの改竄や情報漏洩リスクの低さを表します。

クライアントとのディスカッションなどを通じてこれら5つそれぞれについてどの項目に、どの程度の品質を目指すかを明確にしたうえで、評価基準や目標値を定めていくことが有効です。

「SLA」

SLAはService Level Agreementの略で、クライアント間とコンサルタント間で合意される成果物のサービス保証品質を意味します。プロジェクトによって開発されたシステムが最低限充足する品質を締結し、プロジェクトではその品質の充足を目指して開発が進められます。

基本的にプロジェクトのゴールとして扱われるものなので、安易にレベルの低い保証内容を締結するわけにはいきません。クライアントにとって満足できない成果物が出来上がるリスクもありますし、クライアントの満足度が低下することはコンサルタントにとってもリレーション上望ましくないからです。

非機能要件の定義と共に、顧客が真に満足する内容や水準をSLAとして設定することが大切です。

「SLO」

SLOはService Level Objectiveの略で、SLAを達成するためのより具体的なパフォーマンスの目標値を示します。サーバーやネットワーク、ストレージなどの各領域の稼働率、性能、可用性、セキュリティ、サポートなど多岐な項目にわたります。

目標値の設定ポイントはSLAによってさまざまですが、先に紹介したRASISに応じて目標値を設定するのも一案です。

SLOにおける各項目を充足すればSLAが達成され、その結果非機能要件で定義した項目が充足されている。そしてその結果クライアントがプロジェクトの成果に満足する、という関係性を持つように、各評価項目と要件を定めていくことが大切です。

クライアントからうまく非機能要件を引き出すポイント

非機能要件について、クライアントは始めから具体的な考えを持っているとは限らないため、クライアントが求めるポイントを察知して、非機能要件に落とし込んでいくためには工夫が必要です。

ここからはクライアントから非機能要件を引き出すためのポイントを紹介します。

主体的に提案

稼働時間やセキュリティ性の高さなどの非機能要件にかかわる部分について、コンサルタント自身の経験や、クライアントとのディスカッション、現状分析などの中から満足度を高める要素を察知し、主体的に提案を交えながら、プロジェクトの非機能要件を引き出して行く必要があります。

図示する

難解な説明を避け、機能や効果についてポンチ絵などで図示したり、想定される効果などについてグラフや図表を用いて簡潔に説明したりして、クライアントとの共通認識を形成することが重要です。

3段階のメリット・デメリット表を活用

要件定義とプロジェクトの方向性については松・竹・梅の三段階のレベルで提案することが有効です。画一的な一つの提案だけでは、それがクライアントにとって費用・効果のバランスの取れた提案となるかどうかは分かりません。複数案を提案することで、そのどれかがクライアントの満足度を最も高める内容となる可能性が高まるでしょう。

決定権はあくまでクライアント

最終決定はあくまでクライアントが形成するように促さなければなりません。クライアントが真に納得しないまま強引に案件を進めてしまうと、そのこと自体が満足度の低下に繋がるリスクがあります。また、プロジェクトにおいてトラブルが発生したときに、クライアントの関係性を不必要に悪化させてしまいかねません。

まとめ

今回の記事では、非機能要件ついて解説しました。コンサルティング案件などを探している方、事例を知りたい方は、ぜひfoRProまでご相談ください。