自治体業務システム標準化キソ（Fit＆Gap編）

すでに基礎でもなんでもないですが、自治体業務システム標準化で極めて重要なFit&Gap作業について、あくまで、私見を申し上げようと思います。
自治体業務システム標準化キソのキソ、自治体業務システム標準化キソ（独自施策編）に続く第三弾です。

Fit＆Gapとはパッケージ機能に合わせるための整理

Fit＆Gapは標準仕様との比較ではない
Fit&Gapは現行システムベンダーの標準対応パッケージとの比較である

結論から言ってしまうと、自治体業務システム標準化における、少なくとも2025年度までの作業では、Fit＆Gapとは”現行システムベンダーの標準対応パッケージを前提に、それでどうやって業務を回すかを検討する行為”である。

通常の説明ではFit&Gapは”標準仕様（標準化基準）と現状業務手順との比較”と説明される。それはもちろん間違いではない。ただ、あくまで新規にパッケージを選定し、同時に精緻なBRPを実施する前提において正しい。残念ながら2025年度の対応では人的にも時間的にもその余裕はない。現実解は現行システムベンダーの標準対応パッケージを導入し、最低限のBPRで対応することだ。
するとFit&Gapとは”現行システムベンダーの標準対応パッケージを前提に、それでどうやって業務を回すかを検討する行為”となるわけだ。以下、なぜそう考えなければならないのかもう少し詳しく見ていきたい。

標準化の効果と標準化範囲

標準化によってパッケージのバリエーションは数十分の一になる
ただし、標準化対象事務範囲以外は引き続き自由
Fit&Gapでは標準化範囲だけでなく範囲外も考慮する必要がある

自治体業務システムは標準化された。とはいえ、後述の通りパッケージには機能差が容認されており、全く統一されるわけではない。では効果はないのか。
機能差があると言っても個々のベンダーからすれば複数のパッケージを開発する余裕はない。標準対応パッケージのバリエーションは一ベンダーあたり一つかせいぜい二つ三つだろう。つまり機能差のバリエーションは開発するベンダー数＋αにまで絞り込まれる。
現状1700通りといえば言い過ぎだが、細かい違いを入れれば数百通りあるであろうパッケージ実装から考えれば数十分の一に集約される。

ところで、この時、標準化されるのは標準化法に定められた特定の事務（標準化対象事務）だけだ。そのほかは従来通り自治体の自由とされている。しかも、標準化対象事務と標準化対象外事務の機能をあわせ持つオールインワンパッケージの提供は引き続き認められる。

現状、このような一体的パッケージを利用して事務を行っている団体からするとFit&Gapの対象は標準化対象事務に限定されたものとはならない。現状の機能範囲全体に対して、標準化後の姿がどのようになるのか想定し、全体を見通して違いを分析する必要がある。

パッケージ導入におけるFit&Gap

従来のFit＆Gapはパッケージ選定やカスタマイズが目的
標準化する際のFit&Gapはパッケージ前提のBPRが目的
本当は標準仕様前提のBPRと同義のはずだった

従来からパッケージ導入の際にFit&Gapが実施されてきた。その目的は大雑把に整理すると

• パッケージ選定のため

• パッケージのカスタマイズのため

• パッケージ前提のBPRのため

といえる。
パッケージ選定では現行業務に最もマッチしたパッケージを選ぶためにFit＆Gapを行う。次に、選定されたパッケージのカスタマイズ必要性を整理するためにFit＆Gapを行う。最後に、パッケージ機能前提で業務のありようを分析するためにもFit＆Gapを行う。

標準化によってパッケージに機能差は無くなるのでパッケージ選定のためのFit&Gapは無意味となる。さらにカスタマイズ禁止なのでカスタマイズのためのFit&Gapも無意味だ。結果、標準化におけるFit&Gapはパッケージ前提のBPRのために特化される。

ところで、パッケージ機能は標準化されていてどれも同じ。だからパッケージ機能との比較と標準仕様との比較は同じとなる。つまり、パッケージ前提のBPRと標準仕様前提のBPRは同義になるはずだった。

パッケージには機能差がある

標準オプション機能と独自施策のパッケージ特例の影響で機能差が生じる

パッケージに機能差が無くなると言ったが、2025年度段階では以下の二点で機能差が生じる。

• 標準オプション機能

• 独自施策のパッケージ特例

本来、標準オプション機能は市にはあるが町村では県が担うため不要な機能など、制度上の違いといった合理的な機能差に限定されるべきものだ。しかし、現段階では全ての団体が実施していない機能など、いわば全会一致とならなかった機能の受け皿にもなっている。将来的には整理されていくだろうが、現状では機能差を容認するものとなっている。
さらに、独自施策編で説明した通り、別出し疎結合が原則の独自施策には”パッケージ特例”がある。独自施策をパッケージ機能としてそのまま保持してよいという特例だ。これは暫定措置であり将来的には整理されるものの、現段階では機能差を容認するものである。

機能差はあっても現行ベンダーしか選択肢はない

パッケージ前提のBPRと標準仕様前提のBPRは結果が異なる
現行ベンダーの標準対応パッケージを導入するしかない
現行システムベンダーの標準対応パッケージとのFit&Gapをするしかない

結局、パッケージには機能差がある。よって、パッケージ前提のBPRと標準仕様前提のBPRでは結果が異なる。つまり、特定のパッケージを定めてFit&Gapを行いBPRする必要がある。

パッケージに機能差があるのでパッケージ選定の意味もでてくる。しかし実際にはパッケージを選定する余裕がない。2025年度の対応では時間も人も足らない。他社パッケージへの乗り換えは同一ベンダー間の移行より手間がかかる。結果、現行システムベンダーの標準対応パッケージを選択するしかない。

ようするにパッケージを選定する余裕がないのにパッケージを特定してFit&Gapをしなければならないという不釣り合いが生じている。
結局のところ現実解は、現行システムベンダーの標準対応パッケージとのFit&Gapをするしかないということだ。

独自施策対応がFit&Gapのキモ

Fit&Gap実施のためにはベンダーのパッケージ機能が定まる必要あり
そのためには独自施策対応の明確化が必要
別だし疎結合で実現する機能も明確にならないとこまる

標準化においてFit&Gapとは、BPRに向けた現行システムベンダーの標準対応パッケージとの比較となる。つまり、”現行システムベンダーの標準対応パッケージを前提に、それでどうやって業務を回すかを検討する行為”に行き着く。

この実施のためには現行システムベンダーの標準対応パッケージの機能が定まっている必要がある。これは本来は標準化され、定まるも何もないものだった。
だが、上述の通り標準オプション機能とパッケージ特例による機能差が存在している。標準化対象事務範囲である標準オプション機能については標準仕様の範疇ではあり、ある程度明確だ。しかしパッケージ特例については明確な基準がなく、どのようなものが出てくるか、ベンダーの判断を待たないとはっきりしない。
ベンダーがパッケージ特例としてどのような機能を提供してくるのかがキモとなる。

さらには、本来の方法である別だし疎結合の提供可否も絡んでくる。
Gap部分、特に標準化対象事務範囲を超える部分への対応はBPRするか別だし疎結合に機能を準備するかの大きく二択。後者の判断のためには別だし疎結合でどのような機能が実現できるかが重要になってくる。
現段階では標準準拠パッケージと別だし疎結合機能との連携方法が不明確で、どの程度の機能が外部に実現できるかが今ひとつはっきりしない。
この点が明確にならないと正確なFit&Gapができない。ここも独自施策対応がキモとなる部分だ。

まだまだFit&Gap実施には課題さまざまだが、与えられた時間はあまりに短い。少しでも早く正確なFit&Gapの実施、BPRの検討が行える状況にしなければならない。