はじめに
システム開発において要件定義はもっとも重要なプロセスで、業務要件とシステム要件を明確に定義することが求められます。まず業務要件を定義し、その後にシステム要件を具体化しますが、システム要件は機能要件と非機能要件に分けて、それぞれ異なる視点からシステムを捉えます。
機能要件はユーザーのニーズに直接応える要素であり、システムが提供する具体的な機能やサービスのことを指します。一方、非機能要件はシステムの動作に関する特性や制約を定義し、システム全体の品質やユーザー体験に大きな影響を与える要素です。
本記事では、システム要件の一つである非機能要件にスポットを当て、非機能要件の定義やその重要性、国際標準等のフレームワークについて深く掘り下げていきます。また、非機能要件の抜け漏れに顧客が気づかないことが多い背景や、非機能要件がシステムにとってなぜ重要であるのかといったことも採り上げて、IT初心者にもわかりやすい内容を心掛けて解説していきます。
非機能要件とは？
非機能要件とは、機能以外の、システムの動作に関する特性や制約に影響するシステム全体の品質に対する要件のことですが、簡単に言えば、「システムがユーザーにとって“よい状態であること”に関わる要件」ということになります。
例えば、システムがユーザーにとって使いやすいこと、わかりやすいこと、誰かと同時に使っても一定の速度で動作すること、障害が起きにくいことなど、機能そのものではなくシステムそのものの「品質」に焦点を当てたものです。
要するに、「ユーザーがシステムで何ができるか」を定義する機能要件とは異なり、非機能要件では「システムがユーザーにとってどのようによいか」を定義します。
非機能要件はなぜ重要なのか？
非機能要件は、システム全体の品質及びユーザー体験を左右する重要な要素であることは先にお伝えしたとおりですが、このセクションでは、非機能要件がシステムにとってなぜ重要であるのかを詳しく解説します。
ユーザー体験の向上
非機能要件は、システムがどのように動作するかを決定するため、ユーザー体験に大きな影響を与えます。例えば、応答速度や可用性（システムやサービスがどれだけ利用可能であるかを示す指標）、使いやすさといった要件は、ユーザーがシステムを利用する際の満足度を大きく左右するものです。スムーズで快適な操作感が得られることで、ユーザーはシステムを継続的に使用し、ポジティブな評価をする可能性が高くなります。
信頼性と安定性の確保
システムがビジネスに与える影響は大きく、特に信頼性や安定性は極めて重要です。非機能要件を適切に定義することで、システムのダウンタイムを最小限に抑え、安定したサービスを提供することができます。これにより、顧客の信頼を得ることができ、長期的なビジネス関係を築くことが可能になります。
セキュリティの強化
現代のシステムでは、データの保護が不可欠です。非機能要件には、セキュリティに関する要件も含まれます。この取り決めにより、データ漏洩や不正アクセスを防ぐための対策が講じられ、顧客情報や機密データの保護が強化されます。安全なシステムは、顧客に対して安心感を提供し、企業の信頼性を高める要因となります。
パフォーマンスの最適化
システムのパフォーマンスを最適に保つことも重要です。特に、処理速度や負荷に対する耐性などは、システムが高負荷に対応できるかどうかを決定づけるため要注意です。パフォーマンスを最適化することにより、ビジネスの成長やトラフィックの急増に対しても柔軟に対応できるシステムを構築することができます。
メンテナンスの容易さ
非機能要件は、システムの保守性にも影響を与えます。この保守性や拡張性といった要件を考慮することで、将来的な改修や機能追加が容易になります。これにより、システムのライフサイクル全体にわたってコストを抑え、効率的な運用が可能になります。
法規制や業界標準の遵守
多くの業界では、特定の非機能要件が法規制や業界標準として求められています。これらの要件を遵守することは、法的な問題を回避し、企業の信頼性を維持するためにも不可欠です。適切な非機能要件を定義し、実装することで、リスクを軽減し、安定したビジネス運営が可能になります。
非機能要件はシステムの全体的な品質、つまり、ユーザー体験、信頼性、セキュリティ、パフォーマンス、メンテナンス性、さらには法規制の遵守に至るまで、多岐に影響を及ぼします。システム開発において、非機能要件は決して軽視してはいけない重要な要素であることがお分かりいただけたでしょうか。
非機能要件が顧客から出てこないこれだけの理由
機能要件は顧客が直接的に必要とするものですので、顧客からの要求という形で確認がしやすい一方、非機能要件は今まで見てきたとおり、システムの全体的な品質とユーザー体験に関わるものであるため、顧客自身が気づいていなかったり、わざわざ口にしなくてもわかっているはずぐらいの感覚になっているケースが非常に多く見受けられます。
このような状況は、実にさまざまな要因によって引き起こされますので、以下に、その理由と背景について詳しく解説します。
理由１：日常的に意識されていないから
顧客は、システムを使用する際、主に機能的な側面に焦点を当てることが多く、例えば、アプリケーションの使いやすさや機能の豊富さは明確に意識していますが、「応答速度」や「システムの安定性」といった特性は、顧客にとって直接的でなく、また目に見えないこともあり、日常的に意識されていません。このため、顧客が非機能要件について具体的な要求を持たないケースが多くあります。
理由２：経験則に基づいた期待だから
多くの顧客は、過去の経験から「当たり前」とされる非機能要件の基準を持っています。例えば、「Webサイトはすぐに開くべき」という認識はありますが、その具体的な数値（例えば2秒以内に表示されるなど）を示すことはあまりありません。このような期待は、言語化されずに暗黙の了解として存在するため、開発者側も顧客の具体的なニーズを把握しづらいといった側面があります。
理由３：言語化が難しいから
非機能要件はしばしば抽象的であり、明確な基準があるようでない（ここまでやればよいというものがない）ため、顧客が自分の要望を具体的に言語化することが難しいことが挙げられます。たとえば、「システムが速くなければならない」といった要求は、実際には「どの程度の速さが求められているのか」といった具体的な数値に落とし込む必要がありますが、多くの顧客はその数値を把握しておらず、結果として曖昧な表現に終始してしまいがちです。
理由４：ステークホルダー間で期待や要件が異なるから
プロジェクトに関与するステークホルダー（開発者、経営陣、ユーザーなど）によって、非機能要件に対する理解や期待が異なることがままあります。たとえば、開発者は技術的な視点から要件を評価し、経営者はビジネスの観点から要件を考慮しますが、実際のユーザーは利用時の体験から非機能要件を評価します。そのため、それぞれの立場で異なった期待があるのはもちろんのこと、それぞれのニーズが対立したり、矛盾したりするケースも発生します。このように、顧客自身も何が重要なのかを把握できないといった状況が生まれます。
理由５：後回しにされがちだから
要件定義では機能要件が優先されがちな傾向にあるため、非機能要件は後回しにされることが多く、顧客もその重要性を認識しづらいといった状態が発生します。そのため、機能が実装された後に非機能要件の不足が明らかになるケースが多く、顧客はその時になって初めて気づくといったことが、頻度高く起こります。
このような状況に対処するためには、開発者が積極的に顧客とコミュニケーションを取り、具体的な非機能要件を顧客から引き出す努力が必要不可欠となります。
非機能要件の基本的な項目
このセクションでは、非機能要件の基本的な項目をいくつか採り上げて、イメージできるように例をあげながら解説します。
（※国際標準のISOや、国内基準のIPA、デジタル庁が発行している定義については、「9. 非機能要件の様々なフレームワーク」のセクションで採り上げます）
性能要件
システムの応答時間や処理能力に関する要件です。例えば、ユーザーがボタンを押してから結果が表示されるまでの時間が短いことが重要な要件となります。
信頼性要件
システムが安定して動作し続けるかどうかを定義します。例えば、システムがダウンしないことや、障害が発生してもすぐに復旧できることが含まれます。
拡張性要件
将来的にシステムが利用者やデータ量の増加に対応できるかどうかを示す要件です。たとえば、ユーザーが増えてもパフォーマンスが低下しない設計が求められます。
セキュリティ要件
システムがどの程度安全であるかを示す要件です。たとえば、外部からの不正アクセスを防ぐことや、データを暗号化して保護することが含まれます。
保守性要件
システムのメンテナンスや修正がどれだけ簡単に行えるかを定義します。将来のバグ修正や機能追加に対応しやすい設計が求められます。
移植性要件
システムが異なる環境（例えば、別のOSやサーバー）に移行しても問題なく動作するかどうかを示す要件です。
機能要件と非機能要件の違い
このセクションでは、機能要件と非機能要件の違いを再度、確認します。機能要件は「ユーザーがシステムで何ができるか」を定義するのに対し、非機能要件は「システムがユーザーにとってどのように良いか」という点に焦点を当てています。以下に例を挙げます。
例えば、ログイン機能を例にすると、機能要件では「ユーザーがログインできる」という具体的な動作を定義しますが、非機能要件では「ユーザーが1秒以内にログインできる」「ログインが常に安全である」など、パフォーマンスやセキュリティに関する要件を定義します。
ログイン機能の例
・機能要件＝「ユーザーがログインできること」
・非機能要件＝「ユーザーが1秒以内にログインできること」（性能要件）、「ログインが常に安全であること」（セキュリティ要件）
非機能要件の考慮不足によるリスク
このセクションで、機能要件の考慮不足により、どのような問題を引き起こす可能性があるか、について確認しておきましょう。
性能要件の考慮不足
ユーザーがシステムの操作に対して反応が鈍いと感じることにより、そのサービスから離れてしまう可能性がある。
信頼性要件の考慮不足システム
信頼性要件が不十分であったため、システムが頻繁にダウンし業務に支障をきたす。
信頼性要件の考慮不足システム
信頼性要件が不十分であったため、システムが頻繁にダウンし業務に支障をきたす。
非機能要件を明確に定義するための流れ
このセクションでは、非機能要件を定義するための具体的な流れをSTEPに沿って解説します。
STEP1：プロジェクトの目的と範囲を理解する
プロジェクトの目標やビジネスニーズを把握し、どのようなシステムやサービスが提供されるか、また、システム化の範囲について明確にします。
STEP2：ステークホルダーにヒアリングを実施する
ステークホルダー（ユーザーや開発チームなど）からのニーズを収集します。ユーザーに対してはヒアリングを実施し、非機能要件に関連する期待や懸念事項を把握していきます。
STEP3：非機能要件の項目を定義し、項目ごとに考慮する
性能、信頼性、可用性、セキュリティ、拡張性などの非機能要件の項目を定義し、項目ごとに具体的な要件を考慮していきます。この時、ISO25010やIPA非機能要求グレードなどのフレームワークを活用すると抜け漏れが少なくなります。
STEP4：各非機能要件に対し、具体的な数値目標を設定する
各非機能要件に対して、可能な限り測定可能な数値目標を設定していきます。
例：レスポンスタイム2秒以内、稼働率99.9%以上など。
STEP5：非機能要件の優先順位付けを行う
非機能要件が満たされない場合のリスクを評価し、優先順位付けを行います。評価する際は特に、影響を受けるビジネスプロセスやユーザーへの影響度を考慮します。
STEP6：非機能要件をドキュメントに起こす
定義した非機能要件をドキュメント化し、明確で理解しやすい形式にまとめます。この時、テンプレートがあれば非常に便利です。
▲図１：非機能要件（サンプル）
https://www.ipa.go.jp/archive/files/000072715.pdf
P.65（1）共有基盤の項目例（データセンタあり、ネットワーク構築済）より抜粋
非機能要件の様々なフレームワーク
このセクションでは、非機能要件に関する国際標準や国内基準のフレームワークについて、わかりやすい説明を加えながら３つご紹介します。
非機能要件の抜け漏れを防止するためには、これらのフレームワークを導入するのが一番の近道となりますので、よく内容をご確認ください。また、実際のプロジェクトへの導入については、開発対象の製品やサービスの特性を考慮したうえで、最適な基準を選択するようにしてください。
ソフトウェア品質特性（ISO/IEC25010）（※機能適合性以外）
| 品質特性 | 品質副特性 | 説明 |
|---|---|---|
| 性能効率性 | 時間効率性 | 素早く動くかどうか |
| 資源効率性 | コンピュータのメモリや電力を無駄なく使っているかどうか | |
| 容量満足性 | 処理できるデータの量や、同時に何人まで使えるかどうか | |
| 互換性 | 共存性 | 他のシステムと一緒に使えるかどうか |
| 相互運用性 | 他のシステムと問題なくデータをやり取りできるかどうか | |
| 使用性 | 適切度認識性 | どう使うかをすぐに理解できるかどうか |
| 習得性 | 使い方を簡単に覚えられるかどうか | |
| 運用操作性 | 簡単に操作できるかどうか | |
| ユーザーエラー防止性 | 間違った操作をしにくい作りになっているかどうか | |
| ユーザーインタフェース快美性 | 画面が見やすく、使いやすくデザインされているかどうか | |
| アクセシビリティ | 高齢者や障害者でも使いやすい作りになっているかどうか | |
| 信頼性 | 成熟性 | エラーを起こさず安定して動くかどうか |
| 可用性 | 必要なときにちゃんと使えるかどうか | |
| 障害許容性 | 多少の問題があっても動き続けられるかどうか | |
| 回復性 | トラブルがあったときにすぐに回復できるかどうか | |
| セキュリティ | 機密性 | 不正にデータを見られたりしないように守られているかどうか |
| インテグリティ | データが間違えたり壊れたりしないように守られているかどうか | |
| 否認防止性 | データの送信者やアクションを実行した人が、あとで「自分ではやっていない」と言えないように記録が残せるかどうか | |
| 責任追跡性 | 誰がどの操作を行ったか追跡できるかどうか | |
| 真正性 | データやメッセージが、正しい人やシステムから送られたものか確認できるかどうか | |
| 保守性 | モジュール性 | 機能が小さな部分（モジュール）に分かれていて、それぞれ個別に作りやすいかどうか |
| 再利用性 | 一度作った部品やコードを、他のプロジェクトや別の場面で再利用できるかどうか | |
| 解析性 | 問題が起きたときに、原因をすぐに調べられるかどうか | |
| 修正性 | 新しい機能を追加したり、問題を直したりするのが簡単にできるかどうか | |
| 試験性 | テストしやすいか、またテスト中に問題を見つけやすいかどうか | |
| 移植性 | 適応性 | 新しいシステムに変わっても、ソフトウェアが問題なく使えるかどうか |
| 設置性 | ソフトウェアを簡単にインストールできるかどうか | |
| 置換性 | 他のソフトと入れ替えやすいかどうか |
非機能要求グレード（IPA）
| 大項目 | 説明 | 特徴 |
|---|---|---|
| 可用性 | システムがどれだけ長い時間、問題なく動作し続けるかどうか。サーバーが止まらずに使い続けられる時間の長さを表す。 | 稼働率 |
| 目標復旧水準 | ||
| 大規模災害 | ||
| 性能・拡張性 | システムがどれだけ早く動作するか、また利用者が増えたときに問題なく対応できるかどうか。たとえば、サイトがアクセスの増加に耐えられるかなど。 | 性能目標 |
| 拡張性 | ||
| 運用・保守性 | システムが安定して運用され、問題が起きたときにどれだけ簡単に修正や改善ができるかどうか。エラーが出ても素早く対応できるかが重要。 | 運用時間 |
| バックアップ | ||
| 運用監視 | ||
| マニュアル | ||
| メンテナンス | ||
| 移行性 | システムやデータを他のシステムに移したり、バージョンアップしたりするときに、どれだけスムーズに進められるかどうか。 | 移行方式の規模 |
| 移行スケジュール | ||
| 設備・データ | ||
| セキュリティ | システムが不正アクセスやデータの盗難からどれだけ守られているかどうか。利用者のデータを安全に保つための仕組みが重要。 | 重要資産の公開範囲 |
| システム環境・エコロジー | システムがどれだけ省エネで、環境に優しいかどうか。コンピュータやサーバーのエネルギー消費を減らし、環境への負荷を少なくすることが求められる。 | 制限 |
| 耐震 |
デジタル・ガバメント推進標準ガイドライン実践ガイドブック（デジタル庁）（※中分類は代表的なもののみピックアップしています）
| 大分類 | 中分類 | 説明 |
|---|---|---|
| ユーザビリティ及びアクセシビリティに関する事項 | ユーザビリティ | システムが使いやすく、直感的に操作できること |
| アクセシビリティ | 障害を持つユーザーが利用できるように、音声、視覚、運動のサポートがあること | |
| システム方式に関する事項 | アーキテクチャ | システムの全体的な設計方針や構成要素の相互関係が明確であること |
| プラットフォーム互換性 | 異なるOSやデバイスでの動作が保証されていること | |
| API設計 | 外部システムとの連携を容易にするためのAPI設計がなされていること | |
| 規模に関する事項 | ユーザー数 | システムを利用するユーザーの総数が明確に定義されていること |
| ユーザーの成長を見越したスケーラビリティが考慮されていること | ||
| データ量 | システムが処理するデータの量や種類が明確に定義されていること | |
| データ量に基づいてストレージやデータベースの設計が行われていること | ||
| データ量の増加に対応できるような拡張性が考慮されていること | ||
| 性能に関する事項 | レスポンスタイム | ユーザーからのリクエストに対する応答が行われるまでの時間が明確に定義されていること |
| ターンアラウンドタイム | リクエストから完了までの全体的な処理時間が定義されていること | |
| サーバー処理時間 | サーバーがリクエストを受け取ってから応答を返すまでの時間が明確に設定されていること | |
| リソースの最適化や負荷分散が適切に行われていること | ||
| 信頼性に関する事項 | 平均故障間隔 | システムが正常に稼働する平均的な時間間隔が明確に定義されていること |
| 障害目標復旧水準 | 障害発生時に求められる復旧水準（例：99.5%の復旧率）が設定されていること | |
| 拡張性に関する事項 | 機能追加の容易さ | 新しい機能の追加が容易に行える設計であること |
| 技術的な拡張 | 新技術の導入が容易であること | |
| 上位互換性に関する事項 | バージョン管理 | 新しいバージョンへの移行が容易であること |
| 上位互換性 | 過去のデータや機能との互換性が保たれていること | |
| 中立性に関する事項 | プラットフォーム中立性 | 特定のプラットフォームに依存せず、広く利用可能であること |
| 標準準拠 | 業界標準や規格に準拠していること | |
| 継続性に関する事項 | 稼働率 | システム稼働率の目標が設定されていること |
| 目標復旧時点 | 障害発生後にシステムをどの時点に復旧させるかの目標が明確に定義されていること | |
| 目標復旧時間 | 障害発生から復旧までの時間（例：30分以内）の目標が設定されていること | |
| 情報セキュリティに関する事項 | データ保護 | 機密情報の暗号化やアクセス制御が実施されていること |
| 主体認証 | ユーザーやシステムの認証方法（パスワード、生体認証、二要素認証など）が明確に定義されていること | |
| アクセス制御 | ユーザー権限に基づいてアクセスが制限されていること | |
| ログ取得及びログ管理 | システムイベントやユーザーアクティビティのログ取得が実施されていること | |
| ログの保存期間や管理手順が明確にされていること | ||
| 不正アクセスや異常を検知するためのログ分析が定期的に行われること | ||
| 情報システム稼働環境に関する事項 | クラウドサービスの構成 | 使用するクラウドサービスの種類（IaaS、PaaS、SaaS）と構成が明確に定義されていること |
| クラウド環境のセキュリティ要件が設定されていること | ||
| サービスレベルアグリーメント（SLA）が確立されていること | ||
| ハードウェアの構成 | 使用するサーバー、ストレージ、バックアップ装置などの構成が明確にされていること | |
| ハードウェアの性能要件（CPU、メモリ、ディスク容量など）が設定されていること | ||
| 冗長構成や耐障害性の計画が整備されていること | ||
| ソフトウェア製品の構成 | 使用するソフトウェア製品やライセンスの要件が明確にされていること | |
| ソフトウェアのバージョン管理や互換性が考慮されていること | ||
| 必要なミドルウェアやサポートツールの構成が定義されていること | ||
| ネットワークの構成 | ネットワークトポロジーや通信プロトコルが明確に定義されていること | |
| 帯域幅、遅延、冗長化の要件が設定されていること | ||
| ネットワークセキュリティ対策（ファイアウォール、VPNなど）が実施されていること | ||
| 施設・設備要件 | システム稼働に必要な物理的施設（データセンターなど）の要件が明確にされていること | |
| 電源供給や冷却システムの要件が設定されていること | ||
| 設備のセキュリティ対策（アクセス制御、監視カメラなど）が実施されていること | ||
| テストに関する事項 | テスト内容 | 実施するテストの種類（単体テスト、結合テスト、システムテスト等）が明確に定義されていること |
| 各テストの目的や範囲が具体的に示されていること | ||
| テスト方法 | テストの実施方法（手動テスト、自動テストなど）が定義されていること | |
| テスト結果の評価基準が明確に設定されていること | ||
| テスト環境 | テストを実施するための環境が整備されていること（ハードウェア、ソフトウェア、ネットワーク等） | |
| 環境設定やデータ準備に関する手順が明確であること | ||
| 移行に関する事項 | データ移行 | 旧システムから新システムへのデータ移行手順が明確に定義されていること |
| データの正確性と完全性が確保されるための検証プロセスが存在すること | ||
| 移行後のデータの整合性が確認されていること | ||
| システム移行 | 旧システムから新システムへの移行手順が文書化されていること | |
| 移行作業に伴うリスクが評価され、対策が講じられていること | ||
| 移行後のシステムが正常に稼働することを確認するためのテストが行われること | ||
| 業務運用移行 | 業務プロセスや手順が新システムに適応されるように調整されていること | |
| 引継ぎに関する事項 | 運用開始時 | 新システムの運用に必要な知識や手順が全関係者に共有されていること |
| システムの基本的な機能や操作方法に関するトレーニングが実施されること | ||
| 運用に必要なドキュメントや資料が整備されていること | ||
| 運用事業者交代時 | 交代する事業者に対して、運用手順やポリシーが適切に引き継がれること | |
| 重要な連絡先やサポート体制が明確にされていること | ||
| 既存の課題や改善点が文書化され、次期事業者に共有されること | ||
| 次期更改時 | システム更改に向けた計画が早期に策定されていること | |
| 現行システムの運用データや実績が新システムに引き継がれること | ||
| 次期運用のための教育やトレーニングが計画されていること | ||
| 教育に関する事項 | ユーザートレーニング | システム利用者向けのトレーニングプログラムが存在すること |
| 管理者トレーニング | システム管理者向けの専門的なトレーニングが提供されること | |
| 定期的な教育プログラム | 定期的なアップデートや新機能に関する教育が実施されること | |
| 運用に関する事項 | 運用要件 | システムの稼働に必要な条件やリソースが明確に定義されていること |
| 定期的なシステムチェックや運用管理が計画されていること | ||
| 運転管理・監視等要件 | システムの稼働状況をリアルタイムで監視する体制が整っていること | |
| 異常検知やアラート通知が適切に行われること | ||
| 運用サポート業務 | 問題発生時の対応手順が明確で、適切に実施されること | |
| 業務運用支援 | 業務プロセスに対する技術的な支援が提供されること | |
| 業務効率化のためのツールやプロセスが整備されていること | ||
| システムの利用状況を把握し、改善提案が行われること | ||
| 保守に関する事項 | アプリケーションプログラムの保守要件 | アプリケーションのバグ修正や機能改修が迅速に行われること |
| ハードウェアの保守要件 | ハードウェアの故障に対して迅速な修理や交換が可能であること | |
| ソフトウェア製品の保守要件 | セキュリティパッチやアップデートが迅速に適用されること | |
| 技術的なサポートが提供され、ユーザーの問い合わせに対応できること |
https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/2d9df6c5/20220509_resources_standard_guidelines_guideline_05.pdf P.207～
非機能要件に関するよくある質問 (FAQ)
このセクションでは、本記事で記載しきれなかった非機能要件に関する事柄について、Q＆A形式で回答していきます。なお、この質問は、実際のコンサルティングのなかで、クライアントからよく頂戴する質問をまとめたものでもあります。
Q：非機能要件はどうやって計測しますか？
A：パフォーマンス要件や信頼性要件などは、具体的な数値目標を設定し、それに基づいて定期的にモニタリングすることで計測できます。
［パフォーマンス要件の目標例］
・レスポンスタイム：ユーザーのリクエストに対する応答が２秒以内であること
・スループット：１秒間に100件のトランザクションを処理すること
［信頼性要件の目標例］
・稼働率：サービスの稼働率が99.9％以上であること
・障害復旧時間：障害発生から復旧までの時間が30分以内であること
Q：小規模なプロジェクトでも非機能要件は重要ですか？
A：はい。小規模でも非機能要件は重要です。どのようなシステムでも、ユーザーの期待に応え、長期的に信頼されるためには、適切なパフォーマンスと信頼性が必要です。
Q：非機能要件を満たすためにどのようなテストが必要ですか？
A：パフォーマンステスト、負荷テスト、ストレステスト、セキュリティテストなどが必要となります。これらのテストにより、システムが非機能要件を満たしているかどうかを確認できます。ちなみにこの類のテストはシステムテストフェーズで実施する場合が多いです。
Q：どのようにして非機能要件の優先順位を決めるべきですか？
A：プロジェクトの目的からビジネスへの影響度を評価して決める方法と、ユーザーのニーズから狩野モデルを活用して決める方法の2通りがあります。ビジネスへの影響度が高い要件であること、あるいはユーザーが必須と考えている要件であることを確認しながら、実際の優先順位を決めていきます。
Q：顧客が非機能要件を明確に示さない場合、どうすればよいですか？
A：顧客とコミュニケーションを取り、非機能要件の重要性を説明することが第一歩です。具体的な例や過去のプロジェクトでの影響を示すことで、理解を促進していくことも重要です。
Q：顧客から非機能要件を引き出すためには、どのような質問をすればよいですか？
A：以下のような、具体的な質問が有効です。
・「どの程度の応答時間でしたら許容されますか？」
・「システムのダウンタイムについて、どのくらいの時間が許されますか？」
・「データセキュリティに関する特別な要求はありますか？」
Q：非機能要件を後から追加することはできますか？
A：可能ですが、後から追加した場合はプロジェクトが進行した分の手戻りが発生しますので、プロジェクトの進行やコストに影響する恐れがあります。
非機能要件は、最初の要件定義の段階でしっかりと確実に定義しておくことが重要となります。
さらに詳しく知りたい方へ
要件定義についての記事を複数アップしていますのでご紹介します。それぞれの目的に合わせて必要とする時にご一読いただければ幸いです。
▼要件定義で定義する３つの要件（業務要件・機能要件・非機能要件）を体系的かつ網羅的に解説したブログ
▼要件定義の成果物に焦点を当て、例を挙げながら特に書き方についての詳細を解説したブログ
▼要件定義の要件の不備について詳しく解説したブログ
▼要件定義をサラッと復習したいときに読むブログ
▼要件定義の前フェーズで定義する要求定義について網羅的に解説したブログ
まとめ
非機能要件は、システムの性能、信頼性、セキュリティなどに関わる重要な要素であり、ユーザー体験やシステム運用に大きな影響を与えるものです。これらの要件が明確に定義されていない場合、システムはユーザーの期待に応えられず、結果としてプロジェクト全体に大きなリスクが及ぶ可能性があります。この点はご理解頂けたことと思います。
また、顧客が非機能要件を明確に示さない（示せない）理由には、理解不足やその重要性が軽視される傾向を挙げ、この問題の解決に向けては、「顧客を理解したうえで、顧客に対して開発側から非機能要件の重要性をわかりやすく説明し、具体的な項目を提示すること」が、もっとも効果的な進め方となることも、お伝えしてきたとおりです。
さらに、非機能要件を抽出するためのフレームワークや、明確に定義するための具体的な流れを取り入れることで、プロジェクトの成功確率を高めることができること、また、最後のFAQのセクションを通じて、一般的な疑問を解消するなかで、非機能要件に対する理解をより深めていただけたのではないかと思います。
結論、非機能要件はシステム全体の品質を左右するものであるため、堅実な要件定義とその実装が求められます。今後のプロジェクトにおいて、ここまで本記事でお伝えしてきたことをご活用いただき、今まで以上に非機能要件を考慮し確実に抽出することで、より高品質なシステム構築を目指していただければと思います。
QualityCubeでは、最上流の企画/要求定義工程から下流のテスト工程まで、プロダクト分析とプロセス分析による現状分析や品質コンサルティング、更にはDXコンサルティングも行っております。開発製品やサービスの品質向上や品質改善、その他DXに関することでご課題やご検討中のことがございましたら、ぜひお気軽にご相談ください。
ご相談は無料で承っております！
要件定義代行支援サービスは、こんな課題をお持ちの方をサポートします！
・要件定義工程の外注を検討している
・要件定義のできる経験者のリソースが不足している
・要件定義がうまくいっていないと感じている
・要件定義の担当者が少ないため、プロジェクト受注を断念するケースがある
なお、ブログの最新リリース情報につきましては、当社メルマガでリアルタイムにご確認いただけますので、本記事がよかった、ためになった、という方はぜひ、メルマガ登録もお願いします。
最新IT情報やお役立ち情報をコンサルタントが配信中！
