「二秒以内」を、合意できる要件にする

架空事例：青葉機材の非機能要件を検討する。二秒、負荷量、復旧時間などは説明用の仮定であり、SA試験や実システムに一律に適用する推奨値ではない。

達成した二秒と、待たされた五秒

開発者は、在庫照会APIの応答時間を計測した。平均は一・二秒。要望にあった「二秒以内」を満たしているように見える。営業担当者にも使ってもらうと、「まだ遅い」と言われた。

営業が測っていたのは、照会ボタンを押してから、予約してよいか判断できる情報が揃うまでの時間だった。画面は最初に機種一覧を取り、次に在庫を取り、さらに点検状態を取っていた。APIの一呼出しは速くなっても、画面上では五秒待つ。

どちらかが時計を読み間違えたわけではない。測定対象が違っていた。

非機能要件を数値化するとき、最初に必要なのは数値ではなく、どこからどこまでを評価するかの定義である。シラバス5-5は、品質だけでなく、実現方法や開発上の制約、運用・操作、移行などを非機能要件の例として含めている。1 「画面以外の話を後で決める」という意味ではない。機能を業務に使える条件を決める仕事である。

「速い」は、一つの統計量ではない

説明のため、一万回の照会を考える。九千五百回は〇・八秒で返り、残り五百回は二十秒かかったとする。平均は (9500×0.8＋500×20)÷10000＝1.76秒 になる。平均二秒以内は達成している。それでも二十回に一回は、営業が顧客を二十秒待たせる。

平均値が誤りなのではない。平均値だけでは分布が見えないのである。

中央値は典型的な応答を捉える助けになるが、この例では遅い側の五百回が目立たない。高いパーセンタイルや、所定時間内に完了した割合を見ると、平均では隠れる遅延を別の角度から評価できる。GoogleのSRE書籍も、平均だけでなく分布や測定位置を意識したサービス指標を説明している。2

ただし、「95パーセンタイルが二秒」と書いても、残りの応答が何秒かは制約しない。高位パーセンタイルは最大値そのものでもない。標本から分位点を求める方法には違いがあるため、受入れの判定に使うなら集計方法も揃える必要がある。本事例では、説明を明瞭にするため「対象照会のうち、二秒以内に所定の結果を表示できた割合」を直接数える方式を候補にする。

ここで、二秒以内に「システムエラー」を返せば達成としてよいだろうか。業務に必要な可否判断ができていない以上、本事例では達成に数えない。一方、正しく貸出し不可と判定して理由を表示する応答は、業務上は正常な結果である。HTTPのステータスだけで、利用者にとっての成功を決めない。

分母と負荷条件を書いて初めて、同じ試験になる

「二秒以内の照会が95%以上」という目標候補を置いた。分母には何を数えるか。入力が未完了の操作を含めるのか、取り消した操作を含めるのか、通信断で計測できなかった操作はどうするか。これを事後に選び直すと、遅い処理や失敗した処理を除外して、見かけ上の成績を良くできてしまう。

負荷も必要である。営業全体で毎秒三十件の照会が来る場合と、一人が十秒おきに操作する場合では、同じ応答時間の試験にならない。登録済みの予約が千件か百万件かによっても、条件は変わり得る。

青葉機材では、まず次の項目を合意する。これは要件を具体化するための例であり、この表だけで完全な性能試験計画になるわけではない。

観点	本事例で明確にする内容
対象操作	標準機材について、機種・数量・期間を指定した照会
測定の開始と終了	利用者の照会操作から、判断に必要な結果の表示完了まで
判定対象	正常な可否回答。不正入力、通信断、中断の分類規則も事前に定める
負荷	照会の到着頻度、予約確定との混在比、短時間の集中の仕方
データ	機種数、個体数、予約件数、期間や倉庫への偏り
実行環境	端末・ブラウザ、回線条件、サーバ構成、外部連携条件
集計	測定期間、開始直後の扱い、時間内完了率、失敗率の定義

同時利用者数と毎秒の要求数も区別する。百人がログインしていても、全員が一秒おきに要求する場合と、ほとんど操作しない場合では負荷が違う。人数だけを並べても、必要な処理能力は定まらない。

また、試験のたびに条件を広げていては合格できない。初めに採用する条件を合意し、変更が必要なら理由と影響を評価する。測定可能性とは、後から都合よく測る自由ではなく、同じ前提なら同じ合否を判断できる状態である。

部品の目標を足しても、全体の目標にならない

画面処理の一部は外部の契約管理サービスに依存している。自社のAPIだけを二秒以内にしても、外部応答を直列に待つなら、利用者が待つ時間にはその分が加わる。全体目標から各処理に時間の予算を割り当てる必要がある。

しかし、各処理の95パーセンタイルを足せば、全体の95パーセンタイルになるわけではない。どの要求で各処理が遅くなるか、その相関や実行順序が関係するからである。全体の分布は、全体として測るか、採用した確率モデルの前提を明示して評価する。

並列に問い合わせれば、待ち時間を短くできることもある。ただし、後の処理が前の結果に依存するなら、単純には並列化できない。依存のない処理も、共通DBや同じ回線を使うなら競合が増える可能性がある。ここで必要なのは、特定の技術を「高速化の正解」と決めることではなく、機能間の依存と資源の制約を調べることである。

外部情報をキャッシュする案にも同じことが起きる。速く表示できても、古い点検状態を使って機材を貸し出してしまえば、業務の約束を損なう。本事例では、照会時の参考表示と、予約確定時に必要な確認を分ける案を検討する。どの情報の古さを、どの判断で許すかを決めなければ、性能と正確性の折合いは付かない。

稼働率の数字には、業務の時間割が隠れている

予約受付は毎日行うが、倉庫の出庫準備は特定の時間帯に集中する。深夜に十分停止できる業務と、深夜にも貸出しを確定しなければならない業務では、必要な可用性が違う。

仮に一か月の評価対象時間を一万分と定め、利用不能時間を十分以内にするなら、時間に基づく可用性は99.9%以上となる。ただし、この割合だけでは、十分の停止が一度起きるのか、一分の停止が十回起きるのかは区別できない。出庫直前に十分止まる影響と、夜間に止まる影響も異なる。

したがって、サービス提供時間、計画停止の扱い、部分的な機能停止をどう数えるかを定義する。本事例なら、照会は可能だが予約確定ができない状態を、予約業務にとって利用可能とみなすかを決める必要がある。単にサーバが起動している時間を数えても、営業が仕事をできる時間にはならない。

稼働率と、要求の成功割合も同じ指標ではない。短時間の停止が大量の要求に重なれば、時間ベースでは小さくても、失敗した要求の割合は大きくなることがある。定義を確認せず、異なる種類の百分率を比較しない。2

復旧時間と、取り戻せるデータの時点

障害から一時間以内にサービスを再開するという要求と、直前十五分を超える確定データの損失を許さないという要求を置く。前者はRTO、後者はRPOに関わる目標の例になる。RTOは復旧までの時間、RPOはどの時点までのデータを回復対象とするかに着目する。両者の違いは、コンプリートテキスト第13章の基礎に対応する。1

十五分おきのバックアップを設定すれば、RPO十五分が保証されるだろうか。バックアップが失敗した場合、壊れたデータを保存した場合、復元に必要なログがない場合には成立しない。設定した間隔と、実際に回復できる時点は別である。

同様に、一時間以内にサーバを起動できても、予約記録の整合を確認し、外部との重複処理を調べ、営業が使える状態へ戻すまで一時間を超えれば、定義した復旧目標を満たさない可能性がある。復旧の開始点と終了点も、対象業務に合わせて定義する。

失ってよいデータが十五分分とされても、その十五分に顧客へ確約した予約が含まれるなら、業務上の対応が必要になる。紙の受付記録を使って再入力するのか、外部の確定記録と照合するのか、受付を止めるのか。バックアップの方式だけでなく、障害中と復旧後の仕事まで設計する。

非機能要件は、設定項目をすべて最大にすることではない

無停止、即時応答、データ損失なし、最小費用、最小運用要員。この希望をそのまま並べても、実現可能な計画にはならない。高い目標を選べば必ず良いのではなく、事業上の必要性と実現する費用、時間、運用負担を比較する必要がある。

IPAの非機能要求グレードは、要求項目と段階的なレベルを使って、利用者と開発者の認識を合わせる道具として説明されている。重要な項目から確認していくものであり、すべてを最高レベルへ揃えることを目的としていない。3

青葉機材では、予約確定の誤りを防ぐ条件は維持しながら、外部情報が得られない場合の照会は「確認中」として受け付ける案を比較する。これなら営業が依頼を失わずに済む反面、確約までの時間と担当者の作業が増える。受付継続と即時確約を同じサービスと考えず、それぞれの目標を説明する。

SREの用語で整理するなら、SLIは観測する指標、SLOは目標、SLAはサービスについての合意であり、同書では目標未達時の帰結を含む契約として区別される。2 目標を示しただけで、すべての契約条件や責任分担まで合意できたことにはならない。

最後に、分類表の版にも注意する。提供されたSAシラバスVer.5.2の5-5には、品質要件の例として機能性、信頼性、使用性、効率性、保守性、移植性が記載されている。コンプリートテキストでは、JIS X 25010:2013の製品品質モデルなど、別の規格・版も扱っている。数や名称が違うからと無理に一つへ置き換えず、参照している資料、版、分類対象を確かめる。1

二秒という数字は、最初と同じである。しかし、その対象、分母、負荷、失敗の扱い、実現に払う代償が見えてきた。ここまで定めて初めて、開発者と利用者は、同じ二秒について話している。

知識を答案へ戻す

午前Ⅱの判別軸。 応答時間、スループット、稼働率、RTO、RPOは、いずれもシステムの良さを表すように見えるが、測定対象が違う。性能効率性と利用者の業務効率も同義ではない。規格の品質特性を問う設問では、指定された版とモデルを優先する。

午後Ⅰへの接続。 数値のある一文を、条件ごと読む。「営業時間中」「ピーク時」「確定済み」「外部サービスを含む」といった限定は、方式を選ぶ根拠になる。問題文にない負荷や可用性を勝手に上乗せせず、その業務に必要な品質を説明する。

午後Ⅱへの接続。 「高性能なサーバを採用した」で終えず、どの業務上の待ちを、どの測定条件で評価し、何とのトレードオフで方式を選んだかを書く。本事例なら、外部照会の遅延を切り離す一方、古い情報で確約しないよう確定時の確認を維持した、という判断を説明できる。これは本書の作例である。

立ち止まって考える：平均1.76秒なら、「利用者を二秒以上待たせない」を満たすか

満たすとはいえない。本章の例では五百回の照会が二十秒かかっている。平均値の上限と、個々の操作の最大待ち時間の上限は異なる。何を要求しているかを確かめ、時間内完了率、失敗率、必要なら最大時間など、目的に対応した基準を定める。

出典と照合範囲

[1] IPA「SAシラバス Ver.5.2」4-14、4-15、5-5、7-2、およびコンプリートテキスト第3・10・13・14・16章：非機能要件、品質の分類、信頼性・性能・復旧の基礎を照合した。計測例の数値と要件表は、本書が置いた仮定に基づく。公式シラバス

[2] Google, Site Reliability Engineering, Chapter 4: Service Level Objectives：SLI・SLO・SLAの区別、利用者側の測定、分布を考慮した指標という観点を参照した。本章の待ち時間の分布、時間内完了率、可用性の数値例は独自に作成・計算したもの。著者公開本文

[3] IPA「システム構築の上流工程強化（非機能要求グレード）紹介ページ」：要求レベルを段階的に示し、重要項目から受発注者間の認識を合わせるという利用目的を参照した。グレード表の全項目やレベル値は転載していない。IPA公開ページ