要件定義の打ち合わせで、開発会社から「非機能要件はどうしますか？」と聞かれて、言葉に詰まった。そんな経験はないでしょうか。「機能」ではないものを決めると言われても、何をどこまで書けばよいのか見当がつかない、というのは自然な戸惑いです。
「非機能要件と言われても、何をどこまで書けばいいか分からない…」
先に結論をお伝えします。非機能要件は、「止まったら何が困るか」「どのくらいの人が使うか」「何を守りたいか」を、業務の言葉で答えるところから始めれば大丈夫です。数値やサーバーの構成まで発注者が自分で決める必要はありません。決めるのは、業務への影響と優先順位です。
この記事では、非機能要件とは何か、発注者が決めるべき6つの観点、そして打ち合わせでそのまま使える質問例とチェックリストを解説します。
非機能要件とは？「機能」以外の、使い心地と安心感を決めるもの
機能要件は「システムで何ができるか」（例：受注を登録できる、請求書をPDFで出せる）を指します。一方、非機能要件は「それをどんな品質で提供するか」を指します。たとえば次のような違いです。
| 機能要件（何ができるか） | 非機能要件（どんな品質か） |
|---|---|
| 受注を登録できる | 月末の混雑時でも、登録に数秒以内で反応する |
| 請求書をPDFで出せる | 障害が起きても、翌営業日の朝までには使える状態に戻す |
| 社員ごとにログインできる | 不正なログインを検知し、記録を一定期間残す |
どちらも欠けるとシステムは使い物になりませんが、機能は画面や操作として目に見えるのに対し、非機能要件は言われなければ誰も書かないのが厄介な点です。書かれていないものは見積もりにも含まれないため、後から「その対応は別料金です」となりやすい部分でもあります。要件定義のあとに見積もりが上がる理由は、次の記事で解説しています。
なぜ発注者が決める必要があるのか
「技術的なことは開発会社に任せたい」と思われるかもしれません。ただ、非機能要件には技術では決められない判断が多く含まれています。
- 止まった場合に、どのくらいの時間まで業務が耐えられるか
- どこまでの費用をかけて、止まりにくくするか
- 個人情報など、何を最優先で守るか
これらは業務の事情と予算の話であり、現場を知る発注者にしか答えられません。開発会社が勝手に決めると、業務に合わない水準になったり、必要以上に高い水準で見積もったりしがちです。開発会社に悪意があるわけではなく、情報がないために安全側か、あるいは最小限に倒れてしまうのです。
非機能要件の認識のずれを防ぐための公的な道具として、IPA（情報処理推進機構）が「非機能要求グレード」を公開しています。
📰 出典：IPA「システム構築の上流工程強化（非機能要求グレード）」
IPAの説明によると、非機能要求グレードは、ユーザ（発注者）と開発者の間で非機能要求の認識がずれることを防ぐためのツール群です。非機能要求の項目を網羅的に並べ、それぞれの要求レベルを段階で示し、重要な項目から順にレベルを決めながら両者で確認していく使い方が想定されています。なお、このページの情報は2023年8月時点のもので、事業は終了していると記載されています（2026年11月時点で確認）。
発注者が決める6つの観点
非機能要求グレード2018では、非機能要求を6つの大項目に分けています（出典：上記IPAページ、および項目一覧）。ここでは、各項目を発注者の言葉に置き換えて整理します。専門用語は用語のまま書き、括弧で説明を添えます。
1. 可用性（＝止まりにくさ、止まったときの戻りやすさ）
「システムが使えない時間をどこまで許せるか」を決めます。
- 利用してもらう時間帯（平日9時〜18時だけか、24時間365日か）
- 止まった場合に、何時間までなら業務が耐えられるか
- 障害が起きたとき、どの時点のデータまで戻せればよいか（直前まで／前日の夜まで）
止まらない構成にするほど費用は上がります。「24時間止まらない」と一言で言う前に、本当に必要な時間帯と、耐えられる停止時間を業務側で整理しておくことが大切です。
2. 性能・拡張性（＝処理の速さ、利用者やデータが増えたときの余裕）
「何人が、どのくらい同時に使うか」と「今後どれだけ増えるか」を決めます。
- 利用者の人数と、同時に使う人数の最大値（月末や朝礼後など、集中する時間帯）
- 扱うデータの量（1日の登録件数、数年後の累積件数）
- 画面が反応するまでの待ち時間の目安（業務が滞らない範囲）
数字が正確でなくても、「社員30人、月末の午前に集中」のような言い方で十分です。
3. 運用・保守性（＝動かし続けるときの手間と体制）
「作ったあと、誰が何をするか」を決めます。
- 監視（＝システムが正常に動いているかを見張ること）と、障害の連絡方法
- バックアップ（＝データの控え）の取り方と保管期間
- 保守の受付時間と、障害時に誰が何分以内に対応するか
このあたりは保守契約の内容と直結します。契約前に確認しておくと、「それは保守の範囲外です」というすれ違いを減らせます。
4. 移行性（＝今のシステムやデータから乗り換える際の進め方）
「古いシステムやExcelのデータを、どう新しいシステムに移すか」を決めます。
- 移すデータの範囲と量（過去何年分まで必要か）
- 切り替えの際に、業務を止められる時間はどのくらいか
- 移行の作業を誰が担当し、確認は誰が行うか
古い仕様書が残っていない場合は、移行の難しさが上がります。早めに開発会社へ共有しておきましょう。
5. セキュリティ（＝守りたい情報と、守り方の水準）
「何を、誰から、どこまで守るか」を決めます。
- 扱う情報の種類（個人情報、取引先情報、社内の機密など）
- 誰がどの情報を見られるか（権限の分け方）
- ログ（＝誰がいつ何をしたかの記録）を残す期間
- 社外の人が使うかどうか（使う場合は求める水準が上がる）
中小企業向けの考え方として、IPAが「中小企業の情報セキュリティ対策ガイドライン」を公開しています。要件を決めるときの参考になります。
📰 出典：IPA「中小企業の情報セキュリティ対策ガイドライン」
6. システム環境・エコロジー（＝設置場所や機器、消費電力などの条件）
クラウドを使うか自社に設置するか、使う端末は何か、といった前提条件です。クラウド中心のシステムでは、開発会社の提案に任せる割合が大きくなる項目です。ただし、「社内のネットワークからしか使わせたくない」「特定の地域にデータを置きたい」といった社内ルールや取引先の要請がある場合は、必ず最初に伝えてください。
「何をどこまで書くか」の目安
すべてを細かく決める必要はありません。次の順番で進めると、負担を抑えられます。
- 業務への影響が大きい項目を3つ選ぶ。たいていは可用性、セキュリティ、性能のどれかです
- 業務の言葉で書く。「月末の午前、30人が同時に登録しても待たされない」のように、場面で書きます
- 決められない項目は「未定」と書く。空欄のまま進めるより、「未定」と分かる方が見積もりのずれを防げます
- 「必須」と「できれば」に分ける。予算を超えたときの調整の材料になります
- 開発会社の提案する水準を、費用とセットで確認する。水準を上げると何がいくら増えるのかを聞きます
IPAの非機能要求グレードは、システムの典型的な型に近いものを選び、重要な項目から水準を決める使い方が示されています。難しく感じる場合は、開発会社にこの資料を使って整理してほしいと依頼するのも一つの方法です。依頼内容をまとめる書き方は、次の記事で解説しています。
やりがちな失敗
- 「できるだけ速く」「なるべく止まらないように」と書く。基準がないと、完成後に「速い」「止まらない」の認識がずれます
- 最初から最高水準を求める。費用が大きく増えるうえ、実際の業務にはそこまで必要ないことも多くあります
- 開発会社の書いた水準をそのまま承認する。業務との照らし合わせを一度はしましょう
- 運用開始後の体制を決めていない。作ったあとに誰が見張るのかが曖昧だと、障害時に対応が遅れます
発注者がやること チェックリスト
- ☐ システムが止まった場合、業務が耐えられる時間を現場に確認した
- ☐ 利用者の人数と、利用が集中する時間帯を整理した
- ☐ 扱う情報の種類（個人情報の有無など）と、見られる人の範囲を整理した
- ☐ 古いシステムやExcelから移すデータの範囲を決めた
- ☐ 運用開始後の窓口担当者と、障害時の連絡の流れを決めた
- ☐ 社内ルールや取引先の要請で守るべき条件（データの置き場所など）を洗い出した
- ☐ 決められない項目は「未定」と書き、いつまでに決めるかを開発会社と確認した
開発会社への質問例
- 「この規模のシステムで、非機能要件として発注者側が決めておくべき項目を、優先度の高い順に教えていただけますか」
- 「止まっても許される時間を『半日』と『1時間』にした場合、それぞれ構成と費用はどう変わりますか」
- 「性能の目標は、どのような数字を前提に見積もっていますか。利用者が2倍に増えたときは、追加の費用がかかりますか」
- 「今回の見積もりには、監視・バックアップ・障害対応のうち、どこまで含まれていますか」
- 「非機能要件のうち、まだ決まっていない項目は、いつまでに決める必要がありますか。決めないとどの工程に影響しますか」
まとめ
- 非機能要件は「機能」以外の品質のことで、書かれないと見積もりにも入らず、後から追加費用になりやすい
- 決めるのは技術ではなく、業務への影響と優先順位。発注者にしか答えられない部分が多い
- IPAの非機能要求グレードの6つの観点（可用性・性能・拡張性・運用・保守性・移行性・セキュリティ・システム環境・エコロジー）に沿って、重要な3つから、業務の言葉で書き始める
- 決められない項目は「未定」と明記し、水準を上げると費用がどう変わるかを開発会社に確認する
※ 本記事の内容は2026年11月時点の公開情報にもとづく一般的な解説です。個別の契約・システムの判断は、開発会社や専門家にご相談ください。
あわせて読みたい関連記事
