当サイトの記事は編集部が国土交通省・IPA・デジタル庁などの公的機関の情報、規格や業界団体の公開情報を調べて独自に執筆しています。記事内にIT・Webエンジニアの転職サービスへの案内（広告）を含みます。
要件定義書を書いていて、機能の一覧はできたのに『非機能要件の欄に何を書けばいいの？』と手が止まってしまう。そんな方も多いはずです。
結論から言うと、非機能要件とは「何ができるか」以外の、システムの質に関する決めごとです。止まらないか、速いか、情報を守れるか、直したり移したりしやすいか、の4つの問いに置き換えると、ぐっと決めやすくなります。
この記事を読めば、要件定義書に書く項目と、決めるまでの進め方が分かります。
非機能要件とは？機能要件との違い
機能要件は「システムで何ができるか」、非機能要件は「それをどのくらいの質でできるか」です。同じ機能でも、非機能要件が違えば作り方も費用も変わります。
デジタル庁の標準ガイドライン群用語集では、非機能要件を「機能要件以外の情報システム要件のこと」としています。具体的には、性能や信頼性、拡張性、運用性、セキュリティなどが挙がっています。
一方の機能要件は、同じ用語集で「システム要件のうち機能に関する内容」とされています。
- システムで何ができるか
- 例：注文を登録できる
- 例：月末に集計表を出せる
- それをどのくらいの質でできるか
- 例：注文が多い日でも待たされない
- 例：夜間も止まらずに動く
例えばこんな場面で考える
ネットで注文を受け付けるシステムを例にしてみますね。「注文を受け付ける」は機能要件です。
「セールの日にアクセスが集中しても、画面がすぐ出てほしい」
「お客さんの住所や電話番号は、外に漏れないようにしてほしい」
こうした声が非機能要件です。機能の一覧には出てこないけれど、なければ困ることばかりですよね。
非機能要件を4つの問いに置き換える
非機能要件の言葉は硬くて分かりにくいものです。「止まらない？」「速い？」「守れる？」「直せる・移せる？」の4つの問いにすると、業務の担当者とも話しやすくなります。
『可用性とか拡張性とか言われても、ピンとこない…』という方もいますよね。そこで編集部では、非機能要件を4つの問いに置き換えた確認表を作ってみました。
| 問い | 主に当たる非機能要件 | 業務の担当者への聞き方の例 |
|---|---|---|
| 止まらない？ | 可用性、信頼性、継続性 | 止まったら困る時間帯はいつですか？ 止まった時、どれくらいで戻ればいいですか？ |
| 速い？ | 性能、拡張性、規模 | 一番混む日はいつですか？ 何人くらいが同時に使いますか？ |
| 守れる？ | セキュリティ | 外に出てはいけない情報は何ですか？ 誰がどこまで見てよいですか？ |
| 直せる・移せる？ | 運用・保守性、移行性、引継ぎ | 毎日の確認は誰がしますか？ 今のデータはどこまで移しますか？ |
4つの問いで聞くと答えが出やすい
業務の担当者に「可用性の要件を教えてください」と聞いても、答えに困ってしまいます。でも「止まったら困る時間帯はいつですか？」なら、すぐに答えが返ってくるんです。
返ってきた答えを、要件定義書では正式な項目名に戻して書きます。聞く時はやさしい言葉、書く時は正式な言葉、と使い分けるのがコツですよ。
問いごとに、もう一歩深く聞くこと
最初の答えが返ってきたら、もう一歩だけ深く聞いてみましょう。ここで聞いた事が、そのまま要件定義書の中身になります。
- 止まらない？：止まった時に、紙や電話など代わりのやり方で業務を続けられるかも聞く
- 速い？：今は何人で使っていて、数年後にどれくらい増えそうかも聞く
- 守れる？：情報を見る人だけでなく、変えたり消したりできる人も決める
- 直せる・移せる？：困った時の連絡先と、今のシステムをいつ止めるかも決める
例えば「止まったら困るのは月末の締めの日だけ」と分かれば、ほかの日は点検の時間にあてられます。全部の日を同じ水準にしなくていいので、費用も抑えやすくなるんです。
要件定義書の非機能要件に書く項目
要件定義書の非機能要件の項目は、IPAの「非機能要求グレード2018」と、デジタル庁の「DS-100」が参考になります。全部を書く必要はなく、自分のシステムに関係する項目を選んで書きます。
IPAの非機能要求グレードは、非機能要件の項目を大項目から細かい項目まで順に並べた資料です。現行の非機能要求グレード2018は、2018年4月に公開されています。
大項目は6つです。2019年のIPAセミナー資料では、全体が6大項目、34中項目、116小項目、238メトリクスで組み立てられていると紹介されています。
| 大項目（非機能要求グレード2018） | 4つの問いでいうと |
|---|---|
| 可用性 | 止まらない？ |
| 性能・拡張性 | 速い？ |
| 運用・保守性 | 直せる？ |
| 移行性 | 移せる？ |
| セキュリティ | 守れる？ |
| システム環境・エコロジー | 置き場所や設置の条件 |
国のガイドラインに並ぶ非機能要件
デジタル庁のDS-100では、要件定義書の非機能要件として次の事項を挙げています。国の情報システム向けですが、民間でも項目の抜けを確かめるのに役立ちます。
- ユーザビリティ及びアクセシビリティ、システム方式、規模
- 性能、信頼性、拡張性、上位互換性、中立性
- 継続性、情報セキュリティ、情報システム稼働環境
- データマネジメント、テスト、移行、引継ぎ
- 教育、運用、保守
このうち「データマネジメント」は、2025年5月27日の改定で加わった事項です。「中立性」は、特定の会社の技術にしばられないよう、オープンな標準的技術や製品を使うことなどを書く事項とされています。
小さなシステムなら、まずここから
『こんなに項目があると、小さな社内ツールには重すぎる…』と感じた方もいますよね。小さなシステムなら、まずは次の項目から書いてみてください。
- 使う人数と、混む時間帯
- 止めてはいけない時間帯
- 見てよい人と、変えてよい人
- データの控えをどこに、どのくらいの間隔で取るか
- 困った時に誰が直すか
非機能要件定義書を別に作ることもある
非機能要件の量が多い時は、要件定義書の本体とは別に「非機能要件定義書」として1冊にまとめることもあります。分けた場合は、要件定義書の本体から参照先を書いておくと迷いません。
要件定義書全体の目次の作り方は、要件定義書の書き方｜項目・目次と、伝わる書き方のコツで紹介しています。
非機能要件の決め方
非機能要件は、業務の担当者の声を聞き、確かめられる言葉に直し、費用と釣り合うかを見て決めます。高いほど安心ですが、そのぶん費用もかかります。
『全部「高い水準」にしておけば安心じゃないの？』と思いますよね。ただ、止まらない仕組みや速い仕組みは、そのぶん作る費用も動かす費用もかかるんです。
- 4つの問いで、業務の担当者に困る場面を聞く
- 聞いた答えを、正式な項目名に当てはめる
- 「すぐ」「たくさん」を、確かめられる言葉や数字に直す
- 開発側に、実現の方法と費用の目安を出してもらう
- 費用と釣り合う水準に決めて、要件定義書に書く
架空の記入例で見る書き方
社内の勤怠を記録するシステムを例に、編集部で架空の記入例を作ってみました。数字の所は、実際には業務の担当者と相談して埋めていきます。
| 項目 | よくないメモ | 確かめられる書き方の例 |
|---|---|---|
| 性能 | 速いこと | 出勤の打刻画面は、朝の混む時間帯でも○秒以内に表示する |
| 可用性 | 止まらないこと | 平日の○時から○時は止めない。点検は休日の夜に行う |
| セキュリティ | 安全なこと | 他の社員の勤怠は、所属長と人事担当だけが見られる |
| 移行性 | データを移す | 今の表計算ファイルの過去○年分を移し、件数を照らし合わせる |
「速いこと」「安全なこと」のように、確かめようのない言葉で書いてしまうことがあります。テストの時に合格かどうかを決められないので、後で言った言わないの原因になります。
決めた非機能要件は、次の基本設計で具体的な仕組みになります。つなぎ方は基本設計書とは？書く項目と書き方（外部設計）を見てみてください。
非機能要件でよくある相談
よくある相談は「機能と性能の違い」「機能要件と非機能要件の区別」「お客さんから非機能要件を言われることはあるか」などです。
よく寄せられる相談を、内容をまとめた形で紹介しますね。
相談1：機能と性能は何が違う？
機能は性能に含まれないのか、機能要件と非機能要件の区別が分からない、という相談です。
機能は「何ができるか」、性能は「それをどのくらい速く、たくさんこなせるか」です。性能は非機能要件の一つなので、機能とは別の欄に書きます。
相談2：資格の勉強で、機能要件と非機能要件の違いがつかめない
情報処理の資格の勉強をしていて、2つの違いがよく分からない、という相談もあります。
覚え方としては、「その要件をなくすと、できる事が減るか」を考えてみてください。できる事が減るなら機能要件、できる事は同じでも使い心地や安心感が落ちるなら非機能要件です。
相談3：非機能要件は、お客さんから求められることもある？
非機能要件は、顧客からの要求として出てくる場合もあるのか、という相談です。
あります。
「夜も止めたくない」「個人情報は社外に出したくない」のように、お客さんの言葉で出てくることが多いんです。
ただ、言われない項目もあるので、開発側から4つの問いで聞いていくと抜けを防げます。
相談4：非機能要件の説明を読んでも、ピンとこない
非機能要件を調べたら、説明の文章が難しくて分からなかった、という相談もありました。
そんな時は、身近なお店に置き換えてみてください。「商品を売る」が機能なら、「行列ができてもすぐ会計できる」「お金を盗まれない」「閉店後に棚を入れ替えられる」が非機能要件です。
非機能要件を決められる人になりたい方へ
非機能要件は、業務と技術の両方が分かる人が求められる所です。聞き出して、数字に直して、費用と釣り合わせる経験は、上流工程の仕事で大きな強みになります。
非機能要件の打ち合わせは、業務の担当者と開発の担当者の間に立つ仕事です。どちらの言葉も分かる人がいると、話がぐっと早く進みます。
要件定義や設計書を書く経験は、上流工程を任される職場で評価されやすいものです。今の職場で経験を積むのも大切な道ですし、担当工程から一歩進みたい人は、求人の仕事内容を比べてみると道が見えてきます。
IT・Webエンジニアの転職（PR）
仕様書を書く経験を活かせる職場を探すなら、求人も比べてみる
要件定義や設計を任されるか、発注側か開発側か、扱うシステムや働き方は会社によって大きく違います。担当したい工程や条件から、IT・Webエンジニアの求人を比べてみてください。
無料ITエンジニアの求人を探す求人の条件・待遇は各求人票と応募先の案内でご確認ください。
よくある質問
非機能要件とは何ですか？
機能要件以外の情報システムの要件のことです。性能、信頼性、拡張性、運用性、セキュリティなど、システムの質に関する決めごとを指します。
要件定義書の非機能要件には何を書けばいいですか？
IPAの非機能要求グレード2018の6つの大項目や、デジタル庁のDS-100に並ぶ事項が参考になります。全部ではなく、自分のシステムに関係する項目を選んで書きます。
非機能要件定義書は別に作るものですか？
量が少なければ要件定義書の1章として書き、多ければ別の文書にまとめることもあります。別にした時は、要件定義書の本体から参照先が分かるようにしておきましょう。
非機能要件を書かないと、どうなりますか？
開発側がそれぞれの判断で作ることになり、思っていたより遅い、止まる時間が長いといった食い違いが起きやすくなります。テストで合否を決める基準もなくなってしまいます。
非機能要件は誰が決めますか？
求める水準を決めるのは発注側です。開発側は実現の方法と費用の目安を出し、両者で釣り合いを見ながら決めていきます。
まとめ
- 非機能要件は「何ができるか」以外の、システムの質に関する要件
- 止まらない・速い・守れる・直せる移せるの4つの問いで聞くと決めやすい
- 書く項目は非機能要求グレード2018とDS-100が参考になる
- 確かめられる言葉や数字で書き、費用と釣り合う水準にする
コメント