2 「なんちゃって共通基盤」を招く3つの要因

2 「なんちゃって共通基盤」を招く3つの要因

ここまで、共通基盤導入のメリットと札幌市の共通基盤について紹介しましたが、どれも「共通基盤ならあたりまえ」のことのように思われたかもしれません。

しかし、この「あたりまえ」をするのがとても大変だということを、私たちは身をもって体験しました。

導入時には共通基盤のつもりだったのに、気がついたら「なんちゃって」になってしまうこともよく起こり得るのです。

共通基盤を導入したのに、業務システムの開発ベンダーから「この製品でなければ動作保証ができないと言われ、インフラを業務システムごとに用意することになってしまった。」
「共通機能を導入したのに業務システムの要件を満たせず、個別の仕様変更が必要となってしまった。」
・・・・・・既に共通基盤を導入している自治体からそういったお話をお伺いしました。

札幌市でも同様に過去に導入したオープンシステムの構築でクォーターサイズのサーバーラックが乱立してしまったことや、システムごとにベンダーの指定する機器やソフトウェア製品を採用しなければならなかったといったことが起こっていました。

そこで、システム基盤の要件定義を行う際にこれらの事例について分析を行いました。その結果、共通基盤を導入しにもかかわらず効果が出ない事例は、次の3つにわかれることが判明しました。

(1)「機器指定・製品指定になり、インフラの費用低減ができない」
(2)「用意した共通機能が業務システムの要件を満たせず、個別の機能開発になる」
(3)「アーキテクチャが異なるため、学習コストが高く参入業者が増えずマルチベンダーにならない」

そして、これらを生み出している要因を分析してみると、3つの考慮不足に起因していることがわかりました。

2.1 MWと業務システムの境目に緩衝がない

これは、(1)「機器指定・製品指定になり、インフラの費用低減ができない」に繋がる要因です。

共通基盤のメリットの2つ目である「機器やシステム、ベンダーを入れ替え可能にする」を実現するためには、「システムとシステム」や「インフラとシステム」を直接結びつけることをせずに、それらの間に緩衝のしくみを導入することが一般的です。

この緩衝の仕組ですが、「システムとシステム」の間には、サービス連携基盤やデータ連携基盤と呼ばれるソフトウェアが、そして「インフラとシステム」の間には、サーバー仮想化ソフトウェアなどが導入されます。

これらのうち、特にインフラを構成するMW(ミドルウェア)の一部と業務システムの間の緩衝が不足しているケースが多く見られます(図3)。

zu3

具体的には、データベースや帳票出力機能などのMWが緩衝のしくみを介さずに業務システムから直接利用されるケースです。
このような作り方をすると、業務システムはMW製品の固有機能に依存した作りとなり、MWと業務システムの結びつきが強くなってしまうことになります。

両者の結びつきが強くなってしまうと、MWや業務システムをそれぞれ入れ替え可能、つまりカセッタブルではなくなってしまいます。

サーバーなどの機器の費用が年々低下するなかで、インフラの費用に占めるMW費用の割合が大きくなっています。MWと業務システムの間に緩衝のしくみがなければ、MWの製品指定が発生し競争が発揮されず、せっかくのオープン化による効果が期待できるインフラの費用低減効果を期待できなくなってしまいます。

また、MWは頻繁にバージョンアップされるため、その度に業務システムに修正やテストが必要にもなり、保守コストの増加を招くだけでなく、システム障害を発生させる元凶にもなってしまいます。

2.2 共通機能の分析が不足している

これは、 (2)「用意した共通機能が業務システムの要件を満たせず、個別の機能開発になる」に繋がる要因です。

共通機能が使われない理由の中として、業務システムが取り込んで利用しようとしても、共通機能の仕様が業務要件を満たしていないため個別に開発してしまうというケースがあります。
こうしたケースは、住所入力支援や外字文字入力といった機能で、業務シーンごとに要件を詰めていくと細部で異なってしまうために発生しやすくなります。

しかも、これらの機能は開発ベンダーが過去に作った類似の機能を資産として持っていることも多く、その場合は共通機能を使わないで済ませようとする傾向はさらに強くなります。

また、宛名情報や税情報などを扱う機能の場合、関わる業務が広いだけでなく、いつの情報をどの範囲で使うのかがさまざまであるため、汎用の機能として用意するのが非常に難しくなります。
機能の利用シーンに加え、扱われる情報の範囲なども含めて十分に分析を行った上で共通化を行う必要があります。

2.3 業務システムのアーキテクチャ統制が機能していない

これは、(3) 「アーキテクチャが異なるため、学習コストが高く参入業者が増えずマルチベンダーにならない」に繋がる要因です。

共通基盤を導入しても、その基盤上で動作する業務システムのアーキテクチャ統制が機能していないため、システム毎にアーキテクチャがバラバラになり、特定のベンダーしか参画しこないという事態を招いているケースが多く見られます。

業務システムのアーキテクチャの統制が機能しない原因は、共通基盤を導入しても、その上で動作する業務システムのアーキテクチャは開発ベンダーの裁量に任されてしまっていることにあります。
つまり、統制がとれていないためですが、その原因には「統制が存在していない」場合と、存在していても「統制をチェックしていない」場合があります。

いずれの場合においても、業務システムのアーキテクチャ統制が機能していなければ、業務システムの開発ベンダーが全体システムの整合性よりも開発の効率を優先した作り方を選択することを止めることはできません。

その結果、規約を守らなくても「動けば良い」という作り方や自社で慣れた作り方をしてしまい、業務システムごと、作ったベンダーごとにアーキテクチャがバラバラになってしまいます。

システム毎にアーキテクチャが異なってしまうと、本来であれば自由度を高くできるスクラッチ開発や、パッケージ開発を採用して、どのベンダーでも参入可能な状況を整えたとしても、他の業務システムを保守するための学習コストが参入障壁となり、特定のベンダーしか参画しこないといった事態を招くことになります。

続きはこちら