Tsuzura

非機能要件の決め方

非機能要件を、対象、利用条件、指標、集計、合格基準、確認方法へ変え、技術選定とテストへ渡す手順です。

公開日
更新日

求めた機能が動いても、実際に利用できる品質かは別に判断します。待ち時間や停止には、受け入れられる条件が必要です。情報の扱い、利用できる人の範囲、変更のしやすさ、費用も同じです。その条件が決まっていないと、技術を比べる基準も、テストの合否も決まりません。

非機能要件は、サービスがどの利用条件で、どの程度の品質を満たす必要があるかを記録した要件です。「速い」「安全」と書くだけでは判断できません。対象と条件を固定します。そのうえで、測る量と集計方法を決め、合格基準と確認方法を対応づけます。値を決められない場合は推測せず、未決事項として判断者へ戻します。

この記事は、AIを補助に使いながら初めて小規模なWebサービスや業務システムを作る人を対象にしています。前提知識は必要ありません。読み終えると、一つのサービスまたは重要な利用経路（利用者が目的を完了するまでの一連の操作）について、技術選定とテストへ渡せる「非機能要件票」を作れます。

一機能分の要件と受入条件がまだない場合は、先に要件と受入条件の決め方を確認してください。この記事では、すべてのサービスへ共通する数値や、負荷テスト・セキュリティテストの詳しい手順は扱いません。監視製品の設定、公開後のサービス目標・復旧目標、個別の法令・契約判断も対象外です。

非機能要件が必要な理由

非機能要件が必要なのは、機能の有無だけでは、実際に利用できる品質かを判断できないからです。実装前に品質の条件を決めておくと、技術選定、設計、テスト、公開判断が同じ基準を参照できます。

機能が動くことと品質を満たすことは別

機能要件は、サービスが何をするかを定めます。品質に関する要件は、その機能やサービスが、どの利用条件で、どの程度の品質を満たすかを定めます。

IEEE Computer Societyのソフトウェア工学知識体系（SWEBOK V4.0a）は、非機能要件を、使う技術に関する制約と、解決方法が満たす品質水準に分けています。ただし、「非機能要件」という言葉の分類は資料や組織によって揺れます。この記事では判断を混ぜないため、次の三つに分けます。

種類 決める内容 本記事での扱い
機能要件 サービスが何をするか 入力として参照する
品質に関する要件 どの条件で、どの程度の品質を満たすか 対象、条件、測定、合格基準を決める
設計上の制約 採用または禁止する技術・環境 必要な理由と見直し条件を記録する

品質要件と設計上の制約を分ける

必要な結果と実現方法は別の判断です。品質に関する要件へ特定の製品名や構成を書いてしまうと、ほかの方法で同じ結果を満たせるか比較できなくなります。

特定の技術、規格、実行環境（コードやサービスを動かす本番・検証などの環境）を固定する必要がある場合は、設計上の制約として分けます。NASAの要件記述ガイドも、要件へ実装方法を混ぜないことと、性能値に許容範囲を持たせて検証可能にすることを確認項目にしています。NASAの正式な文書形式を小規模開発へそのまま当てはめる必要はありませんが、必要な結果と実現方法を分ける考え方は使えます。

制約には、固定する内容だけでなく、その理由と見直す条件も残します。理由を説明できない技術指定は、要件ではなく好みや未確認の前提かもしれません。設計の判断基準はソフトウェア設計の基本原則で扱っています。

必要な品質を選ぶ

すべての品質を同じ強さで求める必要はありません。利用条件と、品質を満たせない場合の影響を確認し、今回決める品質だけを選びます。

品質モデルは確認漏れを探すために使う

ISO/IEC 25010:2023の公開概要は、ソフトウェア製品の品質を九つの特性と下位特性で整理し、要件、設計、テスト、受入基準、測定へ使える参照モデルと説明しています。公開概要では特性名や詳しい定義までは確認できないため、この記事ではISOの正式一覧を転載しません。

品質モデルは、必要な観点の確認漏れを探すための参照です。すべての項目を必須にするチェックリストでも、合格値の一覧でもありません。次の表は、候補を絞るための本記事独自の整理です。

確認する品質 選ぶ判断 主に記録する条件
性能 待ち時間や、一定時間に扱う操作・要求の数（処理量）が利用へ影響する 同時利用や要求の集中（負荷）、測定の開始点と終了点、対象期間
信頼性 停止や誤った結果が利用や業務へ影響する 正常とみなす状態、対象となる事象、対象期間
セキュリティ 情報の閲覧、変更、操作を許す相手と範囲を守る必要がある 守る対象、想定する危険、確認項目、証拠
アクセシビリティ Webの画面や一連の操作について、適用する基準がある 基準の版と満たす段階（適合水準）、対象ページ、一連の操作
互換性 接続先や実行環境の違いが動作へ影響する 対応する範囲、依存先の条件、変更時の確認
保守性 担当者や変更頻度が、変更の安全性と所要時間へ影響する 変更の影響範囲、確認に使える時間、維持する責任者
容量 利用者数、データ量、外部サービスの利用量に上限がある 通常時と最大時の想定量、上限、見直し条件
費用 初期費用、継続費用、運用作業が採用判断へ影響する 費用の対象、対象期間、予算超過時の通知と見直し条件

この表は、候補を探す単位です。非機能要件票では、一つの品質だけを一件にし、その一件の測定方法、合格基準、判断者をそろえます。

対象外にする品質にも理由を残します。「今回は不要」と確認した状態と、存在を知らずに抜けた状態は区別が必要です。

利用条件と失敗時の影響から絞る

品質を選ぶときは、まず利用者、端末、接続環境を確認します。次に、同時利用や要求の集中（負荷）、データ量、時間帯、外部サービスを確認します。ISO/IEC 25019:2023の公開概要も、利用時の品質には利用状況の指定が必要で、その状況が変われば前提を指定し直すとしています。

次に、品質を満たせないときに何が起きるかを確認します。利用者が作業を完了できない、業務上の判断を誤る、情報が失われる、権限のない操作が通るなど、影響が大きい品質から条件を決めます。判断に必要な情報がなければ、対象外にせず未決事項へ移します。

費用とほかの品質への影響を確認する

品質は、一つだけを最大にすればよいわけではありません。SWEBOKは、非機能要件どうしに良い影響と悪い影響があり、求める水準には価値と費用の関係があると説明しています。

高い水準を求めるほど、構成、開発、確認、運用の負担が増える場合があります。反対に、費用を減らす判断が、性能、信頼性、セキュリティへ影響することもあります。選んだ品質ごとに、必要な理由、満たせない場合の影響、ほかの品質への影響を記録します。

曖昧な要求を判断可能にする

品質名や数値を一つ置くだけでは、非機能要件は完成しません。対象と利用条件を固定し、測る量、測る位置、期間、集計方法、合格基準、確認方法まで対応づけます。

対象と利用条件を決める

最初に、どのサービス、機能、または利用経路を対象にするかを一つ選びます。対応する機能要件と受入条件も参照できるようにします。

利用条件には、測定結果を変えるものだけを残します。まず、利用者の範囲と端末、接続環境を確認します。次に、同時利用や処理量、データの量と状態を確認します。対象時間と外部サービスも、結果を変える場合だけ残します。対象に含まない条件も明記すると、結果を別の利用状況へ誤って広げにくくなります。

測る量・位置・期間を決める

指標は、品質を判断するために測る量または判定規則です。指標名だけでなく、単位、算出方法（どう計算するか）、測る位置、元にする記録、測定期間を決めます。

Googleのサービス信頼性ガイドは、サーバー側の記録と利用者側の測定では見える範囲が異なること、集計期間と集計方法を分けて考えることを説明しています。これはGoogleのサービス運用に基づく実務資料であり、章内の数値を全サービス共通の基準としては使いません。

測る位置が違えば、同じ名前の指標でも意味が変わります。利用者が操作を始めた時点から測るのか、サーバーが処理を始めた時点から測るのかを記録します。測定期間も、テスト中の一定時間なのか、公開後の継続した期間なのかを分けます。

集計方法を決める

集計方法は、集めた測定値を合否判断へ変える方法です。主な方法には平均、割合、回数、最大値、パーセンタイルがあります。

パーセンタイルは、測定値を小さい順に並べたとき、指定した割合がその値以下に入る境界です。平均は全体の傾向を示せますが、一部の遅い処理や短時間の集中を隠す場合があります。同ガイドも、平均だけでは遅い側の分布を捉えられない条件を説明しています。どの集計方法が正しいかではなく、守りたい利用者の結果を判定できる方法かを確認します。

合格基準と確認方法を対応づける

合格基準は、測定や確認の結果を受け入れる条件です。合否の境目となる値（閾値）、許容範囲、満たすべき状態を、根拠とともに記録します。

ISO/IEC 25023:2016の公開概要は、品質尺度の合否範囲を一律には割り当てず、システムや製品の性質、利用者の必要などに応じて決めるとしています。同規格は改訂予定で後継規格が開発中です。この記事では、同規格が尺度ごとの合否範囲を一律に割り当てていないという範囲だけを参照します。

確認方法はテストだけではありません。NASAの製品検証ガイドは、テスト、分析、検査、実演を検証方法として挙げています。小規模なサービスでは、要件の性質と影響に合わせて必要な方法を選びます。どの方法でも、実施条件、期待する結果、結果を保存する場所、合否を判断する人が必要です。

単一の数値で決められない品質を扱う

すべての品質を、一つの数値へ置き換える必要はありません。セキュリティやアクセシビリティでは、対象範囲、適用する基準、確認項目、証拠を組み合わせて判断します。

セキュリティは目的・証拠・責任者を決める

セキュリティは、検出件数や一つの点数だけでは合格を判断できません。守る情報と機能、想定する危険、確認する対策、測定または確認方法、合格条件、証拠、責任者を対応づけます。

NISTの情報セキュリティ測定ガイドは、情報セキュリティの尺度を目的や重大なリスクへ結び付けるよう説明しています。記録するのは、範囲と算出方法、目標と証拠、測定時点とデータ元、責任者などです。一つの尺度だけでは判断に足りず、追加の分析が必要になる場合も示しています。これは米国NISTの任意ガイドであり、日本の法令や個別システムの安全性を保証するものではありません。

個人情報、決済、組織全体の権限、高い影響を持つ処理が関わる場合は、記事やAIだけで合否を決めません。組織のセキュリティ責任者、法務、プライバシー担当など、対象に応じた判断者へ確認します。

アクセシビリティは基準と対象範囲を決める

Webのアクセシビリティは、「誰でも使える」という言葉や自動検査の点数だけでは範囲と合否が決まりません。適用する基準、その版と適合水準、対象ページ、一連の操作、確認方法を記録します。

W3CのWebアクセシビリティ基準（WCAG 2.2）は、検証可能な達成基準と適合水準を示し、ページ全体と、開始から完了までの一連の操作を適合範囲に含めています。WCAGへの適合は、すべての利用者の必要を満たす保証ではありません。適用される法令や契約上の水準も、対象地域と組織に応じて別に確認します。

必要に応じて分析・検査・実演を使う

自動テストで判定しにくい条件は、未確認のまま合格にせず、分析、検査、実演を組み合わせます。検査は文書や成果物を確認する方法、実演は実際の操作で要求どおりに振る舞うことを示す方法です。分析は測定結果やモデルなどから条件を満たすか判断します。

使った方法の名前より、対象、条件、期待する結果、証拠、判断者が対応していることが重要です。専門的な評価が必要なら、必要な担当者と確認範囲を先に決めます。

非機能要件票にまとめる

非機能要件は、選んだ品質ごとに一件ずつ記録します。複数の品質を一行へ詰め込むと、測定方法や判断者が曖昧になるためです。

品質ごとに一件ずつ記録する

次の書式は、この記事で一次資料を整理して作った空欄票です。ISO、NASA、NISTなどが定める公式書式ではありません。

最初の一件は、次の順で埋めます。

  1. 対象と、対応する機能要件を決める
  2. 品質を一つ選び、必要な理由と満たせない場合の影響を書く
  3. 結果が変わる利用条件を決める
  4. 測る量または判定規則、合格基準、確認方法を対応させる
  5. 内容を判断する人を決める

この五つのうち、結果に影響する項目が未決なら、未決事項へ移し、推測で先へ進みません。測定の詳細、設計上の制約、引き渡し先は、五つがそろってから補います。

# 非機能要件票

## 1. 対象

- サービス・機能・利用経路:
- 対応する機能要件・受入条件:
- 対象に含むもの:
- 対象に含まないもの:

## 2. 必要な品質

- 品質の名称:
- 必要な理由:
- 満たせない場合の影響:
- ほかの品質と費用への影響:

## 3. 利用条件

- 利用者の範囲:
- 端末・接続・実行環境:
- 同時利用・処理量:
- データの量と状態:
- 対象時間・測定期間:
- 外部サービス等の前提:

## 4. 測定と集計

- 測る量または判定規則:
- 単位・算出方法（どう計算するか）:
- 測る位置:
- 元にする記録:
- 集計期間:
- 集計方法:

## 5. 合格と確認

- 合格基準・許容範囲:
- 基準を決めた根拠:
- 確認方法: [テスト / 分析 / 検査 / 実演]
- 保存する証拠:
- 未達時の扱い:

## 6. 設計上の制約

- 固定または禁止する技術・環境:
- 制約が必要な理由:
- 解除または見直す条件:

## 7. 未決事項

- 未決の内容:
- 未決の理由:
- 解決するための行動:
- 判断する人:
- 期限または実装を止める条件:

## 8. 承認と引き渡し

- 状態: [決定済み / 未決 / 対象外]
- 確認責任者:
- 判断日:
- 対策後にも残る影響の可能性（残るリスク）:
- 見直す条件と担当者:
- 技術選定へ渡す記録:
- テストへ渡す記録:
- 公開・運用へ渡す記録:

「決定済み」は、対象、条件、合格基準、確認方法、責任者がそろい、必要な判断者が内容を確認した状態です。「対象外」には、適用しない理由と見直す条件を残します。結果を変える項目が未確認なら「決定済み」にはしません。

設計上の制約は理由と見直し条件を残す

品質に関する要件と設計上の制約は、票の中でも欄を分けます。制約には、採用または禁止する技術・環境、その理由、解除または見直す条件を記録します。

特定の技術を選ぶ判断は、この票の次の工程です。候補技術を先に固定してから品質条件を合わせると、比較対象と合格基準が狭まります。法令、契約、既存環境、組織の運用条件などで固定が必要な場合だけ、根拠を参照できる形で残します。

決められない値は未決事項にする

値や条件を決める根拠が足りない場合は、空欄をAIや実装者の推測で埋めません。未決の理由、解決する行動、判断する人、期限または実装を止める条件を記録します。

NASAの要件記述ガイドも、未決事項へ理由、解決方法、責任者、期限を付け、仮定を明示して確認するよう示しています。未決の内容が技術選定や合否を変えるなら、決まるまで次の工程を止めます。影響しない範囲だけ進める場合は、その範囲を明記します。

AIで下書きし、人が承認する

AIは、資料から品質候補と不足項目を整理する補助に使えます。ただし、事業上の許容値、契約上の条件、対策後にも残る影響の可能性（残るリスク）をAIだけで決めた状態は、承認済みの非機能要件にはなりません。

AIへ任せるのは候補と根拠の整理

AIへは、機能要件と受入条件を渡します。利用者・利用環境、既存の設計・運用記録、適用する規格・契約も、入力してよい範囲で参照させます。秘密情報、個人情報、顧客情報は、そのAIへ入力してよいと確認できるまで渡しません。

依頼する作業は、品質候補の抽出、記入済み項目と不足項目の区別、根拠の参照先の整理までです。資料から確認できない値は「未決」とし、推測値を完成欄へ入れないよう指定します。

根拠のない値は採用しない

AIが数値を提示した場合は、どの資料、業務上の許容範囲、契約、実測に基づくかを確認します。根拠が確認できなければ、値を削除して未決事項へ戻します。

GitHubのAI生成コードのレビュー指針も、AIの生成物について、動作確認だけでなく、要求、意図、既存の設計に合っているかを人が確認するよう示しています。この資料は非機能要件の目標値を決める手順ではないため、AIの出力を人が文脈と意図に照らす必要性だけを参照します。

品質目標と残るリスクは人が承認する

人が決めるのは、必要な品質、合格基準、設計上の制約、未達時の扱い、残るリスクです。判断者は、技術担当だけとは限りません。業務への影響、費用、契約、セキュリティ、アクセシビリティを判断できる担当者を、品質ごとに記録します。

AIの提案を採用したかではなく、誰が、どの根拠を確認し、どの条件を受け入れたかを残します。判断者が決まらない場合も未決事項です。

次へ進むか判断する

非機能要件票ができたら、技術選定、テスト、公開前確認、運用へ必要な情報を分けて渡します。同じ表をそのまま使うのではなく、各工程が判断する項目を参照できる状態にします。

技術選定へ渡す

技術選定では、候補となる技術や構成が、決めた品質条件と設計上の制約を満たせるかを比較します。比較では、製品名だけを見ません。根拠資料、確認済みと未確認の条件、費用と運用負担、見直す条件をそろえます。

非機能要件票に未決の重要項目があれば、候補を一つに決める前に解決します。技術選定の詳しい方法は、技術選定の進め方で扱います。設計判断の記録は、後続の記事で扱います。

テスト・公開・運用へ渡す

テストへは、対象、利用条件、合格基準、確認方法、保存する証拠を渡します。テストの対象範囲と方法を選ぶときは、テストの種類と選び方へ進みます。

公開前には、同じ公開候補について証拠がそろっているかをサービス公開前の確認で照合します。公開後に継続して測る品質は、測る場所、正常範囲、通知先、見直し担当をWebサービスの最低限の運用設計へ渡します。本記事では、公開判定や監視の設定自体は扱いません。

完了を確認する

次の項目を説明できれば、非機能要件を次の工程へ渡せる状態です。

  • 対象にするサービス、機能、利用経路と、対応する機能要件が分かる
  • 必要な品質と、対象外にした品質の理由が分かる
  • 利用条件、測る量、測る位置、期間、集計方法が決まっている
  • 合格基準、確認方法、保存する証拠が対応している
  • 品質に関する要件と設計上の制約を分けている
  • 未決事項に理由、解決する行動、判断者、期限または停止条件がある
  • 品質目標、制約、残るリスクを確認する人が決まっている
  • 技術選定、テスト、公開前確認、運用へ渡す記録の場所が分かる

どれかが未確認でも、すべての作業を止めるとは限りません。ただし、その項目が技術選定や合否を変えるなら、決定済みとして先へ渡しません。非機能要件票は、形容詞を数値へ置き換える書類ではなく、品質について誰が何を根拠に判断するかをそろえる記録です。

初回表示、更新頻度、利用者別データの条件が決まったら、SSR・CSR・SSG・ISRの選び方で、画面や機能ごとの実行場所とキャッシュ境界を決めます。

出典