自治体業務システム標準はなぜホワイトリスト方式なのか

自治体業務システムの標準化ではいわゆるホワイトリスト方式が採用されている。厳しすぎるとの意見もあるホワイトリスト方式だが、なぜそうしなければならないのか改めて説明しておきたい。

ホワイトリスト方式

自治体業務標準化検討の極初期のころ、標準仕様はホワイトリスト方式であるべきだと主張したのは僕なので、今一度ちゃんと説明しておきたい。
ここで言うホワイトリスト方式とは標準仕様では各システムが持たなければならない機能を決めるだけではなく、”仕様に定められた機能以外は持ってはいけない”と定める方式だ。結果、必要となる機能はすべて仕様に列挙しなければならなくなり、仕様が膨大になるのではとの批判がある。
自治体ごとの要望を取り上げようとすると膨大な仕様になるとの批判は、標準化のそもそもの趣旨からして的はずれなわけだけど、それでもなぜここまで厳しくする必要があったのかだ。

標準としての実効性がなくなる

1つ目の理由がホワイトリスト方式にしなければ標準としての実効性がなくなってしまうということだ。
業務標準化では既存の各社パッケージソフトウエアの機能比較から標準として採用すべき機能が精査されている。もし、実装必須の機能だけを定める仕様にしてしまうと、全てのパッケージが持っている機能だけ標準として採用すれば全てのパッケージが”すでに”標準に準拠した製品ということになってしまう。これでは標準仕様としての意味をなさない。
実際にはそんな極端なことにはならないだろうけど、”標準化する”という意義からして無難なところだけ必須機能にして逃れるという骨抜きになる危険性を大きくはらんでしまう。

カスタマイズ禁止にならない

2つ目の理由がカスタマイズ禁止にならなくなってしまうことだ。
標準化の大きな目的がカスタマイズを禁止することにある。ではなぜカスタマイズが起こるのか。それは自治体視点からすればパッケージに機能が不足しているからだ。不足してるから強化しろとなる。
その発想自体を否定しようといのが今回の標準化の取り組みであり、標準化された機能で満足しなさいという限定となっている。
しかし、もし標準機能以外を持っても良いとなれば、自治体から
「そもそも必要な機能が不足しているパッケージが悪い。カスタマイズではなくパッケージの本来機能として実装せよ」
という要望がでかねない。これでは実質カスタマイズしてることと変わりなくなってしまう。
実際、標準仕様には実装必須のものとベンダの判断で実装してもしなくてもよいオプション機能があるのだが、某省の検討途中には
「オプション機能については自治体が要望すればベンダーは実装しなくてはならない」
という規定が入りそうになったことがあるくらいだ。(廃止したけど)

厳しいかもしれないけど

以上のように、厳しいかもしれないが標準仕様を実効性あるものとし、カスタマイズを厳密に禁止する上ではホワイトリスト方式は必須となる。
全国の自治体業務システムが一斉に標準化されるなどという取り組みは前代未聞だけど、2040を乗り切るためにはどうあっても実現しなければならない最後のチャンスでもある。地方自治を守るため、この厳しさをなんとか受け入れ、長期的な視点で必要な取り組みを実践願いたい。