こんにちは！アンドパッドのデータ部でデータスチュワード/データアナリストをしています中野です！今年の5月にアンドパッドにジョインして大体100日くらい経ちました！最近は、カスタマーサクセス向けのダッシュボードの運用など、データの運用に関わるプロジェクトでPMをしています。今日は、社内向けに公開したBIダッシュボードを、公開後も長く使ってもらい続けるための運用の取り組みを紹介したいと思います。
Motivation
まず前提からお話します。
データ部はデータ・ドリブンな社内環境/文化の構築をミッションの一つに据えています。そして、その取り組みの第一歩として、カスタマーサクセス向けに顧客の機能利用度がわかるようなダッシュボードを作成し、いつでも確認できるように公開しています。
同じようにBIツールを用いたダッシュボードの導入は、世間での需要も多く、近年では体系だった方法論も書籍化されてきているという印象です。一方で、導入後の運用のノウハウについては、まだまだ十分に蓄積されていないような印象を受けます。
そのため、今回はアンドパッドのデータ部で実施されているダッシュボード運用の取り組みについて、ジョインして大体100日くらい経った人間の目線から「学びになるなぁ」と思ったこと、そして、今後さらに運用を安定化させていくために、PMの視点からやっていきたいと思っていることをいくつかご紹介したいと思います。
会議体の設置
まず、アンドパッドのデータ部で特徴的だと思ったのは、ダッシュボードの構築プロジェクトとは別に、「ダッシュボード改善運用」という会議体を設置していることです。基本的に構築プロジェクトと改善運用とで主要メンバーは変わらないのですが、あえて「違う会議体」という形で、プロジェクトを区切っています。
こうして区切ることによって、構築プロジェクトの目的は「ダッシュボードを実装して公開すること」、改善運用の目的は「ダッシュボードを運用すること」であるというふうに目的の違いを際立たせることができます。また、運用から入った身としては、構築プロジェクトに参加していないメンバーでもスムーズに運用に入れたりと、運用メンバーの入れ替えがしやすいというメリットも感じています。
運用の柱としては、「改善運用」の定例会議を毎週実施しています。定例では、今週どんな問合せが来たとか、あの要望への対応状況はどうかとか、そういう話をしています。
要望の分類
ダッシュボードを公開した後は、たいてい利用者からいろいろな要望が来ると思います。データ部では、これらの要望を「改善要望」「追加要望」「小規模案件」の3つに分類しています。ざっくり以下のような建付けです。
| 種別 | 解説 |
|---|---|
| 改善要望 | すでにある指標やグラフに関して、「定義をこう変えてほしい」「グラフの見た目を変えてほしい」などの要望 |
| 追加要望 | 「新しいグラフを追加してほしい」「新しい指標を追加してほしい」というような、新しいものの追加要望 |
| 小規模案件 | ダッシュボードの一部として新しいページを作ったり、要件が複雑だったりして、実現にある程度工数がかかったりする要望 |
もちろん、分類するだけでなく、それぞれに対する対応の仕方も異なります。 例えば、追加要望・改善要望は軽いものが多いので、大体1~2週間でプロジェクトメンバーの誰かひとりに対応をしてもらうという形ですが、小規模案件の場合は重いタスクになりがちなので、きちんとPMを置き、ステークホルダーと一緒に要件を定義し、WBS作ってスケジュール引くなど、ミニプロジェクト的な扱いで進めます。
分類して整理しているからこそ、対応方針を立てやすいという側面があると感じています。
ドキュメントの整備
ある種当然のことかもしれませんが、ドキュメントの整備は運用において本当に大切だと感じました。データ部では、以下のようなドキュメントが作成されています。
開発者向け
- データ基盤まわりの基本設計(共通基盤と異なる部分がある場合)
- テーブル設計
- リリース手順
- 問合せの対応例
利用者向け
- 各指標の定義書
- 利用ガイドライン
- 閲覧権限のルール
利用ガイドラインには、初回説明会の資料とか、問合せの仕方、FAQなど、ダッシュボードを初めて利用する人にとって役に立つ情報をまとめます。そのほか、顧客データというセンシティブなものを扱う性質上、閲覧権限を設けるのですが、その制限の仕様であるとか、権限申請の仕方とかもドキュメント化して公開しています。特に閲覧権限に関しては、組織や利用者層の拡大に伴ってルールが複雑化していく傾向があるので、ドキュメント化しておくのは重要だと感じました。
忘れがちだけど重要だと感じたのが、リリース手順書です。ダッシュボードを公開した後に、要望対応のたびに何らかのリリースをすることになるので、リリース手順をきちんとまとめておくのはどんなダッシュボードを作る際にも重要です。また、ダッシュボードの利用が日々の業務に組み込まれていくと、突発的なリリース作業が業務影響を与える場合もあると思うので、リリース日のルールとか、リリース運用フローを整備して手順書に明記おくのは、リスク回避にもなるのではないかと思います。
問合せ窓口の設置
利用者からの要望・質問を吸い上げるために、窓口を設置するのは重要です。私の携わっているプロジェクトでは専用のslackチャンネルを開設しています。また、要望や質問を挙げる対象が人間である以上、利用者が遠慮してしまい要望を吸い上げづらいということも考えられます。データ部では、slackチャンネルに要望用・質問用のワークフローをそれぞれ設けています。これだけでも「人間を介している感」が薄れるので利用者目線では質問しやすくなりますし、質問・要望に対する対応履歴も残るので、運用を引き継ぐ際にも役立ちます。
利用度のモニタリング
利用者の情報を収集し、運用者向けのダッシュボードにまとめて、毎週確認しています。 ダッシュボードの利用者の増減があれば、その原因調査をして、課題を抽出し、利用度を上げるための対応をします。
悲しいことに、世の中には「せっかくダッシュボードを作ったけれども、あまり利用されなかった」というような事例が山のようにあるようです(私も経験があります)。利用者にとってはデータを確認することは主業務ではないですから、日々の業務に対処するうちに、だんだんとダッシュボードを見なくなっていくのです。そうした危うい兆候は、組織別に利用度をモニタリングすることで、早い段階で捉えることができます。もしダッシュボードの利用が業務にきちんと組み込まれていれば、例えば毎月の月初めには閲覧数が増えるなどの傾向も見えてくるので、少なくとも週次・月次での利用者数の統計を取るのがおすすめです。
これからやっていきたいこと
ここまで、ダッシュボード運用で実際にやってきた取り組みを紹介してきました。ここからは、さらに運用を安定化させるために、今後やっていきたいと思っていることをお話ししたいと思います。
ダッシュボードの運用の安定化とは？
「ダッシュボード運用の安定化」を一言で要約するとしたら、「要望・問合せ対応をデータ部の定常業務にすること」だと思います。
そもそもデータ部の立場からすれば、ダッシュボードは組織のデータ活用を推進するための、数ある施策の一つという位置づけです。そのため、一部の部門向けのたった一つのダッシュボードだけでなく、色々な部門向けに色々な目的でダッシュボードを展開していきたいですし、そうした施策がひと段落ついたら、次はどんどん高度な分析をしていきたいというのが本音です。そういうわけで、ダッシュボードの運用にかける労力はなるべく軽く、それでいて安定的に要望への対応ができる状態を目指して、定常業務の一つに落とし込むことが重要だと思っています。
アンドパッドでは、まだそのレベルには達していませんが、いくつか考えていることを挙げていきたいと思います。
問合せ当番制の導入
開発に関する知識は、どうしても開発を担当したエンジニアやアナリストに集中してしまいがちです。 そのため、いくらドキュメントを整備しても、導入プロジェクトが終わった段階で属人化を避けるのは難しいものです。しかしながら、これを解消しなければ、長く使われるダッシュボードを維持するのは困難です。
データ部では、属人化解消のために、週替わりで問い合わせ当番を決めて、slackチャンネルに来る質問への対応をしてもらう、という当番制をつい最近導入しました。正直導入には不安がありましたが、ある程度ドキュメントを整備したらもうあとはやるかやらないかの問題ですし、開発者がサポートできる余裕があるうちに対応体制を整えるのが重要なので、早めに進めました。少々荒っぽいのですが、「当番をして知識をつけよう」というスタンスなので、なんと入社後1~2ヶ月くらいでもう当番が回ってきます。
小規模案件の標準化
先述のように、ダッシュボードに新しいページを追加するなどの要望は、小規模案件として分類し、ミニプロジェクトのように進めると紹介しました。小規模案件の大半は、新しいプロダクトの販促に伴って、その機能利用度をモニタリングするために新規ページを追加してほしいという要望です。ANDPADは、建築業界向けのVertical SaaSであり、業界の課題解決に沿って複数の製品群を提供しているという性質上、多種多様な機能やプロダクトが日々リリースされています。そのため、この種の、「新規ページを追加する」という小規模案件は今後も絶えることなく発生し続けると考えられます。
一方で、こうした要望に対しては、ステークホルダーの特定から始まって、 要求事項の洗い出しや要件定義、実装、ドキュメント整備などといった手順がだいたい決まってくるため、一種の「製造ライン」のようにみなせそうなことがわかってきました。そこで、それぞれの手順でやることを明確化して、大体の標準工数も決定して、プロセスを標準化することで、誰が担当になっても対応できるようにすることで、今後の運用の安定化につなげたいと思っています。
データガバナンス強化
複数のダッシュボードを複数の組織に展開していくと、「あちらのダッシュボードの指標Aはこういう定義だが、同じように見えるこちらのダッシュボードの指標A'は定義が微妙に違う」とか、「あっちのダッシュボードとこっちのダッシュボードとでどういう使い分けをしたらいいかわからない」というような、利用者の混乱を引き起こす問題が出てきてしまいます。
こうした問題に対して、プロジェクト間で連携をとって指標の定義を統一させたり、それぞれのダッシュボードの目的をよりシャープにしたり、使い分けのルールの整備をしたりして、利用者にとって混乱のない状況を作っていきたいと思っています。
最後に
アンドパッドのデータ部では、いっしょにダッシュボードを運用・改善して、データ活用をさらに高度に導いていってくれる仲間を募集しています。現在はどんどん社内でのデータ活用が拡大しており、学びも多い状況です！今ジョインしたらめちゃくちゃダイナミックで楽しいと思いますので、ぜひエントリーしてください！お待ちしております！
