はじめに
システム開発における要件定義というと、まず思い浮かぶのは「機能要件」ではないでしょうか。
たとえば、「どのような画面を作るか」「どのような業務フローにするか」「どのようなデータを管理するか」といった内容です。
一方で、インフラエンジニアが担当する基盤領域では、主に「非機能要件」を整理していくことになります。
しかし、この非機能要件というのが非常に難しい存在です。
機能要件は業務に直結するため利用者もイメージしやすいですが、非機能要件は「問題が起きなければ意識されない」ものが多く、お客様側もSIer側も軽視してしまいがちです。
そこで役立つのが、IPA（情報処理推進機構）が公開している「非機能要求グレード」です。
今回は、実際に業務で利用した経験を踏まえながら、非機能要求グレードの概要や活用メリット、そして実務上感じた注意点についてまとめます。
非機能要件とは何か
まず、非機能要件とは何かを整理しておきます。
非機能要件とは、システムの機能そのものではなく、「システムをどのような品質で動かすか」を定義する要件です。
代表的なものとしては以下があります。
- 可用性（どれくらい止められるか）
- 性能・拡張性（どれくらいの負荷に耐えるか）
- 運用・保守性
- セキュリティ
- 災害対策
- バックアップ
- 監視
- ログ管理
たとえば、業務システムで「検索機能を作る」というのは機能要件です。
一方で、
- 同時アクセス1000ユーザでも3秒以内に応答する
- 年間停止時間は4時間以内
- 障害時は30分以内に復旧する
といった内容は非機能要件になります。
特にインフラ領域では、非機能要件が曖昧なまま進むと後工程で大きな問題になります。
設計フェーズで「そんな可用性が必要だったのか」「DRサイトが必要だったのか」「監視対象に含まれると思っていた」といった認識齟齬が頻発するためです。
非機能要求グレードとは
そこで活用したいのが、IPAが公開している「非機能要求グレード」です。
非機能要求グレードは、非機能要件を体系的に整理するためのガイドラインです。
利用ガイドやExcel形式の活用シートも公開されており、無料で利用できます。
大項目は以下の6カテゴリに分類されています。
- 可用性
- 性能・拡張性
- 運用・保守性
- 移行性
- セキュリティ
- システム環境・エコロジー
さらに詳細項目まで含めると、全238項目が定義されています。
もちろん、これらをすべて要件定義フェーズで確定させる必要はありません。
重要なのは、
- 何を決める必要があるのか
- どこが未決事項なのか
- 誰が判断するのか
を漏れなく整理できる点にあります。
実務で感じた最大のメリットは「抜け漏れ防止」
実際に案件で利用して感じた最大のメリットは、「抜け漏れ防止」です。
インフラ要件定義では、経験豊富なメンバーがいる場合でも、案件ごとに考慮漏れが発生します。
以下のように細かな点が数多くあります。
- バックアップ保存期間
- ログ保管期間
- DR切替方式
- 運用監視の通知フロー
- メンテナンス時間帯
- 時刻同期
- ウイルス対策更新方式
- 証明書更新運用
非機能要求グレードを利用すると、「その項目を採用するかどうか」は別として、一度は確認する流れになります。
これが非常に大きいです。
実際、要件定義レビューでも、
「この項目、まだ決まっていません」
「今回は対象外です」
「クラウドサービス側で担保されています」
といった整理ができるため、後から「聞いていない」を減らしやすくなります。
また、若手メンバーにとっても教育効果があります。
インフラ経験が浅いと、そもそも「何を確認すべきか」がわかりません。
非機能要求グレードは、インフラ要件定義のチェックリストとしても非常に優秀だと感じています。
クラウド時代でも十分活用できる
「非機能要求グレードはオンプレ時代のものでは？」と思う方もいるかもしれません。
確かに、一部の項目はクラウドサービス側で吸収されるケースがあります。
たとえば、
- ハードウェア保守
- 電源冗長
- 物理セキュリティ
- データセンター設備
などは、AWSやAzure、IBM Cloudを利用する場合、利用者側で詳細設計しないことも多いでしょう。
しかし、だからといって非機能要件が不要になるわけではありません。
むしろクラウドでは、
- マルチAZ構成にするか
- バックアップ保持期間をどうするか
- IAM権限をどう分離するか
- 監視をどこまで実施するか
- 運用アカウントをどう管理するか
など、クラウド特有の検討事項が増えます。
そのため、「不要な項目は除外しつつ、必要な項目を整理する」という使い方が現実的です。
特に最近は、クラウドだから簡単というイメージだけで進み、運用設計が後回しになるケースもあります。
非機能要求グレードをベースにしておくことで、クラウド案件でも一定の品質を保ちやすくなると感じています。
ただし、非機能要求グレードだけでは不十分
一方で、実務上は「非機能要求グレードだけでは足りない」と感じる場面も多くあります。
これはかなり重要なポイントです。
非機能要求グレードは、あくまで「確認観点の整理」です。
そのため、実際の要件定義では以下のような資料も必要になります。
- システム構成図
- ネットワーク構成図
- サーバ一覧
- ソフトウェア一覧
- 環境一覧
- アカウント管理方針
- 運用体制図
特にクラウド案件では、アカウント設計や責任分界点の整理が重要になります。
たとえば、
- クラウドアカウントは顧客保持かSIer保持か
- 本番・開発・検証をどう分離するか
- 開発環境や検証環境にもDR環境を作るか
- 運用監視は誰が担当するか
など、案件固有のルールが必ず存在します。
これらは非機能要求グレードには直接書かれていないため、別途整理が必要です。
また、Excelシートだけで管理すると情報量が増えすぎて、読みづらくなる問題もあります。
実務では、
- 非機能要求グレード → チェックリスト
- 個別設計資料 → 詳細定義
という役割分担にするのが扱いやすい印象です。
非機能要件は「決めること」より「会話すること」が重要
最後に、実務で最も感じるのは、非機能要件は「正解を決める作業」ではなく、「認識を合わせる作業」だということです。
たとえば可用性一つ取っても、
- 本当に24時間365日必要なのか
- 夜間停止は許容できるのか
- DRサイトはどこまで必要なのか
は、お客様の業務特性によって変わります。
つまり、テンプレートを埋めれば終わりではありません。
非機能要求グレードの価値は、「会話のきっかけを作れること」にあります。
毎週少しずつでも会話し整理していくことで、ギャップを埋めることができます。
実際の案件でも、
「そこまで必要ですか？」
「その運用コストは許容できますか？」
「障害時の優先順位はどうしますか？」
といった議論を進めるための土台として役立つ場面が非常に多いです。
インフラ要件定義は、目立たない工程ですが、ここでの整理不足は後工程で必ず跳ね返ってきます。
だからこそ、非機能要求グレードのようなフレームワークをうまく活用しながら、抜け漏れの少ない要件定義を進めていくことが重要だと感じています。
コメント