非機能要件の決め方｜外注前チェックリスト

非機能要件は、システムの速度・安定性・安全性・運用方法を決める条件です。外注前に「対象業務」「想定利用量」「障害時の影響」「復旧目標」「測定方法」を優先順位付きで整理すると、過剰投資と見積もり漏れを防げます。すべてを最高水準にするのではなく、事業上必要な水準を数値で決めることが重要です。

監修：株式会社GeekBridge 代表取締役 板橋 晟星

• 非機能要件とは？機能要件との違いと主な項目
  • 非機能要件の主な7分類
• 外注前に決めたい非機能要件チェックリスト
  • 可用性と障害復旧
  • 性能と将来の利用量
  • セキュリティと権限管理
  • 運用、監視、バックアップ
  • 優先順位を3段階で付ける
• 非機能要件で変わる費用・期間の目安
  • 費用が増えやすい非機能要件
  • 期間へ与える影響
• 非機能要件を外注する進め方と会社選び
  • ステップ1：停止・遅延・漏えいの影響を整理する
  • ステップ2：現状値と将来予測を集める
  • ステップ3：要件を数値と条件で表す
  • ステップ4：役割分担と成果物を決める
  • ステップ5：RFPと見積条件へ反映する
  • 見積書で確認するポイント
  • 開発会社を見極める質問
  • よくある失敗と回避策
• まとめ
• よくある質問
  • 非機能要件は、どこまで決めてから開発会社へ相談すべきですか？
  • システムの稼働率は何％に設定すべきですか？
  • 非機能要件の整理を外注すると、費用と期間はどのくらいですか？
  • 非機能要件はリリース後に追加できますか？

非機能要件とは？機能要件との違いと主な項目

非機能要件とは、システムが「どのような品質で動くべきか」を定める条件です。画面や機能だけでは判断しにくいものの、リリース後の安定運用や利用者の満足度、障害時の事業損失に大きく関係します。

システム開発の要件は、機能要件と非機能要件に大きく分けられます。

例えば「商品を検索できる」は機能要件です。一方、「利用者が200人同時にアクセスしても、検索結果を原則3秒以内に表示する」は非機能要件です。

発注のご相談を受ける開発会社の立場では、「アクセスが増えても落ちないようにしたい」「セキュリティを万全にしたい」といった抽象的なご要望をよく伺います。しかし、絶対に停止しないシステムや、あらゆる攻撃を完全に防ぐシステムは現実的ではありません。求める水準を上げるほど、開発費だけでなくクラウド利用料、監視費、保守費も増加します。

そのため、非機能要件では「高いほどよい」と考えるのではなく、障害や情報漏えいが起きたときの影響から必要水準を逆算します。

非機能要件の主な7分類

発注者が外注前に確認したい非機能要件は、次の7分類です。

特に見落とされやすいのが、運用・保守と復旧に関する条件です。システムが完成しても、アラートを誰が受け取り、障害発生時に誰が判断し、どの順番で復旧するかが決まっていなければ運用できません。

また、バックアップが存在することと、実際に復元できることは別です。バックアップの取得頻度だけでなく、復元手順と定期的な復元確認まで要件に含めます。

外注前に決めたい非機能要件チェックリスト

非機能要件は、いきなり技術仕様から決める必要はありません。まず発注者が業務上の条件を示し、開発会社に実現方法と費用を提案してもらう進め方が現実的です。

可用性と障害復旧

可用性とは、必要なときにシステムを利用できる度合いです。発注者は、次の項目を確認してください。

• システムを利用する曜日と時間帯
• 計画停止を許容できる時間帯と長さ
• 停止すると影響を受ける利用者、売上、社内業務
• 一部の機能だけを止めて運用できるか
• 障害発生から復旧まで許容できる時間
• 障害時の連絡先と判断責任者
• 休日・夜間対応の必要性
• 外部サービス停止時の代替手段

可用性は「99.9％」のような稼働率で示されることがあります。24時間365日を前提に単純計算すると、稼働率と年間停止時間の関係は次のとおりです。

ただし、計画メンテナンスを停止時間に含めるか、外部サービスの障害をどう扱うかによって計算結果は変わります。数値だけを記載せず、測定期間と除外条件も決めましょう。

障害復旧では、RTOとRPOも重要です。RTOは「障害発生後、何時間以内に復旧するかという目標」、RPOは「何時間前のデータまで戻せればよいかという目標」です。

例えば「RTOは4時間、RPOは1時間」とした場合、障害から4時間以内の復旧を目指し、失われる可能性があるデータを最大1時間分に抑える設計を検討します。数値を短くするほど、冗長化（＝同じ役割の設備を複数用意すること）やバックアップの費用が増える傾向があります。

性能と将来の利用量

性能要件では、「速く動くこと」ではなく、想定する負荷と測定条件を示します。

• 現在の利用者数と3年程度の増加見込み
• 1日当たりの利用件数
• 同時に利用する最大人数
• 月末、キャンペーン、朝会前などの繁忙時間
• 登録するデータ件数とファイル容量
• 画面表示や検索結果の許容時間
• CSV出力や集計処理に許容できる時間
• 外部システムと連携する件数と頻度

悪い指定例は「画面を高速に表示する」です。これでは完成時に合否を判断できません。

良い指定例は「通常時200人が同時利用する条件で、主要5画面の応答時間を原則3秒以内とする」のような表現です。応答時間とは、利用者が操作してから画面や結果が返るまでの時間です。

すべての画面に厳しい基準を設ける必要はありません。ログイン、検索、決済など利用頻度や重要度が高い処理を選び、対象範囲を明確にすると費用対効果を保ちやすくなります。

セキュリティと権限管理

セキュリティ要件は「強固にする」だけでは不十分です。扱う情報と想定リスクを整理します。

• 個人情報、決済情報、営業秘密を扱うか
• 管理者、一般社員、取引先などの利用者区分
• 利用者ごとに閲覧・登録・承認・削除の権限を分けるか
• 多要素認証（＝パスワード以外の確認手段も使う認証）が必要か
• 社外からのアクセスを許可するか
• 操作履歴を何年間保存するか
• 通信中・保存中のデータを暗号化するか
• 退職者や異動者のアカウントを誰が停止するか
• 脆弱性診断（＝攻撃につながる弱点を検査すること）を実施するか
• 情報漏えい時の報告経路をどうするか

社内システムでも、URLを知っている人なら誰でもアクセスできる設計は適切ではありません。一方で、すべての操作に多要素認証を要求すると、現場の負担が大きくなる場合があります。情報の重要度と利用場面に応じて認証方法を分ける考え方が必要です。

運用、監視、バックアップ

リリース後の担当範囲は、開発会社との認識差が生じやすい項目です。次の内容を外注前に整理します。

• システムを監視する時間帯
• 監視する対象と異常の基準
• 異常通知を受け取る担当者
• 一次対応を自社と開発会社のどちらが行うか
• 問い合わせ窓口と受付時間
• 定期メンテナンスの頻度
• OSや利用ソフトウェアの更新担当
• バックアップの頻度、保存先、保管期間
• 復元試験の頻度
• 障害報告書の要否と提出期限

「24時間監視」と「24時間復旧対応」は同じではありません。自動監視が常時動いていても、夜間は担当者への通知だけで、復旧作業は翌営業日となる契約もあります。監視、連絡、調査、復旧のどこまでが含まれるかを分けて確認してください。

優先順位を3段階で付ける

非機能要件には、次のように優先順位を付けます。

• 必須：満たさなければ業務開始や法令順守ができない
• 重要：できる限り実現したいが、費用次第で調整できる
• 将来対応：初回リリース後の利用状況を見て追加する

優先順位がないと、開発会社は安全側に寄せた高い見積もりを出すか、反対に最低限の構成を前提とする可能性があります。同じ依頼内容でも見積金額が大きく異なる原因になるため、初回リリースで必要な範囲を明示しましょう。

非機能要件で変わる費用・期間の目安

非機能要件に必要な費用は、システムの規模だけでなく、求める可用性、扱うデータ、試験方法、運用時間によって変わります。機能数が少ないシステムでも、24時間稼働や厳格な監査が必要なら費用は高くなります。

個別作業を外注する場合の一般的な目安は次のとおりです。税別を想定した概算であり、対象システムの規模や既存環境によっては範囲を大きく超えることがあります。

これらは独立した追加作業とは限らず、通常の開発費に含まれる場合もあります。そのため、表の金額を単純に合算するのではなく、見積書の対象範囲を確認してください。

費用が増えやすい非機能要件

特に費用へ影響しやすいのは、次の条件です。

• 24時間365日の監視と緊急復旧
• 99.99％など高い稼働率
• 大量アクセスに備えた負荷試験
• 複数拠点にまたがる災害対策
• 個人情報や決済情報を扱う厳格なセキュリティ
• 長期間のログ保存と監査対応
• 多数の端末、OS、ブラウザへの対応
• 短いRTO・RPO
• 本番と同等規模の試験環境

高い可用性を求める場合、開発時の構築費だけでなく、サーバーやデータベースを複数用意する月額費用も増えます。見積もりでは「初期費用」と「リリース後の月額費用」を分けて比較しましょう。

期間へ与える影響

非機能要件の整理は、一般的な中小規模の開発で2～8週間程度が一つの目安です。ただし、複数部門との調整、既存システムの調査、監査部門の確認がある場合はさらに必要です。

負荷試験やセキュリティ診断は、開発完了直前に初めて実施すると、問題の修正によってリリースが遅れる可能性があります。要件定義（＝作るものと条件を決める工程）の段階で試験内容を決め、設計中とリリース前に確認する日程を確保してください。

非機能要件を外注する進め方と会社選び

非機能要件は、発注者だけでも開発会社だけでも適切に決めにくい領域です。発注者が事業上の制約と許容範囲を伝え、開発会社が技術的な選択肢、費用、リスクを提示する分担が基本です。

ステップ1：停止・遅延・漏えいの影響を整理する

最初に、システムで問題が発生した場合の影響を書き出します。

• 売上が停止する
• 店舗や工場の業務が止まる
• 顧客への連絡が必要になる
• 個人情報が漏えいする可能性がある
• 手作業で一時的に代替できる
• 翌営業日までに直れば問題が小さい

「何時間止まると重大か」「手作業で何件まで対応できるか」まで整理すると、必要な可用性や復旧時間を決めやすくなります。

ステップ2：現状値と将来予測を集める

既存システムや手作業の記録から、利用者数、処理件数、データ量、繁忙時間を集めます。新規事業で実績がない場合は、標準・繁忙・最大想定の3パターンを置き、仮定であることを明記します。

将来予測を一つの数字に決めきれない場合は、「初年度は200人、3年以内に1,000人を想定」のように段階を示します。初期費用を抑えつつ、拡張可能な設計を相談しやすくなります。

ステップ3：要件を数値と条件で表す

各要件には、対象、目標値、測定条件、優先度を設定します。

測定できない条件は、完成時の受入判定で争点になりやすくなります。受入条件とは、発注者が完成した成果物を検査し、契約どおりか判断する基準です。

ステップ4：役割分担と成果物を決める

外注時は、次の成果物を依頼範囲に含めるか確認してください。

• 非機能要件一覧
• システム構成図
• 性能・負荷試験計画書と結果
• セキュリティ試験結果
• 監視項目と通知先一覧
• バックアップ・復旧手順書
• 障害対応フロー
• アカウント・権限一覧
• リリース後の運用手順書

自社、開発会社、クラウド事業者、外部サービス提供会社の責任範囲も明記します。外部サービスが止まった場合に、誰が問い合わせを行い、利用者へ連絡するかまで決めておくと運用時の混乱を抑えられます。

ステップ5：RFPと見積条件へ反映する

RFP（＝開発会社へ要望と提案条件を伝える文書）には、必須条件だけでなく、現状値、将来予測、優先順位も記載します。詳細は RFPの作り方｜システム開発の依頼準備でも解説しています。

開発会社へは、次の項目を分けた見積もりを依頼すると比較しやすくなります。

• 非機能要件を整理する費用
• 設計・構築費
• 試験環境と試験実施費
• 外部診断費
• クラウドなどの月額利用料
• 監視・障害対応の月額費
• 要件変更時の追加費用

要件を決めながら進める部分が多い場合は、契約形態によって費用や責任範囲が変わります。システム開発契約の選び方｜請負・準委任を比較も併せて確認してください。

見積書で確認するポイント

金額だけでなく、前提条件と対象外の作業を確認します。

• 同時利用者数やデータ量の前提が記載されているか
• 対応する端末・OS・ブラウザが明記されているか
• 負荷試験やセキュリティ試験が含まれるか
• 試験で問題が見つかった場合の修正費を含むか
• クラウドの月額費用が試算されているか
• 夜間・休日の監視と復旧対応を区別しているか
• バックアップの取得だけでなく復元試験を含むか
• 外部サービス障害時の対応範囲が明確か
• 受入条件と検査期間が定義されているか
• リリース後の保証、保守、追加改修の条件があるか

「非機能要件対応一式」とだけ書かれた見積書では、何が含まれるか判断できません。項目ごとの設計内容、試験方法、月額費用を説明してもらいましょう。

開発会社を見極める質問

非機能要件に強い開発会社は、希望をそのまま受け入れるだけでなく、費用とのバランスや代替案を説明します。提案時には次の質問が有効です。

• この性能目標を満たす構成を選んだ理由は何ですか
• 利用者が想定の3倍になった場合、どこを変更しますか
• 障害時に自動で復旧する範囲と、人の作業が必要な範囲はどこですか
• 性能や復旧時間をどのように試験しますか
• 月額費用を抑える代替案はありますか
• セキュリティ診断で問題が見つかった場合、誰が改修しますか
• リリース後の監視と緊急対応は誰が担当しますか
• 将来、他社へ保守を移管できる資料は残りますか

回答では、専門用語の多さよりも、前提、選択肢、費用差、残るリスクを分かりやすく説明できるかを見ます。「絶対に落ちません」「セキュリティは完全です」と断言するのではなく、限界や対象外を説明する会社のほうが現実的です。

よくある失敗と回避策

自社だけでは性能、可用性、セキュリティの水準を判断しにくい場合は、業務影響と予算を共有したうえで複数案を依頼してください。要件整理から相談したい場合は、開発のご相談はこちらからお問い合わせいただけます。

まとめ

• 非機能要件は、速度、安定性、安全性、復旧、運用など「どのような品質で動くか」を決める条件です
• 発注者は技術構成より先に、利用時間、想定利用量、障害時の業務影響、許容停止時間を整理します
• 「高速」「万全」などの抽象表現ではなく、対象、数値、測定条件、例外を記載します
• 可用性を上げ、RTO・RPOを短くするほど、初期費用と月額運用費が増える傾向があります
• すべてを最高水準にせず、「必須・重要・将来対応」の3段階で優先順位を付けます
• 見積もりでは、設計・構築費だけでなく、試験費、クラウド月額費、監視費、障害対応費を確認します
• 開発会社には、選択した構成の理由、代替案、試験方法、責任範囲、残るリスクを説明してもらいましょう

よくある質問

非機能要件は、どこまで決めてから開発会社へ相談すべきですか？

利用時間、想定利用者数、繁忙時の件数、扱う情報、停止時の影響、復旧希望時間まで整理できれば相談可能です。技術構成や細かな数値を自社だけで確定する必要はありません。開発会社に複数案と費用差を提案してもらい、要件定義で確定します。

システムの稼働率は何％に設定すべきですか？

一律の正解はありません。停止による売上・業務・顧客への影響と、代替手段の有無から決めます。稼働率だけでなく、利用時間帯、計画停止を含めるか、障害時の復旧時間、外部サービス停止時の扱いも併せて定義してください。

非機能要件の整理を外注すると、費用と期間はどのくらいですか？

一般的な目安は50万～200万円程度、2～8週間程度です。システム規模、関係部門数、既存環境の調査、セキュリティや監査の水準によって変動します。負荷試験や脆弱性診断、災害対策環境の構築は別費用になる場合があります。

非機能要件はリリース後に追加できますか？

監視項目や一部の運用手順は追加しやすい一方、可用性、データ構造、権限設計、復旧方式などは後から変更すると高額になりやすい項目です。初回リリースに必要な基盤部分を先に決め、利用量に応じて拡張する項目を分けてください。