◆「統合データベース」の落とし穴
最近のＩＴ活用の流行として「統合データベース」がある。これまで個別に開発されてきた業務別のデータベースでは、データが不連続であり、更新の時間差が発生する。これでは、いけない！個別データベースを、一つに統合してデータを一元管理することで、 全体最適化を目指そうというものだ。
個別最適は「悪」、全体最適は「善」なのである。最近では、ちょっと心得のあるユーザが、データベースの図を、ドラム缶の絵で示して、現状は、個別のドラム缶が、散在している。これを、真ん中に、大きなドラム缶を一つ書いて、データの一元管理、そして各方面で共有するというような絵を書いて、「統合データベース」の必要性を声高に唱えたりする。業者のパンフレットにも、そういった絵が描いてあるものが、多く見受けられる。
本当に、ドラム缶の数を減らすことが、仕事上の問題の解決になるのか。これも、「解決問題」ではないのか。データベースを統合して、全体最適化することは、裏返せば、全体最悪に陥るリスクもあるということだ。統合データベースが故障すれば、全ての業務が停止する。順序性のある業務プロセスと統合データベースには相容れない面がある。業務プロセスや組織を、同時並行作業できるように再編成しなければ、かえって融通が利かないだけの「やっかいもの」になりかねない。
例えば、設計情報を、生産技術者が検討した上で、付加価値を加え、関連部署に情報を伝達している業務プロセスにおいて、生産技術に強みを持つ会社が、統合データベース化して、設計情報をリアルタイムで関連部署で共有すると、どうなるか。
生産技術者の検討が加えられていない設計情報で、関連部署が並行して行動を起こすことになる。その後に、生産技術者が検討した付加価値のある情報が来る。それによって、先行で実施した業務との整合性をとらなければならない。手戻りや間違いが発生する。そうなると、関連部署は、例え設計情報がリリースされても、生産技術者が検討を加えるまで行動を起こそうとしない。リスク軽減の観点から、当然である。このような場合には、設計者と生産技術者が共同で作業した上で、設計情報をリリースしなければならない。
ここまで考えて、業務プロセスを変えなければ、データベース（ドラム缶）だけが統合され、あいかわらず、実際の業務は、順番に行われることになる。結局、統合データベースによる情報のリアルタイム共有、スピードアップ、全体最適化などは、全てお題目になってしまう。
そもそも、ユーザにとって、コンピュータの中の情報記憶装置である、データベースが、分割されているか、一つにまとまっているか意味があるのか。ユーザが必要としているのは、出力なのである。その出力が、一元的に得られれば、コンピュータ内部で、データベースが一つになっている必要性は何もない。それは、システム屋が、最適な配置を考えれば良い事である。ただし、システム屋の理屈で、統合データベースが都合が良いからと言って、それを全体最適化・一元化性善説で正当化し、ユーザの業務プロセスに押し付けるのは、いただけない。データベースが業務毎に、分散しているのは、業務の分権、リスク分散の面からは都合が良い。どこかのデータベースが停止しても、別のデータベースを利用する業務は継続可能なのである。
このような観点から、複数のデータベースから取り出した情報を、一つの画面上にまとめて表示するポータルや、分散されたデータベースや業務システムを連携して、ユーザからは、あたかも、統合されているかのように動かす技術なども出てきている。これを、「連合データベース」あるいは「連合システム」と呼ぶ。
実際に、著者の携わった統合システムも、既存の個別データベースは、そのまま活かし、その上位にメタ・データベースを配置し、内部的に既存の個別データベースと連携させ、ユーザからは、このメタ・データベースに対して入出力させるというシステムを構築した。これを、既存の個別データベースを物理的に一つに統合した場合、開発コスト・期間は、膨大なものになったと思われる。はたして、それだけの投資に対する利益が出たか否かは疑問である。
こうすれば、リスク分散を図りつつ、個別のデータベースに、個別に同じようなデータを転記・再入力する必要もなく、最新のデータを各業務で共有することもできる。前述の「自動化の落とし穴」と合わせて、データベースも適度に分散配置することで、人間の融通が活かせ、適度に遊びが効いた、小回りの聞くシステムを徐々に拡張しながら構築することができる。環境変化の激しい時代だからこそ、開発にも運用にも小回りの利くシステムが必要なのであり、統合データベースはいかにも、小回りや融通の聞かない重厚長大な感じがする。
コメント