ビッグデータかどうかは重要ではない。速いかどうか、である。
昨年後半から今年前半にかけ、IT業界のバズワードナンバーワンといえば、文句なしに「ビッグデータ」であろう。その直前まで業界を覆っていた雲（クラウド）を吹き散らして、今や誰もが口を開けばビッグ、ビッグだ。
■バズワードにご用心
（SAPに勤務している私が言うのもナンだが、）データをビッグにすると、いいことがありますよ、とITベンダーは言う。そりゃあ、大きいストレージに強いサーバー、太いネットワークが売れそう、となればITベンダーがそう言うのは当然だｗ。逆に言えば、ユーザー企業にお勤めのみなさんの場合は、それに唯々諾々と乗っていたのでは、、、「毎度ありがとうございます！」(笑)。
本稿では、なぜ「ビッグデータ」に踊らされてはいけないのか？では、どう考えればよいのか？について解説する。
結論から言うと、「ビッグ」かどうかは重要ではない。「速い」かどうか、が重要なのである。
余談だが、ビッグデータの定義として「3V（Volume、Variety、Velocity）」を挙げるのはまあいいとして、これにValueを加えて「4V」と唱えているITベンダーにはさすがに笑ってしまう。（ビッグであろうとなかろうと）データにValueがあるかどうかは使い方次第だ。決してビッグデータそのものに価値があるわけではない。それなのに、さもValueがあるかのように言い立てるITベンダーの節操のなさには失笑を禁じ得ない。
-----
企業システムをざっくりと「業務系」と「情報系」に分けて考えた場合、現在「ビッグデータ」が話題になっているのは、圧倒的に「情報系」分野である。なぜか？「業務系」のデータは、そこまでビッグじゃない、からである。SAPはいわゆる業務系システムの領域では世界最大手だが、SAPユーザーのかなり大手のほうでも、業務系データが1日あたり10GB以上増える企業というのは稀である。それでも年に3TBずつ増えると考えればちょっとしたものだが、ITベンダーが喧伝したがるようなケタ感にはならない。だから「情報系」が中心になっているのだ。
■情報系システムは「D、A、I」
そこで、「情報系システム」をごく単純化して表すと、下記の図①のようになる。
データウェアハウス（DWH）やデータマート（DM）などの情報系システムにあるデータ（Data）を、分析（Analysis）して、そこからなんらかの価値がある洞察や示唆（Insight）を発見すれば、イイことありますよ、というわけだ。この構図自体は、もう何十年も前、「情報系システム」の誕生以来、基本的に変わっていない。
ここで、ITベンダーが唱えているビッグデータ論を単純化すると、図②のようになる。
DAIのうち、Dをビッグにすると、その結果、より価値の高いInsightが見つかるかもしれませんね、というわけだ。
分析対象となるデータがより大きくなるということは、データの詳細度が上がる、あるいはこれまで顧慮していなかったデータをも対象に含める、ということだから、たしかによりよいInsightが見つけられる「可能性」はある。
ただし、あくまで「可能性」である。よりよい示唆が見つかる「かもしれません」というだけで、「必ず見つかります」では決してない。
そしてその可能性を実現するのは、データを分析（Analysis）するヒトだ。むろんアナリティクス系のツールも支援してはくれるが、ツール自体が示唆（Insight）を発見してくれるわけではない。
■実は「DAI」だけに力を入れても無意味である
落とし穴はまだある。
洞察/示唆（Insight）は、意思決定者（ManagerあるいはManagement）が受け取って理解し、それに基づいてなんらかのアクション（Action）を指示して、それが現場に伝わり、その結果がうまくいったときに、初めて価値が生み出される可能性が出てくる。（下記図③）
この後半部分（I、M、A）の流れがもし詰まっていたり、反応が遅かったりしたら、前半部分がどんなによくなっても、まったく意味がないことは明らかであろう。D、A、I、M、Aと情報がきれいに流れる体制ができていて、初めて意味があるのだ。
「過去15年間、情報系システムに○億円も突っ込んだのに、ほとんど成果が出ていない」、という不満をユーザー企業から聞くことがある。というより、大半のユーザー企業が同じような経験を持っているのではないだろうか。しかしもしDAIMAが流れていなかったのなら、それは情報系システムの問題（だけ）ではない。それらを含むDAIMAプロセス全体の作り込みができていなかった、ということだ。
さらに、「DAIMAの前」にも流れがある（下記図④）。
情報系の手前には、まず業務系システム（Enterprise system または ERP）がある。情報系に入ってくるデータの大半は、（純外部データを購入してくるケースを除き、）基本的にいずれかの社内システムから来るはずだ。
その前には業務系システムのユーザーである、従業員（Employee）がいる。
そしてそのさらに先に、顧客（Customer/Consumer）がいることもある。
つまり情報系システムを活用して効果を出したければ、
顧客（Customer/Consumer）
従業員（Employee）
業務系（ERP）
情報系（Data）
分析（Analysis）
洞察/示唆（Insight）
意思決定者（Manager/Management）
アクション（Action）
という一連の流れを整えなければならないのだ。これをとりあえずCEEDAIMAフレームワークと呼んでおくことにしよう。
■情報系システムの本質「CEEDAIMAサイクル」
さきほど「効果が出る可能性がある」という話が出たが、アクションの結果としての効果が計上されるのは、実際には右端ではなくて、業務系システムのところである（下記図⑤）。
意思決定者が出したアクションが伝わる先は、要するに現場社員（やその先にいる顧客）であり、その結果がうまく行って効果が出るとすれば、それは業務系システムのところで「チャリン」とカウントされるからだ。
つまり、情報系システムの本質的な流れは、左から右への一方通行ではなく、「CEEDAIMA「サイクル」なのである（下記図⑥）。
ためしに御社の業務系・情報系を含めたデータの流れを俯瞰してみていただきたい。バリエーションはあれ、本質だけを突き詰めると、情報系システムは必ずこうした位置づけになっているはずだ（決算や監督官庁報告などの外部向けレポート出力のための情報系システムは除く。これらは売上や利益を増やすための活動ではないので）。
逆に言えば、もしこのCEEDAIMAサイクルが回っていないとしたら、どこかに深刻な問題があることになる。
■「打席に立つ回数」を増やす
情報系システムへの投資を通じてリターンを出したい、ROIを得たいと願う企業は、すべからくこの「CEEDAIMAサイクル」を意識しなくてはならず、かつこのサイクル全体ができるだけスムーズかつ「速く」回るように全精力を傾けなくてはならない。
なぜなら、速く回るということはイコール「見直し・修正の機会が増え、それだけ施策の精度を上げられる」からだ。野球に例えれば「打席に立つ回数が増える」ということだ。
仮にこのサイクルのどこか1か所、たとえば業務系から情報系へのデータ転送が、月次のバッチ処理だったとすると、このサイクルはどんなに頑張っても月に1回転しかしないことになる。あるいはマネジメントからのアクションが月1回の○○会議を経て出ることになっている場合も同様だ（下記図⑦）。
この場合、せっかく情報系システムに巨額の投資を行い、現場の状況を把握しようとしていたとしても、打席に立つチャンスは年12回しかないことになる。
しかしこのサイクル全体が1日1回転できるようになれば、月30回転させられる。昨日打った施策の結果がどうだったか？が翌朝分かれば、それに基づいて今日の施策の微調整ができる。つまり「月に30回打席に立つ」ことができるわけだ。
■高度な予測モデリング vs 高速CEEDAIMA
ITベンダー、とくに情報系ツールを売っているところは、とかく「分析ツール」の機能を競っている。過去のデータをさまざまな切り口から「分析」して高度な予測モデルを作り、それによって将来を読んで施策を打ちましょう、と。
しかしいくらツールがすごくても、それを使うのは人間だ。F1カーに乗れば誰でも350km/hで走れるわけではない。ビッグデータ時代なのに分析人材が足りない、養成が急務である、といった一般論はさておき、とりあえず「ウチの会社」にそうした高度な分析能力を駆使できる人材が来るのはいつのことだろう？
一方、CEEDAIMAサイクルが1日1回るようになれば？もはや高度なモデリング等は不要になってくる。とりあえず今日やってみて、その結果がどうだったかが明日の朝にはわかるのであれば予測モデリングに凝るよりも、とりあえず何種類かの施策を同時にやってみて、その結果を見て調整しまたやってみる、と繰り返すほうがずっと確実なのではないだろうか。
たとえばスーパーマーケットで特定の牛乳を販促したいとき。お客は10円引きだったら切り替えてくれるのか？15円でないとだめなのか？かわりにポイントを付与する場合、10ポイントだったらどうか？20ポイントでは？土地柄による違いは？ポイントカードを持つ得意客と、一見さんでの違いは？男女、年齢層では？・・・
CEEDAIMAサイクルがより速く回る企業－－月次より週次、週次より日次、日次より1日に何回転も回せる企業－－これこそが当ブログのタイトルでもある「超リアルタイムビジネス」（Real-Realtime Business）の姿なのである。
■「ビッグ」データより「ファスト」サイクル
おっと、忘れかけていた、ビッグデータの話。データがビッグだと何が嬉しいのか？
上述のように、データがビッグな場合、洞察/示唆（Insight）の精度が上がる可能性はある。ただし実際にInsightの精度を上げられるかどうかは、分析を行うヒトの技量に依存するうえ、仮になんらかの有益なInsightが見いだせた場合でも、それを反映した指示（Action）が出るのが年12回では... 宝の持ち腐れもいいところではなかろうか。
ビッグデータを扱うこと自体が無意味だとは言わない。しかしこのCEEDAIMAサイクル全体においては局所的な影響しか持っていないことは間違いない。したがってその部分だけに着目するよりも、サイクル全体の中のボトルネック箇所を洗い出し、そこを「速く」して、サイクル全体をできるだけ速く回すほうが、ずっと確実だ。
冒頭に申し上げた結論の意味がお分かりいただけただろうか？「ビッグ」かどうか、は問題の核心ではない。速いかどうか、が問題なのである。
何週か前に掲載したフランスの食品スーパー最大手、Casinoの「プレシジョン・リテーリング」はまさにこの超リアルタイムビジネスの好例であるが、これ以外にもさまざまな事例が出てきている。次回以降、CEEDAIMAサイクルを実践している事例をご紹介していこう。