非機能要件がシステムの「品質」を左右する！定義項目を解説

要件定義は、システム開発の上流工程のなかでもとくに重要な工程です。要件定義によって、そのプロジェクトで「何をどのようにシステム化するか」が決定されるからです。

要件定義の工程で定める開発要件には、大きく機能要件と非機能要件があります。この記事では、非機能要件を定義する目的や定義手順、おもな定義項目について説明します。

非機能要件を定める目的とは？

要件とは、「必要な条件」のことです。要件定義は、そのプロジェクトで何をシステム上に実現するのかを明確にし、併せて、実現の成否の評価指標を固めていく作業といえます。流れとしては、まず業務要件を整理・把握し、業務要件に基づいて開発要件（機能要件・非機能要件）を検討していきます。

なお、要件定義については、こちらの記事で詳しく解説しています。よろしければ併せてご確認ください。
要件定義とは？具体例を挙げながらシステム開発の手戻りを防ぐ進め方のコツを解説！

（1）業務要件（business requirements）

ITシステムは、稼働させること自体が目的ではありません。ITシステムによって業務に利益がもたらされたときに初めて、そのシステムは価値ある存在となります。そのため、要件定義ではまず、業務のあるべき姿（業務機能、業務フローなど）と現状のギャップを洗い出していきます。業務のギャップを洗い出せたら、そのなかから業務背景なども考慮しながら、システム化する範囲を定義します。

業務要件のポイントは、洗い出しの段階では、業務そのものに焦点をあてることです。「これはITシステムでは実現できないから」と担当者が先入観を持っていると、「作ったはいいが、業務改善につながらない」システムができあがるリスクがあります。また、洗い出しが不十分だと、開発工程で「これもシステム化してくれないと困る」と追加要件が発生し、多大な手戻りコストが発生しかねません。

業務要件の定義は、通常、その業務に精通した顧客（発注側）が主導で実施します。

（2）機能要件（functional requirement）

業務要件が定まったら、機能要件を定義していきます。機能要件とは、そのプロジェクト内でシステムに必ず実装する機能・挙動のことです。「◯◯の機能をこのように改善してほしい」「△△の機能はないと困る」など、発注側をヒアリングしながら、開発者が機能要件を精査していきます。

いわば、機能要件は、発注側自身が認識しているニーズをドキュメント化したものです。リリース時点で機能要件をすべて実装したシステムが、発注者にとって「思ったとおりのシステム」となります。未実装の機能があれば「使いにくいシステム」ではなく「使えないシステム」の烙印が押されますし、機能（明示されたニーズ）を美しく実装したところで「思った以上のできあがりだ！」と高い評価を得ることは難しいでしょう。

（3）非機能要件(non-functional requirement)

システムリリース後に発注側から高い満足度を得たいならば、非機能要件の精度を高めるべきです。業務要件や機能要件をもとに「どのような品質でシステムを稼働させていくか」を定義したものが非機能要件だからです。

どれだけ精緻な非機能要件を定義・実装できたかが、システムの使いやすさや安定性に直結します。しかし、えてして発注側は、「自分たちにとって“使いやすい”とはどういう状態か」や「自分たちはどういった要素で安定性を測っているか」を把握していません。そのため、非機能要件が発注側からニーズとして挙がってくることは稀です。

非機能要件の定義も、責任者は発注側です。しかし、検討そのものは、システム開発のノウハウを持ち合わせている開発側が主導していくことをおすすめします。発注側と密度の高いコミュニケーションを取り、使いやすさや安定性を構成する要素を細分化し、ニーズ（現状維持なのかギャップ改善なのか）を掘り起こしていきましょう。

要件定義の段階で非機能要件の精度を高めておくことは、開発側にコストメリットももたらします。開発フェーズでの手戻り回避、運用フェーズでのトラブル回避につながるからです。

非機能要件はどのような手順で定義する？

非機能要件を定義する際の重要なポイントは、「表現されない要件はシステムとして実現されない」「数値化されない要件は人によって基準が異なる」（IPA-SEC『超上流から攻めるIT化の原理原則17ヶ条』より）です。

これらの原則が引き起こすトラブルを回避することを目的に、非機能要件は次の手順で検討するケースが多いです。

①　開発側が草案を作成する

②　顧客と要件をすり合わせる

③　コストを勘案して要件を精緻化し、合意する

それぞれの概略を説明します。

①　開発側が草案を作成する

草案は一般的に、独立行政法人情報処理推進機構（IPA）が定める「非機能要求グレード」に沿って作成していきます。非機能要求グレードについては、次章で詳しく説明します。

②　顧客と要件をすり合わせる

草案をたたき台として、発注側が求める「使いやすさ」や「安定性」を浮き彫りにしていきます。例えば、「レスポンスタイムを現行の5秒から3秒に縮めたい」「繁忙期はシステム稼働の終了時刻を21時から23時に引き伸ばしてほしい」「繁忙期は土日祝もシステム稼働時間にしたい」など、変更リクエストが数値や具体的内容で出てくるでしょう。

変更リクエストを受けたときは、リクエストの背景にある業務理由を確認しておくと、代替案やもっと適した案を提案しやすくなります。

③　コストを勘案して要件を精緻化し、合意する

発注側からのリクエストをすべて汲むと、工数や体制が青天井になってしまう可能性があります。「レスポンスタイム3秒を実現するには、CPUやメモリの増強が必要」「システム稼働時間を拡張するならば、相応の運用体制が必要」など、金銭コストや工数も勘案して要件を取捨選択し、合意します。

非機能要件として定める項目とは？

非機能要件の範囲は、機能以外のすべてが対象となります。「これさえ定義しておけば問題ない」というラインがないのが、非機能要件の定義の難しいところです。とはいえ、非機能要件の定義漏れが発生しやすいことはIT業界共通の課題でもあります。独立行政法人情報処理推進機構（IPA）は、この課題解決の一つの助けとして、「非機能要求グレード」をまとめています。2010年4月に初版が公開、その後バージョンアップが繰り返され、2022年4月現在の最新版は「非機能要求グレード2018」です。

「非機能要求グレード」では、非機能要件を大きく6つのカテゴリーに分類しています。これらをミニマムとして非機能要件を検討すると、重大な定義漏れが発生するリスクを回避できます。

以下、各カテゴリーの概略を説明します。

（1）可用性

「システムの継続的な利用」を実現するための要件を定めます。具体的な検討要素には、システム稼働時間、耐障害性（冗長化や、障害発生から復旧までの目標タイム）、災害対策（データバックアップ）などが挙げられます。

（2）性能・拡張性

「システムの安定的な利用」を実現するための要件を定めます。具体的な検討要素には、処理量や処理速度（平常時・ピーク時・縮退運転時）を意識したサイジング、今後の業務量の動向を見据えた機器・ネットワークのキャパシティプランニングなどが挙げられます。

（3）運用・保守性

「システムの安定的な稼働」を実現するための運用・保守面の要件を定めます。具体的には、運用環境（機器設置場所の温度・湿度管理）、運用内容（通常時・保守時・障害時）、運用・保守体制などが挙げられます。

（4）移行性

「開発したシステムのスムーズなリリース」を実現するための要件を定めます。具体的には、現行システムからの移行時期、移行対象の資産、移行方式（段階移行・一括移行）などが挙げられます。

（5）セキュリティ

「システムの安定的な稼働」を実現するためのセキュリティ面の要件を定めます。具体的には、利用者制限（社内・社外）、不正アクセス防止策、セキュリティリスクの管理方法などが挙げられます。

（6）システム環境・エコロジー

「システムの安定的な稼働」を実現するための環境面の要件を定めます。具体的には、機材設置環境（耐震・免震）、適合規格、環境マネージメント（環境負荷を低減させる方策）などが挙げられます。

（7）その他

IPAが策定する「非機能要求グレード」は、あらゆるシステム開発の現場で汎用的に役立ちます。しかし、「非機能要求グレード」だけで万全とは限りません。例えば、ECサイトの開発であれば、UIを含めたユーザビリティなども定義が必要でしょう。

定義漏れを防ぐべく、開発者には、発注側のニーズを引き出すコミュニケーションスキルや、具体的な業務オペレーションをイメージする経験値などが求められます。

また、非機能要件を標準化したものは、IPA「非機能要求グレード」のほかに、日本情報システム・ユーザー協会（JUAS）の「非機能要件要求仕様定義ガイドライン」も代表的です。適宜参考にすることをおすすめします。

非機能要件の精度はシステム開発の成功に大きく関わる

要件定義の工程の成果物となる業務要件・機能要件・非機能要件のなかでも、非機能要件の精度がシステム開発の成功・失敗の評価を左右するといっても過言ではありません。IPAやJUASが策定する非機能要件の標準も参考にしながら、発注側と協働して非機能要件を定義していきましょう。