非機能要件定義書の書き方 6大項目・記載例・IPA非機能要求グレードの活用法を解説

「非機能要件定義書に何を書けばよいかわからない」「性能やセキュリティの要件をどう定義すればよいか迷っている」。システム開発の上流工程で、非機能要件の定義に悩むエンジニアやプロジェクトマネージャーは多いのではないでしょうか。

非機能要件とは、システムの「機能以外の品質・条件に関する要件」のことです。可用性、性能、セキュリティ、運用・保守性など、ユーザーの目には見えにくいですが、リリース後のトラブルの多くはこの非機能要件の定義不足に起因しています。

IPAが公開している「非機能要求グレード」を活用すれば、非機能要件の項目を網羅的に整理し、発注者と開発者の認識を揃えることができます。この記事では、非機能要件定義書の6大項目、具体的な記載例、IPAの非機能要求グレードの活用方法、そして作成時のポイントまで、実務で使える形で解説します。

確認したいポイント	結論	詳細
非機能要件定義書には何を書くか？	6大項目を中心に記載	可用性・性能/拡張性・運用/保守性・移行性・セキュリティ・システム環境の6項目が基本です
機能要件との違いは？	「何ができるか」vs「どう動くか」	機能要件は「システムに必要な機能」、非機能要件は「その機能がどの品質・条件で動くか」を定義します
IPAの非機能要求グレードとは？	項目の網羅と合意のためのツール	6大項目・238メトリクスを段階的なレベルですり合わせるIPAの無償ツール群です。たたき台として活用できます
作成のポイントは？	数値で定義し合意を取る	「速く」「安全に」ではなく「応答3秒以内」「稼働率99.9%」のように数値で定義し、関係者で合意することが重要です

この記事でわかること

・非機能要件の定義と機能要件との違い

・非機能要件定義書の6大項目と各項目の記載内容

・IPA非機能要求グレードの活用方法

・項目ごとの具体的な記載例

・非機能要件定義書を作成する際のポイントと注意点

＼ システム開発・DX推進のご相談はネクストスケールへ ／ ▶ 相談予約はこちら

非機能要件とは？定義と機能要件との違い

非機能要件定義書の書き方に入る前に、「非機能要件とは何か」を正確に理解しておきましょう。

非機能要件の定義

非機能要件とは、システムの機能以外の品質・条件に関する要件のことです。機能要件が「システムで何ができるか」を定義するのに対し、非機能要件は「その機能がどの程度の品質・性能・安全性で動くか」を定義します。

たとえば、ECサイトにおける「商品を検索できる」は機能要件、「検索結果が3秒以内に表示される」「同時に1,000人がアクセスしても遅延しない」「24時間365日稼働する」はすべて非機能要件です。

機能要件との違い

比較項目	機能要件	非機能要件
定義する内容	システムで何ができるか	どの品質・条件で動くか
具体例	ログイン、検索、帳票出力	応答速度、稼働率、セキュリティ
可視性	ユーザーから見えやすい	ユーザーからは見えにくい
定義漏れのリスク	機能不足で業務が回らない	リリース後にトラブルが頻発

非機能要件はユーザーから自発的に出てくることが少なく、後回しにされがちです。しかし、定義が不十分なままリリースすると、「遅い」「止まる」「セキュリティが甘い」といった運用開始後のトラブルに直結します。

非機能要件定義書の6大項目

IPAの「非機能要求グレード2018」では、非機能要件を6つの大項目に分類しています。この分類をベースに、非機能要件定義書を構成するのが実務的です。

1. 可用性

システムを継続的に利用可能な状態に保つための要件です。具体的には、運用時間（24時間稼働か営業時間内のみか）、稼働率の目標（99.9%など）、目標復旧時間（RTO：障害からの復旧にかける時間の上限）、目標復旧地点（RPO：データのどの時点まで復旧するか）を定義します。

記載例：「稼働率99.9%（年間のサービス停止許容時間8.76時間以内）」「障害発生時の目標復旧時間は4時間以内」

2. 性能・拡張性

システムの応答速度、処理能力、将来のデータ量やユーザー数の増加への対応に関する要件です。画面の応答速度、バッチ処理の完了時間、同時接続ユーザー数、データ保持量の上限、将来の拡張計画を定義します。

記載例：「画面遷移の応答時間は3秒以内」「同時接続ユーザー数1,000人に対応」「データ量は年間20%増加を想定し、5年分のデータを保持」

3. 運用・保守性

システムの日常的な運用管理と保守作業に関する要件です。監視の対象と方法、障害検知と通知の仕組み、バックアップの頻度と保持期間、ログの保管ルール、定期メンテナンスの計画を定義します。

記載例：「サーバーの死活監視を5分間隔で実施し、異常時はメールで管理者に通知する」「データベースのフルバックアップを日次で取得し、30日間保持する」

4. 移行性

既存システムから新システムへのデータ移行と業務切り替えに関する要件です。移行対象のデータ種類と量、移行方式（一括移行/段階的移行）、移行時のダウンタイム許容範囲、切り戻し計画を定義します。

記載例：「現行システムから5年分の取引データ（約200万件）を新システムに移行する」「移行作業は土日の48時間以内に完了させる」

5. セキュリティ

システムの情報セキュリティに関する要件です。認証方式（ID/パスワード、二要素認証など）、アクセス制御（ロールベースの権限管理）、通信の暗号化（TLS/SSL）、監査ログの記録、脆弱性対策を定義します。

記載例：「すべての通信をTLS1.2以上で暗号化する」「ログイン認証にはID/パスワード＋二要素認証を採用する」「操作ログを1年間保持し、不正アクセスの監査に利用する」

6. システム環境・エコロジー

システムの稼働環境と環境負荷に関する要件です。サーバーの設置場所（オンプレミス/クラウド）、クラウドの場合のリージョン（データセンターの所在地）、開発・テスト・本番環境の構成、CO2排出量やエネルギー効率への配慮を定義します。

記載例：「本番環境はAWS東京リージョンに構築する」「開発環境・テスト環境・本番環境の3環境を用意する」

IPAの非機能要求グレードの全項目は、公式サイトから無料でダウンロードできます（参考：IPA 非機能要求グレード）。

＼ システム開発・DX推進のご相談はネクストスケールへ ／ ▶ 資料請求はこちら

IPA非機能要求グレードを活用した定義の進め方

非機能要件をゼロから洗い出すのは困難です。IPAの非機能要求グレードを「たたき台」として活用することで、効率的に定義を進められます。

非機能要求グレードの構成

非機能要求グレードは、6大項目・中項目35・小項目118・メトリクス238という体系で構成されています。各メトリクスにはレベル0〜5の6段階が設定されており、レベルが大きいほど実現の難易度とコストが高くなります。

また、3つの典型モデルシステム（社会的影響がほとんどないシステム・限定的なシステム・極めて大きいシステム）ごとに、目安となるレベルがあらかじめ設定されています。自社のシステムに最も近いモデルを選び、そこから必要に応じてレベルを調整する、という使い方が基本です。

定義の進め方｜3ステップ

ステップ1：対象システムに最も近いモデルシステムを選定し、目安レベルを出発点にします。

ステップ2：6大項目のうち重要度の高い項目から、目安レベルを確認し、自社の要件に合わせてレベルを調整します。すべてのメトリクスを埋める必要はなく、プロジェクトに関係する項目を中心に検討します。

ステップ3：発注者と開発者で各項目のレベルを確認し、合意した内容を非機能要件定義書として文書化します。

この進め方のポイントは、「曖昧な要求を数値に翻訳して合意する」ことです。「速く」ではなく「3秒以内」、「安全に」ではなく「TLS1.2以上で暗号化」のように、数値や基準で定義することで、発注者と開発者の認識のズレを防ぎます。

非機能要件定義書の作成ポイントと注意点

非機能要件定義書を作成する際に押さえておくべきポイントと、よくある失敗を防ぐための注意点を紹介します。

ポイント1：要件は必ず数値で定義する

「レスポンスが速いこと」「セキュリティが高いこと」のような曖昧な表現は、テスト工程で合否判定ができないため避けましょう。「画面の応答時間が3秒以内であること」「稼働率が99.9%以上であること」のように、客観的に計測可能な数値で定義します。

ポイント2：コストとのトレードオフを意識する

非機能要件のレベルを上げるほど、開発費用と運用費用が増加する点を認識しておく必要があります。稼働率99%と99.99%では、コストが数倍〜数十倍変わることもあります。業務への影響度とコストのバランスを関係者間で議論し、過剰品質を避けることが重要です。

ポイント3：発注者と開発者の双方で合意する

非機能要件は、発注者と開発者が合意した内容を文書として残すことが特に重要です。口頭で「なんとなく」決まった要件は、後工程で「そんな話は聞いていない」というトラブルの原因になります。非機能要求グレードの活用シートに記入した内容を、合意文書として保管しておきましょう。

ポイント4：クラウド環境特有の要件も考慮する

クラウド環境でシステムを構築する場合は、データの保管リージョン、クラウドベンダーのSLA、マルチテナント環境でのセキュリティなど、オンプレミスにはない要件も検討が必要です。クラウドベンダーが保証するSLAと、自社が求める可用性レベルの整合性を確認しておきましょう。

ポイント5：テスト方法も合わせて定義する

非機能要件を定義する際に、その要件をどのようにテスト（検証）するかも合わせて定義するのがベストプラクティスです。「応答時間3秒以内」という要件であれば、「100ユーザーが同時アクセスした状態で、主要10画面の応答時間を負荷テストツールで計測する」のように、テスト方法と条件を明記しておきます。

要件定義の具体例については、要件定義の例の記事でシステム種類別のサンプルを紹介しています。また、要件定義書のフォーマットでは書式やレイアウトの基本を解説しています。システム開発の外注を検討中の方は、システム開発の外注とはも参考にしてください。

＼ システム開発・DX推進のご相談はネクストスケールへ ／ ▶ 相談予約はこちら

まとめ

非機能要件定義書は、システムの「機能以外の品質・条件」を定義する文書であり、リリース後のトラブルを防ぐために不可欠な成果物です。IPAの非機能要求グレードが示す6大項目（可用性・性能/拡張性・運用/保守性・移行性・セキュリティ・システム環境）をベースに構成するのが実務的です。

作成にあたっては、要件を曖昧な表現ではなく数値で定義すること、コストとのトレードオフを意識すること、発注者と開発者の双方で合意を文書化すること、テスト方法も合わせて定義することがポイントです。

非機能要件はユーザーから自発的に出てくることが少ないため、開発側から「この項目についてはどの水準を求めますか」と具体的に問いかけて引き出す姿勢が求められます。IPAの非機能要求グレードをたたき台にして、プロジェクトの初期段階で関係者と合意を形成しておきましょう。

＼ システム開発・DX推進のご相談はネクストスケールへ ／ ▶ 資料請求はこちら