標準準拠は運用の勝負！自治体向け「開発者オンボーディングKIT」で現場を動かす

どうも〜おかむーです！今日はちょっとエンジニアっぽい話をしますよ〜。

• 地方公共団体の「標準準拠システム」は法律で求められているが、現場の導入ハードルが高い
• エンジニア視点では「ドキュメント＋モック＋CI」があれば採用が一気に進む
• だから今回は『開発者オンボーディングKIT』という実践的なテンプレートを提案します！

結論

標準化省令（地方公共団体の基幹業務システムの統一・標準化）を現場で実効化するには、単に仕様を出すだけじゃなく、開発者が即動けるキットを提供することが鍵。要するに「ドキュメントだけで止めない、コードで動かす支援」を国と自治体が共通で用意すべきです。

レポート本文

背景（法令と現場のギャップ）

デジタル庁の取り組み（https://www.digital.go.jp/policies/local_governments）や法令（https://laws.e-gov.go.jp/law/503AC0000000040）で、標準準拠システムが求められているのは周知の事実です。ただ現場を見ると、仕様書（PDF/HTML）だけ渡されて「さあ移行してね」になりがち。エンジニア的に言うと、これではオンボーディングコストが高くて誰も手を出さないんですよね。

これ見てくださいよ：Japan Dashboard（https://www.digital.go.jp/resources/japandashboard）やe-Stat（https://dashboard.e-stat.go.jp/）は良い例で、データ公開の成果を見せてる。一方で地方の基幹システム移行は“見える化”されていなくて、進捗や導入率のKPIがデータとして追えない。

問題点を技術的に整理

• ドキュメントが人間向け（PDF・長文）で機械可読性が低い
• モックAPIやサンプルデータがないため開発着手が遅れる
• テストスイートやCIが共有されておらず、準拠判定が属人的
• 採用状況の定量KPI（何自治体が準拠したか）が公開されていない

要するに、現行は"仕様の配布"に留まり、"実装可能性の担保"が不足しているということです。

提案：開発者オンボーディングKITの中身（実装レシピ）

小さくて使えるキットを自治体向けに公式で配布するイメージ。中身は次の5点。

OpenAPIベースの仕様テンプレート（YAML）

JSON Schema / CSVスキーマのサンプル

モックサーバ（docker-compose）とサンプルCSV/CSV→JSON変換スクリプト

Contract Test（例：PACT / pytest + requests テスト）

CIテンプレート（GitHub Actions）と導入手順ドキュメント

エンジニア的に言うと、API一つをスタブで立ち上げてしまえば、自治体側も住民向けサービス事業者も並行して開発できます。要するに「API一本で解決する話なんですよね」ってことです。

簡単なコード例（OpenAPI & モック起動）

openapi: 3.0.0
info:
title: resident-api
version: '1.0'
paths:
/residents/{id}:
get:
parameters:
- name: id
in: path
required: true
schema:
type: string
responses:
'200':
description: resident
content:
application/json:
schema:
$ref: '#/components/schemas/Resident'
components:
schemas:
Resident:
type: object
properties:
id:
type: string
name:
type: string

このYAMLを使って、wiremockやPrismなどでモック立ち上げ→CIで契約テストを回す流れをテンプレ化します。

テスト例（pytest風）

import requests

def test_get_resident():
r = requests.get('http://mock:8080/residents/123')
assert r.status_code == 200
data = r.json()
assert 'id' in data and data['id'] == '123'

政策KPIの設計例（数値目標と実績の追い方）

国が示すべきは単なる「準拠義務」ではなく、可観測なKPI：

• 準拠率：全国自治体に対する標準準拠システム稼働割合（%）
• 開発開始リードタイム：仕様公開からモック起動までの平均日数
• CI通過率：提出された自治体リポジトリでの自動テスト合格率

現状は実績公開が乏しいので、Japan Dashboardのような仕組みでKPIを可視化することを提案します。

導入負担を下げる運用設計

• テンプレリポジトリ（GitHub / GitLab）を公式で公開してフォークさせる
• 3ヶ月のパイロット補助金と技術支援窓口を併設
• 公式モックサーバ（短期のSaaS）を用意して、ローカルでの起動を不要にする

これで小さな自治体でも短期間に「動くもの」を持てるようになります。

まとめ

• 仕様公開だけでは現場は動かない。コードと環境をセットで渡すことが重要
• OpenAPI＋モック＋CIのKITがあればオンボーディングコストは劇的に下がる
• KPIを公開して進捗を可視化することで、法令の実効性が担保される

おかむーから一言

テクノロジーは人を動かすための道具なんです。仕様書だけ渡して「さあやれ」は無理ゲー。コードで走るテンプレを用意して、現場と国が一緒に走る仕組みを作りましょう！

---

参照：

• 地方公共団体の基幹業務システムの統一・標準化（デジタル庁）: https://www.digital.go.jp/policies/local_governments
• 地方公共団体情報システムの標準化に関する法律（e-Gov）: https://laws.e-gov.go.jp/law/503AC0000000040
• Japan Dashboard（デジタル庁）: https://www.digital.go.jp/resources/japandashboard
• 統計ダッシュボード（e-Stat）: https://dashboard.e-stat.go.jp/