女性向けエンジニアスクール
3秒でわかる
何を作るかではなく、どのくらいの速さや堅さで動くべきかを決める要件。性能や可用性など、後から直すと作り直しになる部分です。
もう少し詳しく
どういうものか
非機能要件は、システムが「どう動くべきか」を定める要件です。機能要件が「注文を確定できる」「在庫を検索できる」という動作そのものを指すのに対し、非機能要件は「注文確定は 2 秒以内に返る」「年間の停止時間は 4 時間以内」「個人情報は保存時に暗号化する」といった品質の水準を指します。
IPA の分類では、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの 6 分類が使われます。基本情報技術者試験や IT パスポートでもこの区分で出題されます。
なぜ必要か
機能要件だけを満たしたシステムは、テスト環境では動いて本番で壊れます。10 件のデータで確認した一覧画面が、10 万件になると 30 秒かかる。監視もログもないので、落ちたことに翌朝まで誰も気づかない。こうした事態は「作る前に数値を決めていない」ことから起きます。
さらに厄介なのは、非機能要件が後から効いてくる点です。1 秒以内に返す必要があると最初に分かっていればキャッシュや索引を前提に設計できますが、稼働後に判明するとテーブル設計から作り直しになります。
具体例
要件は文章ではなく測れる数値で書きます。
悪い書き方 レスポンスは十分速いこと
良い書き方 商品検索は同時 500 ユーザー時に 95 パーセンタイルで 1.0 秒以内
悪い書き方 高可用であること
良い書き方 月間稼働率 99.9% 以上(月あたり停止 43 分まで)
悪い書き方 安全であること
良い書き方 <a href="/glossary/password" class="text-primary font-medium underline underline-offset-2 hover:text-primary-dark">パスワード</a>は bcrypt で保存し、管理画面は MFA 必須数値が入っていれば、達成したかどうかを試験で判定できます。入っていなければ、それは要件ではなく感想です。測る条件も一緒に書きます。同時接続数、対象データ件数、測定する時間帯が抜けていると、開発側と発注側で別の状況を思い浮かべたまま合意してしまいます。
つまずきやすいところ
可用性を上げようとして「99.999% を目指す」と書いてしまう例をよく見ます。年間の停止許容が 5 分になり、冗長化と自動切り替えと監視体制に相応の費用が乗ります。可用性の桁を 1 つ上げるとコストは跳ね上がるため、業務が本当に止められない時間帯はどこかを確認して決めます。
もう 1 つは、性能要件を平均値で書くことです。平均 0.5 秒でも、上位 5% が 10 秒かかっていれば苦情は出ます。パーセンタイルで書きます。
似た用語との違い
| 用語 | 問い |
|---|---|
| 機能要件 | 何ができるか |
| 非機能要件 | どのくらいの品質で動くか |
| 制約条件 | 予算や納期など、選択の幅を狭める前提 |
覚え方
機能要件は料理の品目、非機能要件は提供時間と衛生基準。品目が同じでも店の評価はここで決まります。
