非機能要件が見落とされる構造的理由
要件定義の場で、議論の大半は「何ができるか」に費やされる。
「お問い合わせフォームが必要です」「商品一覧ページは絞り込み検索が使えるようにしたい」「管理者が記事を投稿できる機能が欲しい」——こうした要望はクライアントにとって具体的にイメージしやすく、受託者にとっても見積もりを立てやすい。画面遷移図や機能一覧に落とし込み、認識を合わせることができる。
一方で「そのフォーム、1秒以内に送信完了できる必要がありますか」「商品が1万点を超えても同じ速度で動作する必要がありますか」「不正アクセスやSQLインジェクションへの対策はどの水準を求めますか」——こうした問いは、場の空気を止める。発注者は「そこまで考えていなかった」と困惑し、受託者も「標準的な対応をします」と曖昧に流してしまう。
これが非機能要件の見落としが起きる構造的原因である。
発注者側には3つのバイアスがある。第一に、「動けばいい」という完成イメージの甘さ。画面を触れて機能が動作することがゴールになり、「どのくらい速く」「どのくらい安全に」という品質軸が後回しになる。第二に、非機能要件が「当然含まれているもの」という思い込み。エンジニアならセキュリティ対策は当然やっているはずだ、という期待感が明文化を妨げる。第三に、非機能要件を定義することへのコスト感覚の欠如。要件定義に時間をかけることを嫌い、「まず作ってみてから調整したい」というアジャイル的な発想が、実際には合意形成の省略として機能してしまう。
受託者側にも構造的な問題がある。非機能要件を詳細に定義すると、見積もりが高くなる。競合他社との価格競争の中で、「標準的な品質でお届けします」と抽象的に済ませることが受注を獲得するための現実的な選択肢になりがちだ。また、非機能要件の実装コストは、機能要件と比べて説明しにくい。「ログイン機能を作る工数」は説明できても、「セッション管理の脆弱性対策に必要な工数」は発注者に理解されにくい。
この非対称な情報環境の中で、非機能要件は「誰も明文化しないまま着手される」プロセスが常態化している。
機能要件と非機能要件の本質的な違い
機能要件と非機能要件は、システムの異なる側面を定義する。
**機能要件（Functional Requirements）**は、システムが「何をするか」を定義する。ユーザーが実際に操作する機能、データの処理・表示・保存の仕組み、画面の遷移フローなどが該当する。例として、「ユーザーがメールアドレスとパスワードで登録できる」「管理者が商品情報をCSVで一括インポートできる」「注文確定時に確認メールが自動送信される」などが機能要件に当たる。これらは仕様書・画面設計書・ワイヤーフレームに落とし込みやすく、完成の判定が比較的明確である。
**非機能要件（Non-functional Requirements）**は、システムが「どのように動くか」を定義する。特定の機能を実現するための品質条件や制約条件であり、機能そのものではなくシステム全体の振る舞いを規定する。「1000人が同時にアクセスしても3秒以内に画面が表示される」「個人情報は暗号化して保存される」「月間稼働率99.9%を保証する」などが非機能要件に当たる。これらは機能の実装方法や基盤設計に影響を与えるが、画面に直接現れにくいため、完成の判定基準も曖昧になりやすい。
両者の関係を端的に言えば、機能要件は「何をするか」であり、非機能要件は「どのくらいうまくするか」である。レストランで例えるなら、「パスタを提供する」が機能要件、「10分以内に提供し、温度は70℃以上を維持する」が非機能要件に相当する。
重要なのは、非機能要件が未定義でも短期間は機能するシステムを作れる点だ。しかし本番稼働後の負荷増加・セキュリティインシデント・障害復旧の局面で、非機能要件の甘さが一気に顕在化する。後から対応しようとすると、基盤設計からやり直す必要が生じ、初期設計の何倍ものコストがかかることが多い。
非機能要件の6大カテゴリ
IPA（情報処理推進機構）は非機能要求グレードの中で、非機能要件を「可用性」「性能・拡張性」「運用・保守性」「移行性」「セキュリティ」「システム環境・エコロジー」の6大カテゴリに体系化している。Web制作・システム開発の現場では、以下の解釈で理解するとよい。
1. 性能・応答性能（Performance）
ページの表示速度、同時接続数、データ処理速度などを定義する。具体的には「トップページの初期表示は2秒以内」「同時接続ユーザー500人でも応答時間が劣化しない」「月次集計バッチ処理は午前3時〜5時の間に完了する」などが該当する。Eコマースサイトでは表示速度が直接コンバージョン率に影響するため、性能要件の定義は事業指標と直結する。
2. 信頼性・可用性（Reliability / Availability）
システムがどのくらい停止せずに動き続けるかを定義する。「月間稼働率99.5%（計画外停止は月3.6時間以内）」「障害発生から2時間以内に復旧」「データのバックアップは日次で取得、7日間保持」などが典型的な要件となる。ECサイトや予約システムのように停止が直接的な機会損失になるサービスでは、この要件の設定が事業継続計画（BCP）と連動する。
3. セキュリティ（Security）
不正アクセス・情報漏えい・改ざんを防ぐための要件を定義する。「個人情報はAES-256で暗号化して保存する」「パスワードはbcryptでハッシュ化する」「OWASP Top 10に対応したセキュリティ対策を実施する」「ログイン試行失敗5回でアカウントをロックする」などが含まれる。個人情報保護法・要件・PCI DSS準拠などの法的・規格的要件もここに含まれる。
4. 保守性・運用性（Maintainability / Operability）
システムを保守・運用するための要件を定義する。「エラーログはサーバーに30日間保持し、管理画面から確認できる」「コンテンツの更新はCMSから担当者が単独で行える」「月次リリースのデプロイ作業は1時間以内に完了する」などが典型例だ。特に受託開発では、納品後の運用フェーズで誰が何をするかを初期段階で明確にしておくことが、トラブル防止に不可欠である。
5. 拡張性・移行性（Scalability / Portability）
将来の規模拡大やシステム変更に対応できる設計要件を定義する。「ユーザー数が現在の10倍になった場合でもサーバースペックの追加で対応できる設計」「既存の基幹システムとAPIで連携できるようにする」「将来的に他社クラウドへの移行が容易な構成にする」などが含まれる。初期開発コストを抑えるために拡張性を犠牲にすると、数年後の改修コストが膨大になるため、事業の成長フェーズを見据えた要件設定が重要である。
6. 法令・コンプライアンス要件（Compliance）
業種・業態に応じた法的要件を定義する。医療情報を扱うシステムであれば医療情報システムの安全管理に関するガイドラインへの準拠、金融サービスであれば金融庁のガイドラインへの対応、ECサイトであればPCI DSSへの対応などが求められる。これらは機能としては見えにくいが、対応しないと事業そのものが法的リスクを負うため、最も優先度の高い非機能要件の一つである。
見落としが引き起こす実害
非機能要件の未定義が実際にどのような問題を引き起こすか、典型的なシナリオを3つ示す。
シナリオ1: セール開催日の大規模障害
アパレルブランドのECサイトを構築した事例。要件定義では商品登録・カート・決済の機能要件に集中し、同時接続数の上限は特に定めなかった。通常時は100人程度のアクセスで問題なく動作していたため、双方に油断があった。シーズンセールの初日、SNSキャンペーンと重なり数千人が一斉にアクセス。サイトは15分で応答停止した。サーバースペックの緊急増強を行ったが、データベースのインデックス設計が負荷を想定していなかったため、半日以上の停止が続いた。機会損失と復旧コストは当初の開発費を超えた。この案件で「性能・拡張性」の非機能要件が定義されていれば、負荷テストの実施とインフラ設計の見直しが初期段階で行われていたはずである。
シナリオ2: 個人情報漏えいによる信頼失墜
中小企業向け会員サービスのシステムを開発した事例。発注者は「セキュリティはよしなにやってほしい」と伝え、受託者も「標準的な対策を実施します」と返答した。実際にはパスワードを平文でデータベースに保存しており、SQLインジェクション対策も不十分だった。サービス開始から1年後に不正アクセスが発生し、数千件の会員情報が流出。発注者はセキュリティ要件を明示していなかったと主張し、受託者は「明示的な要件がなければ標準的な実装をした」と反論した。責任の所在を巡る争いは長期化し、双方の信頼関係は完全に崩壊した。
シナリオ3: 担当者退職後のブラックボックス化
システムを内製に近い形で受託開発した事例。発注者の要望で短期間・低コストで開発を行い、保守性の要件はほとんど定義されなかった。担当していた受託者フリーランスが1年後に案件を離れると、ソースコードのコメントはほぼなく、環境構築手順もドキュメント化されていなかった。後任のエンジニアが修正・改修するたびに膨大な解析コストが発生し、小さなバグ修正に数十万円かかるケースも生じた。保守性の要件として「コメント記述率50%以上」「環境構築手順書の提供」「エラーログの実装」を定義していれば、こうした状況は避けられた。
合意文書として残すための実務プロセス
非機能要件を有効に機能させるためには、口頭確認ではなく合意文書として残すことが必須である。
ステップ1: IPAの非機能要求グレードを使った洗い出し
は、非機能要件を体系的に洗い出すための実務ツールである。「可用性」「性能・拡張性」「運用・保守性」「移行性」「セキュリティ」「システム環境・エコロジー」の各カテゴリにわたる質問リストと、要件レベルを段階的に示すグレード表が公開されている。要件定義の初期段階で、このチェックリストを発注者・受託者双方で確認することが推奨される。
ステップ2: 優先度と水準の合意
すべての非機能要件を最高水準で実装することは現実的ではない。コストと品質のトレードオフを整理するため、各カテゴリの優先度（必須／推奨／将来対応）と具体的な数値目標を合意する。例えば「稼働率は99%で十分だが、セキュリティは最優先で対応する」「性能は現在の想定ユーザー数×3倍まで対応できれば十分」といった合意を文書に残す。
ステップ3: 非機能要件を見積もりと契約に反映する
非機能要件の水準が決まれば、実装コストを見積もりに明示できる。「セキュリティ対策費用：○○万円（OWASP Top 10対応、ペネトレーションテスト実施含む）」のように、何にいくらかかるかを発注者が理解できる形で提示する。契約書には「本契約における非機能要件は別紙○を参照とし、それ以外の要件対応は別途見積もりとする」という条項を設けることで、後からの無償対応を防ぐことができる。
ステップ4: 受け入れ基準の明文化と検証
非機能要件は「完成した」かどうかの判定が難しいため、受け入れ基準を具体的な数値・テスト手順として定義しておく。「負荷テストで500同時接続時に応答時間3秒以内を確認」「OWASP ZAPによる脆弱性スキャンで高リスク項目ゼロを確認」などのように、測定可能な形で記述する。納品前にこれらの基準をクリアしたことをエビデンスとして提出することを、契約上の要件にする。
発注者・受託者それぞれのアクション指針
発注者が今すぐできること
まず、自社サービスの事業上のリスクを整理することから始める。システムが止まると何が起きるか、情報が漏えいすると何が起きるか、動作が遅いとユーザーが離脱するかを具体的に考える。そのリスクの大きさが、非機能要件の水準を決める根拠になる。
次に、受託者に対して「非機能要件はどのように定義・担保しますか」と問う習慣をつける。この問いに対して明確に答えられない受託者は、非機能要件を軽視している可能性がある。逆に体系的な回答が返ってくる受託者は、品質に対する意識が高い。
そして、非機能要件の定義に時間とコストをかけることを、投資として捉え直す。要件定義に追加で50万円かけることは、本番障害による機会損失数百万円を防ぐための保険である。
受託者が今すぐできること
ヒアリングシートに非機能要件の確認項目を必ず含める。「同時接続数の想定は何人ですか」「個人情報の取り扱いはありますか」「システム停止が許容される最大時間は何時間ですか」という質問を標準化する。これらを問うこと自体が、発注者の非機能要件への意識を高めるきっかけになる。
見積書には非機能要件対応の費用を明示し、対応しない場合のリスクを記載する。「本見積もりには負荷テストは含まれていません。想定アクセス数が変化した場合、追加対応が必要になります」という一文が、後のトラブルを防ぐ。
また、提案時点で「この規模のサービスで最低限必要な非機能要件」を先に示すことは、発注者の信頼を獲得する差別化要因になる。単に安い見積もりを出すのではなく、品質と安全性のリスクを説明できる受託者は、中長期的なパートナーとして選ばれやすい。
参考文献
非機能要求グレード 2018 (2018)
Non-functional requirement (2024)
非機能要件 (2024)