「画面を速くしたい」「できるだけ止めたくない」という希望は、非機能要件を考える出発点になります。ただし、このままでは開発側が何を作り、発注側が何をもって確認するのかが揃いません。
非機能要件を決めるときは、利用条件、目標とその理由、確認方法、判断する人を一組で整理します。この記事では、要件を話し合うための表と、曖昧な希望を具体化する例を示します。特定の数値を推奨するものではありません。
非機能要件を項目の穴埋めで終わらせない
IPAの「非機能要求グレード2018」は、利用者と開発者の認識の食い違いを防ぐため、要求項目を分類し、要求レベルを段階的に示す資料です。重要な項目から要求を確認する使い方も説明されています。IPAの非機能要求グレード2018
この資料は2018版のアーカイブです。項目を確認する参考にしつつ、現在の対象システムや契約の条件に合うかを判断します。すべての項目で最も高い要求を選べばよい、という扱いにはしません。
まずは、そのシステムが使えないと誰の何の業務が困るのかを整理します。業務上の理由が明確になると、要件に必要な根拠や、費用との比較を議論しやすくなります。
一つの要求に五つの情報を付ける
以下は会議や要件整理に使うひな型です。値をまだ決められない欄は、決めるために必要な情報を残します。
| 情報 | 確認すること | 仮の例 |
|---|---|---|
| 対象と利用条件 | どの機能を、誰が、いつ使うか | 月末に管理者が集計画面を利用する |
| 業務上の理由 | 満たせないと何が困るか | 締め作業の確認が後続業務へ影響する |
| 要求する状態 | 何を満たしたいか | 想定するデータ量で待ち時間を許容範囲にする |
| 確認方法 | どの条件で、何を測るか | データ量と同時利用を決めて応答を測定する |
| 判断者と残る事項 | 誰が合意し、何が不足しているか | 業務担当が許容時間を判断し、件数見込みを補う |
「許容範囲」は、そのまま最終要件にはできません。業務上どれだけ待てるかを確認し、測定条件とともに判断できる値へ具体化します。根拠なく数値だけを置いて合意済みにしないことが大切です。
「速い」を、条件付きの要求へ変える
同じ画面でも、データ量や同時利用、処理の種類が違えば確認したい状態は変わります。対象操作を特定し、通常時だけでよいのか、業務上の混雑時も対象かを話し合います。
外部サービスを呼ぶ処理がある場合は、その待ち時間を含めて利用者の体験を評価するのか、システム内の処理を別に測るのかも整理します。どちらか一方だけの値を、説明なく全体の性能として扱わないためです。
実際の試験に落とし込む段階では、負荷試験計画の作り方で、測定条件や停止条件を別途整理できます。要件合意と試験実施はつながりますが、同じ作業ではありません。
「止まらない」を、業務への影響と復旧条件へ分ける
停止の影響は、時間帯や対象機能によって異なります。計画停止を許容できる時間、障害時に優先して戻す機能、手作業で代替できる業務があるかを確認します。
復旧までの時間と、どこまでのデータを戻す必要があるかも別の論点です。バックアップがあることだけで、業務が求める時間内に復旧できると決めないようにします。運用体制や確認方法まで含め、何を確認済みとするかを揃えます。
決めきれない項目は、調べる作業へ分ける
利用人数やデータ増加量が分からない場合は、仮の条件であることを明記し、調査担当と見直す時点を決めます。その前提が変わったときに、費用や構成、納期への影響を再確認する必要があるかも残してください。
最初の会議では、重要な機能一つについて、利用条件、業務上の理由、確認方法を揃えるところから始められます。未決定事項が見える状態にすることも、曖昧なまま実装へ進むのを防ぐための成果です。