包括的なアーキテクチャ上で、何を目指すのか
OSSで広がるさまざまな選択肢や可能性を享受しながら、アナリティクスをどう進化させていくかという言うと、目指すところは、単なる業務としてのアナリティクスではなく、アナリティクス自体を自動化させるような取り組みに移っていくと考えられる（本連載第4回）。最近では、オペレーショナル・アナリティクス（Operational Analytics）とオペレーショナライズド・アナリティクス（Operationalized Analytics）といった整理もされている。
オペレーショナル・アナリティクスとは、本稿でのアナリティクスと同義であり、ある企業（部署）が、事業（業務）を運営していく上で、ビジネスとしての健全性（収益性、効率性）を計測したり、予測したりするモデル構築と言える。具体的には、“もしも”、事業や業務の運営方法を変えた場合、そのインパクトはどうなるのかに答えることができるレベルが求められる。
オペレーショナライズド・アナリティクスとは、一言でいえば、アナリティクスの業務プロセスへの統合と言える。アナリティクスで得たインサイト（洞察）を何らかの施策へと落とし込み、事業や業務プロセスの中に組み込んでいく。本稿第4回でも言及しているが、アナリティクス活動自体をアセット化するということとほぼ同義である。
オペレーショナライズド・アナリティクスは、次の3つを統合することである。
- （オペレーショナル）アナリティクス
- 事業・業務プロセス
- ITシステム
昨今、オペレーショナル・アナリティクスと、オペレーショナライズド・アナリティクスを混同しているケースが散見されている。上記の3つの統合を試みる場合、全体をシステム構築と捉え、ウォーターフォール型開発における業務要件定義工程の中で、アナリティクスにおける予測モデル構築を検討しているケースである。当然ながら、アナリティクスはシステム構築ではないので、予測モデル構築とITシステム構築は分けて実施するべきであろう。
ここで重要なことは、ある特定の予測モデル構築が決定したことを前提にITシステムを構築するのではなく、モデルを改良することを前提に、業務プロセスとITシステムを構築することである。
完成されたITシステムを目指すのではなく、上記の3つの視点から、ビジネス・バリューを生み出す仕組みを構築し、そして継続的に変更を加えていくことが、オペレーショナライズド・アナリティクスの本質と言える。そして、前述した通り、アナリティクスを起点に仕組みを見直すことから、ウォータフォール型開発手法ではなく、アジャイル型開発手法がより効果的である。
これまでのバックナンバー
- ビッグデータの本質は「アナリティクス」の繰り返し
- アナリティクスの勘所--仮説構築とデータ収集の柔軟性
- アナリティクスの難所—“データの理解”とは
- 競争優位性を実現するアナリティクスの2つの要因
- アナリティクスに真の付加価値をもたらすビジュアライゼーション
われわれの目指すゴールは、アナリティクス活動自体を、アナリティクスの対象とし、モニタリングできるようにオペレーショナライズドすることではないだろうか。仕組みだけでなくアナリティクスを効果的に活用できる企業文化を育むことも忘れてはいけないだろう。
