IPAの非機能要求グレード：システムの品質を漏れなく考えるための実践ガイド

システムは、必要な機能が動くだけでは十分ではありません。利用者が増えても使えること、障害から復旧できること、安全に情報を扱えること、継続して運用できることが必要です。

IPAの「非機能要求グレード」は、こうしたシステムの品質や制約を体系的に確認し、利用者と開発者が必要な水準を合意するための公開資料・ツール群です。 企画、要件定義、設計、既存システムの見直しで、検討漏れを減らす土台になります。[1]

本記事はIPA資料の要約と、実務での進め方を組み合わせた解説です。以下の数値や対策例は本記事の例示であり、IPAが一律に求める基準ではありません。

非機能とは何か

機能要件は「何ができるか」、非機能要件は「どのような品質・条件でそれを実現するか」を定めるものです。

観点	機能要件の例	非機能要件の例
注文	利用者が商品を注文できる	ピーク時の負荷でも注文受付が目標時間内に完了する
顧客情報	顧客情報を登録・検索できる	権限のある担当者だけが参照でき、操作を追跡できる
帳票	日次レポートを作成できる	翌営業日の業務開始までに処理を終え、失敗時に再実行できる
サービス	Web画面から業務を行える	必要な時間帯に利用でき、障害時に許容時間内で復旧できる

非機能は「機能以外だから重要ではない」という意味ではありません。遅い、止まる、情報が漏れる、復旧できないシステムは、機能が揃っていても業務を支えられません。非機能要件は、顧客体験、事業継続、信頼、運用費用に直接関わります。

ここでは、関係者の希望・必要性を「要求」、それを具体化して合意した条件を「要件」として説明します。「非機能要求グレード」という名称ですが、実務では非機能要件を決めるために使います。

非機能要求グレードは何をするものか

IPAは、非機能要求の認識の行き違いを防ぐため、検討項目を分類し、それぞれの要求レベルを段階的に示しています。[1]

例えば「止まりにくくしてほしい」「十分に速くしてほしい」という希望のままでは、費用も構成も受入条件も決まりません。対象業務、稼働時間、許容停止時間、負荷、復旧目標などに分解し、関係者が同じ条件を理解できるようにします。

グレードは、システムに一つの点数を付ける認証制度ではありません。 各項目の必要水準を検討するための枠組みです。レベル番号の意味は項目によって異なるため、「全項目をレベル3」とするだけでは品質を説明できません。レベルの記述を確認し、最終的には具体的な値と条件を合意します。[4]

すべてを最高水準にすると、構築費だけでなく運用負担も増えます。事業への影響、リスク、予算、運用体制に応じて、水準を選ぶことが大切です。

網羅性が高く、システムを考えるうえで重要な理由

非機能要件は担当者の経験だけに頼ると、得意分野に偏りやすくなります。性能やセキュリティを確認していても、移行の切戻し、復元試験、保守体制などが抜けることがあります。

非機能要求グレードには、システム基盤に関する要求を広く、体系的に見渡せるという価値があります。チェックリストとして使えば、「検討した」「対象外と判断した」「まだ決まっていない」を区別できます。[2]

ただし、あらゆる非機能要件をこれだけで完全に網羅するものではありません。主な対象はシステム基盤です。画面の使いやすさ、アクセシビリティ、アプリケーション固有の品質、業界・契約に固有の条件などは、必要に応じて追加します。[4]

6つの分野と、具体的に決めること

IPAは非機能要求を次の6分野に整理しています。[2] 「決めること」と「対応・確認の例」は、本記事の実務向け整理です。

分野	決めること	対応・確認の例	決めない場合に起こり得ること
可用性	サービス時間、計画停止、稼働率、障害・災害時の復旧目標、許容データ損失	単一障害点の確認、冗長化、切替手順、バックアップ、復元・災害復旧訓練	業務時間中に停止し、再開時刻もデータ損失も予測できない
性能・拡張性	通常・ピーク時の処理量、応答時間、バッチ期限、データ増加、将来の拡張条件	負荷試験、容量計画、DB・アプリの性能改善、増強手順の確認	利用増加時に遅延・タイムアウトが発生し、業務処理が間に合わない
運用・保守性	監視、対応時間、役割分担、バックアップ運用、変更・保守、サポート	通知先・当番体制、手順書、復元試験、パッチ管理、変更の切戻し、保守契約	異常に気付かない、担当者不在で対応できない、変更後に復旧できない
移行性	移行対象、データ量、停止可能時間、移行方式、検証、切戻し条件	移行リハーサル、件数・金額・関連データの照合、所要時間測定、移行可否判定	データ欠落、停止時間超過、旧システムに戻せない状態が起こる
セキュリティ	保護対象、脅威、アクセス権、認証、暗号化、記録、検知・対応	最小権限、必要なMFA、鍵・秘密情報管理、脆弱性対応、監査ログ、対応訓練	不正アクセス、情報漏えい、操作の追跡不能、被害の拡大が起こる
システム環境・エコロジー	利用・設置条件、適合規格、電力・温度などの設備条件、環境負荷	環境条件の確認、設備・供給能力の確認、必要資源の適正化、不要資源の停止	設置・利用条件に適合しない、容量や電力が不足する、無駄な資源消費が続く

クラウドでも6分野を確認します。物理設備の一部を事業者が管理していても、利用者側には構成、設定、データ保護、監視、復旧手順などの判断が残ります。自社の担当範囲、事業者の担当範囲、提供条件で満たされる項目を記録してください。

どの資料を使うか

日本語の2018年版には、利用ガイド、グレード表、項目一覧、樹系図、活用シートなどが含まれます。[1]

資料	実務での使い方
利用ガイド	検討手順と考え方を理解する
グレード表	典型的なモデルを参考に、重要な要求の出発点を作る
項目一覧	詳細まで確認して漏れを減らす
樹系図	全体像と項目の関係を俯瞰する
活用シート	自社の対象システムに合わせて選択・調整した結果を記録する

実際の進め方

IPAの基本手順は、モデルシステムの選定 → 重要項目のレベル決定 → その他の項目のレベル決定です。[1] 以下は、その手順を実務の成果物・検証につなげる進め方です。

1. 対象と業務への影響を整理する

業務責任者、開発、インフラ、運用、セキュリティの担当者で、次を確認します。

• 対象業務、利用者、利用時間帯、外部サービスとの接続。
• 通常・ピーク時の利用量、データ量、今後の増加見込み。
• 停止、遅延、データ損失、情報漏えいが起きた場合の業務への影響。
• 予算、納期、運用人数、契約・社内規程上の条件。

2. モデルを選び、重要な項目から調整する

IPAには「社会的影響が殆どない」「社会的影響が限定される」「社会的影響が極めて大きい」という3つのモデルがあります。[2]

対象に近いものを出発点にし、事業の実態に合わせて調整します。会社の規模だけで機械的に選ばず、停止やデータ損失の影響を確認してください。

まず、構成や費用を大きく左右するサービス時間、復旧目標、ピーク負荷、セキュリティ、運用体制、移行時の停止条件などを決めます。

3. 項目一覧で漏れと矛盾を確認する

各項目を「採用」「対象外」「未決定」に分け、対象外には理由、未決定には担当者と期限を付けます。

次のような矛盾も確認してください。

• 夜間もサービスを提供するが、夜間の障害対応者がいない。
• 短時間復旧を目標にするが、バックアップからの復元に数時間かかる。
• データ損失を許容しないが、バックアップしかなく、直前の更新を回復できない。
• ピーク時の処理を保証するが、外部APIの利用上限を確認していない。

4. 測定できる要件と受入条件を書く

「高速」「高可用」「安全」ではなく、対象・条件・目標・確認方法を書きます。

以下は架空のWebサービスの例です。自社の業務に合わせて変更してください。

ID	要件の例	検証方法
NFR-A01	顧客向け主要操作の月間可用性を99.9%以上とする。測定対象・成功条件・計画停止の扱いを別途明記する	顧客操作を模した外形監視と障害記録から、合意した方法で算出する
NFR-P01	合意したデータ量・操作比率で、100リクエスト/秒の負荷を30分継続したとき、検索APIのp95応答時間を2秒以内、エラー率を0.1%未満とする	本番に近い構成で負荷試験を行い、遅延・エラー・資源使用量を確認する
NFR-A02	DB障害シナリオではRTOを60分以内、RPOを15分以内とする。計時開始と業務再開の判定条件を定める	復旧演習で経過時間と回復できたデータ時点を記録する
NFR-O01	サービス時間中は監視通知を担当者に届け、通知から15分以内に一次確認を開始する	通知試験と対応訓練で、配信・確認時刻を記録する
NFR-M01	本番移行の停止時間を2時間以内とし、主要データの照合合格後に公開する。超過・照合不合格時の切戻し条件を定める	移行・切戻しリハーサルと照合結果を確認する
NFR-S01	管理者の対話的ログインにはMFAを要求し、権限変更と重要操作の監査ログを保持する。保持期間・参照権限を合意する	MFA未実施時の拒否、権限制御、ログ生成・検索を試験する
NFR-E01	合意した設置先の電力・温度・スペース条件に収まり、余剰資源は四半期ごとに見直す	設備・構成の確認と資源使用量のレビューを行う

• p95：測定した応答時間の95%がその値以下となる指標。残りの遅い応答やエラーも確認します。
• RTO（Recovery Time Objective）：サービスを復旧するまでの目標時間。
• RPO（Recovery Point Objective）：どの時点までのデータを復旧するかという目標。15分なら、障害直前の最大15分相当のデータ損失を許容する想定です。

RTOとRPOは別の要件です。「早く復旧する」と「直前のデータまで戻せる」は分けて決めます。

5. 設計・費用・運用体制につなげる

要件ごとに、実現方式、担当者、費用、前提、依存先を整理します。「マルチゾーンだから大丈夫」「マネージドだから復旧できる」と済ませず、業務全体として目標を満たせるか確認します。

例えば、冗長化は機器故障には役立っても、誤削除されたデータの復元を保証しません。バックアップも取得するだけでは足りず、復元できることと所要時間を確認する必要があります。

外部サービスに依存する場合は、利用上限、障害時の動作、再試行、重複処理防止、連絡先も設計します。

6. 検証し、運用で見直す

要件IDを設計、試験、監視に対応付けます。満たせない条件があれば、設計変更、要件変更、残るリスクの承認を記録してから公開判断を行います。

公開後も、利用量の増加、障害、構成変更、運用人数の変更に合わせて再評価します。非機能要件は、稼働後の品質を確認する基準にもなります。

最初に作るべき成果物

実務では、次の情報を一つの要件台帳にまとめると進めやすくなります。

記録項目	記録する内容
識別と範囲	要件ID、IPAの該当項目、対象サービス・業務
要求水準	選択したレベル、その具体的な意味、目標値、測定条件
判断の根拠	業務への影響、選択理由、対象外の理由
実現と責任	設計方式、担当者、外部依存、費用
検証	試験方法、合格条件、結果、運用時の測定方法
未解決事項	未決定項目、期限、残るリスク、承認者・承認日

大切なのは表を埋めることではなく、必要な品質を合意し、実現し、確認できる状態にすることです。非機能要求グレードは、その判断を個人の経験だけに頼らず、体系的に進めるための有用な土台です。

公式資料と版の違い

IPAの紹介ページは誰でも閲覧でき、本体資料も公開されています。現在の紹介ページはアーカイブで、事業は終了しています。日本語の2018年版と、初版に分類された英語版を区別して利用してください。英語版を2018年版の完全な翻訳として扱わないようにします。[1][3]

1. IPA：非機能要求グレード紹介ページ
2. IPA：非機能要求グレード実践セミナー資料（PDF）
3. IPA：非機能要求グレード2018 改訂情報（PDF）
4. IPA：非機能要求グレード本体・英語版（ZIP） — Usage GuideのDescription Manualを参照。
5. IPA：非機能要求グレード2018・日本語版一括ダウンロード（ZIP）

資料を転載・改変して利用する場合は、紹介ページに掲載された使用条件を確認してください。