だからその“分析（BI）プロジェクト”は失敗する（2/3）

コラムカテゴリー：データ分析

分析（BI）システム導入をご検討される企業様向けに、“プロジェクトが失敗する原因とその注意点”を9つ提唱しているコラムです。今号は以下の4.～6.（レスポンス）に関する内容についてご説明いたします。

（前回コラム）
だからその“分析（BI）プロジェクト”は失敗する（1/3）
（次回コラム）
だからその“分析（BI）プロジェクト”は失敗する（3/3）

分析を行う“目的”を深堀りしましたか？
分析に必要なデータ材料が揃っていますか？データ同士が繋がりますか？
成果を定量的に測定できますか？
レスポンス目標を立てましたか？
データの“サイジング”を実施しましたか？
OLAPキューブ（多次元分析）の構築は適切ですか？
BIツール・開発ベンダーの選定は適切ですか？
いつも作っているその帳票、目的は何ですか？
企業内で “分析業務”を認める風土、活かす風土を形成できますか？

4．レスポンス目標を立てましたか？

みなさんがいざ分析を行う際に、システムからの回答時間が何秒であれば、ストレス無く利用することができますか？
システムが結果を出してくれるまでの時間“レスポンスタイム”の目標値を明確にすることも、分析（BI）システム構築には欠かせません。しかし、目的や分析対象データ量に関係なく、“全ての処理を一律○秒以内”と定義してしまえば、開発ベンダーから高額な見積金額が提示されるでしょう。
重要なのは、分析の目的によって異なる目標値を定義する、ということです。

（例）

店の販売状況から、店舗や物流センターの過剰在庫、不足を分析する

このような日常的に行う分析業務では、分析条件を変える度に毎回何分も待っていては、分析効率は上がりません。数秒単位でのレスポンスが求められます。

重視しているKPIの改善状況を分析し、所属長に定期的に報告する

例えば所属長に報告する場合、ある程度の期間・カテゴリ等のサマリを報告するのが常です。“分析”よりも“報告”の意図が強くなれば対象データ量は増え、その大量データの集計結果を返すにはレスポンスが悪化してしまうでしょう。しかし、実際の報告頻度はどれほどでしょうか？少なくとも毎時間ではないはずです。このようなケースの場合、レスポンスはそこまで重視しなくてもよいかもしれません。極端な話、BIツール上で表現できなくても、「大量データを処理して数値を返すバッチ処理」を夜間に組み込み、毎朝ダッシュボードなどに出力させる仕組みさえあれば解決するかもしれません。

上記のように、分析目的や分析対象データ量によって異なるレスポンス目標を立てることができれば、開発ベンダー側もより具体的な見積を提示できるだけでなく、目的達成のための別案等を提案してくれるかもしれません。

5．データの“サイジング”を実施しましたか？

レスポンス目標を立てたら、実現可否の調査「データの“サイジング”」を実施します。通常、サイジングに必要な情報はITベンダーに対するRFP（提案依頼書）に記載しますが、情報の過不足を開発ベンダーとすり合わせずに、“完成するまで早いか遅いかわからない”状態のままプロジェクトを進めるのは大変危険です。
分析(BI)ツールを導入するITベンダーの選定が終わり、いざプロジェクトがスタートする段階でも、認識齟齬が無いか再度確認の場を設けるべきです。きちんとRFPに記載していても、受け手側が都合よく解釈してしまうのは当然ですし、イレギュラーケースの扱い等も事前に確認しておかなければ、後々問題となり追加費用を請求されてしまう可能性もありますのでご注意ください。
以下は、データのサイジングに必要な情報の一例です。

概要	具体例
マスタデータ量	店舗マスタ、商品マスタ、物流センターマスタ、顧客マスタ、給与マスタ…それぞれのマスタデータ量。今後のマスタ件数増加予定…etc
トランザクションデータ	受注データ、出荷データ、売上データ、在庫データ、生産実績データ…それぞれのトランザクションデータ量。今後のデータ件数増加予定…etc
データ保持期間	DWHに格納するデータそれぞれの保持期間。（例：販売実績データは過去3年保持。在庫データは過去1年保持など。）…etc
ユーザー情報	システム利用者数、同時実行ユーザー数。今後の利用対象者増加予定。…etc
他システムI/F	DWHへデータ統合する連携元システムからの、I/F本数。論理／物理レコード長。…etc
夜間バッチ処理	DWH内・BIツール内で夜間に処理すべき内容の他、連携他システムの夜間バッチ終了時刻などの考慮…etc
月次処理等	一時的にInput/Output量やCPU負荷、メモリ使用量が急上昇する処理の考慮…etc
ユーザーアップロード	「ユーザーが手元に保持しているファイル情報を取込む」機能を実装する場合、そのアップロード対象データのファイルサイズ等の考慮…etc

6．OLAPキューブ（多次元分析）の構築は適切ですか？

分析を効率良く行う手段として、「OLAPキューブの構築」があります。OLAPとは、簡単に言えば「データベースからデータを取り出し、多次元的な分析を行う処理のこと」です。代表的なOLAP2種についてご説明します。

M-OLAPキューブを適用すべきデータ

多次元データベース（キューブ）にデータをあらかじめ保存しておくことで、高速アクセスが可能なM-OLAPキューブ。しかし、下記の弱点があります。

変更の度に再作成が必要であること
大量の明細データを保持するには限界があること

1.について、分析対象データを“随時最新の状況” で分析する目的であれば、M-OLAPキューブは不向きです。例えば夜間バッチにて前日〆時点でM-OLAPキューブを構築しておき、“日次単位”で分析するケースであれば、M-OLAPが適しています。

2.について、例えば在庫データのように、日々の仕入や出荷が発生せずとも、“在庫”として存在している限りトランザクションレコードが日々作成されてしまうデータを分析する場合、それを“長期間分まとめて” M-OLAPキューブにすることはおそらく不可能です。分析の目的を考え、「分析対象データを絞る」「分析対象期間を絞る」事などを検討し、適切なデータ量に絞ったM-OLAPキューブを構築しましょう。

R-OLAPキューブを適用すべきデータ

事前のバッチ処理が不要で、データ範囲に制限のないR-OLAPキューブ。弱点は、「対象データが増えるほど、クエリが複雑になるほど、レスポンスが悪化する」点が挙げられます。
陥りやすい点として、目的に絞ったM-OLAPを定義できたことにより、逆に、「全てのニーズに対応できる“全部入り”のR-OLAPキューブを作ろう」という誤った判断をされてしまうケースがあります。その場合、ユーザーが分析中に意図せずして“大量データの取得クエリ”を発行してしまう可能性があり、サーバーへの負荷が高まりレスポンスが悪化します。最悪の場合、システムがダウンすることも考えられます。
“全部入り”キューブは、往々にして、「なんでもできる」から「何をすればよいのかわからない」状態に収束します。分析の目的に沿ったデータに絞り、キューブを定義すべきです。

終わりに

レスポンスは、人によって遅い/速いの定義が異なるため、非常に曖昧になりやすい点に注意が必要です。具体的に定義した目的（前回コラム参照）それぞれに対し、定量的な目標値を設定することが、より良い分析環境を構築する上で重要です。
また、データ収集技術の発展が著しい昨今、企業内には様々な種類のデータが大量にストックされています。それらのデータを一ヶ所に集約した際のレスポンスを担保する“サイジング”は、プロジェクトを成功させる上で非常に重要なポイントとなりますのでご留意ください。

次回コラムでは、“システム構築”の視点から少し離れ、“分析を行う企業のあり方”について、筆者の考えを述べたいと思います。

（トラックバック）

だからその“分析（BI）プロジェクト”は失敗する（1/3）
だからその“分析（BI）プロジェクト”は失敗する（2/3）
だからその“分析（BI）プロジェクト”は失敗する（3/3）