仕事における「脳」の使い方を考える

一時期流行った手と腕の組み方で自分の資質がわかるという診断があります。

参考)貴方の効き脳はどっち? 右脳派?左脳派?
http://www.izmic.jp/mame/2014/01/entry_1903/

これを仕事に当てはめてみると、右脳タイプは「感性を大事に仕事を進める」 顧客の要望を汲み取り、共感し、どちらかというと営業や企画の方がより求められる素質ではないでしょうか?

感覚的には「粘土づくり」に似ていると思います。 うっすらとしたイメージはあるのでそれに近づける仕事となります。

完成図はなく臨機応変・想像で作成していく「粘土づくり」

また、左脳タイプは「論理的に仕事を進める」 顧客の問題点を解消する具体案を提示し、決まったことをきっちりとさばくのが得意で、エンジニアや経理の方により求められる素質かと思います。

こちらも感覚的には「模型づくり」に似ていると思います。 設計図はあるのでそれに忠実に作成していく仕事となります。

f:id:gri-blog:20200110105649p:plain
設計図を元に間違いなく作成していくことが重要な「模型づくり」

ただ多くの記事でも言われるように、大事な点としては自分がどんな素質でも仕事においてバランス良く頭を使う必要があり、 バランスが悪いとうまく仕事が進まないことが多々あると思います。人間なので右脳と左脳両方使うのが大事です。 偏ってしまうと、それぞれ以下のような状況になります。

◆右脳寄り過ぎな仕事
  ・顧客要望に共感しすぎて本質がブレる
  ・自分の考えに固執してしまい、思い込みで進めてしまう

◆左脳寄り過ぎな仕事
  ・自分の知識が想像の限界で、柔軟な発想が出ない
  ・仕事を「作業」として進めてしまい、本来の目的を見失う

必要なのは左右の脳をそれぞれスイッチしながら使う。 「アイデアをロジカルに詰める」ことが重要だと思います。 これをまとめると以下のような感じになると思います。

・要望を聞き、素材を得て、周辺情報を集める(右脳・左脳)
        ↓
・集まった情報から本質を想像する(右脳)
        ↓
・そこから具体案を組み立てる(左脳)
        ↓
・案を顧客とディスカッションする(右脳)
        ↓
・最終案をまとめ、その内容でモック、ドラフトを作成する(左脳)
        ↓
・できたものの見直し、改善する(右脳)
        ↓
・顧客へ報告し、更なる改善を議論し、顧客の要望を引き出す(右脳・左脳)

そう、先程の「模型と粘土」の例でたとえるのならば、右脳と左脳を全力で活用するあの世界大会「GBWC」がイメージに近いと思います。

https://bandai-hobby.net/GBWC/japan/

既製品に足りない点を自分の頭で考え作り出す、そんなこの大会で求められる資質同様に 自分の独りよがりでもなく、設計図通りでもない「想像の上を行く創造」が毎回仕事でもでできればなぁと 思いながら自身も仕事をしていますが、なかなかうまくできないことも多々あります。

ただ意識することは大切だと思うので、上記を頭の片隅に置いて日々の仕事を行うのが良いと思います。

面倒なスキーマ定義を自動で行いRedshiftのテーブルを楽に作成する方法

どうも、アナリティクス&デベロップメント部のTです。

最近数十~100GBほどのcsvデータを分析するという場面に遭遇しました。

通常ならGCPのBigQueryかな、ってとこなのですが、 今回はクライアントさんがAWSしか使用していなかったので、 代わりにRedshiftを使うことにしました。

***

さて、Redshiftに限らず、RDBで新しいテーブルを作成する際は、CREATE TABLEで最初にスキーマカラム名、データ型など)を定義しなくてはいけません。

これ、カラムが少ないデータだったらまだいいのですが、10列、20列、それ以上... とあるデータに対して、 各カラムの名前・型云々を一個一個て入力していくのって、超絶面倒です。

しかも一度テーブルを作成してしまったら、あとから細かい修正を加えるのも手間がかかります。

***

そこで本記事のお話ですが、AWS GlueというサービスをRedshiftと組み合わせて使えば、面倒なスキーマ作成・編集をかなり楽に行うことができます。

ポイントとしては以下の2つです。

  • Glueでcsvファイルをパースすることで、スキーマを自動で定義できる(データカタログの作成)
  • Glueで定義したスキーマをもとにRedshiftから直接csvファイルを読み込むことで、データを確認しつつ並行してスキーマ編集もできる

解説

続きを読む

PrestoでUNIX時間の範囲指定をしたらハマった話

最近になってPrestoというSQLに近いクエリで操作できるデータ分散処理基盤を扱うようになりましたが、 今まで書いてきたSQLクエリと同じ感覚でデータ抽出しようとしていたら痛い目に遭いました。

本記事ではその時の模様をお話をします。

Take Home Message

  • UNIX時間のカラムで抽出範囲指定をするときは、TD_TIME_RANGE関数を使うのがよい
    • Presto側で設定したPartitionを有効利用できるため
    • TIMESTAMPをUNIX時間に変換してから数値比較に持ち込むにしても、型に注意が必要
    • 公式ドキュメントが参考になる

状況

課題

とあるテーブルから、2019年7月(日本時間)の一か月間分のログの行数を数えたいと思いました。

しかしそのテーブルlog_tableでは、時刻カラムtimeUNIX時間でデータが入っていました。

さて、どう抽出すればよいでしょう?

正解例

SELECT COUNT(*) FROM log_table
WHERE TD_TIME_RANGE("time", '2019-07-01 00:00:00', '2019-07-02 00:00:00', 'Asia/Tokyo')
)

PrestoにはTD_TIME_RANGE関数が用意されていて、これを使うとタイムゾーン指定も含めて簡単に書けます。


アンチパターン

なにをやってしもたみや?

ところがどっこい、とある港区のデータ分析会社で働くT君は、 以下のようなクエリを書いて処理を行っていました。

SELECT COUNT(*) FROM log_table
WHERE time BETWEEN TO_UNIXTIME(TIMESTAMP '2019-07-01 00:00:00 Asia/Tokyo') 
                             AND TO_UNIXTIME(TIMESTAMP '2019-07-02 00:00:00 Asia/Tokyo')

いったんTO_UNIXTIME関数でTIMESTAMPをUNIX時間に直して、BETWEEN句により範囲指定を行おうとしたわけです。

しかし、こうしてしまったがゆえに、待てど暮らせど結果が返ってこず、とんだ待ちぼうけを食らってしまいました。

さて、何が悪かったのでしょう?

やってはいけない理由

まずは前提として、UNIX時間の範囲指定を行うときは、必ず整数型同士の比較を行わなくてはいけません。

さもないと、Presto側で用意したPartitionをうまく利用してくれず、必要以上にスキャンを走らせることになります。

しかし、ドキュメントTO_UNIXTIMEの仕様を見てみると、以下のようにありました:

to_unixtime(timestamp) → double

Returns timestamp as a UNIX timestamp.

はい、もうわかりましたね。

気が付かないうちに、INTEGERとDOUBLEで比較を行っていたのです。

     ・・・

一応、

CAST(TO_UNIXTIME(TIMESTAMP '2019-07-02 00:00:00 Asia/Tokyo' AS INTEGER)

のように整数型に変換すれば問題なく実行できます。

ただ、せっかくTD_TIME_RANGE関数という文明の利器(?)があるのですから、恩恵にすがりましょう。


おわりに

先ほどのアンチパターンクエリですが、実行してみると以下のようなWARNINGが出ていたので問題に気付き、リンク先のページを見て解決できました。

** WARNING: time index filtering is not set on
  - hoge_db.log_table
** This query could be very slow as a result.
** Please see https://docs.treasuredata.com/articles/presto-performance-tuning#leveraging-time-based-partitioning

Prestoは時刻操作関連の関数が通常のSQLと比べて独自なものが多く、 知らないといろいろと余計な苦労するな、と感じました。

皆様もPrestoを使うときはお気を付けを!

ForecastFlow を Tableau Prep から使う方法 - 予測編

ForecastFlow の予測を Tableau Prep から使用する方法を紹介します.

執筆時点の ForecastFlow Python パッケージのバージョンは 0.0.2 1.0.5 です.

ForecastFlow でモデルを訓練する

いつもどおりにモデルを訓練してください.

2019年12月3日以前のモデルは Prep に対応していないので再度訓練をお願いします.

TabPy サーバーの用意

Python3.7 以上をインストールしてから forecastflow, tabpy をインストールしてください.

pip install forecastflow tabpy

次に ForecastFlow TabPy Examples から config.toml を入手してください.

GitHub - GeeResearch/ForecastFlow_TabPy_Examples

コンソールを開いて config.toml の存在するディレクトリで以下のようにして TabPy を実行してください.

tabpy --config config.toml

スクリプトの用意

スクリプトの取得は2019/12/16に新しくスニペットから取得する方法が追加されました. スニペットから取得した場合はメールアドレスと ID が自動的に埋まるため少しだけ楽になります.

f:id:gri-blog:20191216164506p:plain
図の部分を編集

スニペットからスクリプトを取得する

プロジェクト -> データ -> モデルの順に選択して予測に使用するモデルのページを表示してください.

左側のメニューから Python アイコンをクリックするとコードスニペットが表示されます. コピーして prediction_example.py などの名前で保存してください.

正しいパスワードを埋めてください. 必要に応じてデータ名, 予測名を編集してください.

f:id:gri-blog:20191216171414p:plain
モデルページからスクリプトを取得

GitHub からスクリプトを取得する(これまでの方法)

prediction_example.py を ForecastFlow TabPy Examples から入手してください.

prediction_example.py はそのままでは利用できません. email, password, project_id, model_id を編集する必要があります.

email と password は ForecastFlow へのログインに使うものを入力してください.

project_id と model_id は ForecastFlow でモデル一覧を表示してから Actions にある <> をクリックすると表示されます.

f:id:gri-blog:20191204090747p:plain
ID を表示するには Actions の <> をクリック

data_name を編集して Prep からアップロードされる予測データの名前を変えることができます.

prediction_name を編集して生成される予測モデルの名前を変えることができます.

Tableau Prep から利用する

まず Tableau Prep で予測に使いたいデータを読み込みます.

次に + をクリックしてスクリプトの追加を選択します.

f:id:gri-blog:20191204085543p:plain
スクリプトの追加を選択

  • 接続タイプ Tableau Python Server
  • 接続
    • サーバー: TabPyサーバーのIPアドレスを指定. TabPy サーバーと Tableau Prep が同じマシンならば localhost
    • ポート: 9004
    • その他は空欄で OK
  • prediction_example.py を参照
  • 関数名に ff_predict を指定

f:id:gri-blog:20191204085630p:plain
接続タイプ, サーバー, 関数名を指定して, prediction_example.py を開く

この状態でフローを実行すると Tableau Prep から ForecastFlow にデータが渡されて予測が行われます.

出力はプライマリーキーと予測値を列に持つので, プライマリーキーを使って元のデータと結合して使うことが多いと思います.

f:id:gri-blog:20191115101528p:plain
典型的な利用例

更新履歴

2019/12/16 ForecastFlow 1.0.5

gri.jp

SQLおすすめの勉強法・参考書

SQLのクエリを書きリレーショナルデータベース(RDB)から自在にデータ集計ができることは、データアナリスト必須の素養の一つです。

しかし、学生のうちは使う機会がない人がほとんどで、 新卒入社していきなり使うことになり面食らう人も多いでしょう。

また、今までSQLを書いてきた人でも、

  • 売上げランキングトップの商品をカテゴリごとに取ってくる
  • アクセスログからセッション単位の滞在時間を集計する

など、少し複雑な処理になるとどう書けばいいかわからない、という人もいるかと思います。

本記事ではそういった人を対象に、SQLのおすすめ勉強法と参考書をご紹介いたします。

はじめに

SQLと一口に言っても、複数の種類があり、それぞれ書き方が少しずつ異なります。 代表的なものだけでMySQL, PostgreSQL, SQLiteなどがありますし、 BigQueryやRedshiftといったクラウドDWHもそれぞれSQLベースの構文を持っています。

とはいえ、種類によって異なるといっても方言のようなもので、微妙な差異はありますが基本的なクエリの書き方はほぼ同じです。

したがって、初学者は最初の内はこだわる必要はなく、代表的なものを一つ抑えておけば他のSQLも容易に対応できるでしょう。

もし迷うのであれば、入門書籍の比較的多いMySQLから始めることをお勧めします。

入門レベル

システム・アルゴリズム開発をやるにしろレポーティングやTableau等ダッシュボード作成をメインに据えるにしろ、新卒で入社したら最初の2か月のうちにSQLの簡単なクエリは書けるようにしておくことをお勧めします。

思いがけないところで広く必要になる機会に出くわします。

スッキリわかるSQL入門 第2版 ドリル222問付き! (スッキリシリーズ) 中山清喬

スッキリわかるSQL入門 第2版 ドリル222問付き! (スッキリシリーズ)

スッキリわかるSQL入門 第2版 ドリル222問付き! (スッキリシリーズ)

初歩的なとこからわかりやすく、入門としてかなりおすすめです。

巻末のドリルも使いやすいです。

SQLほんの少しでもわかる場合は、ドリルから手を付けてわからなかったら本文読む、という進め方をお勧めします。

A, B, Cと問題が分かれていますが、難易度はほぼ一緒です。

題材だけが異なるので、好きなのを一つ選びましょう。*1

~中級レベル

条件分岐や行間比較を使って少し複雑なクエリを書きたくなったら以下の書籍を参照することをお勧めします。

特にWindow関数は上記の入門レベルの本には掲載されていないので、下記の本などで抑えておくと何かの時に役立ちます。

達人に学ぶSQL徹底指南書 第2版 初級者で終わりたくないあなたへ (CodeZine BOOKS) ミック

達人に学ぶSQL徹底指南書 第2版 初級者で終わりたくないあなたへ (CodeZine BOOKS)

達人に学ぶSQL徹底指南書 第2版 初級者で終わりたくないあなたへ (CodeZine BOOKS)

  • 作者:ミック
  • 出版社/メーカー: 翔泳社
  • 発売日: 2018/10/11
  • メディア: 単行本(ソフトカバー)

SQLの歴史的経緯や設計思想を交えつつ、通常のSQL入門書では盲点となるようなポイントごとに記述がなされています。

CASE文を書いた集計や不等式条件を用いたJOINなど、「こんな書き方もできるんだ!」と驚くことも多いです。

同著者のSQL実践入門──高速でわかりやすいクエリの書き方 (WEB+DB PRESS plus)も効率の良いクエリを書きたい人におすすめです。

10年戦えるデータ分析入門 SQLを武器にデータ活用時代を生き抜く (Informatics &IDEA) 青木 峰郎

実践を見据えたクエリの書き方が要領よくコンパクトにまとまっているほか、後半は分析基盤についても述べられています。

9章の縦持ち・横持ち変換だけでも目を通しておくと便利です。

レシピ・パターン集

ビッグデータ分析・活用のためのSQLレシピ 加嵜 長門

ビッグデータ分析・活用のためのSQLレシピ

ビッグデータ分析・活用のためのSQLレシピ

場面に合わせた実用的なクエリが豊富に掲載されています。

DBシステムごとに実行可能かどうかも併記されているので、 普段使わないDB環境でクエリを書く時にも便利です。

前処理大全[データ分析のためのSQL/R/Python実践テクニック] 本橋 智光

前処理大全[データ分析のためのSQL/R/Python実践テクニック]

前処理大全[データ分析のためのSQL/R/Python実践テクニック]

シチュエーション別に、SQL, R, Pythonの3種類のコードが併記されており、読み物としても面白いです。

マニアレベル(読んでない)

プログラマのためのSQL 第4版 ジョー・セルコ

プログラマのためのSQL 第4版

プログラマのためのSQL 第4版

SQLの世界的第一人者の手によって書かれた聖典です。 極めたい方は是非。

*1:第1版での情報です。現行の第2版では確認していません。

TableauダッシュボードにGoogle Analyticsのデータものっけたい

TableauからGoogle Analyticsにいい感じに繋ぐには

Google Analytics(以降GAとする)の常に最新のデータをTableauでみる(つまりライブ接続する)方法について考えてみました。GAは、Tableauからだと必ず抽出になってしまい、デフォルトの接続方法だと常に最新のデータをみるライブ接続はできません。そこで、ライブ接続と同等の状況をつくり出すワークアラウンドを考えてみました。

使うツール群はこちらです。 f:id:gri-blog:20191120083930p:plain

TableauでGAのデータに接続し、今回は更に、売上データなどの別データソースのトランザクションデータのチャートに重ねて表示してみます。こちらがゴールイメージです。 f:id:gri-blog:20191119165147p:plain

Google AnalyticsからGoogle Spreadsheetにデータを取り込む

GAからGoogle Spreadsheetに必要な分だけデータを取り込んで、それをTableauで読みにいくことにします。Google Spreadsheetには、アドオンが用意されているので、取り込むこと/その処理を毎日実行することは難しくありません。

簡単のためデイリーのPVのみを取ってきます。(最終的にTableauで、月ごとにみたい場合はこの時点でDimensionsを月にしておくのが簡単です。尚、データブレンディングを使わず、日付をキーにテーブルを結合して、値を使う際はLOD計算をする方法でいく場合はその限りではありませんが。)

アドオンからCreate new reportを押します。 f:id:gri-blog:20191119164905p:plain

GAのアカウント情報を選択肢、MetricsやDimensionsを入れます。Dimensionsは増やしていくと、その値の種類数のかけ算でレコード数が増えることに注意が必要です。 f:id:gri-blog:20191119232844p:plain

Limitは消しておきます。ちなみに私は、Metricsのセルの中身はこんな感じにしています。

ga:users,ga:sessions,ga:bounceRate,ga:goalCompletionsAll,ga:goalConversionRateAll,ga:pageValue,ga:entrances,ga:pageviews,ga:avgTimeOnPage,ga:exits

Configurationができたら試しにRun reportsをして、データが取れることを確認します。 f:id:gri-blog:20191119234223p:plain

結果のシートはこんな感じになりました。ここで上から十数行は設定情報が入ってきていて、Tableau的にはいらない情報が入ってきてしまっているんですね。。これを後で消すことにします。 f:id:gri-blog:20191119165139p:plain

結果がOKであれば先程のアドオンのSchedule reportsから、自動実行の設定をします。こんな感じの間隔で設定してみます。 f:id:gri-blog:20191119164926p:plain

Google Spreadsheetをマクロで加工する

先程確認した通り、Tableau的に余計な行が入っているのでこれをスクリプトで消します。ツールからスクリプトエディタを開きます。 f:id:gri-blog:20191119164936p:plain

シートをコピーして、上から14行分削除するコードはこんな感じになると思います。

function cp_ga(){
  // 現在のスプレッドシートの取得
  var ss = SpreadsheetApp.getActiveSpreadsheet();

  // GAのアドオンを実行して出来上がったシートの取得
  var ss_sheet_ga = ss.getSheetByName("Daily-Pageviews");

  // 前回作成したシートがあったら削除
  var ss_sheet_cp = ss.getSheetByName("Daily-Pageviews のコピー");
  if (ss_sheet_cp) { ss.deleteSheet(ss_sheet_cp); }

  // GAのアドオンを実行して出来上がったシートをコピー、その後〜14行目まで削除
  var ss_sheet_cp = ss_sheet_ga.copyTo(ss);
      ss_sheet_cp.deleteRows(1, 14);
}

プロジェクトと関数にも適当に名前をつけて、試しに実行してみると、Authorization requiredと言われるので、"許可を確認"を押してすすみ f:id:gri-blog:20191119164944p:plain

確認されていませんと言われたら、詳細をクリックして許可していきます。 f:id:gri-blog:20191119164953p:plain

三角のボタンで、実行します。 f:id:gri-blog:20191119165002p:plain

こんな感じのシートが出来上がれば、想定どおりです。 f:id:gri-blog:20191119165011p:plain

では、時計みたいなボタンを押して、自動実行する設定をします。 f:id:gri-blog:20191119165024p:plain

トリガーを追加して、 f:id:gri-blog:20191119165030p:plain

先程のSpreadsheetのアドオン実行のややあとの時間帯に設定します。 f:id:gri-blog:20191119165035p:plain

準備したデータにTableauから接続する

いよいよTableauの設定です。

まずは、売上データ(GAじゃない方)に接続します。後ほどデータブレンディングという方法で、売上とGAのデータを重ねてみたい関係で、日付に当たるカラムのカラム名を"Date"として、GA側と同じにしておきます。GA側を変更して合わせてもOKです。(売上データは、Tableauに付属のサンプルデータを使いました) f:id:gri-blog:20191119165042p:plain

次にGAのデータを読み込んでおきます。 f:id:gri-blog:20191119165047p:plain f:id:gri-blog:20191119165051p:plain

売上データはシンプルに例えばこんな感じのチャートにしておき、、これを開いた状態で f:id:gri-blog:20191119165055p:plain

左上のところでGA側のデータソースをクリックして切り替えて、GAのデータソースの[Date]のところに赤い鎖がついていることを確認します。鎖が赤くない場合は、鎖をクリックすると赤くなりリンクされます。 f:id:gri-blog:20191119165101p:plain

このまま[Pageviews]をドラッグして折れ線グラフにします。これがもうデータブレンディングです。通常、テーブルが2つあって1つのチャートにする場合"結合 (Join)"しないといけませんが、同じ名前のカラムがある場合それをせずにデータブレンディングでもう一方のテーブルのデータを持ってくることができます。なお、データブレンディングではGA側のデータは"属性"になっている(つまりATTR([Pageviews]))ので、更に合計にする(集計を二重にかける)ことができません。

ここでチャートは二重軸にし、更にDateをフィルターに入れて例えば直近の30日間のみ表示されるようにしておきます。 f:id:gri-blog:20191119165108p:plain f:id:gri-blog:20191119165112p:plain

これで完成です。 お疲れさまでした。次の日、データが更新されていれば成功です!! f:id:gri-blog:20191119165147p:plain

Hrioki Saito

いいダッシュボードづくり〜5種類の型

Dueling Data: 5 Types of Dashboards という英語のブログ記事に紹介されているダッシュボードを元に、同様のダッシュボードを日本風にローカライズしながら作成してみました。

public.tableau.com

この元記事の主張として、ダッシュボードのレイアウトは色々あるけれど、ざっくり5種類の型に分けることができると言っています。実際の現場では、いいとこ取りをしながらハイブリッド型にすることもありますし、もっと大まかに3種類しかないという境地に至った人もいるでしょう。が、どんな修行も「守破離」であるべきということで、まずは「守」りということで作ってみました!1つずつ型をみていきます。

1 KPIダッシュボード

f:id:gri-blog:20191118175731p:plain

KPIダッシュボードは、経営層が、主要な経営指標を、ひと目で確認するためのものです。主要な指標(売上や利益)が、今それがいくつなのかがすぐに分かるようにデザインされていて、細かいフィルタやパラメータを使用した操作する機能はあまりないという特徴があります。

デザインの部分では、昨年と今期の推移を比べている折れ線グラフは、単に線の色を変えるのではなく、昨年の方はエリアチャートにしています。異なる種類のチャートなのに、重ねても全く違和感がないというのがなかなか面白いですね。

このダッシュボードに関しては、オリジナルと比べて並べる数字を全面的に刷新させています。具体的に、工夫した点は以下になります。

  • 元々直近の一週間の値だったものを、期初から現在まで日数(Year to Date、以降YTDとする)ベースの値に変更。経営層が見るダッシュボードということで、今期の状況を確認するためのダッシュボードという意味合いを明確に。

  • 対通期進捗率と昨対比を算出。対通期進捗率は、(現在までの合計値) ÷ (通期目標)。昨対比は、該当日のYTDと前年同日のYTDの比。

  • 各KPIの値は、今期が目標達成可能なペースで推移しているかどうかによって、色が変わる。目標達成可能なペースかどうかは、前年同日の対通期進捗率を使って今期の目標と比較して判定。例えば、12月が決算の会社で、毎年12月に年の半分を売り上げている会社は、11月末時点で目標の半分の売上でも、十分目標達成可能なペースであるという状況を考慮している。

  • 折れ線グラフの色は、前年同日と比較して色が変わるようにした。ちなみに比較している値は、週ごとに移動平均を算出して比較。

  • 折れ線グラフの横軸もYTDとしており、期末に近づくにつれ表示している期間も長くなっていく仕様。

ちなみに合計でみる指標については、折れ線グラフのチャートを累計にするのも良いかもしれません。

トップダウンダッシュボード

f:id:gri-blog:20191118181131p:plain

トップダウンダッシュボードは、特定の部門の部門長が、該当部門の状況を、把握するためのものです。KPIダッシュボードにあるような指標と合わせて、その部門の詳細な状況も深堀りできるようなチャートや機能があるという特徴があります。

経験上、世の中のダッシュボードはこの型が多い様に思います。まず小さく始めるのであれば、このトップダウン型にKPIかQ&Aの要素をハイブリッドさせたダッシュボードをベースに、カスタマイズしていくのがいいと思います。

右下に配置されているのはいわゆるグラフではなく、ほとんど明細データそのままという感じです。なるほど、なんでもかんでもいわゆるチャートにしがちですけど、こんな風にそのままディスプレイするものもありってことですね。

3 Q&Aダッシュボード

f:id:gri-blog:20191118181137p:plain

Q&Aダッシュボードは、経営層〜中間管理職の複数の様々な問いに、クイックに答えるダッシュボードです。この問いは、ここ最近注視しているトピックか、または組織を横断するような問いでも構いません。組織的なKPIをみたり、複雑なIssueを深堀りするという目的には向きません。

個人的にはQ&Aダッシュボードは、名脇役であることが多い気がしています。メインはKPIやトップダウンに添えてしんがりを守っているようなイメージです。

ボトムアップダッシュボード

f:id:gri-blog:20191118181141p:plain

ボトムアップダッシュボードは、中間管理職またはアナリストが、特定の部門や個人のパフォーマンスをモニターするためのダッシュボードです。何か改善の必要がある拠点が左側を見ると簡単にわかると同時に、その部門のサマリとなる指標も合わせて右に表示しているようなレイアウトになっています。

ここでは配送オペレーションに関するダッシュボードで、左のチャートで出荷までの日数が遅くなりがちな拠点がひと目でわかると同時に、右側には配送拠点をまたいだ全体でのKPIも表示しているという具合です。ちなみに、この配送拠点の地名は某大手EC事業者の配送拠点を参考にしてみました。なんとも言えないリアリティが感じられる気がしません?

5 One Big Chartダッシュボード

f:id:gri-blog:20191118181154p:plain

One Big Chart ダッシュボードには、地図や散布図の一つの大きなチャートで構成されていて、フィルターやドリルダウンする機能が充実しているという特徴があります。これはアナリストが全体像を俯瞰的に把握できると同時に、深堀りしたいときにはその機能も十分に備えているという具合です。

全体を通しての色など

タイトルエリアの下の線を、弊社GRIのロゴのクマと同じカラーコードの濃いめの黄色にしてみました。それに合わせて、背景色を薄い黄色にし、グラフの線や棒で使用する色もなるべく黄色に合う色、青系やオレンジにしました。ちなみに美しいと感じる色の組み合わせというのは、反対色よりも少しずらした色という話しを聞いたことをあります。京都に行って着物の方を注意深く見てみると、着物の帯と帯締めの色の組み合わせがそうなっているはずです。

さいごに

料理をするとき誰に振る舞うか、ランチなのかディナーなのかを想像せずに、最高に料理が出来上がることはないですよね。

ダッシュボードも同じだと思います。 パッとしないダッシュボードの多くは、そもそも誰がどう使っているかのイメージがないことが多々ある気がします。この5種類のダッシュボードの型は、それぞれどんな立場の人がどんな目的で使うかが明確です。私はこのブログ記事のメッセージを、裏側からこう理解しました。ダッシュボードについて、

"誰が何のために使うのか"が定まっているならば、既に型(≒レイアウト)はほぼ決まっている。残りやることは、その型をベースに細部を作り込んでいけばよいだけ

と。実際に最近では、Tableauプロジェクトがキックオフしたとき「このプロジェクトは○○型でいこう」という会話でおおまかな共通の完成イメージが持てていたりします。どんなダッシュボードを作りたいか分からなくて手が動かせないという状況や、何やらたくさんのチャートを作ったもののダッシュボードとして収集がつかないという状況に陥った際は、"誰が何のために使うのか"を見直して型を考えると、完成イメージがみえてくるのかもしれませんね。

Hiroki Saito