こんにちは、株式会社High Link CTOの nogaken(@nogaken1107)です。
プロダクト開発企業にとって、データ負債は大敵です。
要件に合わないデータ構造、過去データの欠損、不整合データの存在、etc。
これらデータに関する負債は、開発スピードの悪化や分析業務の阻害などを通じて事業に大きな悪影響を及ぼします。
弊社で開発している香り商品ECのプラットフォームである Coloria (https://coloria.jp)は、サービス提供開始から5年が経過しています。その中で、多くのデータ負債を生み、そしてそれらを返済しながらサービスを運営してきました。（そしていまも、現在進行形で返済を続けています。）
データ負債は、発生させないことが理想ですが、プロダクトの要件の変化が不確実である以上、0にすることはできないと考えています。特に、リソースの限られたスタートアップ企業では、スピードを重視して開発することが多いためなおさらです。
そのため、データ負債を生まないようにするだけでなく、発生したデータ負債をいかに大きくしないようにするか、というのも重要です。
そこで本記事では、High Linkで取り組んでいる
- データ負債を生みにくくするため
- データ負債を大きくしないため
の取り組みや考え方について紹介します。
データ負債を生みにくくするために
要件が変化するたびに最適なデータの持ち方を考える
まず最初に重視しているのが、要件に最適なデータ構造を常に意識し続けることです。データモデリングを継続的に行い続けること、とも言えます。
プロダクトの改善に取り組んでいる限り、システムに対する要件は変化します。
変化する要件は、機能要件であることもあれば、パフォーマンスや分析ニーズなどの非機能要件であることもあります。
要件が変化すれば、それに適したデータ構造も変化します。また、要件が少しだけ変わったように見えても、それに適したデータ構造が、現在の構造の延長線上にあるとは限りません。
そのため、要件が変化するたびに、既存のデータ構造のまま、または既存のテーブルにカラムを追加するといった手間の少ないやり方で済ませるのではなく、あるべき理想のデータ構造について考え、できるだけ近づけるというのが重要です。
もちろん、時間制限もあるため毎回最適なデータ構造に変更し続けるのは難しいですが、少なくとも「本来はこうやって持つべきデータを、スケジュール要件の都合上こういう持ち方にしている」ということをチームの共通認識として持つことが重要です。そうすることで、適切なタイミングでデータクレンジングするといった決定がしやすくなります。
Design Docによる設計レビューで設計品質を高める
上記と関連しますが、Design Docによる設計レイヤーでの相互レビューを継続的に行なっています。1週間以上かかるような比較的粒度の大きい開発については、コードを書き始める前に設計ドキュメントを記述してレビューをしています。
コードを書いてからのGithub上でのレビューのみの場合、コードの前段のデータモデリングに関する議論や、テーブル設計の議論によって大部分の実装が無駄になったり、またはそれを遠慮してコメントを控えるといったことが生じやすくなります。
Design Docによって、データモデリングや設計に関する議論が活発化し、上述の最適なデータの持ち方に関する議論と共通認識がチームに生まれます。また、設計指針を言語化して残すことによって設計のノウハウが蓄積し、学習材料にもなります。
Design Docには以下のようなテンプレートを用いています。
# Context (背景) > 開発が必要となる背景。プロダクトバックログアイテムなど、施策や企画の詳細が記述されているドキュメントへのリンクや概要を記載する。 # Goal (目的) > この開発プロジェクトの目的。プロジェクト終了時に満たしているべきこと。機能要件であることもあるし非機能要件の場合もある。 # Non-Goal (目的でないもの) > このドキュメントで開発スコープから外すもの。Goalで明確になっているなら不要。 # Design Policy > この設計でGoalを達成するため、設計指針として重視するもの。 > Alternative Solutionsでなく、Solutionに記載された解決策を選択した理由となるもの。 > ex1. 今後の要件変更の不確実性が高いのでとにかく目の前の要件を満たす設計にする > ex2. 今後起こりうる確度の高い要件変更を考慮して、その変更を考慮に入れた上で設計する # Solution > 解決策。テーブル構造やシステムアーキテクチャを記述する。必要に応じてセクションに分割して、セクションごとに記述する。言語だけでわかりづらい場合は、表や図も活用する。 # Alternative Solutions > 選択しなかった解決策。他に考えられる解決策と、なぜそれではなくSolutionを選択したのかを記述する。
データ負債を大きくしないために
データ移行を恐れずやり続け、チームとしてデータ移行に習熟する
データ負債を大きくしないために重要と考えているのが、チーム全体としてデータ移行に習熟し、フットワーク軽くデータ移行をやり続けられるようになることです。
サービス無停止のデータ移行はある程度のリスクを伴います。一般的なテーブルの移行の場合、ダブルライトの期間を設け、旧データをバッチ処理などで移行し、参照先を切り替え、ダブルライトを停止する、といった複数のステップを踏む必要があり、ステップを誤るとデータ不整合や障害につながります。
ただ、少数のテーブルだけで完結する複雑性の低い負債であれば、基本的に上記手順を踏めば移行可能なため、移行フローへの習熟ができればそこまで負荷なく行えるようになります。
逆に、多くのテーブルにまたがる、複数の課題が重なりあったような負債は、負債返済のプランニングに必要な情報処理能力が増え、それだけ時間と労力がかかります。また、問題の複雑性によって認知負荷は増し、ステップミスによる障害発生確率もあがります。
負債を小さいうちに返済する→データ移行に習熟する→より効率的に小さいうちに負債を返済する...という好循環を生まれれば、負債解消へのフットワークは向上し、小さいな負債をこまめに返済する習慣がチームに生まれます。
データのスペシャリストと連携してデータ品質を上げていく
最後に重視しているのが、アナリティクスエンジニアやデータアナリストと連携した継続的なデータ品質向上です。
分析要件に関しては日頃から分析業務や分析業務の効率化、サポートを行っているアナリスト・アナリティクスエンジニアが最も解像度高く把握しています。
そこで、早い段階でのデータ課題の発見と解消を行うために、開発エンジニアとアナリティクスエンジニア、データアナリストでのミーティングを実施しています。これによってデータに関する問題や要望をいち早くキャッチし改善するサイクルを作っています。
おわりに
本記事では、High Linkで取り組んでいる、
- 大きなデータ負債を生まないため
- 生んでしまったデータ負債を大きくしないため
の取り組みについて紹介しました。
データ負債を生みにくくするために、
- 要件が変化するたびに最適なデータの持ち方を考えること
- Design Docによる設計レビューで設計品質を高める
データ負債を大きくしないために、
- データ移行を恐れずやり続け、チームとしてデータ移行に習熟すること
- データチームと連携してデータ品質を上げていくこと
を重視していることを紹介させていただきました。
ハイリンクで解消した具体的な負債の内容については、こちらの記事でも紹介されているのでぜひご一読ください。
Coloriaの開発チームでは、日頃プロダクトのPDCAを高速で実現するための新機能開発や機能改善に加え、データ負債をはじめとする各種技術的負債の解消に継続的に取り組んでいます。
技術を大事にしながら、ユーザーに価値を届けることにコミットしていきたいエンジニアを募集中です。
技術的負債については、失敗談や思想含めて話したいことがたくさんあるため、ぜひ一度お話しできれば幸いです。
