要件定義の打ち合わせで「非機能要件はどうしますか」と聞かれて、何を答えればいいのか分からないまま「お任せします」と返した。そんな経験のある方に向けた記事です。
非機能要件は技術の話に見えます。ですが、実際に決められるのは発注側だけです。同時に何人が使うのか、止まったら何時間で業務が困るのか、データを何年分残すのか。これらは業務をやっている人しか知りません。この記事では、非機能要件が何を決めるものかを整理したうえで、発注側が業務の言葉で答えていく手順を説明します。
この記事のポイント
- 機能要件が「何ができるか」、非機能要件は「どのくらいで動くか」
- 項目は6つに整理されていて、全部を同時に決める必要はない
- 答えられるのは発注側だけ。技術用語ではなく業務の言葉で伝える
- 決めずに進むと、あとから性能や停止時間で必ず揉める
目次
非機能要件とは何を決める要件か
まず、機能要件との違いから整理します。ここが曖昧なままだと、何を答えればいいのかが最後まで分かりません。
機能要件との違いは「何を」と「どのくらい」
機能要件は「何ができるか」です。受注を登録できる、在庫を検索できる、承認できる。画面や帳票として目に見えるものが中心になります。
一方の非機能要件は「どのくらいで動くか」です。検索結果が何秒で返るか、何人が同時に使えるか、月に何時間まで止まってよいか、データを何年残すか。目には見えませんが、使い勝手と費用の両方を大きく左右します。
分かりやすいのは、同じ機能でも条件次第で金額が何倍にもなる点です。「受注を検索できる」だけなら安く作れますが、「100人が同時に使っても3秒以内に返る」となると、構成そのものが変わります。機能の数だけを見て見積もりを比べても意味がないのは、この差が金額に乗っているからです。
もうひとつ知っておきたいのが、非機能要件は使い始めてから不満として出てくるという性質です。機能の抜けは検収の場で「この画面がない」と気づけますが、遅さや止まりやすさは、実際の業務量で数か月使ってみるまで表に出ません。気づいたときには稼働しているので、直すのに一番お金がかかる状態になっています。
非機能要件は6つの項目に整理されている
何をどこまで決めればいいのかは、すでに整理されたものがあります。IPA（情報処理推進機構）が公開している非機能要求グレードで、非機能要求の項目を網羅的にリストアップし、6つの大項目に分類したうえで、要求レベルを段階的に示したものです。ユーザーと開発者のあいだで認識の行き違いが起きるのを防ぐことを目的に作られており、2009年から2018年度まで実施された事業の成果物です。事業自体は終了していますが、項目の整理として今も使えます。
| 項目 | 決めること | 発注側が答える形 |
|---|---|---|
| 可用性 | どれくらい止まらずに動くか | 止まって困る時間帯と、許せる停止時間 |
| 性能・拡張性 | 速さと、増えたときの余裕 | 同時に使う人数と、3年後の想定件数 |
| 運用・保守性 | 稼働後の面倒の見方 | 誰が運用するか、問い合わせ窓口の時間帯 |
| 移行性 | 旧システムからの移し方 | 移す範囲と、切り替えに使える日数 |
| セキュリティ | 守り方と権限の分け方 | 扱う情報の種類と、社外から使うかどうか |
| システム環境 | 置き場所と前提条件 | クラウドか自社か、使う端末とブラウザ |
右の列を見ていただくと分かるとおり、答えるのに技術の知識は要りません。業務の実態を知っているかどうかだけです。
発注側が決めないと開発会社が決める
ここが実務で最も問題になる点です。非機能要件は、発注側が何も言わなくても勝手には消えません。開発会社が自分たちの標準で仮置きして作り進めます。
そして開発会社の標準は、多くの場合「その金額で作れる範囲」で置かれます。安く見積もるほど、性能も可用性も控えめな前提になります。ここを確認しないまま契約すると、稼働してから「月末に画面が固まる」「夜間バッチが朝までに終わらない」といった形で表に出てきます。
そのときに「そんなに遅いとは聞いていない」と言っても、要件定義書に何も書かれていなければ、開発会社の落ち度とは言えません。仕様どおりに作られているからです。追加費用を払って作り直すことになります。
逆の失敗もあります。不安だからと高い水準を丸ごと求めてしまい、必要のない構成で見積もりが膨らむケースです。使うのが社内の10人だけなのに、大規模サービス並みの可用性を求めれば、当然その分の金額が乗ります。決めないのも危険ですが、根拠なく高く求めるのも同じくらい損をします。
大事なのは、項目ごとに「自社の業務ではどの程度必要か」を言えるようにしておくことです。全項目で最高水準を求める必要はありませんし、逆に全項目を空欄で出す必要もありません。
抜けやすいのは移行性とセキュリティ
6項目のうち、発注側が特に抜かしやすいのは移行性とセキュリティです。どちらも「作る」という意識から外れやすいためです。
移行性は、旧システムのデータをどこまで移すかという話で、見積もりに含まれていないことがよくあります。範囲を決めるのは発注側の仕事で、ここが決まらないと金額も出ません。
セキュリティは、扱う情報の種類で必要な水準が変わります。社内だけで使うのか、取引先が外から使うのか、個人情報を持つのか。この3点だけでも先に伝えておくと、提案の前提が揃います。
抜けているかどうかを自分で点検したい場合は、要件定義書レビューシートに非機能要件やデータ移行など見落としやすい論点が項目として並んでいます。レビューの進め方そのものは要件定義書レビューのチェックリストの記事で扱っています。
非機能要件を発注側が決めるための進め方
ここからは、実際にどう進めるかです。全部を一度に決めようとすると必ず止まります。
重要な項目から段階的に決める
IPAの非機能要求グレードでも、全項目を一度に均一に確認するのは現実的ではないとして、重要な項目から段階的に要求レベルを確認する手順を示しています。手順は3段階で、自社に近いモデルシステムを選び、重要項目のレベルを決め、そのあとで残りの項目を決める、という流れです。
実務では、まず可用性と性能の2つだけ決めてしまうのが早いです。この2つは費用への影響が大きく、後から変えると構成のやり直しになります。逆にシステム環境のような項目は、あとから調整しても傷が浅く済みます。
順番をつけるときの目安は、あとから変えるといくらかかるかです。サーバーの構成や方式に関わるものは先に、運用のルールで吸収できるものは後に回します。決める順番を間違えなければ、途中で仕様が固まっていなくてもプロジェクトは進みます。
「全部埋めてから相談する」と考えると、いつまでも打ち合わせが始まりません。2項目だけ決めて持っていくほうが、話が前に進みます。
技術用語ではなく業務の言葉で答える
非機能要件で発注側が固まってしまう最大の原因は、技術の言葉で答えようとすることです。「稼働率99.9%」と言われても、それが自社にとって適切かどうかは判断できません。
答え方を変えてください。数値ではなく、業務の事実を伝えます。
- この業務が止まると、何時間目から誰が困るか
- いちばん混むのはいつで、そのとき何人が同時に使うか
- 1日あたり何件の伝票が流れるか。3年後はどれくらいになりそうか
- 過去のデータは何年分見られる必要があるか。税務や監査で求められる期間はあるか
- 社外から使う人はいるか。いるなら誰が、どの端末で使うか
この5つに答えられれば、技術的な水準は開発会社が翻訳できます。むしろ、発注側が慣れない数値を先に指定してしまうほうが危険です。根拠のない「99.99%」が独り歩きして、不要に高い構成の見積もりが返ってくることがあります。
答えるときは、幅を持たせて構いません。「同時に30人前後、月末だけ50人くらい」で十分です。正確な数字が出せないからと黙ってしまうより、おおよその実態を伝えるほうが役に立ちます。分からない項目は「分からない」と伝えたうえで、どう調べれば分かるかを開発会社と決めてください。
社内で聞く相手も決めておきます。同時利用者数は現場の管理者、データの保持年数は経理か法務、社外からの利用は情報システムの担当。この3方向に確認すれば、たいていの項目は埋まります。
止まったときの損失を先に出しておく
可用性をどこまで求めるかは、止まったときにいくら損をするかで決まります。ここを出しておくと、開発会社との会話が一気に具体的になります。
難しい計算は要りません。1日あたりの受注金額を営業時間で割って、1時間止まったときの機会損失をざっくり出す。それに加えて、手作業で回すなら何人が何時間かかるかを足す。この程度で十分です。
私の感覚では、この数字を出した時点で「そこまでの可用性は要らない」と気づくケースが半分くらいあります。止まっても半日は紙で回せる業務に、二重化の構成を入れる必要はありません。逆に、1時間止まると出荷が止まるような業務なら、費用をかける根拠が社内でも説明できます。IPAも非機能要求グレードの効果として、発注者側の情報システム費用の説明根拠が明確になる点を挙げています。
見積もりに入っているかを確かめる
決めた非機能要件が、実際に見積もりへ反映されているかは別の話です。要件定義書に書いてあっても、金額に入っていないことがあります。
提案を受け取ったら、次の3点を確認してください。性能テストを実施するのかどうか、実施するならどの条件で行うのか、セキュリティ診断は含まれているのか。どれも「やります」とは書かれていても、費目として金額が積まれていない場合があります。どの段階で何を確かめるのかはシステム開発テストの種類の記事で整理しています。
もし含まれていないなら、その場で追加するかどうかを判断してください。あとから足すこともできますが、テスト工程に入ってから性能テストを追加すると、日程を組み直すことになります。実施しないと決めるのも選択肢です。大事なのは、実施しない前提で契約したと双方が分かっている状態にしておくことです。
非機能要件を含めた要件定義書全体の書き方は要件定義書のサンプルと作り方の記事にまとめています。書式から入りたい場合はそちらを先に見てください。
非機能要件についてよくある質問
- Q. 非機能要件は誰が書くのですか。
- 要件定義書としてまとめるのは開発会社であることが多いですが、内容を決めるのは発注側です。業務が止まって困る時間や利用人数は、社外の人には分かりません。書く作業と決める作業は別だと考えてください。
- Q. 小規模なシステムでも決める必要がありますか。
- 規模が小さいほど、決める項目は絞って構いません。ただし可用性と性能の2つは、社内で数人が使うだけのシステムでも確認しておくほうが安全です。データの保持年数も、あとから増やせないことがあるので先に決めておいてください。
- Q. 稼働率はどれくらいを指定すればいいですか。
- 先に数値を指定しないでください。止まったときに何時間で誰が困るかを伝えて、それに見合う水準を開発会社に提案してもらうほうが結果的に安く済みます。数値だけが独り歩きすると、必要のない構成になりがちです。
- Q. あとから変更できますか。
- 項目によります。運用時間や監視の範囲は比較的変えやすい一方、性能と可用性は構成そのものに関わるため、稼働後の変更は大きな費用になります。この2つを先に決める理由もそこにあります。
