---
title: システム開発 非機能要件 × セキュリティ＿20260815
tags:  #システム工学  
author: [Yukiko](https://image.docswell.com/user/yukiko_it)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/GEWGVQNMJ2.jpg?width=480
description: システム開発 非機能要件 × セキュリティ＿20260815 by Yukiko
published: August 15, 26
canonical: https://image.docswell.com/s/yukiko_it/K1Q77L-2026-08-15-202228
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/GEWGVQNMJ2.jpg)

システム開発 非機能要件 × セキュリティ
Why / What / How で学ぶ 実践学習資料
ISO/IEC 25010 ｜ IPA 非機能要求グレード 2018 ｜ OWASP ASVS ｜ NIST SP 800-53 / 800-63
うさうさ研修工房｜ YUKIKO
査読済み論文・公式標準ドキュメント準拠


# Page. 2

![Page Image](https://bcdn.docswell.com/page/47ZL4W3MJ3.jpg)

WHY
なぜ非機能要件が失敗プロジェクトを生むのか
機能要件は満たしていても、性能・可用性・セキュリティが原因で「使えないシステム」になるケースは後を絶たない
手戻り・炎上プロジェクト
契約・責任範囲の紛争
本番障害・機会損失
要件定義で非機能を扱わず、開発後半〜
リリース後に性能未達・障害が発覚し大規
模な作り直しが発生
「言った・言わない」の水掛け論となり、ベン
ダーとユーザ企業間の訴訟・追加費用トラ
ブルに発展
可用性設計の不備によるサービス停止は、
直接的損失に加え顧客信頼の毀損という
形で長期化する
Why｜非機能要件が問われる理由
2


# Page. 3

![Page Image](https://bcdn.docswell.com/page/YJ6W3GX5JV.jpg)

WHY
ビジネス・法令面のインパクト
顧客信頼とブランド毀損
コンプライアンス・監査対応
障害・情報漏えいは報道され、顧客離反・株価下落など定量化しづ
らい損失に直結する
個人情報保護法、業界ガイドライン等でセキュリティ・可用性の説
明責任が求められる
調達・RFPでの説明責任
運用チームの疲弊
官公庁・大手企業の調達では非機能要求グレードに基づく合意形
成が事実上の標準になりつつある
非機能要件の未整理は、リリース後の場当たり的対応・属人化・離
職リスクを高める
Why｜非機能要件が問われる理由
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/GJ5MLVXGJ4.jpg)

WHAT
機能要件と非機能要件の違い
機能要件（ Functional）
システムが「何をするか」を定義
•
画面・帳票・業務ロジック
•
入出力データの仕様
•
利用者から見える振る舞い
非機能要件（ Non-Functional）
システムが「どれだけ良く動くか」を定義
•
性能・拡張性、可用性
•
運用性、セキュリティ
•
移行性、環境・エコロジー
•
ISO/IEC 25010・IPA非機能要求グレードで体系化
出典：ISO/IEC 25000シリーズ用語定義（ソフトウェア品質要求評価：SQuaRE）に基づく整理
What｜非機能要件の全体像
4


# Page. 5

![Page Image](https://bcdn.docswell.com/page/9E29L3XD7R.jpg)

WHAT
ISO/IEC 25010：ソフトウェア品質モデル
国際標準が定める品質特性。2011年版は製品品質8特性・利用時品質5特性、2023年改定で構成が再編された
1
2
機能適合性
5
3
性能効率性
6
信頼性
4
互換性
7
セキュリティ
使用性
8
保守性
移植性
2011年版 製品品質モデル 8品質特性・ 31副特性（利用時品質は別途 5特性・11副特性）｜ 2023年改定でISO/IEC 25002・25010・25019に再構成
What｜非機能要件の全体像
5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/D7Y4Q18MEM.jpg)

WHAT
IPA非機能要求グレード 2018：6大項目
大項目6・中項目35・小項目118・メトリクス238。ユーザ企業と開発企業の認識齟齬防止を目的とした実務ツール
A. 可用性
B. 性能・拡張性
運用時間・目標復旧時間・稼働率
業務量、性能目標値、リソース拡張性
D. 移行性
E. セキュリティ
移行時期、移行方式、リハーサル
What｜IPA非機能要求グレード
アクセス制限、データの秘匿、監査
C. 運用・保守性
運用時間、バックアップ、監視・保守
F. システム環境・エコロジー
耐震、環境負荷、法令制約
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/VENYK2Q3J8.jpg)

WHAT
深掘り①：可用性 × 性能・拡張性
可用性 Availability
•
•
•
•
運用時間（24時間無停止／夜間停止 等）
目標復旧時間（RTO）／目標復旧時点（RPO）
稼働率（99.99％／95％等の目標値）
障害許容性（冗長構成・フェイルオーバー）
What｜非機能要件 深掘り
性能・拡張性 Performance
•
•
•
•
業務量（同時アクセス数・データ量の見積り）
性能目標値（応答時間、スループット）
リソース拡張性（スケールアップ／アウト）
性能品質保証（負荷試験、監視指標）
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/Y79PV1DPE3.jpg)

WHAT
深掘り②：運用・保守性 × 移行性
運用・保守性 Operability
•
•
•
•
通常運用（監視・バックアップ方式）
保守運用（パッチ適用、リリース手順）
障害時運用（一次対応・エスカレーション）
サポート体制（問合せ窓口、SLA）
What｜非機能要件 深掘り
移行性 Migration
•
•
•
•
移行時期（一括／段階移行のスケジュール）
移行方式（並行稼働、切替リハーサル）
移行対象（データ・プログラム資産の棚卸し）
切り戻し計画（ロールバック手順）
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/G78DP43X7D.jpg)

SECURITY
深掘り③：セキュリティ非機能要件
IPA非機能要求グレードE項目：前提条件の明確化から始まり、防止・検知・回復の3層で整理する
アクセス・利用制限
データの秘匿
ネットワーク制限、利用者制限、アクセス経路の制御
重要情報の暗号化、通信経路の暗号化（TLS等）
不正監視・検知
証跡管理・監査
不正アクセス検知、ログ監視、インシデント対応体制
アクセスログ、証跡の保存期間、監査対応
セキュリティ｜非機能要件としてのセキュリティ
9


# Page. 10

![Page Image](https://bcdn.docswell.com/page/L7LM16VNJR.jpg)

SECURITY
OWASP ASVS：アプリケーションセキュリティ検証標準
設計・開発・脆弱性診断で参照される、検証可能なセキュリティ要件の国際標準（
OWASP財団策定）
Level 1
Level 2
Level 3
最低限の防御
標準的な検証
最高レベルの保証
全Webアプリ共通の基礎ライン。ブラックボックス
診断で検証可能。OWASP Top10相当の重大脆弱
性を排除
機密性の高い業務データを扱うアプリ向け。ソー
スコードレビューを伴う深い検証が必要
医療・金融・重要インフラ等、侵害時の影響が極
めて大きいシステム向けの最高水準
認証カテゴリはNIST SP 800-63Bのデジタルアイデンティティガイドラインと整合。PCI DSS要件6・ISO/IEC 27001附属書A.14ともマッピングされる
セキュリティ｜国際標準
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/4EMYW5GQEW.jpg)

SECURITY
NIST SP 800-53 / SP 800-63：組織横断の統制基準
SP 800-53：セキュリティ管理策
SP 800-63B：デジタル認証
•
•
米国NIST策定、連邦情報システム向け統制カタログ
機密性・完全性・可用性を保護する管理策群
•
•
パスワード長・複雑性ポリシーの具体的指針
多要素認証（ MFA）導入の推奨
•
ASVS・ISO/IEC 27001・PCI DSSとも相互マッピング
•
認証情報のハッシュ化・ソルト保存の要求
•
民間組織もリスク低減の指針として任意採用可能
•
自動化攻撃（クレデンシャルスタッフィング等）対策
セキュリティ｜国際標準
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/PER9Y3ZKJ9.jpg)

HOW
非機能要件の定義プロセス
1
2
3
4
ヒアリング
テーラリング
レベル選定・合意
文書化・契約反映
業務量、想定利用者数、法令・契
約制約を確認
238メトリクスから対象プロジェクト
に必要な項目を絞込み
重要項目から優先し、ユーザ企業
と要求レベルをすり合わせ
要件定義書・RFP・契約書に非機
能要求を明記
出典： IPA「非機能要求グレード 2018 利用ガイド（利用編／解説編）」に基づく標準プロセス
How｜実践プロセス
12


# Page. 13

![Page Image](https://bcdn.docswell.com/page/P7XQG495EX.jpg)

HOW
グレード表を用いたレベル合意の実践
3つのモデルシステム：社会的影響度が「小」「中」「大」の 3グレードで主要項目の目安を提示し、自社システムの位置づけを素早く把握でき
る
優先順位付け
レベル＝目安と心得る
判断根拠を記録
「プロジェクト目標への重要度」「システム全体へ
の影響度」「技術的実現可能性」の3軸で評価し、
拮抗時はコスト増を伴う項目を後回しに
238メトリクスのレベル選択＝要件定義の完了で
はない。難易度の視認性を高めるための参考情
報として扱う
「なぜこのレベルにしたか」を記録し、後工程での
手戻り・認識齟齬の再発を防止する
How｜実践プロセス
13


# Page. 14

![Page Image](https://bcdn.docswell.com/page/37K94ZPR7D.jpg)

HOW
セキュリティ要件の実装・検証フロー
設計
開発
テスト
運用
ASVS Levelを選定し、対象カテゴリ
を要件定義書に反映
認証・アクセス制御・暗号化を実装
（SP 800-63B準拠）
ASVSチェックリストに基づく脆弱性
診断・ペネトレーション
ログ監視・インシデント対応・継続
的な統制評価（SP 800-53）
How｜実践プロセス
14


# Page. 15

![Page Image](https://bcdn.docswell.com/page/LJ3WLDXGJ5.jpg)

まとめ： Why × What × How
WHY
機能要件だけでは事業は守れない。信頼・法令・コストの観点から非機能要件は経営課題
WHAT
ISO/IEC 25010とIPA非機能要求グレードの 6大項目が、検討すべき範囲を体系的に示す
HOW
テーラリング→レベル合意→文書化、そして ASVS/NIST基準に基づくセキュリティ検証を反復する
面白きこともなき世を面白く うさうさ研修工房


# Page. 16

![Page Image](https://bcdn.docswell.com/page/8JDKNP2NEG.jpg)

REFERENCE
参考文献・出典
1
ISO/IEC 25010:2011 / 2023, Systems and software Quality Requirements and Evaluation (SQuaRE) — Quality models
2
独立行政法人情報処理推進機構（ IPA）『非機能要求グレード 2018』利用ガイド（利用編・解説編）、グレード表
3
OWASP Foundation, Application Security Verification Standard (ASVS) v5
4
NIST Special Publication 800-53 Rev.5, Security and Privacy Controls for Information Systems and Organizations
5
NIST Special Publication 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management
6
経済産業省 委託事業『システム及びソフトウェア品質の見える化、確保及び向上のためのガイド』
本資料はうさうさ研修工房（ALJ Education Plus株式会社）が上記公的標準・公式ドキュメントを基に編集した学習教材です。最新版は各発行元の公式サイトをご確認ください。
参考文献
16