設計対象:

IPA「非機能要求グレード」の大分類・中分類・小分類の項目体系を参照し、プロジェクトで必要な非機能要件項目を網羅的に洗い出す。

IPAの6大分類:

• 可用性: 継続性（稼働率、RTO、RPO）、耐障害性（冗長化、バックアップ）
• 性能・拡張性: 業務処理量（スループット）、応答性能（応答時間）、リソース効率性、拡張性
• 運用・保守性: 運用容易性（監視、バックアップ運用）、保守性（障害対応、設定変更）、移行性
• 移行性: データ移行、環境移行、共存性、互換性、ロールバック
• セキュリティ: 機密性（暗号化、アクセス制御）、完全性（監査ログ）、可用性（DoS対策）、真正性（認証）
• システム環境・エコロジー: 環境条件（OS、ミドルウェア）、準拠性（法規制、標準規格）、エコロジー（省電力）

具体的な進め方:

1. IPAグレード表のレビュー: IPAの項目一覧表（エクセル版）をダウンロードし、全ての中分類・小分類項目をレビューする
2. プロジェクト適用範囲の選定: システムの特性（Webアプリ、基幹システム、IoTなど）に応じて、対象となる項目を選定する
3. カスタマイズ項目の追加: IPAの標準項目で不足する場合、プロジェクト固有の項目を追加する（例：特定業界の規制対応）
4. 不要項目の除外: システムに該当しない項目（例：オンプレミス前提の項目をクラウドシステムでは除外）を明示的に除外し、理由を記録する

設計原則:

• 網羅性の確保: IPAの体系を活用することで、項目の抜け漏れを防ぐ
• ステークホルダーとの共通言語: IPAの標準用語を使用することで、顧客・開発・運用間のコミュニケーションを円滑にする
• トレーサビリティ: 各要件項目がIPAのどの分類に対応するかを明記し、体系的に管理する

文書化の推奨表現:

• 要件項目一覧の作成: IPA分類に沿って、適用する項目と除外する項目を一覧化する
• 除外理由の記録: 除外した項目については、その理由を明記する（例：「クラウド構成のため、物理機器選定は対象外」）

設計対象:

洗い出した各要件項目に対して、IPAの5段階グレード（Lv1〜Lv5）を参考に、システムに求められる目標レベルを設定する。

IPAグレードの考え方:

• Lv1: 最低限の水準（検証環境、限定利用）
• Lv2: 一般的な業務システムの水準（社内業務アプリ）
• Lv3: 企業間取引・外部公開サービスの水準（SaaS、Webサービス）
• Lv4: ミッションクリティカルな水準（24時間365日稼働、高可用性）
• Lv5: 社会インフラレベルの水準（医療、金融基幹、公共インフラ）

具体的な進め方:

1. システム特性の分析: システムの重要度、利用規模、サービス時間、ビジネスインパクトを分析する
2. カテゴリ別のレベル設定: 大分類（可用性、性能など）ごとに全体的な目標レベルを決定する
3. 項目ごとの調整: 各項目の重要度に応じて、カテゴリの基準レベルから上下に調整する
4. コスト・スケジュールとの調整: 高グレード設定は開発・運用コストに直結するため、予算・納期とのバランスを考慮する
5. 顧客との合意: グレード設定と実現コストのトレードオフを顧客に説明し、合意を得る

設計原則:

• メリハリをつける: すべての項目を高レベルにするのではなく、重要度に応じてメリハリをつける
• ビジネス要件との紐付け: 各グレード設定の根拠をビジネス要件やSLAと紐付けて説明する
• 段階的な向上: 初期リリースではLv2、将来的にLv3へ向上など、段階的なアプローチも検討する
• 比較可能性: 同業界・類似システムのグレード実績を参考にする

文書化の推奨表現:

• グレード一覧表の作成: 各要件項目に対する目標グレード（Lv1〜Lv5）を記載した一覧表を作成する
• グレード設定根拠の記録: なぜそのグレードを選定したのか、ビジネス要件との関係を明記する
• コスト影響の明示: 高グレード設定による開発・運用コストへの影響を記録する

設計対象:

設定したIPAグレードを参考に、各要件項目に対して具体的な目標値（定量的な数値・基準）を定義し、測定方法を明確にする。

具体例:

• 稼働率（可用性）:
  • Lv2: 月間稼働率99.0%以上 → 測定方法：監視ツールによる稼働時間記録
  • Lv3: 月間稼働率99.9%以上 → 測定方法：同上
  • Lv4: 月間稼働率99.99%以上 → 測定方法：同上
• 応答時間（性能）:
  • Lv2: 主要画面の応答時間5秒以内（平均値） → 測定方法：APMツールによる実測
  • Lv3: 主要画面の応答時間3秒以内（90パーセンタイル） → 測定方法：同上
  • Lv4: 主要画面の応答時間1秒以内（90パーセンタイル） → 測定方法：同上
• RTO（可用性）:
  • Lv2: 障害発生から4時間以内に復旧 → 測定方法：障害訓練
  • Lv3: 障害発生から1時間以内に復旧 → 測定方法：障害訓練
  • Lv4: 障害発生から30分以内に復旧 → 測定方法：障害訓練

具体的な進め方:

1. IPAグレード表の参照: IPAグレード表には各レベルの目安値が記載されているため、それを参考に目標値を設定する
2. 既存実績の参照: 既存システムの実績値や業界標準値を調査し、現実的な目標を設定する
3. 測定条件の定義: 目標値を測定する際の前提条件（想定ユーザー数、データ量、測定時間帯など）を明確にする
4. テスト・検証方法の定義: 受入テストや負荷試験で目標達成を検証する方法を定義する

設計原則:

• SMART原則の適用: 目標値はSpecific（具体的）、Measurable（測定可能）、Achievable（達成可能）、Relevant（関連性）、Time-bound（期限）であること
• 測定可能性の確保: 主観的な表現（「十分な性能」など）ではなく、定量的な数値目標を設定する
• 検証可能性の確保: テストや監視ツールで客観的に検証できる目標値とする
• 現実的な設定: 技術的・コスト的に実現可能な範囲で目標を設定し、過度な要求を避ける

文書化の推奨表現:

• 目標値の明記: 各要件に具体的な数値目標を記載する（例：稼働率99.9%、応答時間3秒以内、RTO30分以内）
• 測定方法の明記: 目標達成をどのように測定・検証するかを記載する（例：監視ツール、負荷試験、脆弱性診断）
• 測定条件の明記: 測定時の前提条件（同時接続数、データ量、ネットワーク帯域など）を明確にする
• IPAグレードとの対応: 各目標値が対応するIPAグレードを記載し、トレーサビリティを確保する

設計対象:

定義した非機能要件（IPAグレード、目標値）について、顧客や運用チームなどのステークホルダーと合意を形成し、必要に応じてSLA（サービスレベル合意）として正式に文書化する。

具体的な進め方:

1. 顧客へのプレゼンテーション: IPAグレード表を用いて、各カテゴリの目標レベルと実現コストのトレードオフを説明する
2. レベル調整の協議: 顧客の期待値とコスト制約を踏まえ、必要に応じてグレードを調整する
3. 運用チームとの調整: 監視・保守体制、障害対応手順、バックアップ運用などの実現可能性を運用チームと確認する
4. SLA文書の作成: 必要であれば、稼働率保証、サポート対応時間、ペナルティ条項などを定義したSLA文書を作成する
5. 合意記録の作成: 合意内容を議事録や承認記録として残し、変更管理の起点とする

設計原則:

• 透明性の確保: IPAグレードという客観的な基準を用いることで、目標レベルの設定根拠を明確に説明する
• 現実的な合意: 過度な期待値を調整し、技術的・予算的に実現可能な範囲で合意を形成する
• 変更管理の仕組み: 要件変更が発生した場合の変更管理プロセス（グレード再評価、コスト再見積もり）を合意しておく
• 責任範囲の明確化: システム提供者と利用者の責任分界点を明確にする（例：ネットワーク障害は責任範囲外）

文書化の推奨表現:

• 合意記録の作成: ステークホルダーとの合意内容（IPAグレード、目標値、実現方式）を議事録や承認記録として残す
• SLA文書の作成: 外部提供サービスの場合、正式なSLA文書を作成し、契約書に添付する
• 制約事項・前提条件の明記: 非機能要件が成立する前提条件や制約事項を明記する（例：通常時の想定ユーザー数100名以下、計画停止を除く）
• IPAグレード表の添付: 合意文書にIPAグレード一覧表を添付し、各項目のレベルを明示する