[技術解説]
今、DBに注目する理由―企業システムの変化で問われるDB技術
2009年11月10日(火)桑原 里恵（札幌スパークル システムコーディネーター）
データベースがまた、大きく進化した。長寿命のDB製品が、なぜこれほどまでに機能強化を重ねるのか？ 実現像が変わり、DBのあり方が変われば、求められる製品技術も変わる。企業システムの視点から今日のDBが直面する課題と技術の関係を考える。
業務プロセスとITの一体化は、今日の企業システムに共通する重点課題である。企業は業務プロセスを通して、ビジネス・モデルや戦略を具現化し、日常業務に定着させる。業務プロセスの強さは事業競争力に直結する。
IT化にとっては、事業に貢献するシステムの具体像であり実現目標として、「業務プロセスとの一体化」がある。
事業の視点で業務プロセスを描き、そこに必要な機能を組み合わせていく。システムの単位には縛られない。そして、顧客や担当者の利用場面に合わせて、業務に密着した機能を用意する。
実現像へのこだわりが明らかになれば、システムに求める姿や特性にも違いが見えてくる。システム像が変われば、求める技術も変わってくる。こうした変化の構図を、今もっとも顕著に感じるのがデータベースである。
事業視点の業務プロセスは組織やシステムの垣根を超えて流れる。複数のシステムで発生する「モノ」や「コト」の動きをきめ細かにデータにし、時差なく情報として共有することで、業務プロセス全体が可視化する。
その情報を基点に機能が連鎖して、業務プロセスが一貫化する。離れた場所にいる人が、あたかも隣にいるかのように連携しあう。業務プロセスや役割分担の変更にも、情報によって業務プロセスの動きが共有できているからこそ、柔軟に対応できる。
今日の業務プロセスは情報の力に強く依存している。業務プロセスを可視化し、情報を基点としたしくみを確立することが、ITを駆使した業務プロセスの基礎になる。それだけに、情報を担うデータベースの存在感は大きい。業務プロセスとの一体化が進むことでもっとも強く影響を受け、変化が求められているのはデータベースである。
言い換えれば、データベースの充実度によって、企業システムの成長が左右される。改めて、データベースの重要性を認識し、あり方を問い直さなければならない。そこに、新しいDB技術の価値と必然性もあるはずだ。
業務密着で問われるDBのスピード
Web上の画面から顧客が直接注文を登録する。その場でシステムが注文内容をチェックし、在庫を引き当て、納期を回答する。確定した注文データは即座に後続のプロセスに引き継がれる。顧客の注文から出荷まで、リアルタイムに業務プロセスが流れていく。
最近増えているアプリケーションの姿である。顧客や営業担当者が自ら画面に向かい、システムと対話しながら注文のプロセスを実行する（図2-1）。
「確定後入力」から「確定前入力」に変化するシステム。業務と密着したシステムは、人が仕事をするタイミングで動く。図は受注入力の例。従来は確定後のデータを入力するため、事前に多くの手作業を要した（上段）。今日では、受注申込から確定に至る一連の判断と事務作業を支援している（下段）
従来のシステムでは、確定後のデータを登録していた。注文を決める手順はすべて人手に頼っている。システムが担う機能は後方の一部にすぎない。
一方、最近のアプリケーションでは、人の動きに合わせて、システムを業務の最前線に位置づけている。業務プロセスとの一体感が強い。注文データの確定に至る過程をシステムが支援することで、顧客や担当者の体験をそのままデータとして記録し、業務プロセスの可視化や支援機能に役立てられる。
こうしたアプリケーションは、注文データをつくる部分と、確定した注文を登録する部分の2つの要素で構成される。基幹系の入力アプリケーションに、高度な分析や検索を組み込む形だ。
分析といっても、シミュレーションや一般的なBIのように人が読み判断するものではない。データの妥当性をチェックし、論理値を算出するアプリケーション内部の処理だ。構成確認や代案の誘導、リコメンデーションなど。入力時のデータチェックとは、使うデータ量もロジックの複雑さも次元が異なる。
何よりも、圧倒的に速くなければならない。対話型の入力に耐えられる速度が必要だ。分析には多回数のデータ読み込みがある。データベースの速さが肝になる。しかも、1つのデータが多様なロジックに使われる。データをスタンバイするにも限界がある。まずは、シンプルなデータの読み書きが速いこと。DB技術の基本性能が問われる。
ここで1つ注意したいのは、データ確定前の分析部分にも、多数のデータの書き込みがあることだ。問われているのは、データを読み分析する速さだけではない。これには3つの理由がある。
まず第1に、業務プロセスを可視化し、顧客や担当者の動きを記録するには、きめ細かなデータが必要になる。
2つめは、注文の申込から確定までには複数のステップがあり、複数のロジックが組み合わさっていることである。ステップやロジックごとの結果は途中状況のデータとして持つ。すべてのデータが整ったところで、「完全なデータ」となって、確定入力に流れる。3つめは、分析ロジックや処理の自律性を高め、プログラムの巨大化や複雑化を避けるためである。これはSOAを考えると分かりやすい。サービスごとの結果をデータに返していくことで、サービスが自律し、組み替えが自由になる。
業務プロセスとの一体化によって、データベースが扱うデータは一気に増加する。アプリケーション途中のデータ読み書きの頻度は、従来の確定後入力のアプケーションとは比較にならない。大量のデータを使った分析をし、大量のデータを書き込んでいく。データベースの速さが、業務プロセスとの一体化の前提条件になっている。
データベースの経済性に対する具体策
分析と確定入力では、本来、データベースに求める特性が異なる。かつては、業務支援のシステムを独立して、非同期で基幹系のシステムにデータ連動する形も多かった。しかし実際には、在庫引き当てや価格算出のように、リアルタイムに基幹系のデータベースを見る場面が多く、そう単純に2つに分けることはできない。しかも、データを書き込む頻度が増えている。大量のデータを読み分析すると同時に、細かな単位でデータを書く。分析と入力がシームレスに1つにつながる。
それには、異なる2つの要素を1つのデータベースで対応するか、あるいは、情報共有と分析に特化したデータベースを、入力系のデータベースとリアルタイムに統合するかのどちらかだ。前者には、入力と分析を両立するDB技術、後者にはリアルタイム連携のDB統合の技術が必要になる（図2-2）。
もう1つ、業務プロセスとの一体化を進めるには、急激に巨大化するデータベースに対する「規模の経済性」への具体策が求められる。従来、特に基幹系のデータベースは信頼性が第1で、費用が少しくらい高くても、手厚い構成を組むという考え方が多かった。確定後のデータだけであれば、事業の成長に比例した増加だけなので、ある程度費用を読むこともできていた。
しかし今は、業務プロセスとITの一体化が進むのに合わせて、データが広がっていく。顧客や取引先との接点や協業関係のIT化もある。業務プロセスの進化によって、10倍、20倍といった単位でデータが増えていく。拡張性への強さも経済性の武器になる。
もちろん、信頼性に対する厳しさは変わらない。むしろ、確定後の処理に比べて、業務プロセスに直接関係する分だけ、事業への影響が大きい。
規模の経済性と信頼性の両立。これもまた、今日のデータベースに必須の技術課題である。DB技術のHA構成によって、スケールアウト型のHW環境を使うことなど、システム全体を見渡した具体策が求められる。
業務プロセスの一貫化は信頼性が生命線になる
業務プロセスとの一体化では、もう1つ顕著なアプリケーションの変化がみられる。先の注文のしくみを例にすれば、注文の入力時点で後続プロセスに対するデータのチェックを完了し、クリーンな確定データとして流通することである。「前品質」とか「コミット・ベース・プロセス」と呼ばれる。
従来は、注文入力の時点では受注に必要な最小限のチェックをするだけで、後続のプロセスで段階的にデータを追記し、正確性を高めていく形がとられていた。モノやコトの動きに合わせてデータを確定していく。時には、受注時点で顧客と納期や納品形態を約束しても、実際に処理をしてみると対応できないなどということも起きる。
前品質のプロセスは、発生時点のシステム負担が重い。しかし、ここでデータをクリーンにし、確定状態にすることで、業務プロセス全体の想定データができあがる。あとは、データに基づきプロセスを遂行していくだけだ。
前品質のプロセスを可能にしているのは、リアルタイムの情報共有である。情報がなければ、後品質と同じくモノの動きを待つしかない。ITとの一体化によって、初めて成立する業務プロセスであるとも言える。
それだけに、前品質におけるデータベースの信頼性への要求は桁違いに高い。しかも、前品質のプロセスには、複数のデータベースが関わる。複数のデータベースの連携を前提とした信頼性と運用能力の確保が前提となる。
会員登録（無料）が必要です
- 1
- 2
- 次へ ＞
