「検索できる」は確認できても、「快適に使える」は、そのままでは判定できません。1人なら速くても、月末に利用が重なると待たされるかもしれません。
この記事では、非機能要件のうち性能と運用条件を、確認できる文章にする方法を扱います。題材は架空の社内資料検索です。数値・結果・担当の案は説明用で、実測値や一般的な推奨値ではありません。権限、アクセシビリティ、データ保護などを含む非機能要件全体の網羅表ではありません。
「速くする」の前に、使う場面を決める
GOV.UKの性能テストのガイドは、通常時の利用量、将来の増加、特定時期の集中を見積もってから、現実的な性能テストを設計するよう説明しています。
この作例では、まず経費申請の担当者に「月末の何時ごろ、どの資料を探しているか」を確認する案を置きます。「社員数が多い」だけでは、一度に何回検索されるかは分かりません。
| 曖昧な希望 | 具体化する項目 | 社内検索での確認例 |
|---|---|---|
| 検索が速い | 操作、開始と終了、待ち時間 | 検索ボタンを押してから、結果を操作できるまで |
| 多人数でも使える | 一定時間内の検索回数、集中の仕方 | 月末の混雑時間帯に何回検索されるか |
| データが増えても使える | 資料数、内容の長さ、更新処理 | 資料を追加している間も同じ条件で確認するか |
| 止まっても困らない | 利用時間、代替手段、連絡担当 | 検索が使えない間、どこで最新の申請手順を案内するか |
同時に開いている画面数と、毎秒届く検索の数は別の条件です。「同時利用100人」と書くなら、各人がどの間隔で何をする想定なのかも残します。
数値と、測り方を一緒に書く
GoogleのSREの解説は、実際に測る指標と目標値を区別しています。また、サーバーの応答だけではブラウザー側の遅さを見落とす場合があり、平均値だけでは一部の長い待ち時間が隠れると説明しています。
この考え方を社内検索に当てはめるなら、「平均2秒」だけではなく、どの検索を数え、どこまで表示できたら成功かを先に決める案があります。
以下は、打ち合わせで確認するための記入例です。数値の妥当性は利用者の待てる時間、想定利用量、実装コストから検討し直してください。
対象：ログイン済み利用者による社内資料検索
環境：専用の検証環境。ブラウザー・端末・回線条件は実行記録に固定する
データ：架空の資料1万件と、権限・検索語別に期待結果を定義したケース集
負荷：毎秒5回の検索操作を20分間、計6,000回開始する
測定範囲：ボタン操作から、正しい結果または正しい0件案内を操作できるまで
期限：各操作を10秒まで観測する。20分終了後も最後の操作の期限まで記録する
目標案：全操作の95%以上が2秒以内に正常表示される
失敗の上限案：通信エラー・誤った結果・10秒以内に完了しない操作の合計が0.5%以下
記録：全操作を分母にする。失敗・遅延・未完了を除外しない
集計：一つの操作に失敗理由が複数あっても、失敗件数は1件と数える
状態：関係者との合意前。負荷と目標値は仮置き
この条件だけでも、ブラウザー・回線・検索語の構成などはまだ具体化が必要です。条件を決めた実行記録やケース集を一緒に保存して、別の人が同じ確認をできる状態にします。
速かった結果だけで合格にしない
上の条件で、次の結果が得られたと仮定します。これは計算を説明するための作例です。
| 結果 | 件数 | 扱い |
|---|---|---|
| 2秒以内に正常表示 | 5,900件 | 速さの目標を満たす操作 |
| 2秒を超え、10秒以内に正常表示 | 80件 | 正常だが、速さの目標を満たさない操作 |
| 通信エラー・誤った結果・期限までに未完了 | 20件 | 失敗した操作 |
2秒以内の正常表示は全6,000件の約98.3%、失敗は約0.33%です。この架空の実行では、上で置いた二つの数値条件を満たします。
ただし、これはその検証条件での判定です。本番での継続的な品質を保証する結果ではありません。遅い操作が特定の権限や検索語に偏っていないか、初回の検索や更新中の検索も含めたかを確認します。速く返っても、権限に合わない資料を表示した検索を成功に数えることはできません。権限違反などの重大な不具合は、失敗率が0.5%以下でも許容する趣旨ではありません。別の品質条件として確認・是正します。
達成できないときの対応も決める
GOV.UKは、性能テストで問題が起きた負荷と壊れ方を記録し、許容できるリスクかをサービスの責任者が判断するよう説明しています。Test your service's performance
社内検索なら、利用時間、通知先、代替の案内方法を担当者と確認するところから始められます。「24時間動く」と「24時間、担当者が対応する」は別の約束です。
たとえば「平日の業務時間に検索できない場合、運用担当が障害案内を更新し、管理部署が確認した代替の手順ページを案内する」という案でも、担当者・判断基準・案内までの時間・業務時間外の扱いは別途合意が必要です。要件書に担当部署を書いただけで、その部署が引き受けたことにはなりません。
目標が厳しすぎる場合も、数字だけ緩める前に、困る利用場面と費用を照らし合わせます。性能の対策を選ぶには、どこで時間がかかるかを調べる必要があり、この記入例だけで構成やサーバー台数は決まりません。
最初のレビューで確認すること
- 数値は、利用者の事情や利用量の見積もりと結び付いているか。
- 成功・失敗・測定の開始と終了を、別の人も同じ意味で読めるか。
- データ、検索の構成、端末、回線、更新処理などの条件を残しているか。
- 未達時の判断者と対応、未合意の項目が見えるか。
まずは「速い」「安定している」と書いた一文を、この観点で書き換えてみてください。機能や範囲の整理が先なら要件定義の始め方、操作ごとの完了条件を詰めるなら受け入れ条件の書き方が続きになります。