第5回に登場したモスフードサービスの永井正彦氏も,新しいデータ項目を追加するといった情報系システムの改修作業に時間をかけてはいけないと考えている。「情報系システムではどんなデータが新たに必要になるか読めない。それだけに,DWHに格納されていないデータでも,すぐに提供できる仕組みを用意しておく必要がある」(永井氏)。

 このこだわりは,旧情報系システムでの経験から来ている。「(旧情報系システムでは)新たなデータ項目の追加要求があっても,すぐに要求に応えられず,3カ月程度の時間がかかっていた」と永井氏は振り返る。

 3カ月の時間がかかっていた大きな理由は,基幹系システムからデータを取り出す部分は自作のプログラムだったからだ。自作のプログラムなので基幹系システムから取り出すデータ項目を追加するには,プログラムを新たに作ったり修正したりしてテストすることが必要で,どうしても手間がかかってしまう(別掲記事「DWHにデータを追加するときのポイント」参照)。

図1●モスフードサービスは新規データを早く追加するためにETLツールを採用
図1●モスフードサービスは新規データを早く追加するためにETLツールを採用
データ取得プログラムを自社開発する場合と比べ,時間がかからないことを重視した
[画像のクリックで拡大表示]

 また,情報系システムの保守担当者はほかのシステムも兼任しているので,改修に時間がかかればかかるほど,作業をやりくりせねばならず,なかなか改修に着手できない。そうした理由から3カ月の時間がかかっていた。

 永井氏は第5回で紹介したように検索速度の劇的な向上を図ったが,「いくら検索速度が速くても,欲しいデータがDWHに格納されていなければ情報系システムの価値は半減してしまう」と考え,新しく構築した情報系システムではデータ取得プログラムの自作をやめることにした。

 データ取得プログラムを自作する代わりに,それらの機能を備えた「ETL(Extract/Transform/Load)ツール」を採用した(図1)。ETLツールを使えば,DWHに新たなデータを追加する際もパラメータの設定だけで済み,プログラムの追加開発が必要ない。

 ただETLツールの購入費用は,データ取得プログラムの開発費用(開発協力ベンダーに支払う金額)よりも高いと試算された。

 しかし,「自社開発ではプログラムの改修にどうしても時間がかかり,利用者のニーズに早く応えられない。さらに今後発生するであろうデータ項目の追加や変更にかかる費用を考えると,費用面でもETLツールを導入した方が有利になる」(永井氏)との判断である。

リッチクライアントを生かす

画面1●Flexで開発したサークルKサンクスのデータ分析画面
画面1●Flexで開発したサークルKサンクスのデータ分析画面
オブジェクト指向のビジュアル開発ツールが備わっているので,比較的少ない工数で画面を変更できる
[画像のクリックで拡大表示]

 サークルKサンクスの情報系システムの画面は,リッチクライアント・ツールの「Adobe Flex」を使って開発している(画面1)。Flexを選んだ理由の一つは,「画面の改修を容易に行えること」(業務統括本部 システム本部 システム開発部 店舗システム マネージャー 渡部正則氏)にあった。

 同社のスーパーバイザーと呼ばれる社員は,複数の店舗を回って商品発注や店舗運営などを支援する。商品の売れ行きなど定型的なデータを参照することは頻繁にあり,しかもたいていの場合外出先から行う。こうした利用環境を考慮し,Webブラウザでシステムを利用できるようにしたかった。

 またスーパーパイザーの業務において,これまで店舗運営では売り上げを最も重視していたが,今後は客単価を最も重要視するように変わるかもしれない。そのような場合,これまで目立たなかった客単価のボタンを大きくし,目立つ色に変更するといった改修が必要になる。そうした改修は頻繁にあることが考えられるので,既存のプログラムを改修しやすい開発ツールが求められた。

 「HTMLファイルをテキスト・エディタで修正すると,凝った画面にすればするほど修正に手間がかかる。Flexはオブジェクト指向の考えをベースに作られたツールなので,プログラムの改修は比較的行いやすい」(渡部氏)と判断した。

DWHにデータを追加するときのポイント

 情報系システムを数多く手がけてきたITエンジニアによると,データ・ウエアハウス(DWH)にデータを追加する際のポイントは大きく3点ある。

 1点目のポイントは,コードの不一致をなくすことだ。日立システムアンドサービスで情報系システムの構築を担当している奥沢浩氏(オープンソリューション本部 ビジネスコンサルティング部 BI担当部長)は,「商品が改良された場合,改良前後に別々の商品コードを設定するケースがあった」と指摘する。

 別の商品コードのままDWHにデータを格納すると,この商品の売れ行きを長期にわたって見たい場合に,同じ商品にもかかわらず別商品として認識され,支障が出る恐れがある。「同一の商品に複数のコードが存在する場合は,二つのコードを関連させるグループ・コードのようなものを導入し,同じ商品であると認識できるようにして解決する」(奥沢氏)。

 また,「(基幹系システムで)営業エリアごとに営業管理システムを構築して顧客コードを付けた結果,同じ顧客にもかかわらず顧客コードが一致しないことはよくある」と語るのは,TISの山田英司氏(事業統括本部 産業第1事業部 産業システム第1部 部長)だ。「最近は企業合併などで,元々違う企業のシステムからデータを取得しようとした場合にもよく起こる」という。

 こうしたケースで何も対処せずにDWHにデータを格納すると,集計が適切にできない恐れがある。「このような場合は,一方のシステムからデータを取得したときに,顧客コードを他方に合わせるような工夫が必要だ」と山田氏は説明する。

組織には日付データを持たせる

 2点目のポイントは,組織変更を考慮することだ。日立システムアンドサービスの水谷和之氏(オープンソリューション本部 ビジネスコンサルティング部 BIグループ 技師)は,「支店の統廃合や名称変更などで,過去のデータを参照できないケースが増えてきている」と語る。例えばある部門の過去の売上額を見たい場合,検索条件に現在の部門名,検索時期にその部門が存在しない時期を指定した場合,「該当データなし」という結果になってしまう。

 この結果は正しいという考え方もあるが,組織変更前の情報を見せるようにするには,「部門が存在していた日付データを持ったテーブルを用意しておくとよい」(水谷氏)。このテーブルを使って検索時期に該当する部門名を判断できるようにする。

 最後のポイントは,利用者の使い勝手を向上させるために,DWHに取り込む前にデータを付加することだ。例えば,基幹系システムでは支店がどの地域にあるかは不要だが,情報系システムでは同じ地域ごとにカテゴライズしてから支店のデータを見たいとする。このような場合,DWHに支店のデータを格納する際に,「関東」「九州」といった地域のデータを付加することを検討しよう。