行政サービス開発と官民の関係性（私見）

行政サービスのデジタル化がデジタル庁発足後さらに加速されてきているが、サービス開発は行政組織だけでは達成できない。
官民の開発に対する関与の度合ついてはさまざまなレベルがあり、これによってサービスのオーナーシップのあり方が異なる。
今回は行政組織内の開発能力にさまざまなレベルがある中で、どんな開発体制があり得るのか整理してみたい。

1.事業者委託による開発

これまでの多くの行政オンラインサービスは大手のITベンダーに依存していた。システムの企画や仕様書の作成まで外注しており、この結果、サービスに対する行政によるオーナーシップを持たずベンダーに完全に依存する形となっていた。
これを見直し、サービスのオーナーシップを取り戻すために民間からITプロジェクトマネージャーを採用し、協働できる体制を構築したり、デジタル化に対応する行政人材の育成が一部の行政組織で進んできた。デジタル推進組織を構える官庁、自治体はまずこれを目指していると思われる。
一方でこのやり方は引き続きベンダーとのコミュニケーションにコストがかかり、簡素な改修もすぐに実装されないといったケースも多く、アジリティが低いことがネックである。加えて、委託コストも高止まりする傾向にある。

2.ローコードツールを活用した簡易な内製

コードを書かなくてもサービスを構築可能なローコードツールを活用することで行政内部のIT人材がサービスを開発することを可能になる。こうしたツールに行政職員も含めた内部の人材が習熟すればクイックに新しいサービスがリリースでき、改修も簡単なものはすぐさま行うことができる。e-maffやgbizformといった農水省、経産省の動きはこうした姿を目指している。これはプロジェクトマネジメントだけでなく、プロダクトのオーナーシップを一段行政側に強めるものである。
一方で採用するローコードツールによる機能制約はあり、柔軟な機能開発が難しいケースがあるほか、上手くサービスを選択しなければライセンスコストが高くなるといったケースも見られる。
また、これが成り立つための最も重要な点として内部の行政職員が十分なプロセス改善の知識や、ツールに対する知見を備えていなければ機能しない。

3.コードレベルでの内製

ローコードツールではなく、スクラッチでサービスデザインから開発、リリースまで全てを行政内部で行い、ITサービス企業のように振る舞う形がもう一歩踏み込んだ形として考えられる。この場合、活用する技術をコントロールしてサービス開発を行うことができる。海外のGDS, GovTech,USDSなどの組織はデザイナーからエンジニア、プロダクトマネージャーまで幅広い専門人材を有し、オリジナルのプロダクトを開発、運用している。
彼らは特に政府全体の基礎となるプロダクトを独自で開発することで政府サービスの質の標準化を担保しようとしている。行政内部で全てを開発できる能力を持つことは、外注先とのコミュニケーションコストをなくし、目的に合わせてクイックに開発を行える、インシデントが起きた際にも内部で対応可能となるといったメリットがある。政府のコアなサービスを内製することは他の行政機関にも貢献し、コスト面でも外注よりメリットが出るケースもある。デジタル庁もこうした組織をベンチマークしながら、まずは組織体制の整備を進めている。
一方で人材の採用は非常に競争的な環境にあり、サービス開発を行うチームとしてメンバーが機能することもカルチャーが確立していなければ難しい面がある。加えて開発環境が整備されていることも前提となる。デジタル庁もまさにこうした状況に対応していくことが必要となる。

4.SaaSを活用した公的サービス提供

行政組織が手続き等のデータベースを整備し、APIを公開すれば、民間事業者側がそのAPIを活用してサービスを開発し、国民や事業者に提供するビジネスモデルが考えられる。例えば納税や労務管理等の分野ではすでにそうしたSaaS事業者が多く存在し、行政手続きを行いやすいインターフェースや利用体験を提供しているほか、自治体に対して行政手続のインターフェースをSaaSとして提供しているケースもある。

行政サービスのSaaSは
①ユーザである市民、事業者からフィーを取るモデルと、
②行政組織からの委託を受けてそこから売上を得るモデル
がある。

①の場合、事業者にビジネス上のメリットがなければ維持されず、全ての国民、事業者がそのサービスを享受できるわけではないところがあり、行政側にフロントサービスのオーナーシップはない。一方、手続き処理系のサービスではバックオフィスでAPI経由で流れ込んでくるデータを適切に管理することが行政側に求められる。つまり引き続き行政組織によるデータのオーナーシップは維持しなければいけないことには変わりないため、データ連携のためのAPIを整備・管理し、データを適切に活用することが非常に重要になる。

②は行政側が1〜３の代わりにSaaSを導入する形になる。この中で、やはりフロントサービスのオーナーシップを行政側が持つことが重要になるとともに、バックオフィスのデータ管理環境は整備することが①同様重要だろう。
また、この場合には、民間が独自に行政サービスの利便性を高めるために提供している①の類型とは異なり、「行政機関が委託した、行政機関による提供サービス」として位置づけられるため、セキュリティ基準等は行政で求められる要件を満たすことが求められ、一段参入のハードルは高くなると考えられる。

行政サービスの提供に当たってどの開発手法を選ぶのか

ここまで見てきた行政デジタルサービスの開発体制類型は、開発するサービスの目的や、行政組織の持つ能力によってどれを選択すべきかも変わってくると考えられる。

デジタル庁などが政府横断で利用するコアなサービス開発については技術レベルでコントロールすることが重要となり、3.を選択することが考えられるが、一方で運用になればトランザクションが膨大になるため、そこは1.のモデルで回すといった考え方もある。
このケースの場合、上述の通り、デザイン、エンジニアリング、アーキテクチャ設計等各スペシャリストを組織内に十分抱える必要がある。

また各行政機関の手続きサービスの提供でも、簡素なプロセスでそこまで複雑な作り込みが必要なければ2.のようにローコードツールでクイックに開発、運用できる体制を構築するか、もしくは4.②のようにSaaSを活用してサービスを提供することが考えられる。
この場合には業務に携わる行政職員のITリテラシーとツール利用のスキル向上がキーになると考える。

上記のような開発能力が担保できない行政組織が1.を選択したとしても最低限ベンダーとコミュニケーションし、開発をコントロールできる体制は備える必要がある。また、サービスの性質によっては、事業者とアジャイル開発などにも取り組めるような体制が行政側も必要となる。

上記のような形で政府がオーナーシップをもつサービスがある一方で4.①のように民間の創意工夫により、政府が提供するAPIを活用して、より利用しやすいサービスを市民、事業者に提供することも重要である。ただし、これらのサービスは継続的なビジネスモデルが成り立つ範囲でしか提供されない。
①の提供モデルとしては
１）サービス利用料を市民・事業者に課金してサービスを運営
２）サイトにウェブ広告を掲載し、その収入で運営
３）行政サービス活用のためのユーザー登録を通じて、その事業者が提供する他のサービスへの誘導を図り、マーケティングコストの範囲で運営
といったパターンが考えられる。

他にもクリエイティブなビジネスモデルがあるかもしれないが、4.①のサービス類型はあくまでサービス提供事業者の責任の下でサービスが提供される点で、１〜３や４②とは性質が異なる。サービス提供事業者がビジネスとして成り立たなくなった場合にはそれが終了されてもユーザーは文句が言えない、といった点を考えると、行政がこれに全て依存することは難しいのではないか。
一方でそのサービスが十分なユーザーベースを持ち、利用されている場合には4. ②のように行政組織が委託先にするといったスイッチングもあり得るかもしれない。

まとめ

このように行政のデジタルサービスの開発手法を整理してきたが、重要なのはサービスの目的、行政組織が持つ開発能力、コスト効率性などの軸で評価し、どれを選択するかを考えていくことが重要になると思われる。

ただし、いずれの場合でも重要なのは行政組織がサービスのオーナーシップを持ち、どの開発類型を取るべきか判断できるだけのリテラシーを持った人材を育成していくことである。

全て内製を行うことはできないとしても、行政組織のシステムガバナンスや、サービスの質担保の観点からITリテラシーを持つ人材を内外から集め、組織化することで全体最適の観点からサービスを提供していくことが求められるのではないか。

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