申請フォームを組み、審査状況を確認できる画面を作り、動くところまで届けて終える。これまでの案件は、納品した時点で役目を終えるものがほとんどでした。デジタル庁は、政府情報システムに統一的な指標で満足度を測る仕組みを整えようとしています¹。集めるのは定量的な満足度や利便性についてのフィードバックで、直接収集して分析できる仕組みが対象です²。しかもこの仕組みは、システムに組み込む評価機能と、収集したデータを分析するダッシュボードという2つの部品で構成されています³。測る仕組みまで含めて設計できるかどうかが、これからの案件で問われる経験を分けていきます。

1. 満足度の評価機能とは何を作る仕事なのか｜2つの部品で考える

評価機能とダッシュボードという言葉だけを見ると、既存の画面に1枚足す仕事のように思えるかもしれません。ですが中身を見ていくと、担う範囲はもう少し広がっていきます。

令和8年8月には、政府情報システムの開発または運用・保守を請け負う事業者と、請け負おうとする事業者を対象にした説明の場も開かれています¹⁰。対象になっているのは、まさにこれから案件に関わろうとする立場の技術者です。

システムに組み込む評価機能で問われる経験

組み込む側の評価機能は、利用者からの満足度や利便性についての声を、システムの中で直接収集する仕組みです²。フォームを1つ足す話ではなく、収集したデータが後段の分析にそのまま使える形で残るかどうかまで設計に含まれます。

つまずきやすいのは、入力のしやすさと、データとしての一貫性を両立させる部分です。項目を絞りすぎれば分析に使えず、増やしすぎれば利用者の負担になります。このバランスを取る経験は、フロントの実装経験だけでは積み上がりません。

集めたデータを分析するダッシュボードで問われる経験

もう1つの部品は、収集したデータを分析するためのダッシュボードです³。集めるだけで終わらせず、傾向を読み取れる形に整えるところまでが範囲に入ります。

集計の経験よりも、数字をどう提示すれば現場の改善につながるかを考える経験のほうが、この部品では差になります。数えるだけの画面と、判断を後押しする画面は、見た目が似ていても中身は別物です。

出典：デジタル庁「政府情報システムにおける利用者満足度評価の導入」をもとに作成

2つの部品でつまずきやすい点を並べて比較する

評価機能とダッシュボードは、担う工程が違えば、つまずく場所も違います。組み込む側は入力設計とデータの一貫性、分析する側は数字を判断材料に変える提示の設計です。どちらも実装経験があるだけでは埋まらない差になります。次の表に、部品ごとの主な仕事内容と求められる経験、つまずきやすい点を整理しました。

部品	主な仕事内容	求められる経験	つまずきやすい点
システムに組み込む評価機能	満足度・利便性の声を直接収集する仕組みの実装	入力設計とデータの一貫性を両立させる経験	項目を絞りすぎて分析に使えなくなる
収集データを分析するダッシュボード	収集したデータを可視化し傾向を読み取れる形に整える	数字を判断材料に変える提示の設計経験	集計だけで終わり改善につながらない

2. なぜいま測る話になったのか｜計画と答申という2つの根拠

この仕組みは、思いつきで始まったものではありません。政府情報システムにおける利用者満足度評価の導入は、令和8年7月21日に閣議決定された計画を根拠としています⁴。計画という形で決まっている以上、案件の側もその前提に合わせて動くことになります。

加えて、規制改革推進に関する答申等も後押しの1つになっています⁵。計画という縦の根拠と、答申という横からの後押しが重なったことで、統一的な指標を整える方向が固まりました¹。

令和8年7月の計画決定が示す方向

計画に基づく取り組みの狙いは、各府省庁が自律的かつ継続的に改善活動を行える環境を整えることに置かれています⁷。1回作って終わりではなく、作った後も改善を続けられる状態を目指す方向です。

このため評価機能は、単発の満足度調査を代わりに行うものではありません。日々の利用の中でフィードバックを集め続け、改善のたびに参照できる状態を保つ仕組みとして位置づけられています。運用し続けられる設計が前提になります。

閣議決定という形を取ったことも見過ごせません⁴。府省庁ごとの判断に委ねるのではなく、政府情報システムに関わる案件全体に共通の前提として広げていく決め方だからです。個別の発注者との相談ごとではなく、案件全体の土台が動いている話として受け止める必要があります。

規制改革推進の答申が後押しする理由

もう一つの根拠として挙げられているのが、規制改革推進に関する答申等です⁵。作る側の都合で完了を判断してきた進め方に、利用者の満足度という物差しを重ねる動きだと読めます。

技術力の高さよりも、利用者にどう使われているかを説明できる経験のほうが、この文脈では評価されやすくなります。動くかどうかの説明から、伝わっているかどうかの説明へと、求められる言葉が変わっていきます。

計画と答申という2つの根拠が重なっている以上、この動きは一時的な施策では終わりません。前提を早く押さえているかどうかが、次に来る調達の要件を先取りできるかどうかを分けていきます。次の章では、その要件が具体的にどう変わるのかを見ていきます。

3. 調達に入るということの意味｜案件の要件がどう変わるのか

方針は、調達プロセスの見直しや研修・勉強会等を通じた普及啓発により活用を推進するとされています⁶。つまり、この評価の仕組みは案内文の中だけにとどまらず、実際の調達要件として案件に落ちてくる話です。

調達に組み込まれるということは、見積もりの前提そのものが変わるということでもあります。ここまでを作れば納品、という線引きが1段階後ろにずれていきます。

見積もる範囲がどう動くか

これまでの案件は、画面が動作すること、データが正しく処理されることまでを見積もりの範囲としてきました。これからは、定量的な満足度や利便性のフィードバックを直接収集・分析できる仕組みまでが範囲に含まれます²。

実装工数よりも、収集した後にどう活用されるかまで見通した設計のほうが、見積もりの精度を左右します。作って渡すだけの仕事から、渡した後も参照され続ける仕組みを渡す仕事へと、性質が移っていきます。

見積もりの相談も、この前提を共有できているかどうかで進み方が変わります。仕組みの全体像を先に示せる経験のほうが、要件のすり合わせにかかる時間を短くします。

改善のひと回りのどこが案件の範囲になるか

組み込む、集める、分析する、直すという4つの工程を1周として見ると、案件として担うのは組み込む・集める・分析するまでの3工程です。直すという実際の改善の運用は、各府省庁が自律的に行う活動として位置づけられています⁷。

案件の側は、改善そのものを肩代わりするのではなく、発注者が自分たちで改善を回せる状態まで仕組みを整えるところに責任が置かれます。この線引きを理解しているかどうかで、要件の読み方が変わってきます。

出典：デジタル庁「政府情報システムにおける利用者満足度評価の導入」をもとに作成

これまでとこれからで見積もる範囲を比べる

調達に評価の仕組みが入ることで、完了の定義そのものが変わります。これまでは動作確認と納品で仕事が完結していましたが、これからは収集・分析まで見通した設計が求められます。次の表に、観点ごとにこれまでの案件とこれからの案件の違いを整理しました。

観点	これまでの案件	これからの案件
完了の定義	動作確認と納品で完了	収集・分析まで見通した設計で完了
見積もりの範囲	フロントの実装が中心	評価機能とダッシュボードの実装まで
発注側との関わり	納品後は個別の問い合わせ対応	調達プロセスの見直しを通じた活用の推進

4. 高い場合と低い場合で何が起きるのか｜紹介される側と促される側

測った満足度は、測って終わりにはなりません。利用者満足度の高いシステムは、優良事例として紹介されます⁸。一方で満足度の低いシステムには、改善を促すという対応が取られます⁹。

紹介される側と促される側という2つの道があるとわかると、案件に関わる立場としてどちらの流れに乗るシステムを作っているのかを意識する必要が出てきます。

高い評価が導く紹介という道

利用者満足度の高いシステムは、優良事例として紹介されるとされています⁸。公開した直後だけ高い状態では、紹介の対象として示し続けることは難しくなります。

1回の実装で終わらせず、公開後も指標を追い続けられる設計にできるかどうかが、この道に乗れるかどうかを分けます。作った直後の見栄えよりも、運用してからの推移のほうが問われる場面です。

紹介という形で外に出るということは、1つの案件の中だけで評価が完結しなくなるということでもあります。作ったものが他の府省庁からも見られる状態になる点は、これまでの案件にはなかった性質です。

低い評価が導く改善を促される道

満足度が低い場合は、改善を促すという対応が取られます⁹。その改善は、利用者の声に基づいた継続的な改善を促進する、という考え方の上に成り立っています¹⁵。

促されてから慌てて手を入れるのではなく、あらかじめ改善の余地を残した設計にしておく経験のほうが、この道では役に立ちます。直しやすい構造にしておくことは、評価が動いた後の負担を大きく変えます。

出典：デジタル庁「政府情報システムにおける利用者満足度評価の導入」をもとに作成

高い評価に乗るか、低い評価から改善を促されるかは、案件を受けてから決まるものではありません。設計の時点でどちらの道を見据えているかが、後になって効いてきます。

5. すでに関心は動いている｜128の申込と366名という数字の読み方

この話は、まだ先の予定ではありません。政府情報システムの開発または運用・保守を請け負う事業者及び、請け負おうとする事業者を対象とした勉強会が開かれています¹⁰。実施日は令和8年8月6日で、すでに終えた取り組みです¹¹。

対象になっているのが、これから請け負おうとする事業者まで含まれている点は見過ごせません。すでに関わっている技術者だけの話ではなく、これから参画しようとする立場にも開かれている場です。

対象になったのはどんな事業者か

勉強会の対象は、開発または運用・保守を請け負う事業者と、請け負おうとする事業者の両方です¹⁰。すでに案件に入っている立場だけでなく、これから入ろうとする立場も含めて呼びかけられています。

勉強会ではデジタル庁のサービスデザインに関する取り組みも紹介されています¹⁴。評価の仕組みだけでなく、その手前にある考え方まで共有しようとする姿勢が見えます。

これから請け負おうとする事業者まで対象に含めているのは、すでに関わっている事業者だけで閉じた話にしない姿勢の表れです。参画する前の段階から、情報を追いかけておく価値があります。

申込128と参加366という数字が示す関心の量

この勉強会には、申込事業者数128という規模の関心が集まりました¹²。実際の参加者数も366名にのぼり、1つの案件に関わる範囲を超えて動いている数字です¹³。

数字の大きさよりも、これから請け負おうとする立場までこの場に集まっている、という中身のほうが重い意味を持ちます。情報を早く押さえておくかどうかが、案件に関わり始めるタイミングを左右します。

これだけの事業者が同じ場に集まっている状態は、評価の仕組みが案件の条件として意識され始めていることを示しています。

出典：デジタル庁「政府情報システムにおける利用者満足度評価の導入」をもとに作成

6. 単価につながるスキルの整理｜測る側まで踏み込めるかで変わります

ここまでの流れを整理すると、案件で問われる経験は3段階に分かれていきます。画面に組み込む経験、集計と可視化を担う経験、そして改善の運用に伴走する経験です。

フロントの実装経験だけで止まるよりも、集めたデータをどう可視化し、どう改善の運用につなげるかまで語れる経験のほうが、これからの案件では条件を協議するときの材料になります。

この3段階を意識しておくと、案件を選ぶときの基準も変わります。今の経験がどこまで届いているかを先に把握しておくと、次に踏み出す一歩が具体的になります。

関わり方によって問われる経験は変わる

画面に組み込む関わり方では、入力設計とデータの一貫性を保つ実装経験が問われます。集計と可視化を担う関わり方では、数字を判断材料に変える可視化の経験が問われます。

改善の運用を支える関わり方まで踏み込めると、利用者の声を継続的な改善につなげる運用経験が問われるようになります¹⁵。関わる工程が後ろに進むほど、求められる経験の抽象度も上がっていきます。

3つの関わり方は、経験の深さだけでなく、発注側との距離の近さも変えていきます。改善の運用に近づくほど、発注側とのやり取りの頻度も増えていく傾向があります。

関わり方ごとに単価の考え方を整理する

報酬の水準は案件ごとに異なりますが、どの関わり方まで担えるかは条件を協議するときの材料になります。次の表に、関わり方ごとに求められる経験と、単価を考えるときの材料を整理しました。

関わり方	求められる経験	単価を考えるときの材料
画面に組み込む	入力設計とデータの一貫性を保つ実装経験	収集項目の設計まで踏み込めるかどうか
集計と可視化	数字を判断材料に変える可視化の経験	ダッシュボード設計の経験の有無
改善の運用を支える	利用者の声を継続的な改善につなげる運用経験	発注側の改善サイクルに伴走できるかどうか

3つの関わり方は、どれか1つを選ぶものではありません。組み込む経験から始めて、可視化、改善の運用へと積み上げていく経験のほうが、単価を協議する場面での説得力になります。

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

評価機能の実装も、ダッシュボードの設計も、画面越しのやり取りで進めやすい工程です。要件を確認し、実装し、動作を確かめるという流れは、場所を問わず組み立てられます。

Remoguでは、案件の90%以上がフルリモート可能です。場所に縛られずに設計や実装の経験を活かしたい人にとって、探しやすい環境が整っています。

要件のすり合わせや進捗の共有も、画面越しのやり取りで十分に進められる性質の仕事です。現地でなければ分からない情報が少ない領域だからこそ、リモートでの参画がしやすくなっています。

画面に組み込む経験しかない場合はどう進めればよいですか

組み込む経験は、この仕組みの入口として十分な土台になります。そこに集計・可視化の経験を1つずつ足していけば、関わる工程を後ろへ広げていけます。積み上げてきた実装経験を、可視化の学び直しに接続する進め方が現実的です。

政府・自治体系の案件はリモートで参画しにくいのではないですか

案件によって進め方は異なりますが、Remoguでは案件の90%以上がフルリモート可能です。政府・自治体系だからといって現地稼働が前提になるとは限らず、案件ごとの条件を確認しながら選べます。

まずどこから確かめればよいですか

測る仕組みまで担える経験があるかどうかは、実際の案件情報に触れてみないと見えてきません。まずはRemoguに登録して、これまで積み上げてきた経験がどの関わり方に近いのか、自分の目で確かめてみてください。

参画までにどんな準備をしておくとよいですか

評価機能とダッシュボードの両方に触れた経験がまだ少ない場合も、どちらか一方の経験を言葉にして整理しておくだけで、面談の材料になります。積み上げてきた実装経験を、今回のような案件の言葉に置き換えてから登録に進むと、話がかみ合いやすくなります。

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

出典・参考情報

＊1 デジタル庁「政府情報システムにおける利用者満足度評価の導入」取組の目的（2026年8月）
＊2 デジタル庁「政府情報システムにおける利用者満足度評価の導入」集める対象（2026年8月）
＊3 デジタル庁「政府情報システムにおける利用者満足度評価の導入」2つの部品（2026年8月）
＊4 デジタル庁「政府情報システムにおける利用者満足度評価の導入」根拠の日付（2026年8月）
＊5 デジタル庁「政府情報システムにおける利用者満足度評価の導入」もう一つの根拠（2026年8月）
＊6 デジタル庁「政府情報システムにおける利用者満足度評価の導入」調達への反映（2026年8月）
＊7 デジタル庁「政府情報システムにおける利用者満足度評価の導入」運用の狙い（2026年8月）
＊8 デジタル庁「政府情報システムにおける利用者満足度評価の導入」高い場合（2026年8月）
＊9 デジタル庁「政府情報システムにおける利用者満足度評価の導入」低い場合（2026年8月）
＊10 デジタル庁「政府情報システムにおける利用者満足度評価の導入」勉強会の対象（2026年8月）
＊11 デジタル庁「政府情報システムにおける利用者満足度評価の導入」実施日（2026年8月）
＊12 デジタル庁「政府情報システムにおける利用者満足度評価の導入」申込数（2026年8月）
＊13 デジタル庁「政府情報システムにおける利用者満足度評価の導入」参加者数（2026年8月）
＊14 デジタル庁「政府情報システムにおける利用者満足度評価の導入」内容の一部（2026年8月）
＊15 デジタル庁「政府情報システムにおける利用者満足度評価の導入」全体の狙い（2026年8月）