実装を積み重ねてきたエンジニアが、次に見る先はアーキテクチャ設計の案件です。ただ、非機能要件まで任されたとき、可用性やRTOをどの水準で決めればよいのか、判断の基準が定まらないまま進めることになりがちです。水準を高く取りすぎればコストが膨らみ、抑えすぎれば停止が起きたときに責任を問われます。この記事では、非機能要件をどこで固定するかの考え方と、その判断を任される案件の見分け方を整理します。

1. アーキテクチャ設計の案件で、いま問われていること

アーキテクチャ設計の案件とは（実装からの越境）

アーキテクチャ設計の案件は、実装だけを担う案件と切り分けて発注されることが増えています。求められるのは、機能を動かす設計だけでなく、可用性や性能、セキュリティといった非機能要件まで含めて全体の構成を決める役割です。実装の経験を積んだエンジニアにとって、ここは次に越境できる領域になります。

ただし、越境した先で最初に戸惑うのは、非機能要件の水準を決める場面です。要件定義の段階で水準が決めきられていない案件もあり、設計を担う側が根拠を示しながら固定していく場面に出会います。

この越境は一度で終わるものではありません。要件は稼働を始めたあとにも見直されることがあり、水準を固定した根拠を書き残しておくと、次に判断が必要になったときにも参照できます。

非機能要件が握れると任される範囲が広がる

可用性やRTOのような非機能要件を任されるようになると、設計の裁量は大きく広がります。機能要件だけを実装する立場から、システム全体の前提を決める立場に移っていくためです。操作の経験を積むことよりも、非機能要件を固定した根拠を残す経験のほうが、次の案件で評価される差になります。

任される範囲には、使用する技術の選定や、システム全体の構成を描く工程も含まれます。実装だけを担っていた頃には見えなかった判断が増える一方、それに比例して裁量も大きくなっていきます。

では、水準を1段変えると、実際にはどれだけの差になるのでしょうか。地方公共団体情報システムの非機能要件の標準に示された数値で見てみます。

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

稼働率という言葉は同じでも、そこに定める水準が1段違うだけで、許容される停止時間には大きな差が生まれます。次の章で、その差を具体的な数値で確認します。

2. 可用性を1段変えると、何がどれだけ変わるか

99%と95%で年間停止時間はここまで違う

デジタル庁と総務省が示す地方公共団体情報システムの非機能要件の標準では、平日1日12時間運用を想定した場合、稼働率99%での年間累計停止時間は約29時間です¹。

同じ想定で稼働率を95%まで下げると、年間の累計停止時間は約145時間まで広がります²。稼働率という表記だけを見ると小さな差に思えますが、実際に止まってよい時間で比べると、その差は一目で分かります。

この標準が示す数値は、平日1日12時間運用という前提のもとで算出されたものです¹。24時間稼働のシステムとは前提が異なるため、自分が関わる案件の運用時間に合わせて読み替える視点が必要になります。

重要度が高いほど水準を上げる

この標準では、住民記録システムのように安否確認に必要なデータを持つシステムには、稼働率99.5%という水準が示されています³。停止したときの影響が大きい業務ほど、水準を高い側に固定する考え方です。

さらに、大規模災害の発災後72時間を業務継続性の目安として位置づけている点も見逃せません⁴。これは自治体システムに固有の話ではなく、非機能要件を段階で定義し、条件で固定するという考え方の実例として読み替えられます。

重要度に応じて水準を分けるという発想は、システムの種類を問わず使えます。すべてを高い水準で固定するのではなく、影響の大きさに応じて範囲を絞ることが、コストと信頼性の釣り合いを保つ鍵になります。

稼働率別に見る年間停止時間の目安

ここまでの数値を、稼働率と年間停止時間、想定される業務の関係として整理すると、水準を選ぶときの判断材料になります。同じ非機能要件の標準の中でも、業務の重要度によって示される水準が異なり、時間で示されるものと示されないものがある点も併せて確認しておきます。数値を並べて比べることで、どの水準を選ぶかの検討がしやすくなります。

稼働率	年間停止時間の目安	想定される業務・位置づけ
99%	約29時間1	一般的な業務システムの水準として示される例
95%	約145時間2	停止の影響を抑えたいものの、最上位までは求めない業務
99.5%	本資料では時間の記載なし	住民記録システム等、安否確認に必要なデータを持つシステムの例3

表の3行目には、時間の記載がない項目があります。示されていない数値を推測で埋めることはできないため、この記事でも「記載なし」のまま扱っています。数値がない項目でも、重要度に応じて水準を上げるという考え方自体は変わりません。

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

稼働率の水準によって、停止時間には数十時間から百時間を超える規模の差が生まれることが分かりました。次は、この差を踏まえて、非機能要件をどこで固定するかを考えます。

3. 非機能要件を「どこで固定するか」の決め方

業務の重要度と停止許容から決める

非機能要件を固定するときの起点は、業務の重要度と、止まってよい時間の長さです。住民記録システムの例のように、影響が大きい業務ほど水準を高く固定し、影響が限定的な業務では標準的な水準で足りることもあります³。重要度を先に決めてから水準を選ぶ順番を守ると、判断の根拠が残ります。

重要度を測る基準は、業務そのものだけでなく、利用者の数や、停止した場合に生じる二次的な影響にも及びます。判断の根拠を複数の角度から積み重ねておくと、後から水準を説明しやすくなります。

コストとのトレードオフ（上げすぎない）

水準を上げるほど、備えるための仕組みとコストは増えていきます。非機能要件の標準では、目標復旧時間（RTO）を「2時間以内」から「1営業日以上」まで、複数の水準から選ぶ形で定義しています⁵。これは、非機能要件に単一の正解があるわけではなく、業務の性質に合わせて段階から選ぶものだと示しています。

水準を必要以上に高く取ることは、過剰設計につながります。逆に低く抑えすぎると、停止時間の許容を超えてしまいます。コストをかけることよりも、重要度に見合った水準で固定することのほうが、設計を担う側としての評価につながります。

RTOの水準を「2時間以内」のように短く固定するほど、備える仕組みは複雑になります⁵。短い時間を選ぶこと自体が目的になってしまうと、業務の重要度と釣り合わない構成になりかねません。

非機能要件を固定するときの3つの判断軸

業務の重要度、停止許容時間、コストという3つの軸を並べて確認すると、非機能要件をどこで固定するかを検討しやすくなります。それぞれの軸で「何を問うか」を先に決めておくと、水準を選ぶ根拠を後から示しやすくなります。1つの軸だけで判断すると、重要度は高いのにコストが見合わない、あるいはコストは抑えられたのに停止許容を超えるといった食い違いが起きやすくなります。3つの軸を同時に確認する順番を守ることが、固定した水準に説明力を持たせる近道になります。次の表は、軸ごとに確認する問いと、決め方の視点を整理したものです。

判断軸	確認する問い	決め方の視点
業務の重要度	止まると誰の何に影響するか	重要度が高い業務ほど、要求水準を高い側で固定する
停止許容時間（RTO）	止まってよい時間はどれくらいか	目標復旧時間は複数の水準から選ぶ形で定義されている5
コストとの釣り合い	水準を上げるとコストはどれだけ増えるか	重要度に対して過不足のない水準で固定する
見直しの余地	状況が変わったら水準を見直せるか	固定した前提を文章に残し、変更時に再検討できるようにする

図の作成：Remogu編集部。非機能要件を固定する位置を検討するための考え方を整理したもので、統計データではありません

重要度と停止許容、コストのつり合いで水準を固定できれば、非機能要件は決めきれないものではなくなります。この前提を明文化しておくことは、リモートで案件に関わるときに、さらに効いてきます。

4. リモート・フリーランスで設計に関わるときの進め方

前提と根拠を文章で残す

対面が前提の現場では、非機能要件の前提を口頭で補いながら進めることができます。リモートで設計に関わる場合は、その場の説明に頼れない分、前提と根拠を文章に残すことが判断の質を左右します。稼働率をどの水準で固定したか、その理由は何かを書き残しておくと、後から参照する側も同じ判断基準に立てます。

文章に残すのは、結論だけではありません。他の水準を選ばなかった理由まで書き添えておくと、後から前提が変わった場合にも、判断をやり直しやすくなります。

責任範囲は協議で決める

非機能要件まで任される案件では、どこまでの範囲を担うのかが曖昧なまま進むと、後になって負担だけが増えることがあります。着手前にクライアントと協議し、責任範囲を条件として確認しておくことが、リモートで設計に関わるときの土台になります。クライアントと条件を協議しながら決めていく関係だと捉えておくと、進め方の見通しが立てやすくなります。

責任範囲を先に決めておくのは、範囲を狭めるためではありません。どこまでを担い、どこからをクライアント側の判断とするかを明確にすることで、双方が同じ前提で進められるようになります。

対面前提と非同期での進め方の違い

対面が前提の進め方をそのままリモートに持ち込むと、伝わっていたはずの前提が抜け落ちることがあります。会議室で交わされていた一言のすり合わせや、その場の空気で共有されていた優先順位は、非同期の進め方では自然には残りません。場面ごとに、対面前提の進め方と非同期での進め方を並べて確認すると、どこを文章に残すべきかが見えてきます。次の表は、前提の共有から責任範囲の確認まで、進め方の違いを整理したものです。

場面	対面前提の進め方	非同期・リモートでの進め方
前提の共有	会議の場で口頭にすり合わせる	前提と根拠を文章に残し、参照できる場所に置く
判断の根拠	その場の説明で補足する	判断の理由をドキュメントに書き添える
責任範囲の確認	進めながら都度確認する	着手前にクライアントと協議し、範囲を明確にする
変更の伝達	集まって説明する	変更履歴を残し、非同期でも追える形にする

前提を文章に残し、責任範囲を協議で決める進め方は、リモートでの設計判断を支える土台になります。とはいえ、すべての案件で非機能要件まで任されるわけではありません。次は、その裁量がある案件をどこで見分けるかを見ていきます。

5. 非機能要件に関われる案件かを、どこで見極めるか

非機能要件を握れる立ち位置か

非機能要件に関わる裁量があるかどうかは、案件の記載内容から見分けられます。実装範囲だけが細かく指定されている案件は、非機能要件がすでに固定済みで、変更の余地が小さい傾向があります。一方で、重要度や停止許容から一緒に検討する余地が示されている案件は、設計判断そのものに関わりやすい立ち位置です。

案件の記載内容を読むときは、実装対象の技術だけでなく、非機能要件に関する記述があるかどうかも確認すると、関わる余地の大きさが見えてきます。記述が薄い場合でも、面談の場で重要度や停止許容の検討余地を確認する方法があります。

意思決定者と直接話せるか

非機能要件を固定する判断は、最終的にクライアント側の意思決定者が握っています。複数の窓口を経由してやり取りする案件では、判断の理由まで共有されにくくなります。意思決定者と直接話せる案件のほうが、非機能要件を握れる立ち位置に近づきます。

Remoguが扱う案件は、案件の90%以上がフルリモート可能です⁶。リモートのまま、非機能要件を握れる立ち位置に近い案件を確認できます。

図の作成：Remogu編集部。案件を見極める観点を整理したもので、統計データではありません

非機能要件を握れる立ち位置かどうかは、案件の記載内容と、意思決定者との距離で見分けられます。ここまでの考え方を、まとめとして整理します。

6. まとめ

アーキテクチャ設計の案件で非機能要件まで任されるかどうかは、水準をどこで固定するかを判断できるかどうかにかかっています。ここまでの内容を整理します。

• 稼働率を99%から95%まで下げると、年間の累計停止時間は約29時間¹から約145時間²まで広がります。
• 非機能要件は、業務の重要度と停止許容、コストのつり合いで固定するものであり、単一の正解を選ぶものではありません。
• リモートで設計判断に関わるときは、前提と根拠を文章に残し、責任範囲を協議で決めることが土台になります。
• 非機能要件を握れる案件かどうかは、案件の記載内容と、意思決定者と直接話せるかで見分けられます。

非機能要件まで任される案件は、実装だけを担う案件とは見え方が異なります。まずは、自分の経験に合う関与度の案件がどれくらいあるかを確かめてみましょう。Remoguに登録すれば、リモートを前提とした環境で、その一歩を踏み出せます。

7. よくある質問

非機能要件とアーキテクチャ設計の案件について、よく聞かれる点をまとめます。

可用性はどこまで上げるべきですか

業務の重要度と停止許容から判断します。影響が大きい業務では水準を高い側に固定し、影響が限定的な業務では標準的な水準で足りることもあります³。上げすぎるとコストが増えるため、重要度に見合った水準を選ぶ視点が欠かせません。目標復旧時間も同様に、複数の水準から業務に合う段階を選ぶ形になります⁵。

未経験でも非機能要件に関われますか

実装の経験を積んだ立場からでも、案件の記載内容に重要度や停止許容を一緒に検討する余地が示されている案件であれば、関わりやすくなります。最初から水準の決定をすべて担うのではなく、既存の水準を確認し、その根拠を文章として整理する役割から始める進め方もあります。段階を踏んで関与度を広げていけば、非機能要件の判断に慣れていくことができます。

リモートで設計判断はできますか

対面前提の進め方をそのまま持ち込むのではなく、前提と根拠を文章に残し、責任範囲を協議で決める進め方に切り替えれば、リモートでも設計判断に関われます。意思決定者と直接話せる案件かどうかも、判断のしやすさに影響します。

非機能要件に関わると報酬は上がりますか

報酬は案件によって異なり、一律の基準は示されていません。ただし、非機能要件まで含めて設計を任される立ち位置は、実装だけを担う立ち位置とは関与の範囲が異なります。自分の経験がどの関与度の案件に合うかは、条件を確認しながら判断する形になります。気になる案件があれば、登録して条件を確認してみるところから始められます。

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

出典・参考情報

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