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

DWHの生命線「レスポンス」の失敗事例

ある大手製造業の例です。このプロジェクトでは、ユーザー企業の担当者にデータ・ウエアハウスの構築経験はありませんでしたが、要求定義のディスカッションとFS（フィジビリティ・スタディ）を重ねて理解してもらいました。

データ・ウエアハウスで重要なことは、「効果」と「レスポンス」です。効果に関しては、予測することならできますが、確実ではありません。一方でレスポンスは、データ量/ツール/システム構成を検討すれば、おおよその見当はつきます。

FSの期間に、ユーザー企業の担当者には、「分析が有効である」ことと「利用されてこそ価値がある」ことを十分に理解してもらいました。導入ステップとしては、初歩的な段階からスタートして、定着してきたら徐々に高度化することとし、まずはレスポンス重視（すばやい反応）で要件定義を完了しました。

基本設計が固まってから、ユーザー企業の担当者の上司がプロジェクトに加わり、あらためて分析要件が出されました。その時には（開発企業側の人材である）PM（プロジェクト・マネージャ）も3人目になっており、当初のコンセプトはユーザー企業に全く理解してもらえませんでした。担当者はコンセプトを理解していましたが、人事異動によってプロジェクトから外れてしまいました。

ユーザー企業側が新体制となってしまったことにより、分析イメージだけが先行しました。ツールには長所/短所があり、画面の表現方法やDBのテーブル構造にも影響します。それを無視した分析表現は、レスポンスを悪化させ、エンドユーザーに使ってもらえるわけがありません。

さらに、要求は厳しく、DBは継ぎはぎだらけで、たくさんのデータ・マートを作り、常に改修の連続でランニング・コストもかさばっていきました。これらの収束に時間とコストがかかったのは言うまでもありません。

真の要求を引き出す要求定義と要件定義のこつ

データ・ウエアハウスという情報系システムは、言いかえれば、「その会社のコア・コンピタンス（他社にまねのできないノウハウや技術）は何か、個人に属している知識は何か」を要求定義として形にあらわすことです。

このために一番重要なのは、データ・ウエアハウスが自分のためだけにあるのではなく、「みんなが利用し、全員がハッピーになるためのもので、会社の競争力を高めてくれるもの」ということを参加者全員に認識してもらうことです。

このうえで、「どのように活用したら収益がもっと上がるのか」を表現したものが要件定義です。要件定義が固まるまでのプロセスの例は図2の通りです。

以下では極端な例を紹介しますが、京都のある企業と福岡のある企業の要件定義をしたときには、“企業文化”や“企業風土”を理解したうえでデータ・ウエアハウスを構築するべきだと実感しました。

（a）京都の、ある老舗企業の要件定義では、序列というしきたりについて学びました。

ディスカッション時に、座る席が指定されていました。また、「前打ち合わせ」「本打ち合わせ」「後打ち合わせ」と通常1回の打ち合わせを3回行っていました。

観察していると、「本打ち合わせ」の時には、一番偉い人しか意見を言わないし、ほかの人はうなずくだけでした。とりあえず、そのしきたりに従って要件定義を終えました。

（b）福岡のある企業の要件定義では、マイペースなユーザー企業がいるということを学びました。

分析対象部門の帳票を全部見せてもらうことになり、その理由や今後の段取りもすべて説明して納得してもらったところ、「はい、分かりました」と言って、300種類の帳票を持ってきました。

当方では、持ってきてもらった帳票の整理に着手し、完了させました。種類を分別し、項目を分析軸として、整理したのです。こうして再度確認すると、「まだありました」と言って、今度はその倍以上の帳票を持ってきました。

後で地元のSEに聞いてみると、「あの系列企業は、お殿様だから、分かっていなくとも分かったと言う。『苦しゅうない、好きにやれ』という感じだ」ということでした。そういうことが事前に分かっていれば、必死に帳票を整理する前に、理解しているかどうかをもっと確認したはずでした。

次ページでは、テンプレートを過信することの危険性について、失敗事例を紹介しながら解説します。