はじめに
IT業界に携わっている皆さんは、「ビジネス・インテリジェンス(Business Intelligence : BI)」という言葉を耳にしたり、製品や技術に触れたりした方も多いのではないでしょうか。 BIとはおおざっぱに表現すると、
業務システムに蓄積されたデータを分析することで、業務上の意志決定や業務そのものの改善に必要な知見を得ること
ということができます。業務システムには業務を遂行した結果としてのデータが日々記録されていきます。このデータを将来のために活用しようというのがBIの基本的な考えです(※1) 。
BIというと、システム開発とは無関係のものというイメージを持っている方が多いかもしれません。「データウェアハウス(※2) 」・「OLAP(※3) 」・「データマイニング(※4) 」など少々毛色の違ったテクノロジー、統計や数理モデルを用いた分析などを見ると、これは自分には関係ない、専門家にお任せした方がよいと考えるのは自然です。しかしちょっと待って下さい。BIは業務を遂行する現場担当者に対して情報システム部門がプレゼンスを発揮することのできる領域の一つなのです。システムを利用する現場の社員は日々の業務に忙殺されていたりITスキルがなかったりして業務システムのデータを活用するところまで手が回りません。現場担当者からデータ分析について相談されたときに、さっとデータを分析して分かりやすいレポートを提示できたとしたら、その現場担当者も一目置いてくれるでしょう。システムメンテナンスのためだけに存在する情シスから脱却して、現場から頼られる情シスへと変貌するチャンスです。
情シス部門ではなくSIerなどで業務システムを提案・構築する立場の人にとっても、BIはシステム提案に付加価値をつける上で有力なオプションになります。業務システムでは、データのエントリー画面だけでなく、帳票やレポート画面などが用意されますが、これらはデータを加工してビジュアル化しているという点ですでにBIの要素を備えています。BIでの活用を前提としたデータモデルを実現したりBI機能をサブシステムとして追加したりすることで、企業価値を高める戦略的な情報システムとしてのポテンシャルを獲得できるのです(もちろんうまくつくらないとダメですが)。
BIを実現するために必要な活動のうち高度な数理モデルや統計の知識が必要とされるのは全体のほんの一部分です。大部分は業務分析から始まり、要件定義、設計・実装にいたる通常のシステム開発と同様のプロセスを踏んで実現していきます。つまりシステム構築の知識・経験はBIにおいて、高度な数理モデルや統計の知識と同じかそれ以上の価値を持ちます。単純なクロス集計やOLAPぐらいまでをITエキスパートの領域と考えれば、高度な分析だけを分析エキスパートに任せることもできます。
筆者もBI関連のプロジェクトにアサインされるまでほとんど予備知識がなかったのですが、OLAPやデータマイニングを自分でやってみたところ非常に面白く、プログラミングとはまた違った世界がそこにありました。元々データの可視化などに興味があったというのもあるのですが、人間の手作業では不可能な大量データ分析を実行し、その結果それまで気づいていなかった法則が発見できたなどは、コンピューターが人の認識能力を拡大してくれるというのを実感した気がしたものです。みなさんも敬遠せずに取り組んでみることをお勧めします。
本記事では、これから数回にわたり「業務アプリ開発者・情シス部員のための BI入門」と題して、導入ポイント、基盤技術、ソリューションとの関連などの観点からBI/BA技術をご紹介したいと思います。種々の分析ツール・手法の概要についても説明します。対象読者としては、業務システムの開発者や情報システム部門の方々を想定していますが、BI導入検討中の業務部門担当・部門長の方にとっても参考になるような記事にしたいと思っています。
第1回目の今回は、Google Analyticsを引きあいにしてBIを概説してみたいと思います。
※1：最近ではビジネス・アナリティクス (Business Analytics : BA)という言葉が出現しています。BAはBIの一部と位置づけられますが、BIが現状把握に力点を置いているのに比べて、BAは未来予測や最適化にフォーカスした技術として捉えられています。
※2：Data Warehouse/DWH : 業務システムからトランザクションデータを抽出し、分析に適した構造に加工して蓄積する大規模なデータベース
※3：Online Analytical Processing : DWHなどからデータを様々な観点(多次元)で分析する
※4：Data Mining : 大量データに統計や計算機科学(ニューラルネットワーク、決定木など)のモデルを適用して半自動的にルール(データ項目間の関係や規則性)を抽出する技術。
企業活動におけるデータ活用
業務システムでは業務を遂行するためにデータを記録します。例えば、販売管理のシステムでは、電話やインターネットで受けた注文にしたがって在庫を引き当て、商品を発送します。受注データには「届け先住所」という項目が含まれますが、これは配送時に必要になるため受注時に記録しておきます。配送が完了した後も、出荷した証拠を残すためとか、誤配送があったときの確認のためなどにしばらくの期間データを取り置きすることになります。これらはデータの一次利用ということができます。
BIでは、受注データを二次利用して、頻繁に購入している個人(得意客)を抽出して割引キャンペーンの案内や新製品のお知らせ送ったり(※5) 、全体的な購買傾向から需要予測をして生産計画を立てたり在庫調整を行ったりします。企業活動で得られる情報を能動的に収集・分析することで未来を予測し、企業価値を高めていく活動がBIであるということができます。企業におけるデータ活用の例を図2に示します。
※5：このような活動をデータベースマーケティングと呼びます。購買された商品の配送以外のダイレクトメール発送などの目的で「届け先住所」を利用する際は顧客の承認(パーミッション)を得る必要があります。
BIシステムとしてのGoogle Analytics
BIについてのイメージを持っていただくためにWebサイトアクセス解析サービスであるGoogle Analyticsを引きあいに出してみます。Webサイトを運営したりブログを執筆したりしている人であれば、カウンターのCGIを設置しているだけではあきたらずGoogle AnalyticsのJavaScriptをページに埋め込んでいる人も多いでしょう。Google Analyticsは、普通に設置するだけで、ページビュー、セッション数、リファラー情報(参照元のサイト)などの基礎データはもちろん、オーガニック検索(Google、Yahooなど検索サイトでの検索)で入力されたキーワードの集計レポートも利用できます。
| レポート | 説明 |
|---|---|
| ユーザー | セッション(IPアドレスなどで識別された訪問者)、ページビュー、滞在時間、地域など |
| トラフィック | 訪問の契機となったリンク元、検索キーワード、実施したキャンペーンなど |
| コンテンツ | サイト内ページの閲覧数ランキング、入り口/出口になるページはどこかなど |
| コンバージョン | コンバージョン目標の達成率 |
トラフィックやコンテンツのデータは単独で閲覧するだけでなく、組み合わせてより詳細に深掘りした分析をすることもできます。これはカスタムレポート機能により、ユーザー自らの視点でデータを加工・分析することで実現しています(※6) 。図3は特定のページを見た人をユーザー種類(新規・リピーター)に分ける分析レポートを作っているところです(リピーターが32%であることを示しています)。このような深掘り分析をOLAPではドリリングと呼んでいます(※7) 。
※6：OLAPによる多次元分析レポート作成がFlashの画面だけで作成できてしまいます。
※7：Drilling:様々な集計項目(ディメンション)のレベルを切り替えて分析することです。詳細レベルに降りることをドリルダウン、レベルを上げることをドリルアップと呼びます。
表1の「コンバージョン」とは、サイトを訪問した人が会員登録したり商品をカートに入れたりと、そのサイトの運営者が狙いとする行動をすることです。ECサイトではコンバージョン率を高めることが売上の高さに直結します(※8)。Google Analyticsでは、コンバージョン目標を設定してコンバージョン率をモニタリングすることで、サイトの改善効果を測定することができます。筆者はホームページで、フリーソフトウェアをいくつか公開しています。メンテナンスしているのはiEditというアイデアプロセッサーのみですが、このソフトウェアのダウンロードページにどれぐらい訪問者を誘導できているかを知るために、図4のような導線を想定してコンバージョン目標を設定しています。
※8：ンバージョン率だけでなくサイトの訪問者数が多くないと(知名度が高くないと)当然売上は高くなりません。
コンバージョンレポートでは、設定されたコンバージョンの達成率やどのページで脱落しているかなどをビジュアルに把握することができます(図5)。このレポートでは各ページへの流入、導線からの逸脱(サイトからの離脱や導線以外のページへの遷移)も数として把握でき、誘導効果を上げるための改善について検討することができます。
ダウンロードページに進んだ人は39%程度のようです。紹介ページを見てダウンロードページを見なかった人が6割程度ですが、ここでの離脱は紹介ページの説明を読んだ上で訪問者が決定したことですので、Webサイトの問題である可能性は低いと考えられます（※9） 。紹介ページまではそれほど大きな離脱がないことから、説明を読んでダウンロードするかしないかを決定している人が多いのでしょう。逆に紹介ページまでに離脱率が高いようであれば、ページの改善を検討する必要があると考えられます。
以上のようにGoogle AnalyticsはWebサイトを訪れる人の行動データを収集・分析し、サイトのコンテンツや導線の改善策を講じるプロセスを支援してくれるパーソナルなBIシステムということができます。
※9：レポートでは、ページへの遷移率と遷移数の整合性が取れていません。これは想定とは異なる導線でダウンロードページにたどり着いている人が多いからと考えられます。iEditのダウンロードを目的として訪問する人はトップページからではなく、オーガニック検索から直接紹介ページに来る人が多いようです。
企業におけるBI利用プロセス
Google Analyticsの利用シーンがある程度イメージしていただけたと思いますので、企業でのBI利用と対比して見ていきましょう。BIでは次のようなPlan-Do-Seeによる仮説検証プロセスを繰り返しまわすことで、データに基づく意志決定・業務改善を組織に定着させていきます。通常のPlan-Do-Seeと違ってSeeから始めるところが特徴と言えます(※10)。
※10：ここでは、改善策立案をPlanとして位置づけているのでSeeから開始という説明をしています。BIによる業務改善をプロジェクトとしてとらえた場合は、経営の意図や目的の確認から入りますので、全体のプランニング(グランドデザイン)は先にあるのが普通です。
現状把握
日々の業務を遂行していて現場担当者が感じている問題や、経営者が認識した問題について現状を正確に知るための活動です。
Google Analyticsでは「サイトの売上が伸びない、会員数が増加しない」などの問題を分析するためにレポートを分析し、「○△ページで直帰する訪問者が多い」とか「□×の導線の途中で離脱しやすいページがある」などの傾向を数値として把握します。
企業の業務においても「大量在庫が発生しやすい」とか「顧客単価が上がらない」などの問題意識を現場の業務担当者や経営者が認識して、情報システム部門の分析担当者に分析を依頼します。業務分析者は在庫管理システムや販売管理システムのデータを抽出して分析し、「購買に季節変動がある」とか「セールの時にしか買いに来ない客が多い」などの傾向を発見しレポートします。この傾向把握にはOLAPによる多次元分析やデータマイニングが有効です。
業務システムに必要なデータが存在しない場合もあります。このような場合は、インタービューやアンケートなどの定性的なデータで代用する場合もあります。それらも入手できない場合分析そのものを断念するしかありません。この場合、必要なデータが業務を通して収集できるようにシステムを改修したり業務フローを変更したりする必要が発生します。
改善策立案
現状把握の結果に基づき仮説を立て改善策を立案します。
Google Analyticsではサイトの改善策を提案してくれる機能もあります。だいたい直帰しやすいページは情報の提示方法が分かりにくいものだったり、次のページに遷移する条件として個人情報の登録を要求していたりと、訪問者に心理的障壁を作らせてしまっているケースが多いものです。このように導線の妨げになるような要因を取り除くことでサイトを改善していきます。
企業の業務の改善策は分析担当者だけで立案できるものではありません。その問題の優先度や改善施策にかかるコスト、施策の費用対効果などを勘案して業務担当者と分析担当者が共同で策定します。費用対効果を予測する際にもBI技術を利用できます。BIの仮説検証プロセスを何サイクルか回す中で組織としての経験値の増加とともに予測精度が上がっていきます。
改善策を実施する前に、「どんな数値」が「どの程度」変化すれば改善と判断するのかを決めておく必要があります。Webサイトの場合は「コンバージョン率が15％向上したら」などになるでしょうし、企業の業務の場合は「在庫の破棄量が20%削減されたら」「顧客の平均単価が10％上がったら」などとなります。これらの数値をKPI(key performance indicator)といいます。事前に決めておく必要があるのは、実施前と実施後のKPIを比較できないと施策の効果が分からないまま終わってしまうからです(※11)。
※11：結果が出てからKPIを決めると指標の選択にバイアスがかかり適正な判断ができません。
改善策実施
立案した改善策を実施します。
Webサイトの場合はコンテンツやサイト構成を変更します。企業の業務の場合は、業務プロセスの変更であったり、顧客向けキャンペーンの実施であったり、さらには組織構造の見直しであったりするかもしれません。実施後はKPIを継続的にモニタリングすることで施策の効果を測定します。
| 活動 | 企業におけるBI活用 | Google Analyticsを使ったWebサイト改善 |
|---|---|---|
| 現状分析 | 業務アプリのデータベースに蓄積されたデータを収集する。分析に必要なデータ必ずしも存在するとは言えない。収集したデータに対してOLAP分析やデータマイニングを実施し傾向を把握する | ユーザーの訪問時にアクセス記録が自動収集される。各種レポートやカスタムレポートによる分析を行い、傾向を把握する |
| 改善策立案 | 現状分析から仮説を立て、業務改善策を立案する。改善策の効果予測にもBIテクノロジーが利用できる。このときにKPIを決定しておくことが重要 | 現状分析から仮説を立て、コンテンツやサイト構成を見直す。KPIはコンバージョン率などだいたい決まっている。 |
| 施策実施 | 立案した施策を実施しKPIをモニタリングする | 見直し案を元にサイトに変更を加える |
非常にざっくりですが、BIの利用シーンをイメージしていただけたでしょうか。
BIの難しさ
BIという言葉が登場して久しいですが、分析結果を業務オペレーションに効果的にフィードバックする仕組み作りが難しく有効利用されていないケースが多いのが実情です。BIによるソリューションの代表には、CRM(Customer Relationship Management:顧客関係管理)システムやSFA(Sales Force Automation:営業支援)システムなどがありますが、高価な製品を導入してシステムを構築しても効果が出せなかったりする事例が多く、難易度の高いプロジェクトとされています。
システム開発の観点では、Web-DBアプリなどのオンライントランザクション(OLTP)システムの構築に詳しい技術者の数は多い反面、BIに必要とされるDWHやETL（※12） 、OLAPなどの経験を積んだ技術者が少なく、難しさを助長している面もあると思われます。
データ分析の観点では、分析エキスパートの確保および社内育成が難しいという問題があります。データ分析者はBIのツールに精通している必要がありますし、その作業は、地味で忍耐を要するものです。データの収集や加工に多くの時間を費やす必要がありますし、データを収集するために業務部門と調整をしたりするタスクも発生します。見栄えのいいレポートや切れ味鋭い分析の裏にはこの地道なステップが必要不可欠なのです。
分析結果活用の観点では組織への定着化のハードルが高く投資効果が得にくいということが挙げられます。BIを導入するということはデータに基づく判断を組織として取り入れるということですから、業務システム上にしっかりとしたデータ基盤を整備して運用する必要があります。分析ツールは高価です（※13）が「うちでの小槌」ではないのです。テクノロジーへの過度な期待は禁物です。手持ちのデータがちゃんとしていなければ、有益な分析結果は得られません。まさにガベージイン・ガベージアウト(ゴミデータからはゴミ分析が生成される)なのです。
このようにテクノロジー・人材・組織化という三位一体の困難さを乗り越えていく必要があります。
※12：Extract Transform Load : 業務システムからデータを抽出・変換しDWHなどへロードするためのソフトウェア。プログラミングによるバッチ処理よりも開発・保守が容易とされる。
※13：一般的にBI製品は高価ですが、OSSの製品や安価に導入できるものもあります。
おわりに
今回はBIの全体像をGoogle Analyticsと対比させてざっくりと俯瞰してみました。BI導入の難しさについても述べましたが、恐れる必要はありません。組織の実情にあわせてスタートし実績を積んでいけばよいのです。BIのテクノロジーも所詮IT技術の一分野にすぎません。BIに詳しいIT技術者が増えていけば困難と言われている多くの部分はカバーされより多くの企業で有効利用されていくことでしょう。
次回はBIに必要なデータ構造やデータ品質について述べてみたいと思います。
