システムの速さ・止まったときの対応はどう決める？発注前の非機能要求

非機能要求は、仕事をどんな条件で行えるかを決める

機能要求は「問い合わせを登録する」「担当班が内容を確認する」のように、システムで何を行いたいかを説明するものです。非機能要求は、その仕事をどの速さ、利用状況、使える時間、情報の扱い方などの条件で行いたいかを説明します。「非機能」は、業務に関係がない、重要でないという意味ではありません。

登録ボタンがあっても、混み合うと仕事が進まない、必要な時間に利用できない、見せるべきでない人へ内容が見える、といった状態では目的に届きません。そのため、機能一覧と別の一般論にせず、対象の仕事へ条件を結び付けます。

何ができるか

問い合わせ窓口が内容を登録し、担当班が同じ問い合わせを確認する、という仕事の案です。

どんな条件で行えるか

問い合わせが集中する時間にも必要な操作ができること、止まったときの受付と再開を扱えること、役割に合う閲覧範囲を守ることなどを詰めます。実現済みという意味ではありません。

何で満たしたと判断するか

対象の操作、試す利用状況、測る範囲、期待する結果、確認する役割を組にします。基準を満たせばどこまでの要求を確認したことになるかも決めます。

IPAの「非機能要求グレード」は、発注側と開発側の認識をそろえるため、重要な項目から要求の段階を確認する枠組みです。本稿では、分類をそのまま全欄へ埋めるのではなく、業務の操作と影響から相談を始めます。IPAの紹介ページで、目的と利用手順を読む

同資料は2018年の枠組みを説明するアーカイブで、ページは2023年8月時点の情報とされています。典型モデルの数値を自社の合意値にするものでも、全社に同じ性能や費用を求めるものでもありません。

問い合わせ登録から、どこで仕事が止まるかをたどる

最初に「システム全体が速いこと」ではなく、日々の仕事を一つ選びます。この例では、窓口が問い合わせを登録し、担当班が内容を確認するところです。受付の表示だけで、担当が内容を受け取った、対応を終えたと扱わないよう、終点を分けます。

1. 利用者と操作を決める。問い合わせ窓口が何を登録し、担当班が何を開くかを確かめます。画面名だけでなく、その操作が次の仕事へどうつながるかを聞きます。
2. 普段と集中する場面を分ける。受付が増える時間帯、複数拠点から重なる操作、添付資料の有無など、実際に違いが生じる条件を調べます。同じ利用者数でも、内容を読むだけか一斉に登録するかで条件が違います。
3. 止まったときの影響を追う。窓口で受け付けられないのか、担当班へ渡らないのか、履歴が見られないのかを分けます。待つ人と、その後に遅れる仕事が見えると、優先する条件を決めやすくなります。

会社全体の最低条件と、業務ごとの追加条件も分けます。例えば社内で決めた閲覧の原則があるなら、その原則を参照しつつ、この問い合わせの内容をどの役割が見られるかを具体化します。部署ごとに同じ原則を書き直すより、共通の基準と、この業務で補う点の関係を示します。共通基準が実在するかも確認対象です。

異なる部署から違う希望が出たら、どちらかの欄を黙って上書きしません。適用する操作や利用時間が違うのか、それとも同じ操作について意見が違うのかを確かめます。後者なら、業務への影響と実現条件を並べ、判断する責任者へ選択肢を示します。

やり取り自体がまだ曖昧なら、利用者ヒアリングで具体的な仕事を聞く手順から始めます。日常の操作が分からないまま、技術用語の一覧だけで要求を決めないためです。

「速く登録したい」を、操作・利用状況・測り方へ書き直す

速さを決めるときは、測定の始まりと終わりをそろえます。「登録の処理が終わるまで」と「窓口の画面へ受付結果が表示されるまで」は同じ範囲とは限りません。さらに担当班へ届くまでを問題にするなら、担当側で同じ記録を確認できるところも別に扱います。

この段階でも、測る対象は明確にできます。まだ決めていない秒数を相場や他社の例で補う必要はありません。業務担当へ「どの操作の待ち時間が、次の受付や担当への連絡を妨げるか」を尋ね、IT担当と観測する操作・時間帯を選びます。測った現状と、将来こうしたいという希望を別に残してください。

一度の速い結果や平均だけで判断しない

空いているときに一回動かした結果だけでは、集中時に使えるか分かりません。また平均が短くても、一部の操作が長く待たされることがあります。普段と集中時を分け、遅い操作がどの程度あるか、失敗や途中中断をどう数えるかまで、開発会社と測り方を決めます。

GoogleのSRE資料も、平均だけでは遅い側の操作を見落とし得る点を説明しています。本稿ではこの観点を測定の相談に使い、原典の人数や秒数を推奨値に移していません。平均と遅い操作の違いを、Googleの原典で読む

比較する各社には、同じ端末・接続条件、対象操作、記録や添付の量、同時に行う仕事、測定の始点と終点を伝えます。サーバー内部の処理だけを示す回答と、利用者の画面表示までを示す回答は、そのまま同じ数字として比較できません。どこまで含む結果かを聞き直します。

大量の同時操作を試す負荷試験は、仕事中の本番へ無断で行うものではありません。開発会社と試験用の環境・データ・実行条件を決めます。現状の観測も、許可された記録を必要な範囲で用い、問い合わせ本文や個人情報を測定資料へ不用意に複写しないようにします。

使える時間と、止まっても受付を失わない方法を決める

「いつでも利用できること」とだけ書く前に、窓口が実際に受け付ける時間と、担当班が見る必要のある時間を確かめます。勤務時間外でも受付だけが必要なのか、担当者の対応まで必要なのかでは、求める運用が変わります。

提供側が稼働率を示す場合は、何の操作を利用可能と数え、どの期間・時間帯を対象にし、計画停止をどう扱うかを読みます。サービス全体の稼働率だけで、拠点の通信や社内の認証を含めた問い合わせ登録まで保証されたことにはしません。自社の業務に必要な範囲との違いを確かめます。

解説図を原寸で見る

停止中の受付と、再開後の照合を一緒に考える

この例の別条件は「勤務時間外に受付が止まる」です。許容できる停止時間も、代わりの受付方法もまだ決まっていません。そのため、紙や別の表で必ず受け付けるといった運用を、決定済みとして足しません。

業務責任者と窓口には、止まっている間に問い合わせが来たら何を知らせるか、受付を待てるか、別の経路が必要かを聞きます。別経路を使う案なら、再開後に誰が同じ問い合わせを見分け、未処理を引き継ぎ、重複登録を防ぐかまで詰めます。代わりの入口を用意するだけでは、仕事へ戻す手順が残るためです。

例えば「勤務時間外は受付だけ残し、担当確認は次の勤務へ引き継ぐ」という案が業務上可能なら、受付と担当確認を分けた条件を提供側へ相談できます。反対に、その時間にも担当へ届かないと困るなら、その理由と対応体制を示して別案を求めます。どちらも、この架空例の採用済み運用ではありません。

止まると困る理由を示すと、すべての機能へ一律に最も厳しい条件を求めずに話せます。ただし、代替手段を考えたことだけで停止を容認したことにはせず、必要な人が実行できるか、情報を保護できるか、再開後の処理まで成立するかを確かめます。

復旧は、再開までの時間と戻せる記録の時点を分ける

復旧を相談するときは、「どれくらいで仕事を再開したいか」と「どの時点までの記録を戻す必要があるか」を別々に考えます。短時間で画面を開けても、直近の問い合わせが抜けていれば担当へ引き継げません。反対に記録が残っていても、必要な人が使えなければ再開できません。

前者はRTO（許容する復旧までの時間）、後者はRPO（失ってよいデータの時間幅）の目標として表すことがあります。AWSの信頼性の指針も、業務への影響を踏まえて二つを定める考え方を示しています。これはAWSの災害復旧に関する資料であり、本稿が特定の構成や共通の目標値を推奨する根拠にはしていません。復旧までの時間とデータ損失の目標の違いを原典で読む

問い合わせ受付なら、最後に戻せる記録より後の問い合わせが何を手掛かりに照合できるか、添付資料や閲覧権限も戻せるか、窓口と担当班がどこまで確認すれば再開と判断できるかを聞きます。バックアップファイルの作成完了と、仕事の復旧確認を同じ結果にしません。

この架空例の復旧時間や復旧済みという値は未確認です。要望を決めた後には、提供側へ実現条件と試験方法を示してもらいます。実際の復元の計画と確認を詳しく行う段階では、バックアップから仕事を戻せるか確かめる手順へ進みます。別記事の注文数や目標時間を、この問い合わせ受付へ写すものではありません。

閲覧範囲は「安全に」ではなく、役割と操作で表す

閲覧の要求では、問い合わせ窓口、担当班、管理する人が、どの情報を見て何を行う必要があるかを分けます。問い合わせの本文、添付、履歴、管理設定など、対象を一つの「アクセス権限」という言葉にまとめると、相手が別の範囲を想像するおそれがあります。

問いへの回答から、見る・登録する・変更する・取り出すといった操作を役割ごとに具体化します。本稿の原例では実際の役割設定が決まっていないため、「担当班ならすべて見てよい」とはしません。権限の必要性は業務担当へ、情報の扱いと認証などの社内基準はIT・情報管理担当へ確かめます。

画面のボタンが隠れているだけでは、その役割から情報や操作を制限できているか判断できません。提供側が用意する許可された試験利用者で、必要な人が対象を扱えることと、権限のない役割から扱えないことを、合意した範囲で確かめます。添付の別保存先へ直接移動した場合なども、必要な対象なら確認に含めます。

製品に「権限機能あり」と書かれていても、自社で必要な役割や範囲を設定できるとは限りません。設定で対応できるのか、追加対応が必要か、運用で補う案なのかを回答してもらいます。情報管理上の必須条件は、便利さや速さとの点数の平均で埋め合わせないよう、判断する条件を分けてください。

この架空例では、何を調べてから条件を決める？

設備保守会社の問い合わせ窓口を例に、普段の受付と、勤務時間外に止まる場合を考えます。どちらも検討用の架空例です。停止が起きた記録や、改善前後の結果ではありません。

まだ測っていない値を「ゼロ」や「問題なし」で埋めないでください。測った現状と、今後必要な条件も別です。回答を得たら、値と一緒に対象の操作・利用状況・判断した人・観測や試験の範囲を残します。

「止まったら困る仕事」から、開発会社へ聞く順番を決める

業務責任者と窓口担当が、受付が止まった間も仕事を続けられるかを先に話します。その答えによって、開発会社へ求める説明が変わります。優先して話す項目を決めても、ほかの条件を不要にするわけではありません。

1. 代わりの方法では受け付けられない

   「勤務時間外も受付が必要で、別の窓口では引き受けられない」など、必要な操作・時間帯・理由を具体的に伝えます。開発会社には、実現方法、費用、運用担当の仕事、試験方法を答えてもらいます。

   回答後：実現できない場合は、業務責任者と受付範囲やシステムの方式を見直します。「運用で何とかする」として残さず、何ができないのかを明らかにします。

2. 別の窓口なら受け付けられそう

   代替受付で何を記録し、誰が保管し、再開後に誰が元のシステムへ引き継ぐかを決めます。実際に重複や漏れを防げる方法か、運用担当と開発会社に確かめます。

   回答後：引継ぎまで成立する見込みを確認してから、許容する停止時間や対応時間を相談します。代替案の名前があるだけでは、条件を満たしたとは判断できません。

3. どこまで待てるか、まだ分からない

   窓口とIT担当で、待ち時間が次の受付を妨げる操作と時間帯を絞り、現状を観測します。開発会社には「未確定の条件」と「何を調べてから決めるか」を伝えます。

   回答後：前提付きの提案は、その前提と一緒に比較します。仮の数値を、確定した性能の約束として扱いません。

厳しい条件ほど、構成や運用の手間が増えることがあります。緩めれば、受付の遅れなどの影響が残ります。開発会社へ同じ前提で案・制約・費用を示してもらい、業務責任者が残る影響を理解して選びます。情報を見せる範囲の制約も、速さや停止時間とは別に確認してください。

開発会社の回答を比べ、登録・引継ぎ・再開の操作で確かめる

各社へ渡す説明には、対象の仕事、使う状況、求める状態、確かめ方、まだ決めていないことをそろえます。同じ要求を複数の資料に書く場合は、採用する版も示します。製品全体の条件と個別の受付業務の条件が違う場合は、どちらを適用するかを確認します。

「対応できます」の一言で比べず、前提を聞き直す

回答は、標準でできること、追加対応が必要なこと、条件付きでできること、未対応、未確認に分けます。例えば待ち時間の回答なら、同時に使う人数、問い合わせや添付の量、通信条件、どこからどこまで測った結果かを聞きます。サーバー内の処理時間と、窓口の画面へ結果が出る時間を、そのまま同じ数字として比べないでください。

サービス水準の合意をSLAと呼ぶことがあります。製品のSLAを読むときも、数える対象・期間、対象外となる条件、定められた対応を確かめます。製品の値だけで、自社の全操作や業務の復旧まで保証されたとは判断できません。個別の契約条件は、対象の契約で確認します。

合意後は、次の順番で確かめる

1. IT担当と開発会社が、試す条件をそろえる。対象の版、許可された試験環境、試験用の問い合わせ、窓口・担当班の役割、普段と集中時の利用状況を決めます。測定の始点・終点と結果の残し方も合意します。
2. 窓口の登録と、担当班の確認を分けて試す。窓口は登録を実行し、受付結果が出るまでを合意した方法で測ります。担当班は同じ問い合わせを開き、必要な内容が見えるかを確認します。閲覧範囲は役割別に試し、見せない情報が見えていないかも確かめます。
3. 停止と再開は、受付記録が渡るところまで試す。合意した試験方法で、停止中の代替受付、記録の保管、再開後の登録と照合を確認します。復旧に必要な記録と、未処理の問い合わせが残らず引き継げたかを確かめます。性能・閲覧・復旧を、一回の画面表示だけで合格にはしません。

受入操作の組立ては、通常・入力違い・やり直しから受入テストを決める方法で詳しく説明しています。依頼全体をまとめるときは、RFPで目的・範囲・回答条件をそろえる方法へ進めます。

運用、利用人数、扱う情報が変わったら、影響を受ける条件を見直します。以前の試験結果は、そのときの版と条件に対する結果として残してください。

まとめ：一つの業務操作から、使える条件と確かめ方を決める

非機能要求は、機能の名前に「高速・安定・安全」を添えるだけでは具体化できません。問い合わせを登録し担当が確認する一件に、普段・集中時・停止時の条件を重ね、操作の終点、仕事への影響、再開する条件、情報を扱う役割を説明します。

業務担当は困る場面と必要な状態を示し、IT担当は現状の観測と社内基準を確かめ、提供側は実現方法・制約・試験方法を回答します。未観測や未決定は残したまま、回答に応じて人の仕事とシステムへ求める範囲を更新します。書いたことだけで実装や合格、契約の成立にはしません。