Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Avatar for Fumina Chihama Fumina Chihama
April 10, 2024
610

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

Avatar for Fumina Chihama

Fumina Chihama

April 10, 2024
Tweet

More Decks by Fumina Chihama

Transcript

  1. 自己紹介
 • 名前: 野川賢二郎 (@nogaken1107) 
 ◦ 株式会社High Link 執行役員CTO

    
 • 経歴: 株式会社LINE → 株式会社High Link 
 ◦ ハイリンクには初期フェーズに入社し、今回のテーマ となる、データ負債の発生と解消に当事者として経 験してきました
 • 趣味: 
 ◦ 歩く
 ▪ 昨年はエクストリームウォークというイベントで 25時間かけて100km歩きました 
 • おすすめ( しません)
 
 2
  2. 目次
 • プロダクトの紹介
 • 生じた問題
 • どう解消していったか 
 • どうすれば負債が生まれることを防げたか?

    
 • どうすれば負債が大きくなることを防げたか? 
 • 組織としてデータ負債を生みにくく/大きくしないための取り組み 
 
 4
  3. 6 6

  4. カラリア 香りの定期便
 7 • 香水を中心とした香り商品のサブスク 
 ◦ 約1000種類の商品の中から毎月ユーザーが好きなも のを選べて、楽しめる 


    ◦ 目に見えないからこそ難しい 「香りとの出会い」をテク ノロジーを活用することによって身近に 
 • 2019年1月にリリースしサービス開始から 約5年
 • ユーザー数50万人超
 ◦ toCサービスで、かつユーザー規模も大きくなってきた ため、データ分析の重要性が大 
 

  5. ユーザー体験の流れ②
 9 • ユーザーは、定期注文を スキップしたり、停止*したりすることができる 
 ◦ 言い換えると、定期便の契約は注文継続性を表す ”状態”を持つ
 ▪

    注文待ち、スキップ中、停止中、エラー中 (決済エラーなど) 
 ◦ この”状態” (定期便ステータス)が、今回紹介する負債の発生箇所 
 
 *現在、停止機能は廃止されてスキップに一本化されている 

  6. 定期便ステータスのデータにおいて生じた問題
 11 • サービス開始から4年経過した2023年、分析面で問題が顕在化 
 ◦ データが不完全
 ▪ 事業上重要な数値を正確に出すことができない 


    1. ある時点での定期便ステータスを100%の精度で出せない 
 2. N-1月からN月への定期便ステータスの遷移率が正確に出せない 
 ◦ 分析が複雑化
 ▪ 分析のためにクエリが複雑化し、分析者の認知コストが高くなりすぎている 
 • データ基盤である程度吸収できるものの、メンテコストが高く、かつ高度な分析の際は 複雑なクエリを書く必要が生じていた 

  7. 問題の原因: データの“更新”による過去情報の喪失
 12 • スキップ、決済エラーといったイベントを、既存のカラムの 更新によって実装していた 
 ◦ これにより、過去の情報がデータ更新によって失われていた 


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

  8. 負債解消の目的
 14 • 分析者やデータ利用者のニーズに応えられる状態にすること 
 ◦ 1. 100%の精度で今後発生するデータを分析できるようにする 
 ◦

    2. 分析しやすいデータの持ち方にする 
 • その状態を維持しやすいデータにすること 
 ◦ 事業計画を作成するのにも利用されるデータのため、一時的でなく長期的に正しいデータが維持 されやすいデータの持ち方にする 

  9. 負債解消の方針
 15 • 目的を達成するために、2つの点を重視 
 1. 定期便ステータス、イベント、ステータス遷移の定義とデータ定義をドキュメント化する 
 ◦ 仕様が明文化されておらず、ある時点で正しい定期便ステータスとは何なのか?というのが定まっていな

    かったので、改めて定義し共通認識を作る
 2. ログ出力をただ改善するのではなく、機能要件と分析要件を共に満たすデータの持ち方にリプ レースする
 ◦ アプリケーション開発者は機能要件に対する意識が強くなりがちで、分析要件の意識は長期的に見ると薄ま ることが想定されるので、どちらも満たしやすいデータ設計に持ち変えるのがよいという考え

  10. 成果物: データ
 17 1. データの完全性
 ◦ 状態とイベント共に履歴情報が保持されている
 ◦ RDBのUNIQUE制約によって”単一の状態”
 を持つことが保証されている


    2. 分析の容易性
 ◦ 履歴が保持されているため、過去の
 状態を復元するためにログを参照する必要がない
 ◦ 状態が単一のテーブルに集約されているため
 わかりやすい

  11. レコードの更新を避ける 
 19 • 負債発生の根本原因は、 レコード更新による履歴情報の喪失 (“消えた事実”) 
 ◦ イベントを明示的に扱い、

    INSERTで表現することで、履歴情報が残る 
 • 特に、売上や売上予測に関連するようなテーブルに関しては履歴の保持を徹底すべき 

  12. Confidential どうすれば負債が大きくなる ことを防げたか? • 「負債を生まない」ことも重要だが、「負債を大きくしない」ことがそれ以上に大事だ と考えている (スタートアップにおいて)
 ◦ サービス開発初期はどうやっても負債がうまれやすい 


    ▪ 分析要件やパフォーマンス要件は、サービスが成長してから発生するため 
 ▪ 初期ほど開発リソースも時間もないため 
 • カラリアの場合は初期開発は副業エンジニア1名 
 ◦ 負債はある程度生まれる前提で、生まれた負債とうまく向き合い続けることが重要 

  13. どうすれば負債が大きくなるのを防げたか?
 22 1. 対処療法でなく根本治療 
 ◦ 過去情報をみられるようにしたい、という分析要件があがってきた際に、対処療法的にログを追加 するのでなく、元のデータの移行を検討すべきだった 
 2.

    データ移行を恐れずやる、チームとしてデータ移行に習熟する 
 ◦ データの移行はサービスの規模が小さいほどコストが低い ので、早い段階でガンガンデータを移 行していくべき
 ▪ データサイズ、依存関係、障害発生時のリスク 
 ◦ サービス無停止のデータ移行は手間ではあるが、何度かやっているうちにチームが習熟していく 
 ◦ データ移行に習熟すると、1も 
 やりやすくなり好循環が生まれる 
 
 

  14. まとめ
 • カラリアにおいて生じた、サービス初期からの実装によって生じたデータ負債について紹介 
 ◦ アンチパターン回避によって防げた 
 • スタートアップにおいては特に 「負債を生まない」のも大事だが「負債を大きくしない」

    のが大事
 ◦ 負債を大きくしないためには 
 ▪ 対処療法でなく根本治療 
 ▪ データ移行を恐れずやる、チームとしてデータ移行に習熟する 
 • 弊社が組織として取り組んでいる、負債とうまく付き合うための取り組みを紹介 
 ◦ Design Docによる設計レビュー 
 ◦ データチームと連携した継続的なデータ品質向上 
 ◦ 20%ルール
 27