ガバクラ移行後の「住民票データ」が各システム間をどう渡り歩くのか想像して、要点を挙げてみる…というチャレンジ
サムネ写真は、昨年11月に購入したFender社のSanta Ana overdrive というギターエフェクターの設定値メモです。
記事内容とは一切関係ありません。
住民記録システムの標準仕様書を読んでみる
さて、とんでもないスコープの業務・システムを扱うガバクラ以降のプロジェクトですが、やっぱり全体の中でコアとなるデータは「住民記録データ」だと思ったので
それを管理する住民記録システムを中心にしてデータのIn／Outはどんなものなのかを想像の範囲で超概略の図にしてみました。
参考にしたのは住民記録システムの標準仕様書です。
（ページ数膨大なので全部は目を通せてないけど）
https://www.soumu.go.jp/.../jich.../02gyosei02_04000147.html
要件としてベンダーに提示するにも、関係者と認識を合わせるにも、
何よりも己の理解のためにも、こういう「モデル化」っていうのは必要ですし
なんと言ってもおもしろいですよね。
そして、約10年間いろんな業種のお客さんのシステム刷新や導入のプロジェクトに端役ながら参画してきた自分として、4つくらい、標準仕様書を元にベンダーと設計をする際にリソースを割いて早めに決めておいた方がいいテーマがあるんじゃないかなと考えました。
以下数字①〜④は画像中の数字と対応しています。
①ユーザーへのホスピタリティのレベル感（＝使用性）
住民からの申請内容の審査とシステムへの入力が、業務のボトルネックになってしまわないような入力機能（自動入力とか、エラーチェック、一括登録／修正）が必要だけど、作り込みすぎるとテストも運用保守も大変。
「どこからどこまでをシステムでやるのがコスト最適か」の基準を明確にした方がいい。
もっというとこういう話は標準仕様書に含めて欲しいけど、あるのかな。（←全部目を通していない）
標準仕様書にないのなら、少なくとも、「うちの使うシステムではこう」をRFPに載せたいですね。
②ユースケースに基づいた機能の棲み分け
「このシステムとあっちのシステムで、同じ項目なのに内容が違う…」
を起こさないためにもシステム間の役割分担を「使い方レベル」で決めた方がいい。
住民記録システムを例にすると、標準仕様書に記載されてる保有項目は170近く。（もっとあるかも）
例えば「住所」なんて、最初の登録先は住民記録システムなんだろうけど、
あらゆる業務に使う項目だから他のシステムへも受け渡しがされるはずで、
じゃあもし「税務システム」の方で納付通知書とか送付の都合で、住民記録の住所とは違う住所を使いたかったら、それの情報を税務側で同じ項目に上書きしちゃうとまさに上記の状態が発生するわけで。
「こういう業務（情報の追加更新）がありうるけど、それってどのシステムでどうやるんだっけ」→「その為には、実はこっちのシステムでのみ更新、利用するxxマスタと登録画面も用意しとかないとヤバくない？」
という決めをしておかないと、たぶんベンダー側ではそういうユースケースチックな要件はわからないし、各システムで整合取るべきトコロと実はそうでないトコロが誰にもわからなくなって開発もテストも超大変になりそうだ。
③ジョブのスケジューリング
他システムとのデータ連係はジョブ起動にするんだろうけど、
その他システム毎のバッチ処理も含めたジョブスケジュールって結構自治体毎に違いがあるのでは？
これまでは別々のサーバで動かしていた各システムを一つのクラウドサーバに集めたことで、「ジョブ設計」の複雑さと重要度がグッと上がるはず。
「ガバメントクラウド移行後の想定ジョブスケジュール（順番だけでも）」
を業務側が積極的に提示できたらサイコー。
てかもうこの際だからジョブの基本スケジュールも標準としてデジタル庁なりが示してくれた方が、自治体側としては助かるんじゃないかな。
④インターフェースの統合と共通化の方針
住民記録システムを発信元としてインターフェースするデータの内容は、大きく分けて
「個人番号（マイナンバー）を含むか／含まないか」
「日本人住民のデータか／外国人住民のデータか」
に区別できるように見えるので、
「XXシステムに送る項目はあれとこれとそれで、、、」
「△△システムにはこれとこれだけにして、、、」
とかいうような連係先システム毎のI/F設計するんじゃなくて、
・マイナンバーありI/F（日本人住民）
・マイナンバーありI/F（外国人住民）
・マイナンバーなしI/F（日本人住民）
・マイナンバーなしI/F（外国人住民）
みたいに大きな違いを軸にしてある程度共通化した
I/Fを用意して、開発本数を減らす、受けるシステム毎に不要な項目は捨てて必要なものだけ取り込むように受け口の方をイジる、という思想を採用したらなんか問題あるのかな。
これはさすがにざっくり過ぎるとも思うけど、とにかくこういう、開発／テスト工数を減らす方針決めした方がいいと思う。
外からじゃわかること少ないけど、やっぱ基幹業務システムのプロジェクトは出だしの決め事で後工程の大変さが1/3にも30倍にもなりうるというのが今回も当てはまるだろう
今日もまた一人でガバクラ移行のプロジェクトのイメージトレーニング？みたいなことをしました。
ぼくなんかよりもっと知識も経験もある人なら他にも検討テーマや、それへの良い案とかもポンポン出るんでしょうけど。
今日はこのくらいにしといたるわ…（震え声）
ガバクラ移行の現場では今どんなことをしてるんだろうか。
25年度末までが移行（切替）完了の期限だから、そろそろどこもベンダー選定を終えて設計に入りつつある頃か、それともまだ「標準仕様書」を噛み砕いて自分たちとしての要件を整理しているところか。。。
一つ言えることは、↑に挙げた四つみたいなことを早めに決めるのに有識者の時間を最初にしっかり割いておいた方が絶対後で助かるよってことかなあ。
設計書を100個書くより、設計の前提（方針）をパワポ数ページで明確にする方が半年後のプロジェクトメンバーにとって有益である