制度を作るときは運用も一緒に考えよう

新しい制度等を創設する際、多くの行政組織は権利関係やステークホルダーの利益衡量については丁寧に考えますが、実際にその申請がどのように運用されるかが関係者でイメージされていないため、いざ制度開始となった際にユーザーである申請者や、申請の対応を行う行政官に大きな負担が生じ、制度の円滑な実施を妨げるといったことが多く起きています。

これは制度の問題だけではなく、運用のデザインの問題です。こうした障害を回避する上でどのようなことを行うべきか、整理してみたいと思います。

関係する行政組織、部署が複数にまたがる場合には、一緒に届け方を考える

例えば、A課が審査を行い、B課が承認を行うといった役割分担が申請においてなされる場合には、両者が同じテーブルについて届け方を考えることが重要です。これがなされない場合に起きる問題としては、

・A課とB課でチェックする情報が異なる場合に、それぞれが様式を作成し、重複するデータ項目を何度も申請者に記入させることにより、申請者の負担を増大させる。

・A課とB課で申請様式のデータ等の理解がズレることによって、A課とB課の担当者間で不要なやり取りが繰り返され、制度の運用が煩雑になり負担が増大する。結果、申請者対する評価結果を伝えるまでの時間がより長くなる。

つまり、申請全体として必要な申請情報やプロセスが統合的にデザインされていないと実務担当者、申請者双方の負担が大きくなることになります。
これが申請件数の少ない手続であればなんとか回るかもしれませんが、数百、数千、数万といったオーダーが大きくなると、その影響は致命的になってきます。

多くの公務員が長時間残業しなければいけなくなる、かつ、市民は制度が使いづらいと不満を漏らすといった状況は上記のような事情による部分が多分にあるものと思われます。

こうした状況を避けるためには、制度を定める際に関係する行政組織、部署の人が集まり、みんなでプロセスを詰めると共に、必要なデータの洗い出しを行うことで、最も効率的な情報設計、プロセス設計を行うことが必須になります。最初のサービス設計を丁寧に行うことが結果としてその後の多くの無駄な作業を減少させるのです。その際、関係する部署のローカルな要求はなるべく排除すべきです。その結果として全体の効率性を阻害することが高いからです。関係部署が多数に上る場合には、優先順位をつけて対応していくことが必要になります。

デジタル化による恩恵についてもこれができて初めて最大化されることになります。情報設計、プロセス設計が最適化されていない制度はいくらデジタル化しても関係者全てに負担が増えるだけになります。デジタル化したけど一向に楽にならない、ユーザーの不満が止まらないといった状況が生じるのは情報設計、プロセス設計が十分行われていないためです。

プロセスに関与する行政機関、部署がどこで関与するかを明確にし、どういった情報を受け渡しするのか整理することがその助けになります。

システム化を前提とした情報・プロセス設計を行う

情報設計、プロセス設計を関係者が共通の理解の下に行うことが重要でありますが、特に申請件数が3桁を超えてくると効率的な情報・プロセスをデジタル前提で整理することが重要です。

デジタル前提で効率化できるポイントは以下の点であると考えられます。

・申請情報の受け渡しについて対面、郵送でかかる時間を大幅にショートカットできる。（数日〜数時間　→　数分に短縮）

・申請情報の誤りをユーザーの入力段階で排除できる。（バリデーション等のチェック機能を活用することで、紙であれば生じていた差戻しを不要化）

・既に行政側で所有しているデータがあれば情報連携で再利用できる。（行政保有データを利用することでそのデータ項目の確認を不要化）

これらはデジタル化によって実現できる機能の一部ですが、こうしたデジタルを前提としたプロセス最適化を前提とすると、本来必要だと思っていた部署の関与が実は必要なかったり、かかる人員を減らすことにもつながります。

データで制度が届いているかを確認する

加えて、制度策定段階でデータ項目が整備されていれば、制度が上手く届いているかをどのデータをチェックして管理すれば良いかもわかります。制度を作る段階からどのデータの変化がユーザーの満足度や、運用のキャパシティに影響を与えるかを考える必要があります。例えばデジタルサービスを運用する場合、以下のようなデータをウォッチすることが有効です。

・日単位のユーザーアクセス数（サービス対象の範囲やサービスの重要性に応じて時間単位、週単位などウォッチする期間も適切な間隔を検討。）

・ユーザーの離脱率（申請完了に至らないユーザーの比率。プロセスのどの部分で離脱しているかわかれば対策が考えられるため、なお良い。）

・申請対象者の属性情報（事業者向けのサービスであれば、大企業が多いのか、中小企業・個人事業主が多いのかなどによって、ユーザーサポートをどれぐらい準備しなければならないか考えられる。）

・問合せ件数及び応答率（問合せ件数が多い、応答率が低い場合には、ユーザーの不満が高まっている可能性が高い。）

上記のデータも一例ではありますが、こうしたデータはベンダーにシステム開発・運用を委託する場合であってもなるべく発注者である行政側が見られる環境を整備してもらう必要があると思います。逆にこういったデータがすぐに確認できないベンダーは、ユーザーのことを考えたサービス運用を行なっているのか疑わしいとも言えるのではないでしょうか。内製の場合には、こうした運用上ベンチマークすべきデータを設定してダッシュボード化することも大切になります。

ここまで行政を中心に議論してきましたが、制度という言葉をサービスと置き換えると、民間企業がオンラインサービスを開発する際にも考えるべきポイントと一致するのではないでしょうか。

届け方を考えずに制度を運用し始めると、本当は市民にとってメリットのあある制度でも、その運用のまずさから批判され、十分にその制度の価値が届けられません。また、それは本当に届けるべきユーザーにそのメリットを届けられないことにもつながります。制度を作るときには運用こそ一番注意深く考えるべきだと思います。

行政をハックしよう ―ユーザー中心の行政デジタルサービスを目指して