はじめに―データアナリティクスを阻む課題
現代社会において、我々は膨大なデータを日々蓄積しています。しかし、そのデータを十分に活用できているとは言い難い状況にあります。データ活用によって実現できる具体的な効果は数多く存在しますが、データアナリティクスがどのような分野で効果を発揮するのか、その理解がまだ浸透していません。
データアナリティクスを促進する手段として、BI（ビジネスインテリジェンス）ツールの活用が有効的な手段であることは広く認識されています。しかし、BIツールの活用にはそれなりのスキルが求められるため、人材が不足している現状では、多くの企業が外部の専門家に依存せざるを得ない状況に陥っています。
さらに、内製化を目指す場合でも、データアナリティクスのベストプラクティスが明確でなく、どのように進めればよいのか迷いがちです。このコラムでは、データアナリティクスを阻む課題について考察し、その解決策を提案していきます。
課題解決に向けた仮説と現状
データアナリティクスを内製で進めるにあたって、BIツールを活用するための課題とはどのようなものがあるでしょうか。
主な課題をまとめてみました。
冒頭で記載した「ベストプラクティスが明確ではない」「どのように進めればよいのか迷いがち」という課題は人的要素のスキルセットにかかる課題であり、この課題を解消することは内製化を加速するためのキーになると考えています。
さらにこの人的要因に関する課題を整理してみます。
セルフBI化に向けた人的資本の課題とソリューション
内製化には教育機会を増やしていくということは重要なファクターになるでしょう。
一方で、研修や部分的なナレッジの展開だけ埋められるのは、型となる進め方の部分や断片的な作り方の部分に過ぎず、継続的な内製化を進められるとは限りません。このギャップに気づかずにただただ内製化メンバーの努力だけで推進されているケースは数多く存在します。
これらのギャップを埋めていく仮説として、ベストプラクティスの理解のみならず、それが導入されたプロセスの理解と蓄積が必要ではないかと考えました。専門家や有スキル者が作成したダッシュボードを紐解いてもベストプラクティスを理解することは難しいのが現状であり、セルフBIの促進には、ダッシュボード作成の具体的なプロセスを理解できるような仕組みを整えることが近道になります。
ソリューション
これらの観点からも有識者が持つベストプラクティスをダッシュボード構築の上流から下流までしっかりと展開することが必要と考えており、弊社ではその一つの引き出しとして「ダッシュボードのレシピ化」が有効と考えています。
レシピとは、ダッシュボードを作成するためのスキルやナレッジを記載したドキュメントで、これによって皆様には以下の二つの効果が期待できます。
- 要件定義からテストまでの流れをまとめられたレシピを参照することで、ダッシュボードを作成できるようになり、データ分析の速度の向上が見込める。
- レシピを基に社内のメンバーにスキルを伝えることで、社内全体でダッシュボード作成のスキル習得が見込める。
それでは、レシピの具体的な内容についてご説明いたします。なお、今回のレシピはTableauを用いたダッシュボード作成となっておりますため、Tableau Desktopの基礎知識をお持ちであることを前提とさせていただきます。
まず、今回ご提供するレシピは、弊社で作成したサンプルダッシュボードの作成方法を
- 要件定義
- 設計
- 開発
- テスト
の4つのフェーズに分割し、各フェーズ内で行う作業を、具体的にご説明したものです。
本レシピに記載された方法を実際になぞってみることで、Tableauに不慣れな方でもサンプル通りのダッシュボードが作成できることを想定しておりますので、図などを用いながら分かりやすいように記載しております。
続いて、各フェーズの内容をご説明いたします。詳細な内容は実際のレシピに記載しておりますので、本コラムでは簡単なご紹介とさせていただきます。
1.要件定義
要件定義フェーズでは、ダッシュボードの方向性を決定します。
まず、要件定義でのゴールを明確にしましょう。ゴールとしては、何を目的に、何をどのように作るか決めることです。手順は以下の通りです。
- ユーザーがダッシュボードによって何を達成したいか、何を解決したいかといった要望を把握し、それを機能的に実現できるかどうかを検討した後、何を実装するか決定します。
- ユーザーのペルソナを整理します。一口にユーザーと言っても、部署や役割など様々です。誰が使うのかも明確にしましょう。
- データの整理をします。保持しているデータの定義や粒度や、データがダッシュボードに至るまでの流れを整理することで、データをどう扱うか明確になります。
- ダッシュボードのアウトプットを明確にします。ラフ図を描くことで、ダッシュボード全体の方向性を整理し、目的との乖離がないか確認できます。
弊社では、この1～4を実現するためのフレームワークを準備し、要件定義を標準的に行える仕組みを取っています。
画像①：手描きのダッシュボードラフ図の例
画像②：ダッシュボードラフ図の例
2.設計
設計フェーズでは、データとダッシュボードの設計を行います。
このフェーズのゴールは、ダッシュボードの作成に必要なデータや項目を明確にすることです。このフェーズで行う設計が、次の開発フェーズでの指針となりますので、要件定義を基に詳細に設計しましょう。
データ設計では、項目定義書を作成し、項目と計算式の定義を行います。ダッシュボード設計では、ラフ図を基に作成するチャートやそれに必要な項目を整理し、実際のチャート作成の方法を詳細化します。
画像③：項目定義書の例
3.開発
ついにダッシュボードの開発です。このフェーズではデータの加工とダッシュボードの構築を行います。
このフェーズのゴールは、ダッシュボードを作成し、最終的な見た目や機能を確認することです。ここでダッシュボードの大枠が出来上がり、全体の完成まであと少しです。
まずデータをTableauに接続し、加工しましょう。接続先はPrepとDesktopのいずれでも構いません。加工することで、ダッシュボード上で利用しやすくなります。データを用意できたら、ダッシュボードの構築に移ります。まずはチャートを作成し、作成したチャートをダッシュボードに配置しましょう。最後に、Tableau Cloudにパブリッシュします。パブリッシュすることで、必要なユーザーがダッシュボードを見ることができるようになります。
画像④：ダッシュボード完成図
4.テスト
作成したダッシュボードをテストしましょう。
このフェーズのゴールは、作成したダッシュボードが実際に使用するうえで問題がないかを確認することです。せっかく作成したダッシュボードも、想定通りの挙動をしなければ利用できません。
まず、テスト仕様書を作って準備しましょう。仕様書を作ることで、テストの観点が明確になります。次に仕様書に沿ってテストを行い、最後にテスト結果をまとめます。テストで問題が分かればダッシュボードの修正を行い、問題がなければついにダッシュボードが完成します。
テストは、実際にユーザーがダッシュボードを使用する際のことを考慮して行う必要があるため、テスト仕様書を作成する時点で観点を整理しておくと良いでしょう。Thomas J.Ostrandという方の提唱した4つの視点（ユーザー、仕様、設定、バグ）(1)や、ソフトウェア品質の国際規格であるISO/IEC 9126が定めた6つの品質特性（機能性、信頼性、使用性、効率性、保守性、移植性）(2)は観点の参考になるかと思います。
画像⑤：テスト仕様書の例
以上4つのフェーズがレシピの内容となります。
本レシピによって、弊社としては二つの効果を想定しています。
一つは、「スキルの習得によってBIツール利用の敷居が下がること」、もう一つは「レシピを通してTableauのスキルが社内に広がり、ダッシュボードの内製化が可能になること」です。レシピによってスキルの向上が期待できます。
おわりに―まとめと今後の展開
本コラムでは、ダッシュボードレシピの一部を抜粋してご紹介をいたしました。
皆様のダッシュボードの作成スキルの向上に本レシピが寄与することが、弊社の想定しているゴールです。本レシピを参考にサンプルと同じものを作ったり、独自のダッシュボードを作ったりするという形でお使いいただき、実践的にダッシュボード作成スキルを向上させることができると弊社は考えています。
本コラムでご紹介いたしましたレシピの完全版に興味をお持ちになりましたら、ぜひ弊社までお問い合わせください。
また、現在レシピ化しているのは不動産ダッシュボードサンプルのみですが、今後は他業種のダッシュボードレシピも展開する予定ですので、引き続き弊社から情報を発信させていただきます。
出典
(1) T.J. Ostrand and E.J. Weyuker, “Using Data Flow Analysis for Regression Testing,” Proc. of the 6th Annual Pacific Northwest Software Quality Conf., pp.233-247
(1988).
(2) “ISO/IC 9126:1991, Information technology software product evaluation: Quality Characteristics and guidlines for their use,” International Organization for Standardization / International Electrotechnical Commission, (1991).