【インフラエンジニア必見】非機能要件を実現するための非機能要求グレード活用法を徹底解説 -

インフラエンジニアとは
非機能要件とは
1. 非機能要求グレード導入の目的
2. 非機能要求グレードの概要
非機能要求グレードの各項目の説明
さいごに
参考文献

インフラエンジニアとは

IT業界で活躍するインフラエンジニアは、システム基盤の設計・構築・運用を担い、ITシステムの非機能要件を満たすことが主な役割です。ここでいう「非機能要件」とは、システムの機能そのもの以外の要件を指し、例えば性能、信頼性、セキュリティなどがあります。独立行政法人情報処理推進機構（IPA）は、非機能要件を体系的に整理し、以下のように分類しています。

可用性
性能・拡張性
運用・保守性
移行性
セキュリティ
システム環境

インフラエンジニアは、非機能要件を満たすために技術的な工夫と知見を駆使して業務に取り組みます。自社サービスを提供する場合は、自ら非機能要件を明確に定義し、それに基づいてシステム開発を進められます。しかし、顧客から受託するシステム構築では状況が異なります。顧客が非機能要件を明確に定義できていないケースは珍しくありません。このため、インフラエンジニアにはコンサルタント的な視点も求められます。顧客と共に非機能要件を整理・検討し、要件定義を支援する能力が必要です。

インフラエンジニアの担当範囲はプロジェクトによって異なります。一般的にはサーバー、ネットワーク、ストレージといった物理機器に加え、仮想化ソフトウェアやデータベース、アプリケーションサーバーなどのミドルウェアも扱います。近年はクラウドサービスを導入する企業も増えており、クラウド環境の設計や運用も重要な業務です。インフラエンジニアは幅広い技術領域をカバーし、コンテナ技術やIaC（Infrastructure as Code）など最新の知識を常に学び続ける必要があります。技術が好きな人にとっては非常にやりがいのある分野といえるでしょう。

非機能要件とは

非機能要件については、独立行政法人情報処理推進機構（IPA）が公開している「非機能要求グレード」を参考にするのが一般的です。プロジェクトで独自の非機能要件が整理されていない場合でも、このグレードを活用することで一定の品質を確保できます。非機能要件の明確化に役立つため、積極的に活用することを推奨します。
参照リンク：IPA 非機能要求グレード

非機能要求グレード導入の目的

ITシステムを構築するベンダーと、それを発注する顧客との間で非機能要件を定義し、合意しておくことは非常に重要です。なぜなら、システムがある程度完成した段階で認識のずれが発覚すると、手戻りによる追加作業が発生し、コストや納期に大きな影響を与える可能性があるからです。さらに、必要なハードウェアのスペック不足により、最終的に要件を満たせないという深刻な問題に発展することもあります。しかし、ITシステム構築が専門ではない顧客にとっては、どの非機能要件をどのレベルで提示すべきか判断が難しいのが実情です。そこで有効なのが、IPAが提示している「非機能要求グレード」です。このドキュメントを活用することで、ベンダーと顧客は非機能要件について具体的かつ明確に合意でき、後の認識齟齬によるトラブルを未然に防ぐことができます。

非機能要求グレードの概要

非機能要求グレードは上述したとおり、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つのカテゴリで構成されています。適切に検討し、ステークホルダー間で合意を得ておくことが重要です。

非機能要求大項目	説明
可用性	システムサービスを継続的に利用可能とするための要求。稼働時間、障害・災害時の稼働目標（RTO/RPO など）を定義する。
性能・拡張性	システムの性能および将来の拡張に関する要求。スループット、レスポンスタイムなどの性能目標や、将来的な業務量増加に対応する要件を定義する。
運用・保守性	システムの運用と保守に関する要求。バックアップ、監視方法、各種保守作業の要件を定義する。
移行性	現行システム資産の移行に関する要求。移行方法、対象、スケジュールを定義する。
セキュリティ	情報システムの安全性確保に関する要求。コンプライアンス遵守、アクセス制御、暗号化、セキュリティリスク対策を定義する。
システム環境・エコロジー	システムの設置環境や環境への配慮に関する要求。耐震・免震構造、設置スペース、省エネ性、発熱・騒音などの制約条件を定義する。

非機能要求グレードの各項目の説明

前節で説明した非機能要求グレードの各大項目について、中項目と小項目を順を追って解説します。あわせて、実務経験で得られたノウハウも紹介しますので、ぜひ参考にしてください。
なお、本記事で紹介するノウハウは、以下のような前提条件を想定しています。

・比較的大規模で、ミッションクリティカルなシステム
・ITベンダーの立場でシステムを構築する視点

可用性

非機能要求大項目	非機能要求中項目	重要項目	主要な小項目 ※太字：重要項目
可用性	継続性	〇	・運用スケジュール・システムの稼働時間/停止運用・業務継続が要求される業務範囲・障害発生時の復旧水準・システム稼働率
	耐障害性		・サーバ、端末、NW機器、NW、ストレージ等の冗長性・データのバックアップ方式、復旧範囲
	災害対策		・大規模災害発生時の業務継続性に関する要求・大規模災害発生時のデータ保管に関する要求
	回復性	〇	・大規模災害発生時の復旧作業内容・可用性確認範囲

<継続性>
・オンライン処理、バッチ処理など処理方式が複数ある場合は、それぞれについて業務継続の方針を決めておいた方が良い。
・業務継続性の観点から、SPOF（単一障害点）が存在する場合は必ず明記しておきましょう。サーバやスイッチについては、冗長構成により業務継続性を確保するのが一般的です。ただし、例えばストレージ筐体については、単一構成を採用しているシステムも多く見受けられます。
・Active-Standby構成を採用している機器については、切替に要する時間を事前に合意しておきましょう。Active-Standby構成では、トラブル発生時の切替中に一時的な業務エラーが発生する可能性があります。運用開始後にトラブルが発生した際、顧客とのトラブルを避けるためにも、切替時間の目安を明確にしておき、試験により要件を満たしていることを確認しておくことが重要です。
・稼働率については、慎重に顧客と合意を図るようにしましょう。ミッションクリティカルなシステムでは、99.999％（年間で約5分の停止）という高い稼働率が求められることがありますが、オープンシステムでこれを実現するのは非常に難易度が高いと言えます。また、クラウドを利用するシステムにおいては、現時点では99.999％の稼働率を実現するのは困難です。そのため、各クラウドサービスのSLA（サービスレベルアグリーメント）を十分に確認し、全体としての稼働率を慎重に検討・設定することが重要です。

<耐障害性>
・物理機器については、部品レベルで冗長構成になっているかどうかをハードベンダに確認しましょう。

性能・拡張性

非機能要求大項目	非機能要求中項目	重要項目	主要な小項目 ※太字：重要項目
性能・拡張性	業務処理量	〇	・性能、拡張性に影響を与える業務量・システム稼働からライフサイクル終了を見越した業務量増分・ユーザ数、同時アクセス数、データ量、オンラインリクエスト件数、バッチ処理件数
	性能目標値	〇	・オンライン/バッチレスポンスタイム(システムにリクエストが与えてから、レスポンスを返すまでにかかる時間) ・オンライン/バッチスループット(システムが単位時間あたりに処理できる処理件数、データ量等)
	リソース拡張性	〇	・CPU、メモリの使用率・ディスク、ネットワークの使用率・サーバ処理能力の増強方法(スケールアップ/スケールアウト)
	性能品質保証		・ネットワーク帯域保障の有無・HWリソース占有の有無・性能試験の頻度および範囲・スパイク負荷発生時の対応(同時トランザクション数制限、Sorry動作等)

<業務処理量>
・一般的なWebシステムでは、大量アクセスからシステムを守るため、同時アクセス数に制限を設けることが多いです。ロードバランサーやWebサーバーなど、複数のポイントで流量制御を行うことが望ましいため、どの機器でどのような制御をするか、事前に検討しましょう。
・オンラインリクエスト数は、単位時間を明確に定義することが重要です。たとえば、バーストトラフィックに対応するため「1,000件/秒」に耐えられる構成を作ると、過剰スペックになる場合があります。要件としては、たとえば「10,000件/分」程度に設定し、バースト発生時も1分単位でみたときには要件を満たせているという形がITベンダーにとっては安全です。顧客と十分に議論し合意を得ましょう。
・業務量の増加見込みは事前に明確にしておく必要があります。特にオンプレミス環境の場合、リソース拡張に上限があることを留意してください。

<リソース拡張性>
・CPUやメモリの使用率を評価する際は、測定に使う単位時間を決めておくことが重要です。CPU使用率は瞬間的に大きく変動するため、単位時間を短くしすぎると過剰に見積もる恐れがあります。
・サーバの処理能力を増強する際は、スケールアップ（既存サーバの性能向上）にするかスケールアウト（サーバ台数の増加）にするかを、サーバの種類ごとに事前に決めておくことが望ましいです。特に物理サーバの場合、CPUやメモリ、ディスクなどの部品が販売終了していたり、増設用のスロットが埋まっていて拡張できない場合があるため、注意が必要です。
・ハードウェアリソースを占有する必要がある機器を選定しておきましょう。たとえば、システムの中核となるデータベースサーバは専用機として構築し、他のサーバの影響を受けにくくすることが一般的です。
・スパイク負荷が発生してもシステム全体が停止しない設計を検討しましょう。分散型サービス拒否攻撃（DDoS）対策製品の導入も有効な手段の一つです。

運用・保守性

非機能要求大項目	非機能要求中項目	重要項目	主要な小項目 ※太字：重要項目
運用・保守性	通常運用	〇	・運用時間(通常時、特定日(休日、祝祭日、月末月初など)) ・バックアップ(取得範囲、取得頻度、保存期間、取得方法) ・運用監視(監視対象、監視間隔) ・時刻同期の範囲
	保守運用	〇	・計画停止有無・運用負荷削減(保守作業自動化範囲) ・パッチ適用ポリシー(パッチ情報提供頻度、適用対象、適用タイミング、検証有無) ・活性保守の対象・定期保守頻度・予防保守(故障に至る前の予兆を検出した際の事前交換など)の頻度
	障害時運用		・復旧作業のやり方(手動/復旧製品/業務アプリによる復旧有無) ・代替運用の有無、範囲・システム異常検知時の対応(対応可能時間、駆け付け時間) ・交換用部材の確保レベル
	運用環境	〇	・開発用環境/試験用環境の設置・運用マニュアル提供レベル・リモートオペレーション有無・外部システム接続有無
	サポート体制	〇	・保守契約(ハードウェア/ソフトウェア) ・ライフサイクル期間(次回システム更改までの期間) ・メンテナンス作業分担(ITベンダと顧客間の役割分担) ・一時対応役割分担(ITベンダと顧客間の役割分担) ・サポート体制の要員・定期報告会の実施要否、頻度

<通常運用>
・バックアップの世代数や保存期間は、事前に明確に定義しておきましょう。これらはディスク容量の見積もりに大きく影響するため、要件次第では後からディスクの追加購入が必要になる可能性があります。また、バックアップ対象が複数ある場合は、対象ごとに要件を整理・明文化することを推奨します。
・運用監視はシステム安定稼働のために非常に重要です。何をどの間隔で監視するかを十分に検討しましょう。例えば、CPU使用率を5分間隔で取得している場合、トラブル発生時に原因特定が困難になることがあります。重要な項目については、システムリソースに影響を与えない範囲で、より短い取得間隔を検討すると良いでしょう。また、標準コマンドで取得できない項目については、スクリプトを独自に作成して監視対象に組み込む必要がある場合もある点に注意してください。

<保守運用>
・パッチ適用の方針や適用頻度は、事前に明確に定めておきましょう。パッチ適用には、影響範囲の確認やエージングを含む試験など、多くの手間と時間が必要です。緊急の脆弱性対応やサービス停止につながる重大バグ対応を除き、通常パッチは長期的なスパンで計画的に適用することを推奨します。
・パッチ適用の対象はOSやミドルウェアだけでなく、機器のファームウェアも含めて検討してください。機器ベンダーから定期的に情報を受け取れる仕組みを設け、早期に対応できる体制を整えることが重要です。
・活性保守（無停止でのメンテナンス）ができない対象は、あらかじめ明確にしておきましょう。ローリングアップデートに対応するコンポーネントでは活性保守が可能ですが、Active-Standby構成では切り替え時に瞬断が発生する場合があります。また、データベースのテーブル構造変更などではシステム停止が必要になる場合があります。これら活性保守が困難なケースは少なくないため、後々のトラブルを防ぐためにも、事前に顧客へ説明・共有しておくことが重要です。

<運用環境>
・可能な限り本番環境と同等の開発環境を用意できるよう、顧客と交渉しておきましょう。開発環境で十分な試験が実施できなかったために本番環境でトラブルが発生するケースは少なくありません。
あとで後悔しないように、必要性を具体的かつ明確に説明して理解を得ることが重要です。

<サポート体制>
・ハードウェアおよびソフトウェアの保守契約を念入りに確認しておきましょう。システムのライフサイクル中に、通常サポート期間が終了してしまうことは少なくありません。そのため、延長サポートの有無や、終了後のサポート内容（対応範囲・サービスレベルなど）について、あらかじめ明確にしておくことが重要です。

移行性

非機能要求大項目	非機能要求中項目	重要項目	主要な小項目 ※太字：重要項目
移行性	移行時期	〇	・移行スケジュール（移行期間、システム停止期間、並行稼働有無）
	移行方式	〇	・システム展開方式（段階的なシステム展開の有無）
	移行対象（機器）	〇	・移行設備（ハードウェア/OS/ミドルウェアなど）
	移行対象（データ）	〇	・移行データ量、データ形式・移行媒体（本数、種類）・変換対象（データ変換要否、変換ツール要否）
	移行計画		・移行作業分担（ITベンダと顧客の作業分担）・リハーサル（範囲、回数、外部連携試験有無）・トラブル対処（移行中の体制や計画）

<移行時期>
移行スケジュールについては、十分に検討する必要があります。顧客としてはサービス停止期間をできるだけ短縮したいと考えますが、ITベンダーとしては現実的かつ実行可能なスケジュールを提案し、リスクを最小化することが重要です。

セキュリティ

非機能要求大項目	非機能要求中項目	重要項目	主要な小項目 ※太字：重要項目
セキュリティ	前提条件・制約条件	〇	・情報セキュリティに関するコンプライアンス(法律、社内規定など)
	セキュリティリスク分析	〇	・セキュリティリスク分析(脅威の洗い出し、影響の分析範囲)
	セキュリティ診断	〇	・セキュリティ診断(ネットワーク診断、Web診断、DB診断など)
	セキュリティリスク管理		・セキュリティリスクの見直し(頻度、範囲) ・セキュリティリスク対策の見直し(運用開始後の脅威に対する整理) ・セキュリティパッチ適用(適用範囲、方針、タイミング)
	アクセス・利用制限	〇	・認証機能(認証有無、認証回数) ・利用制限(システムによる対策、物理的な対策) ・管理方d法(ルールの策定)
	データの秘匿	〇	・データ暗号化(伝送データ暗号化要否、蓄積データ暗号化要否)
	不正追跡・監視	〇	・不正監視(ログ取得、ログ保管期間、不正監視対象など) ・データ検証(デジタル署名有無、検証間隔)
	ネットワーク対策	〇	・ネットワーク制御(通信制御有無) ・不正検知(検知の範囲) ・サービス停止攻撃の回避(ネットワーク輻輳対策要否)
	マルウェア対策	〇	・マルウェア対策(対策範囲、リアルタイムスキャン要否、フルスキャン頻度)
	Web対策	〇	・Web実装対策(セキュアコーディング要否、WAF導入要否)
	セキュリティインシデント対応/復旧		・インシデント対応時の体制要否

＜ネットワーク対策＞
・近年、DDoS攻撃による被害が多発しているため、何らかの対策を講じることが望まれます。Akamai や Cloudflare などの外部サービスの利用も検討してください。

システム環境・エコロジー

非機能要求大項目	非機能要求中項目	重要項目	主要な小項目 ※太字：重要項目
システム環境・エコロジー	システム制約/前提条件	〇	・構築時の制約条件(法令、条例、社内規定などの制約) ・運用時の制約条件(法令、条例、社内規定などの制約)
	システム特性	〇	・ユーザ数・クライアント数・拠点数・地域的広がり・特定製品指定(顧客からの指定された製品の有無) ・システム利用範囲・複数言語対応
	適合規格	〇	・製品安全規格(規格取得の要否) ・環境保護(規格取得の要否) ・電磁干渉(規格取得の要否)
	機材設置環境条件		・耐震/免震(上限震度) ・スペース(設置スペース制限、拡張余地) ・重量(床荷重、設置対策) ・電気設備適合性(供給電力適合性、電源容量制約、停電対策など) ・温度（帯域）・湿度（帯域）・空調性能
	環境マネージメント		・環境負荷を抑える工夫(グリーン購入法利用、機材ライフサイクル検討) ・エネルギー消費効率・CO2排出量・低騒音

さいごに

インフラエンジニアの仕事は、非機能要件を満たすことにあります。そのため本記事では、非機能要求グレードについて説明してきました。検討すべき事項が多いため、すべての項目について最初から顧客と合意することが難しいプロジェクトもあるでしょう。しかし、少なくとも重要な項目については事前に検討し、十分に議論しておくことが大切です。非機能要求グレードを有効活用して要件定義をしっかりと行うことで、後工程での認識のずれによるトラブルを防ぐことができます。最後までお読みいただき、ありがとうございました。