非機能要件という言葉を案件情報で見かけても、性能や可用性が具体的に何を指すのか、説明できないまま案件を選んでいませんか。画面や操作で確かめられる機能要件と違い、非機能要件は普段の使用感に表れにくく、設計や運用の場面で初めて重みが分かります。この記事では、非機能要件の主な領域から、可用性と性能・拡張性の関係、クラウド基盤での実現、受発注での合意の進め方までを順に整理します。読み終える頃には、非機能要件に関わる案件で何を確かめればよいかが見えてくるはずです。

1. 非機能要件とは何を含むのか

非機能要件とは、システム動作環境に対する要求を定義する際に重要な要件を含む要件です¹。その定義の内容は、業務・情報システム両面で必要な要件を網羅するものです²。

非機能要件の定義

「機能要件は満たしているのに、なぜか本番で評価が上がらない」——そんな声を耳にすることがあります。その理由の一つは、動作環境に対する要求を定義する非機能要件が後回しになっていることです。機能要件が「何をするシステムか」を決めるのに対し、非機能要件は「どれだけ安定して、どれだけ速く、どれだけ守られて動くか」を決める領域だと捉えると、案件で求められる経験の幅が見えてきます。案件を選ぶときは、機能の実装経験よりも、非機能要件を含めた設計に関わった経験のほうが、評価の分かれ目になりやすいところです。

主な領域の全体像

非機能要件がひとつの項目で完結しないところが、最初につまずきやすいポイントです。可用性、性能・拡張性、セキュリティ、運用・保守——領域は複数にまたがり、しかもそれぞれが独立しているわけではありません。可用性を高めようとして仕組みを増やせば、性能や運用の負荷に跳ね返ることもあります。全体像を先に押さえておくと、案件の会話で「どの領域の話をしているか」を見失わずに済みます。次の図で、主な領域の位置関係を整理します。

出典：デジタル庁・総務省『地方公共団体情報システム非機能要件の標準』（2025年）をもとに作成

【表1】非機能要件を理解するときにまず押さえておきたい基本用語です。可用性・性能・拡張性・セキュリティ・運用保守という言葉は案件情報や要件定義の資料に繰り返し登場しますが、意味を取り違えると議論がかみ合いません。それぞれの言葉が指す範囲を、具体的な視点とあわせて整理しました。案件の面談で説明を求められたときに、この整理を思い出せると会話がスムーズに進みます。

用語	意味	具体例
可用性	システムが止まらずに使える状態を保つ度合い	停止時にどこまで許容するかという設計判断
性能	求められる処理量に対して十分な速さで応答できるか	想定する利用者数に見合う応答時間の確保
拡張性	利用者数や処理量が増えたときに対応を広げられるか	前提となる利用者数の変化への備え
セキュリティ	不正なアクセスや操作からシステム基盤を守る仕組み	アクセス管理や監視の設計
運用・保守	動かし続けるための管理や維持の仕組み	監視体制や異常時の対応手順の整備

機能要件との違い

要件には種類があり、業務要件は、情報システムを活用した業務の内容を定義します²。機能要件のうち機能に関する事項では、情報システムに備える機能について、処理内容、入出力情報・方法、入力・出力の関係等を記載します²。業務要件と機能要件は、業務の内容と備える機能を定める要件です。

これに対して非機能要件は、業務・情報システム両面で必要な要件を網羅するものとして定義されます²。処理の中身ではなく、システム動作環境に対する要求を定める側にある点が、機能要件との違いです¹。

業務要件は業務の内容、機能要件は備える機能の処理内容や入出力、非機能要件は動作環境に対する要求と、定義する対象が分かれています。案件情報で要件の名前が出てきたときに、どの種類の話をしているのかを読み分ける手がかりになります。

要件の種類	何を定義するか
業務要件	情報システムを活用した業務の内容2
機能要件	備える機能の処理内容、入出力情報・方法、入力・出力の関係等2
非機能要件	システム動作環境に対する要求を定義する際に重要な要件1。業務・情報システム両面で必要な要件を網羅2

では、非機能要件には具体的にどんな項目が並ぶのでしょうか。

2. 非機能要件の項目一覧と例

主な項目と記載内容

デジタル庁のデジタル・ガバメント推進標準ガイドラインは、非機能要件の定義に多くの項目を挙げています。表はそのうちの主な項目で、すべてを並べたものではありません。項目の名前を押さえておくと、案件情報に「性能」「信頼性」といった言葉が出てきたときに、どの内容の話なのかを照らし合わせられます。

項目	記載する内容の例
規模	機器数、設置場所、データ量、処理件数、利用者数等2
性能	応答時間、バッチ処理時間等。性能が過度にならないよう、適切な要件とします2
信頼性	稼働率等。過度にならないよう、適切な要件とします2
拡張性	情報システムの性能及び機能の拡張性要件2
継続性	障害、災害等による問題発生時に求められる機能、システム構成、その目標復旧時点及び目標復旧時間等2
データマネジメント	2025年5月27日の改定で、非機能要件定義に追加された事項2

規模の項目に並ぶ利用者数は、性能・拡張性を決めるための前提となる項目としても位置づけられています¹。そのため、規模を確かめてから性能の数字を置く順番になります。

一方、停止に関わる要件は一つの項目にまとまっていません。稼働率は信頼性の項目に²、目標復旧時点と目標復旧時間は継続性の項目に置かれています²。止まるときの要件は、複数の項目をまたいで確かめます。

データマネジメントの追加

2025年5月27日の改定で、非機能要件定義に「データマネジメントに関する事項」が追加されました²。規模や性能のように以前から並んでいる項目とは別に、改定で加わった項目です。要件定義書の項目を読むときは、その資料がいつ時点のガイドラインを前提にしているかを添えて確かめると、項目が見当たらない理由も整理できます。

実現性の検証と水準の置き方

非機能要件は、技術的に検討を要する事項を多分に含みます。そのためガイドラインは、日本産業規格等のほか、RFI等を通じて広く情報を取得し、実現性等の検証を行うものとしています²。項目を一覧で眺めるだけでは数字を決められず、実際に実現できるかを情報収集で確かめる手順が、進め方に含まれているわけです。

また、性能と信頼性は高ければ高いほどよいわけではありません。どちらも、過度にならないよう適切な要件とします²。要件の数字を決める場面では、水準を上げる方向だけでなく、適切な範囲に収める判断も求められます。

では、こうした項目のうち、止まらないことに関わる可用性は、性能や拡張性とどう釣り合うのでしょうか。

3. 可用性と性能・拡張性の設計

可用性の考え方とトレードオフ

可用性と聞くと、稼働率の数値をまず思い浮かべるかもしれません。ただ実務で問われるのは数値そのものより、何を制限すれば止まらずに済むかという判断です。操作を制限することで、利便性や可用性に影響する可能性があります¹。つまり可用性は、機能を絞ってでも止めないという判断と、利便性を保ったまま動かし続けるという判断の間で揺れ動く設計上の綱引きです。ここでの経験は、稼働率の目標値を覚えていることよりも、どこを制限しどこを開放するかを事業側と協議した経験のほうが強く効いてきます。

性能・拡張性の前提

性能や拡張性の設計は、利用者数などの前提から始まります。性能・拡張性を決めるための前提となる項目として、利用者数などが位置づけられます¹。想定する利用者数や処理量が変われば、必要な性能も拡張の余地も変わるため、前提条件を最初にすり合わせておくことが、後工程の手戻りを防ぐ近道になります。案件情報だけでは前提が見えないこともあるため、面談で「想定利用者数はどの程度か」を確認する姿勢が、設計者としての信頼につながります。

出典：デジタル庁・総務省『地方公共団体情報システム非機能要件の標準』（2025年）をもとに作成

【表4】可用性と性能・拡張性に関わる案件かどうかを見極めるときに、確認したい観点をまとめました。案件情報には要件の詳細まで書かれていないことがあるため、面談の場でどこまで踏み込んで質問できるかが、経験を正しく伝えられるかの分かれ目になります。表の右側には、確認すると見えてくる案件の実像を添えました。

観点	確認するポイント	案件で見えてくること
可用性の水準	停止をどこまで許容するかの前提	制限と利便性のどちらを優先する設計か
性能の前提	想定利用者数や処理量の見込み	求められる応答速度や処理能力の規模
拡張性の余地	利用者数増加への対応方針	将来を見据えた設計変更の頻度
合意の状態	発注者と受注者の間で水準が確認済みか	要件定義がどこまで固まっているか

稼働率・RPO・RTOとバックアップ

稼働率・RPO・RTOは、どれも停止や障害に関わる指標ですが、測っているものが違います。稼働率はサービスを提供できる割合、RPOは戻す時点、RTOは戻すまでの時間の目標にあたるため、同じ「止まらない」の話でも、どの指標を指しているかで確かめる内容が変わります。

指標	意味
稼働率	明示された利用条件の下で、情報システムが要求されたサービスを提供できる割合1
RPO（目標復旧地点）	業務停止を伴う障害が発生した際、バックアップしたデータなどから情報システムをどの時点まで復旧するかを定める目標値1
RTO（目標復旧時間）	目標復旧時間。SLAに定めていないクラウドサービスでは、稼働率を元に業務停止時間の最大値を算出して検討することが考えられる1

RPOは、バックアップ頻度・バックアップ装置・ソフトウェア構成等を決定するために必要です¹。どの時点まで戻したいかが決まって初めて、どのくらいの間隔でデータを取るかが決まるため、バックアップの設計はRPOの値から始まります。

例として、全体バックアップを週次で取得する場合でも、RPO要件である1日前の状態に戻すためには、毎日差分バックアップを取得することを想定しています¹。これは標準が想定している例です。RPOの値が変われば、取得の間隔も変わります。

一方で、一般的にサービス利用料と稼働率は比例関係にあります¹。稼働率を高めたいほど利用料も上がる方向に動くため、可用性の水準は、先に見た制限と利便性の釣り合いに加えて、費用との釣り合いでも決まります。

RTOについては、目標復旧時間をSLAに定めていないクラウドサービスを利用する場合に、クラウドサービスの提供事業者がSLAで示す稼働率を元に業務停止時間の最大値を算出し、RTOを検討することが考えられます¹。稼働率の数字が復旧にかけられる時間の見積もりにつながるので、3つの指標は独立していません。

これらを実際に支えるのが、クラウド基盤と運用です。次の章では、クラウド基盤での実現と、運用・保守・セキュリティの要件を見ていきます。

4. クラウド基盤での実現と、運用・保守・セキュリティ

クラウド基盤での構築・運用

非機能要件の標準が前提とするのは、IaaSやPaaSなどのクラウドサービスによって提供されるシステム基盤を用いて構築される業務システムです¹。標準では、クラウドサービスによるシステム基盤の構築や運用を要求します¹。オンプレミスの設計経験だけでは判断しづらい部分、たとえば基盤側でどこまで担保され、どこから設計側の責任になるかという線引きは、クラウド基盤での構築・運用に関わった経験があるかどうかで理解の速さが変わります。

運用・保守・セキュリティの要件

構築して終わりではなく、動かし続ける段階での要件も非機能要件の範囲です。システム基盤に対するセキュリティや運用管理上の要件を定義することが求められます¹。監視や異常時の対応手順、アクセス管理といった運用・保守の設計は、開発工程だけを見ていると経験として積み上がりにくい領域です。開発フェーズの経験よりも、運用・保守まで見届けた経験のほうが、こうした要件を任される際には評価されやすいところです。

出典：デジタル庁・総務省『地方公共団体情報システム非機能要件の標準』（2025年）をもとに作成

【表6】クラウド基盤での構築・運用や、運用・保守・セキュリティに関わる案件で確かめたい観点です。基盤側がどこまで担保し、設計側がどこから責任を持つかという線引きは案件によって異なるため、表の内容を面談時の質問リストとして使うことができます。あわせて、合意の記録が残っているかも確認したい点です。

観点	確認するポイント	実務での動き方
クラウド基盤の範囲	IaaS・PaaSなど基盤側が担保する範囲	基盤の標準機能と個別設計の切り分け
セキュリティ要件	アクセス管理や監視の要件定義の有無	要件定義書への反映状況の確認
運用管理の体制	異常時の対応手順や監視体制の整備状況	運用フェーズでの役割分担
合意プロセス	グレードを提示し確認した記録があるか	受発注間での認識合わせの進み方

要件は、受発注で合意して初めて機能します。次の章では、要件の合意とグレードでの整理を見ていきます。

5. 要件の合意と、グレードでの整理

非機能要求グレードでの整理

非機能要件は項目の数がいくつもあり、案件ごとに濃淡もあるため、そのまま話し合うと論点がかみ合わなくなりがちです。そこで使われるのが、要件をいくつかの段階（グレード）に整理して、どの水準を満たすかを選ぶ考え方です。可用性なら止まらないことを優先する水準から、コストを抑えて一定の停止を受け入れる水準まで、性能・拡張性やセキュリティも同じように段階を持たせて捉えます。デジタル庁の非機能要件の標準は、J-LISが平成26年3月に作成した非機能要求グレード（地方公共団体版）で示された要求グレードのうち、クラウド調達時の対象となり得る項目を中心に、要件を修正・追加したものです¹。グレードという共通の物差しがあると、発注者と受注者が同じ言葉で水準をすり合わせやすくなります。

受発注での合意

水準を決めるだけでは終わりません。決めた水準を、発注者と受注者の双方が同じ理解で合意しておくことが欠かせません。合意が曖昧なまま進むと、想定していた可用性の水準と、実際に構築された基盤の水準がずれ、後になって「聞いていた話と違う」という食い違いが起きます。要件定義の段階でグレードを提示し、双方で確認し、合意する——この一連の流れに関わった経験は、上流工程での信頼を積み上げる材料です。

図の作成：Remogu編集部。非機能要件を合意していく一般的な流れを整理したもので、統計データではありません

こうした案件は、リモート中心でも関われます。次の章では、案件への関わり方と選ぶ観点を見ていきます。

6. 案件への関わり方と、選ぶ観点

可用性・性能・運用・クラウド基盤の経験が効く

ここまで見てきた可用性、性能・拡張性、クラウド基盤、運用・保守の経験は、それぞれ単独でも案件選びの材料ですが、組み合わさるとさらに強みになります。たとえば可用性のトレードオフを判断した経験と、クラウド基盤での運用経験の両方があれば、要件定義から運用設計まで一貫して関われる案件の候補が広がります。特定の技術や製品の名称を覚えていることよりも、非機能要件をどう考え、どう合意に落とし込んだかという経験のほうが、案件の面談では伝わりやすい材料です。

リモート中心でも関われる

非機能要件に関わる設計や合意の仕事は、対面での折衝が欠かせないように思えるかもしれません。ただ実際には、要件定義の資料をもとにしたオンラインでの協議や、クラウド基盤上での検証作業など、場所を選ばずに進められる部分が含まれます。Remogu（株式会社LASSIC運営）が扱う案件の90%以上がフルリモート可能です³。

冒頭の問いに戻ると、非機能要件の中身を説明できないままになりやすい理由は、画面に表れにくいことと、項目が複数に分かれていることにありました。案件情報にこの言葉を見かけたら、どの項目の話なのか、数字が何を測っているのかを、面談で一つずつ尋ねてみてください。

手がかりになるのは、技術名の数より、何を止めずに何を制限したか、発注者とどの水準で合意したかという経験の中身です。可用性の判断やクラウド基盤の運用に関わった経験は、その問いに答える材料です。

積み上げてきた経験を、場所に縛られない形で活かせる案件があるかどうかは、まず登録して自分の条件と照らし合わせるところから分かります。

7. よくある質問

非機能要件の案件で何を決め、設計するのですか

可用性、性能・拡張性、クラウド基盤の構築・運用、セキュリティや運用管理といった要件を、案件ごとの前提に合わせて定義し、発注者と合意しながら設計します。何をどこまで満たすかは案件ごとに異なるため、要件定義の段階でグレードを確認する動きが欠かせません。

どんな経験が活きますか

可用性のトレードオフを判断した経験、性能・拡張性の前提を利用者数などから見積もった経験、クラウド基盤での構築・運用に関わった経験、運用・保守やセキュリティの要件定義に関わった経験は、いずれも評価の材料です。特定の技術名を数多く経験していることよりも、要件を考え、合意に落とし込んだ経験のほうが伝わりやすいところです。

可用性やクラウド基盤の経験は活きますか

活きます。可用性の判断とクラウド基盤での運用は特に相性がよく、基盤側でどこまで担保されるかを理解していると、要件定義の段階から頼られやすくなります。オンプレミス中心の経験しかない場合も、クラウド基盤との違いを整理して語れれば、経験の伝え方として十分に成立します。

リモートで関われますか

案件により異なりますが、要件定義の資料をもとにしたオンラインでの協議や、クラウド基盤上での検証作業など、場所を選ばずに進められる部分があります。詳しくは前の章で触れたとおりです。積み上げてきた経験を活かせる案件があるかを、確かめるところから始めてみましょう。

機能要件と非機能要件の違いは何ですか

機能要件のうち機能に関する事項は、備える機能の処理内容や入出力情報・方法等を記載するものです²。非機能要件は、システム動作環境に対する要求を定義する際に重要な要件を含みます¹。

非機能要件グレードとは何ですか

デジタル庁の非機能要件の標準は、J-LISが平成26年3月に作成した非機能要求グレード（地方公共団体版）の要求グレードを元に、クラウド調達時の対象となり得る項目を中心に要件を修正・追加したものです¹。

バックアップの取得間隔はどう決めますか

RPOを先に決め、そこからバックアップ頻度等を決めます¹。標準が想定する例は、週次の全体バックアップで1日前に戻すときに、毎日差分バックアップを取得するものです¹。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 デジタル庁「地方公共団体情報システム非機能要件の標準」（2025年9月・2026年9月確認）
＊2 デジタル庁「デジタル・ガバメント推進標準ガイドライン」（2025年5月・2026年9月確認）
＊3 Remogu（株式会社LASSIC運営）公開情報：扱う案件の90%以上がフルリモート可能