発注したシステムが「動くけれど使い物にならない」状態になるとき、原因のほとんどは機能ではなく非機能要件にある。画面も帳票も仕様どおりなのに、月末に処理が終わらない。障害から復旧するのに丸一日かかる。5年後に誰も触れなくなる。これらは要件定義書の機能一覧を何度読み返しても出てこない。
この記事は、システムを発注する側が非機能要件をどこまで決めるべきかを整理したものである。受託開発会社として要件定義から入る立場で、「発注側が決めておいてくれると見積が固くなる項目」と「決めなくていい項目」を分けて書く。用語の解説ではなく、判断の道具として使えるようにした。
この記事でわかること
Photo by Compagnons on Unsplash
- 非機能要件と機能要件の違いと、6つの分類で何を決めるのか
- 非機能要件が見積金額のどこに効くか（工数の増え方の構造）
- 発注側が決めるべき項目と、開発会社に決めさせてよい項目の切り分け
- IPA「非機能要求グレード」を実務で使うときの間引き方
- 決めないまま発注したときに何が起きるか（受託側から見た典型パターン）
結論：発注側が最初に決めるのは6項目のうち3つでいい
Photo by Luke Chesser on Unsplash
非機能要件は項目数が多く、全部を発注側が決めようとすると要件定義が止まる。実務上、発注側が最初に決めるべきなのは3つである。
| 決める順 | 項目 | 発注側にしか決められない理由 |
|---|---|---|
| 1 | 止まってよい時間（可用性） | 業務が何時間止まると誰が困るかは、発注側の業務知識でしか決まらない |
| 2 | 同時に使う人数とデータ量の5年後（性能・拡張性） | 事業計画の話であり、開発会社は推測しかできない |
| 3 | 誰が何を見てよいか（セキュリティ） | 組織の権限設計そのもの。社内規程・監査要件と紐づく |
残りの3つ（運用・保守性、移行性、システム環境）は、開発会社に選択肢と費用差を出させて選ぶのが正しい。発注側が先に細かく決めると、その前提が技術的に不合理でも押し通されて、かえって高くつく。
非機能要件とは何か（機能要件との違い）
Photo by Amsterdam City Archives on Unsplash
機能要件は「システムが何をするか」、非機能要件は「それをどういう品質で満たすか」を決めるものである。
| 機能要件 | 非機能要件 | |
|---|---|---|
| 問い | 何ができるか | どのくらいの品質でできるか |
| 例 | 受注データを登録できる | 1,000件を3秒以内に一覧表示できる |
| 例 | 月次で請求書を出力できる | 月末の同時アクセス50人でも処理が完了する |
| 検収時 | 動くかどうかで判定できる | 基準値を決めていないと判定できない |
| 見落とし | 気づきやすい（画面が無い） | 気づきにくい（動いてはいる） |
決定的な違いは最後の2行にある。機能要件は抜けていれば検収時に気づく。非機能要件は基準値を決めていなければ、遅くても壊れやすくても「仕様どおり」になる。揉めるのは常にこちらである。
要件定義の全体像は要件定義の進め方｜工程・成果物・完了ゲートの実務手順にまとめている。この記事はその中の非機能要件だけを深掘りしたものと考えてほしい。
非機能要件の6分類（IPA 非機能要求グレード）
日本で最も使われている分類は、IPA（情報処理推進機構）の「非機能要求グレード」による6大項目である。
| 分類 | 決めること | 発注側が決める? |
|---|---|---|
| 可用性 | 稼働時間帯、止まってよい時間、障害からの復旧目標、バックアップ世代 | 決める |
| 性能・拡張性 | 同時利用者数、データ量、応答時間、将来の増加見込み | 決める |
| セキュリティ | 権限区分、認証方式、ログの保存期間、外部公開範囲 | 決める |
| 運用・保守性 | 監視方法、障害連絡経路、定期メンテ枠、保守体制 | 選択肢を出させる |
| 移行性 | 既存データの移行範囲、並行稼働の有無、切替方式 | 選択肢を出させる |
| システム環境・エコロジー | 設置環境、クラウド/オンプレ、法令・規格対応 | 選択肢を出させる |
出典: IPA「システム構築の上流工程強化（非機能要求グレード）」
非機能要求グレードは項目数が非常に多く、全項目を埋めることを目的にすると発注側が消耗する。実務では後述の間引き方を使う。
非機能要件が見積のどこに効くか
これが上位の解説記事にほとんど書かれていない部分である。非機能要件は「品質の話」として説明されるが、発注側にとっては金額の話である。どの項目がどう工数に変換されるかを構造で示す。
| 決める内容 | 何の工数が増えるか | 増え方の性質 |
|---|---|---|
| 止まってよい時間を短くする | 冗長構成の設計・構築、切替手順の作成と訓練、監視の作り込み | 段階的。単純な冗長化と自動切替では作業量が大きく変わる |
| 復旧目標時間を短くする | バックアップ方式の高度化、復旧手順の文書化とリハーサル | 段階的 |
| 同時利用者数・データ量を上げる | 性能設計、負荷試験の設計と実施、インフラ費用 | 試験の工数が跳ねる。基準値がないと試験自体を設計できない |
| 権限区分を細かくする | 権限モデルの設計、画面ごとの制御実装、権限別のテスト | 掛け算で増える。区分数×画面数でテストケースが膨らむ |
| ログの保存期間を長くする | 保管設計、ストレージ費用 | 主に運用費用（初期費用より継続費用） |
| 既存データの移行範囲を広げる | 移行ツール作成、データクレンジング、並行稼働の運用 | 読めない。元データの状態次第で工数が大きくぶれる |
| 対応ブラウザ・端末を増やす | 実装の分岐、動作確認の組み合わせ | 掛け算で増える |
この表の使い方は、見積が高いと感じたときにどの非機能要件を緩めれば下がるかを逆引きすることである。機能を削るより、非機能要件のグレードを下げるほうが業務影響が小さい場合は多い。特に「権限区分」と「対応端末」は掛け算で効くため、削ったときの下げ幅が大きい。
見積そのものの読み方はシステム開発の見積もりガイド、単価の妥当性はシステム開発の人月単価 相場早見表で扱っている。
発注側が決めるべき3項目：どう決めるか
1. 止まってよい時間（可用性）
「24時間365日止まらないでほしい」と書かないこと。これは要望であって要件ではない。決めるのは次の3つである。
- 業務時間帯：システムが使われている時間。夜間バッチがあるならその時間も含める
- 業務時間内に止まった場合、何分で困るか：15分なのか、4時間なのか、翌営業日でよいのか
- データが失われてよい時間：直近何分ぶんの入力をやり直せるか
3つ目が抜けやすい。「止まらないでほしい」と「データを失いたくない」は別の要件で、対策も費用も別である。
決め方の実務手順は、業務ごとに聞くことである。全社で一律に決めると最も厳しい業務に引きずられて全体が高くなる。受注入力は4時間止まると困るが、月次レポートは翌日でよい、という差が出せれば、その差がそのまま費用差になる。
2. 同時利用者数とデータ量の5年後（性能・拡張性）
現在値だけでなく、5年後の想定を出す。開発会社が推測すると安全側に倒すため、過剰な設計になりやすい。
決めるのは4つ。
- 同時に使う人数（ピーク時。全社員数ではない）
- 1日あたりの登録件数（ピーク日。平均ではない）
- 蓄積されるデータの総量と、何年ぶん保持するか
- 上記が5年後にどうなるか（事業計画から引く）
「応答時間3秒以内」のような数値は、どの画面のどの操作かを特定しないと意味がない。全画面3秒以内は過剰要求になる。一覧表示・検索・帳票出力など、遅いと業務が止まる操作を3つ程度に絞って基準を決めるのが実務的である。
3. 誰が何を見てよいか（セキュリティ）
権限は掛け算で工数が増えるため、最初に整理する価値が最も高い項目である。決めるのは次の順番。
- 権限の区分数（部長・担当・パート・外部委託先、など）
- 区分ごとに見せてはいけないデータ（他部署の原価、個人情報、取引先の単価）
- 操作の制限（閲覧のみ／登録可／削除可／承認可）
- ログに残す操作と保存期間（監査要件があるなら先に確認する）
ここで「とりあえず細かく分けておく」をやると、テストケースが区分数×画面数で膨らむ。実際に運用で使い分ける区分だけに絞るほうが、費用も運用負荷も下がる。
IPA 非機能要求グレードの間引き方
非機能要求グレードは網羅性が高い反面、発注側が全項目を埋めるのは現実的ではない。実務では次の順で間引く。
- まず「社会的影響がほとんど無いシステム」のモデルシステムを基準にする。非機能要求グレードはモデルシステム別に推奨値を持っている。自社が該当するモデルの推奨値を出発点にすれば、ゼロから考えなくてよい
- 推奨値から変えたい項目だけを議論する。「なぜこの業務は推奨値では足りないのか」を説明できる項目だけが、本当に決めるべき項目である
- 重要項目（グレード表で重要度が高いとされる項目）だけ発注側で確定し、残りは開発会社の提案値を確認する形にする
- 埋まらない項目は空欄のままにせず、「開発会社の提案に従う」と明記する。空欄は「決め忘れ」と「任せる」の区別がつかず、後で揉める原因になる
4番目が実務上いちばん効く。RFPや要件定義書に「この項目は提案に従う」と書いてあれば、提案書の比較時にそこが差分として見える。RFPの書き方はRFPとは｜書き方と提案が集まる項目設計にまとめている。
決めないまま発注するとどうなるか
受託側から見た典型的な帰結を挙げる。いずれも「開発会社が悪い」とも「発注側が悪い」とも言い切れない、基準値が無いために起きる問題である。
| 決めなかった項目 | 起きること | 発覚する時期 |
|---|---|---|
| 同時利用者数 | 開発環境では速いが、本番の全社利用で遅い。改修は設計まで戻る | 受入テスト〜稼働直後 |
| データ量の5年後 | 3年目に一覧表示が実用に耐えなくなる。作り直しに近い改修 | 稼働2〜3年後 |
| 復旧目標時間 | 障害時に「どこまで戻せるか」の合意が無く、復旧作業中に揉める | 最初の障害時 |
| 権限区分 | 稼働直前に「この人に見せてはいけない」が判明し、全画面の改修 | 受入テスト |
| 移行範囲 | 移行対象が膨らみ、移行だけで当初見積を超える | 移行設計〜移行リハーサル |
| 保守体制 | 稼働後の問い合わせ先・対応時間が決まっておらず、無償対応の押し付け合いになる | 稼働直後 |
このうち権限区分と移行範囲は、受入テストの段階で発覚すると打ち手がほとんど無い。スケジュールを延ばすか、機能を落とすか、追加費用を払うかの三択になる。要件定義の段階で30分議論しておけば避けられるものが多い。
失敗の全体像と立て直し方はシステム開発の失敗｜乗り換え判断と既存コードの調査・査定で扱っている。
提案を比較するときに非機能要件をどう読むか
複数社から提案を受け取ったとき、金額差の理由が非機能要件にあることは多い。次の3点を見る。
- 前提条件の欄：安い提案ほど「可用性は業務時間内のみ」「移行は直近1年分のみ」といった前提が書かれている。前提が違えば金額は比較できない
- 試験の記載：性能試験・負荷試験が見積に含まれているか。含まれていない提案は、性能が出なかったときの改修が別費用になる
- 保守の範囲：稼働後の監視・障害対応が含まれるか、時間帯はどこまでか
金額だけを並べると、非機能要件を削った提案が最も安く見える。同じ前提に揃えてから比較するのが原則である。開発会社の選び方はシステム開発会社の選び方にスコアシートを載せている。
よくある誤解
「非機能要件は技術の話だから開発会社が決めるもの」 — 半分は正しい。実現方式は開発会社が決めるが、目標値は発注側の業務判断である。何時間止まると誰が困るかを開発会社は知らない。
「非機能要求グレードを全部埋めれば安心」 — 埋めること自体は目的ではない。埋めた結果として過剰な要件になれば、費用だけが増える。推奨値から変える項目に理由があるかどうかが本質である。
「非機能要件は後から足せる」 — 可用性と性能はアーキテクチャに関わるため、後から変えると設計まで戻る。権限とログは比較的後から足しやすいが、テスト工数は同じだけかかる。後から足せるかどうかで優先順位を決めるのは実務的な考え方である。
「要件定義書に書いておけば守られる」 — 数値基準と測定条件がセットで無いと守れない。「3秒以内」は、どのデータ量で・どの回線で・何人が同時に使っているときの3秒なのかまで書いて初めて検収できる。
まとめ
- 非機能要件は品質の話ではなく、発注側にとっては見積金額と検収可否の話である
- 発注側が決めるのは可用性・性能拡張性・セキュリティの3つ。残りは開発会社に選択肢と費用差を出させる
- 目標値は業務ごとに差をつける。全社一律にすると最も厳しい業務に引きずられて高くなる
- 権限区分と対応端末は掛け算で工数が増える。緩めたときの費用の下げ幅が大きい
- 非機能要求グレードは推奨値から変える項目だけ議論する。埋まらない項目は空欄にせず「提案に従う」と明記する
- 提案比較は前提条件を揃えてから。安い提案は非機能要件を削っていることが多い
次に読む
参考文献・出典
- IPA 独立行政法人 情報処理推進機構「システム構築の上流工程強化（非機能要求グレード）紹介ページ」 https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html
