非機能要件が見積を分ける正体
「同じ機能一覧を渡したのに、A 社と B 社で見積が倍違う」——このズレの多くは、機能ではなく 非機能要件 (性能・セキュリティ・可用性など) の解釈差から生まれています。機能要件は画面や項目として目に見えるため、発注側と受注側の認識が揃いやすい一方、非機能要件は明示しない限り「どこまでやるか」が会社ごとに大きく振れます。結果として、片方は「小規模 Web + そこそこの品質」で積み、もう片方は「金融並みの信頼性」で積む、というような食い違いが起こります。
この記事では、非機能要件が見積にどう効いてくるかを、IPA (情報処理推進機構) の「非機能要求グレード」に沿った 6 分類で整理します。発注側の担当者が、過剰でも過少でもない現実的な水準を指定できるようになることを目的とした内容です。
1. 非機能要件とは何か (IPA 準拠の 6 分類)
非機能要件とは、「何ができるか (機能)」ではなく「どのように動くか (品質・制約)」を規定する要件です。IPA が公開している「非機能要求グレード」では、次の 6 分類で整理されています。
| 分類 | 主な観点 | 発注側が気にすべきこと |
|---|---|---|
| 可用性 | 稼働率・障害許容時間・復旧目標 | いつまで止まってよいか |
| 性能・拡張性 | 同時利用者数・応答時間・将来増加 | どれくらいの負荷を捌くか |
| 運用・保守性 | 監視・バックアップ・パッチ運用 | 誰がどう運用するか |
| 移行性 | データ移行・並行稼働・切替方式 | 既存資産をどう引き継ぐか |
| セキュリティ | 認証・権限・暗号化・監査ログ | 誰から何を守るか |
| システム環境・エコロジー | 設置場所・法規制・環境配慮 | 業界規制・立地要件 |
これらは、機能一覧のように「作るか / 作らないか」の二択ではなく、「どのグレードで作るか」というスライダーです。同じ会員登録機能でも、可用性 99.0% と 99.99% では設計も冗長化構成も別物になり、その分工数 (= 見積) が伸びます。
2. 6 分類が見積に与える影響レンジ
分類ごとに「基準ケース」と比較して、総額に対しどれくらい上乗せされうるかの目安を挙げます。数字はあくまで一般的な傾向であり、案件規模と組み合わせで変動します。
| 分類 | 影響レンジ | 上振れの代表要因 |
|---|---|---|
| 可用性 | +5〜30% | マルチ AZ / マルチリージョン冗長、24 時間 365 日監視 |
| 性能・拡張性 | +10〜40% | 同時接続数の想定引き上げ、負荷試験、キャッシュ設計 |
| 運用・保守性 | +5〜20% | 監視ダッシュボード、ジョブ管理、運用手順書一式 |
| 移行性 | +5〜25% | 既存データ移行、旧システム並行稼働、切戻し設計 |
| セキュリティ | +10〜50% | 脆弱性診断、監査ログ、暗号化、鍵管理、規格準拠 |
| システム環境 | +0〜15% | オンプレ制約、業界固有の設置要件 |
たとえば、開発費 1,500 万円の中規模 Web システムで、可用性を「99.9% (月 43 分停止許容)」から「99.99% (月 4.3 分)」に引き上げるだけで、200〜400 万円の上振れが発生することは珍しくありません。詳しくは 開発見積が高くなる / 安くなる要因 でも整理しています。
3. 具体シナリオで見る金額インパクト
抽象的な % では実感しづらいので、代表的な 3 シナリオを比較します。ベースは「中規模 Web システム (機能 20〜40 画面、開発費 1,500 万円想定)」です。
シナリオ A: 同時 1,000 ユーザーが常時利用する
- 通常想定 (同時 100 ユーザー) はベース金額でカバー可能
- 同時 1,000 ユーザー保証で +300〜600 万円
- 発生する追加作業は次のとおりです。
- DB 設計 (インデックス・パーティション・読み書き分離)
- キャッシュ層 (Redis 等) の導入と設計
- 負荷試験環境の構築とテスト工数
- オートスケーリング設計
「ピーク時に何人使うか」を 1 桁見誤ると、後からアーキテクチャごと組み直す羽目になります。
シナリオ B: 24 時間 365 日稼働 (止められない)
- 通常想定 (平日日中稼働 / 夜間バッチ停止許容) はベース金額
- 24 時間 365 日稼働 + 障害復旧目標 30 分で +400〜800 万円
- 発生する追加作業は次のとおりです。
- サーバ冗長化 (マルチ AZ / ロードバランサ)
- 無停止デプロイの設計
- 監視・アラート・オンコール体制
- 障害訓練と手順書整備
「止められない」は、開発費だけでなく 開発後の保守・運用費用 にも継続的に効いてきます。
シナリオ C: 金融データ・個人情報を扱う
- 通常想定 (一般的な個人情報保護水準) はベース金額
- 金融相当 (PCI DSS や ISMS 準拠水準) で +500〜1,500 万円
- 発生する追加作業は次のとおりです。
- 通信・保存の全面暗号化と鍵管理
- 認証・権限・監査ログの厳密設計
- 脆弱性診断 (外部ベンダーへの発注費含む)
- セキュリティレビュー工程の追加
セキュリティは「あとから足す」がもっとも高くつく領域です。設計初期に決めておくかどうかで、同じゴールに到達する工数が 2〜3 倍変わります。
FIXITセキュリティを「あとから足す」と 2〜3 倍って、そんなに違うの？
Dodaiそこは事故ります。暗号化やログは全機能に手を入れるので、後付けは工数がふくらみます。
FIXITDodaiそれも過剰投資の元です。事業影響から必要水準を逆算するのが安全です。
FIXITDodaiはい。損失規模・停止許容時間・ピーク利用者数の 3 点を先に決めます。
4. 発注側が指定すべき最低ラインと過剰スペックの見分け方
非機能要件は「盛れば盛るほど安心」ではありません。過剰スペックは、そのまま無駄な費用になります。次の 3 つの問いで、必要水準の当たりをつけられます。
問い 1: 止まったとき、事業にいくら損失が出るか
- 1 時間止まって数千円〜数万円の損失 → 可用性 99.0〜99.5% で十分
- 1 時間で数十万円〜数百万円の損失 → 可用性 99.9% 以上を検討
- 1 時間で数千万円の損失 (決済・基幹) → 99.99% 以上と冗長化
問い 2: ピーク時の同時利用者は本当に何人か
社内システムであれば、社員数がそのまま上限になります。BtoC の Web サービスでも、キャンペーン想定を除けば「登録ユーザーの 5〜10% が同時利用」が現実的な上限です。「念のため 10 倍」で指定すると、そのまま 10 倍の設計になります。
問い 3: 扱うデータの流出時の影響はどこまでか
- 社内向け業務データ → 一般的な暗号化と権限管理
- 顧客の個人情報 → 個人情報保護法対応 + 監査ログ
- 決済・医療・金融 → 業界規格準拠と第三者診断
過剰スペックの典型サインは、「特定の規格に準拠する必要はないけれど、念のため全部やっておいて」という指定です。この「念のため」が、そのまま数百万円の上乗せに直結します。
5. 非機能要件チェックリスト (発注前に埋める)
見積依頼前に、次のシートを埋めて渡すだけで、各社の見積精度が上がり、比較も容易になります。詳しくは 発注前に整理すべきこと でも触れています。
| 項目 | 記入例 |
|---|---|
| 想定同時利用者数 (通常時 / ピーク時) | 通常 50 / ピーク 200 |
| 応答時間の目安 | 一覧表示 3 秒以内、検索 5 秒以内 |
| 稼働時間帯 | 平日 8:00〜22:00、土日は縮退運用可 |
| 許容停止時間 (月あたり) | 60 分以内 |
| バックアップ頻度と保持期間 | 日次 / 30 日 |
| 障害復旧目標時間 (RTO) | 4 時間以内 |
| 障害復旧目標地点 (RPO) | 24 時間以内のデータ喪失は許容 |
| 取り扱うデータの機密度 | 顧客の連絡先 / 決済情報なし |
| 認証方式 | メール + パスワード + 2 要素 (管理者のみ) |
| 監査ログの保存期間 | 1 年 |
| 準拠が必要な規格・法令 | 個人情報保護法 / 特になし |
| 既存システム連携 | 会計 SaaS 1 本 / API 連携あり |
| 運用担当 | 社内情シス 2 名 (平日日中のみ) |
この情報が揃うと、開発会社は「どのグレードで積むか」を根拠を持って決められるようになり、見積書の読み方 の内訳もはっきりします。
6. 非機能要件を後から追加すると起こること
非機能要件は、後から追加すると機能追加よりもコスト影響が大きい領域です。理由は、アーキテクチャの前提そのものが変わるためです。
典型的には、次のような事象が発生します。
- 再見積が発生します。設計中〜開発中に「同時 1,000 ユーザー対応」を追加すると、DB 設計・キャッシュ設計・負荷試験計画をやり直すため、開発費の 20〜50% 相当の再見積が出ることがあります。
- スケジュールが後退します。再設計・再実装・再テストで 1〜3 か月の後退が発生しがちです。
- 既存実装の手戻りが発生します。暗号化やログ要件を後から入れると、ほぼ全機能に手を入れることになります。
- 保守費が恒常的に増えます。24 時間 365 日監視や冗長化は、リリース後もランニングコストとして継続的に効きます。
一方で、要件定義の段階で明示しておけば、多くの場合はアーキテクチャ選定に織り込む形で吸収でき、追加コストは限定的です。安易な「小さく始めて後で拡張」は、機能面では有効でも、非機能面では危険です。目安金額の裏側は システム開発の見積相場、極端に安い見積のリスクは 安すぎる見積が危険な理由 も参考にしてください。
コツ
非機能要件は「盛れば盛るほど安心」ではありません。事業影響 (止まると何が困るか) からの逆算で最低ラインを決め、要件定義の段階で明示的に織り込むのが、金額とリスクの両方を抑える一番実効性のあるレバーです。
まとめ
非機能要件は、機能要件よりも見積に大きく効くケースがある領域です。IPA の 6 分類 (可用性 / 性能・拡張性 / 運用・保守性 / 移行性 / セキュリティ / システム環境) を踏まえて必要水準を言語化し、「同時 1,000 ユーザー」「24 時間 365 日稼働」「金融データ」の 3 シナリオで数百万円〜千万円単位の上振れが起こり得ることを念頭に置くと、複数社の見積の差を建設的に読み解けるようになります。過剰スペックを避けるには、事業影響からの逆算で最低ラインを決め、後から追加せず要件定義の段階で織り込むのが安全です。
AI 駆動開発のクリエイティブスタジオである FIXIT では、発注担当者の業務要件から非機能要件のグレードを一緒に整理し、複数パターンで見積を提示するかたちで相談を受けています。「自社の場合、どこまで盛るべきか判断がつかない」という段階の方は 無料相談 からお気軽にご連絡ください。進め方の全体像は AI 駆動開発サービス もあわせてご覧ください。