Yapodu Tech Blog

株式会社ヤポドゥの技術ブログです。

IPA非機能要求グレードで整理する非機能要件定義の進め方

いわゆるインフラ構築の業務を行う際に、まずは非機能要件定義から開始することが多くあります。 今回は非機能要件定義と使用される IPA の資料 非機能要求グレード について書いていきます。

非機能要件定義とは

そもそも、非機能要件定義とは何でしょうか？

Non-functional Requirements

非機能要件定義とは 非機能要件（Non-functional Requirements）、または品質属性（Quality Attributes）と定義されておりシステムが提供する具体的な機能以外に、持つべき重要な特性のことを指します。 例えば、性能、セキュリティ、ユーザビリティ、互換性といった属性がこれにあたり、これらはシステムの「機能」そのものではなく、求められる「特性」です。特定のコード行を記述して実装するものではなく、ソリューション全体から現れる特性と言えます。 顧客が要求するこのような属性は仕様書に記述される必要があり、プロジェクトに適用される要件の種類を決定し、適切なものを含める必要がある。

上記は要約となりますが、システムの具体的な機能やコードと異なる特性を仕様書としてまとめることと言えます。

非機能要求

非機能要求とは、クライアントがソフトウェアを通じて実現したい目的を具体化したもの、主にシステム基盤において実現される要求です。

IPA 非機能要求グレードとは

IPA 非機能要求グレード2018

www.ipa.go.jp

「非機能要求グレード」は、「非機能要求」についてのユーザと開発者との認識の行き違いや、互いの意図とは異なる理解を防止することを目的とし、非機能要求項目を網羅的にリストアップして分類するとともに、それぞれの要求レベルを段階的に示したものです。重要な項目から順に要求レベルを設定しながら、両者で非機能要求の確認を行うことができるツール群です。

非機能要件定義を進める際に、フレームワークのようにある程度のひな形や定義を使用し進めることができるようになります。

段階的な手順

IPAの非機能要求グレード内の利用ガイドには以下の手順が紹介されています。

  1. モデルシステムの選定
    • 規模やシステム内容に合うモデルを選択。
  2. 重要項目のレベル設定
    • 重要度の高いメトリクス（指標）に絞り込んだ上で、モデルとなるシステムを想定したレベル値の選択。
    • 各メトリクスの選択レベルを調整することで、目的のシステムへの要求に近づけていきます。
  3. 重要項目以外のレベル設定
    • 非機能要求の全項目について要求レベルを決定。

どのように進めるか?

ヤポドゥでは利用ガイドをベースにおおよそ以下の手順で進めます。

  • モデルシステムの選定と項目の絞り込みについて打ち合わせ等で認識合わせを行い、その後システムに沿った項目表（ヒアリングシート）を埋めていく流れとなります。
  • プロジェクトによって異なりますが、決定事項を Markdown や Word などで文章として記載し、非機能要件定義書として納品を行います。

非機能要求グレードに含まれていないもの

非機能要求グレードは2018年に更新されていますが、クラウドに関してはクラウド事業者のSLA（サービス品質保証）の確認やSaaS利用の導入事例が一部記載されているのみであり、実務的には補足的な内容にとどまっています。
そのため、具体的なクラウドサービス選定や実際の運用設計にあたっては、自身でより詳細かつ最新の情報を補完する必要があります。
AI（人工知能）やCI/CD（継続的インテグレーション/継続的デリバリー）といった比較的新しい技術領域や概念に関する記述は、現行のグレードには盛り込まれていません。
それらのグレードに含まれていない、あるいは記述が不十分な技術領域に関する非機能要件については、プロジェクトの具体的な内容や技術的特性を十分に考慮した上で、既存の評価項目に追記する形で整理するのか、あるいは独立した新たな評価項目として設定・管理するのかを、個別に検討し判断する必要があります。

非機能要求グレードに含まれていない項目記載の具体例

クラウドのサービス利用

クラウドネイティブなシステム設計では、使用するサービスに踏み込んだ検討が必要です。
非機能要求グレードで挙げられている可用性やセキュリティといった重要項目をクラウド環境に当てはめ、より具体的な非機能要件として定義していきます。 例えば、以下のような項目が考えられます。

重要項目

  • 可用性・SLA管理
    • 利用する各クラウドサービスの SLAを把握し、システム全体の目標SLA（例：99.99%）を達成するための設計になっているか。本番環境とその他での SLA を分ける必要がある際は使用すべきサービスのオプションを確認する。
    • 例: Aurora Cluster の有無
  • 性能・拡張性
    • オートスケーリング戦略、サーバーレス環境の複数インスタンス稼働
    • 例: ECSのAuto Scaling、初期起動タスク設定方針
  • セキュリティ
    • 最小権限の原則に基づいたロール・権限設計、定期的な棚卸し
    • 例: IAMポリシーの設計、複数環境時の IAM Identity Center の活用
  • 運用・保守性
    • クラウドプロバイダー提供の監視サービスの活用、アラート設計、通知体制
    • 例: Datadog, CloudWatchの活用、アラート設計、IaC - GitOpsの活用

AI（人工知能）活用

AIをシステムに組み込む場合、従来のシステムとは異なる品質特性が求められます。

  • 信頼性・精度
    • モデルの精度と再現性: AIモデルの予測精度（例：正解率、適合率、再現率）、再現性を担保するための仕組み。
    • 誤判定時の影響と対策: 誤った予測をした場合の影響範囲を特定し、そのリスクを低減・回避する策。
  • データの品質: 学習データの品質（正確性、網羅性、バイアスの有無）がモデルの性能に大きく影響するため、データ収集・管理プロセスも重要。
    • RAG (Retrieval Augmented Generation) のデータ元となるデータソースの選定、データの前処理、クリーニング、取り込み運用の設計。
  • セキュリティ・倫理:
    • 学習データの保護: 個人情報や機密情報を含む場合の適切なマスキング、匿名化。

CI/CD（継続的インテグレーション/継続的デリバリー）

プロジェクトによって記載は変わりますが、開発の迅速性と品質を両立するため、CI/CDパイプライン自体の非機能要件も定義するケースが増えています。 ただし、あくまでも非機能要件の一部であり、機能に紐づく品質などは別途定義する必要があります。

  • 効率性・速度
    • デプロイ頻度: どの程度の頻度でリリースを行えるようにするか。
  • 信頼性・品質
    • 自動テスト: CI/CD時の自動テスト方針
    • デプロイ戦略: Blue/Greenデプロイ、カナリアリリースなど、安全なデプロイ戦略の採用とロールバック手順の確立。
  • IaC のテスト
    • インフラ構成コードのテストと検証。
  • セキュリティ
    • パイプラインの保護: CI/CDツールやリポジトリへのアクセス制御、シークレット管理（例: GitHub Actionsのシークレット、Workload Identity連携）。
    • 脆弱性スキャン: コードやコンテナイメージに対する静的/動的解析、脆弱性スキャンをパイプラインに組み込む (例: Amazon Inspector)。
  • 運用・保守性
    • パイプラインの監視: パイプラインの実行状況、成功/失敗の監視と通知。

これらの項目はあくまで一例であり、AIや自動テストなどは機能要件にそのまま記載するほうがよいケースが多いです。
プロジェクトの目的、規模、技術スタック、規制要件などに応じて、必要な項目を取捨選択し、具体的な目標値を設定していくことが重要です。

非機能要件定義を非機能要求グレードに沿って進める利点

非機能要件定義を非機能要求グレードに沿って進めることには大きな利点があります。最新技術に関する項目が含まれていない場合もありますが、基本的な考え方や品質基準が体系的かつ網羅的に整理されており、実務において非常に有効な指針となります。また、情報技術に対して抵抗感や苦手意識を持つ関係者に対しては、「経済産業省が推奨する基準である」という公式な根拠を示すことで、客観的かつ説得力のある基準として利用でき、プロジェクト内での合意形成や品質保証において大きな効果を発揮します。