使われないダッシュボードを生まないためのプロジェクトマネジメント / Project management to avoid creating unused dashboards

Sansan R&D

August 09, 2024

Tweet Share

Transcript

1. 使われないダッシュボードを ⽣まないためのプロジェクト マネジメント Google Cloud Next Tokyo '24

2. - ダッシュボード構築におけるよくある失敗 - ダッシュボード構築における5 つの Phase - プロジェクトマネジメントにおける Key Factor

   アジェンダ

3. 坂⼝ 遥 Yo Sakaguchi Sansan株式会社技術本部 研究開発部

4. ダッシュボード構築における よくある失敗

5. よくあるダッシュボード構築：パターン 1 4 依頼 依頼 営業/CS PdM / 営業企画 /事業企画

   データエンジニア スプシで⾒てるんだけど、 データを⾃動更新したり、 ⾒た⽬をよくしたいから ダッシュボードにして！ ダッシュボード作りたいけ ど、データが⾜りないから 新しく連携して！ついでに 必要なテーブルも作って！

6. よくあるダッシュボード構築：パターン 1 5 営業/CS PdM / 営業企画 /事業企画 データエンジニア 提供

   提供 とりあえず依頼内容をこなすか、、、 ダッシュボードの要件が あまりわからないけど、、

7. よくあるダッシュボード構築：パターン 1 6 依頼 依頼 営業/CS PdM / 営業企画 /事業企画

   データエンジニア なんか思ってたのとちょっ と違うのと、こういう要素 もほしいので改修してほし い！ 頼んだ！

8. よくあるダッシュボード構築：パターン 1 7 営業/CS PdM / 営業企画 /事業企画 データエンジニア この改修内容だと

   テーブルの構造を⼤きく変えないと いけない、、、

9. よくあるダッシュボード構築：パターン 2 8 依頼 営業/CS PdM / 営業企画 /事業企画 データエンジニア

   新しいダッシュボードを 作ろうと思っているので、 テーブルを作ってほしい！

10. よくあるダッシュボード構築：パターン 2 9 営業/CS PdM / 営業企画 /事業企画 データエンジニア 提供

    提供 こんなダッシュボードを 作ってみたのでよかったら 使ってください！ とりあえず依頼内容をこなすか、、、 ダッシュボードの要件が あまりわからないけど、、

11. よくあるダッシュボード構築：パターン 2 10 営業/CS PdM / 営業企画 /事業企画 データエンジニア 良さそうなダッシュボードだけど、

    どこでどう使えばいいんだろう、、、

12. 積み上がる使われているかわからないダッシュボード 積み上がる似たようなテーブル それに伴い、肥⼤化する運⽤保守コスト - 現場ではダッシュボードを使って何かしたいという思いはある - ダッシュボード企画者は良いものを届けようと努⼒はしている - 実装者は依頼にスピーディーに答え、依頼内容を忠実に実装する その結果、、、

    11

13. なぜこうなってしまうのか？

14. ダッシュボードはデータと合わせた⼀つのプロダクトと 捉え、ソフトウェア開発の御作法などを取り⼊れていく - BI ツールの発展によってダッシュボードを作るハードルはどんどん下がっている - ⼀⽅で、ダッシュボードそのものや、ダッシュボードの裏側のデータのライフサイクル は、下⼿するとサービスやプロダクトよりも⻑いことがある - そのため、容易に負債化してしまう

    ダッシュボードの捉え⽅/扱い⽅を変える 13

15. ダッシュボード構築における 5 つの Phase

16. Phase.0 探索、現状調査 Phase.1 要求定義、要件定義 Phase.2 PoC 開発、仮説検証 Phase.3 試運転、モデリング開始 Phase.4

    本番稼働、運⽤保守 5 つの Phase とPhase ごとの有効なツール 15 Looker Studio Looker Looker Google Sheets

17. Phase を進めていくにあたって、柔軟かつ保守性の⾼い Backend 群を選定する 16

18. 想定ユーザーにヒアリングを⾏うが、多くの場合、何も数値を⾒ていないということはな い。現場で使われている Google Sheets などに⼤きなヒントが隠されている Phase.0 探索、現状調査 17 覚悟を決めて、運⽤されている Google

    Sheets を解読する ヒアリングを⾏う対象は 幅広く

19. 要件において最も重要なことは、そのダッシュボードや数値を⾒てユーザーが 何をするのか、ということである Phase.1 要求定義、要件定義 18 誰が⾒るのか？ Who When How Much

    いつ⾒るのか？ どれくらいの頻度で ⾒るのか？ どのような形で ⾒るのか？ How What Why/So What 何の数値を ⾒るのか？ ⾒た上でどんな アクションを取るのか？

20. Quick and Dirty を⼀定許容し、⾼速で PDCA サイクルを回していく この Phase は Google

    Sheets や Looker Studio など変更が容易なものを採⽤する Phase.2 PoC 開発、仮説検証 19 Looker Studio Google Sheets Lake Table Lake Table Lake Table Lake Table DWH Table

21. ユーザーからフィードバックをもらいつつ、DWH の要件を⾒極めていく データモデリングを⾏うことによって、ELT の柔軟性/保守性が増していく Phase.3 試運転、データ モデリング開始 20 Looker Studio

    Google Sheets Lake Table Lake Table Lake Table Lake Table DWH Table DWH Table DWH Table DWH Table Cloud Composer dbt

22. 本番稼働する前に、データ加⼯の責務と範囲を明確にする 可能な限り、データの加⼯処理は ETL/ELT に寄せた⽅が保守性は⾼くなる Phase.4 本番稼働、保守 21 Looker Studio Lake

    Table Lake Table Lake Table Lake Table DWH Table DWH Table DWH Table DWH Table Cloud Composer dbt Data mart

23. プロジェクトマネジメントに おける Key Factor

24. ステークホルダー マネジメント アジャイル ソフトウェア開発 ダッシュボードのアウトカム定義 ダッシュボード構築を成功に導くKey Factor 23

25. プロジェクト マネジメント全般に⾔えることだが、キーマンの⾒極めと巻き込みは同様に 重要である。また、ボトムアップでのアプローチは可能だが、時間がかかる可能性がある ステークホルダー マネジメント 24 意思決定者 / エバンジェリストを プロジェクト⽴ち上げ当初から

    巻き込む よりスピードを求めるな ら、トップダウンでアプ ローチする

26. 序盤の Phase において、ビジュアライズへのこだわりは⼀切不要。Quick and Dirty を許 容し、PDCA を⾼速で回し、不確実性をいかに削減できるかが重要になる アジャイルソフトウェア開発 25

    表形式でも要件を 満たせることはある PDCA を回し、 不確実性を削減する 過度なビジュアライズへの こだわりは不要

27. アクションに繋がらないダッシュボードに価値はない。アクションを取れたとしても、何 かしらのアウトカムを⽣み出せないのであれば、改善の余地がある。 “綺麗なダッシュボード” ができたら、プロジェクト終了では決してない ダッシュボードのアウトカム定義 26 作って終わり、ではなく ユーザーと共に ”育てていく” ユーザーのアクションに

    繋がるダッシュボードを⽬指す

28. 主に CS・営業が担当顧客へのアプローチの際に活⽤している。 また、随時利⽤者からのフィードバックをもらい、改善を続けている。 Bill One での事例紹介 27 請求書受領/発⾏数の推移を元に アップセルの提案に繋げる

29. Summary

30. ダッシュボードやデータを加⼯する How は様々だが Phase に応じて使い分けることが重要である ユーザーと共にデータ活⽤によるアウトカムを、 ⼀歩ずつ愚直に積み上げていくことが最も近道な⽅法である Summary

31. We are hiring! 研究開発部 採⽤情報 https://media.sansan-engineering.com/randd 30

32. None