香りECスタートアップにおける データの更新によって生まれた データ負債事例と学び

Transcript

1. @High Link, Inc. 香りECスタートアップにおける データの更新によって生まれた データ負債事例と学び
 2024/03/26 @ Offersデータ構造x技術負債LT vol.2 nogaken (@nogaken1107)
2. 自己紹介
 • 名前: 野川賢二郎 (@nogaken1107) 
 ◦ 株式会社High Link 執行役員CTO 
 • 経歴: 株式会社LINE → 株式会社High Link 
 ◦ ハイリンクには初期フェーズに入社し、今回のテーマ となる、データ負債の発生と解消に当事者として経 験してきました
 • 趣味: 
 ◦ 歩く
 ▪ 昨年はエクストリームウォークというイベントで 25時間かけて100km歩きました 
 • おすすめ（ しません）
 
 2
3. はじめに：今日話すこと
 • カラリアにおいて、データの更新によって生じたデータ負債の事例について紹介 
 ◦ アンチパターン“消えた事実”によって生じた負債 
 • どうしたらデータ負債が発生すること/大きくなることを防げたか？ 
 • 弊社が組織として取り組んでいる、負債とうまく付き合うための取り組みを紹介 
 3
4. 目次
 • プロダクトの紹介
 • 生じた問題
 • どう解消していったか 
 • どうすれば負債が生まれることを防げたか？ 
 • どうすれば負債が大きくなることを防げたか？ 
 • 組織としてデータ負債を生みにくく/大きくしないための取り組み 
 
 4
5. プロダクトの紹介
 5 5
6. 6 6
7. カラリア 香りの定期便
 7 • 香水を中心とした香り商品のサブスク 
 ◦ 約1000種類の商品の中から毎月ユーザーが好きなも のを選べて、楽しめる 
 ◦ 目に見えないからこそ難しい 「香りとの出会い」をテク ノロジーを活用することによって身近に 
 • 2019年1月にリリースしサービス開始から 約5年
 • ユーザー数50万人超
 ◦ toCサービスで、かつユーザー規模も大きくなってきた ため、データ分析の重要性が大 
 

8. ユーザー体験の流れ①
 8 • ユーザーは定期便カレンダーにアイテムを追加でき、それが毎月ユーザー毎に決められた注文日に自 動で注文される
 
 

9. ユーザー体験の流れ②
 9 • ユーザーは、定期注文を スキップしたり、停止*したりすることができる 
 ◦ 言い換えると、定期便の契約は注文継続性を表す ”状態”を持つ
 ▪ 注文待ち、スキップ中、停止中、エラー中 (決済エラーなど) 
 ◦ この”状態” (定期便ステータス）が、今回紹介する負債の発生箇所 
 
 *現在、停止機能は廃止されてスキップに一本化されている 

10. 生じた問題
 10 10
11. 定期便ステータスのデータにおいて生じた問題
 11 • サービス開始から4年経過した2023年、分析面で問題が顕在化 
 ◦ データが不完全
 ▪ 事業上重要な数値を正確に出すことができない 
 1. ある時点での定期便ステータスを100%の精度で出せない 
 2. N-1月からN月への定期便ステータスの遷移率が正確に出せない 
 ◦ 分析が複雑化
 ▪ 分析のためにクエリが複雑化し、分析者の認知コストが高くなりすぎている 
 • データ基盤である程度吸収できるものの、メンテコストが高く、かつ高度な分析の際は 複雑なクエリを書く必要が生じていた 

12. 問題の原因: データの“更新”による過去情報の喪失
 12 • スキップ、決済エラーといったイベントを、既存のカラムの 更新によって実装していた 
 ◦ これにより、過去の情報がデータ更新によって失われていた 
 ◦ アンチパターン “失われた事実”*
 • 過去情報の喪失を補うために、イベントログを出力していたが、過去のステータスを100%で復元するの が難しいログになっていた 
 スキップ時の処理
 - 次回注文日を1ヶ月先に更新
 スキップ状態の条件
 - 次回注文日が1ヶ月以上先
 * 「失敗から学ぶRDBの正しい歩き方」, 曽根壮大, 2019/3/6, 技術評論社 
 https://gihyo.jp/book/2019/978-4-297-10408-5 

13. どう解消していったか
 13 13
14. 負債解消の目的
 14 • 分析者やデータ利用者のニーズに応えられる状態にすること 
 ◦ 1. 100%の精度で今後発生するデータを分析できるようにする 
 ◦ 2. 分析しやすいデータの持ち方にする 
 • その状態を維持しやすいデータにすること 
 ◦ 事業計画を作成するのにも利用されるデータのため、一時的でなく長期的に正しいデータが維持 されやすいデータの持ち方にする 

15. 負債解消の方針
 15 • 目的を達成するために、2つの点を重視 
 1. 定期便ステータス、イベント、ステータス遷移の定義とデータ定義をドキュメント化する 
 ◦ 仕様が明文化されておらず、ある時点で正しい定期便ステータスとは何なのか？というのが定まっていな かったので、改めて定義し共通認識を作る
 2. ログ出力をただ改善するのではなく、機能要件と分析要件を共に満たすデータの持ち方にリプ レースする
 ◦ アプリケーション開発者は機能要件に対する意識が強くなりがちで、分析要件の意識は長期的に見ると薄ま ることが想定されるので、どちらも満たしやすいデータ設計に持ち変えるのがよいという考え

16. 成果物: データの仕様
 16 • ステータスとイベントの定義を明確にしたうえで、イベントによるステータスの状態遷移図を作成 
 ◦ このデータ仕様を元に、バックエンドの自動テストと、データ基盤側のテストを作成 

17. 成果物: データ
 17 1. データの完全性
 ◦ 状態とイベント共に履歴情報が保持されている
 ◦ RDBのUNIQUE制約によって”単一の状態”
 を持つことが保証されている
 2. 分析の容易性
 ◦ 履歴が保持されているため、過去の
 状態を復元するためにログを参照する必要がない
 ◦ 状態が単一のテーブルに集約されているため
 わかりやすい

18. どうすれば負債が生まれることを防げたか？
 18 18
19. レコードの更新を避ける 
 19 • 負債発生の根本原因は、 レコード更新による履歴情報の喪失 (“消えた事実”) 
 ◦ イベントを明示的に扱い、 INSERTで表現することで、履歴情報が残る 
 • 特に、売上や売上予測に関連するようなテーブルに関しては履歴の保持を徹底すべき 

20. 機能追加のたびに最適なデータの持ち方を考える
 20 • 機能要件が変化したとき、どうしても既存のモデル、データの持ち方に引きづられて考えがち 
 • 既存のデータの持ち方でどう要件を実現できるか？を考えるのでなく、この要件を実現するのに最適な データの持ち方は何か？を考えるのが理想 
 ◦ 継続的なデータモデリング 
 

21. Confidential どうすれば負債が大きくなる ことを防げたか？ • 「負債を生まない」ことも重要だが、「負債を大きくしない」ことがそれ以上に大事だ と考えている (スタートアップにおいて）
 ◦ サービス開発初期はどうやっても負債がうまれやすい 
 ▪ 分析要件やパフォーマンス要件は、サービスが成長してから発生するため 
 ▪ 初期ほど開発リソースも時間もないため 
 • カラリアの場合は初期開発は副業エンジニア1名 
 ◦ 負債はある程度生まれる前提で、生まれた負債とうまく向き合い続けることが重要 

22. どうすれば負債が大きくなるのを防げたか？
 22 1. 対処療法でなく根本治療 
 ◦ 過去情報をみられるようにしたい、という分析要件があがってきた際に、対処療法的にログを追加 するのでなく、元のデータの移行を検討すべきだった 
 2. データ移行を恐れずやる、チームとしてデータ移行に習熟する 
 ◦ データの移行はサービスの規模が小さいほどコストが低い ので、早い段階でガンガンデータを移 行していくべき
 ▪ データサイズ、依存関係、障害発生時のリスク 
 ◦ サービス無停止のデータ移行は手間ではあるが、何度かやっているうちにチームが習熟していく 
 ◦ データ移行に習熟すると、1も 
 やりやすくなり好循環が生まれる 
 
 

23. 組織としてデータ負債を生みにくくする/大きくしないため の取り組み
 23 23
24. 1. Design Docによる設計レビュー
 24 • 2週間以上かかるような比較的粒度の大きい開発プロジェクトについては、設計ドキュメントを記述して 実装に入る前に相互レビューをするようにしている 
 • データモデリングについて重点的にレビューすることによって致命的なデータ負債の発生を防ぐ 

25. 2. データチームと連携した継続的なデータ品質向上
 25 • 早期のデータ課題の発見と解消を継続的に行うために定期的に開発エンジニアとアナリティクスエンジ ニアで定例(DevData定例)を実施 
 ◦ データに関する問題や、要望をいち早くキャッチし、継続的に改善するサイクルを作っている 

26. 3. 20%ルール
 26 • エンジニアリソースの20%程度を、 データ含む技術的負債の解消 、ライブラリアップデート 、新技術の検 証などにあてることができるという仕組み 
 ◦ ビジネスサイドとの合意形成なしに、エンジニアがチームで優先度を決めることができる 

27. まとめ
 • カラリアにおいて生じた、サービス初期からの実装によって生じたデータ負債について紹介 
 ◦ アンチパターン回避によって防げた 
 • スタートアップにおいては特に 「負債を生まない」のも大事だが「負債を大きくしない」 のが大事
 ◦ 負債を大きくしないためには 
 ▪ 対処療法でなく根本治療 
 ▪ データ移行を恐れずやる、チームとしてデータ移行に習熟する 
 • 弊社が組織として取り組んでいる、負債とうまく付き合うための取り組みを紹介 
 ◦ Design Docによる設計レビュー 
 ◦ データチームと連携した継続的なデータ品質向上 
 ◦ 20%ルール
 27
28. ご清聴ありがとうございました！！
 バックエンドエンジニアを中心に、エンジニアを募集中です。
 カラリアでは、香りの定期便の他にも、香りのギフトというギフトサービスをやっていたり、物流 (在庫管理、製造管理）の基幹業務 システムをRailsで内製していたりします。
 少しでも気になる方は紹介資料を覗いてみてください。
 
 エンジニア向け会社紹介資料: https://high-link.notion.site/10a3e50a52aa4033853a16707bd9fc1c?pvs=74
 28