非機能要件はどこまで決めればいいのか｜中小企業のシステム導入で外せない6つの項目
システムを入れるとき、「この画面でこの入力ができる」という機能の話は、発注側もベンダーも盛り上がります。ところが、「止まったらどうするか」「同時に何人が使うか」は、後回しになりがちです。後回しにしたまま進むと、稼働直前に性能や権限の追加見積が出て、慌てることになりかねません。
非機能要件は、IPA（情報処理推進機構）の「非機能要求グレード」にある可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6項目を、発注側が数字で一言ずつ答えられる状態にすれば足ります。すべてを細かく詰める必要はなく、止まってよい時間、同時に使う人数、移行するデータの量、権限の分け方の4点は、発注前に数字にしておきたい項目です。
非機能要件とは：まず1分だけ
非機能要件は、システムが「何ができるか」ではなく、「どんな品質で動くか」に関する要件です。IPAは、非機能要求を6つの大項目に分類し、さらに中項目、小項目、指標（メトリクス）へと細かく体系化しています。2018年に改訂版が公開されています。
この体系は、約240の指標を持つ大きなものです。中小企業が全部を埋める必要はありません。大項目ごとに、自社の業務で何を決めておくべきかを押さえるのが現実的です。機能要件との違い、業務要件との関係は業務要件・機能要件・非機能要件の違いで扱っているので、ここでは決める中身に絞ります。
6つの項目で、発注側が決めること
項目 | 決めること | 発注側が答える質問 | 書き方の例（架空） |
|---|---|---|---|
可用性 | 使う時間帯と、止まってよい時間 | 何時から何時まで使うか。止まったら何時間まで耐えられるか | 営業日の8時から20時は原則止めない。メンテナンスは夜間で月1回2時間まで |
性能・拡張性 | 処理の量と、今後の増え方 | 同時に何人が使うか。ピークはいつか。3年後にどう増えるか | 同時利用は最大20人。月末の締めに利用が集中する |
運用・保守性 | 監視、バックアップ、問題が起きたときの対応 | 誰が見るか。障害時にどこまで対応してもらうか | バックアップは毎日。障害の連絡は営業日の午前中に受ける |
移行性 | 移行の方法と、移行するデータの量 | どのデータを持ち越すか。何年分か。切り替えで止められる期間は | 過去5年分の取引データを移行。切り替えは週末の2日間 |
セキュリティ | 誰が何を見られるか、不正アクセスへの備え | 職種ごとに見せてよい情報は。外部から使うか | 経理だけが原価を見られる。社外からの利用は認証を必須にする |
システム環境・エコロジー | 設置する環境と、環境への配慮 | どこに置くか。自社の設備を使うか | クラウドの事業者に任せ、自社に設置する機器は持たない |
表の「書き方の例」はすべて架空のもので、自社の数字に置き換えるための見本です。IPAの資料でも、可用性では運用スケジュールや障害時の稼働目標、性能・拡張性では業務量と今後の増加見積りが、要求の例として挙げられています。
項目1：可用性は「止まってよい時間」で決める
可用性は、システムを使いたいときに使えるかどうかです。決めるのは、使う時間帯と、止まったときにどこまで耐えられるかです。耐えられる時間は、止まったときに業務がどう困るかから逆算します。
たとえば、受注の入力が止まると出荷の指示が出せなくなる会社と、半日止まっても紙で回せる会社では、必要な水準が違います。水準を上げるほど、機器を二重にするなどの構成が必要になり、費用が増えます。業務への影響とコストを並べて、水準を選んでください。
項目2：性能・拡張性は「同時の人数とピーク」で決める
性能は、処理の速さと量です。発注側が答えやすいのは、同時に何人が使うか、いつ集中するか、という使い方の話です。月末の締め処理や、朝一番の一斉の入力は、ピークの代表例です。
拡張性は、将来の増え方です。3年後に人数や取引が倍になる見通しがあるなら、いま伝えておかないと、あとで作り直しの見積りになります。逆に、増える見通しがないなら、余裕を持たせすぎないことも、費用を抑える判断です。
項目3：運用・保守性は「誰が見て、誰が直すか」で決める
運用・保守性は、稼働したあとの面倒の見やすさです。バックアップの頻度、監視の仕組み、障害が起きたときの連絡と対応の分担が含まれます。稼働前は見落としやすく、稼働後に最も困る項目です。
決めるのは、障害の連絡を誰が受け、どの時間帯に、どこまで対応してもらうかです。社内に詳しい担当者がいないなら、対応をベンダーに任せる範囲を、契約の段階で書いておきます。
項目4：移行性は「何を、何年分、いつ切り替えるか」で決める
移行性は、古いシステムや表計算ソフトから新しいシステムへの乗り換えのしやすさです。決めるのは、移行するデータの種類と量、切り替えの期間、切り替え中に止められる時間です。
移行するデータの量は、見積りに直結します。過去何年分を持ち越すかで作業量が変わるので、「全部」と言う前に、実際に参照する期間を確かめてください。使わない過去のデータは、移行せず保管するだけでも足りる場合があります。
項目5：セキュリティは「誰が何を見られるか」で決める
セキュリティで発注側が決めるのは、まず権限です。職種や役職ごとに、見られる情報、変えられる情報を分けます。原価や給与のように、見せる相手を絞りたい情報は、先に洗い出しておきます。
権限の分け方は、あとから変えると、画面の作り変えに近い手間がかかることがあります。外部から使うか、使うなら認証をどうするかも、このときに決めます。
項目6：システム環境・エコロジーは「どこに置くか」だけ決める
この項目は、設置場所の温度、騒音、耐震、消費電力など、機器を置く環境に関することです。クラウドを使う場合は、大半を事業者が担うので、発注側が決めることは多くありません。自社に機器を置くのかどうかだけを決めておけば、この項目は足ります。
一段深く：「決めない」と、見積りの中で誰かが決める
非機能要件を決めないまま進めると、決まらなかったのではなく、ベンダー側が何らかの前提を置いて見積りを作っている場合があります。同時利用の人数も、止まってよい時間も、ベンダーの標準的な想定が入っているかもしれません。それが自社の使い方とずれていれば、稼働直前に、追加の作業と追加の見積りとして表に出てきます。
だから、決める水準は、完璧である必要はありません。発注側が数字で答えた内容を、RFP（提案依頼書）に書いて、すべてのベンダーに同じ条件で見積りを出してもらうことが目的です。比べ方はRFP（提案依頼書）の書き方に、見積りの読み方はシステムの見積書はどこを見ればいいのかにあります。追加開発が保守費に変わる点はカスタマイズはどこまで許すべきかが参考になります。
よくある質問
Q. 非機能要件は、どこまで細かく書けばよいですか。
A. 項目ごとに、発注側が数字や段階で答えられる範囲までです。IPAの非機能要求グレードは、項目ごとに段階を選ぶ形で作られています。細かい指標は、ベンダーと相談しながら詰めても構いません。
Q. パッケージやクラウドのサービスでも、非機能要件は必要ですか。
A. 必要です。サービスごとに、稼働時間の保証や、バックアップの範囲、利用人数の上限が違います。自社の使い方がその範囲に収まるかを、契約の前に確かめてください。
Q. 自社に詳しい人がいません。誰に相談すればよいですか。
A. まず、業務で困ることを言葉にして、ベンダーに提示してもらった水準と照らし合わせてください。判断が難しい場合は、第三者の支援を使う方法もあります。
まとめ
非機能要件は、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6項目を、発注側が一言ずつ答えられるようにすれば足ります。止まってよい時間、同時の人数、移行するデータの量、権限の分け方の4点は、最低限、数字にしてから見積りを依頼してください。決めた内容をRFPに書いておけば、追加見積りの驚きは大きく減ります。
非機能要件の水準の決め方や、RFPへの落とし込みを整理したい方は、お問い合わせからお気軽にご相談ください。
あわせて読みたい
この記事を書いた人
小林悠真（こばやし・ゆうま）／LF&L株式会社 代表取締役。九州大学で音響設計・音楽マネジメントを学びデザイン思考を培った後、ヤマトシステム開発・バンテックで物流／生産管理、ラクスル等のITスタートアップで事業開発・SCM構築を経験。製造業・物流業のDXコンサルタントとして、現場の1歩から経営システムまでの全体最適を支援する。テューバ奏者・LFコンサート代表理事も兼務。