はじめに
この記事は、芽室町の MADO / MADO-queue に関する以下の記事を読んだことをきっかけに書いています。
自治体がVibe Codingで「書かない窓口」を内製し、OSSとして公開した理由
https://note.com/memuro_dx_oss/n/nf982351d30ef
MADO-queueをDockerで動かす〜 現場の窓口で本番稼働している番号発券システムを、自分の手元で立ち上げる 〜
https://note.com/memuro_dx_oss/n/ncf31d9f148f9
AIで内製した自治体システムの、これからの課題
https://note.com/memuro_dx_oss/n/nb0d5871aa78c
MADO-queue は、自治体の窓口で使われる番号発券・呼出系のシステムです。職員の方が内製し、実際の業務で使われ、さらに OSS として GitHub 上に公開されています。
この3本を読んで私が強く気になったのは、MADO-queue が「よくできた職員内製システムである」という点だけではありません。
むしろ、個人の工夫として始まったものが、実際の窓口業務で使われ、OSSとして公開され、外部からIssueやPull Requestを受け取れる状態になったとき、そのシステムを自治体としてどう受け止め、どう管理対象にしていくのか、という点です。
これは、単にコードを直せば済む話ではないと思っています。
誰が管理するのか。
誰が判断するのか。
どの変更ならメンテナー判断で扱えるのか。
どこから庁内確認が必要なのか。
外部からの提案を、どうすれば本家側の負担を増やさずに判断材料へ変換できるのか。
このあたりが曖昧なままだと、せっかくOSSとして公開されても、外部からの支援がそのままメンテナーの負担になってしまう可能性があります。
私がMADO-queueにIssueを書いているのは、そこに課題感があるからです。
私は MADO-queue のメンテナーでも、芽室町の意思決定者でも、委託事業者でもありません。外部の個人コントリビューターとして、Issue整理、確認観点の提示、判断材料化といった形で関わっています。
この記事は、職員内製システムを自治体の管理対象にしていくには何が必要かを考えると同時に、私が MADO-queue に Issue を書くとき、どういう考え方で論点を切り分けているのかを、あとから読める形にしておくためのものです。
この事例を見ていて、単なる「便利なシステムを作った」という話ではなく、もう少し大きな問いがあると感じました。
それは、職員内製で始まったシステムが、職場で使われ始めたあと、どの時点で、どのように自治体の管理対象になっていくのか、という問いです。
個人制作から、業務システムへ
職員内製システムは、多くの場合、最初から大きな調達や正式なプロジェクトとして始まるわけではありません。
現場で困りごとがある。
既存の仕組みでは対応しにくい。
そこで、技術に詳しい職員が小さく作る。
使ってみたら便利だった。
周囲にも使われるようになる。
この流れ自体は、非常に健全だと思います。
現場を知っている人が、現場のために作る。
大きな予算や調達を待たずに改善できる。
業務理解と実装が近い。
これは、職員内製の強みです。
一方で、そのシステムが実際の業務で使われ始めると、性質が変わります。
最初は個人の成果物だったものが、いつの間にか業務上必要な仕組みになる。
担当者が異動したらどうするのか。
障害が起きたら誰が対応するのか。
バックアップはあるのか。
引継ぎはできるのか。
外部から修正提案が来たとき、誰が判断するのか。
この段階になると、単に「作った人が分かっているから大丈夫」では済まなくなります。
OSS公開は目的ではなく、手段
MADO-queue の面白いところは、職員内製システムが OSS として公開されている点です。
OSS として公開されることで、外部の人がコードを読めるようになります。Issue を立てられます。改善案を出せます。Pull Request を送れます。実装や運用について、外部から確認することもできます。
これは、自治体にとって大きな可能性があります。
ただし、OSS公開そのものがゴールではありません。
OSS にしただけで、保守体制が完成するわけではありません。
GitHub に置いただけで、情報資産管理が済むわけでもありません。
外部から Issue や Pull Request が来ても、それを庁内でどう扱うかが決まっていなければ、判断の負荷はメンテナー個人に集中します。
つまり、OSS公開は強力な手段ですが、それだけでは足りません。
必要なのは、GitHub 上の開発・保守の流れと、自治体内部の情報資産管理・業務システム管理の流れを、無理なく接続することだと思います。
2つの管理トラック
この種のシステムには、少なくとも2つの管理トラックがあります。
1つ目は、GitHub上のOSSとしての管理です。
Issue をどう扱うか。
Pull Request をどう確認するか。
PATCH / MINOR / MAJOR の変更をどう分けるか。
タグや Release note をどう残すか。
CONTRIBUTING.md や SECURITY.md をどう整備するか。
メンテナーがどこまで判断できるか。
これは、OSSプロジェクトとしての運用です。
2つ目は、自治体の情報資産・業務システムとしての管理です。
管理部署はどこか。
管理責任者は誰か。
運用部署はどこか。
バックアップや復旧はどうするか。
障害時対応はどうするか。
異動時の引継ぎはどうするか。
情報資産台帳にどう載せるか。
監査や庁内決裁の対象になるのか。
これは、自治体内部の管理です。
この2つは別物です。
しかし、完全に切り離すこともできません。
GitHub 上では軽微な修正に見えても、実際の窓口運用に影響する場合があります。
逆に、庁内で毎回重い確認を必要とすると、OSSとしての小さな改善が止まってしまいます。
だからこそ、両者を混ぜすぎず、しかし接続点を作る必要があります。
外部提案を、庁内で判断できる形にする
私がIssueを書くときに意識しているのは、外部から見えた論点を、そのまま大きな問題提起として投げないことです。
「これは大事そうです」と書くだけでは、本家側は判断しにくい。
「こうすべきです」と書きすぎると、外部から方針を押し込んでいるように見える。
一方で、何も書かなければ、外部から見えている運用上の論点は共有されません。
そのため、Issueではできるだけ、今判断できる大きさに論点を切ります。
本家側が採用、保留、追加確認、対象外のどれかを選びやすい形にする。
庁内確認が必要な話と、GitHub上で扱える話を混ぜない。
メンテナー個人の責任を重くするのではなく、判断材料を軽くする。
私がIssueを書いている理由は、外部から正解を提示したいからではありません。職員内製システムがOSSとして公開されたあと、外部からの関与をどうすれば継続運用の助けにできるのかを、実際のIssueの形で確かめたいからです。
外部コントリビューターができることは、単にコードを書くことだけではありません。
むしろ、自治体OSSでは、外部提案を「判断しやすい形」にすることが重要だと思います。
たとえば、Issue で次のような点を整理します。
この変更は何を改善するのか。
既存運用に影響するのか。
画面表示だけの変更なのか。
データ構造や業務フローに影響するのか。
PATCH 相当の軽微な変更なのか。
庁内確認が必要な変更なのか。
複数人の確認が取れているのか。
Release note に残せば後から追えるのか。
こうした整理があると、メンテナーは判断しやすくなります。
重要なのは、メンテナーに責任を押し付けることではありません。
むしろ逆です。
判断材料を軽くし、論点を小さくし、後から説明できる形にすることで、メンテナー個人の負担を減らすことができます。
PATCH相当の変更をどう扱うか
たとえば、既存運用への影響が小さく、表示修正や軽微な不具合修正にとどまる変更があります。
こうした変更まで、すべて同じ重さで庁内確認や責任者決裁に載せると、運用が重くなります。
一方で、軽微だからといって、何も記録せずに取り込むのも危険です。
そこで、PATCH相当の変更については、次のような整理が有効ではないかと思います。
既存の業務フローを変えない。
データ構造を変えない。
運用部署の判断を必要としない。
Issue 上で変更理由が説明されている。
可能であれば、複数人の見解が一致している。
マージ後は v1.0.1 のようなタグや Release note に残す。
こうしておけば、メンテナーが判断できる範囲を増やしつつ、判断が属人的になりすぎることを防げます。
また、あとから「どの変更がどの版に入ったか」を追いやすくなります。
これは、単に開発者向けの便利機能ではありません。
自治体の説明責任にもつながります。
責任可読性という考え方
この話で重要なのは、「誰が責任を取るのか」を抽象的に問うことだけではないと思います。
むしろ、後から読んだときに、判断の流れが見えることが重要です。
誰が提案したのか。
誰が確認したのか。
何を根拠に PATCH 相当と判断したのか。
どこから庁内確認が必要になるのか。
どのバージョンに入ったのか。
Release note に何が残っているのか。
こうした情報が読める状態を、ここでは「責任可読性」と呼びたいです。
責任可読性があると、メンテナー個人に過度な負担をかけずに済みます。
外部コントリビューターも、自分の提案がどう扱われるかを理解しやすくなります。
庁内の人も、あとから経緯を追いやすくなります。
自治体OSSでは、この責任可読性がかなり重要になるのではないかと思います。
職員内製システムは、いつ自治体の情報資産になるのか
最終的に問うべきことは、ここだと思います。
職員が作ったものは、いつまで個人の成果物なのか。
職場で使われ始めた時点で、自治体の業務システムなのか。
窓口業務に組み込まれた時点で、情報資産台帳に載せるべきなのか。
OSS公開された時点で、外部との接点を持つ自治体システムとして扱うべきなのか。
これは、MADO-queue だけの話ではありません。
今後、自治体の中で小さな内製システムは増えていくと思います。
ノーコード、ローコード、生成AI、スクリプト、簡易Webアプリなど、職員が自分たちで業務改善する手段は増えています。
そのとき、すべてを大規模な調達案件として扱うのは現実的ではありません。
一方で、便利だからという理由だけで、個人管理のまま業務利用が広がるのも危険です。
必要なのは、個人内製から組織管理へ移すための、中間的な運用モデルではないかと思います。
おわりに
MADO-queue の取り組みは、職員内製、自治体OSS、GitHub上の外部貢献、庁内の保守・引継ぎ・情報資産管理が一つの事例の中でつながっている、非常に興味深い事例だと感じています。
この記事では、職員内製システムを自治体の管理対象にしていくには何が必要かという観点から、MADO-queue を題材に考えてきました。
あわせて、私が MADO-queue に Issue を書くとき、どういう考え方で論点を切り分けているのかも整理しました。
大事なのは、外部から大きな理想論を押し込むことではありません。
本家の負担を増やさないこと。
Issue を小さくすること。
判断材料を軽くすること。
必要以上に Pull Request を押し込まないこと。
庁内確認が必要な論点と、メンテナー判断で扱える論点を分けること。
そのため、Issueを書く側にも、論点を小さくし、判断材料を軽くし、どこから庁内確認が必要になるのかを分ける意識が必要だと考えています。
その積み重ねの先に、職員内製システムを自治体の管理対象として継続運用していくための、現実的なモデルが見えてくるのではないかと思います。