差分

===内外の視点から見た行政手続のオンライン利用促進における課題===

===内外の視点から見た行政手続のオンライン利用促進における課題===

https://www8.cao.go.jp/kisei-kaikaku/kisei/meeting/wg/digital/20210202/gijiroku0202.pdf#page=2

https://www8.cao.go.jp/kisei-kaikaku/kisei/meeting/wg/digital/20210202/gijiroku0202.pdf#page=2

○林専門委員　では、進めさせていただきます。林達也と申します。よろしくお願いいたします。<br>

○林専門委員　では、進めさせていただきます。林達也と申します。よろしくお願いいたします。<br>

　今回はこのタイトルで、10分という中でかなり詰め込みなので駆け足になってしまいますが、お話しさせていただければと思います。<br>

　今回はこのタイトルで、10分という中でかなり詰め込みなので駆け足になってしまいますが、お話しさせていただければと思います。<br>

　プロフィール等は流用なので端的になのですけれども、テック系のセキュリティーやデ ータ解析のスタートアップに在籍させていただいております。もともとレピダムというR&D の会社を創業してやっておりました。現在、経済産業省の情報プロジェクト室でデジタル 化推進マネージャーという役職を非常勤で週2日ほどやらせていただいております。また、 慶應義塾大学のほうで社会人博士課程、あとは研究所のリサーチャーをさせていただいて おります。委員等、本WGも含め幾つかさせていただいたり、また、いわゆるコミュニティ ーワークというところもやらせていただいております。<br>

　プロフィール等は流用なので端的になのですけれども、テック系のセキュリティーやデ ータ解析のスタートアップに在籍させていただいております。もともとレピダムというR&Dの会社を創業してやっておりました。現在、経済産業省の情報プロジェクト室でデジタル化推進マネージャーという役職を非常勤で週2日ほどやらせていただいております。また、慶應義塾大学のほうで社会人博士課程、あとは研究所のリサーチャーをさせていただいております。委員等、本WGも含め幾つかさせていただいたり、また、いわゆるコミュニティーワークというところもやらせていただいております。<br>

　この辺は割愛させていただいて、今回経営者としての視点、もう一つは専門家・コンサルタント、こちらはITシステムやID、認証・認可、セキュリティー、プライバシーですね。 あとはソフトウエアのエンジニアとしていわゆる学術研究、私のテーマはトラストというものなのですけれども、それですとか、国際標準化をずっとやっておりましたのでインタ ーネットの国際標準といった視点と、公務員として官公庁の内側でデジタル化推進マネージャーというお仕事、あとはこちらの専門委員ですとか、何より一市民としての視点で今 回5回ほど参加させていただいた中で感じたこと、課題感を御共有させていただければと 思います。<br>

　この辺は割愛させていただいて、今回経営者としての視点、もう一つは専門家・コンサルタント、こちらはITシステムやID、認証・認可、セキュリティー、プライバシーですね。 あとはソフトウエアのエンジニアとしていわゆる学術研究、私のテーマはトラストというものなのですけれども、それですとか、国際標準化をずっとやっておりましたのでインタ ーネットの国際標準といった視点と、公務員として官公庁の内側でデジタル化推進マネージャーというお仕事、あとはこちらの専門委員ですとか、何より一市民としての視点で今 回5回ほど参加させていただいた中で感じたこと、課題感を御共有させていただければと 思います。<br>

私の認識なのですけれども、本WGの前提と課題、有用性と範囲というところがあると思 っているのですが、前提としましては、やはり規制改革推進会議はトップダウンの「強い 指示」ができるというのが非常に重要な項目かと思っております。これはベースラインを 割ったある意味「ひどい」ものを改革するところが目的なのではないかと認識しておりま して、うまくいっているものに改革は不要でしょうというところも含めて、ですから、こ

　私の認識なのですけれども、本WGの前提と課題、有用性と範囲というところがあると思 っているのですが、前提としましては、やはり規制改革推進会議はトップダウンの「強い 指示」ができるというのが非常に重要な項目かと思っております。これはベースラインを 割ったある意味「ひどい」ものを改革するところが目的なのではないかと認識しておりま して、うまくいっているものに改革は不要でしょうというところも含めて、ですから、このワーキング・グループがあるということは、デジタルガバメントは「イケてない」とい うことは何となく分かるところでございます。<br>

　有効性として、例えば「押印廃止」や「エンド・ツー・エンドデジタル化」みたいな形 のものは非常にトップダウンでの「最低限のこと」を「効率的に」「短期的に」推進する ための手段として有効なのではないかと感じております。まずそれをやれば確実に総体で はベターになるというアプローチだと認識しています。<br>

のワーキング・グループがあるということは、デジタルガバメントは「イケてない」とい うことは何となく分かるところでございます。

　一方で、ここには課題もあるかと思っておりまして、取組の煮え切らなさみたいなもの もあって、令和5年や令和6年の話を今しているのですけれども、ITの分野の速度感で言 うと非常に遠い話でなかなか難しいと。もう一つは、現状がひどいということがあえてあ る前提で言いますと、短期的な解にフォーカスしていますが、長期的にはこれは理想的な ものではないかもしれない、間違った方向に行ってしまう可能性があるかもしれないとい う認識がございます。<br>

有効性として、例えば「押印廃止」や「エンド・ツー・エンドデジタル化」みたいな形 のものは非常にトップダウンでの「最低限のこと」を「効率的に」「短期的に」推進する ための手段として有効なのではないかと感じております。まずそれをやれば確実に総体で はベターになるというアプローチだと認識しています。

　端的に言いまして、もうほぼここが要点なのですが「ひどいと言われたから直す...」と いうマインドセットから「最高のサービスを提供しよう!」というものに至るギャップを どうしたら超えられるかということが課題になるのかと思います。<br>

一方で、ここには課題もあるかと思っておりまして、取組の煮え切らなさみたいなもの もあって、令和5年や令和6年の話を今しているのですけれども、ITの分野の速度感で言 うと非常に遠い話でなかなか難しいと。もう一つは、現状がひどいということがあえてあ る前提で言いますと、短期的な解にフォーカスしていますが、長期的にはこれは理想的な ものではないかもしれない、間違った方向に行ってしまう可能性があるかもしれないとい う認識がございます。

　これは内部の話、しかも本来規制改革推進会議から叱られる側のポジションで大変恐縮 なのですけれども、経産省情プロ室の取組も御紹介させていただきたいと。民間から「デ ジタル化推進マネージャー」というものを人材としてプールしています。1月末で12名だ と思います。経産省内外の取組をデジタル化、オンライン化、システム化してきておりま して、そのナレッジが「失敗も含めて」共有されています。分かりやすい何をやっている かの例なのですけれども、こちらのWGでも何度も御紹介いただいているGビズID、法人認 証基盤ですとか、Gビズフォームと言われる一般的な申請実務を可能な限り汎用的にカバ ーできるものですとか、GビズコネクトというAPI連携を内外で容易に行えるようなミド ルウエアの開発などをさせていただいております。<br>

端的に言いまして、もうほぼここが要点なのですが「ひどいと言われたから直す...」と いうマインドセットから「最高のサービスを提供しよう!」というものに至るギャップを どうしたら超えられるかということが課題になるのかと思います。

　それらの取組の知見を「Digital Service Playbook」という形でGitHubのほうで今公開 させていただいております。この中では、特にサービスデザインやBPRの部分は参考にして いただけるかと思っています。良し悪しあった「jGrants」という取組もあるのですけれど も、私が入ったときにはもう既にあったものなのですが、こちらの課題や反省点などもこ ちらのPlaybookに反映されています。<br>

これは内部の話、しかも本来規制改革推進会議から叱られる側のポジションで大変恐縮 なのですけれども、経産省情プロ室の取組も御紹介させていただきたいと。民間から「デ ジタル化推進マネージャー」というものを人材としてプールしています。1月末で12名だ と思います。経産省内外の取組をデジタル化、オンライン化、システム化してきておりま して、そのナレッジが「失敗も含めて」共有されています。分かりやすい何をやっている かの例なのですけれども、こちらのWGでも何度も御紹介いただいているGビズID、法人認 証基盤ですとか、Gビズフォームと言われる一般的な申請実務を可能な限り汎用的にカバ ーできるものですとか、GビズコネクトというAPI連携を内外で容易に行えるようなミド ルウエアの開発などをさせていただいております。

　このPlaybookのBPRの章は私もすごく参考になったのですけれども、「ECRS(イクルス)」 という考え方で、Eliminate(エリミネート)・排除、Combine(コンバイン)・結合、Rearrange (リアレンジ)・交換、Simplify(シンプリファイ)・簡素化といったことをBPRのプロセ スで考えるというところを参考にできればと思っています。<br>

それらの取組の知見を「Digital Service Playbook」という形でGitHubのほうで今公開 させていただいております。この中では、特にサービスデザインやBPRの部分は参考にして いただけるかと思っています。良し悪しあった「jGrants」という取組もあるのですけれど も、私が入ったときにはもう既にあったものなのですが、こちらの課題や反省点などもこ ちらのPlaybookに反映されています。

　こちらは既に共有されているお話ではありますけれども、BPRにおいて変えるべき考え 方の一例として、ここはすごく重要で、虚偽の申請を防ぐために各種証明書類を出してく ださいということがあるわけですけれども、それは本来は法に基づいて罰せられる内容なのです、なので、誓約だけを行ってくださいと。これはMAFFさんの事例ですごくよいなと 思って、省内でも展開させていただいたのですけれども、こういう例外処理(プロセス) のタイミングを制御することで、双方の不要な作業を削減するというのは、非常にBPRにお いては重要かと思っています。<br>

このPlaybookのBPRの章は私もすごく参考になったのですけれども、「ECRS(イクルス)」 という考え方で、Eliminate(エリミネート)・排除、Combine(コンバイン)・結合、Rearrange (リアレンジ)・交換、Simplify(シンプリファイ)・簡素化といったことをBPRのプロセ スで考えるというところを参考にできればと思っています。

　また、最近サービスですと、止まってはいけないがメンテナンスはしないといけないの で予告して定期的に止めますという話があって、e-Govさんなどが1週間止まったのが話 題になりましたけれども、本来であればパブリッククラウドですら最近は不定期に全世界 的にたまに落ちてしまうわけです。クラウドファーストと言っている我々においては、落 ちることを前提にして、問題の検出をなるべく早くやって、常にメンテナンスを可能にす る。そういったレジリエンスを高める行為、ツイッターは鯨を出すというのを昔やってい たのですけれども、こういうことができるようにならないと前に進みにくいのかなと思っ ています。<br>

こちらは既に共有されているお話ではありますけれども、BPRにおいて変えるべき考え 方の一例として、ここはすごく重要で、虚偽の申請を防ぐために各種証明書類を出してく ださいということがあるわけですけれども、それは本来は法に基づいて罰せられる内容な

　事例をなるべくしゃべってくださいというお話だったのですけれども、なかなかまとめ づらいので、境界線はどこだったかということをまとめてみました。これは官民関係なく 経験上言えることなのですけれども、一緒に作成したベンダーに恵まれたかどうかという のは完全に間違いなく有効だったと思います。一緒にチームとして働けたものは成功しま した。あと、意思決定者に専門性に対するリスペクトがあったか。あると任せていただけ るのでアジリティが向上するということがございます。必要なリソースが分かって獲得で きていたか。分からないケースは結構あります。初期にちゃんと時間を使えたかというの は結構重要で、最初の頃は立ち上がりが遅かったりするのですけれども、ここでも計画を して素早く動けるかということと同じく、コミュニケーション密度を高くできたか。これ はベンダーさんと毎日のようにコミュニケーションして、最終的なトータルコストを抑え て、品質を向上するためのコミュニケーションを実現できたかというところは非常に大き いと思います。「運用」のことを考えて物をつくれたかというのも大きくて、これはサー ビスの継続性の問題みたいなところになってくるかと思います。<br>

　官公庁のお仕事をさせていただいている中で、ベンダーコントロールというのは非常に 難しい問題だと感じています。多くの失敗システムは丸投げによるものだと断言していい かと思っています。運用も投げざるを得ないのですけれども、これが当たり前になってい るというのはサービスの提供という概念ではおかしいのです。さらに、ベンダーによいも のをつくるインセンティブがないことも問題で、ベンダーは納品すれば終わりですと。我々 はいいベンダーを選べませんし、いいベンダーは割が合わないから入札してくれないとい う悪いスパイラルになっている。もともとサービス開発は民間でもとても難しいもので、 これだけでビジネスになり得るものではありますから非常に難しいのですけれども、そこ でさらにつくりっ放しになりがちだったり、官公庁ではe-Taxのように時期の問題があっ て濃淡も出やすいので非常に難しいところがあると思います。これらを自分たちのシステ ムとして運用問題、運用していけるかというところが課題になると思うのですけれども、完全内製は難しいものの、ベンダーと毎日、サービスと毎日、毎週向き合えるかというと ころが一つ指標になるかと思っています。<br>

 

　ユーザーエクスペリエンスを、一ユーザーの感性で使いやすさを確認できるかなのです けれども、いわゆる「バックオフィスシステム」というものに今回近いものもかなり多く あると思うのですが、これは省庁だけではなく民間もひどくて、競争原理がない選択肢が ない押しつけのシステムというのは、総じてひどくなると感じております。例えば組織内 の経費・旅費精算システムや法人向けインターネットバンキングなどは本当にひどいと。<br>

のです、なので、誓約だけを行ってくださいと。これはMAFFさんの事例ですごくよいなと 思って、省内でも展開させていただいたのですけれども、こういう例外処理(プロセス) のタイミングを制御することで、双方の不要な作業を削減するというのは、非常にBPRにお いては重要かと思っています。

　使ってみたかどうかということもよく問われるのですけれども、各委員からもこういう 質問が出ると思うのですが、試したら確かに分かるのですが、実際に省庁からAWS、Amazon Web Servicesですね。そこにアクセスできないみたいなことが起きているわけです。これ でレビューをちゃんとできているかと言われると、そもそもいいサービスかどうかを毎日 見ることすらなかなかできない状況で、これは非常に問題だと思います。<br>

また、最近サービスですと、止まってはいけないがメンテナンスはしないといけないの で予告して定期的に止めますという話があって、e-Govさんなどが1週間止まったのが話 題になりましたけれども、本来であればパブリッククラウドですら最近は不定期に全世界 的にたまに落ちてしまうわけです。クラウドファーストと言っている我々においては、落 ちることを前提にして、問題の検出をなるべく早くやって、常にメンテナンスを可能にす る。そういったレジリエンスを高める行為、ツイッターは鯨を出すというのを昔やってい たのですけれども、こういうことができるようにならないと前に進みにくいのかなと思っ ています。

　ということも踏まえて、今、足りないものは何かということだと思うのですけれども、 トップダウンの政策はあると。そうであれば、ボトムアップの支援策が欲しいですね。こ れはレビューや仕様策定を支援したり、相談できる横串の窓口が欲しい。知見の共有、類 型化、ベストプラクティスとバッドプラクティスの共有、これも横串の連携みたいなもの ができるといいなと感じています。もし可能でしたら、これは勝手に思っていることです けれども、本WG主導で何か一つ、できれば一番困っていそうなものを成功事例にできれば よいのではないかと思います。<br>

事例をなるべくしゃべってくださいというお話だったのですけれども、なかなかまとめ づらいので、境界線はどこだったかということをまとめてみました。これは官民関係なく 経験上言えることなのですけれども、一緒に作成したベンダーに恵まれたかどうかという のは完全に間違いなく有効だったと思います。一緒にチームとして働けたものは成功しま した。あと、意思決定者に専門性に対するリスペクトがあったか。あると任せていただけ るのでアジリティが向上するということがございます。必要なリソースが分かって獲得で きていたか。分からないケースは結構あります。初期にちゃんと時間を使えたかというの は結構重要で、最初の頃は立ち上がりが遅かったりするのですけれども、ここでも計画を して素早く動けるかということと同じく、コミュニケーション密度を高くできたか。これ はベンダーさんと毎日のようにコミュニケーションして、最終的なトータルコストを抑え て、品質を向上するためのコミュニケーションを実現できたかというところは非常に大き いと思います。「運用」のことを考えて物をつくれたかというのも大きくて、これはサー ビスの継続性の問題みたいなところになってくるかと思います。

　特にAPIのデザインチェック・標準化レビューは実施するべきだと思っていて、これは CIO補佐官に相談したところ、依頼があればもちろんやるよと言っていただけているので、 私ももちろん含めてできるのではないかと思っています。<br>

官公庁のお仕事をさせていただいている中で、ベンダーコントロールというのは非常に 難しい問題だと感じています。多くの失敗システムは丸投げによるものだと断言していい かと思っています。運用も投げざるを得ないのですけれども、これが当たり前になってい るというのはサービスの提供という概念ではおかしいのです。さらに、ベンダーによいも のをつくるインセンティブがないことも問題で、ベンダーは納品すれば終わりですと。我々 はいいベンダーを選べませんし、いいベンダーは割が合わないから入札してくれないとい う悪いスパイラルになっている。もともとサービス開発は民間でもとても難しいもので、 これだけでビジネスになり得るものではありますから非常に難しいのですけれども、そこ でさらにつくりっ放しになりがちだったり、官公庁ではe-Taxのように時期の問題があっ て濃淡も出やすいので非常に難しいところがあると思います。これらを自分たちのシステ ムとして運用問題、運用していけるかというところが課題になると思うのですけれども、

　もう一つ、無謬性を捨てていいかどうかというところが必ず出るのですけれども、先ほ ども落ちていいかいけないかみたいなものがあったのですが、オール・オア・ナッシング という考え方を捨てられるかどうかというのは非常に大きいと思います。問題は起きる前 提で物事を考えられるかということですね。特に金融システムみたいなグレードは必要が ないというところを意識できると、物をつくっていくことに対してすごく抵抗が下がるの ではないかと思っています。<br>

　こちらはデジタル庁さんに担ってもらいたいものなのですけれども、この中、いろいろ ありますが、GitHubの禁止みたいなものも含めて起きないでほしいなということはありま すし、アーキテクチャ・プラットフォーム化への道はきっと彼らにバトンが渡されていく のではないかと思っています。<br>

 

　こちら、まとめてみたのですけれども、全部は割愛するのですが、1点だけ、端的に言 って総体的に官公庁はベンダーになめられがちです。ですから、きちんとコミュニケーシ ョンすることが重要だと思います。ですから、人的・組織的・横断的な取組はデジタル庁 さんに行くのだろうと思っているのですけれども、システム、データ的な横断的な取組はAPI化・標準化の推進をできればと思いますし、長期的な取組のためにやるべきことという 意味では、課題の収集というものがまず今この瞬間少しずつできているので、これを進め ていければと思います。<br>

完全内製は難しいものの、ベンダーと毎日、サービスと毎日、毎週向き合えるかというと ころが一つ指標になるかと思っています。

ユーザーエクスペリエンスを、一ユーザーの感性で使いやすさを確認できるかなのです けれども、いわゆる「バックオフィスシステム」というものに今回近いものもかなり多く あると思うのですが、これは省庁だけではなく民間もひどくて、競争原理がない選択肢が ない押しつけのシステムというのは、総じてひどくなると感じております。例えば組織内 の経費・旅費精算システムや法人向けインターネットバンキングなどは本当にひどいと。

使ってみたかどうかということもよく問われるのですけれども、各委員からもこういう 質問が出ると思うのですが、試したら確かに分かるのですが、実際に省庁からAWS、Amazon Web Servicesですね。そこにアクセスできないみたいなことが起きているわけです。これ でレビューをちゃんとできているかと言われると、そもそもいいサービスかどうかを毎日 見ることすらなかなかできない状況で、これは非常に問題だと思います。

ということも踏まえて、今、足りないものは何かということだと思うのですけれども、 トップダウンの政策はあると。そうであれば、ボトムアップの支援策が欲しいですね。こ れはレビューや仕様策定を支援したり、相談できる横串の窓口が欲しい。知見の共有、類 型化、ベストプラクティスとバッドプラクティスの共有、これも横串の連携みたいなもの ができるといいなと感じています。もし可能でしたら、これは勝手に思っていることです けれども、本WG主導で何か一つ、できれば一番困っていそうなものを成功事例にできれば よいのではないかと思います。

特にAPIのデザインチェック・標準化レビューは実施するべきだと思っていて、これは CIO補佐官に相談したところ、依頼があればもちろんやるよと言っていただけているので、 私ももちろん含めてできるのではないかと思っています。

もう一つ、無謬性を捨てていいかどうかというところが必ず出るのですけれども、先ほ ども落ちていいかいけないかみたいなものがあったのですが、オール・オア・ナッシング という考え方を捨てられるかどうかというのは非常に大きいと思います。問題は起きる前 提で物事を考えられるかということですね。特に金融システムみたいなグレードは必要が ないというところを意識できると、物をつくっていくことに対してすごく抵抗が下がるの ではないかと思っています。

こちらはデジタル庁さんに担ってもらいたいものなのですけれども、この中、いろいろ ありますが、GitHubの禁止みたいなものも含めて起きないでほしいなということはありま すし、アーキテクチャ・プラットフォーム化への道はきっと彼らにバトンが渡されていく のではないかと思っています。

こちら、まとめてみたのですけれども、全部は割愛するのですが、1点だけ、端的に言 って総体的に官公庁はベンダーになめられがちです。ですから、きちんとコミュニケーシ ョンすることが重要だと思います。ですから、人的・組織的・横断的な取組はデジタル庁 さんに行くのだろうと思っているのですけれども、システム、データ的な横断的な取組は

 

API化・標準化の推進をできればと思いますし、長期的な取組のためにやるべきことという 意味では、課題の収集というものがまず今この瞬間少しずつできているので、これを進め ていければと思います。

{{DEFAULTSORT:てしたるかはめんとわきんくくるふ}}

{{DEFAULTSORT:てしたるかはめんとわきんくくるふ}}