はじめに
なぜこの記事を書こうと思ったか
ここ数ヶ月、いわゆる「行政手続きのデジタル化」のプロジェクトに複数携わらせてもらっています。
どのプロジェクトも、当事者である職員が高いモチベーションと課題意識を持ち、デジタル化の実現に向けて邁進しています。
ですが、複数のプロジェクトに関わる中で感じるのは、共通の'How To'のようなものがまだまだ確立されていないということです。
『行政 デジタル化 事例』と検索すると、「こういうツールでやりました」「業務の棚卸しを行ったことが大きかったです」など、成功を左右する要因に関する話しはみかけるのですが、いわゆる「お作法」について書かれている記事はなかなか見つけることができません。
デジタル化のプロジェクトでは、それまで続けてきた仕事をデジタル技術でガラっと変えてしまおうという、ある意味未開の地を開拓するようなものですから、暗中模索になるのは当然です。
とはいえ、何かしら共通する'型'というか、押さえるべきポイントはあって、そこを押さえることで、無駄な議論を避け、手戻りなくプロジェクトを進めていけるのではないかと思うのです。
この記事では、私がこれまで関わってきたプロジェクトを通じて感じた、行政手続きをデジタル化するにあたり押さえておい方がよいと(勝手に)思うポイントについてご紹介します。
<この記事を読んで欲しい人>
- 行政関係者
- 行政のデジタル化に興味のあるエンジニアを始めとしたQiita読者のみなさん
<この記事で触れること>
- 行政事務のデジタル化を進めていくための心構えについて
- 行政事務のデジタル化を進めていく上で押さえておくべきことについて
<この記事では触れないこと>
- 具体的な事例・技術について
- システムの構築・調達の方法について
- システム構築後の運用・保守について
※なお、ここでいう「デジタル化」は、必ずしも「オンライン化」のことを指しているわけではありません。
「行政手続きのデジタル化」プロジェクト成功のための8カ条
1. まずはゴールを決める
プロジェクトが立ち上がり、まず最初に行うことはゴールの設定です。
ここでいうゴールとは、フロー図の終端のことではなく、何を以てプロジェクトを成功とするか、ということです。
プロジェクトメンバー全員が、プロジェクトを経て実現したいビジョンを共有し、そのうちどこまでを達成できたら成功とするか、という目標を定めましょう。
ただし、ゴールは、市民(顧客)サービスの向上や、事務負担やリスクの軽減に繋がるものでなければなりません。
いずれにも当てはまらない、デジタル化することが目的になってしまっているプロジェクトは実施そのものを見直すべきではないかと思います。
申請書の体裁をそのままWebフォーム化する、印鑑が必要な書類は電子申請後に郵送または持参させる、といったことが何の検討もなくゴールになってしまわないよう注意してください。(もちろん、検討を経て、止むを得ずそういった方法を採るということであれば致し方ないかと思います。)
（とはいえ）「ゴール」は通過点
この項では「ゴール」と表現しましたが、正確には、構築が完了すると間髪なく、効果測定による検証・改善(6項参照)や、運用保守(7項参照)がスタートします。
プロジェクトは先々まで続いていくということを心の隅に留めつつ、一旦のゴール達成(構築完了)を目指しましょう。
「覚悟」も必要
デジタル化のプロジェクトは、現状の体勢で、現行の業務と並行して行うことになることがほとんどかと思います(大きいプロジェクトだと、検討・構築の期間だけ増員となることもあるかもしれませんが)。
プロジェクトの間は、検討や議論、予算獲得や合意形成のための資料作成、プロジェクト管理など、多くの作業を行わなければなりません。
構築が完了し、運用が軌道に乗るまでの間は、プロジェクトに関わる全てのメンバーが協力し、これを乗り切る覚悟も必要です。
2. プロジェクトを左右する要件を確認する
ゴールが決まったら、プロジェクト全体に影響するような要件を確認・共有します。
〈要件の例〉
- 法令・条例等
- 構築や運用に携わる職員数
- スケジュールや予算額
- 利用しなければいけないシステム 等
ここが不明瞭なままだと、後に手戻りが発生し、プロジェクトが停滞する原因になるからです。
なお、上述のような事柄には当てはまらない細かな要件については、プロジェクトを進める過程で都度軌道修正しながら決めてくことになります。
3. デジタル化の恩恵を十分に享受できる仕組みを考える
具体的なフローを考えていくことになったら、まず、既存のフローのことは一旦忘れましょう。
なぜなら、既存のフローは、アナログ環境下においては最適化されたものですが、デジタル環境下では、必ずしも最適なものとは限らないからです。
機械にできることは機械に任せてしまうことで、作業を効率化し、尚且つ、負担やリスクが軽減できるという「デジタル化による恩恵」を受けることができます。
<デジタル化による恩恵の例>
- 一度入力された内容を複写(引用)することで、それまで複数だった入力箇所をの一箇所に集約することができた。
- 所得情報を引用し、かつ自動計算することで、所得証明書の添付や手入力、計算が不要になった。
- CRM(顧客関係管理)システムを使うことで、遠隔の窓口との情報共有がスムーズになった
- 受信した申請データをAPIで業務システムと連携させることで、申請データの入力漏れを防ぐとともに、後工程を効率化することができた。
こうしたデジタル化による恩恵を受けるには、デジタル化することでどういったことができるようになるのかを広く知っておくことが大切です。
行政職員の場合は'広く浅く'で構いませんので、色々な事例の情報を日頃から収集されておくことをお勧めします。
なお、相談相手のエンジニアにも色々と質問を投げかけてみるといいとは思うのですが、より質の高い議論ができるよう、行政職員自身も一定の知識を持っておく方がよいかと思います。
4. 俯瞰して考えることを忘れない
デジタル化に向けてフローを検討していると、以下のような指摘を受けることがあります。
- 紙への記入からPCへの入力に変わることで、むしろ作業負担が増えている
- デジタル化＝省力化だと思っていたが、フローに落とし込んでみるとそれ程変わらなかった
確かに、その作業部分だけを見ているとそう思うかもしれませんが、これを俯瞰して見てみると、
- 紙への記入からPCへの入力に変わることで、むしろ作業負担が増えている
→ しかし、後工程では、デジタル化されているデータを引き継ぎ、利用できるため全体の作業量が減っている - デジタル化＝省力化だと思っていたが、フローに落とし込んでみるとそれ程変わらなかった
→ しかし、紙の紛失などのリスクが軽減されている といった効果があることがわかります。
特にリスクの増減については見落とされがちで、目の前の業務量の変化だけで議論されてしまう傾向があります。
これを防ぐために、なるべくこまめに、メンバー全員で、それまでに練り上げた案を俯瞰して見る機会を意識的に作るようにしましょう。
5. 認識の共有はこまめに
デジタル化の議論は、あらゆる事柄とステークホルダーが連動し入り混じった複雑なものになりがちです。ましてや、こういった議論に慣れていない行政職員は、新しい知識を勉強しながら議論に挑む必要があり、非常に大きな負担となります。
そのため、認識のズレが頻繁に発生します。
不慣れが故、エンジニアが発した何気ない単語が「ん?...よくわからなかった気がしたけど、まあいいか」とスルーされ、その結果、認識のズレが発生してしまう場合もあります。
行政職員とエンジニアの双方で、議事録をよく確認すること(少しでもわからない点があれば必ず確認すること)、議論の本題の前に「この件はこういう整理だったと思いますが...」といったように必ず前提を具体的に確認し合うようにするなど、こまめに認識を共有する機会を作るようにしましょう。
わからないことや困ったことも抱え込まず共有する
行政職員にとって、デジタル化の議論の中で飛び交う単語は今まで聞いたことのないものばかりです。
エンジニアがサラっと言った一言でも、わからないことはすぐに「今の言葉がわかりません」と言うようにしましょう。
逆にエンジニアにとっても、行政界隈の単語は聞き慣れないものばかりです。
「支出負担行為」などとサラっと言ってしまわないよう、誰にでもわかる単語を用いることを心がけましょう。
モックアップやプロトタイプを活用する
最近の制作の現場では、モックアップやプロトタイプを作成し、素早い意思決定に繋げることが主流になってきています。
(IT用語で「モックアップ」とは「画面イメージ」のこと、「プロトタイプ」とはモックアップに動きを付けることをいいます。)
デジタル技術に詳しくない行政職員にとって、実際の画面イメージや、実際に動くものを見せることは、誤解と認識のズレを防ぐのに非常に効果があります。
最近では、protやAdobe XDなど、動きのあるモックアップやプロトタイプを簡単に作成できるツールも出てきています。行政職員でも十分に使えるので、ぜひ活用してみてください。
また、kintoneやPower Appsなどのローコードツールを使ってのデジタル化を検討しているのであれば、簡単なデモ版を作成し、それを使って議論するのも手かと思います。
6. 効果測定に基づく改善を常に行う
デジタル化の利点は効果が測定できることにあります。
たとえば、とあるWebサイトにおいて、どのサイトからやってきて、どういう操作をして目的を達成したか、或いはどこで離脱したのか、などといった様々なことが測定・記録することができます。
測定・記録したデータを解析することで、検索エンジン対策(SEO対策)や、機能改善・機能追加に繋げたり、政策の立案や検証の重要な根拠資料にもなります。
Webサイトやシステムは、作り手の意図と、実際の使われ方が異なることもありますので、そういったズレを見つけるのに役立ちます。
また、異なるパターンのデザインを表示させ、それぞれの使われ方を検証し、方向性を決定する(ABテスト)といった使い方もできます。
異常値やエラーを記録しておくことで、どこてでどういった不具合が発生しているか確認することもできます。
行政がシステムを導入するときは、「使われる...かもしれない」という機能も最初に全て定義してしまい、いざ稼働してみると全くその機能が使われなかったり、逆に必要な機能が盛り込まれていなかったりし、改修にコストが発生するといったことがしばしばあります。
そういったことを防ぐ対策のひとつとして、最初は必要最低限の機能のみを実装し、その後の使われ方を記録・分析したうえで新たな機能を追加していくといったことができます。
とはいえ、闇雲にデータを取得しておいて、後から検証方法を考えようとしても、思うような効果は見込めません。
デジタル化の議論においては、どうしても目に見える機能のことばかりに気が行ってしまいますが、こうした効果測定についても、予め計画を立てて盛り込むようにしましょう。
7. 運用保守のことを計画段階から考えておく
どれだけ穴のない素晴らしいシステムを構築しても、運用保守は必ず発生します。
制度の変更、運用ルールの変更など、軽微なものであっても都度対応が必要となります。
多くの行政機関では、エンジニアをほとんど抱えておらず、組織内で使うシステムのほとんどが外注されています。
一方で、デジタル化のプロジェクトにおいては「予算がかけられないので(簡単な技術で以て)内製で構築したい」と言われることがあります。
確かに、プロジェクトメンバーの中にITに明るい職員がいると、VBAやローコードツールなどを駆使し、内製でも十分素晴らしい仕組みが構築できるでしょう。
ですが、キーマンとなる職員も容赦無く異動となってしまうのが行政の世界。
ITに全く明るくない職員が後任となってしまうのが行政の世界。
誰でも運用ができるレベルのものなのか、構築段階から慎重に見極めなければいけません。
少しでも不安があれば、迷わず構築段階から外注することをお勧めします。
ですが、もし予算の都合などで外注が難しい場合は、内製で構築し、数年の運用の後、内製した仕組みをベースに外注による再構築を行うことをお勧めします。
数年の運用での実績で効果が見込まれれば、きっと予算化も可能となるはずです。
もしくは、内製で構築し、その後保守を外注することも考えられます。
この場合、詳細な仕様書を準備しておく必要があります。(なるべく構築段階で作成しておくことをお勧めします。)
いずれにせよ、構築を完了させることがプロジェクトのゴールではありません。
せっかく考えた仕組みが後年に渡り使われ続け、更に発展し続けるために、陳腐化しない仕組みを考えることも大切です。
8. 上手くいってもいかなくても必ずアウトプットを
プロジェクトを通して得た学びは必ず他の業務、他の行政組織のデジタル化のプロジェクトにおいて大いに参考になります。
行政のデジタル化という大きな目標の過程で躓いたことは、大抵他の誰かも躓いているはずです。
残念ながら、現時点で行政のデジタル化にかかるナレッジはネット上にあまり存在していません。
多くのナレッジがネット上で共有され、誰かの躓きがそのナレッジによって解決することを願っています。
そのために、成功したことだけでなく、失敗したことや、検討の過程で不採用になったことなど、あらゆる事柄をQiitaなどにアウトプットしていただきたいと思います。
オープンソース化されると最高
作った仕組み(ソースコード)を外部に公開(オープンソース化)するという事例も少しずつ出てきています。
<オープンソースの例>
オープンソース化することで、他の自治体が同じ仕組みを利活用することができたり、市民開発者等の外部からのフィードバックを受けられたりするというメリットがあります。
オープンソースとして公開するにあたっては、著作権やライセンスに問題がないかを確認したり、外部からのフィードバックに対応できる体勢を整えたりしなければなりませんが、じっくり議論された仕組みが組織内に留まらず、広く社会に貢献できる仕組みとして広がれば、行政のデジタル化はより進むのではないかと思います。
最後に
この「行政のデジタル化」という分野が長らく加速しなかった理由は数多くあると思います、そのうちの一つが、デジタル化に際して最も汗をかくことになる「中の人」が行政のプロフェッショナルであってITのプロフェッショナルではないということです。
この記事では、私が勝手に「こうではないか」と思うポイントをご紹介しましたが、私自身も行政側の人間ですので、これからご紹介することが正しい「お作法」なのかはわかりません。
ですので、この記事をきっかけに、普段Qiitaを愛読されているエンジニアの皆さんともこの課題感が共有され、私たちが住みやすい社会の実現に向けた「小さなナレッジ」が共有される文化が育っていくことを願っています。
「これは加えた方がいいよ」「これは違うと思う」そう言ったご意見等々ありましたら、都度記事を修正しますので、どしどしご意見をお聞かせください。