公共システムの案件は、要求水準が重いと聞くたびに足がすくむものです。ところが、実際に何を審査され、どこで予算が決まるのかを説明できる人は限られています。国の情報システムは、性格の異なる3つの区分に分かれており、区分によって求められる経験も単価の考え方も変わります。この記事では、統括・監理の仕組みと3つの区分を整理し、参画前に確認しておきたい視点をまとめます。

1. 統括・監理とは何をされることなのか｜審査と一括計上の2点

公共のシステム案件と聞くと、要求水準の重さばかりが気になり、実際に何を審査され、誰が予算を握っているのかが見えないまま二の足を踏む場面が出てきます。まず押さえたいのは、「統括・監理」という言葉が指している中身です。

デジタル庁は、国等の情報システムを統括・監理し、各事業が基本方針に従っているか等を審査する仕組みを整えています²。案件は思いつきで進めてよいものではなく、通る前提を満たしているかを常に問われる性質を持っています。

何を審査されるのか

審査で見られているのは、個々の技術選定の巧拙だけではありません。情報システムの標準化や統一化によって、相互の連携を確保できているかという観点が重ねて確認されます³。

言い換えると、単体で動くかどうかより、他のシステムとつながる前提で作られているかが問われます。設計の段階から連携を意識できるかどうかで、レビューの通りやすさは変わってきます。

予算はどう決まるのか

もう1つの柱が、予算の仕組みです。情報システムの予算はデジタル庁に一括計上され、そこから各府省に配分されて執行される形になっています⁴。窓口が一本化されている点は、民間の受発注とは大きく異なります。予算の相談先が1つに絞られている分、要望が通るかどうかの筋道も、民間とは違う形で見えてきます。

この一括計上は、政府全体の方針に沿った戦略的な投資を行うための仕組みでもあります⁵。案件ごとの都合より、政府全体の優先順位が先に立つ場面があることは、見積もりの前提として押さえておきたい点です。図2に、予算が配分されていく流れを整理しました。

出典：デジタル庁「国等の情報システムの統括・監理」（2026年6月）をもとに作成

2. 3つの区分｜共通基盤・共同プロジェクト・各府省システム

デジタル庁は、国等の情報システムを、①デジタル庁システム、②デジタル庁・各府省共同プロジェクト型システム、③各府省システムという3つの区分に整理し直しました¹。同じ「公共案件」でも、この区分によって案件の性格はまったく異なります。

区分が変わると、整備・運用の主体も変わります。共通基盤としての性格が強い区分もあれば、複数の府省をまたぐ移行が中心になる区分、個別の業務システムとしてレビューを受ける区分もあり、参画前に見分ける視点が要ります。方針全体は、行政サービスの改革と業務システムの改革を一体的に進める考え方に立っています¹⁶。

区分ごとに整備・運用の担い手が変わる

①デジタル庁システムは、各府省の共通基盤となるものであり⁶、デジタル庁自身が整備・運用の主体になります。共通基盤である以上、1つの変更が他の府省のシステムにまで影響する重みを持ちます。

②と③は、デジタル庁と各府省が共同で、あるいは各府省が主体となって進める点で①と異なります。誰が最終的な意思決定者かを把握しておくと、案件の相談先や進め方の見通しが立てやすくなります。担い手が分からないまま設計を進めると、後になって別の意思決定者から差し戻しを受ける場面も出てきます。図1に、区分ごとの担い手の違いをまとめました。

出典：デジタル庁「国等の情報システムの統括・監理」（2026年6月）をもとに作成

なぜ区分を意識する必要があるのか

統括・監理の対象は、国の情報システムに限りません。国、地方公共団体、準公共部門等の情報システムの整備・管理についても、共通の基本方針が及んでいます¹⁵。案件の裾野は、想定より広く見ておいたほうが実態に近づきます。

区分を確認せずに案件へ参画すると、求められる互換性の水準やレビューの重さを見誤り、見積もりが後から崩れる原因になります。逆に言えば、区分さえ押さえておけば、初めて関わる案件でも身構える範囲を絞り込めます。区分と、案件で問われることの違いを、表1に整理しました。

区分	整備・運用の主体	案件で問われること
①デジタル庁システム	デジタル庁自身（各府省の共通基盤として整備・運用6）	相互接続を崩さない互換性、標準化への追随3
②共同プロジェクト型システム	デジタル庁と各府省が共同で推進	LAN統合・構造刷新・クラウド化という移行の実務
③各府省システム	各府省が整備し、政府全体でレビューを受ける14	基本方針・中長期計画に沿った、レビューを通す前提の設計

3. 第1区分の案件｜共通基盤だから互換性の要求が重い

第1区分であるデジタル庁システムは、各府省の共通基盤です⁶。共通基盤としての性格は、案件で問われる中身に直接跳ね返ってきます。

個別の業務を効率化する仕組みと違い、影響範囲が1つの府省にとどまりません。設計の前提を誤ると、連携している複数のシステムに波及する点が、この区分の特徴です。1つの府省の都合だけで仕様を決めることはできず、他の府省がどう使っているかを常に視野に入れておく必要があります。

互換性という要求の重さ

情報システムの標準化や統一化によって、相互の連携を確保しようとする方針が明確に示されています³。第1区分の案件では、独自仕様を積み上げるより、標準に沿っているかどうかがまず問われます。

「動けばよい」という発想では通りません。仕様を決めるたびに、他のシステムとの接続点を確認し、影響範囲を洗い出す作業が積み重なります。共通基盤ならではの手間として織り込んでおきたいところです。設計を1人で完結させず、影響を受ける側との調整を前提にスケジュールを組む姿勢が求められます。

参画前に確かめておきたい視点

この区分に関わる案件では、設計書やインターフェース仕様を読み解く力に加え、変更が他の府省システムにどう波及するかを説明する力が求められます。単体の実装力だけでは評価が伸びにくい領域です。仕様書の行間を読み、書かれていない前提を関係者に確認できるかどうかも、この区分では実務上の強みになります。

独自の最適化より、標準への追随を優先する場面が多く出てきます。「自分の技術で最適化する」より「決められた標準に沿わせる」ほうが評価される、という発想の転換が求められます。この転換に早く慣れられるかどうかが、共通基盤の案件で長く関わり続けられるかの分かれ目になります。

4. 第2区分の案件｜LAN統合・構造刷新・クラウド化という移行の実務

②デジタル庁・各府省共同プロジェクト型システムでは、複数の取組が同時に進んでいます。バラバラに整備されてきた各府省のLAN環境の統合が、その1つです¹¹。

加えて、運用等経費が特に大きい情報システムの構造刷新¹²、個別情報システムのクラウド化・UI/UXの改善¹³も、同じ区分の取組として進められています。共通するのは、既存の仕組みを作り直す「移行」の実務だという点です。

3つの取組の中身

LAN統合は、府省ごとに個別最適化されてきたネットワーク環境を1つにまとめる取組です。構造刷新は、運用コストが膨らんだ既存システムの仕組みそのものを見直す取組で、現行踏襲からの脱却が焦点になります。どちらも、新しい機能を足す仕事ではなく、積み重なってきた個別事情をほどいていく仕事だという理解が出発点になります。

クラウド化・UI/UXの改善は、個別システムを対象に、基盤をクラウドへ移しながら使い勝手を高める取組です。3つとも「新しく作る」より「置き換えて整える」実務が中心になります。図3に、取組の並びを整理しました。

出典：デジタル庁「国等の情報システムの統括・監理」（2026年6月）をもとに作成

移行の実務で問われる経験

この区分では、要件を新しく決める力より、既存の仕組みを壊さずに移し替える手順設計の力が評価されます。切替時の検証やロールバックの計画まで説明できるかどうかが、任される範囲を左右します。

取組ごとに担いやすい範囲は変わります。ネットワークの実務経験があればLAN統合、コスト構造の見直し経験があれば構造刷新、UI設計の経験があればクラウド化・UI/UX改善というように、経験の棚卸しが参画先を決める材料になります。得意な取組を1つ決めてから探すほうが、案件情報を眺めるだけの状態から抜け出しやすくなります。表2に、取組ごとの範囲をまとめました。

取組	内容	参画者が担いやすい範囲
LAN統合	各府省でばらばらに整備されてきたLAN環境を1つにまとめる取組11	ネットワーク設計、移行手順の整備、切替時の検証
構造刷新	運用等経費が特に大きい情報システムの仕組みを刷新する取組12	現行踏襲からの脱却、コスト構造を見直す設計
クラウド化・UI/UX改善	個別情報システムをクラウド化し、使い勝手を高める取組13	クラウド移行の実装、画面・操作性の改善

5. 第3区分の案件｜レビューを通す前提で設計する

③各府省システムは、各府省が整備・運用の主体になる個別の業務システムです。単独で進められるわけではなく、政府全体のプロジェクトについてのレビューを受ける位置づけにあります¹⁴。

レビューは、事業が基本方針に従っているか等を審査する仕組みの一部です²。「通ってから直す」のではなく、通る前提で設計を組み立てる姿勢が、この区分では特に重視されます。

何に沿って設計するのか

基本方針は、情報システムの整備及び管理の基本的な方針（整備方針）として決定されています⁷。整備方針は令和3年12月24日にデジタル大臣が決定したものであり⁸、以降の各府省の計画の土台になっています。

各府省は、この方針を受けて、業務改革や経費削減の方針、投資等の取組を具体化した中長期的な計画を策定しています⁹。デジタル庁自身も、中長期計画を策定しています¹⁰。設計はこの計画との整合を問われます。

レビューを通す前提での設計

レビューを通す前提で設計するというのは、根拠を後から用意するのではなく、方針・計画のどこに沿っているかを最初から説明できる状態で設計を進めるということです。図4に、方針・計画・レビューの関係を整理しました。

出典：デジタル庁「国等の情報システムの統括・監理」（2026年6月）をもとに作成

独自の判断で仕様を決めるより、方針・計画に照らして選択の理由を示せるほうが、レビューは通りやすくなります。「早く作る」より「説明できる形で作る」ことが、この区分では単価にもつながる強みになります。設計の根拠を文書に残す習慣は、レビュー対応に限らず、次の案件を任されるときの信頼にも積み上がっていきます。

6. 単価につながるスキルの整理｜区分を見極められるかで変わります

ここまで見てきた3つの区分は、それぞれ問われる経験が異なります。共通基盤での互換性設計、移行の実務、レビューを通す設計は、似ているようで求められる力の中身が違います。

単価は技術の新しさだけで決まるわけではありません。どの区分の案件かを見極め、自分の経験がどの区分で生きるかを説明できるかどうかが、協議の材料になります。新しい技術を知っているより、区分ごとの要求を見抜けるほうが、公共案件では評価につながりやすい強みです。

関わり方ごとの経験と単価の考え方

共通基盤に関わる経験は、相互接続を壊さない設計力として評価されやすい領域です。移行の実務に関わる経験は、切替時の検証まで含めて語れると、次の案件の単価協議で強みになります。

レビュー対応に関わる経験は、方針・計画に沿った設計文書を作成し、説明できる力として評価されます。3つの関わり方と、生きる経験・単価の考え方を表3に整理しました。

関わり方	生きる経験	単価の考え方
共通基盤（第1区分）に関わる	相互接続・標準化に沿った設計経験、影響範囲を見極める力	互換性を壊さない設計ができる経験は評価されやすい領域です
移行の実務（第2区分）に関わる	LAN統合やクラウド移行の手順設計、切替時の検証経験	移行の実務を通した経験が次の単価協議の材料になります
レビュー対応（第3区分）に関わる	方針・計画に沿った設計文書の作成、説明する力	レビューを通した実績は上流工程の単価に結びつきやすい領域です

自分の経験をどう言い換えるか

「システムを構築しました」で止まる説明では、どの区分で力を発揮できるのか伝わりません。「共通基盤との接続を維持したまま設計しました」のように、区分を意識した言葉に置き換えると、評価する側に伝わりやすくなります。過去の案件を振り返り、どの区分の性格に近かったかを言葉にしておくだけでも、次の面談での説明は変わってきます。

Remoguでは、案件の90%以上がフルリモート可能です。まず登録して、自分の経験がどの区分に近いかを確かめてみることが、単価協議の材料を増やす近道になります。

7. リモートでの進め方と、よくある質問

ここまでの区分の違いは、リモートでの進め方にも関わってきます。共通基盤の案件は関係者が多く、移行の実務は切替のタイミングに関わる調整が発生し、レビュー対応は文書でのやり取りが増えます。区分を把握しておくと、リモートでの連携の設計もしやすくなります。対面でなければ伝わらないと思われがちな調整も、区分ごとの勘所を押さえていれば、資料と定例のやり取りだけで進められる場面は増えていきます。

どの区分であっても、クライアントと協議しながら進める姿勢は共通です。受け身で待つのではなく、区分ごとに問われる観点を踏まえて、確認しておきたい点をこちらから示せると、参画後の信頼につながります。画面越しのやり取りが中心になるほど、こうした一つひとつの確認が信頼の土台になっていきます。

統括・監理の対象は国の情報システムだけですか

対象は国だけではありません。国、地方公共団体、準公共部門等の情報システムの整備・管理についても、共通の基本方針が及んでいます¹⁵。案件を探す範囲は、国の機関だけに限定して考えなくてよいということです。

区分がわからないまま案件に参画してしまうことはありますか

案件情報だけでは、区分までは読み取りにくい場合があります。整備・運用の主体や、レビューの有無を確認する視点を持っておくと、参画前の見極めがしやすくなります。分からない点は面談の場でクライアントに確認してよく、確認すること自体が信頼を損なうわけではありません。まず登録し、経験に合う案件を相談しながら探す進め方も選べます。

レビュー対応の案件は経験がまだ少なくても参画できますか

レビュー対応そのものは、方針・計画に沿っているかを説明する力が問われる領域です。経験がまだ少ない場合は、共通基盤や移行の実務など、別の区分から実績を積む道もあります。最初から上流に立とうとするより、実務で信頼を積んでから説明の場面を任されるほうが、遠回りに見えて着実な道筋になります。

どの区分から始めても、区分を意識した経験の言い換えができれば、次の案件では上流に近い関わり方を目指せます。行き先に迷ったら、まず自分の経験がどの区分に近いかを、Remoguで確かめてみることから始められます。

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

出典・参考情報

＊1 デジタル庁「国等の情報システムの統括・監理」3つの区分（2026年6月）
＊2 デジタル庁「国等の情報システムの統括・監理」審査の仕組み（2026年6月）
＊3 デジタル庁「国等の情報システムの統括・監理」連携の確保（2026年6月）
＊4 デジタル庁「国等の情報システムの統括・監理」予算の流れ（2026年6月）
＊5 デジタル庁「国等の情報システムの統括・監理」投資の考え方（2026年6月）
＊6 デジタル庁「国等の情報システムの統括・監理」第1区分（2026年6月）
＊7 デジタル庁「国等の情報システムの統括・監理」方針の名前（2026年6月）
＊8 デジタル庁「国等の情報システムの統括・監理」決定の日付（2026年6月）
＊9 デジタル庁「国等の情報システムの統括・監理」計画の中身（2026年6月）
＊10 デジタル庁「国等の情報システムの統括・監理」庁の計画（2026年6月）
＊11 デジタル庁「国等の情報システムの統括・監理」第2区分の中身（2026年6月）
＊12 デジタル庁「国等の情報システムの統括・監理」第2区分の中身（2026年6月）
＊13 デジタル庁「国等の情報システムの統括・監理」第2区分の中身（2026年6月）
＊14 デジタル庁「国等の情報システムの統括・監理」第3区分の扱い（2026年6月）
＊15 デジタル庁「国等の情報システムの統括・監理」対象の広さ（2026年6月）
＊16 デジタル庁「国等の情報システムの統括・監理」全体の狙い（2026年6月）