読者です 読者をやめる 読者になる 読者になる

Tbpgr Blog

Ruby プログラマ tbpgr(てぃーびー) のブログ

Re:dash - Re:dashとは?

Re:dash

f:id:tbpg:20160815022818p:plain

f:id:tbpg:20160815022828p:plain

Re:dashとは、

Open Source Data Collaboration and Visualization Platform

オープンソースのデータコラボレーションと可視化プラットフォーム、
と公式に記載されています。

redash.io

より具体的には、特定のデータソースから取得したデータをSQL等で加工し、
表やグラフを作成します。
作成した表やグラフを組み合わせた目的ごとのダッシュボードを作成することで、
いつでも最新の情報を元にしたKPIなどの可視化対象を素早く確認できるようにするツールです。

前提

私自身この領域の経験が多くあるわけでもなく、最近さわりはじめたので
情報収集して内容をまとめているだけです。
不足などあると思います。

繰り返し「KPI」という用語を使っていますが詳細はここでは触れません。
なんぞ?という方はググッてみてください。

全体像

f:id:tbpg:20160815022848p:plain

  • Re:dash がサポートしているデータソースに関しては設定だけで取り込み可能
  • Re:dash がサポートしていないデータソースに関してはサポートしているデータソースに変換する必要がある
  • KPIや可視化対象の要件決定者から依頼を受けたクエリメンテナがSQLでクエリを作成し、ダッシュボードに追加する
    • 可視化対象の要件を知っている本人がクエリをかければ本人がやってもいい
  • プロジェクトの関係者全員がいつでもすぐにブラウザから可視化対象を確認できる

他のツールと比べた Re:dash の特徴

  • オープンソースで設置のコストが低い
    • 高級なBIツールのライセンスは非常に高い
  • 最低限の機能に絞られているが、その分学習コストは低い
    • ただし、公式ドキュメントの情報量はあまり多くない

Re:dashを導入する前の組織が持つ課題

典型的な利用例としてKPIの管理の事例を挙げます

ビジネスのKPIを管理していないケース

KPIを管理していないため、現在本当に重要な課題が不明確になる。
また、取り組んだ課題の効果も明確ではないため
「数値計測するまでもなく明らかに対応した方が良い問題」
以外に関して、その実施基準と実施結果が曖昧になってしまう。
各課題の優先度も定性的な基準や直感・経験に頼る形になってしまう。

ビジネスのKPIを手動で算出しているケース

手動といえどもKPIを基準にしている分だけ何も管理していない状態に比べると
効果的なフィードバック・ループが回っている。

ただし、コスト・期間・正確性の面で問題があり、
本当の望ましい形でのフィードバックループがとはいえない。

Re:dashを導入したあとの組織

KPIが常時可視化されているため、現在対応すべき課題やその優先度が明確になる。
対応前後の効果も数値ベースで計測可能になる。
結果として、行うべき課題に集中しその対応結果を振り返り、
高速にプロダクトを改善し続けることができる。

親記事

tbpgr.hatenablog.com