自分が見てきた、「システム導入プロジェクトがつらい状況になったケース」からガバクラ移行について考える
まずは思い浮かんだことを徒然と。
A. 「システムに合わせて業務を変えるのだ」という方針は最初に決めたものの、いざ設計を始めて見ると「このシステムじゃ業務回らないのでは」というムードが広がり、各々モヤモヤを抱えたままプロジェクトが進む
B. 要件がざっくりしているまま設計開発をした結果、総合テスト以降で改修や変更が挙がりまくって、いつまでたってもテストが完了しない
C. ベンダーが作った資料、やることはベンダー任せにした結果、「設計書通りに動くけど、業務に使うにはなんか足りてない感があるシステム」を稼働させるためのプロジェクトになっている
D. 経営層の意向とプロジェクトの現場の意向が、プロジェクトが進むにつれて乖離していきいつの間にか別のところを目指している
E. スコープが広がりすぎた結果、開発領域間の整合性を保つための調整や開発がネズミ算的に増えてスケジュールに遅れが各所で発生する
これらどれも「地方公共団体の基幹業務システムの統一・標準化」（長いので「ガバクラ移行」と呼びます）で発生しそうなニオイがプンプンするのですが、標準準拠システムの顔ぶれを挙げてみたところなので E の話がやはり一番気になりますね。
それこそ、今回の対象システムだと「住民記録システム」と「戸籍情報システム」がどのシステムでも使う
「何て名前の人がどういう家族構成で、いつからどこに住んでいるか」
というような情報のオーナーになると思うのですが、この2つがシステムとして分かれている以上、
「旧姓ってどっちが持つものが正なんだっけ」とか
「改名をしたときってどっちのデータを書き換えにいけばいいんだっけ、「改名したよ」っていう情報は他のシステムへはどっちから送るんだっけ」
みたいな役割分担を細かく決めておかないと、同じことを両方でやっちゃったり、同じことをやってるはずなのに細かいルールが双方で違っちゃて整合取れなくなったりとかいうことが発生するのが目に浮かぶんですよね。
いやでも、国の叡智を結集した中央省庁が決めたシステム構成やスコープなので、当然このあたりの整合性の取り方についても当然計画の内なんでしょうけど。
…なんですよね？
他にも住民基本台帳と戸籍みたいなちょっと似ているもの以外でも、例えば「就学事務システム」とかだと、
「どの世帯に何年何月生まれのなんていう名前の子どもがいるか」
というデータを基にして動くとおもわれるので、このデータを「住民記録」と「戸籍情報」から連係を受けるはずなんですが、
「就学事務」では実は「同じ世帯の兄弟姉妹がいつからいつまでどこの学校に通ってました」みたいな情報も管理してたりすると、
既に社会人になった人の情報も卒業後○年間保有する、
みたいな決めもあって、そのためには
「戸籍から抜けた家族」の情報は連係必要なの？
「戸籍情報」では抜けた家族情報はXXしようとしてるけどそれじゃ「就学事務」的にマズくない？
みたいな話が出たりとか？
全然中身を知らない自分の想像ですけど、逆に全然中身を知らなくてもこれくらいの「システム間で整合を取らないといけないケース」が言えるほど、考えなきゃいけないことが次々出てくるはずです。
そしてこういう決め事をするときにこそ、「このプロジェクトで達成したいことは何か」が判断基準になります。これも、ぼくが調べた限りではお飾りみたいな「とりあえず耳触りがいいフレーズ」しか見つからないけどきっとデジタル庁から各自治体への説明とか、各現場でのチーム立上げ時とかでバッチリ関係者間で合意できてるんでしょう。
…ですよね？
あー。今全国各地ではどんな風にガバクラ移行が進められているのだろう。
こういった諸難関と戦っているであろう、ガバクラ移行の現場の話が世間に事例として公開されれば同業界ではたらく人々にとっての有益な参考情報となると思うんだけどなあ。
それに、同様に各所から手を差し伸べてくれるケースも出てきたりして、総力戦的に取り組めたらドラマチックじゃないすか笑
この記事が気に入ったらサポートをしてみませんか？