IPA非機能要求グレードとは
IPA非機能要求グレードは、システム開発・調達における非機能要求を発注者と受注者が漏れなく合意するためのツールです。IPA（情報処理推進機構）／SEC（ソフトウェア・エンジニアリング・センター）が2008年に公表し、システム共通基盤の要求項目とレベルを体系化しています。
機能要求は仕様書で詳細に書かれる一方、可用性・性能・運用といった「動き方」に関する要件は曖昧なまま発注され、後から認識齟齬で炎上するプロジェクトが多発していたことが、本グレードが生まれた背景です。
なぜ非機能要求が重要か
- 後戻りコストが大きい：可用性99.9%→99.99%への変更は、設計段階では数倍、運用後は10倍以上のコスト増
- SLAの根拠：稼働率・応答時間等のSLAは非機能要求が源
- 運用フェーズへの影響：監視・保守の工数は非機能要求に強く依存
- クラウド／SaaS時代も不変：パッケージ採用でも、非機能要件の合意は必須（共有責任モデル）
- システム障害の社会的影響：金融・公共系システム障害の多くは非機能領域（可用性・性能・運用）に起因
6大項目の概要
| 大項目 | 主な内容 | 代表的なメトリクス |
|---|---|---|
| A. 可用性 | 稼働時間、目標復旧水準、災害対策 | 稼働率（%）、RTO、RPO、MTBF |
| B. 性能・拡張性 | 応答時間、スループット、リソース拡張 | 応答時間（秒）、TPS、同時接続数 |
| C. 運用・保守性 | 運用手順、監視、保守性、バックアップ | 監視項目数、運用作業時間、復旧時間 |
| D. 移行性 | 移行スケジュール、データ移行、並行稼働 | 移行期間、移行データ量、停止時間 |
| E. セキュリティ | 認証、暗号化、ログ、不正監視 | 認証方式、暗号強度、ログ保管期間 |
| F. システム環境・エコロジー | 設置場所、温湿度、消費電力、騒音 | 消費電力、PUE、温湿度範囲 |
A. 可用性
- 運用スケジュール：平日日中のみ／24時間365日 等
- 目標稼働率：95％（月36時間停止）／99％（月7時間停止）／99.9％（月43分停止）／99.99％（月4分停止）
- RTO（目標復旧時間）：障害発生から業務再開までの目標時間
- RPO（目標復旧時点）：障害時に失われるデータの最大量（時間／件数）
- 災害対策：データセンター冗長化、遠隔バックアップ、DR訓練
B. 性能・拡張性
- 通常時／ピーク時の業務量：オンライン件数、バッチ件数、データ量
- 応答時間：オンライン処理3秒以内／検索2秒以内 等の目標値
- スループット：単位時間あたりの処理件数（TPS、件/分）
- 拡張性：将来の業務量増加に対する拡張余地（CPU・メモリ・ストレージ・帯域）
- キャパシティ計画：3年後／5年後の需要予測に基づく初期サイジング
C. 運用・保守性
- 監視：監視対象（サーバ、NW、アプリ）、監視項目、しきい値、通知方法
- 運用手順：日次／週次／月次／年次の運用作業、運用ドキュメント
- バックアップ：取得頻度、保管期間、保管場所、世代管理
- ジョブ管理：ジョブネット、エラー時の対応、リラン手順
- パッチ適用：適用方針、適用窓、テスト範囲
- 保守性：障害切り分け容易性、ログの取得粒度、リモート保守
D. 移行性
- 移行スケジュール：旧システムからの切替時期、許容停止時間
- データ移行：対象データ、件数、文字コード・形式の変換、データクレンジング
- 並行稼働：旧新システムを並行稼働する期間と方式
- 移行リハーサル：本番前のリハーサル回数、検証範囲
- 切戻し：移行失敗時の旧システム復帰手順
E. セキュリティ
- 認証・認可：パスワードポリシー、多要素認証、シングルサインオン、ロール設計
- 暗号化：通信（TLS）／保管（DB暗号化）の方式と鍵管理
- ログ：取得対象、保管期間、改ざん防止、SIEMへの連携
- 不正監視：IDS/IPS、WAF、EDR、アクセス権棚卸し
- 準拠：個人情報保護法、ISMS、PCI DSS、業界別ガイドライン
F. システム環境・エコロジー
- 設置環境：データセンターの耐震・耐火・温湿度・電源・ネットワーク冗長
- 消費電力／省エネ：消費電力上限、PUE目標、グリーンIT
- 騒音・振動：オフィス設置時の許容騒音レベル
- 耐用年数・廃棄：機器寿命、データ消去、リサイクル
3つのシステム基盤グレード
非機能要求グレードでは、システムの社会的影響度に応じた3つの基盤モデルが示されています。
| グレード | 社会的影響度 | 典型例 | 稼働率の目安 |
|---|---|---|---|
| 社会的影響が極めて大 | 停止により広範な社会活動に影響 | 金融基幹系、社会インフラ、政府ミッションクリティカル系 | 99.99%以上 |
| 社会的影響が大 | 停止により多数の利用者・取引先に影響 | EC基幹、企業基幹系、自治体基幹系 | 99.9%程度 |
| 社会的影響が限定的 | 停止しても影響は限定的 | 社内情報共有系、バックオフィス系 | 99%程度 |
各グレードで6大項目のレベルが推奨値として示されており、「自社のシステムはどのグレードに該当するか」を最初に決めると要件定義がスムーズに進みます。
RFP・要件定義・契約書での活用方法
1. RFPでの活用
RFP（提案依頼書）に非機能要求グレードのシートを添付し、項目ごとにレベル要望と具体値を明示。提案各社の前提条件を揃えられ、見積比較が公平になります。
2. 要件定義書での活用
機能要求と並列に「非機能要件一覧」セクションを設け、6大項目のレベル合意・具体値・測定方法を記載。発注者・受注者の合意ハンコを押す形で運用すると有効です。
3. 契約書・SLAでの活用
稼働率・応答時間・障害復旧時間といった主要メトリクスをSLAに転記し、未達時のペナルティ・改善義務を契約に組み込みます。
4. 運用設計での活用
運用フェーズの監視項目・運用手順書・バックアップ方針は、非機能要求グレードの「C. 運用・保守性」をベースに展開すると整合が取れます。
クラウド・SaaS時代の留意点
- 共有責任モデル：クラウド事業者と利用者の責任範囲を明確化。物理層は事業者、データ・設定は利用者の責任
- SLA確認：SaaS／IaaSが提示するSLAが自社の要求レベルを満たすか確認
- マルチリージョン：可用性目標が高い場合、複数リージョン構成が前提
- ガバメントクラウド：政府・自治体システムでは独自の非機能要件（FedRAMP相当のISMAP）を求められる
- 従量課金とキャパシティ：性能要件と月額コストはトレードオフ。スケーリングポリシーで両立
まとめ
IPA非機能要求グレードは、システム調達における非機能要求の合意ツールとして、機能要件偏重のプロジェクト失敗を防ぐ実践的な枠組みです。可用性・性能・運用・移行・セキュリティ・環境の6大項目を、社会的影響度に応じた3グレードで整理し、RFP〜要件定義〜契約〜運用の各フェーズで活用できます。クラウド／SaaS時代でもその有用性は変わらず、共有責任モデルとSLA管理を前提に、発注者・受注者の認識齟齬を防ぐ定番ツールとして使い続けられています。