非機能要件とは？デジタル庁で定められている非機能要件の項目一覧と定義について解説
非機能要件は、システム開発で定義するもののうち、機能要件以外の要件のことです。
非機能要件は、「情報システムの非機能要件」と「プロジェクトの進め方に関する非機能要件」に大別できます。
「情報システムの非機能要件」は、処理の実行速度などの「性能」や、システムの「セキュリティ」などを指します。
「プロジェクトの進め方に関する非機能要件」は、「移行」や「運用・保守」などを指します。
非機能要件は範囲が非常に広く、発注側での定義が難しい項目であるため、「デジタル・ガバメント推進標準ガイドライン」や「非機能要求グレード」などのガイドラインを活用して定義します。
非機能要件には厳密な定義はありませんが、参考として、デジタル庁の「デジタル・ガバメント推進標準ガイドライン」における非機能要件の項目を紹介します。
◆情報システムの非機能要件
・ユーザビリティ及びアクセシビリティ：使いやすく、誰もが支障なく利用できる設計に関する要件
・システム方式：ハードウェアやネットワークなど、システムの構成に関する要件
・規模：機器数やデータ量など、システムの規模に関する要件
・性能：応答時間や処理時間など、システムの性能に関する要件
・信頼性：稼働率など、システムの安定稼働に関する要件
・拡張性：将来的なシステムや機能の拡張性に関する要件
・上位互換性：バージョンアップ時のシステム改修の許容度などに関する要件
・中立性：標準的な技術や製品の利用に関する要件
・継続性：障害、災害などの問題発生時に求められる機能や復旧方針に関する要件
・情報セキュリティ：システムの情報セキュリティ対策に関する要件
・情報システム稼働環境：システムの構成や設置環境に関する要件
◆プロジェクトの進め方に関する非機能要件
・テスト：システムテストについて、テストの種類や合否判断基準などに関する要件
・移行：本番環境への業務移行、システム移行、データ移行の方式や対象に関する要件
・引継ぎ：システムの開発、運用において、他の関係事業者への引継ぎに関する要件
・教育：システム利用者の教育について、対象者や実施手順などに関する要件
・運用：システムの運用について、運用時間や運用環境などに関する要件
・保守：システムの保守について、サポート体制や保守環境などに関する要件
目次
よくある質問
なぜシステム発注において非機能要件が重要視されるのか？
非機能要件は、システムの品質・安定性・利用者満足度を左右する要素であり、契約や検収の基準とも直結するため重要視されます。
機能要件だけでは「動くシステム」は実現できても、「安心して使い続けられるシステム」にはならないためです。
非機能要件が重要な理由
1. 品質の基準を定めるため
・応答速度、稼働率、セキュリティ水準などは、利用者にとって不可欠な品質条件。
・明確に定義しなければ、システムが「使えるかどうか」の基準が曖昧になる。
2. 契約・検収の判断材料になるため
・非機能要件は契約上の性能保証やSLA（サービスレベル合意）の根拠となる。
・要件が曖昧なままだと、障害発生時や性能不満足時に責任分担が不明確となり、発注者に不利となる。
3. 運用コストやリスクに直結するため
・可用性や保守性が不十分な設計では、障害対応に多大なコストが発生する。
・セキュリティ要件を定義しないと、情報漏洩や法令違反といった重大リスクを招く。
4. 利用者満足度を左右するため
・機能が揃っていても「遅い」「落ちやすい」「使いにくい」システムは定着しない。
・非機能要件の定義は、利用部門の信頼を得るための前提となる。
非機能要件は、システムが安定して使われ続けるための土台であり、契約や検収をめぐるトラブルを回避する鍵でもあります。
発注者が主体的に定義・確認することで、品質を保証し、長期的な投資対効果を守ることにつながります。
非機能要件を定義しない場合、どのようなリスクが生じるか？
非機能要件を定義しない場合、契約上の責任分担が不明確になり、システム品質や運用コストに深刻な影響を及ぼすリスクが生じます。
機能要件だけでは「動くシステム」は作れても、「安定して使えるシステム」にはならないためです。
主なリスク
1. 品質の不確実性
・応答速度や稼働率を定義しないと、「遅い」「よく落ちる」といったシステムでも契約違反にならない。
・利用者満足度が低下し、現場での定着に失敗する。
2. 契約・検収トラブル
・可用性やセキュリティの水準が契約に明記されていないため、障害や不具合発生時に責任所在を巡る争いが発生する。
・発注者が不利な立場となり、追加コストや遅延を負担するリスクがある。
3. 運用コストの増大
・保守性や拡張性を定義しないと、システム改修や運用が属人的になり、長期的に維持費が膨らむ。
・設計段階で考慮不足だった非機能要件を後付けすると、改修コストが大幅に増える。
4. セキュリティ・法令違反リスク
・認証方式やログ管理を定義しなければ、情報漏洩や不正利用の危険性が高まる。
・個人情報保護法や内部統制基準を満たさず、監査で指摘を受ける恐れがある。
まとめ
非機能要件を定義しないことは、品質・契約・コスト・セキュリティの各面で発注者のリスクを増大させる行為です。
発注者は要件定義段階から非機能要件を明文化し、契約・検収・運用の基盤として確実に管理することが不可欠です。
非機能要件はどの段階で設定し、誰が責任を持つべきか？
非機能要件は、要件定義の初期段階から設定し、発注者が主体的に責任を持つことが望ましいです。
ベンダー任せにすると契約や検収の基準が不明確となり、後工程で品質やコストのトラブルに発展する恐れがあります。
設定すべき段階
1. 要件定義フェーズ
・機能要件と同時に非機能要件を定義することで、設計・開発の前提条件を明確化できる。
・開発途中で追加・修正する場合、設計やコストに大きな影響を与えるため、初期段階での合意が重要。
2. 契約締結前
・契約書やRFPに非機能要件を明記し、品質基準やSLA（サービスレベル合意）として担保する。
・契約段階で盛り込まないと、検収時に品質保証の基準が不明確になる。
責任を持つべき主体
1. 発注者（利用組織）
・「どのレベルの可用性やセキュリティが必要か」といった業務上の要件を定義する責任を持つ。
・利用部門・経営層と調整し、業務リスクや法規制を踏まえた基準を提示する。
2. ベンダー
・発注者が示した非機能要件を実現可能か検証し、設計や技術的な妥当性を担保する役割を持つ。
・発注者と共同でテストや検証方法を策定する。
非機能要件は、要件定義の初期段階から発注者が主体的に設定し、契約に明記することで品質・契約・検収の基盤となるものです。
ベンダーは技術的観点から支援しますが、最終的な責任は業務リスクを負う発注者側にあると考えるべきです。
非機能要件をベンダーに任せきりにすると、発注者にどのようなリスクが及ぶか？
非機能要件をベンダーに任せきりにすると、品質基準の不一致、契約上の不利、運用リスクの増大といった問題が発注者に跳ね返る可能性が高まります。
非機能要件は業務リスクや利用者満足に直結するため、発注者が主体的に定義・確認することが不可欠です。
発生しうるリスク
1. 品質基準の不一致
・ベンダーは自社の実装しやすさを優先し、利用者視点で必要な応答速度・可用性・セキュリティ水準を満たさない設計を行う可能性がある。
・結果として「動くが使えないシステム」となり、現場で定着しない。
2. 契約上の不利
・契約や検収基準に非機能要件が明記されないと、性能不足や障害発生時にベンダーの責任を問えない。
・発注者側が追加費用や障害対応コストを負担するリスクが高まる。
3. 運用・保守コストの増加
・保守性・拡張性が考慮されない設計となり、将来の改修や追加開発が高額化する。
・運用フェーズでの障害対応に時間と費用がかかり、長期的なTCOが上昇する。
4. セキュリティ・法令違反リスク
・ログ管理や認証方式が不十分なまま導入され、情報漏洩や法令違反につながる恐れがある。
・発注者側が監査やコンプライアンス違反の責任を問われる可能性がある。
非機能要件をベンダー任せにすると、「発注者が期待する品質」と「ベンダーが提供する仕様」に乖離が生じ、最終的に発注者が業務上の損失やコスト負担を負うリスクがあります。
発注者は、要件定義段階から自ら基準を示し、契約や検収に反映させる姿勢が求められます。
あわせてこの用語と記事をチェック
・非機能要求とは？検討に役立つガイドラインとあわせて分かりやすく解説！
この記事の編集者
武田 祥太郎
大学時代法学部で労働基準法の研究を進める中で日本の労働生産に課題を感じ、ITによる企業体質の健全化を目指して（株）グローバル・パートナーズ・テクノロジーに新卒入社。 民間企業のITガバナンス、マネジメント支援業務に従事し、同社のナレッジ活用知見を活かしてIT調達ナビで記事の展開にも携わる。
