「なるべく速く動くこと」「安全であること」「安定して使えること」——非機能要件は、こうした曖昧な言葉のまま要件定義フェーズを通過しがちです。実装が終わってから「思ったより遅い」「これはセキュリティ的に大丈夫なのか」と問題になるのは、実装ミスではなく、要件定義の時点で基準が数値化されていなかったことが原因です。

なぜ非機能要件だけ「あとから発覚」するのか

機能要件は「ログインできる」「一覧が表示される」のように、動くか動かないかで判定できます。一方、非機能要件は「どのくらい」「どこまで」を決めないと判定不能な性質を持ちます。数値のない非機能要件は、レビューでもテストでも引っかからず、そのまま実装フェーズまで運ばれてしまいます。

結果として基準が実装者の裁量に委ねられ、リリース後にユーザーやステークホルダーの体感と衝突して初めて「バグ」として報告されます。これは実装フェーズで防げる話ではなく、要件定義フェーズで防ぐべき話です。

4カテゴリの数値化テンプレート

非機能要件は「性能」「可用性」「セキュリティ」「運用性」の4カテゴリに分けて、それぞれ数値・閾値まで書き切ります。悪い例と良い例を対比します。

性能

悪い例: 「ページはなるべく速く表示されること」
良い例: 「主要画面のLCPは95パーセンタイルで2.5秒以内。API応答はp95で300ms以内、p99で800ms以内」

可用性

悪い例: 「サービスは安定して稼働すること」
良い例: 「月間稼働率99.9%以上（許容ダウンタイム約43分/月）。障害検知から復旧までのRTOは30分以内、RPOは5分以内」

セキュリティ

悪い例: 「セキュリティ的に問題がないこと」
良い例: 「認証トークンの有効期限は1時間、リフレッシュトークンは30日。OWASP Top 10を静的解析ツールでリリース前に必ずチェックし、High以上の指摘はゼロにする」

運用性

悪い例: 「運用しやすいこと」
良い例: 「エラーログは90日間保持。5xxエラーが5分間で10件を超えたらSlackへ即時アラート。ダッシュボードへの反映遅延は1分以内」

数値化を機能させる3つの問い

数値を書くだけでは形骸化します。各項目に対して次の3つを必ずセットで決めます。

誰が測るか — 計測の責任者を明記する（例: SREチームがp95レイテンシを監視ダッシュボードで測定）
いつ測るか — リリース前の負荷テストか、本番の常時監視か、あるいは両方かを決める
基準未達時にどうするか — リリースをブロックするのか、既知の課題として記録して次スプリントに回すのかを事前に合意する

この3つが抜けていると、数値だけが独り歩きして「誰も測っていない基準」になり、結局あとから発覚するバグと変わらなくなります。

実務でよくある失敗パターン

非機能要件の数値化でつまずきやすいのは、数値の粒度がプロジェクトの規模に合っていないケースです。立ち上げ期のMVPに大企業向けのSLA（99.99%稼働率など）をそのまま持ち込むと、達成コストが跳ね上がり、開発速度を犠牲にしてしまいます。逆に、決済や個人情報を扱う機能でセキュリティの基準を緩く設定すると、リリース後に深刻なインシデントにつながります。テンプレートを機械的に埋めるのではなく、機能ごとのリスクとコストのバランスを見て閾値を調整することが重要です。

要件定義で使えるチェックリスト

性能・可用性・セキュリティ・運用性の4カテゴリすべてに数値が入っているか
「なるべく」「できるだけ」「安定して」など曖昧な副詞が残っていないか
各数値に計測方法と計測責任者が紐づいているか
基準未達時の判断基準（リリース可否）が事前に合意されているか
機能のリスクの大きさと数値の厳しさが釣り合っているか

Bugoon での実践

非機能要件を数値で決めても、実際にその基準を下回ったときにどう報告として拾い上げるかは別の課題です。Bugoon はウィジェットを埋め込むだけで、QA担当者や非エンジニアが画面上からスクリーンショット付きでバグを報告でき、操作ステップも自動で記録されます。「体感で遅い」「なんとなく不安定」といった非機能要件がらみの報告も、再現手順とあわせてそのままGitHub Issueに連携され、カンバンボードで進捗を追えます。Claude Code / Cursor と連携するMCPサーバーも用意しており、報告内容をもとにAIが修正まで踏み込める体制を作れます。

「なるべく速く」を仕様に変える