redashの断捨離を実施したので、方法を共有します
この記事は「Eureka Advent Calendar 2021」の14日目の記事です。
Advent Calendar初投稿です。BI Teamのあらき(@kazuya.araki)と申します。弊社Data Analystとしてプロジェクトの意思決定を支えるインサイトを提供する業務を主軸に、データにまつわる業務を効率化して楽にしたり、データ利活用の一層の成長と向上を図る業務も担っています。
Tableauのコミュニティ(DATA Saber, Serverユーザー会)、BIツール研究所といったBIツールに関する課外活動も行っていますので、Tableau他各種BIツールにご興味のある方はぜひお声がけいただければと思います。
はじめに
今回私が取り上げるテーマは、弊社で利用しているBIツールのひとつであるredashの断捨離を実施した際の方法を紹介します。
BIツールの成果物の断捨離方法については、BIツール界隈でも多くの方々が課題感を抱いている認識がありますので、類似のお悩みを抱えている方々のご参考になれば幸いです。
BIツール導入後の運用にまつわる課題感
redashに限らず、一般的なBIツールの共通の課題として、特に意識なくBIツールを利用していると以下のレポート/ダッシュボードがたまり続ける事案があります。
- 昔は見ていたが、現在誰も見ていないレポート/ダッシュボード。
- いつまでも残り続けているテスト用で作ったレポート/ダッシュボード。
- 残すべきか判断できない退職者が作成したレポート/ダッシュボード。
これらのレポート/ダッシュボードを放置し続けると以下の弊害を生むため、BI利用者、BI運用者双方を悩ませる種となります。
- レポート/ダッシュボードの検索性が悪くなり、必要な情報を取得する時間がかかる。
- 何が正しいレポート/ダッシュボードなのかがわからなくなるので、余計なコミュニケーションが発生する。
- 誰も見ていないレポート/ダッシュボードなのにお金がかかる(サーバー使用料、クエリ課金)。
課題解決方法としては、定期的にレポート/ダッシュボードの棚卸しを行い、不要なレポート/ダッシュボードを断捨離するアプローチが昔ながらの定石となります。
弊社redash環境もご多分に漏れず、この課題を抱える運用フェーズでしたので、年末の大掃除と割り切って断捨離を敢行することにいたしました。
やったこと
※以下、redashクエリ、redashダッシュボードをそれぞれクエリ、ダッシュボードと表記します。
全体像
断捨離を実施するにあたり、4つのプロセスに分解して作業を行いました。
なお、④アーカイブ実施、については特段工夫する点がなかったので、解説は割愛させていただきます。
①対象リスト作成
まずは、対象の洗い出しを行います。
redashにはmetadataと呼ばれるPostgreSQLベースのデータベースにredash内の情報(クエリ/ダッシュボード情報や、閲覧、クエリ実行といったアクティビティなど)が集約されています。
このredash metadataを利用すると、クエリ/ダッシュボードリストが容易に作成できますので、raw dataとしてまずはSQLを作成しました。
クエリ
ダッシュボード
これらの結果をGoogle Sheetsに反映させます。
redashのクエリ結果はURLとして発行できるので、Google SheetsのIMPORTDATA関数を用いればリスト化が容易です。
(弊社はネットワーク設定の関係でIMPORTDATA関数で直接参照できなかったので、redashの結果をCSVに出力した後、Google Sheetsのインポート機能でシートに反映しています)
②断捨離基準を設ける
次に、断捨離する基準を機械的に設定します。
これは、大量のクエリ/ダッシュボードから、必要か不要かの判断する作業はとても退屈で苦痛なので、断捨離における心理的負荷と作業工数を減らすように工夫しました。
断捨離対象から除外するクエリ/ダッシュボード
管理下にあるクエリ/ダッシュボード
BI Teamで運用しているクエリ/ダッシュボードについては、既に別のリストで管理・運用しているため、断捨離対象から除外しました。
直近作成されたクエリ/ダッシュボード
直近作成されたクエリ/ダッシュボードに関しては、現在進行形でニーズがあるため作成されていると判断し、断捨離対象から除外しました。
今回は直近3ヶ月以内に作成されたクエリ/ダッシュボード、と定義しています。
断捨離候補として仕分けリストに含めるクエリ/ダッシュボード
基本的な考え方は、利用頻度がないクエリ/ダッシュボードを断捨離対象にする方向で調整します。
今回は、redash metadataから取得可能な定量情報を基に閾値を設定しましたが、各組織/企業の文化風土、特性などを加味した上で閾値設定のチューニングをするとうまくいくかと思います。
スケジュール未設定のクエリ
スケジュール未設定のクエリは、データ更新が停止しているため、スポットでデータ抽出したクエリであったり、アドホッククエリである可能性が高いと判断し、断捨離候補として選択しました。
ただし、パフォーマンスが悪い、負荷が高い、クエリ課金料が高く、スケジュール設定するとお金がかかる、などといった理由でスケジュールを停止している可能性もあるので、最終判断はクエリ作成者に委ねます(後述)。
直近の閲覧数、閲覧者数が低いクエリ/ダッシュボード
直近利活用できていないクエリ/ダッシュボードはそもそも残し続ける価値がないとドラスティックに判断し、断捨離対象としてノミネートします。
直近利活用できていないクエリ/ダッシュボードの指標として、
- クエリ/ダッシュボードの閲覧回数
- クエリ/ダッシュボードを閲覧した人数
を採用しています。
今回は、直近1年間の閲覧回数が0、または、直近3ヶ月以内の閲覧者が2人以下のクエリ/ダッシュボードと定義しています。
対象リストに反映
以上のロジックを対象リストのGoogle Sheetsに追記します。
具体的には、各ロジックを条件付き書式で定義し、視覚的に分かるように色付けして区別します。
条件付き書式を設定する際は、先にロジックを言語化するとシンプルな条件式で定義できるのでおすすめです。
③作成者による仕分け
ロジックであらかた対象が絞れたところで、最終的な判断は作成者自身の手に委ねる設計としています。
これには2つの理由があります。
- どんなに優れたルールをつくっても、例外はつきものであるので、ルールは「仕分ける人間の心理的負担を減らし、対象スコープを絞るための方法」と割り切ります。
- 断捨離の取り組みを通じて、作成者自身に必要なレポート/ダッシュボードとは何か？という意識を根付かせる裏目標がありました。
- ただし、この思いを一方的に押しつけてしまうと、BIツールに対する心理的安全を損なうことに繋がるので、コミュニケーションには細心の注意を払いました。
- ゴミを跨ぐな(そこにゴミがあると認識しているのに無視して跨ぐのはよくない。転じて、認識している課題を先送りにしない、という意味)、という訴求に近いかもしれません。
具体的な作業はシンプルに、仕分けのフラグを設定するように作成者に依頼しました。
- 黄セル(チェック対象)について仕分けをしてもらう。
- 必要と判断した場合 -> 緑セル(残す対象)に色変化
- 不要と判断した場合 -> 灰セル(アーカイブ対象)に色変化補足: アーカイブしても元に戻せるようにする
③完了後、④アーカイブ実施に移行するのですが、アーカイブ実施にあたり、保険としてアーカイブしても元に戻せるようにSQLのバックアップを取っておきました。
こちらもredash metadataを利用することでSQLのバックアップが可能となります。
まとめ
今回は、弊社が利用しているBIツールのひとつであるredashの断捨離方法について紹介しました。
BIツールによって様々な断捨離方法がありますが、今回紹介したリスト作成と断捨離基準の設定についてはredash以外のBIツールでも応用できるかと思いますので、ご参考にしていただけると幸いです。
(余談ではありますが、Tableau ServerにはTableau Server Repositoryというredash metadataと似たデータベースを内包しているので、Tableauの断捨離を実施する際は同様の手順で実施する予定です。)
また、今回の方法よりも効率よく、かつ効果的に断捨離できるように仕組み化していきたいと考えていますので、他にもこんな良い方法があるよ、こちらの方が楽だよ、などなどありましたら是非ともディスカッションしたいです！
最後に一言
最後まで読んでいただき、誠にありがとうございました。
我々BI Teamは事業上の意思決定をサポートする部門として、日々活動しています。
ご興味ある方はお気軽にお声がけください。
