📋 技術調査 - 非機能要求グレード

概要

非機能要求グレードは、IPA（独立行政法人情報処理推進機構）が策定した、システムの非機能要求を体系的に定義するためのツール群です。

策定の背景・経緯

システム開発における非機能要求（性能・信頼性・セキュリティ等）は、機能要求と比べてユーザと開発者の間で認識がずれやすい特性があります。IPA はこの課題に対処するため、2010年に初版を公開しました。

その後、セキュリティ脅威の増大やクラウドコンピューティングに代表されるシステム基盤の多様化が進み、初版では現状のシステム基盤に必要な非機能要求を定義することが困難になりました。IPA はこの変化に対応し、2018年4月に「非機能要求グレード2018」を公開しました。2026年3月時点で、2018年版が最新の公開バージョンです。

目的

ユーザと開発者が非機能要求の内容・レベルについて共通認識を持ち、認識齟齬を防止します。

2018年改訂のポイント

対象とする非機能要求の範囲

機能要求（What / 業務要求）以外のすべての品質特性を対象とします。具体的には、可用性、性能、運用、移行、セキュリティ、環境に関する要求を網羅します。

特徴

6大項目

グレード表の構造

モデルシステムによる社会的影響度分類

グレード表は、システムの社会的影響度に応じた3種類の典型モデルシステムに対応しています。

利用者はまず対象システムに最も近いモデルシステムを選定し、要求レベルの基準値とします。

段階的なレベル設定

各メトリクスはレベル0〜5の6段階で評価します。レベルが大きいほど実現の難易度と開発コストが高くなります。

ツール群

非機能要求グレードは複数のドキュメントで構成されます。

構造

システムコンテキスト図

コンテナ図

コンポーネント図

グレード表の内部構造

活用シートの構成要素

利用ガイド各編の構成要素

データ

概念モデル

情報モデル

大項目一覧

中項目一覧

モデルシステム一覧

レベル定義

レベルの値が大きいほど、実現の難易度が高くなり、一般的に開発コストが増加します。

代表的なメトリクスとレベルの具体例

A.1.1.1 運用時間（通常）- 可用性 > 継続性

A.1.2 サービス切替時間 - 可用性 > 耐障害性

B.2.1 レスポンスタイム - 性能・拡張性 > 性能目標値

構築方法

入手方法

• IPA公式アーカイブページからZIPファイルを無料ダウンロード
• ダウンロード前に使用条件ページで利用規約を確認
• 日本語版・英語版・中国語版の3言語版を提供

必要なツール

プロジェクトへの導入手順

1. IPA公式アーカイブページから日本語版 ZIP をダウンロード
2. 使用条件を確認し、プロジェクト内での利用ルールを決定
3. ZIP を展開し、ファイル構成を確認
4. プロジェクト用フォルダに活用シート（Excel）をコピー

非機能要求グレード2018/
├── 利用ガイド_利用編.pdf
├── 利用ガイド_解説編.pdf
├── 利用ガイド_活用編.pdf
├── グレード表.pdf / .xls
├── 項目一覧.pdf / .xls
├── 樹系図.pdf
└── 活用シート.xls

活用シートのセットアップ方法

• ZIP 内の 活用シート.xls をプロジェクト用にコピー
• シート内の「プロジェクト名」「システム名」「作成日」セルを記入
• モデルシステムの推奨レベル列を参照列として残し、プロジェクト固有の要求レベル列を追加
• 対象外の項目には「対象外」と記入し、その理由を備考欄に記録

活用シート（Excel）の基本列構成
┌────────────┬────────┬───────────────────┬────────────┬────────────┬──────┐
│ 要件ID     │ 小項目 │ メトリクス        │ モデルレベル│ 採用レベル │ 備考 │
└────────────┴────────┴───────────────────┴────────────┴────────────┴──────┘

グレード表のカスタマイズ方法

• Excel 形式のグレード表はプロジェクト要件に応じて改変可能
• 改変後も著作権表示 (c) 2010-公開年 情報処理推進機構 を維持
• 不要な項目行は削除せず非表示にする（削除すると追跡が困難になるため）
• プロジェクト固有のメトリクスを追加する場合は、既存行の下に追記
• 改変版を配布する場合、使用条件ドキュメントを必ず同梱

利用方法

モデルシステムの選定方法

システムの社会的影響度を判断基準として3つのモデルから1つを選定します。

グレード表の読み方・使い方

グレード表は6大項目・35中項目・118小項目・238メトリクスで構成されます。

• レベルは 0〜5 の6段階で表示
• 数値が大きいほど実現難易度とコストが高い
• 各モデルシステムの推奨レベルはグレード表に列として記載
• レベルはあくまでも難易度の参考値であり、要件定義の完成形ではない

グレード表の列構成イメージ
┌──────┬──────┬──────────┬──────────────────────┬────────┬────────┬────────┐
│大項目│中項目│ 小項目   │ メトリクス           │ モデル1│ モデル2│ モデル3│
├──────┼──────┼──────────┼──────────────────────┼────────┼────────┼────────┤
│可用性│継続性│稼働時間  │ システム稼働時間/日  │  Lv.1  │  Lv.3  │  Lv.5  │
└──────┴──────┴──────────┴──────────────────────┴────────┴────────┴────────┘

活用シートを使った非機能要求の合意プロセス

ユーザ企業と開発企業間でのグレード表活用フロー

段階的な要求レベルの設定方法

1. 選定したモデルシステムの推奨レベルを初期値として活用シートに転記
2. 事業責任者にシステムの業務優先度をヒアリング
3. ヒアリング結果に基づき重要項目のレベルを上下に調整
4. 予算・スケジュール制約とトレードオフを検討し、レベルを確定
5. 重要項目以外の項目は開発企業が推奨レベルのままドラフトとして提示
6. ユーザ企業と開発企業が全項目をレビューし、最終レベルを確定

重要項目の絞り込み方法

• 活用シートの「重要項目」フラグ列を使い、品質・コストへの影響度が高い項目を特定
• グレード表で重要項目としてマークされた項目（約100項目）を優先的に議論
• 全238メトリクスを一度に議論せず、重要項目から順に合意を推進
• 対象システムのビジネス特性（高可用性要求・セキュリティ規制等）に応じて追加の重要項目を設定
• 検討不要と判断した項目には「対象外」と記入し、理由を備考欄に残す

運用

プロジェクトライフサイクルにおける位置づけ

非機能要求グレードは、プロジェクト全フェーズで参照する基準として機能します。非機能要件に関するアーキテクチャ上の決定は、プロジェクト中期以降に変更すると手戻りが大きくなるため、プロジェクト初期での確定が必須です。

要件定義フェーズでの活用タイミング

設計・テストフェーズでの活用方法

設計フェーズ:

• 決定したグレードをアーキテクチャ選定の根拠として記録
• セキュリティレベルはネットワーク構成・認証方式の設計根拠に使用
• 可用性レベルは冗長構成・バックアップ設計の根拠に使用
• 設計書に「グレード表のどの項目・レベルに対応するか」を明記

テストフェーズ:

• 定義したメトリクスをテスト合格基準として使用
• 性能試験では「レスポンスタイム○秒以内」などのグレード値をそのまま合否判定に適用
• セキュリティ試験は設定したセキュリティグレードに基づいて試験項目を決定
• テスト結果が要求グレードを満たさない場合は設計に差し戻し

非機能要求の変更管理

非機能要件は要件定義後も変更が発生します。

• 変更要求にはグレード表の項目・レベルの変更箇所を明記
• 変更がアーキテクチャ・コスト・テスト計画に与える影響を評価してから承認
• 変更履歴をグレード表と要件定義書の両方に記録
• 変更承認後は関係する設計書・テスト仕様書を連動して更新

定期的な見直しプロセス

要件定義書に記録したグレードは、以下のタイミングで見直します。

• フェーズ完了時: 次フェーズの作業開始前に、前フェーズでの変更・判明事項をグレードに反映
• インシデント発生時: 障害や性能劣化が発生した場合、原因となったグレード設定を見直し
• 定期レビュー: 運用開始後1年ごとに、実績データとグレード目標値を照合して乖離を確認

プロジェクト規模別の活用方法

小規模プロジェクトで全238メトリクスを均一に確認することは現実的ではありません。モデルシステムのデフォルトグレードを活用して作業量を削減します。

ベストプラクティス

効果的な非機能要求の合意形成方法

合意形成は「重要項目 → その他項目 → 最終総確認」の順で段階的に進めます。

• 合意形成の起点を重要項目に限定し、議論の焦点を絞る
• 各項目にメトリクス（定量的指標）を必ず添付し、曖昧な合意を回避
• 「稼働率99.9%」のような具体的な数値で合意を取得
• 合意内容は都度文書に記録し、口頭確認のみで進めない
• 事業責任者など意思決定権を持つキーマンの承認を必ず取得

モデルシステム選定のコツ

モデルシステムの選定はグレード全体の初期値を決定するため、慎重に行います。

• 業務の社会的影響度（金融・医療・公共など）を最初の判断軸に使用
• システム停止時のビジネス損失規模を定量化してから選定
• 迷った場合は影響度が高いモデルを選び、後から緩和する方向で調整
• モデル選定の根拠を選定時の議事録に記録

ステークホルダーとのコミュニケーション方法

• グレード表を直接提示するより先に、業務への影響シナリオで説明（例: 「システムが1時間停止すると売上○○円の損失が発生します」）
• 図や表を活用して要件レベルを視覚化し、技術用語の理解ギャップを解消
• ユーザ企業側と開発企業側の担当者が同じグレード表を参照しながら確認
• 技術的な背景知識がないステークホルダーには、レベル差によるコスト・リスクの差異を具体例で提示

段階的な導入アプローチ

全項目を一度に導入することが組織的に難しい場合は、以下の順序で段階的に展開します。

1. パイロットプロジェクトで重要項目のみ適用し、成果を確認
2. 成果が確認できたら、関連システムへ適用範囲を拡大
3. 組織内で標準グレードを定め、プロジェクトごとのカスタマイズルールを整備
4. グレード表をプロジェクト標準テンプレートとして管理し、継続的に更新

他のフレームワークとの併用

非機能要求グレードは IT システム構築向けのフレームワークです。目的に応じて他の標準と組み合わせます。

トラブルシューティング

よくある失敗パターンと対策

ユーザ企業と開発企業の認識齟齬の解消方法

認識齟齬の主な原因は「ユーザ企業が非機能要件を当たり前品質として無意識に期待する」一方、「開発企業がその期待を把握できない」点にあります。

典型的なインシデント例:

これらはグレード表で定量的に合意していれば防止できたケースです。

対策:

• 要件定義の開始時にグレード表をユーザ・開発双方で同時に参照しながら確認
• 「〇秒以内」「稼働率○○%」など定量的な指標で合意し、解釈の違いを排除
• ユーザ企業の担当者に業務目線で「システムが使えない時間の許容範囲」を具体的に回答してもらい、その回答をグレードに変換する手順を採用
• 地方公共団体など発注経験が少ない組織には、地方公共団体版利用ガイドなど業種別の特化版を活用

要求レベルの過大・過小設定の回避方法

過大設定の回避:

• グレードを上げるとコスト・運用負荷・ユーザビリティにどう影響するかを具体金額・工数で提示
• セキュリティグレードを過度に上げると認証手順の増加でユーザビリティが低下することを事前に説明
• 「理想」ではなく「必要十分」を設定基準とすることをステークホルダーと合意

過小設定の回避:

• モデルシステムのデフォルトグレードを下限として扱い、理由なき引き下げを禁止
• 業務停止時の損失シナリオを提示し、ユーザ企業がリスクを具体的に認識できるようにする
• 類似システムの障害事例や性能問題の事例を参考資料として共有

グレード表の項目が多すぎる場合の対処法

大項目6・中項目35・小項目118・メトリクス238という項目数に対して、以下の絞り込み手順を適用します。

非機能要求の優先順位付けの困難さへの対処

優先順位付けが難しい主な原因は、複数の項目が相互に影響し合い、どれが重要かを単独では判断できない点にあります。

• 優先順位の評価軸を「プロジェクト目標への重要度」「システム全体への影響度」「技術的実現可能性」の3軸で評価
• 3軸を5段階でスコアリングし、合計点で優先順位を決定する簡易マトリクスを活用
• 評価結果が拮抗する場合は、コスト増加を伴う項目を後回しにして早期に低コスト項目の合意を固める
• 優先順位の判断根拠を記録し、後工程での「なぜこのレベルにしたか」の問いに対応

まとめ

非機能要求グレードは、IPA が提供するフレームワークであり、6大項目・238メトリクス・3つのモデルシステムにより、ユーザ企業と開発企業の間で非機能要求の認識齟齬を防ぎながら段階的にレベルを合意するための実践的なツール群です。既存の品質標準（ISO 25010 等）が「何を」定義すべきかを示すのに対し、非機能要求グレードは「どのレベルで」合意するかを段階的に導くフレームワークである点に独自の価値があります。要件定義フェーズでの早期導入と、重要項目からの段階的な合意形成が成功の鍵です。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

参考リンク

• 公式ドキュメント
  • 非機能要求グレード | IPA 独立行政法人 情報処理推進機構
  • システム構築の上流工程強化（非機能要求グレード）紹介ページ | IPA
  • 非機能要求グレード本体（日本語版）使用条件 | IPA
  • 非機能要求グレード2018 改訂情報 PDF | IPA
  • 非機能要求グレード 地方公共団体版 利用ガイド PDF
• GitHub
  • 非機能要求グレード 2018 早見表 | GitHub Gist
  • aws-hikinou-grade | GitHub
• 記事
  • 非機能要求グレードの歩き方 Index | Zenn/NTTデータ
  • 非機能要求グレードの使い方についてまとめてみた | Zenn
  • 非機能要件の進め方 | Zenn
  • IPA 非機能要件定義 | Zenn
  • IPA非機能要求グレードを基にした活用プロセス解説 | IT調達ナビ
  • はじめての非機能要件定義 IPA非機能要求グレード活用解説
  • 非機能要求グレードとは？6つのカテゴリと非機能要件を定義するポイント | Qbook
  • 非機能要件を定義するまでの道 | Qiita
  • IPA非機能要求グレードで整理する非機能要件定義の進め方 | Yapodu Tech Blog
  • ソフトウェアテスト観点からの非機能要件 | SHIFT