非機能要件定義の検討方法 – 成功させる４つのステップと検討ポイント

はじめに

要件定義工程では、クライアント業務要件をまとめる機能要件と、パフォーマンスやセキュリティ、運用時間など顧客の視点では見えにくい非機能要件の２つに分かれます。

非機能要件を十分に検討することで、耐障害性、保守性の実現、業務拡大に伴うサーバ拡張対応、セキュリティ対策のように、システム安定稼働を実現します。

そこで非機能要件定義の検討を進めていく方法について解説します。

非機能要件の検討方法は様々ですが、今回はIPA（独立行政法人　情報処理推進機構）の非機能要求グレードを利用する方法を紹介します。
ベンダ独自の基準を作成しても良いですが、公的情報を活用するほうがクライアントに説明するのが容易であり、他ベンダと共通言語で会話できるなどのメリットがあります。

非機能要求グレードはIPA（情報処理推進機構）より入手できます。
このサイトから非機能要求グレード本体の一括DLをクリックしてファイル取得します。

非機能要件の進め方

上記でダウンロードしたファイルには、PDFやExcelの非機能要求グレードが含まれています。
資料の詳細な説明については同封されているドキュメントを参照いただくとして、ここではグレード表の見方について簡単に説明します。

この表は、以下の大項目で体系立てされています。

• 可用性
• 性能・拡張性
• 運用・保守性
• 移行性
• セキュリティ
• システム環境・エコロジー

大項目には、さらに中項目、小項目と細分化していきます。
この小項目の中にも複数の指標があり、その数は238個もあるため、全部を検討するには膨大な時間がかかります。
それらを愚直にクライアントに丸投げしても、まったく進まないでしょう。

非機能要件を検討する場合、以下の４ステップで進めていくことになります。

STEP1
グレード表をもとに非機能要件で検討すべき項目を選定します。
このグレード表は、様々なプロジェクトに適用するため網羅的に項目を用意しています。
そのためプロジェクト特性を考えながら対象を選定していきます。
例えばバッチ処理がなければ、バッチ処理に関する検討項目は除外します。

STEP2
検討項目のレベルを想定で選択します。
各指標にはレベルが割り当てられており、数字が大きいほど難易度の高い要求となります。
開発チームは指標ごとに妥当と思われるレベルを選択していきます。

STEP3
指標のレベルをクライアントに確認します。
選択した指標のうち、クライアントに確認しなければ判断できない項目を対象に、クライアントへのヒアリングを実施します。
例えばシステムの運用時間については、夜間に業務を止めても問題ないのか、24時間無停止なのか確認していきます。

ここで注意ですが、単純に「どれがいいですか」と質問するだけではクライアントも判断できません。
その結果「24時間365日稼働で、あらゆる障害対策を盛り込んで・・・」というオーバークォリティになっていきます。
そのため非機能要件はコストとのトレードオフであることをクライアントに説明し、業務として妥協点を見つけることが必要です。

STEP4
非機能要件定義を作成します。
検討結果をもとに非機能の要件定義書を作成します。
クライアントに確認した事項はもとより、明確なのでクライアントに確認していない項目もドキュメントに明記します。

非機能要件の検討ポイント

グレード表をもとに検討を進めますが、項目が多いため何を対象にすればよいか迷うかもしれません。
そこで、どのシステム開発でも検討するであろうポイントに絞って説明します。
また後からトラブルになりやすいポイントも合わせて伝えます。

可用性

システムの安定稼働と業務継続、運用時間について定義します。

運用時間

運用時間は24時間稼働なのか、またはサービス停止してよい時間帯を設定できるのか検討します。
これはバッチ処理やバックアップなど業務時間外に実施すべき処理があるかよって変わってきます。
ただし業務観点から24時間無停止が求められる場合、データ更新バッチと利用者のアクセスが同時に発生しても対応できる仕組みなど、業務によっては難易度が非常に高くなる場合があります。

サービス切替時間

障害発生時にサービス切替により業務復旧するまでの許容時間について定義します。
この時間が短く、人手で対応できない時間を要求されるなら、クラスタなど自動で切替できる仕組みを検討します。
システム構成に影響を与える検討項目です。

目標復旧地点

ディスク障害などでデータ破損した場合に、どの時点までデータを復旧するのか定義します。
１日１回のバックアップから復旧するレベルであれば仕組みは簡単ですが、それまでのデータは破棄されます。
障害発生直前まで復旧しなければいけないのであれば、アーカイブログの活用であったりレプリケーションの導入など対策が必要です。
グレード表にはバックアップ関連の検討項目もあるため、そのインプット情報として目標復旧地点の定義が必要になります。

目標復旧時間

サービス切替で対処できない障害が発生したときに、業務再開するまでの時間を定義します。
土日や深夜帯に障害発生した場合も考慮する必要があります。
保守対応の場合、リカバリできるスキルを持ったエンジニアがすぐに手配できるとも限りません。
技術的対策だけでなく人間系の対応も含めた対策を考慮した時間設定をします。

業務停止時間を最小化するのであれば冗長化やクラスタ化の導入を検討します。
当然、復旧時間を短縮させるにはコストがかかります。

冗長化については、別記事「冗長化する４つの目的と冗長化の種類、構成の選択」を参考にしてください。

性能・拡張性

サーバ性能や将来の拡張性について検討します。

通常時の業務量

システムによって計測する情報は異なりますが、計測情報の想定値を定義します。
この情報はサーバ構成のサイジングでインプットとなります。

この想定を見誤るとサーバ負荷が高くなり性能劣化やシステム停止という問題につながることもあります。

CPU、メモリ、ディスク追加だけなら対処はしやすいですが、サーバ追加が必要になると大問題になります。
しかし、余裕を持たせすぎてオーバースペックになると、不要のコストがかかることになります。

業務量増大率

将来のサーバ負荷やデータ量増大について想定値を検討します。
業務量増大が見込まれる場合、サーバ増強により対処するスケールアップ、サーバ増設によるスケールアウトすることを意識してシステム構成を検討します。

スケールアップするなら、あらかじめサーバのCPU、メモリ、ディスクの空きスロット数を用意します。

スケールアップでは対処しきれない場合はスケールアウトを検討します。
その場合、サーバ増設することになるので容易に構築できるよう、仮想サーバやコンテナの活用といった対策を視野にいれながらインフラ検討します。

保管期間

ログやDBデータの保管期間を検討します。
データやログによっては、法令により保管期間が定められている場合があります。
それ以外でも業務として過去データを使うニーズなど、大量データを保管する必要がある場合があります。
ストレージ容量もそうですが、DBデータが肥大化するとデータ検索が遅くなる問題にもつながるため、データ退避したりテーブル設計を工夫するなど対策が必要になります。

運用・保守性

システムの運用、保守に関する検討を行います。

バックアップ

バックアップには、主に以下の情報を取得します。

システムバックアップ
サーバ全体のバックアップを取得します。
サーバ構成変更やアプリケーションを大きく変更する際に、サーバ全体のイメージデータを取得します。
システム障害でOSデータが破損するなどデータ復旧できない場合、このイメージデータを取得した時点まで復旧させます。

バックアップ／リストアについては、別記事「可用性を高めてシステム安定稼働させるための基礎知識」を参考にしてください。

データバックアップ
DBなどに格納しているデータをバックアップします。
可用性で検討した目標復旧地点まで戻すための対策を検討します。

良く使われる方法としてDBデータをダンプ出力することが考えられますが、その出力から故障発生時までのデータは救えません。
対策が必要であれば、アーカイブログなどDBデータの変更履歴をたどって復旧させる方法があります。
あらかじめ手順を整理しておけば、対策は難しくありませんが復旧作業に時間がかかります。

復旧時間を短縮させるためにはレプリケーションといった対策もありますが、構築のコストや難易度も上がるため、業務停止による影響と構築コストを天秤にかけて検討します。

運用監視

システムを監視し、トラブル発生時に素早く対策を取る必要がある場合は運用監視の導入を検討します。
サーバの稼働状況を人が24時間365日ずっと見ているのは現実的でないため、監視が必要であれば運用監視サーバを導入します。
監視レベルは後から検討でも良いのですが、システム保守体制にも関係していくため監視導入は初期に検討します。

パッチ適用ポリシー

このパッチ適用ポリシーはクライアントと揉めるポイントなので注意が必要です。
WindowsやLinuxサーバのOSパッチを適用するルールですが、「パッチをインストールするだけの話」のような単純な話ではありません。

OSパッチ適用前には疑似環境で動作検証する必要があります。
この作業だけでも工数がかかるためコストで揉めることになるのですが、問題はOSパッチを適用した結果、アプリケーションが正しく動作しなくなった場合です。
新しいOSのパッチに適用するためのアプリケーション改修する場合の費用調整が難しいです。
もしアプリケーション改修で対応できない場合、問題が起きる部分を除外してアップデートすることになりますが、この手順が非常に煩雑です。
また以降のOSパッチ作業もずっと除外し続ける必要があります。

保守契約を締結してから上記の問題が発生すると対処が非常に難しくなるため、非機能要件の時点で検討します。

システム異常検知時の対応

こちらも保守契約に関連する話ですがトラブルになりやすいポイントになります。

システム障害発生時、24時間365日対応するように言われることが多いのですが、その体制を組もうとすると保守費用が膨大になります。
ここでしっかりと調整しないと、障害発生するごとに土日、深夜を問わずエンジニアの電話が鳴ることになります。

緊急時でも稼働できるように冗長化するなど業務継続できる仕組みを導入し、トラブル発生時は翌営業日とするのが基本です。

24時間止められない高可用性のシステムの場合は、コールセンターの導入も検討しましょう。
ちなみにコールセンターは外部調達できます。

運用環境の構築

システムを運用するための環境について検討します。

開発環境や疑似本番環境といった機器についてはクライアントと調整する必要があります。
システム稼働させるだけなら不要ですが、開発で使用したり運用保守するために必要となる環境があります。
運用時の作業をイメージしながら検討することが重要です。

移行性

システム移行の方針を検討します。
現行システムから新システムに入れ替えるためのスケジュールや一括／多段階展開、役割分担など検討します。
移行はシステム開発のオプション作業のように見られることがありますが、新旧システムや運用を理解したうえで方針検討する必要があり難易度は高いため、経験を積んだエンジニアが対応します。

セキュリティ

昨今のシステム開発では、セキュリティ対策は必須です。
しかしセキュリティ対策を盛り込もうとすれば際限がないため、どこかで割り切る必要があります。

まずクライアントのセキュリティに対する組織規程やルールを確認して、取るべき対策が決まっているか確認します。
そのうえでセキュリティのリスク分析を行い、脅威と対策の検討を行います。

グレード表にもありますが、分析する脅威は以下の観点から確認します。

• アクセス・利用制限
• データの秘匿
• 不正追跡・監視
• ネットワーク対策
• マルウェア対策
• Web対策
• セキュリティインシデント対応／復旧

セキュリティレベルが高いシステムの場合、上記とは別にセキュリティ診断やペネトレーションテストの実施についても検討します。

セキュリティ対策については、別記事「セキュリティ要件・設計で検討する方針・設計ポイント」で解説しています。

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

システムを取り巻く制約事項や特性、機材の設置環境や環境マネジメントについて定義します。

システム制約／前提条件

構築するシステムが法令や条例、社内規定などに制約を受けていないか検討します。
その中でも個人情報や機密情報の取り扱いは多くのシステムに関連するため注意が必要です。
また金融関係のシステムであれば、金融庁との連携も必要になってきます。

これらの制約／前提条件に抜け漏れがあると本番稼働することができません。
機能要件でも検討しているかもしれませんが、整理したうえでプロジェクト計画書にも反映していきます。

機材設置環境条件

オンプレミスの場合、設置する環境の耐震／免震性や設置スペースなど検討します。
電源設備についても、サーバ稼働させるための供給電力が不足しないか確認します。
サーバ室の空調や停電対策など、機器設置環境については検討すべきことが多数あります。

これらは経験者でないと気づかない点もあるため、自信がなければ有識者に相談するのが良いでしょう。