負荷試験や性能検証を数多くこなしてきたエンジニアほど、非機能要件の案件は最初から数値の基準が渡され、それを満たしているかどうかを検証する仕事だと捉えがちです。ところが公共分野の標準を読み解くと、仕事の起点はもっと手前にあります。項目ごとに用意された複数のレベルから、どれを選ぶのかを決める工程がまず存在するのです。この記事では、地方公共団体情報システム非機能要件の標準をもとに、選ぶという工程の中身と、そこでこれまでの経験がどう活きるかを整理します。読み終えたときには、案件を見る目線が少し変わっているはずです。

1. 負荷試験の案件は、数値の前に選択がある

「決められた値を満たす」だけの仕事ではありません

性能試験や負荷試験を数多く担当してきたエンジニアほど、非機能要件の案件は最初から数値の基準が渡され、それを満たしているかどうかを検証する仕事だと捉えがちです。求められた基準値に沿って淡々と測定を重ね、結果を報告書にまとめる、という進め方を思い浮かべることもあるはずです。実際、そのイメージのまま参画できる案件も存在します。一方で、数値が渡されないまま検討が始まり、何を基準に進めればよいのか戸惑う場面に出会うこともあります。

ところが公共分野の標準を読み解くと、仕事の起点はもっと手前にあります。項目ごとに複数のレベルが用意されていて、どのレベルを選ぶのかを決める工程が、数値を測定する作業より先に存在しているのです。試験計画を立てる前に、選ぶという判断がすでに挟まっています。この順番を知っているかどうかで、案件の進め方に対する理解の深さが変わります。

基準を満たしているかどうかを黙々と確認する経験より、なぜそのレベルを選んだのかを言葉にして説明できる経験のほうが、案件では重みを持ちます。測定の技術そのものは前提として求められますが、差になるのはその手前にある判断の部分です。打ち合わせの場でも「なぜこの水準にしたのか」を尋ねられる場面が、測定結果を説明する場面より先に来ることがあります。

図の作成：Remogu編集部。標準が示す選択レベルの考え方を整理したもので、統計データではありません

この標準が何を土台にしているか

この標準の土台になっているのが「非機能要求グレード（地方公共団体版）」です。平成26年3月に地方公共団体情報システム機構（J-LIS）が作成したもので、国が新たに作った基準ではありません。この標準は、そのグレードで示された要求のうち、クラウド調達において対象になり得る項目を中心に、要件を修正・追加したものです²。土台を知っておくと、条文の位置づけを取り違えにくくなります。どこまでが従来からの要件で、どこからが今回の修正・追加なのかを分けて読めるようになるからです。

適用範囲についても明確にされています。原則として、クラウドサービスとして提供されるシステム基盤を対象としている点は、押さえておきたいところです⁸。独自に構築した基盤をそのまま想定した文書ではなく、クラウド調達という文脈が前提にあります。この前提を最初に共有できていると、案件の初期段階での認識合わせがスムーズになります。

ここからは、実際にどうレベルを選ぶのかを見ていきます。

2. 選び方には手順が決まっている

条件が書かれている項目は、条件の有無で分かれます

各項目には「選択時の条件」という欄が用意されていて、そこにプラス条件やマイナス条件が書かれているかどうかによって、選び方の道筋がまず分かれます。この欄を最初に確認するかどうかで、後の作業の進めやすさが変わってくる、という点は押さえておきたい構造です。数値だけを追いかける前に、この欄を開く習慣があるかどうかが分かれ目になります。

プラス条件やマイナス条件が書かれている項目では、国が示した「選択レベル」をそのまま選ぶのか、その条件の下で別のレベルを選ぶのかという二択になります³。条件に自分たちの状況が当てはまるかどうかを確かめる作業が、ここでの実務になります。条件文を読み飛ばすと、この判断自体が抜け落ちてしまいます。打ち合わせの初期段階でこの条件を確認しておくと、後になって前提を問い直す手戻りを避けやすくなります。

条件の記載がない項目は、規模とリスクの物差しで選びます

プラス条件・マイナス条件のどちらも書かれていない項目は、判断の物差しがまったく変わります。自治体の規模や、業務の性質、リスク受容方針等に応じて選ぶことになっています⁴。物差しが変わることを知らないまま数値だけを追うと、判断の根拠を後から示せなくなります。

リスク受容方針という言葉が出てくる点が、この標準の特徴です。どこまでのリスクを受け入れるかを決める作業であり、単純な正解が1つ用意されているわけではありません。基準を満たすかどうかより、選んだ理由を残せるかどうかのほうが、後になって効いてくる場面が多くなります。この方針を尋ねられたときに答えられる経験は、案件を通じて少しずつ積み上がっていきます。

手順を一覧で整理すると

項目ごとに条件の有無をまず確認し、当てはまる状況を照らし合わせ、選んだ理由を書き残す。この3段階を一覧にすると、次の表のようになります。条件を読み飛ばさない順番を身につけておくと、担当する項目や案件が変わっても迷いにくくなります。

項目の状態	選び方	確認すること
プラス条件・マイナス条件の記載がある項目	国が示した「選択レベル」を選ぶのか、その条件の下で別のレベルを選ぶ	条件に書かれた状況が、自分たちに当てはまるかどうか
プラス条件・マイナス条件のどちらも記載がない項目	自治体の規模、業務の性質、リスク受容方針等に応じて選ぶ	規模・業務の性質・受け入れるリスクの水準

手順が決まっているということは、外から参画するエンジニアにとって取り組みやすい構造でもあります。この流れを押さえておくと、案件の中で判断に迷う場面は着実に減っていきます。

3. 2025年9月の改定で、裁量の幅が広がった

第1.2版で何が変わったか

この標準は2025年9月に第1.2版へ改定されました。焦点になっているのは、幅を持たせられる項目の扱いです。自治体の規模や業務の性質、リスク受容方針等に応じて、自治体が自らの裁量でレベルを選択できる取扱いとする改定が行われています¹。改定の方向がはっきりしている点は、この標準の読み解き方に直結します。何が変わり、何が変わっていないのかを分けて把握しておくと、案件ごとの説明もぶれにくくなります。

「レベルを選べるようにする」という改定の方向は、この標準がもともと土台にしている「非機能要求グレード（地方公共団体版）」——平成26年3月にJ-LISが作成したもの——から続く要件を、最新の状況に合わせて修正・追加してきた結果でもあります²。積み重ねの延長線上にある改定だと捉えると、位置づけを見誤りません。

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

決める仕事から、選んで示す仕事へ

決められた値をなぞる仕事と、レベルを選んで理由を示す仕事とでは、日々の進め方がまったく違います。前者は基準に対する適合を確認する作業が中心になり、後者は条件を照らして選択肢を絞り込み、費用やリスクの言葉で説明する作業が中心になります。

この変化は、外から参画するエンジニアにとって追い風です。決まった手順をなぞるだけの経験よりも、なぜそのレベルを選んだのかを言語化してきた経験のほうが、評価される場面がこれから増えていくからです。決められた作業をこなす役割から、選定の理由を担う役割へ、少しずつ立ち位置が移っていく変化でもあります。

とはいえ、すべての項目が自由に選べるわけではありません。プラス条件・マイナス条件が書かれている項目では、これまで通り条件に沿った選び方が求められます。裁量が広がったのは、あくまで幅を持たせ得る項目に限られる点は、正確に押さえておきたいところです。どの項目が対象になるのかを見極める作業自体も、経験があるほど早く進められます。

時期	レベルの決め方	エンジニアの仕事
第1.2版より前	幅を持たせ得る項目でも、示された選択レベルを満たすことが中心	示された基準を満たしているかどうかを確認する
2025年9月の第1.2版以降	自治体が自らの裁量でレベルを選択可能な取扱いに	選んだ理由を、費用やリスク受容方針の言葉で示す

次の章では、この裁量の広がりが最も分かりやすく表れる「性能」の話に移ります。利用者数という前提から、費用の話まで一続きになっている構造を見ていきます。技術と費用が同じ会話の中でつながる場面は、非機能要件ならではの特徴です。

4. 性能の前提は利用者数、そして費用につながる

利用者数が、性能とシステム環境の前提になる

性能・拡張性の項目では、情報システムの利用者数がまず前提になります。想定する利用者数は、性能や拡張性を決めるための前提であると同時に、システム環境を規定する項目でもあります⁵。この二重の役割を押さえることが、この章の出発点です。どちらか一方だけを見て試験計画を立てると、後になって前提を組み直す必要が出てきます。

つまり、負荷試験で確かめる数値そのものより先に、どれくらいの利用者が使う前提のシステムなのかという判断がすでに置かれています。この前提を確認せずに測定だけを進めると、選んだレベルの理由を後から言葉で説明できなくなってしまいます。利用者数を尋ねる質問は、案件の初期段階で最初に交わされる会話の1つになりやすい部分です。

測定の技術より、前提を確認する順番のほうが、選んだ理由を支えます。数値を追う前に利用者数という前提に立ち返る習慣をつけておくと、担当する案件が変わっても迷いにくくなります。

利用者数は、費用の話にも直結する

利用者数の想定は、費用の話にも及びます。利用者数は、パッケージソフトやミドルウェアのライセンス価格に影響することがあります⁶。技術の話がそのまま費用の話に変わる場面です。技術選定を説明する立場になったとき、この結びつきを理解しているかどうかで、話の通りやすさが変わってきます。

技術の選び方を説明する言葉と、費用を説明する言葉が地続きになっている、という点は覚えておきたい構造です。次の表に、利用者数がどこに効いてくるのかを整理しました。案件で技術選定を任されたときに、この2つの影響先を思い出せるかどうかで、説明の説得力が変わります。

影響先	具体的な内容	案件での位置づけ
システム環境の規定	性能・拡張性を決める前提となる項目であり、システム環境を規定する項目でもある	決まった値をなぞるのではなく、想定利用者数から環境を導く判断
ライセンス費用	パッケージソフトやミドルウェアのライセンス価格に影響することがある	技術選定の説明が、費用の説明と直結する

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

利用者数という1つの前提が、環境の規定と費用の両方に効いてくる。この一続きの流れを言葉にできることが、外から参画するエンジニアの価値になります。

5. 可用性のレベルは、何を想定しているか

災害対策の項目が想定しているもの

可用性の中でも災害対策の項目は、特別な出来事のために用意されています。地震、水害、テロ、火災といった大規模災害が発生し、被災した場合に備えることを想定して設けられている項目です⁷。まず、この前提を理解することから始まります。可用性の話をするとき、何を想定した項目なのかを共有できているかどうかが、会話の出発点を左右します。

ここで大切なのは、被害の程度を予測する項目ではないという点です。標準が示しているのは「備えることを想定して項目が置かれている」という事実であり、実際に何が起こるかを断定するものではありません。この違いを取り違えると、必要以上に強い言い方で可用性を語ってしまうことになります。

この前提を理解しておくと、可用性のレベルを検討する会話に落ち着いて参加できます。想定される事象の種類を踏まえたうえで、どこまで備えるかを選ぶ、という順番になるからです。

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

可用性も、規模とリスク受容方針で選びます

可用性のレベルも、プラス条件・マイナス条件が書かれていない項目であれば、自治体の規模や業務の性質、リスク受容方針等に応じて選ぶという同じ考え方に沿います⁴。性能でも可用性でも、選び方の骨格は共通しています。

骨格が共通しているということは、1つの項目で身につけた「条件を確認し、理由を残す」という進め方が、別の項目でもそのまま使えるということです。経験が積み重なるほど、案件の中での動きは速くなっていきます。性能で身につけた進め方を可用性でも使えると気づけるかどうかが、案件をまたいだ経験の活かし方を分けます。

可用性のレベルまで含めて考えると、非機能要件の案件全体が1つの流れとして見えてきます。数値を測る前に、選ぶという判断がある。この記事の主張は、ここまでの章に一貫しています。選ぶという視点を持って案件に向き合えるかどうかが、これから先の非機能要件との関わり方を分けていきます。

6. まとめ

ここまで見てきたように、非機能要件の案件は、数値を測る前に選ぶという工程があります。プラス条件・マイナス条件が書かれている項目は、その条件に沿って選びます³。条件が書かれていない項目は、規模や業務の性質、リスク受容方針等に応じて選びます⁴。

2025年9月の第1.2版では、この選ぶという行為そのものに、自治体の裁量が広がりました¹。性能は利用者数という前提から費用の話へ、可用性は想定される大規模災害への備えへとつながっていて、どの項目も「選んで、理由を示す」という同じ骨格を持っています⁷。

だからこそ、外から参画するエンジニアの価値は、測定の技術そのものより、選んだ理由を費用とリスクの言葉で説明できることにあります。この経験は、非機能要件に限らず、条件を確認して判断を残す仕事全般で活きていきます。負荷試験や性能検証、可用性の設計に携わってきた経験そのものが、すでにこの記事で述べてきた土台と重なっています。

場所に縛られず、裁量を持って、積み上げてきた経験を正当に活かしたい。そう感じている方にとって、Remoguはリモート案件に特化したエンジニアマッチングです。案件の90%以上がフルリモート可能です⁹。まずは登録して、自分の経験に合う条件を確かめてみることが、次の一歩になります。

7. よくある質問

この標準は民間企業の案件にもそのまま使われますか

この標準は地方公共団体の情報システムを対象にした公共分野の標準です⁸。民間企業の案件にそのまま適用されるものではありませんが、項目ごとにレベルを選び、条件と理由を言葉にするという考え方は、公共以外の案件でも参考になります。

非機能要件に関わる案件は、どんなシステムを対象にしていますか

この標準は原則として、クラウドサービスとして提供されるシステム基盤を適用範囲としています⁸。負荷試験や性能検証、可用性の設計に携わってきた経験は、対象になるシステムの前提を理解するうえでそのまま活きます。

非機能要件の経験を、案件を探すときにどう伝えればよいですか

測定の結果だけでなく、なぜそのレベルを選んだのかを、費用やリスク受容方針の言葉で説明できることを伝えると、経験の価値が伝わりやすくなります。Remoguに登録すると、自分の経験に近い条件の案件を確認できます。条件を照らして選び、理由を残すという進め方そのものが、これまでの経験を言葉にする材料になります。

性能や可用性のレベルを検討した経験がなくても、この記事の内容は役立ちますか

負荷試験や性能検証、可用性の設計に携わった経験があれば、この記事で扱った「選ぶ」という考え方はそのまま活かせます。条件を確認し、理由を残すという進め方は、担当する案件が変わっても土台になります。この記事で触れた5つの視点を手元に置いておくだけでも、初めての案件に入る際の見通しは立てやすくなります。選択レベル、手順、改定、利用者数、可用性という順番を思い出せれば、条件を確認する会話にも落ち着いて臨めます。

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

出典・参考情報

＊1 デジタル庁「地方公共団体情報システム非機能要件の標準」第1.2版の改定内容（2025年9月）
＊2 デジタル庁「地方公共団体情報システム非機能要件の標準」非機能要件の標準について（2025年9月）
＊3 デジタル庁「地方公共団体情報システム非機能要件の標準」非機能要件の標準の利用方法（2025年9月）
＊4 デジタル庁「地方公共団体情報システム非機能要件の標準」非機能要件の標準の利用方法（2025年9月）
＊5 デジタル庁「地方公共団体情報システム非機能要件の標準」非機能要求グレード活用シート B.1.1.1（2025年9月）
＊6 デジタル庁「地方公共団体情報システム非機能要件の標準」非機能要求グレード活用シート B.1.1.1（2025年9月）
＊7 デジタル庁「地方公共団体情報システム非機能要件の標準」非機能要求グレード活用シート A.3.2.1（2025年9月）
＊8 デジタル庁「地方公共団体情報システム非機能要件の標準」適用範囲（2025年9月）
＊9 Remoguサイト公開情報（フルリモート可能案件の割合）