こんにちは、新卒エンジニアの鈴木です。
開発に慣れてくると、「機能要件」という言葉はすぐに馴染みます。ログイン機能・検索機能・投稿機能など、画面に現れる機能の一覧として直感的にイメージできます。
ところが、案件でインフラ構成の話になったときに「何を決めればいいのかわからない」という状態に陥りました。
どんなサーバーを使うか、どう冗長化するか、バックアップはどうするか……何から手をつければいいかよくわからないまま、話だけが進んでいく。そのときに整理のきっかけになったのが「非機能要件」という概念です。
この記事では、非機能要件とは何か、どんな項目があるのかを解説します。
目次
非機能要件とは
非機能要件とは、システムが「どうあるべきか」を定義するものです。システムが「何をするか」を決めるのが機能要件なので、ざっくり言うとそれ以外のことですね。
具体的にはシステムの品質・制約などの前提条件です。どれだけ速く動くか、どれくらいサービスが停止せずに動き続けるか、不正アクセスをどう防ぐか……などなど。こういった「動き方」や「あり方」に関わる要件をまとめて非機能要件と呼びます。
| 機能要件 | 非機能要件 | |
|---|---|---|
| 定義 | システムが「何をするか」 | システムが「どうあるべきか」 |
| 具体例 | ログイン機能、検索機能など | 稼働率、レスポンス速度、セキュリティなど |
| 見えやすさ | 画面に現れる | 設計・インフラに隠れがち |
機能要件は画面に現れるので、開発中に「あ、これ足りない」と気づきやすいです。しかし一方で、非機能要件は「そういえば決めてなかった」となりやすく、後から変えようとすると設計やインフラごと見直す羽目になることもあります。
非機能要件はインフラ選定や技術選定に直結するため、後回しにすればするほど手戻りのリスクが上がります。可用性の要件が決まればサーバー構成が見えてきますし、セキュリティ要件が決まれば認証の設計方針が変わります。「追加しようとしたら設計ごと変えることになった」という事態を避けるためにも、早い段階から意識しておくことが大切です。
6つの項目で整理する
非機能要件の整理には、IPA（独立行政法人情報処理推進機構）が公開している非機能要求グレードが参考になります。システムに求められる非機能要件を6つの大項目に分類していて、整理の出発点として使いやすいです。それぞれ解説していきます。
▼IPA非機能要求グレード6大項目
出典：IPA「非機能要求グレード」を参考に筆者作成
まず全体像を把握しておくと、6つの項目はこのように分かれています。可用性・性能拡張性はシステムの「動き方」、運用保守性・移行性は「育て方」、セキュリティ・システム環境はシステムの「前提条件」というイメージで捉えると整理しやすいです。
① 可用性
システムがどれだけ止まらずに動き続けられるか、障害が起きたときにどれだけ早く復旧できるかを定義します。特にビジネスへの影響が大きいシステムでは、1分の停止が売上損失に直結することもあるため、要件を数値で明確にしておくことが重要です。
IPAでは可用性の中項目として、以下のようなものがあります。
| 継続性 | 「システムをどれだけ止めずに動かし続けるか」を決める項目です。稼働率の目標や、障害が起きたときにどこまで業務を続けられるかを具体的に定めます。 |
|---|---|
| 耐障害性 | 一部が壊れても全体が止まらないようにするための設計方針です。冗長化（2台構成など）や自動切り替えでリスクを分散させます。 |
| 回復性 | 障害が起きたあと、何時間以内に復旧するか（RTO）、どの時点のデータまで戻せるか（RPO）といった目標を設定します。 |
| 災害対策 | 地震や大規模障害など、通常の障害対応では対処しきれない事態に備える項目です。 |
- 具体例
- 「稼働率99.9%」は年間約8.7時間の停止が許容される計算になります。ECサイトであれば、停止中の売上損失も試算したうえで要件を決めることになります。
② 性能・拡張性
システムがどれだけ速く動けるか、どれだけ多くのユーザーを同時にさばけるかを定義します。将来的なアクセス増加に対してサーバーを増やして対応できる設計になっているかも含みます。「とりあえず動けばいい」で作ると、ユーザーが増えたタイミングで見直す羽目になりがちです。
IPAでは性能・拡張性の中項目として、以下のようなものがあります。
| 業務処理量 | システムが想定するユーザー数・アクセス数・データ量などの前提条件を決める項目です。ピーク時の負荷を想定して定義し、ハードウェア選定やアーキテクチャ設計、性能テストの基準として利用されます。 |
|---|---|
| 性能目標値 | システムが快適に動作するための基準です。「ページは3秒以内に表示する」「1秒あたり何件の処理をこなす」といった形で具体的に数値目標を決めます。 |
| リソース拡張性 | ユーザー数やデータ量の増加に対し、CPU/メモリ/ディスク等のハードウェア資源を円滑に増強できる能力のことです。 |
| 性能品質保全性 | 長期運用においても安定したパフォーマンスを保つための品質を担保する項目です。帯域の確保や突発的なアクセス急増への対応方針、定期的な性能テストの実施有無などを決めます。 |
- 具体例
- 「ページの表示は3秒以内」「同時に100人がアクセスしても落ちない」といった数値で定義します。キャンペーン時など突発的なアクセス増加を想定しておかないと、本番でサーバーが落ちることになります。
③ 運用・保守性
システムをリリースした後、どうやって安全に運用し続けるかを定義します。障害をいち早く検知できる監視の仕組みや、修正・デプロイを安全に行える手順の整備、ログの出力設計などが含まれます。
「動いているけど何が起きているかわからない」という状態で本番運用に入ると、障害発生時に原因特定だけで時間を大量に消費することになります。
IPAでは運用・保守性の中項目として、以下のようなものがあります。
| 通常運用 | 監視・バックアップ・時刻同期など、日常的な運用作業の方針を決める項目です。 |
|---|---|
| 保守・点検 | OSやソフトウェアのアップデート・パッチ適用など、定期的なメンテナンスの方針を決める項目です。計画停止の頻度や保守作業の自動化範囲も含みます。 |
| 障害時運用 | 問題が起きたときの検知・対応・復旧のフローを整備する項目です。「誰が対応するか」「どう復旧するか」「予備機はあるか」といった取り決めを事前にしておきます。 |
| 運用環境 | 監視システム・ジョブ管理・テスト環境の有無、リモート操作の範囲など、運用に必要なツールや環境を整備する項目です。 |
| サポート体制 | 保守担当者がどのような体制で対応するかを決める項目です。対応時間帯・保守契約の範囲なども含みます。 |
| その他の運用管理方針 | インシデント管理・変更管理・リリース管理など、運用全般に関わる管理プロセスを定める項目です。 |
- 具体例
- エラーが発生したときにログを見ればすぐ原因がわかる状態になっているか、が重要です。適切なログ設計がないと、障害対応がほぼ手探りになります。
④ 移行性
稼働環境やシステム基盤を移行するとき、データや業務を安全に引き継げるかを定義します。オンプレからクラウドへの移行や、サーバー構成の刷新など、インフラごと移す場面が主な対象です。
IPAでは移行性の中項目として、以下のようなものがあります。
| 移行時期 | いつ移行を実施するかのスケジュールを決める項目です。システムをいつから止められるか、並行稼働期間をどのくらい設けるかも含みます。 |
|---|---|
| 移行計画 | 移行をどう進めるかの体制・役割分担・リハーサルの方針を決める項目です。トラブル発生時の対処ルールも事前に定めておきます。 |
| 移行方式 | 一括で切り替えるか、段階的に移すかなど、移行の進め方を選択する項目です。拠点ごと・業務ごとに分けて展開するかどうかもここで決めます。 |
| 移行対象（機器） | どの機器を新環境に移すか、廃棄するかを整理する項目です。 |
| 移行対象（データ） | 移行するデータの量・形式・変換方法を定める項目です。旧システムのデータをそのまま使えない場合の変換方法もここで決めます。 |
- 具体例
- 旧システムのDBをそのまま新システムで使えるか、使えない場合はどう変換するか、切り替え当日にどのくらい止めていいか。こういった点を事前に合意しておく必要があります。
⑤ セキュリティ
不正アクセスや情報漏えいを防ぎ、利用者ごとに適切な権限を管理できるかを定義します。認証・認可の設計から、通信の暗号化、脆弱性対策、ログ監査まで幅広い観点を含みます。
IPAではセキュリティの中項目として、以下のようなものがあります。
| 前提条件・制約条件 | 社内規程や法令など、セキュリティ対策の前提となるルールを整理する項目です。守るべきコンプライアンスを明確にしたうえで対策を設計します。 |
|---|---|
| セキュリティリスク分析 | システムにどんなリスクがあるかを洗い出し、「何が脅威か」「どのくらいの影響があるか」を評価して対策の優先度を決める項目です。 |
| セキュリティ診断 | 実際にネットワークやWebアプリの診断を行い、脆弱性がないかを確認する項目です。診断の実施有無と対象範囲を決めます。 |
| セキュリティリスク管理 | 運用開始後もリスクを定期的に見直し、パッチを適切に当て続ける方針を決める項目です。新たな脅威への対応の仕組みも整えます。 |
| アクセス・利用制限 | 誰がどの機能を使えるかの権限管理と認証方法を決める項目です。「管理者だけが見られる画面」や「操作できる範囲の制限」を設計します。 |
| データの秘匿 | 保存・通信データの暗号化設計を決める項目です。「どのデータを暗号化するか」「鍵をどう管理するか」を定めます。 |
| 不正追跡・監視 | 不正アクセスや操作を検知・記録し、後から追跡できる仕組みを設計する項目です。「誰がいつ何をしたか」のログの取り方・保管期間を決めます。 |
| ネットワーク対策 | 不正な通信の検知・遮断など、ネットワーク側の対策を決める項目です。通信制御のルールやDDoS攻撃への対策も含まれます。 |
| マルウェア対策 | ウイルスなどの悪意あるソフトウェアへの対策方針を決める項目です。リアルタイムスキャンの実施有無や、定期的なフルスキャンのタイミングも含みます。 |
| Web対策 | 安全なコーディング規約の適用やWAFの導入有無など、Webアプリケーションの実装レベルでのセキュリティ対策を定める項目です。 |
| セキュリティインシデント対応/復旧 | セキュリティ事故が起きたときの対応体制と復旧手順を定める項目です。「誰が対応するか」「どう復旧するか」を事前に決めておくことで被害を最小限に抑えられます。 |
- 具体例
- 「管理者だけが見られるページ」「個人情報はどの経路で送受信するか」といった設計は、後から追加しようとすると構成ごと大きく変わることがあります。早い段階から設計に組み込んでおくことが重要です。
⑥ システム環境・エコロジー
システムをどの環境で動かすか、どんな技術的・物理的制約があるかを定義する項目です。クラウドかオンプレかといったインフラ構成の前提から、機器の設置環境や消費電力への配慮まで幅広い観点を含みます。
IPAではシステム環境・エコロジーの中項目として、以下のようなものがあります。
| システム制約/前提条件 | 社内規定・業界ガイドライン・法令・条例など、構築時および運用時の制約や前提条件を整理する項目です。 |
|---|---|
| システム特性 | ユーザー数・拠点数・対応言語など、システムの規模感や特性を定める項目です。 |
| 適合規格 | 製品安全・環境保護・電磁干渉など、システムが取得・準拠すべき規格を定める項目です。 |
| 機材設置環境条件 | 耐震・電源・温湿度・空調など、サーバー等の機材が正常に動くための設置環境を定める項目です。 |
| 環境マネージメント | 消費電力やCO2排出量など、システムの環境負荷を管理する項目です。グリーン購入法への対応や機材のライフサイクルを考慮した選定もここに含まれます。 |
- 具体例
- 「AWSを使っていいか、社内サーバーに置く必要があるか」「対応ブラウザにIEを含むか」といった制約が、技術選定に直接影響します。
より詳しく知りたい方へ：IPAの非機能要求グレード
非機能要求グレードは最終更新が2018年で、クラウドやCI/CDなど最近の技術領域については記述が薄い部分もあります。ただ、フレームワークとしての骨格はしっかりしているので、非機能要件の全体像を掴む入門資料としてはちょうどいい内容です。
今回紹介した6つの大項目の下には中項目35個・小項目118個・メトリクス238個まで細かく整理されているので、より詳しく知りたい方はぜひのぞいてみてください。
👉 参考：非機能要求グレード（IPA）
まとめ：機能要件とセットで、適切なレベルを設定しよう
非機能要件を定義するうえで押さえておきたいのは、機能要件と切り離して考えられないという点です。「どんな機能を持つシステムか」という方向性が見えていないと、稼働率の目標値も、求められる性能も、セキュリティの強度も決まりません。
まず機能要件の大枠を固めてから、非機能要件の検討に入るのが基本的な流れです。
また、システムの規模や用途によって基準が大きく変わります。社内の管理ツールと決済を扱うECサイトとでは、可用性やセキュリティに求められるレベルがまったく異なります。非機能要件は「高ければ高いほどいい」ではなく、システムの性質に合わせて適切なレベルを設定することが大切です。
機能要件とセットで、早い段階から意識してみてください。
最後までご覧いただき、ありがとうございました。
