現在、自治体の情報システムの流れとして、汎用機の導入・更新を経て１０年以上が経過しているが その後の幾多の法改正にともない、また、時流の変化、ハードウェアアーキテクチャ、 アプリケーション構築モデル、プログラミング言語の潮流、また、 団塊世代の退職に伴うレガシー技術者の不足等により、 ハードもソフトも陳腐化しており、システム再構築が急がれているという現状がある。
レガシーシステム・マイグレーションの３手法
システム再構築の手法としては、以下の３種の方法のいずかが選択されるのが一般的である。
- 汎用機上の業務アプリケーションをそのまま、オープンシステム上で動かす”リホスト”
- ビジネスロジックはそのまま維持し、プログラムコードをJavaやC言語で書き直す”リライト”
- ビジネスロジック（業務手順）のからシステムを見直し、根本的にシステムを作り変える”リビルド”
ビジネスロジックがほとんど変化していなけれければ、リホストが最も廉価であるが、 しかし、COBOL等のレガシー技術者が今後ますます不足することを考えると、 汎用機の運用コストを削減できるが、期間限定の中継ぎ的な役割となる。 一方、リライトは、リビルドに対比して、現行のビジネスロジックを尊重した手法であり、 要件の再定義より、現在動いているロジックを最優先に考える手法である。 リライトは、ビジネスロジックは変えないが、実装するシステムは、ソフトもハードも最新技術となるので リホストのような、レガシー技術者不足の課題はない。 リビルドは、ビジネスロジックの見直しをした上で、最新の実装技術により、ソフト、ハードとも一新する手法である。 最近の業務パッケージは、Java等オープン系の言語で実装されることが多く、 また、そもそも、最近のビジネスロジックにあわせて実装されているので、 パッケージを前提としたシステム開発を選択すると、おのずとリビルドを選択することになる。
リビルドの実際
多くの自治体は、中長期的に発生するコストであるシステムの運用・改修コストを抑制しようと考える。 自治体の業務システムの主な改修は、大きく以下の３つに分類される。
- １）法改正対応
- ２）不具合対応
- ３）操作性・利便性の向上
その実態はどのようなものであろうか？ １０年以上も前の汎用機上に構築された独自システムにおいては、 いくら自治体業務の半分以上が法に基づくものであり、 どこも同じような業務を実施しているとはいえ、 実際、どこがパッケージの標準機能として提供され、何をカスタマイズしなければいけないかを明らかにするのは 時間のかかる作業となる。 この作業の検討ポイントは、以下のように分類される。
- １）国・都道府県等の上位組織の法律・条令で規定されている業務
- ２）上位組織の法律で規定されているがその運用を当該自治体に任されている業務
- ３）上位組織では特に規定はないが当該自治体の独自の業務
多くの自治体のシステム導入担当者は、異口同音にシステムの開発・改修コストを抑制したいとの思いがある。 これを実現するためには、上記のような分類にしたがって、現在のシステムとパッケージの相違を明らかにした上で できるだけパッケージをカスタマイズしないで済む方法を模索していく必要がある。
大局的な視点では
以上、自治体の業務システム再構築のごく基本的な考え方をあげたが、 このような仕事を数多くこなしていると、ある疑問にぶつかる。 それは、法改正とシステム改修コストのトレードオフである。 本来、法改正とは、徴税や給付の歪みを解消する、あるいは新たな財源確保のためになされるものであるが、 法改正対応のために、その都度、システム改修コストが発生するのは、それが軽微なものなら問題ないが、 この額が大きくなると、法改正とシステム改修コストのトレードオフが問題となると思われる。
法改正とシステム改修コストのトレードオフについて、中長期的な観点から予測・検証する必要があるとともに 法改正対応が自治体の負担にならないようなしくみが必要であろう。 そのひとつは共同アウトソーシングや地域情報プラットフォームのような標準化であるが、 これらの取組みは、まだまだ過渡期であり、今後の進展に期待したい。