GovTech失敗から学ぶ“制度化された学習”の作り方：成功と挫折を次に活かす仕組みとは

どうも〜おかむーです！今日はGovTechの成功例と大失敗から学んで、「失敗を制度化して次に活かす」ための実務的な方法を紹介しますよ〜

• 政策も技術も「振り返り」を仕組み化しないと同じ失敗を繰り返す
• エストニアのX-Road的な技術は有効だけど、ガバナンスと開示が肝
• 日本は技術力あるけど、プロジェクト後の学びを国レベルで回す仕組みが弱い

結論

失敗事例を単なる「反省会」だけで終わらせず、制度として残すことがGovTechの最短距離。具体的には「公開ポストモーテム」「失敗レジストリ」「標準化された技術モジュール」「段階的資金解放」の4点を組み合わせると効果的です。

レポート本文

失敗から見える共通パターン

ぶっちゃけ、政府ITの大失敗って似たような原因が並んでます。英国のFiReControlはNAO報告で少なくとも4.69億ポンドが無駄になったとされ（参照: NAO report）、要因はスコープ膨張・ガバナンス欠如・利用者不在の設計。Prismやその他の案件も同様で、外注先と政府の期待値ズレが根本にあります（参考: Vanguard, ThirdStageまとめ）。

真面目な話をすると、技術的失敗よりも「運用と意思決定の仕組み」が壊れていることが多いんです。

成功事例から学ぶ“学習ループ”の設計

エストニアのe-Estoniaは技術（デジタルID、X-Road）だけじゃなく、継続的な改善と透明性で信頼を作ったのが鍵（参照: e-Estonia）。僕がシンガポールにいた頃も感じたけど、技術は布石で、運用ルールと市民の信頼が本丸です。

成功する国に共通する要素:

• 標準化されたAPIとデータスキーマ（要するに皆が同じ言語で話せる）
• フェデレーション型のデータ交換（X-Roadのようなモデル）
• 公開されたポストモーテムと学びのカタログ
• 小さく速い反復（MVP→スケール）

技術的に押さえるべき要素（実装寄り）

• API：REST/GraphQLで仕様を標準化、OpenAPIで契約化
• ID：OpenID Connect / eIDAS相当のアイデンティティ戦略
• データ基盤：データカタログ＋メタデータ、行き先追跡（provenance）
• セキュリティ：TLS、細粒度RBAC、KMSによる暗号鍵管理
• インフラ：クラウドネイティブ（IaC、CI/CD、コンテナ）、SRE体制
• 監査性：監査ログの改ざん防止と公開可能なサマリ（市民向け）

要するに、失敗を防ぐには技術も大事だけど「再現可能な実装パターン」と「運用ルール」を両方用意する必要があるということです。

制度化された学習の具体策（政策設計）

公開ポストモーテム義務化：一定規模以上のプロジェクトはポストモーテムを公開し、技術的判断・調達判断を明記

失敗レジストリ：何が失敗したのか、再発防止策は？を検索可能にしてナレッジ化

段階的資金開放とガードレール：MVP評価で次フェーズ資金を出す

標準モジュールの整備と再利用契約：認証・決済・通知などを中央で提供

民間と学ぶ場（サンドボックス／実証実験）：失敗を低コストで経験できる環境

これ、すごくないですか？特に公開ポストモーテムは透明性も生むし、事後処理のコストを下げます。

日本への示唆：今ある強みと穴

強み：エンジニア資産とマイナンバー等の基盤データがある。ぶっちゃけ、技術的にはやれるんです。

穴：地方自治体間の非互換性、調達文化、失敗を許容しない政治的な雰囲気。例えば、技術要件が細かすぎてベンダー任せにならないケースや、失敗の公的評価が抑制されると学びが残らない。

実務的提言：

• デジタル庁は「失敗の公的アーカイブ」を作るべき
• 中央は再利用可能な技術モジュール（認証・データ連携）をSaaSで提供
• プロジェクト評価にUX定量指標（市民のタスク成功率）を入れる

まとめ

失敗を減らす最短ルートは「技術の完璧さ」じゃなくて「学習を仕組み化すること」。公開ポストモーテム、失敗レジストリ、段階的資金開放、再利用モジュール──この4つを組み合わせれば、無駄金を減らしながら実行速度を上げられます。

おかむーから一言

僕は起業してプロダクトを何度も作って壊して直してきました。GovTechも同じで、仕組みとして“失敗から速く学ぶ力”を作ることが国家の競争力になるはず。日本、まだまだイケますよ！