非機能要件を後回しにして失敗するパターン
「何ができるか」の要件（機能要件）は議論されても、「どれくらいの品質で動くか」の要件（非機能要件）は後回しにされがちです。しかしここを疎かにすると、リリース後に深刻な問題が起きることがあります。
非機能要件とは何か
機能要件が「このシステムで何ができるか」を定義するのに対して、非機能要件は「どれくらいの品質・条件でそれが動くか」を定義するものです。
「在庫の一覧を表示できる」は機能要件です。「1万件の在庫データがあっても3秒以内に表示される」「1000人が同時にアクセスしても動作する」は非機能要件です。
機能が揃っていても、非機能要件を満たせなければ実務で使えないシステムになります。
よくある失敗パターン
パターン1：「遅い」でリリース後に炎上
本番環境でデータが増えた途端、画面の表示に30秒以上かかるようになった——というのは珍しくない事例です。
開発中のテスト環境では少量のデータしか入れていないため問題なく動きます。しかし本番で実際のデータ量になると、想定外の遅延が発生します。
これは要件定義の段階で「どれくらいのデータ量を想定するか」「どれくらいの速度が必要か」を決めておかなかった結果です。後から速度改善するには、システムの内部構造を見直す大規模な作業が必要になることがあります。
パターン2：同時接続でシステムが落ちる
月次の締め処理で全社員が一斉にシステムにアクセスしたら、応答しなくなった——こうしたケースも起きます。
普段は10人で使っているシステムでも、月に一度の一斉作業で100人が同時アクセスする場合があります。その想定を要件定義で伝えていなければ、ベンダーは普段の利用規模で設計します。
パターン3：セキュリティの穴が後から発覚
個人情報や取引データを扱うシステムで、リリース後にセキュリティの問題が発覚するケースがあります。
「セキュリティは開発者が考えるもの」と思っている発注者は少なくありませんが、セキュリティ要件は発注者側が要求として出す必要があります。「このデータは社外からアクセスさせたくない」「特定の役職者だけが参照できるようにしたい」といった要求を明示しなければ、ベンダーは標準的な実装しか行いません。
パターン4：バックアップがなくてデータが消えた
サーバーの障害や操作ミスでデータが失われたとき、バックアップの設定について要件定義で合意していなかった——というケースがあります。
「バックアップは当然やるもの」と思っていても、その頻度・保存期間・復元手順までを要件として合意していなければ、発注者の期待とベンダーの実装が合っていないことがあります。
確認しておくべき非機能要件の一覧
以下の観点を要件定義の段階でベンダーと合意しておきます。すべてに厳密な数値が必要なわけではありませんが、「特に重要な点」を明示しておくことが大切です。
パフォーマンス
- 1日の利用件数・データ登録件数の想定
- ピーク時の同時接続人数
- 画面表示・処理にかけられる最大時間（例：一覧表示は5秒以内など）
可用性
- 稼働が必要な時間帯（24時間か、営業時間内のみか）
- メンテナンス停止を許容できるタイミング
- 障害時の復旧目標時間
セキュリティ
- 扱うデータの機密レベル（個人情報・財務情報・機密業務情報など）
- アクセス権限の設計（誰が何を見られるか）
- 社外からのアクセス可否
- 二段階認証などの認証要件
データ保全
- バックアップの頻度と保存期間
- 障害発生時に失ってよいデータの最大量（例：直近1時間分まで）
- 過去データの参照期間（何年分を検索できる必要があるか）
拡張性
- 将来的に利用者数やデータ量が何倍になる想定か
- 機能追加の予定があるか
「要件として出す」ことが重要
非機能要件について重要なのは、「ベンダーが気を利かせてくれるはず」という期待を持たないことです。
ベンダーは発注者から明示されていない要件については、コストと工数のバランスを取りながら標準的な実装を選択します。「本来はもっと堅牢にしたかったが、要件として示されなかった」という立場になります。
「こういうシステムにしてほしい」という要求は、発注者から出すものです。非機能要件も機能要件と同様に、発注者が要求として明示する必要があります。
まとめ
非機能要件の見落としは、機能の作り直しより深刻なケースがあります。パフォーマンス・可用性・セキュリティ・バックアップの4点を要件定義の段階でベンダーと合意しておくことで、リリース後の深刻な問題を防ぐことができます。「当然やってくれているはず」ではなく、明示的に要件として伝えることが重要です。