政府・自治体のシステム調達では、競争を促し、コスト削減のために、マルチベンダによる調達が推奨されている。 しかし、実際のところ、マルチベンダによる調達には、様々な課題がある。

マルチベンダ調達の実態

自治体の例をあげると、自治体の基幹系システムには、住民情報システム、税務システム、財務システム等の 業務システムと、システム共通基盤（連携基盤、職員認証、職員ポータル）等の基盤システムがある。 多くの自治体の構想は、オープンのＡＰＩを提供するシステム共通基盤を構築し、 その上に、業務システムを構築するが、この業務システムは、複数のベンダを選択可能とする。

この方式の留意点は、全体最適の視点から共通基盤にあまりに多くの機能やデータベースを載せ、 各業務システムの要件として、これを活用するこを必須とすると、 多くの業務システムは、パッケージとして完成されているが故に、 外の機能を使うように改修することで、返ってシステム改修費がかかり、コスト高となる点である。 また、共通機能の改修や、データのメンテナンスを誰が行うのかといった課題もある。

上の例でのもうひとつの課題は、各業務システムごとに、ソフト、ハードを調達した場合、 業務システムごとにサーバが構築される。 この方式では、業務ごとに最適なシステム負荷を考慮したシステムとなるので、 必ずしも全体最適なシステムとはなっていない。

理想と現実

できるだけ、共通機能コンポーネント、共通データベースを オープンな仕様で構築し、 各アプリケーションが活用することにより、全体最適を図るとともに ベンダー・ロックインを排除する という理念は、正しい方向であり、進むべき道であろう。 また、地域の情報化という枠組みで、自治体業務と関連する民間金融機関等との 標準インターフェースでの連携も考慮した 財団法人全国地域情報化推進協会 の地域情報プラットフォームは、これを現実化するひとつの枠組みである。

共通基盤の理想は、しかし、現状では、まだまだ過渡期であり、未熟な状態である。 なぜなら、自治体の基幹システムのようなミッションクリティカルなシステムの共通コンポーネント 求められる要件は、性能と安定性が確保され、かつ、そのコンポーネントが代替可能でなければならない。 コンポーネントの粒度や、共通データベースの具体的な定義がなされないまま、 理念と曖昧な仕様のみが先行した状態では、 結局のところ、システム共通基盤が真の意味での代替可能で、 標準インターフェースを備える基盤とななりえず、 その自治体固有の基盤となってしまう。 また、開発ベンダーも、コンポーネントや業務パッケージのメンテナンスにはそれなりにコストがかかるはずであり、 このように微妙に異なる自治体独自仕様の共通基盤が乱立してしまうと、 品質の維持およびそのコストという面で、課題が残る。 特に、自治体の業務システムでは、毎年法改正に対応するための改修の必要性がある点も考慮すべきである。

例えば、上の例のサーバの最適化の問題は、 今の、業務単位のサーバの調達に代えて、 以下のような切り口がひとつの解決策になる。 サーバは、業務共通とし、サーバ性能の最適化は、ブレードサーバのようなスケーラブルな仕組みにより 負荷に合わせて実現する。 ハードディスクのスケーラビリティも同様にサーバのハードディスクの増設でコントロールする。 機器の保守、死活監視、性能監視、セキュリティ監視等の基本的なサーバの運用は、一括して行う。 これには、各業務システムで共通に利用可能な高速プリンタも含まれる。 サーバのキャパシティ・プランニングは、業務アプリケーションの運用担当者からの要望を受け、 サーバの運用担当者が計画する、など。

段階的発展とマイルストーンの設定が必要

ミッションクリティカルなシステムであるが故に、 理想を追求するがあまり、 失敗しました、納期に間に合いませんでした、改修が困難です、 というのでは、大きな問題である。 これを避けるためには、理想を追い求めながらも、 現実を見据え、少しずつ、現実から理想に進んでいくのが望ましい。

このためには、いくつかの具体的なマイルストーンの設定が必要である。 もっとも簡単なマイルストーンは、現パッケージをカプセル化し、 ESB(Enterprise Service Bus）やその１機能としてのSOA(Service Oriented Architecture) で、その構造と意味が標準化されたデータのみ連携する。 ここをはじめとして、徐々に、じっくりと共通機能コンポーネントの全国標準仕様を 作りあげていくことであろう。 先の地域情報プラットフォームは、ひとつの理想であり、仕様策定もすすみつつあるが、 現実的なマイルストーンの設定という面で、まだまだ、考慮すべきことが多い。