【非機能要件とは？】アプリケーション・Webサービス開発に必須の項目を解説｜弁護士監修

システム開発契約書には、システム品質を保証するために非機能要件を盛り込むことが欠かせません。特に、アプリケーションやWebサービスの開発においては、非機能要件を開発初期の段階で契約書に明記することで、開発側と発注側の期待値を調整し、トラブルを未然に防ぐことができます。本記事では、システム開発を委託する企業の経営層や法務担当者向けに、非機能要件の重要性とその定義方法について、契約書自動チェックサービス”Collabo Tips”[コラボ・ティップス]を監修するメリットパートナーズ法律事務所の弁護士が解説します。

機能要件と非機能要件

システム開発における要件定義は大きく機能要件と非機能要件の2つに分かれます。

1.     機能要件

これは、システムが果たすべき業務の機能そのものの要件です。例として「営業情報をシステムで共有したい」や「受発注情報に基づく在庫管理を行いたい」といったものが挙げられます。

2.     非機能要件

機能以外の要件であり、システム基盤やサービスが満たすべき要件です。例えば、「システムダウン時に3時間以内に復旧して欲しい」といった稼働率やセキュリティに関する要件です。

非機能要件の分類－IPAの「非機能要求グレード」

IPA（独立行政法人情報処理推進機構）は、非機能要件を整理し、ユーザーとベンダーが共通理解を持てるようにするためのツールとして「非機能要求グレード」を公開しています。これにより、発注者（ユーザー）による非機能要求の漏れや認識違いを防ぎ、システムの品質を確保することが可能になります（IPA「非機能要求グレード2018利用ガイド［解説編］」2頁参照）。

非機能要求は、以下の6つのカテゴリで分類されています。

1.     可用性

システムの稼働率や復旧時間に関する要求です。例えば、「システムは、24 時間電源を投入する。」、「大規模災害時には、１週間程度で復旧できるようにしたい。」といった要求です。

2.     性能・拡張性

システムのリソース使用効率や、将来的な拡張に対応できる能力を示します。具体的には、応答時間（例：レスポンスタイム1秒以内）や、同時接続数、データ処理能力、将来的な業務拡大に合わせた性能向上の計画（例：今後5年間で取引先が現在の2倍に増加しても対応可能な拡張性）などが含まれます。

3.     運用性・保守性

システム運用に関する要求です。例えば、システムが24時間稼働する場合、定期的なバックアップや監視体制、障害発生時の復旧手順が含まれます。

4.     移行性

旧システムから新システムへのデータ移行やシステム切り替えに関する要求です。移行時期や移行方法の選定、必要なツールや手順の策定が含まれます。

5.     セキュリティ

システムが満たすべきセキュリティ対策に関する要求です。これにはデータ暗号化、アクセス制限、認証・承認の仕組みなどが含まれます。

6.     環境・エコロジー

システムが運用される環境やエコロジーに配慮した要求です。例えば、エネルギー効率向上やCO2排出量の削減が求められることがあります。

IPAのスコープ外の項目

IPAの「非機能要求グレード」には含まれない項目もあります。これらは特定の業務アプリケーションや、製品選定に関するもので、以下の項目が該当します。

1.     業務アプリケーション関連の要件

システム基盤ではなく、業務アプリケーションに関連する要件です。例えば、ユーザビリティ（使いやすさ）や機能の豊富さ、移植性などが含まれます。

2.     製品やソリューションの選定

特定の製品やソリューションの選定に関する要件であり、個別のシステム構成や製品選定が対象となります。

非機能要件の定義方法

非機能要件を定義する際は、機能要件と同様に詳細な定義と合意が求められます。以下のステップで進めると効果的です。

1.     機能要件の確定

非機能要件を決定する前に、システムが満たすべき機能要件を決めておくことが重要です。これにより、非機能要件がシステムにどのように影響を与えるかを把握できます。

2.     システムの方向性確認

システムが基幹業務を担うか否か等により、可用性や性能の要求の厳格さは異なります。システムの規模や目的に応じて非機能要件を柔軟に設定します。

3.     非機能要件の草案作成

IPAの「非機能要求グレード」を参考にし、システムの要求に合わせたレベルで草案を作成します。発注者が自発的に草案を作成するのは難しいため、ベンダー主導で草案作成を進めることが有効です。

4.     発注者とベンダの合意

草案を発注者に提示し、フィードバックを受けて非機能要件を最終合意します。

5.     要件定義書の記載

最終的に、非機能要件を要件定義書に記載します。具体的で測定可能な形で記述することが、システム開発をスムーズに進めるために重要です。

まとめ

このように、非機能要件はシステム開発の品質を左右する重要な要素であり、初期段階での明確な定義と合意がプロジェクト成功に繋がります。