この記事はアドベントカレンダー19日目の記事です。
ドコモのデータプラットフォーム部に所属しているデータサイエンティストの中村光宏と申します。
この記事では、ドコモのスマートライフカンパニー1社員向けに配信しているダッシュボードをリニューアルした際の手法と学びをまとめました。前半は企画部門などの参考になるデザインや企画の思想について、後半には技術部門に向けた技術的な情報をまとめています。
1ヶ月程度の短期間でダッシュボードのUI部分を高速かつ大幅リニューアルできた実績をまとめていますので、担当しているダッシュボードのUIにお悩みの方、リニューアルやリファクタリングしたいと思うものの二の足を踏んでいる方は是非参考にしていただければ幸いです。
なお、表題の”ワンオペ”とはTableauによるUIや前処理の実装部分を指しています、運用や試験・レビューなどは他の社員/パートナー企業様のご協力あってこそ成り立っておりますのでその点あしからず。
リニューアルしたダッシュボードについて
ダッシュボードの概要・提供目的
今回リニューアルしたダッシュボードは、スマートライフカンパニー全体の収支状況から、個別サービスの利用者数・定着率・課金状況等細かい情報までが確認できるダッシュボードです。
提供の主な目的は、①データドリブン経営を進める上で社員にデータに興味を持ってもらう入り口になること、②幹部層が各サービスの状況をリアルタイムに把握できること、の2点で、利用者のレイヤが非常に幅広く設定されているのが一番の特徴です。
利用者が幅広く、概要から詳細まで確認できる必要があるため、かなり大規模なダッシュボードになっています。利用できる指標数は1200、掲載サービスは約40と社内でも最大規模のダッシュボードに位置づけられています。
ダッシュボードのアーキテクチャ
ダッシュボードはSnowflakeとTableauを主軸に構成されています。
各ビジネス部門のデータをRPAやファイル連携などで集計し、Snowflakeで結合した上でTableauで可視化しています。
なぜリニューアルしたのか？
リニューアル前のダッシュボードも前述の提供目的の①②を叶える機能は十分に備えていましたが、色々な課題があったためリニューアルが求められていました。
リニューアル前のデザインが悪かったというよりも、データが増えるに連れてUIや機能の継ぎ足しが続き、結果としてUIとしての不整合が起きていたように思います。
一番の問題：チェックしたい指標までの遷移数が多い
一番の問題にページの遷移数があり、従来のUIは指標のグループ毎にページが分かれてしまっているため、目的の指標にたどり着くまでに数ページの遷移が必要でした。
例えば、◯◯サービスの最新売上を見る場合、事業全体の収支ベージ⇒△△部門の収支データ⇒◯◯サービスの月次収支⇒〇〇サービスの最新月の収支・・ と複数ページの遷移が必要で、この手間が自社全体の数値状況を日々素早く把握したい幹部層からの不評を買ってしまっていました。
明確な目的を持ったユーザがデータをドリルダウンしながら分析していくのには向いたUIでしたが、「データに興味を持ってもらう」にはそこまで向いていないUIとなっていたようです。
リニューアルの企画
リニューアルした際のUIコンセプト
提供目的は既存のものから変わりはありませんが、以下の4点をコンセプトとしてデザインを構築しました。
- 1ページ目でスマートライフカンパニー全体の概要が把握できる
- 必要なデータにアクセスするまでのページ遷移は2〜3ページまで
- 最新のデータを何よりも最初に見せる
- 幹部と社員が同じデータを見ている状態にする
1点目と2点目は具体的な数字を設定しましたが、UIデザインとしてはこの数字設定が振り返って非常に良かったように感じています。
開発中に何度も仕様変更やデザイン変更が発生しましたが、具体的な指針があることでブレずに一貫したデザイン思想が維持できる指針になりました。
構築の際に参考にしたダッシュボード
CRISP METRICS
業態は違うものの、ダッシュボードの構築の際にはCRISPさんのCRISP METRICSを参考にさせていただきました。
売上、ユーザの熱狂度などシンプルにまとめられていて、UI自体も非常に見やすく参考にさせていただいています。何より社内データをオープンにできる取り組みが素晴らしいです(私どものダッシュボードはダミーデータ版でしか公開できずすみません。。)
Google Analytics
フィルタや各アイコンの位置などは、事業部門の担当者に馴染みの深いGoogle Analyticsを参考にしました。
Google AnalyticsのUI自体が全体把握のために洗練されているのも参考にした理由ではありますが、ビジネス部門が使い慣れているUIに思想を近づけることで導入段階でユーザが躓きづらいようにしています。
リニューアルの開発体制
UI(Tableau)でデータの前処理を行う体制
今回の開発は通常のダッシュボード開発とは少し異なる体制で開発を進めました。
通常のダッシュボード開発ではUIのデザインを固めた上でUIに合わせた前処理を行ったデータマートを用意しますが、リニューアルにあたってはデータマートはリニューアル前のものをそのまま用いて必要な前処理は全てUI側(Tableau内)で行っています。
Tableauでデータの前処理を行うとは？
本来はデータマートへの列追加や事前処理で対応するような案件を全てTableau内で完結して再現することを指します。
軽微なものは「◯◯の累計値を新規の計算フィールドで用意する」などですが、高度なものは「月末までの計画値をTableau内で算出しフィールドとして用意する」などです。一見高度に見えるものも、TableauでいうFixed関数など、BIツール自体にある程度の柔軟性があるため、設計を正しく行うことで難なく実装できるものが多い印象でした。
通常とは異なる開発体制を取った背景
流動的な仕様変更への追従
このようなイレギュラーな体制を取った目的は、幹部などの利用者との密なコミュニケーションを取りながらUIを流動的に変えて開発する必要があったためです。
企画段階である程度のUIイメージは固めていたものの、実データを入れると「ちょっと思ったのと違う」となるケースが想定されたので、UIの変更に最も柔軟に対応できる体制としてこの体制を採択しました。
UIの構築側でデータ処理も賄うことで、UI⇔データマート間の仕様調整稼働を大きく低減するとともに、UIレビュー中にリアルタイムにUI修正が行なうなどクイックにダッシュボードのブラッシュアップを行うことを目的としています。
BIツールを使ったダッシュボード開発のデメリットを逆手に取った
TableauなどのBIツールはGUI操作ができるために非常に高速に実装ができる反面、Gitを使ったファイル管理や統合ができないため、複数人での開発遂行が難しいといったデメリットがあります。
最初からUIが複数人で開発ができないのであれば、”ワンオペ”であることにいっそ振り切って一人に前処理とUI構築をまとめてしまったほうが早いといった判断で集約していました。
結果どうなったか？
約3週間でUIのフルリニューアルが完了！
実装から試験完了・リリースまでを約3週間で走り切ることができました。
短期間で実現できた点も素晴らしいですが、週に1〜2回程度のレビューで発生する上層部/利用者からのリクエストの9割以上を採用できる対応力の高い開発体制で終始プロジェクトを進めることができたのが一番の収穫です。
リリース後の社内の評判もよく、リニューアル前のUIと比較して約5倍の社員が利用してくれるプロダクトに進化しました。とはいえ、改善点はまだまだあるので、今後も改善を進めていく予定です。
実際のダッシュボード画面
※今回作成したダッシュボードのTOPページの一部をダミーデータで紹介します。
初期の思想の通り、主要な指標に絞って可視化し、ユーザの操作なしに最新の値が見やすいデザインにできました。企画部門の理解もあり、年月フィルタも削り最新値にこだわったシンプルなUIにできています。
TOPページのUI
TOPページ⇒詳細分析ページの流れをシームレスにわかりやすくするために、タイルUIを採用しました。
タイルと詳細分析ページを対とすることで、ユーザが詳細ページの存在と内容を理解しやすくしています。
TOPページの1タイル
最新の累計収支など、注目するべき値は進捗比ともに直接数値表示を行っています。
効果が出た部分/出なかった部分
Good:修正リクエストに対する心理的安全性の増加
開発シーンでありがちな、企画サイドのリクエストに対する修正の可否は”持ち帰らないとわからない”事象が起きなかった点は、当初想定していませんでしたが良い効果でした。
Tableauエンジニアのみで企画案の技術的対応可否を判断可能なため、MTG中即時に可否判断ができる上「◯◯はできないが△△に変えればできる」といった企画対開発間のコミュニケーションが柔軟に進みました。
そのため、企画サイドもちょっとした思いつきを開発に伝えるようになり、開発側もリクエストにも柔軟に対応できたのがダッシュボードとしてのプロダクト品質を高められた良いメリットでした。
Good:データマートの改修負荷の大幅低減
企画された機能は一旦UIレイヤのみで実装し、安定したらマートに機能を移すスキームが確立できたためデータマートレイヤが仕様変更に振り回されることが減りました。
ダッシュボードも一般的なWebサービスのプロダクト同様、「動いている物を見たらちょっとイメージと違った」ことが少なくないため、クイックに動くものを提供できる体制が構築できたのは非常に良い点だったかと思います。
Bad:仕様変更に慣用な故の試験の煩雑化/非効率化
仕様変更に慣用な開発体制の裏返しですが、試験者や試験監督者が仕様変更に翻弄され試験が効率的に進まない事象が顕著に発生していました。
特にダッシュボード開発は誤った数字を表示してしまっては元も子もないため、数値検証・試験は体制を組んで手厚く実施する必要があります。体制を組んで準備を進める思想の試験チームが、時々刻々と発生する仕様変更に追従するにはかなりの苦労を要したため、この点は相性が悪かったです。
仕様変更を許容する期間、試験で仕様変更を許容しない期間とメリハリを付けて試験を実施するべきだったように思いました。
実装者としての学びのあれこれ
計算フィールド名とコメントはこだわったほうが良い
変数名をきれいにするのはどのようなツールを使った開発であっても共通ですが、今回の開発体制にあたってはなおさら計算フィールドの名称きれいに保つかが重要でした。
BIツールでは変数間の依存関係を可視化する機能が強くないため、「この変数はなにか？」を紐解くコストが高いです。適当な名付けでも開発段階で困ることはないものの最終的なデータマートへの移管の際など、整理が甘いと技術負債になるため同様の開発体制を取る場合は意識しておくことをおすすめします。
BI側の負荷を高めてもUIの表示速度に影響なかった
検討当初、Tableau側で全ての計算を行うことに対する処理速度影響を気にしていましたが、それほど表示速度には影響がありませんでした。
今回、かなりTableau内の計算処理を実装していましたが、データマート側で予め計算処理をしていたときと表示速度に大きな違いはなく、BIツール内で効率的に処理ができているように見えています。
表示速度への影響は内部の計算ロジックより、表示するグラフ数やオブジェクト数の方が大きいため内部処理の影響度は誤差の範囲に留まるようです。
意外とBIツールだけでなんでも実装できる
実装を行った私自身、メインの業務環境がPythonやSQLなどの言語よりのツールを使うことが多いため、BIツールは”表計算ツール+αの計算ができるもの”といった捉え方をしており、どこまで企画からのリクエストを叶えられるか不安がありました。
が、実際に実装を始めてみると工夫次第でかなり込み入った処理も柔軟に再現ができています。先述の通り「月末までの計画値をTableau内で算出しフィールドとして用意する」などもやってみるとそれほど障害なく実装できました。前処理からUまで1システムで実装できるため企画と連携しつつクイックな実装を進めるにはかなり向いているツールであるように思います。
感想とまとめ
この記事ではドコモ内のカンパニー共通ダッシュボードのリニューアルに伴う企画・開発体制のナレッジ経緯をまとめさせていただきました。
ダッシュボードや分析環境はビジネス構築の基盤となるため、高速に状況が変わるビジネス環境の変化に合わせて常に改善を求められるダッシュボードの担当者/担当部門の方は多いかと思います。
フットワークよく開発・企画を進める方法にお困りの基盤部門担当の方へのヒントや参考になりましたら幸いです。
- スマートライフカンパニーとはドコモの「金融・決済」「映像・エンタメ」「電力」「メディカル」「XR」など新たな生活価値・ライフスタイルを創出している事業部門です。詳しくはドコモのスマートライフ事業についてを参照ください。↩
