見出し画像

行政手続のオンライン化に2年間携わってみて

こんにちは。経済産業省大臣官房デジタル・トランスフォーメーション室の髙柳徹と申します。
私は他の記事を書いているデジタル化推進マネージャーのようにIT系のバックグラウンドがない一般的な行政職員ですが、当室で2年間行政手続のオンライン化に携わった中で、行政官ならではの気づきをお伝えできればと思います。
このため、本記事は”行政職員向け”の簡単な内容になっており、IT系の方にとっては、「行政官の頭の中」を知る機会だと思って温かく見守ってくださると幸いです。
なお、本記事は個人の所感を含んでおり、所属組織の公式見解ではございませんのでご理解ください。

当室では、gBizFORM(Gビズフォーム)と呼んでいるMicrosoft Power Platformを活用した行政手続アプリケーションの開発環境を整備し、ローコード開発という特徴を生かし、簡易かつ柔軟に経済産業省が所管する中小規模の簡易な手続のオンライン化を進めています。

このプロダクトに携わる中で、これまで書面で運用していた手続をオンライン化する場合、担当職員は書面からデジタルに考え方をシフトしないとプロジェクトが上手くいかないことに気が付きました。
ローコードとはいえ、システム開発の考え方に通ずるものがあると思い、紹介させていただきます。

なお、行政がオンライン化を進める背景については、こちらの記事で触れていますので、併せてご覧いただけると幸いです。

オンライン化はテーブル中心で考える

まず、行政官が申請書と聞くと、一般的に図1左側のような書面の「様式」をイメージすると思います。
この「様式」を具体的に作成する場合はワープロソフトで宛先欄を作成し、申請者欄を作成し、申請内容欄を作成し・・・と上から順に作り込んでいき、最後に申請様式と併せて提出が必要となる添付書類が何かを定義するのが一般的かと思います。

このような「様式」は、デジタル化が進んだ現代でも申請者に紙で提出を求めていた時代の固定概念とともに、行政機関の中に根強く生き残っています。
( 余談ですが、行政官はごく稀に俗に言う「神Excel」を作ってしまう人が存在する職種なので、「様式」の余白○ミリや全角半角など見た目の細部に少々こだわりを持ったりします )

図1 様式とテーブルの比較(イメージ)

手続をオンライン化する際は、始めにこの「様式」を分解して申請項目(データ)を格納する箱となる「テーブル」を設計します(図1右側のイメージです)。
この時、データ形式がテキストなのか数値なのか、選択肢なのかを一つ一つ定義していきます。

また、「テーブル」を作成した後に、申請フォーム画面や審査画面を作り、プロセスを動かす自動処理フローを作り、データ出力のテンプレートを作り、ダッシュボードを作り・・・と「テーブル」起点にして各機能を開発します(図2のイメージです)。
このため、行政手続のオンライン化は「テーブル中心」に手続を再設計するものだと思います。

図2 テーブル中心設計(イメージ)

手続全体を俯瞰して設計する

手続をオンライン化した場合、申請者が入力した情報は先ほどの「テーブル」にデータとして格納されます。
当然、「テーブル」で決まっているデータ形式でしか申請者は入力できず、保存データも形式に従うものになるため、「テーブル」の設計がUI/UX等にも影響を与えます

図3 テーブル設計による影響(イメージ)

例えば図3のとおり、「パターンA」と「パターンB」は結果的には申請フォームで同様の質問しており、得られる情報も結果的には同じです。
ただ、異なるテーブル設計をしているため、申請フォームや申請情報一覧に蓄積するデータに以下のような違いが生じます

  • 「パターンA」の場合は、申請フォームが煩雑になりますが、データを集計する際に手間が少ないです。

  • 「パターンB」の場合は、申請フォームに無駄がなく申請者のUI/UXが高いですが、一つのフィールドに複数の値が入るため、データ集計のためには一度加工する手間があります。

この場合、どちらが正解ではなく、重要なのは「UI/UXを重視」するのか「データ集計を重視」するのか意図を持って選択し、適切な設計をすることだと思います。

非常に簡単な例ですが、「テーブル」の設計が他の機能に影響を与えることを考慮すれば、オンライン化の担当者はデータの入力から保存、活用までの一連のライフサイクル全体を意識して設計する必要があると言えます。
逆に「テーブル」の設計をあいまいなまま開発を進めると手戻りが発生し、非効率となります。

図4 オンライン化の担当者

なお、データ形式に関しては、デジタル庁がデータの利活用や連携をスムースに行う目的で政府相互運用性フレームワーク(Government Interoperability Framework)を公開しているので、こちらも参考にすると良いです。


紙じゃないオンライン化のポイント

ここまで、オンライン化する際の“ものすごくざっくりとした設計”の話をしてきました。
ここからは、手続をオンライン化する上で、書面の「様式」と比較してポイントになる具体例をいくつかお示しします。

  • ポイント1 自動入力
    書面の場合、大半は「様式」の右上に申請日を記載する箇所があり、オンライン化する際も申請日欄をそのまま作りがちですが、システムの場合は、申請者があえて日付を入力しなくとも申請日を自動的に取得して初期値とすることが可能です。
    同様の例で、ID情報から申請者に関する情報(法人名、所在地、代表者氏名 等)を自動入力することも場合によって可能です。
    したがって、申請フォームを作る際は他から所得できる値がないかを探して、入力を簡素化できるように設計すると、利便性の高いサービスになると思います。

図5 自動入力(イメージ)
  • ポイント2 選択入力
    書面の場合、特に自由記述欄では「選択肢から選ぶ」という概念が少ないかもしれませんが、システムの場合は、入力を選択式にすることで、申請者の利便性やデータ集計に寄与する場合があります。
    例えば「地方公共団体名」という入力項目があったとします。
    自由記載とした場合に、(正解・不正解はあるものの)同じ「A町」であってもそのまま「A町」と記載したり、「〇県A町」と記載したり、「○県✕群A町」と記載したりと同じ団体を指していても申請者によって入力にばらつきが生じる可能性があります。
    後々、データ集計することを考えれば、可能な限り選択式にして表記ゆれが生じないようする方法が望ましいです。
    ただ、地方公共団体の例で言えば、約1,700団体存在することを考えると、選択式にすることでかえってUI/UXが低下するリスクもありますので、やはり「目的をもって」設計することが重要になると思います。

図6 選択入力(イメージ)
  • ポイント3 入力の簡素化
    書面の書類を”そのまま”オンライン化すると不要な部分まで申請フォームにしてしまう場合が考えられます。
    例えば、申請書と併せて「誓約書」を提出する必要があった場合、そのままオンライン化するのではなくチェックボックス等に代替することで結果的に同じ情報を取得でき、「誓約書」自体は省略することができると思います。
    ただし、添付書類を省略・代替する場合は、法令やその他の定めによって省略ができない場合もあり得ますので、根拠法令等をよく確認する必要があるのが注意点です。

図7 入力の簡素化(イメージ)

おわりに(オンライン化の意義 など)

以上、行政手続をオンライン化する際に気を付ることを書いてきましたが、最後にオンライン化の意義について持論を述べたいと思います。
オンライン化することで、行政手続が24時間365日どこでも可能になったり、入力不備を機械的にチェックすることで効率化に繋がったりますが、”それ以上に”重要だと思っている点は、これまで紙(もしくはPDF)では難しかった構造化されたデータを取得できる点だと思います。
これによって、行政機関は紙で運用していた頃と比較してデータの分析・可視化が容易になり、自分達の政策へのフィードバックが期待できます。

と言いつつも現状のgBizFORMでも、まずはオンライン化することに注力しており、今後は取得データの活用するか、またはオープンデータ化に関するを検討をしていくフェーズに移行していくのだと思います。
gBizFORMチームでは、引き続き、国民・事業者にとって便利な行政サービスの提供ができるような取り組みを進めてまいります。

最後まで御覧いただきありがとうございました。

みんなにも読んでほしいですか?

オススメした記事はフォロワーのタイムラインに表示されます!