帳票の入力欄を作り、確認画面を整えてきた経験は、自治体の窓口という現場でも生きてきます。ただ、書かないワンストップ窓口という言葉を見ると、画面を作る仕事という理解で止まってしまうことがあります。デジタル庁が掲げているのは、住民の負担と職員の業務負担を同時に軽くする取り組みであり、画面設計より前に業務の組み替えが要ります。この記事では、案件として関わるときに何を見て、どう単価につなげるかを整理します。

1. 「書かない・待たない・回らない」とは何を指すのか

3つの状態が指している中身

窓口DXという言葉を聞くと、まず思い浮かぶのはオンライン申請の画面やタブレットでの受付入力かもしれません。ですが、デジタル庁が示している目指す姿は、機能の名前ではなく、もう少し具体的な3つの言葉で表されています。それが「書かない」「待たない」「回らない」であり、案件の内容を見るときもこの3つを起点に考えると全体像がつかみやすくなります¹。

この3つは単なる標語ではなく、実現する状態として明記されています¹。加えて、住民の負担軽減と職員の業務負担軽減の両方を満たすことが条件になっており、片方だけを整える設計では目指す姿の半分しか実現できません²。続けて、この両輪を案件の中でどう見ていくかを整理します。

保有情報とマイナンバーカードが前提になっている

「書かない」を成立させる土台にあるのが、自治体がすでに持っている保有情報と、マイナンバーカードなどのデジタルの力を最大限活用するという前提です³。過去の手続で提出済みの情報を、来庁のたびに書き直させない設計が、実装の中心に据えられることになります。

画面の入力項目を減らすことよりも、どの情報を庁内ですでに持っているかを洗い出す設計のほうが、実装の成否を分けます。ここは新規の帳票を一から作る仕事というより、既存のデータをどこまで参照できるかという経路を組み替える仕事に近く、業務システムを扱ってきた経験がそのまま生きてくる場面です。

この3つの状態を実装で支えるもの

「書かない」「待たない」「回らない」は、それぞれ単独の機能を足せば実現するものではありません。情報の連携、窓口の動線、複数窓口にまたがる手続の統合という、性質の異なる3つの実装が組み合わさって、初めて成立する状態であり、担当する範囲によって求められる視点も変わります。

このあと表1で、3つの状態と実装で必要になる要素の対応を整理します。図1でも同じ関係を、住民が抱える負担と結びつけて示していますので、自分のこれまでの経験がどこに重なるかを、あわせて確認してみましょう。

出典：デジタル庁「自治体窓口DX『書かないワンストップ窓口』」（2026年3月）を基に作成

状態	解消する負担	実装で必要になるもの
書かない	同じ項目を繰り返し書く負担8	保有情報とマイナンバーカードの活用3
待たない	窓口で待たされる負担8	受付から審査までの動線の組み替え
回らない	複数の窓口に回される負担8	手続をまたぐ情報連携と窓口の統合

2. 住民と職員の課題は別物｜両方が軽くならないと意味がない

住民が窓口で感じている3つの不満

住民側の視点に立つと、不満として挙がるのは「何度も同じ項目を書かされる」「都度、窓口で待たされる」「複数の窓口に回される」の3つです⁸。これらは別々の場面で起きる負担であり、原因も一様ではないため、対処の仕方もそれぞれ違ってくることになります。1つの不満だけを解消しても、住民の実感は大きくは変わりません。

同じ項目を繰り返し書かせるのは情報連携の設計の問題で、待たされるのは窓口の動線や順番の問題、複数窓口に回されるのは手続の分担そのものの問題です。原因が異なるからこそ、1つの機能を足しただけでは、3つの不満のうち1つしか解消しないことになります。設計の初期段階で、どの不満をどの機能で解くのかを切り分けておくことが要ります。

職員が受付で抱えている課題

一方で職員側には、住民とは別の課題があります。申請書ごとに記入方法を説明する場面があり、記入内容の確認作業も幅広く発生します⁹。住民の負担を軽くする設計だけを進めても、この受付側の負荷はそのまま残ってしまう点に注意が要ります。

説明や確認に時間を割かれる状態が続くと、職員数が減っていく中で窓口の品質を保つことじたいが難しくなります¹⁵。窓口業務の設計は、住民側の体験を良くする設計であると同時に、受付側の作業を軽くする設計でもあり、どちらか一方だけでは成立しません。

両方が軽くならないと案件として成立しない理由

デジタル庁が示す取り組みは、住民の負担軽減と職員の業務負担軽減の両立を条件にしています²。片方だけを整えた設計は、見た目が整っていても、目指す姿の半分しか満たしていないことになります。提案の段階でこの両立を意識できているかどうかは、担当者にもすぐに伝わる部分です。

案件として関わるときも、この二重の視点を持てるかどうかで評価が変わります。図2は、住民の負担と職員の課題の対応を左右に並べて整理したものです。次の章では、この順番を逆にしたときに何が起きるかを見ていきます。

出典：デジタル庁「自治体窓口DX『書かないワンストップ窓口』」（2026年3月）を基に作成

3. 順番を逆にすると起きること｜BPRを飛ばした導入の落とし穴

目指す姿を先に決めるという前提

デジタル庁が示す進め方では、まず「自分たちが目指す窓口の姿」を明確にすることが前提になっています⁶。画面や機能から考え始めるのではなく、ゴールを言葉にして関係者の間で共有することが、最初の工程として位置づけられています。

この前提を飛ばして進めると、何を作れば良いかの基準が現場ごとにばらつきます。設計の途中で仕様が何度も揺れる原因の多くは、実装より前に置かれるこの工程が、そもそも抜けていることにあり、後戻りの手間として跳ね返ってきます。

飛ばした場合に起きること

システムの導入だけでは不十分であり、バックヤードを含めた業務改革が必要だと明記されています⁴。画面だけを整えれば良いという発想では、この条件を満たすことができないという点が、案件を見極めるときの基準になります。

業務改革を伴わずに導入を進めると、かえって手続が複雑化し、バックヤード側の職員の業務が増加するリスクが指摘されています⁵。住民側の画面を整えるほど、裏側の職員の対応がむしろ増えるという逆転が起こり得ることになります。この逆転を避けられるかどうかは、業務フローを見る目を持っているかどうかにかかっています。

先にやった場合の効果

反対に、目指す姿を先に決めてから進めた場合は、窓口業務とバックヤード業務の双方が効率化に向かうという結果につながります⁷。画面と業務の両方を、同じ設計図の中で扱う進め方だといえ、後工程での手戻りも抑えられます。この進め方に関われた経験は、他の自治体案件でも応用が利きやすくなります。

案件に関わるときは、この前後関係を理解しているかどうかが提案の質を分けます。図3と表2で、先にやる場合と飛ばす場合の違いを整理しました。次の章では、実際に何を「書かせない」ためにどう作るかを見ていきます。

出典：デジタル庁「自治体窓口DX『書かないワンストップ窓口』」（2026年3月）を基に作成

進め方	手続の状態	職員の業務
目指す姿を先に決めてから導入6	窓口業務とバックヤード業務の双方が効率化に向かう7	業務改革と合わせて設計するため負担が積み上がりにくい
BPRを飛ばしてシステムだけ導入4	かえって手続が複雑化する5	バックヤードの職員側の業務が増加する5

4. 何を「書かせない」ためにどう作るのか｜保有情報とカードの使い方

保有情報を使って「書かせない」設計にする

「書かせない」を成立させる土台は、自治体がすでに持っている保有情報と、マイナンバーカードなどのデジタルの力を最大限活用するという考え方です³。過去の手続で提出済みの情報を、来庁のたびに書き直させない設計が要り、この視点が実装全体を貫きます。

実装では、どの手続にどの保有情報が使えるかを庁内で洗い出す工程が先に来ます。入力項目を削る工夫よりも、参照できるデータの範囲を広げる工夫のほうが、書かせない状態に直接効いてくるため、設計の優先順位もそこに合わせる必要があります。

オンライン申請との役割分担

書かないワンストップ窓口は、マイナポータルや自治体独自の電子申請システムによるオンライン化と並ぶ取り組みとして進められています¹³。来庁を前提にした窓口の設計と、来庁しない前提のオンライン化は、別の解として扱われている点に注意が要ります。

どちらか一方に寄せる設計ではなく、来庁する住民にも書かせない状態を用意する視点が要ります。ここは、オンライン申請の画面だけを作ってきた経験とは異なり、窓口という対面の場面に特有の設計判断が求められる場面だといえます。この視点を持てるかどうかが、オンライン系の案件との経験の違いになります。

実装の入口になっている公募

自治体窓口DXSaaSの令和8年度の公募結果も公表されており¹⁶、この領域の実装は個別の自治体ごとに進んでいます。案件を探すときは、このSaaS導入の枠組みが、実装に関わるための入口の1つになります。公募の動きを追っておくと、どの時期にどんな実装が動き出すかの見通しも立てやすくなります。

保有情報の参照設計、マイナンバーカード連携、オンライン申請との役割分担。この3つを行き来できる経験が、書かせない設計に関わるときの土台になり、提案の説得力にもつながる場面が増えていきます。この3つのどこか1つにでも心当たりがあれば、参画の入口として十分に語れます。

5. 進み具合は月次で見える｜ダッシュボードで追える指標

取組状況が公開されている

この取り組みの進み具合は、自治体窓口DX取組状況ダッシュボードとして公開されています¹⁰。個別の自治体に問い合わせなくても、全体の状況を確認できる状態が整えられている点は、案件を探すうえでも役立ちます。担当したい自治体の状況を、打診の前に自分で確かめられる点も利点です。

案件を探す立場からすると、この種の公開情報は、どの領域で実装が進んでいるかを把握する材料になります。案件情報だけでは見えない、取り組み全体の広がりを知るための手がかりとして使うことができます。定期的に眺めておくと、次にどの自治体で動きがありそうかの予測材料にもなります。

更新頻度と載っている中身

ダッシュボードのデータは月次で更新されます¹¹。年に一度の棚卸しではなく、毎月動きを追える頻度で整備されている点が、この取り組みの特徴のひとつになっています。この頻度であれば、案件の動きを見落とさずに追いかけることができます。

載っている内容には、窓口DXSaaSの導入状況などが含まれます¹²。どの自治体でどのSaaSが動いているかという、実装の広がりそのものを示す指標として使うことができます。導入が進んでいる自治体ほど、次の実装フェーズに関わる余地も広がっていきます。

密な連携のもとで進んでいる

この取り組みは、デジタル庁が地方自治体と密に連携しながら進めているものです¹⁴。中央だけで完結する仕組みではなく、現場とのやり取りを重ねながら、整備が続けられています。現場の事情を踏まえて進める姿勢は、案件を担当するうえでも求められます。

月次の更新を追っておくと、自分の経験が生きそうな自治体や領域の広がりを、案件の打診が来る前から把握できます。図4で、指標と更新の頻度を整理しましたので、あわせて確認してみましょう。

出典：デジタル庁「自治体窓口DX『書かないワンストップ窓口』」（2026年3月）を基に作成

6. 単価につながるスキルの整理｜両側を軽くできるかで変わります

職員数が減る中での効率化という背景

自治体では職員数が減少していく中で、窓口サービスの品質を維持していくことが課題になっています¹⁵。人手を増やさずに品質を保つには、業務そのものを軽くする設計が欠かせず、この視点が単価にも直結します。この課題を理解したうえで提案できるかどうかが、条件を協議する場面でも効いてきます。

画面の使いやすさだけを整える仕事より、業務の負担そのものを減らす設計に関われる経験のほうが、この背景のもとでは評価されやすくなります。上流の設計判断に踏み込めるかどうかが、そのまま差になっていきます。

双方を軽くできるかが分かれ目になる

評価が変わる分かれ目は、住民側の画面だけを見て設計してきたか、窓口業務とバックヤード業務の双方が効率化に向かう設計に関わってきたかです⁷。関わってきた範囲の広さが、そのまま提案の説得力に直結します。

受付の画面を作ってきた経験は入口として生き、バックヤードの業務フローや庁内データ連携まで踏み込んだ経験は、より上流の設計判断が求められる場面で生きてきます。どちらも無駄になる経験ではなく、組み合わせて語れることが強みになります。

経験を単価の材料に言い換える

「画面を作りました」で止まる実績は、単価を協議する材料としては弱くなります。「業務フローを整理し、双方の負担が軽くなる形に組み替えました」まで言い換えられると、報酬の協議で使える材料になります。実績を言葉にし直す作業そのものが、次の案件の提案書にもそのまま使えます。

表3では、関わり方ごとにどの経験が生き、単価の考え方がどう変わるかを整理しています。受付の画面からバックヤードの業務、データの持ち回りまで、自分の経験がどこに当てはまるかを確かめてみましょう。

関わり方	生きる経験	単価の考え方
受付の画面	入力項目の設計、確認画面のUI経験	画面単体の実装は単価の基準になりにくい領域です
バックヤードの業務	業務フローの整理、既存システムとの連携経験	双方の負担が同時に軽くなる設計に関わるほど評価されやすい領域です
データの持ち回り	庁内データ連携、保有情報の参照設計の経験	「書かない」を支える基盤設計として評価されやすい領域です

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

窓口BPRや保有情報の設計は、庁内の会議やヒアリングが伴う場面もありますが、業務フローの整理や連携設計そのものは、画面越しのやり取りで進めやすい領域です。Remoguでは、案件の90%以上がフルリモート可能です。

場所に縛られず、これまで積み上げてきた設計の経験を自治体領域でも活かしたいと感じているなら、まず自分の経験に近い案件があるかを確かめてみることが、次に取れる具体的な一歩になります。

自治体の窓口BPRの経験がなくても参画できますか

窓口BPRという名称の経験そのものよりも、業務フローの整理や、システム導入前の要件整理に関わった経験が重なっているかどうかが見られる場面が多くなります。業務システムの受付画面や帳票を作ってきた経験は、参画の入口として十分に生きてきます。

経験がまだ少ない領域であっても、双方の負担を軽くするという視点を持って提案できるかどうかが、参画後の評価につながります。エントリー前に、自分のどの経験がこの視点に結びつくかを整理しておくと、条件を協議しやすくなります。

リモートでの参画は可能ですか

窓口BPRやデータ連携の設計といった業務は、庁内の関係者とのやり取りをオンラインで重ねながら進めやすい領域です。画面や帳票の設計に近い工程ほど、場所を選ばずに進めやすくなる傾向があります。会議の頻度や進め方は案件によって異なるため、事前に条件を確認しておくと安心です。

ただし、条件は案件によって異なります。まずはRemoguに登録して、自分のこれまでの経験に合う条件を確かめてみることが、行動に移しやすい一歩になります。

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

出典・参考情報

＊1 デジタル庁「自治体窓口DX「書かないワンストップ窓口」」目指す姿（2026年3月）
＊2 デジタル庁「自治体窓口DX「書かないワンストップ窓口」」両立の目標（2026年3月）
＊3 デジタル庁「自治体窓口DX「書かないワンストップ窓口」」実現の手段（2026年3月）
＊4 デジタル庁「自治体窓口DX「書かないワンストップ窓口」」順番の話（2026年3月）
＊5 デジタル庁「自治体窓口DX「書かないワンストップ窓口」」逆効果の条件（2026年3月）
＊6 デジタル庁「自治体窓口DX「書かないワンストップ窓口」」先に決める事（2026年3月）
＊7 デジタル庁「自治体窓口DX「書かないワンストップ窓口」」進め方の条件（2026年3月）
＊8 デジタル庁「自治体窓口DX「書かないワンストップ窓口」」住民の課題（2026年3月）
＊9 デジタル庁「自治体窓口DX「書かないワンストップ窓口」」職員の課題（2026年3月）
＊10 デジタル庁「自治体窓口DX「書かないワンストップ窓口」」見える化（2026年3月）
＊11 デジタル庁「自治体窓口DX「書かないワンストップ窓口」」更新の頻度（2026年3月）
＊12 デジタル庁「自治体窓口DX「書かないワンストップ窓口」」載る情報（2026年3月）
＊13 デジタル庁「自治体窓口DX「書かないワンストップ窓口」」位置づけ（2026年3月）
＊14 デジタル庁「自治体窓口DX「書かないワンストップ窓口」」進め方（2026年3月）
＊15 デジタル庁「自治体窓口DX「書かないワンストップ窓口」」背景の要請（2026年3月）
＊16 デジタル庁「自治体窓口DX「書かないワンストップ窓口」」SaaSの公募（2026年3月）