一昨年あたりから、自治体においてシステム統合基盤(共通基盤)の導入が始まっているが、 導入にあたっては、まだ理想と現実のギャップがあるようである。

システム統合基盤の導入目的

これまで汎用機で運用されてきたシステムをオープン化するに伴い、 連携や認証といった共通機能を１つのシステムとして構築するのがシステム統合基盤である。 連携機能を導入すると、各業務システムは個々に連携する必要がなく、 統合基盤とのみ連携すればよい。 これにより、連携に伴う初期コスト、保守コストを抑制することができる。

認証機能や職員情報といった共通データベースは、統合基盤にて１箇所で管理することにより、 初期コスト、保守コストを抑制することができる。

さらに、これら以外の共通機能、アプリケーション構築フレームワークの定義といった役割を システム統合基盤に持たせる事例もある。

システム統合基盤の理想と現実

システム統合基盤の理想として、大きく以下の２つがあげられる。

• システムの更新時期に統合基盤自体を他のものに変更しても、連携するシステムは影響を受けない。
• 統合基盤と連携するすべてのシステムに共通する機能、データベースが用意されている。

１つ目は、統合基盤の連携インターフェースを標準化することである程度は解決できる。 それでも、連携に際してデータのマッピングを行う場合、 統合基盤の移行時に、マッピングテーブルの移行をどうするか等の問題が発生する。

２つ目は、理想であるが、現実はなかなか難しい課題がある。 というのは、多くの業務システムはパッケージ化されており、 パッケージ中に独自のデータベースや権限管理、ワークフロー情報を持っている。 これらを統合基盤に一元化するということは、 パッケージを、外部の共通機能や共通データベースを使用するように改造する必要がある。 これは、本来のコストダウンの趣旨と矛盾する課題である。

理想へ向けて

なぜ２つ目の実現が難しいのか？ これは、今までの自治体のシステムに、 「全体で１つのシステムであり必要最小現のシステム構成を実現する」という思想がなかったからである。 また、そのような議論が、各自治体或いは共同アウトソーシングといった やや狭い範囲に留まり、日本標準のようなところまでいっていないこともある。 つまり、システムを用意する側のベンダーもきっちりとした遵守すべき標準がないので 量産によるコストダウンを図れないのである。 裏を返せば、「小さな自治体」のためのシステムのコストダウンに資する統合基盤の 実現に向けては、まず、標準化が重要なのである。

標準化の要素は、連携部分をWebサービスで実装する等とともに、 機能部品をどのようなフレームワークで実装するかが課題となる。 ここは、現時点では、大きくJ2EEと.NETに分類される。 仮にJ2EE,Strutsなどを採用したとしても、Struts自身は、Webアプリケーションの 最低限の機能を規定したものであり、自由度が高い反面、 業務ロジックの呼び出し等の規約がないため、これらの規約の定義やその実現機構を実装する必要がある。

また、そもそもどこまで共通化するか、そのさじ加減が重要である。 経験上、認証基盤、職員情報データベースなどの最小限の共通化からスタートし、 他の共通的に使用するデータベースは、連携機能を通して、または、 統合基盤に配置された複製データベースを通して、やりとりするのが 現実的であろう。

これまで、統合基盤の実現における理想と課題をあげたが、 サービス面でも理想と課題がある。 端的な例は、統合基盤をSOA(Service Oriented Architecture)で実現する場合、 理想とするのは、様々なサービスを組み合わせて 住民からみたワンスストップ・サービスを提供するなどが考えられる。 一方、現時点で、これを実現した例はあまりない。 というのは、自治体の制度運用上、縦割り行政となっており 業務／システムを横串で連携して新たなサービスを生み出す という発想や制度改革がシステムのポテンシャルに追いついていないからである。 統合基盤を実現するシステムも制度もまだまだ未成熟であり これらを徐々に解決していかなければ、 本来の統合基盤の導入目的を果たせないのが現状であり、 早期に解決されることが望まれる。