【設計シリーズ:15】 非機能要件定義書 ― システムの「品質」を設計する羅針盤

概要

システム開発で見過ごされがちな「非機能要件」に焦点を当てた包括的な解説書です。機能要件が「何をするか」を定義するのに対し、非機能要件はシステムの性能、可用性、セキュリティといった「どのように動くか」という品質を定めます。

本書では、これらの要件をMermaid図で体系化し、各項目の具体的な目標設定（稼働率、RTO/RPO等）を詳述。さらに、関係者との合意形成を含む実践的な定義プロセスを紹介し、手戻りのない高品質なシステム構築を目指します。

はじめに：なぜ非機能要件が重要なのか？

システム開発プロジェクトにおいて、「どのような機能を作るか」を定義する機能要件は、常に注目の的です。ユーザーが直接触れ、ビジネス価値に直結するため、その重要性は誰もが認識しています。しかし、どれほど素晴らしい機能も、その土台となるシステムの品質が伴わなければ、絵に描いた餅に過ぎません。

「Webサイトの表示が遅すぎて、顧客が離脱してしまった」 「重要な取引の最中にシステムがダウンし、大きな損害が出た」 「個人情報が漏洩し、企業の信頼が失墜した」

これらはすべて、システムの非機能要件の定義が不十分であったり、見過ごされたりした結果として起こりうる悲劇です。非機能要件とは、システムの機能「以外」のすべての要件を指し、システムの「品質」や「制約」を定義するものです。具体的には、性能、信頼性、セキュリティ、運用性など、システムがどれだけ「うまく動くか」を規定します。

機能要件が「何をするか（What）」を定義するのに対し、非機能要件は「どのようにするか（How）」や「どれくらい良くやるか（How well）」を定義します。両者は車の両輪であり、どちらが欠けてもプロジェクトは成功にたどり着けません。

本稿では、この重要でありながらも見過ごされがちな非機能要件に焦点を当て、その定義、分類、そして実践的な策定プロセスについて、網羅的に解説します。システムの品質を担保し、プロジェクトを成功に導くための羅針盤として、ぜひご活用ください。

非機能要件の全体像：サンプル構成図

まず、非機能要件がどのような要素で構成されるのか、全体像を把握しましょう。以下に、主要な非機能要件の分類と、その具体的な項目例をMermaid形式の図で示します。これはあくまで一例ですが、多くのシステム開発で共通して考慮すべき項目を網羅しています。

graph LR
    Root("非機能要件定義書")

    subgraph "品質特性"
        Root --> A("可用性")
        Root --> B("性能・拡張性")
        Root --> C("運用・保守性")
        Root --> D("移行性")
        Root --> E("セキュリティ")
        Root --> F("システム環境・制約")
    end

    subgraph "可用性の詳細"
        A --> A1("稼働率目標(例:99.9%)")
        A --> A2("目標復旧時間(RTO)")
        A --> A3("目標復旧時点(RPO)")
        A --> A4("冗長化構成")
        A --> A5("バックアップ方式")
    end

    subgraph "性能・拡張性の詳細"
        B --> B1("レスポンスタイム")
        B --> B2("スループット")
        B --> B3("リソース使用率上限")
        B --> B4("将来のデータ量想定")
        B --> B5("スケーラビリティ方針")
    end

    subgraph "運用・保守性の詳細"
        C --> C1("監視・ロギング要件")
        C --> C2("構成管理")
        C --> C3("テスト容易性")
        C --> C4("システム運用手順")
        C --> C5("ドキュメント体系")
    end

    subgraph "移行性の詳細"
        D --> D1("移行対象データ・機能")
        D --> D2("移行方式(一括/段階)")
        D --> D3("移行時の停止時間")
        D --> D4("データクレンジング")
        D --> D5("移行リハーサル")
    end

    subgraph "セキュリティの詳細"
        E --> E1("認証・認可方式")
        E --> E2("アクセス制御")
        E --> E3("データの暗号化")
        E --> E4("脆弱性対策")
        E --> E5("監査ログ")
    end

    subgraph "システム環境・制約の詳細"
        F --> F1("対応OS・ブラウザ")
        F --> F2("インフラ環境(クラウド/オンプレ)")
        F --> F3("法令・コンプライアンス")
        F --> F4("外部システム連携")
        F --> F5("利用技術・言語")
    end

この図は、非機能要件が多岐にわたるカテゴリから成り立っていることを示しています。以降の章では、これらの主要なカテゴリについて、一つひとつ詳細に解説していきます。

1. 可用性 (Availability) - 「止まらない」システムのために

可用性とは、システムがユーザーや他のシステムから利用を要求されたときに、継続して稼働し、サービスを提供し続ける能力を指します。ECサイトであれば24時間365日注文を受け付けられること、工場の生産管理システムであれば計画通りに稼働し続けることが求められます。

可用性を定義する上で重要な指標は以下の通りです。

• 稼働率 (Availability Rate): システムが稼働すべき時間のうち、実際に稼働していた時間の割合です。「稼働率99.9%（スリーナイン）」といった形で目標を設定します。これは年間の停止時間が約8.76時間であることを意味します。99.99%（フォーナイン）なら約52.6分、99.999%（ファイブナイン）なら約5.3分と、0.1%の違いが大きな差を生みます。ビジネスの重要度と、それを実現するためのコストを天秤にかけて目標値を設定する必要があります。
• 目標復旧時間 (RTO: Recovery Time Objective): 障害発生時に、システムをどれくらいの時間で復旧させるかという目標時間です。例えば「RTO 1時間」と定めれば、障害発生から1時間以内にシステムを復旧させる必要があります。この時間が短ければ短いほど、ビジネスへの影響は少なくなりますが、高度な冗長化構成や迅速な復旧手順が必要となり、コストは増大します。
• 目標復旧時点 (RPO: Recovery Point Objective): 障害発生時に、どの時点のデータまで復旧させるかという目標です。「RPO 30分」と定めれば、障害発生直前の30分前までのデータは保証することを意味します。つまり、最悪の場合でも30分分のデータ損失で済むように、バックアップの頻度などを決定します。データの重要性に応じて、RPOをゼロに近づける（データ損失を許容しない）ことも可能ですが、リアルタイムでのデータ複製など高度な技術が必要になります。
• 冗長化 (Redundancy): システムの停止を防ぐために、機器やコンポーネントを複数用意しておくことです。Webサーバーを複数台で運用する（負荷分散）、データベースをプライマリとスタンバイで構成する（フェイルオーバー）などが一般的な例です。どのコンポーネントを、どのような方式で冗長化するかを定義します。
• バックアップ・リストア: データの損失に備え、データを複製（バックアップ）し、有事の際に元に戻す（リストア）ための要件です。バックアップの対象、取得頻度、保存期間、リストアの手順とテスト計画などを具体的に定めます。

2. 性能・拡張性 (Performance & Scalability) - 「快適さ」と「将来性」の担保

性能（パフォーマンス）は、システムが要求された処理をどれだけ速く、効率的に実行できるかを示す指標です。拡張性（スケーラビリティ）は、将来のユーザー数やデータ量の増加に対応して、システムの処理能力を柔軟に増強できる能力を指します。

• レスポンスタイム (Response Time): ユーザーが操作を行ってから、システムが応答を返すまでの時間です。「トップページの表示は2秒以内」「商品検索結果の95パーセンタイル値が3秒以内」のように、具体的な画面や処理ごとに、定量的な目標値を設定します。曖昧な「速く表示する」という表現では、開発者と利用者の間で認識の齟齬が生まれます。
• スループット (Throughput): 単位時間あたりにシステムが処理できる件数です。「1秒あたり100件の注文を処理できること（100tps）」「ピーク時に1分間で5000件のアクセスを処理できること」のように定義します。特にセール時や月末処理など、アクセスが集中する際の目標値を定めることが重要です。
• リソース使用率 (Resource Utilization): システムのCPU、メモリ、ディスクI/O、ネットワーク帯域などのハードウェアリソースを、どの程度使用するかという指標です。「通常時のCPU使用率は50%以下、ピーク時でも80%を超えないこと」のように上限値を定めます。リソースに余裕を持たせることで、突発的なアクセス増にも耐えられ、安定した性能を維持できます。
• 拡張性 (Scalability): 将来の負荷増にどう対応するかの計画です。
  • スケールアップ: サーバーのCPUやメモリをより高性能なものに交換する垂直スケーリング。
  • スケールアウト: サーバーの台数を増やす水平スケーリング。 どちらの方針を主軸にするか、あるいは両方を組み合わせるかを定義します。クラウド環境ではスケールアウトが一般的であり、オートスケーリング（負荷に応じて自動でサーバー台数を増減させる機能）の要件を定義することも重要です。

3. 運用・保守性 (Operability & Maintainability) - システムを「育て続ける」ために

システムは作って終わりではありません。日々の安定稼働を支える「運用」と、時代の変化や新たな要求に応えるための「保守」が不可欠です。運用・保守性は、これらの活動をどれだけ効率的かつ安全に行えるかを示す指標です。

• 監視・ロギング (Monitoring & Logging): システムの健康状態を常に把握し、問題が発生した際に原因を迅速に特定するための要件です。
  • 監視: CPU使用率、メモリ使用量、ディスク空き容量などのリソース監視、サービスの死活監視、レスポンスタイムの性能監視など、何を監視するかを定義します。異常を検知した際の通知方法（メール、チャットツールなど）も定めます。
  • ロギング: いつ、誰が、何を操作したかの監査ログ、エラー発生時の詳細情報を示すエラーログ、システムの動作記録であるアクセスログなど、どのようなログを、どのレベル（詳細度）で、どれくらいの期間保存するかを定義します。
• 構成管理 (Configuration Management): サーバー、OS、ミドルウェア、アプリケーションのバージョン情報など、システムの構成情報を正確に管理することです。手作業による設定変更はミスの原因となるため、Infrastructure as Code (IaC) ツール（Terraform, Ansibleなど）を用いてコードで管理する方針を定めることもあります。
• テスト容易性 (Testability): 機能追加や修正を行った際に、その変更が他の部分に悪影響を及ぼしていないか（デグレード）を効率的に確認できる能力です。単体テストや結合テストを自動化するためのフレームワーク導入や、テストデータ作成の容易さなどを要件として定義します。
• ドキュメント (Documentation): 運用マニュアル、障害時対応手順書、設計書など、運用・保守に必要なドキュメントの種類と、その更新ルールを定めます。ドキュメントが陳腐化すると、属人化が進み、安定した運用が困難になります。

4. 移行性 (Portability / Migration) - 新旧システムを「繋ぐ」ために

新しいシステムを導入する際、多くの場合、既存のシステムからのデータや機能の移行が伴います。移行性は、このプロセスをどれだけスムーズかつ安全に行えるかを示す指標です。プロジェクトの最終段階で大きな課題となることが多く、初期段階での定義が極めて重要です。

• 移行対象: どのデータを、どの機能（バッチ処理など）を新しいシステムに移行するのかを明確に定義します。不要なデータや機能は移行対象から外し、新システムをスリムに保つことも重要です。
• 移行方式:
  • 一括移行（ビッグバン移行）: システムを一度停止し、すべてのデータ・機能を一気に移行する方式。移行期間は短縮できますが、問題が発生した際の影響が大きく、切り戻しが困難です。
  • 段階的移行: 機能単位や拠点単位で段階的に移行する方式。リスクは分散できますが、新旧システムが並行稼働する期間が発生し、システム構成が複雑になります。 どちらの方式を選択するか、その理由と共に定義します。
• 移行期間と停止時間: 移行作業に要する時間と、それに伴うサービス停止時間を定義します。ビジネスへの影響を最小限に抑えるため、深夜や休日など、利用者が少ない時間帯に実施する計画を立てます。
• データクレンジングとリハーサル: 旧システムのデータには、重複や表記揺れ、不整合などが含まれていることが少なくありません。移行前にこれらのデータを整理・清掃（クレンジング）する計画を立てます。また、本番移行の前に、本番相当の環境でリハーサルを繰り返し行い、手順の妥当性や所要時間を確認することが不可欠です。

5. セキュリティ (Security) - システムの「信頼」を守るために

セキュリティは、システムとそこに格納されている情報資産を、不正アクセス、改ざん、破壊、漏洩などの脅威から守るための要件です。一度セキュリティインシデントが発生すると、金銭的な損害だけでなく、企業の社会的信頼を大きく損なうことになります。

• 認証・認可 (Authentication & Authorization):
  • 認証: 利用者が「誰であるか」を確認する仕組み。ID/パスワードだけでなく、多要素認証（MFA）の導入を検討します。
  • 認可: 認証された利用者が「何をしてよいか」を制御する仕組み。役割（ロール）に基づいてアクセス権限を管理するRBAC（Role-Based Access Control）などが一般的です。
• アクセス制御 (Access Control): ネットワークレベルでのアクセス制御（ファイアウォール、IPアドレス制限）や、特定の機能・データへのアクセス権限などを定義します。最小権限の原則に基づき、利用者に必要最低限の権限のみを付与することが基本です。
• データの暗号化 (Data Encryption): 通信経路上のデータ（SSL/TLSによる暗号化）や、データベースやファイルに保存されているデータ（保管データの暗号化）を暗号化し、万が一漏洩しても内容を読み取れないようにします。特に個人情報や決済情報など、機密性の高いデータは暗号化が必須です。
• 脆弱性対策 (Vulnerability Countermeasures): SQLインジェクション、クロスサイトスクリプティング（XSS）など、既知の脆弱性に対する対策を定義します。OWASP Top 10（Webアプリケーションの代表的な脆弱性リスト）などを参考に、セキュアコーディングの規約や、脆弱性診断の実施計画を定めます。
• 監査ログ (Audit Log): セキュリティインシデント発生時の追跡調査や、不正操作の検知のために、重要な操作（ログイン、個人情報へのアクセス、設定変更など）のログを記録します。誰が、いつ、どのIPアドレスから、何を行ったかを記録し、定期的にレビューする体制も定義します。

6. システム環境・制約 (System Environment & Constraints) - システムが立つ「土台」と「ルール」

システムは単独で存在するわけではなく、様々な環境や制約の上で動作します。これらを明確に定義することは、設計や開発の前提条件を固める上で不可欠です。

• プラットフォーム要件: システムが動作するクライアント（PC、スマートフォン）やサーバーの環境を定義します。
  • 対応OS・ブラウザ: Windows 11, macOS Sonoma / Google Chrome, Safari の最新版など、サポートするOSとブラウザ、バージョンを具体的に指定します。
  • インフラ環境: オンプレミスか、クラウド（AWS, Azure, GCPなど）か。クラウドを利用する場合は、利用するリージョンや具体的なサービスも定義します。
• 法令・コンプライアンス (Legal & Compliance): システムが準拠すべき法律、業界規制、ガイドラインなどを定義します。個人情報保護法、GDPR（EU一般データ保護規則）、クレジットカード業界のセキュリティ基準であるPCI DSS、医療情報システムのガイドラインなど、対象となるビジネス領域によって準拠すべき法令は異なります。
• 外部システム連携 (Interoperability): 他のシステムと連携する場合、その連携方式（API, ファイル連携など）、データ形式（JSON, XML）、通信プロトコル、連携するタイミングなどを定義します。連携先のシステムの制約も考慮に入れる必要があります。
• 技術制約 (Technology Constraints): 開発に使用するプログラミング言語、フレームワーク、データベースなどを指定します。企業の標準技術や、開発チームのスキルセット、ライセンス費用などを考慮して決定されます。これらの制約は、アーキテクチャ設計に大きな影響を与えます。

非機能要件定義の実践プロセス

では、これらの多岐にわたる非機能要件を、どのように定義していけばよいのでしょうか。以下に実践的なプロセスを示します。

1. 洗い出しと分類: まずは、考えられる要件を網羅的に洗い出します。ビジネス部門、開発チーム、運用チーム、インフラチームなど、様々なステークホルダーからヒアリングを行うことが重要です。洗い出した要件を、前述した「可用性」「性能」などのカテゴリに分類し、整理します。
2. グレード分けと優先順位付け: すべての要件を最高レベルで満たすことは、コストや納期の観点から非現実的です。要件ごとに「グレード」を設定し、優先順位を付けます。
   • 例（稼働率）:
     • Grade A: 99.99% (ミッションクリティカルな決済システム)
     • Grade B: 99.9% (主要なECサイト)
     • Grade C: 99.5% (社内向け情報共有サイト) ビジネスインパクトの大きさと、実現にかかるコストを評価し、どのグレードを目指すかを決定します。
3. 定量化と合意形成: 「使いやすい」「速い」といった定性的な表現は避け、可能な限り定量的な目標を設定します。「レスポンスタイム2秒以内」「RTO 1時間」のように、誰もが同じ解釈をできる具体的な数値で定義することが、後のトラブルを防ぐ鍵です。設定した目標値については、必ずすべてのステークホルダー間で合意を形成します。
4. 文書化とレビュー: 合意した内容を「非機能要件定義書」として正式に文書化します。このドキュメントは、設計、開発、テスト、運用のすべてのフェーズで参照される重要な成果物となります。完成したドキュメントは関係者でレビューを行い、認識の齟齬がないか最終確認します。

まとめ：品質という名の魂をシステムに吹き込む

非機能要件定義は、決して単なる技術的なチェックリストの作成作業ではありません。それは、システムの「あるべき姿」を描き、その品質という名の魂を吹き込む、創造的な設計活動です。

軽視されがちなこのプロセスに時間と労力をかけることは、手戻りの削減、開発の効率化、運用コストの低減、そして何よりもユーザー満足度とビジネス価値の向上に直結します。機能要件という骨格に、非機能要件という強靭な筋肉と神経を組み合わせることで、初めてシステムは真に価値あるものとして生命を宿すのです。

本稿が、皆様のプロジェクトにおいて、堅牢で信頼性の高いシステムを構築するための一助となれば幸いです。