機能要件と非機能要件の違い｜洗い出し方と具体例
「要件定義で機能の話はしたが、非機能要件と言われてもピンとこない」「稼働してから画面が遅い、障害時に復旧できないといった問題が起きた」。システムの要件は、何ができるかを表す機能要件と、どの程度の品質で動くかを表す非機能要件に分かれます。発注者の関心は機能に集まりがちで、非機能要件は見落とされやすいのが実情です。
この記事では、機能要件と非機能要件の違いを具体例とともに整理し、それぞれの洗い出し方、発注者が確認しておきたい非機能要件のチェック項目、要件定義書への書き方のポイントを解説します。
- 機能要件はシステムが何をするか、非機能要件はどの程度の品質・条件で動くかを定めたものです。
- 機能要件は業務フローから、非機能要件はチェックリストを使って洗い出すのが効率的です。
- 非機能要件は「性能」「可用性」「セキュリティ」「運用・保守」「移行」「利用環境」などに分類できます。
- どちらも数値や具体的な条件で書くことで、見積もりと受入テストの基準になります。
機能要件と非機能要件とは？
機能要件とは、システムが業務を行うために備えるべき機能、つまり「システムで何ができるか」を定めた要件のことです。受注の登録、在庫の引き当て、請求書の発行、データの検索といった、利用者が直接使う機能がこれにあたります。
非機能要件とは、機能以外にシステムに求められる品質や制約、つまり「どのくらいの速さ・安定性・安全性で動くか」を定めた要件のことです。画面の応答時間、稼働時間、障害時の復旧時間、アクセス権限、バックアップの方法などがこれにあたります。
機能要件
- 問い：システムで何ができるか
- 例：受注を登録できる、帳票を出力できる
- 利用者が意識しやすい
- 業務フローから洗い出せる
非機能要件
- 問い：どの程度の品質で動くか
- 例：3秒以内に表示、平日9〜21時は停止しない
- 利用者が意識しにくい
- チェックリストで確認すると漏れにくい
具体例で見る違い
たとえば受注管理システムで考えると、次のように整理できます。
| 区分 | 要件の例 |
|---|---|
| 機能要件 | 得意先コードを入力すると、住所と取引条件が自動表示される |
| 機能要件 | 受注データから出荷指示書と請求書を出力できる |
| 機能要件 | 月末に得意先別の売上を集計できる |
| 非機能要件（性能） | 受注登録画面は通常時3秒以内に表示される |
| 非機能要件（可用性） | 障害発生時は翌営業日までに復旧する |
| 非機能要件（セキュリティ） | 営業担当は自分の担当得意先のデータのみ閲覧できる |
| 非機能要件（運用） | データは毎日自動でバックアップし、7日分保管する |
非機能要件の主な分類
非機能要件の分類として広く参照されているのが、IPA（独立行政法人情報処理推進機構）が公開している「非機能要求グレード」です。ここでは、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つの大項目で非機能要求を整理しています。発注者が確認しやすいように整理すると、次のようになります。
| 分類 | 決めること | 発注者への質問の例 |
|---|---|---|
| 可用性 | 稼働時間、停止許容時間、障害時の復旧 | システムが半日止まったら業務はどうなりますか？ |
| 性能・拡張性 | 応答時間、同時利用者数、データ量の増加 | 同時に何人使いますか？5年後の件数は？ |
| 運用・保守性 | バックアップ、監視、問い合わせ対応 | 障害の連絡は誰が受けますか？ |
| 移行性 | 旧システムからのデータ移行、切り替え方法 | 過去何年分のデータを移しますか？ |
| セキュリティ | 認証、権限、ログ、暗号化 | 誰がどの情報を見られるべきですか？ |
| システム環境 | 利用端末、ブラウザ、設置場所、法令 | スマートフォンやタブレットでも使いますか？ |
機能要件の洗い出し方
- 業務フローを書く対象業務の流れを担当者ごとに書き出し、システムで行う作業に印をつけます。
- 作業ごとに必要な機能を挙げる印をつけた作業について「入力」「確認」「出力」「計算」などの機能を列挙します。
- 画面・帳票・データを整理する機能ごとに必要な画面、帳票、保存すべきデータ項目を一覧にします。
- 例外処理を追加するキャンセル、訂正、締め後の修正など、通常と異なる処理を洗い出します。
- 優先度をつける必須、あると良い、将来対応の3段階で分類し、予算に合わせて範囲を決めます。
非機能要件の洗い出し方と確認チェックリスト
非機能要件は、利用者に「どうしたいですか」と聞いても答えが出にくい要件です。開発会社が提示するチェックリストや質問に沿って、業務への影響から逆算して決めていくのが現実的です。発注者として最低限確認しておきたい項目は次のとおりです。
- 利用時間：システムを使う曜日・時間帯と、夜間や休日の利用有無。
- 停止の影響：止まった場合に業務がどれくらい耐えられるか（数時間か、1日か）。
- 利用者数：登録する利用者数と、同時に使う人数のピーク。
- データ量：現在の件数と、今後5年程度の増加見込み。
- 権限：役職や部署ごとに閲覧・更新できる範囲。
- バックアップ：どの程度前の状態まで戻せればよいか。
- 利用環境：パソコン、スマートフォン、社外からの利用の有無。
- 保守体制：問い合わせ窓口、障害時の連絡手段と対応時間。
要件定義書への書き方のポイント
機能要件も非機能要件も、あいまいな表現を避け、確認できる形で書くことが重要です。書き方の違いで、見積もりの精度と受入テストの判断が変わります。
よい書き方
- 受注登録画面は通常時3秒以内に表示する
- 平日8時〜20時の利用を前提とする
- データは毎日深夜に自動バックアップする
避けたい書き方
- 画面はストレスなく表示される
- 必要なときに使える
- 適宜バックアップを取る
数値で書けない場合でも、「どんな状況で」「何が」「どうなればよいか」を具体的に書くと、発注者と開発会社の認識のずれを防げます。要件定義書全体の構成は、テンプレート記事も参考にしてください。
要件の優先度のつけ方
機能要件も非機能要件も、洗い出すと要望は増え続けます。すべてを実現しようとすると予算と期間が膨らむため、優先度をつけて範囲を決めることが欠かせません。一般的には次の3段階で分類します。
| 優先度 | 判断の基準 | 例 |
|---|---|---|
| 必須 | ないと業務が回らない、法令上必要 | 受注登録、請求書発行、権限管理 |
| あると良い | 効率は上がるが、代替手段がある | ダッシュボード表示、一括取込機能 |
| 将来対応 | 今回の目的に直結しない | スマートフォン専用画面、他システムとの追加連携 |
非機能要件にも優先度の考え方は当てはまります。たとえば「障害時は1時間以内に復旧」は必須でも、「夜間も含めて24時間稼働」は業務上なくてもよい、という判断もあり得ます。優先度の判断基準は、システム化の目的です。目的に照らして、その要件がなければ何が困るのかを一つずつ確認していくと、関係者の合意も得やすくなります。
よくある質問
- 非機能要件は発注者が決めなければいけませんか？
- 最終的に判断するのは発注者ですが、項目の提示や水準の提案は開発会社が行うのが一般的です。発注者は業務への影響を伝え、提案された水準が妥当かを判断します。
- 非機能要件を決めないまま開発するとどうなりますか？
- 開発会社の標準的な想定で作られるため、稼働後に「遅い」「権限が細かく設定できない」「復旧に時間がかかる」といった不満が出やすくなります。後から対応すると追加費用がかかることもあります。
- 機能要件と非機能要件はどちらが重要ですか？
- どちらも欠かせません。機能要件が満たされていても、遅くて使えない、止まると業務が回らないといった状態では実用になりません。両方を合わせて初めて使えるシステムになります。
まとめ
機能要件はシステムが何をするか、非機能要件はどの程度の品質で動くかを定めたものです。機能要件は業務フローから、非機能要件はチェックリストで洗い出し、どちらも数値や具体的な条件で書くことで、見積もりと受入テストの基準にできます。
この記事に関連するサービス
受託システム開発
業務システム・Webシステム・基幹システムを、要件が固まる前のご相談から設計・開発・運用保守まで一貫して開発します。プロトタイプで早い段階から画面を確認でき、開発資産の活用で品質を… サービスの詳細を見る
