仕様書だけが降ってきた――「自治体システム標準化」で現場の混乱を招いた“完成図なき改革”（5/6 ページ）

「自治体システム標準化」と「ガバメントクラウド移行」を巡り、自治体の現場では人手不足、想定外のコスト増、移行遅延、責任の所在の不明確さ――といった深刻な混乱が広がっている。CIO補佐官として、現場で取り組みに関わってきた筆者が「マネジメントの視点」から事業について考える。

[川口弘行，ITmedia]

仕様書は変わり続け、現場は疲弊する

　プロジェクトは、Q：Quality（品質）、C：Cost（費用）、D：Delivery（納期）に加えて、S：Scope（プロジェクトの範囲）で構成されています。プロジェクトがうまく進まない場合は、「Sの見直し」（範囲を小さくすること）が求められますが、政府はその取り組みをしていません。

　政府がやっていることは、完全にその逆でした。

　実は標準仕様書は、凍結されていません。住民記録システムで言えば、第1版は2020年9月に公表されましたが、その後の度重なる改版に伴い、現時点での最新は2025年8月の第6.1版です。マイナーバージョンを含めると半年に1回程度の頻度で改版がされています。

　システム標準化の対象業務は20業務あるため、同時並行的にそれぞれの標準仕様書が現在も変動し続けています。

住民記録システム標準仕様書【第6.0版】等の公表（総務省ホームページ）

　この間に国会議員選挙などもありました。各党が公約として掲げた現金給付、子ども子育て関連の支援施策などを実現させるためのシステムの機能追加要望があり、毎年の税制改正に伴う各種計算ロジックの変更など、事業者側ではシステム開発している横から違う仕様が挟み込まれる、という様子が容易に想像できます。このシステム改修は現在稼働中のシステムにも適用する必要があるので、作業量は単純に2倍になります。

　これらの標準仕様書は、「自治体システム等標準化検討会」が策定しています。この検討会の中で「仕様凍結しないとプロジェクト成功は不可能である」という強い意思を持って政府に答申していれば、もう少し状況は変わったのかもしれません。現在の混乱を招いた要因の一つはここにもあります。

　どんどんS（プロジェクトの範囲）の範囲が広がっているのであれば、さらにこのプロジェクトの難易度が高くなるのは容易に想像できますね。このように「政策として仕様凍結する努力を怠った」というのが、5つ目のボタンの掛け違いです。

　「アジャイル型ならば、どんどん変化していく仕様に追随していくべきなのでは？」という意見もあるかもしれません。

　しかしアジャイルの場合でも、一定期間はプロジェクトの範囲を固定し、その期間内でゴールに向け完成させることを繰り返します。完成を待たずにプロジェクトの範囲を変化させることはありません。つまり一連の施策はアジャイル型ですらなかったのです。

　ただ、税制改正は毎年のように行われていますし、国保や年金などの制度も頻繁にルール変更があることは承知しているため、どうしても制度やシステムに手を加えざるを得ない事情があることは理解できます。

　もし、3つ目のボタンの掛け違いである「標準システムそのものを政府が作らなかった」という問題が解消されており、政府主導で個別業務ごとや自治体の規模ごとに全国の事業者が分担して標準システムの開発に取り組めていたなら、開発リソースの無駄な重複や分散を防ぎ、プロジェクト自体の成功確率も今より高かったのではないかと思います。

　国家プロジェクトとは本来そうあるべきだと筆者は考えていますが、実際にはそのような形にはなりませんでした。これは現行の事業者による強い抵抗があったためでしょうか。もしそうであれば、政府は全体を見通せていなかったことになりますし、事業者側の経営判断も甘かったと言わざるを得ません。