パフォーマンスチューニングの案件では、依頼の内容が「もっと速くしてほしい」という一言だけで進むことがあります。表示や処理の完了までの体感が遅い、という感覚は共有できても、どこまで縮めれば完了と言えるのかは、その一言だけでは決まりません。目標が言葉になっていない状態で着手すると、改善を重ねても「まだ遅い」という指摘が続きやすくなります。地方公共団体の情報システムを対象にした公開資料には、性能に関する要件を整理するための型が示されています。

1. 「速くしてほしい」だけでは、終わりが決まりません

基準がないまま着手すると、指摘が続きます

目標が数値になっていない状態で改善を重ねても、「まだ遅い」という指摘に対して、どこまでやれば区切りになるのかを示せません。速度を測る条件や、許容できる停止時間の考え方が共有されていないと、双方の感覚のずれが、そのまま作業の終わりの見えなさにつながります。

「速い」という言葉には、応答が返ってくるまでの時間を指す場合もあれば、大量のデータを処理しきるまでの時間を指す場合もあります。どちらの速さを指しているかを揃えないまま作業を進めると、改善の方向性そのものがずれてしまうことがあります。

性能に関する要件は言葉にしにくいため、案件の初期段階では後回しになることもあります。ただし、性能要件を先に整理するための型を示した公開資料があります。次の章から、その型を参考にしながら、水準・数値化しない場合の扱い・測定方法という3つの観点を順番に見ていきます。

速度そのものを追いかけることよりも、終わりの基準を先に言葉にすることのほうが、案件の進み方を左右します。基準を決めてから実装に入る案件と、実装をしながら基準を探る案件とでは、後から発生する手戻りの量が変わってきます。性能に関する要件は、着手前の短い会話だけで言葉にできるとは限りません。ただし、公開されている型を借りれば、白紙の状態から項目を洗い出すよりも、話し合う対象を早く絞り込めます。

図の作成：Remogu編集部。要件を整理する考え方をもとに作成したもので、統計データではありません

2. 公開されている非機能要件の型を借りる

地方公共団体向けの共通基準ですが、型は参考にできます

性能要件を整理するための型は、デジタル庁が総務省と協議して定めた「地方公共団体情報システム非機能要件の標準」に示されています¹。この標準は、標準化法（令和3年法律第40号）第7条に基づく共通基準の1つです¹。

元になっているのは、平成26年3月にJ-LISが作成した「非機能要求グレード（地方公共団体版）」です。今回の第1.2版では、クラウド調達で対象になり得る項目を中心に、最新の状況を鑑みて要件が修正・追加されています²。

この標準は、地方公共団体の情報システムを対象にした共通基準です。民間の案件にそのまま当てはまるものではありません。ここで取り入れたいのは、個別の基準値そのものではなく、レベルの選択肢を示す・数値化しない場合の扱いを決めておく・測定方法を切り分けるという整理の型です。参考にできる公開資料がある、という位置づけで読み進めてください。

性能要件の整理に迷ったときに、白紙の状態から項目を洗い出すのは負担の大きい作業です。分野が異なっていても、要件を分解して型にした資料があれば、話し合う項目の抜け漏れを減らせます。この記事で紹介する型も、地方公共団体向けの数値そのものを持ち込むのではなく、項目の立て方や進め方を借りる、という使い方を前提にしています。次の章では、実際にどのような水準が選択肢として用意されているかを見ていきます。

この標準の位置づけと使い方

ここで、この標準の基本情報と、この記事での使い方を整理しておきます。名称・発行元・根拠法・対象・元になった資料をまとめたのが、次の表です。

項目	内容
名称	地方公共団体情報システム非機能要件の標準（第1.2版）
発行	デジタル庁（総務省と協議して策定）1
根拠	標準化法（令和3年法律第40号）第7条1
元になった資料	非機能要求グレード（地方公共団体版・平成26年3月・J-LIS作成）2
対象	地方公共団体の情報システム（民間の案件には直接当てはまりません）
この記事での使い方	レベルの選択肢・数値化しない場合の扱い・測定方法という整理の型を参考にする

名称や根拠法を細かく覚える必要はありません。押さえておきたいのは、対象が地方公共団体の情報システムであるという一点と、この記事ではその型だけを参考にするという使い方です。

3. レベルは選択肢として並んでいます

レスポンスタイムは5段階の中から選びます

この標準では、レスポンスタイムの水準を「規定しない」「10秒以内」「5秒以内」「3秒以内」「1秒以内」の5段階から選べるようにしています⁷。厳しい水準を選ぶほど応答は速くなりますが、その分だけ備えも重くなります。

5段階のうち「規定しない」は、性能要件そのものを数値で持たない選択肢です。すべての案件でレベルを数値に固める必要はなく、規定しない、という選択も型の一つとして用意されている点は、性能要件を検討するときの安心材料になります。数値を置かない代わりに、何を優先するかを言葉で残しておく、という進め方も選べます。

5秒以内や3秒以内といった中間の水準は、体感速度と備えのバランスを取りやすい選択として使われることがあります。厳しすぎず緩すぎない水準を選ぶ場合も、なぜその水準を選んだかを言葉にしておくと、後から見直すときの手がかりになります。

たとえばレベル4にあたる1秒以内を選んだ場合、用意するハードウェアについて高コストなものが求められる可能性があるため、その必要性を十分に検討する必要があります⁷。速さそのものより、速さを支える備えの重さが、水準を選ぶときの論点になります。

どの水準が適切かは、案件ごとの業務内容や利用者の数によって変わります。この記事では水準そのものを断定するのではなく、選択肢が段階として用意されているという考え方を持ち帰っていただければと考えています。

水準を選ぶ会話は、一度で終わらせる必要はありません。着手前に仮の水準を置き、進捗を見ながら調整するという進め方も、この標準が示す「ベンダーと協議して整理する」という考え方に沿っています。

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

4. 厳しくするほど費用が動きます

水準を1段階上げると、備えの重さも変わります

レスポンスタイムに限らず、性能に関する数値を厳しく設定するほど、用意するインフラの規模やクラウドサービスの費用は動きやすくなります。数値化された内容によっては高コストなクラウドサービスが求められる可能性があるため、精緻な数値化と合わせて、要求する数値の必要性を十分に検討する必要があります⁴。

応答を速くするためには、処理を並行して受け付ける仕組みや、負荷が集中したときの余力を増やす対応が必要になりやすく、こうした対応はサーバーの台数やスペックに直結します。水準を1段階厳しくするだけで、裏側の構成が大きく変わることも珍しくありません。速さを求める前に、その速さがどこまで必要かを確認しておくと、後から構成を見直す手間を抑えられます。

性能を引き上げる方法は、機材を増やす方向と、処理そのものを効率化する方向の大きく2つに分かれます。どちらを選ぶかによっても、必要になる費用や検討にかかる時間は変わってきます。水準を決める段階で、この2つの方向性まで話題にできると、後の検討がスムーズになります。

稼働率についても、同じ考え方が使えます。運用時間を平日のみ1日当たり12時間と想定した場合、稼働率99.9%は年間累計停止時間2.9時間、99.5%は14.5時間、99%は29時間に相当します⁸。パーセントの数字だけでは実感しにくくても、時間に置き換えると、どこまでの停止を許容するかを具体的に話し合いやすくなります。

この換算は、運用時間の前提を平日1日12時間とした場合の一例です。実際の運用時間が異なれば、同じ99.9%でも停止時間の長さは変わります。数値を協議する際は、前提となる運用時間もあわせて確認しておくと、認識のずれを防げます。

水準と、それに伴う備えの関係を整理すると、次の表のようになります。

水準の例	必要になる備え	検討のポイント
レスポンスタイム 1秒以内7	高コストなハードウェアが求められる場合がある7	必要性を十分に検討する
稼働率 99.9%（平日1日12時間運用の場合、年間累計停止時間2.9時間）8	停止を許容できる時間が短くなる	運用時間の前提を確認する
稼働率 99.5%（同条件で年間累計停止時間14.5時間）8	ある程度の停止時間を許容できる	前提条件の一致を確認する
稼働率 99%（同条件で年間累計停止時間29時間）8	さらに長い停止時間を許容できる	業務への影響と照らして検討する

5. 数値化しない場合の扱いも決まっています

「決めない」にも進め方が用意されています

性能に関する項目のすべてを数値で決められるとは限りません。この標準では、ベンダーとの調整で当該項目の数値化を要しないと整理された場合、数値化を一律に求めるとは限らず、「ベンダーによる提案事項」を選び、提案を踏まえて検討することとしています⁵。

数値が決まっていない状態は、進め方が整っていないことを意味するものではありません。決めきれない項目があること自体は珍しくなく、この標準はその状態にも正式な扱いを用意しています。数値化を求めるかどうかを先に協議し、求めない場合は提案事項として扱う、という進め方を選べる点が重要です。

「決めていないから進められない」のではなく、「決めない、という扱いを選んだ」という状態を作れるかどうかが分かれ目になります。この整理があるかないかで、後から出てくる指摘への対応のしやすさも変わってきます。

性能に関する項目を洗い出す過程では、費用や納期との兼ね合いで数値化を見送る判断が生まれることもあります。その判断を「決めていない」で終わらせず、「提案事項として扱う」という言葉に置き換えておくと、後から確認するときの手がかりになります。話し合いの記録として言葉を残しておくことが、数値そのもの以上に意味を持つ場面もあります。

「提案事項」として扱うことにした項目は、後から状況が変わったときに見直しの対象にもなります。数値化しないと決めた理由や、その時点での前提を短くでも書き残しておくと、担当者が変わった場合や、案件が長期化した場合にも経緯をたどりやすくなります。

「提案事項」を選んだ場合でも、ベンダー側からの提案内容を確認せずに進めるわけではありません。提案を踏まえて検討する、という一文が示す通り、最終的な判断は双方の話し合いを経て決まります。

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

6. 数値より先に、測定方法を決めます

測定方法と、調達範囲外の条件を切り分けます

性能・拡張性の前提となる項目は、要件定義の段階で明確にしておく必要があります。利用者数や同時アクセス数、バッチ処理件数といった前提は、後から追加すると設計のやり直しにつながりやすい項目です³。

これらの前提は、着手後に増減しやすい数字でもあります。想定していた利用者数が変わったり、バッチ処理の対象データが増えたりすると、当初決めていた水準では不足する場合もあります。前提そのものを固定するというよりも、前提が変わったときにどう見直すかまで、あらかじめ話し合っておくと安心です。

数値の水準を決めるだけでは、合意にはなりません。測定方法や、ネットワークの状態など調達範囲外の条件については、ベンダーと協議し詳細を整理する必要があります⁶。同じ「1秒以内」という水準でも、どの地点でどう測るかが異なれば、実際の結果は変わります。

測定する地点がクライアント側かサーバー側か、平常時か負荷が高い時間帯かによっても、同じ「1秒以内」という言葉が指す状況は変わります。数値だけを取り決めて測定方法を後回しにすると、達成できたかどうかの判断そのものが割れる原因になります。前提となる項目・測定方法・調達範囲外の条件という3つを、水準と同じくらいの重さで扱っておくと、後から起きる認識のずれを防ぎやすくなります。

パフォーマンスチューニングやSREに近い案件は、こうした要件や測定方法を言葉にして進めるやり取りが中心になるため、リモートでも進めやすい領域です。Remoguに掲載されている案件は、90%以上がフルリモート可能です⁹。

整理した内容は、口頭のやり取りだけで終わらせず、要件定義書や議事録などの形で残しておくと、後から見返すときに役立ちます。特に測定方法や範囲外の条件は、当事者の記憶に依存しやすい項目なので、言葉にして残しておく価値があります。

整理する項目	内容	協議の相手
前提となる項目	利用者数や同時アクセス数、バッチ処理件数など、要件定義時に明確にしておく項目3	発注側とベンダー双方
測定方法	どの地点で、どのタイミングで測るかを整理する6	ベンダー
調達範囲外の条件	ネットワークの状態など、調達の範囲に含まれない条件を切り分ける6	ベンダー

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

7. よくある質問

ここまでの内容を、よくある質問の形でも整理しておきます。

非機能要件の標準は、民間の案件にもそのまま使えますか

この標準は地方公共団体の情報システムを対象にした共通基準です¹。民間の案件にそのまま当てはめられるものではありませんが、レベルの選択肢や数値化しない場合の扱いといった整理の型は、参考にできる公開資料として活用できます。個別の案件でどこまで参考にできるかは、案件の性質によって変わります。

レスポンスタイムは1秒以内を選んだほうがよいですか

水準が厳しいほど応答は速くなりますが、その分だけ用意するハードウェアの費用も動きやすくなります⁷。どの水準が適切かは案件の内容によって異なるため、この記事では特定の水準を推奨するものではありません。速さを求める前に、その速さが業務上どこまで必要かを確認しておくと判断しやすくなります。

稼働率の数値はどのように決めればよいですか

運用時間の前提を決めたうえで、パーセントを時間に置き換えると話し合いやすくなります。たとえば平日1日12時間運用と想定した場合、稼働率99.9%は年間累計停止時間2.9時間に相当します⁸。前提となる運用時間が変わると、この換算も変わります。運用時間の前提を変えずに数値だけを比較すると、認識のずれにつながりやすくなります。

性能に関する項目を数値化できない場合はどうすればよいですか

ベンダーとの調整で数値化を要しないと整理された場合は、「ベンダーによる提案事項」を選び、提案を踏まえて検討するという進め方が用意されています⁵。数値化しないこと自体が問題になるわけではありません。数値化を見送った項目も、話し合いの記録として言葉に残しておくと後から確認しやすくなります。

測定方法まで決める必要があるのはなぜですか

同じ水準の数値でも、測定する地点や条件が異なれば結果は変わります。測定方法や、ネットワークの状態のような調達範囲外の条件は、ベンダーと協議して整理しておく必要があります⁶。測定条件を先に言葉にしておくと、達成できたかどうかの判断が割れにくくなります。

性能要件はいつのタイミングで話し合えばよいですか

要件定義の段階で、前提となる項目・水準の選択肢・測定方法という3点をあわせて協議しておくと、後から手戻りが起きにくくなります³。着手が進んでから持ち出すよりも、早い段階で言葉にしておくほうが、双方の認識をそろえやすくなります。

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

出典・参考情報

＊1 デジタル庁「地方公共団体情報システム非機能要件の標準」第1.2版（2025年9月）
＊2 デジタル庁「地方公共団体情報システム非機能要件の標準」第1.2版（2025年9月）
＊3 デジタル庁「地方公共団体情報システム非機能要件の標準」第1.2版（2025年9月）
＊4 デジタル庁「地方公共団体情報システム非機能要件の標準」第1.2版（2025年9月）
＊5 デジタル庁「地方公共団体情報システム非機能要件の標準」第1.2版（2025年9月）
＊6 デジタル庁「地方公共団体情報システム非機能要件の標準」第1.2版（2025年9月）
＊7 デジタル庁「地方公共団体情報システム非機能要件の標準」第1.2版（2025年9月）
＊8 デジタル庁「地方公共団体情報システム非機能要件の標準」第1.2版（2025年9月）
＊9 Remoguサイト公開情報（案件の90%以上がフルリモート可能）