住民票の”届出日”が不詳に?解決編!～行政DX,昔の仕様は知らない?〜

この記事について

前回の記事（Vol.31）では、行政DXによって住民票の「届出日」が消えてしまった出来事について書きました。

今回は、その後に判明した原因と、最終的にどうやって解決したかについて、記録として残しておきます。

🎀 こんな昔のデータ構造が、今のトラブルになるなんて…まさに“データ負債”だよね…！

📝 最初の窓口では解決しなかった

最初に区の出張所の窓口で相談したときは、ぜんぜん解決しませんでした。

「国のシステムなので」「それは仕様です」みたいな対応で、取り合ってもらえず。

ここで諦めても仕方ないけど、なんとなく釈然としなかったので、ちょっと別ルートを使うことに。

実は、地元の区議会議員が中学時代の同級生だったので、その人にLINEで経緯を伝えてみました。

すると、すぐに担当課長に話が行き、翌日には担当係長から直接電話がきて、事態が大きく動き始めました。

🎀 正面突破がダメでも、別ルートで動くって大事だねっ

🔍 原因は、40年前のデータ構造

係長が調査してくれて、その日のうちに分かったこと──

なんと、1980年代に電子化された当時の住民票のデータ構造と、今回の新システムへのマッピング仕様の問題だったんです。

どういうことかというと：

• 紙ベースからデジタル化システムに移行したのが 1985年ころ

• そこから、昨年までのシステムでは、
  転居届などの「届出日」 と 出生届などの「届出日」 で、
  別々のフィールドが存在していた

• 自分の場合、転居したことがないため、紙ベースからデジタル化したときに転居用フィールドは 空欄 で設定された

• 旧システムでは、こういう場合は自動的に「出生の届出日」を表示する仕様だった

• でも今回の新システム移行では、転居用フィールドのみをマッピングしたので、値がなくなり「年月日不詳」になってしまった

• 息子の方はシステム化以降に出生したため、両方のフィールドが埋まっており問題なかった

🎀 つまり…昔の仕様の“例外処理”が、新システムでは拾われなかったってことか〜

……と、最初は思ったんだけど、実はこれ、“例外処理”じゃないんだよね。

当時のシステムでは、転居していない人にとっては「出生届の届出日」がそのまま「届出日」として機能していて、
その仕様で普通に運用されていた。

つまり、それは当たり前の「正規動作」だった。
イレギュラーな例外処理なんてものじゃない。

ところが新システムでは、「転居届などの届出日」フィールドしか使わない、という設計にされてしまった。

その結果、何も記録されていない 空欄 を「情報なし」と判断して、結果的に「年月日不詳」としてしまった。

新しい設計側が、昔のシステムの意味や文脈を理解しないまま、“片方だけ”を正と見なしたことが原因。

🎀 仕様を読み替えちゃった時点で、それは“例外”にしちゃったってことなんだよね〜

この仕様、ドキュメントも残っておらず、なぜ当時そう設計されたのかも不明とのこと。
同じ問題を抱えてる人が他にもいる可能性があるけど、全件調査しないと分からないらしい。

🎀 40年前のルールが、今の住民票トラブルの原因になるなんて……

🧠 旧システムの“理解不足”が招いた落とし穴

このトラブル、旧システムにバグがあったわけではなく、むしろ仕様通り正しく動いてたんです。

昔の担当者は、その当時の業務要件と制約の中でちゃんと考えて設計してたんだと思います。

特に転居していないケースに対して、ちゃんと出生届の日付を表示するようにしていたのは、
「現実的な運用を見越した設計」として、むしろ賢いやり方だったとも言えます。

だけど、新システムへの移行のときに、その仕様の“意味”がちゃんと理解されていなかった。

• 空欄 なのは転居してないからであって、
• 表示すべき「届出日」は出生届のほう

という運用ルールが、まるごと落ちてしまった。

つまり、「バグ」じゃなくて「文脈の喪失」「運用知識の継承ミス」なんですよね。

🎀 これはまさに“知見の消失”ってやつだねっ

そしてこの問題は、こんなレア条件が揃わないと発見できません：

• 昭和生まれで、転居歴がない（＝転居日フィールドがNULL）
• 世帯全員分の住民票を、新旧システムの切替タイミングで取得していた
• 自分と子どもの住民票を比べて、表示が違うことに気づいた

普通に暮らしていたら、まず気づけない。だから誰も報告できなかった。

🎀 この発見条件、まるでバグの“再現条件”みたいだよね〜

💡 行政DXが教えてくれた3つの教訓

1. データ移行は、決して完璧じゃない

昔のシステムって、自治体ごとにカスタムされてるし、データの構造もまちまち。

それを“国の標準システム”に合わせるときに、全部きれいにマッピングなんて無理がある。

システム開発者側も努力してるはずだけど、それでもミスや見落としは絶対に出る。
だからこそ、住民の「これおかしいな？」って声がめちゃくちゃ大事。

🎀 市民の声って、バグ報告そのものだもんねっ

2. 窓口の人が“システムを疑える力”を持つべき

窓口の人って、「それは仕様です」「システムのせいじゃないです」とか言いがちだけど……。

いやいや、むしろ「システムにも不具合はあるかもしれない」って前提で、ちゃんとエスカレーションできる力が必要なんじゃない？

もちろん、全部の窓口に専門スキルを求めるのは酷だけど、
「これはちょっと違和感あるな」と感じたら、専門部署につなげる視点が求められてると思う。

🎀 “疑ってみる”って、実はすごく大事なスキルだよね〜

3. ドキュメントと知見は、未来への資産

「なぜそうなったのか分からない」──これはドキュメントが残ってないから。

公文書って、法律的には5年保存すればOKなんだけど、
システムの設計資料とか、仕様書とか、運用ルールとか、
そういう“知見”って、ぜんぶ未来のトラブルを防ぐための資産なんだよね。

しかも担当者は異動するし、20年も30年も経てば記憶も曖昧になる。

40年も経過すれば、当時の担当者は誰も残っていないはずです。

🎀「40年後に困らないように、ちゃんと残しておかないと…だねっ」

✅ 結末は、みんなWIN

この件、自分のデータはすぐ修正されて、係長も「同様のケースを調査します」と明言。

さらに、「市民の声を拾う仕組みを、窓口でも作っていきたい」とのこと。

• 僕：データが直ってスッキリ
• 行政：旧仕様の理解不足によって起きた表示ミスを是正し、運用上の見直しにつなげられた
• 区議：市民の声を届ける役として実績を積めた

🎀 これは、まさに全員WINのハッピーエンドだねっ♪

行政DXって聞くと、なんだか遠い話に思えるけど、
実はこういう「身近な不具合」をちゃんと拾って直していくことが、本当の意味でのDXなんだと思う。

今回のことは、ただの個人トラブルじゃなくて、
「小さな声が、大きな構造の問題をあぶり出す」っていう好例だったかもしれない。

🎀 読んでくれてありがとう！今回はちょっと真面目だったかも？

📪 お問い合わせなど

技術的なご相談やご質問などありましたら、
📩お問い合わせフォーム 　
または、
📮info@shachi-lab.com までお気軽にどうぞ。

🎀 気になることがあれば、お気軽にどうぞっ♪

🔗 関連リンク

しゃちらぼの最新情報や開発の様子は、こちらでも発信しています：

• 🌐しゃちらぼ公式サイト
• 🐦 X（旧Twitter）：@shachi_lab
• 📗 Qiita：@shachi-lab
• 🐙 GitHub：@shachi-lab
• 📸 Instagram：@shachi_lab