行政の手続きは、紙と窓口が前提だった時代から、オンラインで完結する仕組みへと動いています。担当するエンジニアの目線に立てば、この変化はUIの改善だけでなく、住民や事業者のデータをどう安全に連携させるかという設計の勝負です。国の重点計画では、テクノロジーの活用による行政手続のデジタル完結の推進が掲げられており、案件として関わる機会も広がりつつあります。この記事では、デジタル完結の考え方から、リモートワークでどう関わっていけるかまで整理します。

1. なぜいま行政手続デジタル完結の案件が増えているのか

重点計画に掲げられたデジタル完結の推進

行政手続のオンライン化は、思いつきで進んでいるわけではありません。デジタル社会の実現に向けた重点計画では、テクノロジーの活用による行政手続のデジタル完結の推進が掲げられています¹。窓口で紙を書いていた手続きを、オンラインで完結できる形に置き換えていく方針が、国の計画として明文化されている点が起点になります。

この動きは単発の施策ではなく、デジタル行財政改革の推進の一環として進められています⁶。制度と実装を合わせて見直す取組みなので、システムを一度作って終わりにはなりません。運用しながら手続きの流れそのものを整えていく、継続的な仕事です。

継続的な取組みであることは、案件の在り方にも表れます。一度の開発で完成するのではなく、運用しながら見つかった不便さを都度直していく進め方が中心になり、短期の実装だけでなく、中長期で伴走する関わり方も選択肢に入ってきます。積み上げてきた経験を、腰を据えて生かしたい方にも合う領域です。

案件として求められる開発の中身

計画に描かれるのは方針ですが、実装するのはソフトウェアです。申請フォームの構築よりも、既存のシステムとどうデータを連携させるかという設計判断のほうが、エンジニアの経験が差になる領域です。制度の背景を理解したうえで手を動かせる人材が、案件の中で頼られていきます。

対象となる業務は、住民票や各種証明の発行だけでなく、事業者向けの許認可や届出にも及びます。窓口ごとに異なる書式や確認の仕方を、システムの側でどう吸収するかという課題は、業種を問わず共通しています。一つの手続きを担当するだけでも、関連する複数の制度を把握する必要があり、要件整理の丁寧さがそのまま設計の質につながります。

対象となる自治体や省庁の数だけ、既存システムの作られた経緯も異なります。古くから運用されてきた仕組みを壊さずに、新しい連携の仕組みを足していく進め方が中心になり、一から作り直せる案件のほうがむしろ少数派です。積み上げてきた経験のなかでも、既存の資産を生かす設計力が生きる場面です。

出典：デジタル社会の実現に向けた重点計画（デジタル庁、2025年6月）をもとに作成

次に、デジタル完結を支える考え方の中心にある、ワンスオンリーという原則を見ていきます。

2. デジタル完結とワンスオンリー

情報の提出は一度限りという考え方

デジタル完結の要点の一つが、ワンスオンリーです。情報の提出は一度限りとする考え方で²、同じ書類や番号を手続きのたびに何度も出す状態を解消していく方向性を示しています。窓口ごとに同じ内容を書き直す負担を、システム側の工夫で減らしていく発想です。

利用者から見れば、一度伝えた情報を何度も聞かれない体験そのものが価値になります。裏側では、複数の手続きシステムが同じ情報を安全に参照し合う仕組みが必要で、単純な一元化とは違う難しさがあります。見た目の分かりやすさよりも、裏側の整合性を保つ設計のほうが、成否を分ける部分です。

エンジニアが設計で意識する境界線

ワンスオンリーを実現できるかどうかは、画面の工夫よりも、後ろのデータ設計で決まります。入力欄を減らすことよりも、すでに登録済みの情報をどこから引けるかを先に決めることのほうが、設計の出発点になります。どこまでを一度の入力で済ませるかという線引きが、案件ごとの腕の見せどころです。

実装の段階では、既存の手続きシステムがどのような形式でデータを保持しているかを、まず読み解く作業から始まります。項目名や単位がそろっていない場合も珍しくなく、変換のルールを一つずつ積み上げる地道な工程になります。派手さはありませんが、ここを丁寧に進めた案件ほど、後の運用が安定します。

デジタル完結を支える機能ごとの役割分担

デジタル完結は一つの機能で成り立つものではなく、受付・情報の再利用・進捗確認・通知という複数の機能が組み合わさって初めて成立します。それぞれの機能をどのシステムが担い、エンジニアとして何を確認しておく必要があるかを、下の表に整理しました。案件によっては、これらの機能をすべて一括で担当することもあれば、いずれか一つの機能だけを任されることもあります。案件に参画する際、自分がどの部分を担当するのかを見極める材料にしてください。

要素	担うシステム・機能	エンジニアが確認する点
申請受付	オンライン申請フォーム、電子署名との連携	入力データの検証と、既存情報との突合の方法
情報の再利用	公的基礎情報データベースの参照	参照権限の範囲と、キー設計の整合
進捗確認	マイナポータルとの状況連携	状態遷移が反映されるタイミング
通知	手続き完了・不備の通知の仕組み	通知の重複や欠落を防ぐ設計

出典：デジタル社会の実現に向けた重点計画（デジタル庁、2025年6月）をもとに作成

ワンスオンリーという言葉自体はシンプルですが、実現までの道のりは一段階では終わりません。関わる案件のなかには、まず特定の手続きに限って一度提出の仕組みを試し、範囲を広げていく段階を踏むものもあります。全体を俯瞰しながら、今どの段階の作業を担当しているのかを意識できると、設計の判断にも一貫性が生まれます。この考え方を支えるのが、次に扱うデータ連携の基盤です。

3. データ連携で再入力をなくす

公的基礎情報データベースを参照する仕組み

ワンスオンリーを支える共通基盤として、公的基礎情報データベース、いわゆるベース・レジストリの整備が進められています³。氏名や住所といった基礎情報を一元的な参照先として持ち、それぞれの手続きシステムがそこを見に行く構成です。

個々の手続きシステムが、それぞれ独自に住所や氏名の情報を持っていた状態から、共通の参照先を通じて情報を確認する形へ移っていく、大きな構造の見直しといえます。データベースそのものを一から作るというより、既存のシステムを、参照する側の作法に合わせて組み替えていく仕事が中心になります。

キー設計と名寄せという地味で重い仕事

この仕組みを支えるのは、華やかな画面ではなく、地味なキー設計です。表記のゆれや旧字体を含む名寄せ、参照タイミングのずれをどう吸収するかが、実装の負荷が集中する部分になります。開発量の多さよりも、突合の精度を積み上げる作業のほうが、時間を要する現場です。

複数のシステムが同じ基礎情報を参照する構成では、参照先が一つ止まるだけで、連鎖して手続き全体が止まってしまう可能性もあります。障害時にどこまで処理を進めておくか、再試行の仕組みをどう設けるかといった、落ち着いた設計判断が求められます。表面には出ない部分ですが、利用者の信頼を左右する土台になります。

こうした基盤づくりは、一人で完結する仕事ではなく、既存システムを保守してきた担当者や、基礎情報側の運用チームと、認識をすり合わせながら進める性質の仕事です。技術力に加えて、関係者の間で仕様の理解をそろえていく調整力も、評価される場面が多くなります。

データ連携を設計するときに確認したい観点

公的基礎情報データベースを参照する設計は、つないで終わりではありません。どの範囲まで参照してよいか、更新はどのタイミングで反映されるか、登録がない場合はどう扱うか、そして何をログに残すかまで決めておく必要があります。どの観点も、後から手直しするより、最初の設計段階で決めておいたほうが、手戻りが少なくて済みます。実装を始める前に押さえておきたい観点を、下の表にまとめました。

観点	確認すること	見落とすと起きること
参照範囲	どの基礎情報をどの手続きが参照できるか	権限を超えた参照によるデータの取り扱いミス
更新タイミング	基礎情報が更新された際の反映速度	古い情報のまま手続きが進んでしまう不整合
例外処理	基礎情報に登録がない場合の代替経路	手続きがそこで止まってしまう詰まり
ログと追跡	参照や更新の履歴をどこまで残すか	不具合発生時に原因を追えない状態

出典：デジタル社会の実現に向けた重点計画（デジタル庁、2025年6月）をもとに作成

整った基盤の上に立つのが、利用者が実際に触れるマイナポータルという接点です。

4. マイナポータルとの連携と利用者接点

利便性向上という方針と、対象手続きの広がり

利用者視点の取組みとして、マイナポータルの利便性向上が掲げられています⁴。手続きの入り口を一本化し、進捗を確認できる窓口として役割を広げていく方向性です。

個々の行政手続きシステムからすれば、マイナポータルとの連携は、利用者を迎え入れる玄関口を任される役割にあたります。玄関口の使い勝手が悪いと、その先にある手続き自体の評価まで下がってしまうため、見た目以上に責任の重い接続です。

あわせて、オンライン化を実施する行政手続の一覧等が、重点計画の一部として整理されています⁵。対象となる手続きは固定されたものではなく、状況に応じて順次見直されていく性質のものです。

この一覧を踏まえてシステム側を作るときは、一度に全体を組み替えようとせず、優先度の高い手続きから段階的にオンライン化していく進め方が現実的です。関わる案件も、こうした段階のどこかを切り出した形で公開されることがあり、全体像を把握しておくと、自分の担当箇所の位置づけが見えやすくなります。

接点の設計で問われる感度

利用者接点の実装では、画面の見やすさよりも、途中でつまずかない導線のほうが評価されます。手続きの意味を理解していないと、エラーメッセージ一つとっても、利用者に伝わる言葉になりません。行政の言葉と、生活者の言葉を橋渡しできる感度が、この領域では問われます。

入力途中で通信が途切れた場合や、必要な書類がそろっていない場合に、どこまで進んだ状態を保存しておくかも、設計で詰めておきたい点です。手続きを最後までやり遂げてもらうためには、途中でつまずいた利用者を、迷わせずに導線へ戻す工夫が欠かせません。マイナポータルという共通の窓口があるからこそ、個々のシステム側の作り込みが問われる場面でもあります。

こうした接点まわりの設計は、フロントエンドの実装経験だけでなく、行政手続き特有の流れを踏まえたバックエンドとの調整力があってこそ、精度が上がっていきます。これまで培ってきたUI・UXの経験を、公共性の高い場面で生かしてみたい方にも合う領域です。

出典：デジタル社会の実現に向けた重点計画（デジタル庁、2025年6月）をもとに作成

ここまでの仕組みを踏まえて、実際の案件でエンジニアがどう関わっていくかを見ていきます。

5. リモート・フリーランス案件でどう関わるか

申請システムとデータ連携、それぞれの入り口

行政手続デジタル完結の案件には、大きく分けて申請システムの実装と、データ連携の設計というふたつの入り口があります。前者はフォームや電子署名まわりの実装経験、後者は既存システムとの接続やキー設計の経験が生きる領域です。どちらか一方の経験しかなくても、関われる場面はあります。

案件を見極める際は、案件の詳細に書かれた技術要素だけでなく、どの段階のシステムを担当するのかを確認しておくと、参画後のずれが小さくなります。すでに稼働している仕組みへ機能を足す案件と、新しく連携の基盤を組む案件では、求められる進め方が異なるためです。クライアントとの協議の中で、担当範囲を早めにすり合わせておくことも大切です。

条件をすり合わせるためには、まず自分に合いそうな案件がどれくらいあるのかを、実際の一覧で確かめてみることが近道です。抽象的に想像するよりも、具体的な案件の情報に触れたほうが、必要な経験の輪郭がはっきりします。

リモートで進めやすい領域の見極め方

「行政系の案件は要件が堅く、フリーランスでは参画しにくいのでは」と感じる場面があります。実際には、要件を整理して伝える力と、データ連携を丁寧に設計する経験があれば、参画の余地は十分にあります。制度の名称に構える必要はなく、求められているのは設計と実装の基礎体力です。

設計やデータ連携の実装は、対面での確認がそのつど必要になる作業に比べ、リモートで進めやすい性質を持っています。Remoguが扱う案件の90%以上がフルリモート可能です⁷。場所に縛られずに、こうした案件に関わる選択肢が広がっています。

場所を選ばずに関われることは、住んでいる地域にかかわらず、これまで培ってきたスキルをそのまま活かせるということでもあります。裁量を持って設計を任される働き方に魅力を感じているなら、まずは自分の経験がどの入り口に合うのかを、実際の案件を見ながら確かめてみるのがおすすめです。

経験に応じた関わり方の段階

案件への関わり方は一様ではなく、これまでの経験によって担う範囲が変わります。実装から入る段階もあれば、データ連携の設計を主導する段階、複数のシステムをまたぐ全体設計を担う段階もあります。どの段階から始めても、経験を積むにつれて担う範囲を広げていくことができます。自分の経験がどの段階に近いかを確かめる目安として、下の表を参考にしてください。

段階	主な関わり方	求められる経験
実装フェーズ	申請フォームやAPIの実装を担当	指定された仕様に沿って実装する力
設計フェーズ	データ連携やキー設計を主導	既存システムとの接続を設計した経験
全体設計フェーズ	複数システムをまたぐ連携の設計	行政手続の背景を理解した提案力

ここまで整理してきた流れを、最後に振り返ります。

6. まとめ

行政手続のデジタル完結は、重点計画という国の方針を出発点に、ワンスオンリーとデータ連携、そして利用者接点という三つの層で進んでいます。エンジニアの視点で見れば、それぞれの層に、これまで積み上げてきた経験を生かせる入り口があります。申請の画面づくりよりも、データをどうつなぐかの設計判断のほうが、案件の中で頼られる場面が多くなります。

行政系という言葉の響きに構える必要はなく、求められているのは、既存の仕組みを丁寧に読み解き、安全にデータをつなぐという、これまでと地続きの力です。制度の背景を理解しながら手を動かせる経験は、こうした案件のなかで着実に評価されていきます。

場所に縛られず、裁量を持って設計に関わりたいという理想と、こうした案件が持つ地に足のついた性質は、思っている以上に相性が良いものです。抽象的な不安を抱えたままにせず、実際の案件情報に触れてみることで、自分に合う関わり方が見えてきます。

まずは自分の経験がどの段階に近いかを確かめてみましょう。案件を眺めるだけでなく、Remoguに登録して、条件を実際に確認してみることが、次の一歩になります。

7. よくある質問

ワンスオンリーとは何ですか

情報の提出は一度限りとする考え方です²。同じ書類や番号を、手続きのたびに何度も提出しなくて済むようにする方向性を指しています。設計する側から見れば、どの情報をどこまで使い回してよいかという線引きを、システムの中に落とし込む作業でもあります。

どんなシステムを作ることになりますか

申請を受け付ける画面まわりの実装と、公的基礎情報データベースを参照するデータ連携の設計が中心になります³。どちらか一方だけでなく、両方の経験があると関われる範囲が広がります。案件によって比重は異なるため、参画前に担当範囲を確かめておくと安心です。

マイナポータルとの連携は難しいですか

連携の仕組み自体は手順が定まっていますが、利用者に分かりやすく伝える設計のほうが工夫を要します⁴。技術面の難易度よりも、伝わる導線を作る経験が問われる領域です。仕様書を読み解く力に加え、行政特有の言い回しを、生活者の言葉に置き換える視点があると強みになります。

個人情報の扱いは大丈夫ですか

基礎情報や申請内容を扱うため、参照できる範囲や記録の残し方には配慮が必要です。案件ごとに取り扱いのルールが定められているため、参画時に確認しながら進める形になります。疑似データを使った検証環境が用意されている案件もあり、実データに触れる前に手順を確かめられる場合もあります。

この分野の案件はフルリモートでも進められますか

設計やデータ連携の実装は、リモートで進めやすい領域です。Remoguで扱う案件の傾向を確認しながら、これまで培ってきた経験に合う関わり方を探ってみましょう。まずは登録して、自分の経験に近い条件がどれくらいあるかを、実際に見てみることから始められます。

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

出典・参考情報

＊1 デジタル庁「デジタル社会の実現に向けた重点計画」（2025年6月）
＊2 デジタル庁「デジタル社会の実現に向けた重点計画」（2025年6月）
＊3 デジタル庁「デジタル社会の実現に向けた重点計画」（2025年6月）
＊4 デジタル庁「デジタル社会の実現に向けた重点計画」（2025年6月）
＊5 デジタル庁「デジタル社会の実現に向けた重点計画」（2025年6月）
＊6 デジタル庁「デジタル社会の実現に向けた重点計画」（2025年6月）
＊7 Remogu（株式会社LASSIC運営）公開情報：扱う案件の90%以上がフルリモート可能