![見出し画像](https://assets.st-note.com/production/uploads/images/67741686/rectangle_large_type_2_a0c38166b27a487c7c8092cac5b26d14.jpg?width=1200)
地方自治体向け電子政府システムのホールシステムフレームワークを開発提供する『GovTech-Initiative』プロジェクトプラン
「Digital-Goverment」「e-Government」「電子政府」
呼び名は変わってきているが…
政府を電子化することにより、効率化・省コスト化と市民の利便性を向上する。
国内では
2000年森内閣が「IT基本戦略」で掲げたのが始まりで
2014年からは呼称も「eGoverment」から「Digital-Goverment」となって
20年経った今も
一向に電子化は進んでいない。
2001年のe-Japan戦略で「2003年度までにすべての行政手続きをインターネット経由で可能とする」という目標が示され、20年以上にわたり行政のデジタル化が推進されてきた。しかしながら、2018年度における国の行政手続きのオンライン化率(種類別)は11.5%、オンライン完結率は7.5%
「新型コロナ禍が促すデジタル・ガバメントへの取り組み 〜 株式会社インターネット総合研究所」より
最近の事例では
「ワクチンパスポート」も「感染者追跡管理システム」も
開発段階でもてんでバラバラで
運用でもまともに機能していない。
具体的に何に問題障害があるのか知らないが
”政府主導では何も革新的な事業はできない”という
今に始まったことではない”単なる一例”だとも言えなくないが…。
国連の調査では国際的にも最下位だという。
2000年より前から活躍する”錚々たる日本のITキーパーソン”はいったい何をやっていたのか?と問いたい。
政府を動かすか
それが無理なら政府抜きで独自のサービス網を展開していないのは何故だろう。
ネットにはいかにも聡明博識雄弁な「有識者」が政府を批判し
「絵に描いた餅」を自信満々に述べているのに
この体たらくはなんだろう。
責任はお上だけでなく民間も同じだ。
政府担当者が馬鹿だという批判は多い。
さりとて一概にそういうハナシでもなかろう。
政府が”馬鹿”なら、それを上手く調略できない業者側も馬鹿だ。
批判してる場合じゃなく
批判してる側が賢者なら
これは巨大なビジネスチャンス。
しかし”官民癒”着という世間の批判に足が竦む?
ただここに来てこの”未曾有の災禍”の中
政府肝いりの『デジタル庁』も立ち上がり
「劇的な変革」が
さぁこれから一気に始まるのだろうか。
とはいえ
これまでも阪神淡路、リーマン、東日本とその契機は何度もあった
にもかかわらず何もできてない。
今回は「意気込み」が違うらしいが…。
元凶はふたつ。
・原則・慣行の温存
そもそもが「対面・書面・押印」、「紙ベースの原本確認」の原則・慣行をそのままでシステムを導入しようとしていること。
・実現戦略性のなさ
改革の実務を「忙しい現場の実務担当者」の片手間、徒手空拳、自助努力のお勉強にお任せなこと。
もしやり方をがらっと変えて上手く行かなかったらどうしよう。
担当者の自分が責任を問われるが、根本的には変えずに「やってるふり」ができれば咎められないんじゃないか。
なぜならそれを指示している上司にもビジョンがあるわけでもなく、そのさらにまた上役に対するエクスキューズしか考えていないからだ。
そうしてそれは国の政府レベルまでエスカレートする。
誰も本気で改革しようとはしていない。
こういう改革には「唯我独尊のディレクター」が必要となる。
確信を持って明確なビジョンを持ち、どんな批判にも揺るがず、万難を排して実現する。
日本はどうしても「悪しき民主主義」になる。みんなの意見を聞くふりをして誰ともなく決めるでもなく決まっていく。”船頭多くして…”状態。
ただそれはないものねだり。「唯我独尊のディレクター」なんか現れない。というかみんなが許さない。
このような構図において必要なのは「エクスキューズ」の可能なプロジェクトスキーム。
つまり担当者を含め”現場の人間”は誰も責任を取らなくていい。「この混乱はアイツのせい」だと言えること。
「GovTech-Initiative」はそのスケープゴートになろう。
とはいえ無論”はなから”犬死に覚悟ではさらさらない。勝算あってのこと。
≪シビックテックの民間主導でデジタル行政システムを推進普及する仕組み≫
『GovTech-Initiative〜ガブテック・イニシアチブ』プロジェクト
はじめに
これは「デジタル行政システムを自前で開発して売っていこう」という”いちSIer業者”がやるような商売ではない。
・地方自治体と民間の業者やエンジニアが参加してシステム実装していくプラットフォームだということ。
・単なるマッチングではなく、技術的なフレームワークや社会実装のフレームワークも提供すること。
・ボランティアではなくソーシャルビジネスクラスの持続可能な収益を上げること。
基本コンセプト
・地方自治体が”お気軽に導入”できる仕組み
コストゼロから始められ、手順がイージー、柔軟、現場に負担なしで労務削減。
・パブリックインフラとして提供
政府主導の「e-Gov」と”付かず離れず”のポジションニング
営利企業として国政府や自治体、あるいは民間企業には直接関わらない。(例えばFacebookやTwitterやYouTubeのような)パブリックインフラとして利用できるものとして提供。
・ボトムアップで国政府のeガバメント促進
地方自治体から始めて、次第に中央政府のシステムに浸透させ、いずれ中央政府システムを置き換えていく。
コアビジネスモデル
申請手続きの要件は「真正性の保証」に尽きる。
つまり申請が”条件をすべて満たしているかどうか”を検証すること。
その検証をアルゴリズム化することがコアになる。
申請者個人・法人の証明、申請条件を証明する各種書類データが提示され、まずはそれらに虚偽がないことを検査する。
「偽造」や「不適正」は比較的アルゴリズムは容易だが、条件を満たしているかどうか微妙で人(担当者)が判定しなければならないものもパラメータ化して機械学習する。
このようにシステム化することで、申請受付担当者の業務負担を大幅に軽減する。
テクニカルアーキテクチャ
プロジェクトの混乱の多くは、コアビジネスモデルとUIデザインを混乱して設計していることに起因する。
よって本プロジェクトではRestAPIによりコアビジネスモデルとUIを完全に切り離して設計開発運用する。
・コアビジネスモデル
データベースとRestAPIで政府が設計開発し運用する。
・UI
民間に開放し、個人レベルでも自由に開発頒布でき、利用数により報酬を得られる仕組みとする。
■政府RestAPI+民間オープンアプリ
「政府サイドの中央システム」と「ユーザーサイドのアプリ」のふたつのセグメントをAPIで接続してポータブルに全体を構成する。
政府が中央データレポジトリとそのIOのためのAPI(egAPI)を提供、それを利用するアプリを民間で自由に開発できるスキームとする。
「中央システム」は、トランスレートシステムで繋げて、レガシーシステムを温存することも可能とする。
■政府RestAPI
3つのデータクラスを扱う。
クラス1:オープンデータ
パブリックコモンデータや政府広報データなどプライバシー情報や機密情報以外のデータ。読み取りは認証無しで可能。書き込みは要認証。
クラス2:プライベートデータ
個人または法人のプライベートな属性や契約データ。
データは原則的に”本人”が所有管理し適宜システムに提供する形とする。システムとの連携は規定されたAPIに準拠する。APIのレスポンスはリアルタイムであることが求められるが、人間の承認を介して数時間から数日の遅延を伴ったものでも可能とする。ただしその際のリスクは”本人”が容認するものである。
なお実際には、APIを備えた「プライバシー情報管理サービス」のようなストレージ業者に委託して運用管理されるのが一般的になるとと見込まれる。
データの真正性は、第三者による証人システムや公的組織による証明によるものとする。
クラス3:コンフィデンシャルデータ
政府の所有する政府内のみで流通する部外秘のデータ。
データの更新はブロックチェーン技術により整合性とトレーサビリティを担保する。
■民間オープンアプリ
egAPI経由でデータを読み書きするユーザー向けアプリ。
民間で自由に開発することを前提とする。
プロダクトコンセプト
本プロジェクトでは「デジタル政府システム」の最終プロダクトではなく、それを開発するための「プロジェクトフレームワーク」と「プロダクトプロトタイプ」を開発提供する。
■プロジェクトフレームワーク
アプリケーション製造だけでなく、企画・開発・導入・運用・普及のすべてのライフステージをカバーした「プロジェクトフレームワーク」を提供する。
自治体は本フレームワークを利用することで「安く早く良いシステム」を楽に実現できるものとする。
自治体政府の導入業務を民間サービス業者がオンサイト支援するための「コンサルティング業務フレームワーク」も提供する。
また「ユーザー向けアプリ」については、誰でも自由に提供し、利用できる「アプリマーケット」を運用する。そこでは使用される頻度に応じて、提供者に報酬が入る仕組みを用意する。報酬の財源は自治体や国などの政府予算となると見込まれる。つまりこれが事実上「ユーザー向けアプリ」開発運用の予算となる。想定金額としては、提供者に月額数万円から数十万円の収入が発生する程度とする。
■プロトタイプ
直接的な営利組織ではないため権利や保証、民業圧迫の問題から、本組織では実際に運用するシステムの開発運用には原則的に直接関わることはせず、あくまでプロトタイプの提供までとする。
アーキテクチャは完全オープンとし、モジュールの流用頒布は自由とする。ただし免責とする。
プロトタイプシステムは自治体がサーバホスティング、インプリメント、オーソライズすることで即座に運用可能な完成度とする。
システムは容易にカスタマイズできる仕組みとし、必要な情報はオープンとし「Q&Aサービス」を提供する。
Q&Aサービスは無償から逆入札方式まで用意する。
プロダクト
実際のソフトウェアプロダクトとして以下を開発する。また同時にプロトタイプシステムをサービスするサーバーホストも運用する。
■「egAPI」のフレームワークおよびプロトタイプ
eガバメントセンターシステムのAPIを開発構築するためのフレームワークとそれを利用したシステムのモデルとなるプロトタイプ。
(主にデベロッパ向け)
■「egAPI」アクセッサライブラリ
「egAPI」をWebシステム、モバイルアプリ、Excelなどで簡単利用するための各種アクセッサライブラリ。
(主にデベロッパ向け)
■デジタル政府システム開発プロジェクトのフレームワークおよびプロトタイプ
自治体が発注者となり、「デジタル政府システム開発」をデベロッパにオーダーする際の手順のフレームワークと便利なツールのプロトタイプ。
例えば「egAPI」を設計するためにどのようなドキュメントを集めて担当者にどのようなヒアリングを行うかなどのリストを提供し、それらからAPI設計を生成するシステムとなる。
(自治体向け)
■ユーザーアプリケーションのプロトタイプ
市民、企業、および自治体職員それぞれが利用するアプリケーションのプロトタイプ。
最も一般的でシンプルなアプリケーションとして提供する。
デベロッパはこれを拡張して開発することができる。
(主にデベロッパ向け)
■テストワークフレームワークのプロトタイプ
システム実現の最大最重要の作業要素となる「egAPI」の「テスト」を自治体が行うフレームワーク。
(データ保護のための)ダミーデータの生成や、マニュアルで作業するためのシステム。
一般市民がテストに参加してフィードバックする仕組みと、テスト作業の推進のためにテストワーク参加者に報酬をつけることも可能にする。
(自治体向け)
■アプリ開発プラットフォームのプロトタイプ
直近の「ワクチンパスポート」や「感染者追跡アプリ」のような、緊急のアプリシステムを政府が企画開発運用するためのプラットフォームのプロトタイプ。
要件定義からビジネスモデル設計、製造、検証、実装から運用、普及までトータルにカバー。また各種タスクに業者が入札するプラットフォームも。
■法令条例モデル
コアビジネスモデルとして法令条例をAI学習でプログラム化。
インプットパラメータを抽出し定量化、アウトプットを出力する判断をアルゴリズム化、過去の前例や非言語的な慣例や担当者個人によるブレなどを一旦排除、標準化し、ピュアな「法律プログラム」として作成。
さらにそれで過去の事例をシュミレートしたケースを前例、慣例、担当者のブレなど、さらに本来あるべき判断でパラメータをチューニングする。
マネタイズ
・プラットフォーム使用料
「プロジェクトフレームワーク」「テストマーケット」「ユーザー向けアプリマーケット」「正式APIシステム」など、プロジェクトが運用するプラットフォームの使用量に応じて課金する。
原資は自治体や国の政府予算になると見込まれる。
戦略
本プロジェクトを進めるに当たり、既存大手IT企業や中央政府からの規制妨害が予想される。つまりこれは予め電子化を怠ってきた既成勢力への挑戦となる。
基本戦略は以下の3つとする。
・ボトムアップで展開
・政府関係者や有識者へのコネクションを作り協力関係を構築
・海外展開
1.パイロットモデル自治体キャンペーン
当初いくつかの自治体をパイロットモデルとして、無料から提供する。
同時にシステム検証と学習を目的とし、システムの改善と技術資産の構築も行う。
金額は、システムの完成度に従い、無料から徐々にアップし、”早いもの勝ち”の形にする。
対象は人口1万人以下で、オープンに募集する。
2.ディストリビュータパートナー体制
実際の自治体とプロジェクトを仲介する外部の個人・団体を組織的に募集する。パートナーに対する報酬は「通常決済」と、後払いを行う「ストックオプション」形式を選択できるものとする。
3.ユーザーサポーターパートナー体制
システムを利用する一般市民や企業をサポートする個人・団体を組織的に募集する。
特に問題となる高齢者など情報弱者対応は、パソコン教室などを中心としたサポート体制を構築する。
ロードマップ
1.ミニマムベーシックシステムの開発
2.ディストリビュータパートナー体制の構築
3.パイロットモデル自治体の募集
4.ユーザーサポーターパートナー体制の構築
5.海外のディストリビュータパートナーの募集
6....
この記事が気に入ったらサポートをしてみませんか?