非機能要件とは
システムに求める条件のうち、何ができるかではなく、どれだけ停止せず、速く、安全に稼働し続けるかを定めたものです。受注を登録できる、請求書を発行できるといった条件が機能要件にあたります。障害で停止したら何時間で復旧させるか、繁忙期に何人が同時に利用しても画面が3秒以内に表示されるか、ログを何年保存するかといった条件が非機能要件にあたります。英語の頭文字からNFR（Non-Functional Requirements）とも呼びます。発注側の希望の段階を非機能要求、合意して仕様に組み込んだものを非機能要件と呼び分けることもありますが、実務ではほぼ同じ意味で使用されます。システムに求めることを発注側と開発側が定める要件定義の工程で、機能要件と並べて定めます。
自動車の例では乗車定員や荷室の広さが機能要件で、衝突時の安全性、燃費、故障の少なさ、整備のしやすさが非機能要件にあたります。定員はカタログを確認すれば分かりますが、衝突時の安全性は実際に衝突するまで差が分かりません。しかも購入後に追加することはほとんどできません。
なぜ定めておく必要があるか
システムの要件を定める場では、画面や業務の流れの話が中心になります。非機能要件は言葉にされないまま進行しやすいです。発注側は停止しないのが当然と想定し、開発側は見積もりに収まる水準で構築します。このずれが発覚するのは稼働した後で、月末に画面が応答しなくなる、障害からの復旧に丸1日かかる、といった形で発生します。改修するにはサーバーの構成から変更する必要があり、機能を1つ追加するよりはるかに費用がかかります。
この問題に対して、IPA（情報処理推進機構）は非機能要求グレードという枠組みを公開しました。非機能要件を6つの大項目に分類し、項目ごとに水準を段階で選択できるようにしたもので、発注側と開発側が同じ項目表を参照して水準を合意するために作成されました。水準は一般にレベルが上がるほど開発費が増加する区切りで設けられています。最終版は2018年版で、IPAの事業は終了し、資料はアーカイブとして公開が続いています。更新は停止していますが、項目の網羅性から今も発注側と開発側の共通の項目表として利用されています。国際規格にはソフトウェアの品質特性を定めたISO/IEC 25010もあります。
6つの項目と発注側が検討すること
非機能要求グレードの6つの大項目を、発注側が定める内容に整理すると次の表のとおりです。
| 項目 | 発注側が検討すること |
|---|---|
| 可用性 | 利用する時間帯、停止したときに何時間で復旧させるか、災害時にどこまで復旧させるか |
| 性能・拡張性 | 同時に利用する人数、ピーク時の処理件数、画面が表示されるまでの待ち時間、今後の増加の見込み |
| 運用・保守性 | 監視する時間帯、障害の連絡を誰が何時まで受け付けるか、バックアップを何世代保持するか |
| 移行性 | 旧システムからどのデータをいつまでに移すか、新旧を並行稼働させる期間 |
| セキュリティ | 管理する情報の重要度、利用できる人の範囲、操作の記録を保存する期間 |
| システム環境・エコロジー | 設置場所や利用する地域、守るべき規格などの制約。多くは開発側の提案を確認すれば足りる |
どの項目も業務への影響から逆算して定めます。ただしログの保存期間や個人情報の安全管理のように、法令や業界のガイドラインで下限が定められている項目もあり、業務への影響とは別に確認します。技術の知識がなくても回答できる問いがほとんどで、答えを技術の言葉に変換するのは開発側が担います。
効果
- 見積もりの前提がそろい、複数社の見積もりを同じ条件で比較できる
- 稼働後に性能不足や復旧の遅さが判明して再構築する事態が減少する
- 水準を下げてよい項目を明示でき、不要な費用を削減できる
- 障害時の連絡先や復旧の手順が稼働前に確定し、停止したときの初動が迅速になる
コストとリスク
- 水準を引き上げるほど費用は加速して増加する。Googleのサイト信頼性エンジニアリングの解説書には、信頼性を一段引き上げる費用が前の一段の100倍になることもあるとある
- 停止しにくくするにはサーバーやデータベースを二重化し、障害時に自動で切り替える仕組みが必要になる。インフラ費は二重化した分だけ増加する
- 夜間や休日も障害に対応するには、交代で待機する担当者が必要になり、人件費が毎月かかり続ける
- 細かい指標まで数えると200を超えるため、全部を詰めると要件定義が長期化する
- 水準を高く設定しすぎると見積もりが増大し、低く設定しすぎると稼働後の作り直しを招く
- 合意した水準を満たすかは本番前の負荷試験と、障害時の切り替えやバックアップからの復元の訓練で確認する。開発とは別に工数がかかり、省略すると稼働後に初めて不足が判明する
- 稼働後も水準を守れているかを測定する監視と定期的な報告の運用が続く
- 利用者数や業務が変化すると、当初の前提と実態が一致しなくなる。稼働後も年に1回程度は水準を再検討する手間がかかる
よくある誤解
クラウドを利用すれば停止しないし安全になる
クラウド事業者が責任を担うのは、データセンターやサーバーなどの基盤までです。AWS（Amazon Web Services）も責任共有モデルの中で、アプリケーション、データの保護、アクセス権限の設定は利用者側の責任だと明示しています。仮想サーバーを借りる使い方なら、OSの更新も利用者側が担います。クラウド事業者がSLA（Service Level Agreement）で示す稼働率は個々のサービス単体の数字で、その上に構築したシステム全体の稼働率ではありません。
SLAを結べば非機能要件は定めなくてよい
SLAに記載できるのは定めた水準のうち、稼働率や問合せへの応答時間のように測定できるものだけです。非機能要件が先に確定していないと、SLAに記載する数字も決定できません。しかも違反したときの補償は、多くの場合次の請求から利用料の一部を差し引く扱いで、停止した間の売上の損失は補償されません。
稼働率は100%に近いほどよい
100%は実現できず、近づけるほど費用だけが急に増加します。利用者の通信環境や端末のほうが先に停止するため、一定の水準を超えると利用者には違いが分かりません。必要な水準を満たしたらそれ以上は引き上げないことも選択肢の1つです。
