非機能要件とは？機能以外に決めておきたいこと
数人での確認では問題なかった受注システムが、営業担当者が一斉に使い始めると遅くなることがあります。反応がないため再送し、どの注文が登録されたかを調べ直す。画面はそろっていても、想定どおりに仕事が進まない状態です。
この架空の例から分かるのは、機能一覧だけでは実務で使えるかを判断できないということです。利用量、必要な稼働時間、データの整合性、障害時の継続方法も決める必要があります。こうした条件は、非機能要件を検討する際の重要な観点になります。
1. 非機能要件とは？
機能要件は、注文登録、在庫確保、帳票出力など、システムが行う処理を定めます。非機能要件は、それらを実行するときの品質、稼働条件、制約を定めます。「注文を検索できること」と「多数の人が使っても、業務に必要な速さで検索できること」は、分けて確認する必要があります。
両者の境界は必ずしも明確ではありません。セキュリティ要件から権限管理機能が必要になったり、追跡可能性のために変更履歴画面が必要になったりします。分類の議論で止めるより、設計と確認につながる内容にし、責任を明らかにすることが大切です。
対象範囲を決める段階から扱う理由もここにあります。受入直前に、多拠点での同時利用や受注時間中の無停止が必要だと分かると、データ構造や配置方法まで変わる場合があります。業務側には単純に見える条件でも、実現方法に大きく影響することがあります。
2. 企業が明確にしておきたい要件
技術用語の一覧を埋める前に、実務担当者と一つの仕事を最初から最後まで確認します。受注の例なら、顧客検索、在庫確認、送信、受付確認、倉庫への引渡しです。各段階で、遅延、誤り、処理不能が誰に影響し、その場合にどう仕事を続けるかを考えます。
次の表は考え方の例であり、すべてのシステムに必須の仕様ではありません。回答から性能、復旧、セキュリティ、運用の条件が見えてきます。機能上のルールとして明記する必要がある内容も含まれます。
| 場面 | 確認すること | 未確認だと起こり得ること |
|---|---|---|
| 始業時に検索が集中 | 重要な操作、同時利用数、データ量、許容する応答時間 | 少人数では動いても、実利用では遅くなる |
| 受付確認前に再送 | 受付済みかの確認方法と重複処理の防止 | 同じ依頼を複数回処理する |
| 連携先が停止 | 保持する状態、再処理の範囲、通知先 | 待つべきか再送すべきか分からない |
| 誤更新やシステム停止 | 復旧対象、許容する中断、再利用の確認者 | コピーはあっても受注を再開できない |
| 一覧出力や担当変更 | 閲覧・出力・編集できる人と記録する操作 | 対象外への情報流出や変更者の不明確化 |
使いやすさと運用性も、仕事の流れから考えます。「失敗しました」だけでは、注文が登録されたか分からないかもしれません。受け取る人のいない技術的な警告も、停止の解決につながりません。利用者が理解すべき内容と、運用担当が対応に必要とする情報を具体化します。
稼働し続けることと、問題発生後に復旧できることも別です。停止が少なくても、誤更新への対処が用意されていない場合があります。一方、バックアップがあっても直ちに再開できるとは限りません。それぞれに合った確認方法が必要です。
3. テストで確認できる要件の書き方
利用場面、測定条件、目標、確認方法、確認者を一組にすると整理しやすくなります。「速い」だけでは対象の操作が分からず、「多数が使える」だけでは、閲覧なのか取引の登録なのか分かりません。何を評価するかをそろえるための構成です。
次の数値は記載方法を説明するための仮定であり、業界基準やFenixの保証ではありません。「合意した検証環境で、20万件の注文データと同時利用者50人のシナリオを用い、成功した検索の95%以上で、2秒以内に結果を表示する」といった書き方です。
実際に使うには、検索条件、測定の開始・終了、端末や通信環境、負荷のかけ方も決めます。失敗やタイムアウトは別に記録し、許容条件を設けます。成功した検索の速度だけを報告して、失敗を見えなくしないことが大切です。
「95%」は平均値とは異なります。平均が短くても、一部の利用者が長く待つことはあります。残る検索が重要業務へ影響するなら、その扱いと限界も定めます。見栄えのために指標を増やすのではなく、確認したいリスクに結び付けましょう。
根拠がなければ、数値を適当に埋めないようにします。既存の稼働情報、繁忙時の観察、試行から検討し、仮定と判断時期を残します。業務側が許容する影響を説明し、技術側が実現性と費用を評価して、必要な水準を合意します。
4. 業務の必要性と費用に合った水準の決め方
高い目標には別の構成や費用が必要になることがあります。翌営業日までに必要な社内帳票なら、常時即時出力にしても効果が見合わないかもしれません。一方、顧客や出荷を待たせる受注確認は優先度が高くなり得ます。全体一律ではなく、業務の流れごとに判断します。
選択肢と影響も話し合います。事前案内した時間帯の保守停止は許容できるか。大きな帳票は裏側で処理し、完成時に通知してよいか。こうした方法で必要な成果を適切な投資で実現できる場合がありますが、関係する利用者の合意と範囲への明記が必要です。
業務の目的と技術的な手段も区別します。「一部が故障しても注文を失わない」は具体化すべき必要性ですが、特定の構成を指定するのは手段の選択です。確認済みの制約がなければ、先に技術を固定せず、開発側が案と根拠を示せるようにします。
5. 受入テストと運用で要件を確認する
合意した要件は設計とテストへ反映します。業務側が場面と影響を確認し、技術側が測定と結果を用意し、権限のある人が差異の許容可否を判断します。初期資料に一行あるだけで確認計画がなければ、双方の期待を守る根拠にはなりにくいものです。
結果には試験条件も残します。データが少ない、想定する稼働環境と大きく違う場合は、単に「合格」とせず限界を明示します。停止を想定する確認では、サーバーが起動するだけでなく、取引の状態、復旧、業務再開までを確かめます。
利用者、拠点、連携先が増えたら、初期の前提を見直します。目標を満たさなくなった際には、規模の変化なのか、当初の合意に未達なのかを分けて考えます。要件と確認結果の履歴があれば、「急に遅くなった」という印象だけでなく、事実に基づいて相談できます。
打合せには、止められない仕事、利用が集中する時間や規模、対応に手間がかかった過去の問題を整理すると役立ちます。Fenixと、必要な条件、追加調査、確認方法を具体化できます。品質への期待を、業務側と技術側の双方が実行できる判断に変えることが、非機能要件を定める価値です。
