非機能要件とは何か
まず簡単に整理しておく。
- 機能要件：システムが「何をするか」。ユーザー登録ができる、商品を検索できる、など。
- 非機能要件：システムが「どのように動くか」。速さ、安定性、セキュリティ、保守のしやすさ、など。
機能要件はユーザーストーリーやユースケースで可視化されやすい。一方、非機能要件は暗黙の前提として扱われがちで、 誰も明示的に定義しないまま開発が進むことが多い。
以下では4つのカテゴリごとに「定義すべきこと」と「定義しなかった場合に何が起きるか」をセットで解説する。
1. 性能・スケーラビリティ
性能要件は数値で定義しなければ意味がない。「なるべく速く」は要件ではない。
| 項目 | 定義内容 | 定義例 |
|---|---|---|
| レスポンスタイム | 何パーセンタイルで何秒以内か | 95%ile < 2秒 |
| スループット | 1秒あたりの処理リクエスト数 | 500 req/s |
| 同時接続数 | ピーク時の想定同時ユーザー数 | 1,000接続 |
| スケーリング戦略 | 負荷増大時の対応方針 | 水平スケール・オートスケーリング有効 |
💡 平均値ではなくパーセンタイルで定義する
レスポンスタイムは「平均値」ではなく 95%ile・99%ile で定義することが重要だ。平均は外れ値に引きずられ、実態を隠す。遅いリクエストに苦しむユーザーは平均値の中に埋もれる。
❌ 定義しなかった場合
リリース当日、同時アクセスが集中した結果、レスポンスタイムが30秒を超えた。開発中はローカル環境やステージング環境で数人しかアクセスしておらず、誰も問題に気づかなかった。
「どの程度の負荷に耐えるか」を誰も定義していなかった。開発者はベストエフォートで実装し、テストは機能の正しさだけを確認した。リリース後のリアーキテクチャに数ヶ月を要した。
2. 可用性・信頼性
可用性要件を定義すると、自ずとインフラ構成やバックアップ戦略が決まる。逆に言えば、定義しない限りアーキテクチャの判断基準がない。
| 項目 | 定義内容 | 定義例 |
|---|---|---|
| SLA（稼働率） | 月間・年間の目標稼働率 | 99.9%（月間ダウンタイム約44分） |
| RTO | 障害発生から復旧までの目標時間 | 4時間以内 |
| RPO | 許容できる最大データ損失期間 | 1時間分 |
| 障害時の挙動 | フェイルオーバー有無・メンテナンス画面の扱い | 自動フェイルオーバー・障害画面を表示 |
| 障害対応フロー | 連絡先・エスカレーション経路 | オンコール担当 → チームリーダー → CTO |
❌ 定義しなかった場合
深夜にDBサーバーが落ちた。障害対応の手順が存在せず、誰に連絡すればいいかも明確でなかった。復旧に6時間かかり、その間ユーザーへの告知もできなかった。
「障害が起きたときにどうするか」を事前に決めていなかった。可用性の目標も、許容できるダウンタイムも、誰も考えていなかった。障害が起きてから初めて「どうするか」を考えることになった。
3. セキュリティ
セキュリティは後付けで強化するほどコストが高くなる。設計時に組み込むのが原則だ。
| 項目 | 定義内容 | 定義例 |
|---|---|---|
| 認証・認可 | 認証方式・アクセス制御の粒度 | OAuth 2.0・ロールベースアクセス制御 |
| データ暗号化 | 保存時・転送時の暗号化要件 | TLS 1.3以上・DBの機密カラムは暗号化 |
| ログ要件 | 監査ログの対象操作・保存期間 | 認証・データ変更操作を90日間保存 |
| 脆弱性対応 | ライブラリ更新頻度・診断の実施有無 | 月次でDependabot確認・年1回ペネトレーションテスト |
| 法令・コンプライアンス | 適用される法規制 | 個人情報保護法・GDPR対象の場合はデータ処理記録が必要 |
❌ 定義しなかった場合
リリースから半年後、外部からの脆弱性報告でSQLインジェクションが発覚した。ログが不十分で影響範囲の特定に数週間かかった。対応コストは開発初期に対策していた場合の10倍以上になった。
「どのレベルのセキュリティ対策が必要か」を誰も定義していなかった。開発者各自の判断に委ねられ、統一した基準がなかった。
4. 運用・保守性
運用要件は開発チームだけでなく、インフラ・SRE・運用チームを巻き込んで定義する必要がある。
| 項目 | 定義内容 | 定義例 |
|---|---|---|
| ログ出力 | 出力するログの種類・フォーマット・保存期間 | JSON形式・ERROR以上は即時アラート・30日保存 |
| 監視・アラート | 監視対象メトリクス・閾値と通知先 | CPU 80%超・エラーレート1%超でSlack通知 |
| デプロイ要件 | デプロイ頻度・ダウンタイムの許容有無 | ゼロダウンタイムデプロイ必須・週次リリース |
| 設定変更 | 設定変更に再デプロイが必要か | 機能フラグで再デプロイ不要にする |
| バックアップ | バックアップ頻度・リストア手順の整備 | 日次フルバックアップ・手順書あり |
❌ 定義しなかった場合
本番環境でエラーが頻発しているのに、誰も気づかなかった。アプリケーションログはあったが、監視ツールが設定されておらず、ユーザーからの問い合わせで初めて発覚した。
「誰が・何を・どう監視するか」を定めていなかった。ログの出力形式も統一されておらず、調査に時間がかかった。問題に「気づく仕組み」がなかったことが根本原因だった。
なぜ非機能要件は後回しにされるのか
4つの失敗パターンに共通する構造がある。
- 見えない：機能要件と違い、非機能要件は画面に現れない
- 測りにくい：「安定性」「使いやすさ」は数値化しないと曖昧なまま残る
- ステークホルダーが関心を持ちにくい：発注者は機能の話をしたがる
- 後でなんとかなると思いがち：実際にはなんとかならないことが多い
これらは構造的な問題であり、「次は気をつけよう」では解決しない。 プロセスとして組み込み、チェックリストで確認する習慣が必要だ。
定義のタイミング
非機能要件は要件定義フェーズで機能要件と並行して定義するのが原則だ。アジャイル開発でも「後で決める」は「永遠に決まらない」になりやすいため、意図的にイテレーションに組み込む必要がある。
| フェーズ | 定義すべき要件 |
|---|---|
| 要件定義〜設計 | セキュリティ・コンプライアンス・可用性の目標値 |
| MVPリリース前 | 性能要件の数値化・負荷テストの実施 |
| ステージング環境構築時 | 監視・ログ・アラート設定・デプロイ要件 |
定義するときのチェックリスト
最低限、以下の項目を埋めることを推奨する。
| カテゴリ | 定義すべき内容 | 数値化の例 |
|---|---|---|
| 性能 | レスポンスタイム・同時接続数 | 95%ile < 2秒、同時1,000接続 |
| 可用性 | 稼働率・RTO・RPO | 99.9%、RTO 4時間、RPO 1時間 |
| セキュリティ | 認証方式・暗号化・ログ | OAuth2.0・TLS1.3以上・90日保存 |
| 保守性 | デプロイ方式・監視 | ゼロダウンタイム・P1は15分以内にアラート |
| コンプライアンス | 適用法規・データ保管場所 | 個人情報は国内サーバーのみ |
まとめ
非機能要件は「動く」システムを「使えるシステム」に変えるための定義だ。
定義しないと起きること：
- 性能要件なし → リリース後にリアーキテクチャ
- 可用性要件なし → 障害対応がアドホックになる
- セキュリティ要件なし → 対応コストが後になるほど膨らむ
- 運用要件なし → 問題に気づけない
いずれも、「後から直せばいい」では済まない規模の問題になりうる。 非機能要件の定義は地味だが、システムの品質を左右する根幹の作業だ。 機能要件と同じ重さで扱う習慣を持ちたい。
✅ 関連記事
要件定義フェーズの他のドキュメントについては 業務フロー整理ドキュメントの書き方 も参照してほしい。