少人数で立ち向かうダッシュボードQC効率化

BIサービスの立ち上げは、ダッシュボードの開発速度を上げながらも間違ったデータを提供しないことが求められました。
この矛盾する要求に対して、どのように取り組んだかを紹介します。

※2026-1-29 に行われた「三田データ」の登壇資料です。

Transcript

1. © 2025 ANDPAD All Rights Reserved. 少人数で立ち向かうダッシュボードQC効率化 2026/01/29　三田データ Kazuya Ohora
2. 2 1. ANDPADのプロダクト紹介 2. Andapd Analyticsの紹介 3. 初期のQC 4. 現実解を考える 5. 実際にやったこと 6. 成果と今後の課題 Agenda
3. Confidential Confidential 自己紹介 3 2021年入社以来、データエンジニアとして、データ基盤の開発や運用に従事。2023年 からダッシュボードサービス「Andpad Analytics」の開発も行っている。 
 大洞 和也
 所属
 現業
 データ部 DataPlatform グループ Data Engineer 
 ラーメン / ゲーム/ 猫 
 趣味

4. 1. ANDPADのプロダクト紹介
5. Confidential © 2025 ANDPAD All Rights Reserved. 現場の効率化から経営改善まで一元管理できる クラウド型建設プロジェクト管理サービス 社　内 社　外 営業 / 監督 / 設計 事務 / 管理職 職人 / 業者 メーカー / 流通 案件管理 資料 工程表 写真 報告 チャット 黒板 図面 受発注 •　•　• 
 5 ANDPADとは
6. © 2025 ANDPAD All Rights Reserved. 6 Vertical SaaSのビジネスモデル 注⽂住宅 設備⼯事 マンション修繕 ディスプレイ ゼネコン 分譲住宅 リフォーム 利用企業数 ユーザ数 23.3万 社~ 68.4万 人~ 建設業界における様々なセクターの企業・ユーザー様にご利用頂いています
7. © 2025 ANDPAD All Rights Reserved. 7 マルチプロダクト展開 現場管理を効率化したい 工事写真の撮影・整理・台帳作成を効率化したい 顧客と円滑にコミュニケーションしたい ・ 顧客への提出物をスムーズに作成したい 工程管理の手間を 減らしたい 円滑にコミュニケーショ ンしたい 検査や是正指示を 効率化したい 経営・営業データを 可視化したい 受発注・請求書受領を 効率化したい ｚ 社内での承認フローを 効率化したい 断熱リフォームの効果を 可視化したい 現地調査を効率化したい 現場訪問の回数を 減らしたい 安全衛生管理を 徹底したい 社外リソースを 活用したい システム連携で効率性を 上げたい 施工管理 案件概要 資料 ボード 写真 写真台帳 黒板 黒板 AI作成 豆図AI キャプチャー デジタル サイン 報告出力 レイアウト 電子納品 おうちノート 工程表 横断 マイルストーン チャット 報告 図面 検査 Analytics 引合粗利管理 受発注 請求管理 資料承認 サーモ 3Dスキャン 遠隔臨場 入退場管理 BPO API連携 アプリ マーケット
8. 2. Andpad Analyticsの紹介
9. 9 Andpad Analyticsとは Andpadに蓄積されたデータを可視化するダッシュボードサービスです。(製品紹介)
10. © 2025 ANDPAD All Rights Reserved. ダッシュボードの種類 求められるダッシュボードは多種多様なため、スピード感のある開発が大事 10 • 新築 • リフォーム • ゼネコン • 設備 セクター • 施工管理 • 引合粗利管理 • 図面 • チャット プロダクト • 企業の規模 • 職種 • 利用の深さ その他 多数のダッシュボード
11. 3. 初期のQC状況
12. © 2025 ANDPAD All Rights Reserved. 12 (前提) 技術スタック プロダクト データ加工 Dashboard BigQuery dbtで加工してLookerで可視化する構成
13. © 2025 ANDPAD All Rights Reserved. 13 初期のやり方 • 初期はQCチームに依頼をしていた ◦ 初期はダッシュボードのページの権限の設定など専門的なQCが必要だった ◦ ダッシュボードのチームはダッシュボード開発そのものや環境整備などに注力してい た • 専用の環境に実データを生成し、すべての挙動をダッシュボードで確認していた ◦ 顧客向けのダッシュボードで他の効率的な方法を見つけられていなかった 初期のQCシート
14. © 2025 ANDPAD All Rights Reserved. 14 当時の課題感 • QCチームに依頼しているための非効率さがあった ◦ 仕様やスケジュールなどについてコミュニケーションコストが発生した ◦ QCチームのスケジュールにこちらの開発スピードが依存してしまう状況であった • テストの準備に膨大な時間がかかっていた ◦ ケースの準備 ◦ 正しい集計値の準備 ◦ データの準備 ◦ etc 早急にチームでのQC方法の確立と効率化が必要
15. 4. 現実的な方法を考える
16. © 2025 ANDPAD All Rights Reserved. 16 どうやって効率化するか 1. テストの観点の明確 a. テストしたい観点ごとにどれくらい大事か評価できる b. テストの観点を細分化することで代替がしやすくなる 2. テストサイズを小さくする a. テストピラミッドの考え方を参考にし、大きいテストを小さくしていく i. 現状はプロダクト + dbt + Lookerにまたがるテストなので大変 ii. dbtやLookerで完結するようなテストなら楽になる iii. 自動テストにできるととてもうれしい 3. テスト済みのコンポーネントの再利用 a. 一度検証したコンポーネントは信頼度が高いので再利用したい
17. © 2025 ANDPAD All Rights Reserved. 17 考え方①: テストの観点の整理 観点 重要度 取り組み方 データを他の顧客に見せない 絶対に避けたい 意識しないでも守れる仕組み を作る ダッシュボードが動作する なるべく避けたい 守らないとリリースできない 仕組みを作る ダッシュボードが正しい数値 を返す 出来れば避けたい 大切にしつつ効率も考える
18. © 2025 ANDPAD All Rights Reserved. 18 考え方②: テストを小さくする ローカルで実現できるテスト dbt: unit test、sqlfluff (sql lint) Looker: Lams 一つのサービスで完結 するテスト 統合 テスト dbt: data test Looker: Looker test, Spectacles スプシでの数値確認 なるべく減らす
19. © 2025 ANDPAD All Rights Reserved. 19 考え方③: テスト済みの機能の再利用 • テスト済みのコンポーネントをうまく再利用することで効率化できそう • dbtとLookmlは両方ともSQL加工という点で似ている • うまく責務を分けることで共通層を構築できそう ◦ dbt ▪ Lookerで変動しないデータ加工全般が責務 ▪ レコードを絞り込まないワイドテーブルとして実装する • Lookerで列や行を絞り込む方が柔軟なため ◦ Looker ▪ 共通view • 複数のダッシュボードで使う列や指標を定義する ▪ 個別view • 共通viewからextendsする。(継承する。) • ダッシュボードごとに用意する • そのダッシュボードで必要な列の取得や特異なデータの実装をする
20. 5. 実際にやったこと
21. © 2025 ANDPAD All Rights Reserved. 21 dbtでの品質担保 • レコードが想定通りの数になっていること ◦ data tests : relationshipsを利用する ◦ 特定のエンティティのテーブルに情報を付けてワイドテーブルとするケースが多いの でうまくいっている • レコードの変換がうまくいっていること ◦ unit testを利用する ◦ それなりに実装が大変なので複雑なクエリに対して実装する • unique制約が守られていること ◦ data tests: uniqueを利用する おおよそ正しい加工ができているといえそう
22. © 2025 ANDPAD All Rights Reserved. 22 Lookerでの品質担保① Looker testによって他の顧客のデータが混ざってないことを担保 更にGithub Actionsでテストの実装を強制した test: report { explore_source: report { column: customer_count { field: report.customer_count } } assert: customer_one_or_less { expression: ${customer_count.customer_count}<= 1;; } } report.test.lkml .github/workflows/validate-test-files- existence.yml
23. © 2025 ANDPAD All Rights Reserved. SpectaclesというLookerのCIツールを利用する • SQLのチェック ◦ dimension(列)が実際にクエリできることを確認する • Contents validation ◦ ダッシュボードが壊れていないかを検知可能 ◦ 利用しているdimension(列)やmeasure(指標)がない場合などにエラーになる ◦ parameterによってダッシュボードが動的に変わる場合は検知できない 23 Lookerでの品質担保②
24. © 2025 ANDPAD All Rights Reserved. ダッシュボードが適切に設定されているか • 観点 ◦ measure(集計値)が適切に定義されているか ◦ フィルターなどの設定が適切に設定されているか ◦ パラメーターを切り替えたときに適切に動くか • やること ◦ 設定値の確認 ◦ パラメーターの全パターンでの動作確認 ▪ いくつかのパターンでの集計値の確認 24 QCフェーズで確認すること
25. © 2025 ANDPAD All Rights Reserved. 25 最終的なテストのまとめ システム 観点 手段 dbt データのunique性 dbt data test レコードの数 dbt data test レコードの変換 dbt unit test Looker dimensionの動作 spectacles データの漏洩回避 Looker test dbt + Looker ダッシュボードの設定 統合テスト(手動テスト) 手動テストの部分は大幅に削減された
26. 5. 結果と今後の課題
27. © 2025 ANDPAD All Rights Reserved. 27 得られた結果 • QC期間の大幅な短縮 ◦ 2週間 → 1週間 ◦ 統合テストのパターンが大幅に削減された ▪ データの準備 ▪ ケースと正解の検討時間 • QCの信頼性と安定化 ◦ QCを整理していくなかで、どこまで品質担保できているかチーム内で確認することが できた ◦ 設計の効率化にもつながった
28. © 2025 ANDPAD All Rights Reserved. 28 まだ残っている課題 • テストノウハウの共有不足 ◦ BIエンジニア、コンサルタント、アナリストなどのバックグラウンドのメンバーも多い ◦ QCの知見が多い人ばかりではなく、テストノウハウの共有が課題 • テストのメンテナンス ◦ 基本的に統合テストは再利用できない ◦ リファクタリングや機能改善のたびにどこまでやるか検討しないといけない ◦ ダッシュボードのデグレは現状でも課題
29. © 2025 ANDPAD All Rights Reserved. 29 今後やりたいこと • リグレッションテストの実装 ◦ 何もしていないのに壊れるケースへの対応 ▪ 予期せぬプロダクトの変更 ▪ LookerのupdateによるUIの変更 ◦ リファクタの効率化 • LAMS(Lookmlのlinter)のカスタムルールによる拡張 ◦ 今までのナレッジの強制 ◦ ダッシュボードの設定ルールの統一 ▪ Lookerはダッシュボードがコード管理できる ▪ 統一すべき仕様についてlinterで確認ができる(かも) • テストの定型化 ◦ なるべく、テストに関する知見について考えないでも実行できるように
30. © 2025 ANDPAD All Rights Reserved. 30 まとめ • ３つの観点からダッシュボードのQCを効率化した取り組みを紹介しま した ◦ 担保したい観点を分類していく ◦ なるべく小さいテストに分解していく ◦ 使えるものはなるべく再利用していく • ある程度スピードと品質を両立している一例として、参考になれば幸 いです
31. © 2025 ANDPAD All Rights Reserved. 31 ご清聴ありがとうございました！ https://engineer.andpad.co.jp/