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

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

非機能要件の定義

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

主な領域の全体像

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

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

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

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

まず要となるのが、可用性と性能・拡張性です。次の章では、この2つの関係を具体的に見ていきます。

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

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

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

性能・拡張性の前提

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

非機能要件は項目の数がいくつもあり、案件ごとに濃淡もあるため、そのまま話し合うと論点がかみ合わなくなりがちです。そこで使われるのが、要件をいくつかの段階（グレード）に整理して、どの水準を満たすかを選ぶ考え方です。可用性なら止まらないことを優先する水準から、コストを抑えて一定の停止を受け入れる水準まで、性能・拡張性やセキュリティも同じように段階を持たせて捉えます。グレードという共通の物差しがあると、発注者と受注者が同じ言葉で水準をすり合わせやすくなります。

受発注での合意

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

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

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

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

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

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

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

非機能要件に関わる設計や合意の仕事は、対面での折衝が欠かせないように思えるかもしれません。ただ実際には、要件定義の資料をもとにしたオンラインでの協議や、クラウド基盤上での検証作業など、場所を選ばずに進められる部分が含まれます。Remogu（株式会社LASSIC運営）が扱う案件の90%以上がフルリモート可能です⁷。積み上げてきた設計や運用の経験を、居住地や通勤の制約に縛られずに活かせる案件があるかを、まず登録して確かめてみることが、次の一歩になります。

非機能要件の経験を、自分に合う条件でどう活かせるか——ここまでの内容をまとめとよくある質問で振り返り、次の一歩につなげます。

6. まとめ

非機能要件は、機能要件と違って画面には表れませんが、案件の評価を左右する領域です。ここまでの内容を振り返ります。

• 非機能要件には、可用性、性能・拡張性、クラウド基盤、運用・保守やセキュリティといった複数の領域が含まれます。
• 可用性は稼働率の数値そのものより、何を制限し何を守るかというトレードオフの判断です。
• 性能・拡張性は利用者数などの前提から設計が始まり、クラウド基盤の構築・運用の経験が土台になります。
• 要件は、グレードで段階を整理し、発注者と受注者が合意して初めて機能します。
• こうした経験は、場所を選ばずに活かせる案件にもつながっています。

積み上げてきた設計や運用の経験を、次にどう活かすか——まずは登録して、自分に合う条件の案件があるかを確かめてみましょう。

7. よくある質問

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

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

どんな経験が活きますか

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

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

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

リモートで関われますか

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

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

出典・参考情報

＊1 デジタル庁「地方公共団体情報システム非機能要件の標準」（2025年9月）
＊2 デジタル庁「地方公共団体情報システム非機能要件の標準」（2025年9月）
＊3 デジタル庁「地方公共団体情報システム非機能要件の標準」（2025年9月）
＊4 デジタル庁「地方公共団体情報システム非機能要件の標準」（2025年9月）
＊5 デジタル庁「地方公共団体情報システム非機能要件の標準」（2025年9月）
＊6 デジタル庁「地方公共団体情報システム非機能要件の標準」（2025年9月）
＊7 Remogu（株式会社LASSIC運営）公開情報：扱う案件の90%以上がフルリモート可能