要件定義で陥りやすいワナ

データ・ウエアハウスの根本的な価値とは？

今回から5回にわたり、失敗事例に学ぶというスタンスに立ち、DWH/BI（データ・ウエアハウス/ビジネス・インテリジェンス）システムの導入を成功させるための秘訣を解説します。全5回を通し、（1）考え方、（2）最新技術、（3）製品選定、（4）活用、（5）定着、という流れで説明します。

さて、シドニー・オリンピックで日本中が騒ぎ、百貨店「そごう」が静かに経営破たんした2000年10月ごろ、データ・ウエアハウスの提唱者であるビル・インモン（William H. Inmon）氏が来日しました。筆者は同氏に「データ・ウエアハウスに向かない業種はなんですか」と聞いてみました。

インモン氏は、少し間を置いて「官公庁と学校教育」と答えました。しかし、今では官公庁でも大規模なデータ・ウエアハウスを構築していますし、学校運営でもデータ・ウエアハウスを用いて学生の脱落を防ぎ、就活に威力を発揮しています。インモン氏が考えていた以上に、日本社会も競争原理が浸透しています。

筆者は、年に1回、ITコーディネータが主催するフォーラムに参加しています。ここで、データ・ウエアハウスの需要に関する、大変興味深い話を聞きました。数年前の基調講演ですが、「日本の終身雇用制度を壊したのは米国の戦略だ」という指摘があったのです。

日本企業の強さの源泉は、安定した雇用に守られた経験豊富な人材とノウハウでした。ところが、米国のコンサルティング会社が作ったビジネス・モデルに乗せられ、終身雇用を捨てて能力主義一辺倒になったため、何十年という経験から培われた大事な技術と活用ノウハウが一度に失われてしまったのです。

仕事帰りの「おでん屋」などの社交場で脈々と受け継がれてきた技術が、能力主義によって寸断されてしまったのです。こうなると、散逸した技術・ノウハウを集め直さなくては、国内・国外を問わず勝負になりません。

そこに登場したのが、ITを使った“データの倉庫”でした。つまり、データ・ウエアハウスの根本的な価値とは、あらゆるデータが一貫性のあるつながりを持ちながら“そこに”存在することなのです。

基幹システムのデータを連携できなかった失敗事例

現状、多くの企業では、同一のデータ・ソースに対し、人事/総務/営業/マーケティング/経営企画/研究開発などの各部門が、それぞれ異なった切り口で分析しています（図1）。こうした状況の下、プロジェクト管理の不備から、これら各部門の要求を満たすことができなかった事例がありました。

あるネット系販売会社の構築に携わった時のことです。その会社では、顧客分析と商品分析をきっちり行い、顧客ターゲットを見定めてターゲット・マーケティングを行うためのデータ・ウエアハウスを構築しました。

IT部門とのディスカッションも行い、エンドユーザーであるマーケティング部門も交えて、要求定義/要件定義を十分にこなしていました。プロジェクトにはユーザー企業の担当者が専任として入っていましたが、悪いことに基幹システムのリリースが遅れ、この担当者がそちらに工数の大半を取られてしまいました。

基幹システムのリプレースと同時並行でデータ・ウエアハウスの基本設計以降の工程を進め、リリースまでを完了しました。分析機能は十分でしたが、基幹系データのうち一部の実績データを連携できないことが判明しました。マーケティング部門からは「あれだけ時間をかけて説明し、業務に役立つからと協力したのに、これはないだろう」という不満が出ました。

この失敗の原因は何でしょうか。基幹システム担当のSIベンダーと、データ・ウエアハウス担当のSIベンダーとの連携を、ユーザー企業のIT部門が上手にとりまとめられなかったというだけのことだけでしょうか。それは違います。

「今回のデータ・ウエアハウスの目的は何か。絶対に必要なものは何か。それが崩れた時にはどんな結果になるのか。どれだけの影響がでるのか」ということを、もっと十分にIT部門の担当者が理解して進めなければならないのです。

また、基本設計の重要な場面で主担当が抜けるのであれば、たとえスケジュールが後戻りしたとしても、先の重要事項を十分に理解させておく必要があります。スケジュールに追われて、こうした重要な責務を見失ってしまっては本末転倒であり、“使える”データ・ウエアハウスの構築はできないのです。

次ページ以降では、さらにいくつかの失敗事例をとりあげながら、データ・ウエアハウス構築の注意点を解説します。