高速な開発とデータ品質のトレードオフを超えるためにできること

このnoteでは、事業立ち上げ期の高速な開発とデータ品質の間に発生するトレードオフに、限られたリソースで対処するために取り組んだ内容について紹介します。

はじめまして。Ubie Discoveryで機械学習エンジニアをやっている望月(@smochi_pub)です。
Ubieに一人目のデータ人材として入社して、BI的なデータ整備・活用から予測アルゴリズムの開発まで幅広く担当してきました。

Ubieでは、アルゴリズムの検証や学習のために、初期からデータを貯めることを意識して取り組んできました。その過程で、高速にUIや仕様が変わっていくプロダクトを抱えつつ、データを「正しく」貯めることの難しさも体験してきました。

高速な開発とデータ品質のトレードオフ

開発チームは高速に検証を行うことにフォーカスしているため、UIや仕様もどんどん変わって行きます。実際にユビーでは、toC向けのAI受診相談ユビーでは年間600回、toB向けのAI問診ユビーでも年間150回という恐ろしいリリース頻度で開発を進めています。

高速な開発は事業としては当然嬉しいことですが、データ品質の観点では次のような課題が発生する頻度も増えます。

1. ログの実装がプロダクトの仕様と一致せず正しく記録されない
2. UIやオペレーションの変更で、ユーザの意図がデータに正しく反映されていない
3. 集計に使うロジックが、プロダクトの仕様変更によってビジネス的に意図したものではなくなる

単純にアプリケーションのログ機能自体に単体テストを書いたり、デプロイ時にQAで確認したとしても、リリース後に発生する2や3の課題を予見して検出するような仕組みを作ることはかなり難しいです。

データ品質が担保されない状況では、データを学習や意思決定の材料として活用することも難しく、ただ管理コストがかかるだけのゴミになってしまいます。
リソースが限られたスタートアップで、こうした課題に立ち向かうために、Ubieではいくつかの取り組みを行ってきました。

■ ルールで判断できる異常を素早く検知するテストクエリ

プロダクト開発と同様に、テストには絶大な効果があります。
ただし、このテストはコードに対してのテストではなく、データに対してのテストです。

UbieではアプリケーションのDBからdbtやAirflowによるデータパイプラインを通じて、BigQuery上に分析に必要なデータやデータマートが記録されています。

データパイプラインの最後にテストクエリの実行を追加して、異常がある場合はSlack等に通知が来て対応できるようにしています。

リソースが限られた状況で、データパイプラインが未整備であれば、BigQueryの場合、簡易的にScheduled Queryを使うこともできます。
規模が大きくなると管理が難しくなるので、いずれきちんとデータパイプラインを構築して管理すべきですが、急場を凌ぐ方法としてはありだと思います。

Ubieでは

- 日次更新系のテーブルで新たなトランザクションがゼロ
- マスターに存在しない変数の組み合わせがログに存在している

といったような、簡単なルールで判定できる異常のテストクエリから設定していきました。

ルールで判断できる異常を、一度設定すれば、以降あまりコストをかけずに防ぐことができるテストは、リソースが限られた状況ではありがたい存在です。
ただし、特定の状況で欠損していたり、判断にビジネス的な知見が必要な異常では、この方法でテストを設計することが難しいという問題もあります。

■ 単純な通知は止めよう、次の打ち手に繋がる通知設計

簡単なテストルールの設計が難しい異常では、疑わしい状態を通知して担当者が素早く判断できる状態にすることも有効です。
ある指標の変動や減少がとても大きく、週平均XX%以下、対前週比YY％以下などの条件がそれに当たります。

Ubieでは、通知用のクエリを用意して、redashのアラート機能に設定して使っています。任意の更新間隔でクエリを実行して、slackへの通知が可能で便利です。

このやり方は、通知で終わらない仕組みを設計することが大事です。ネクストアクションが決まってない通知には意味がないです。
次にやるべきことが決まっていないと、通知が放置され続け、オオカミ少年のようになってしまいます。

当たり前のことかもしれませんが、

- 担当を決める
- 担当がアクションできるための情報を付与する

を意識した仕組みを作ることが重要です。
担当の決め方としては、次のような方法があります。

1. 通知作成時に、チケット完了条件に担当者の決定までを入れておく
2. スクラムのセレモニーやチェックリストに通知の確認を入れておく
3. エラー対応担当を週次持ち回りで決めておく

Ubieでは、どの方式も存在していて、スクラムを採用してる開発チームでは2,3、ビジネスチームでは1が多いです。
チーム人数やエラー通知を見て対応できる人間の数などによって決めると良いと思います。

担当者がアクションするための情報として、

- 通知が何の条件によって発生しているのか、日本語で分かるようにする
- 通知に複数の発生要因がある場合は、何に起因するか分かるようにする
- 異常の詳細な状況を確認できるダッシュボードのリンクを貼っておく

などを意識しています。
特にビジネス系チームの担当者に向けた通知の場合は、こうした工夫をしておくことで、すべての初動で通知開発者に連絡がきてパンクする、自分では状況判断できない通知として無視される、といった状況を回避できます。

■ データ活用を全員が自分ごと化できる状態を目指す

データチーム以外が活用しないログやデータマートを作ると、データ品質の維持・管理に対して注意を払うことができるのがデータチームだけになり、非常に負担が高くなります。

特に高速な開発によってデータを生成するUIや仕様がどんどん変化する状況では、開発チームにいない人間がそれをキャッチアップして維持・管理していくコストは、相対的にとても高く感じられます。

データ品質に関心を持つ人を増やすことができれば、データチームのみが注意している場合より対応コストは下がり、異常の発見確率も相対的に向上します。
そのためには、データ活用がデータチームのみの関心事ではなく、開発やビジネスチームの活動の起点として自分ごと化された状況を作っていくことが重要です。

データを自分ごと化してもらうために以下のような取り組みが有効でした。

1. データマートを整備する
2. RedashやTableau等のGUIで確認できる仕組みを整える
3. 分析作業(SQL, Tableau等）のペアプロを実施する

1を実施することで、開発チームにはSQLを書ける人間もたくさんいるので、自然とデータ活用が活発になり、チケットにデータ品質に関する完了定義が入るようになりました。

また、2や3を実施することでビジネス系チームでもデータ活用が可能になりました。
複雑なSQLをスクラッチで書くことは不可能でも、ベースとなるクエリに改変を加えたり、GUIの操作によって自分に関心のある分析作業ができるようになると、データ品質を自分ごと化するメンバーが増え、日々の分析によってデータの異常が素早く検出されます。

実際にビジネスチームのメンバーの分析によって、予期しずらい状況での異常が検知され素早く対応されることが増えました。
もちろん、異常な状態が全く起きない状態を目指すことは重要ですが、異常な状態が素早く発見されることによってデータ品質に大きな影響を与えずにすみます。

テストや通知などで異常を検知する仕組みも重要ですが、データ品質に関して注意を払う人間を増やしていくことが、限られたリソースの中でデータ品質を守る手段としては有効な一手になると感じています。

まとめ

今回はユビーが高速な開発とデータ品質のトレードオフを超えるために、取り組んできたことについて紹介しました。

- ルールで判断できる異常を素早く検知するテストクエリ
　- 分かりやすい致命的な異常をコストをかけずに防ぐ
- 次の打ち手に繋がる通知設計
　- ネクストアクションが決まってない通知には意味がない
- データ活用を全員が自分ごと化できる状態を目指す
　- データ品質に関心をもつ人間を増やして、維持管理コストを下げる

今後もスタートアップの様々な制約下における、データ活用事例について共有できる内容があれば、記事を発信していきたいと思います。

価値あるデータの獲得、整備、活用、すべてのプロセスに興味のある方へ

Ubie Discoveryでは、あらゆる職種で積極的に採用行っています。
この記事を読んで一緒にデータドリブンなプロダクト開発をしていきたいと思われた方は、ぜひ採用サイトをご覧ください。
オンライン会社説明会やカジュアル面談をやっています。

Ubie 採用サイト