技術負債と データ構造 ハコベル株式会社 中村隆宏 TECHBREW IN 東京 〜技術的負債と共に歩むプロダクトの成長〜

所属：ハコベル株式会社 　　 （旧 ラクスル株式会社ハコベル事業部） 役職：シニアアーキテクト 職歴：Paiza 、決済サービス、SI 系 経歴：熊本出身、文化人類学専攻 趣味：旅行、音楽、MMA 中村隆宏 (na9amura)

No content

プロダクトラインナップ 取引階層のフラット化とドライバー の非稼働時間の有効活用 物流に関わる人たちを繋ぎ コミュニケーションを円滑化 AI 技術を活用し配送効率アップ、 業務の効率化、属人化解消

1.テーマ設定

Introduction 　ハコベルに入社して約6 年、ハコベル配車管理とハコベル 配車計画の2 プロダクトでローンチから運用・拡張に携わっ てきました。作ってしまった技術負債、予防すべく努力して いる部分、様々な技術負債との関わり方をしてきました。 　今回はその中からデータ構造にまつわるものを紹介しま す。負債を抱えたくなかったと考えることが多く、予防しよ うと努力している部分です。それを身近なモデルに落とし込 んで紹介します。

2.サンプル

EC サイトを構築するとします。今回サンプルなので以下ような小さいス コープとします。 ユーザー情報を登録する 商品情報を登録する 商品を注文する ECサイトのデータ

ID name address 1 中村 熊本市西区… 2 … ... ID name quantity 1 チョコレート 22 2 … … ID user_id item_id orders 1 1 1 1 2 … … … Users Items Orders Data structure ユーザー、商品などのマスタデータ 注文データなどのトランザクションデータ ID でリレーションを貼る ようなものが構成として思いつくのではないでしょうか

View Usersテ ーブルから 中村 熊本市西区 Itemsテ ーブルから チョコレート 24個 Order 1

完成！

本当に？

ID name address 1 中村 つくば市春日… 2 … ... ID name quantity 1 チョコレート 22 2 … … ID user_id item_id orders 1 1 1 1 2 … … … Users Items Orders Update Records 例えばえばこいう場合 ユーザーが引っ越した 商品がリニューアルした

Updated View Usersテ ーブルから 中村 つくば市春日 Itemsテ ーブルから チョコレート 22個 Order 1

3.何が起きた？

事実の改変 過去に起きた事実はそれ以降の変更に連動しません。今回で言うと届け 先、商品個数は変わらない。ですがシステム、データ、画面上では変わっ てしまっています。

ユースケースの混在 登録ミスがあった場合にレコードを更新する 住所変更、商品リニューアルによりデータを追従させる この2 つのユースケースがありえる。どちらによるものかデータ上から区 別ができない。

データのライフサイクル Users, Items テーブルの カラム内のデータは業務で必要なのに先に消失している レコードは業務で使う単位より長生きしている つまりは、実務上はUsers, Items のライフサイクルとOrders のライフサイ クルは異なる。しかしデータ構成上そうなっていないと言えます

4.どうしよう

ID name address 1 中村 つくば市春日… 2 … ... ID name quantity 1 チョコレート 22 2 … … ID user_id item_id orders ship_to quantity 1 1 1 1 熊本市西区… 24 2 … … … … … Users Items Orders 1. Snapshot データの更新に追従しないデータをそのまま保 存する。データの量・性質によってはusers, items テーブルを丸々コピーしても良いかも。

ID name address 1 中村 熊本市西区… 2 … ... ID name quantity 1 チョコレート 24 2 チョコレート 22 Users Items Orders 2. Domain Logic 変更不可なデータを更新させず、データを追加 する。バリデーションで防いでもいいし、デー タ更新UI を提供しないことで対応するなど（ル ールの永続性に問題はあるが） ID user_id item_id orders 1 1 2 1 2 … … …

ID name 1 中村 Users Orders 3. Immutable Datamodel データ構造でデータの不変性を担保する。データ取得 する際に必要な時点のデータを取得します。 今回の場合： WHRER orders.created > addressed.created ORDER BY addresses.created DESC LIMIT 1 ID user_id item_id orders created 1 1 2 1 2015/01/01 2 … … … ID user_id address created 1 1 熊本市西区… 2010/01/01 2 1 つくば市春日… 2020/01/01 Addresses

5.まとめ

「マスタデータ」とざっくりカテゴライズしているものの中には、実は複 数の性質が混在しています。 本当にUpdate されるべきもの 「テンプレート」「シード」のような性質のもの 今回のサンプルは身近で予想しやすい事例。しかしオペレーションが複 雑、ドメイン領域の理解が浅い場合このような性質が見えにくいです。 ドメインの観点

技術負債の中でもデータ構造にまつわるものは重要度が高いと私は考えて います。以下の観点から初期に整理しておくことを推奨します。 データ構造変更、マイグレーションは作業コスト、リスクが高い 最初のデータ構造で保持してないデータは復元できない 技術負債の観点

技術負債はネガティブな要素も多いですが、うまくトレードオフを考えつ つ借り入れることでプロダクトの成長を加速させられるメリットもありま す。しかし実際のお金と違い、返済しやすいもの、しにくいものがありま す。その性質を見極めて計画的に借り入れましょう！ ご利用は 計画的に 全体まとめ

ドメイン知識理解、データ構造設計、ユー ザーバリューへの向き合いのバランスを高 いレベルで調和させたい人！募集中です！

THANK YOU