スタートアップ企業が陥りがちなデータモデルのミス

2021/05/28 08:31

Sameer Al-Sakran
Metabase CEO
この記事は、著者の許可を得て配信しています。
 Common data model mistakes made by startups

いくつかのスタートアップ企業のアナリティクス・スタックの構築を手伝っていると、いくつかのパターンが見えてきます。もちろん素晴らしいパターンもあることもあります。何が起こっているのかわからない状態から、何が起こったのかがぼんやりとでもわかるようになった瞬間は、誰もが喜びます。

それ以外のパターンは、あまり良いものではなく、たいていはデータモデルやスキーマに関する決定に関わるものです。

以下で説明するアンチパターンは、スタートアップ企業に特有のものであるということを念頭においてこの記事を読んでください。これらのパターンの中には、後期の段階にある(レイタ―ステージの)企業にとっては実際によい例となるものもありますが、製品市場に適合する前の、リソースに制約のある小規模なスタートアップ企業にとっては、これらのパターンは犯す必要のないミスとなります。

前置きが長くなりましたが、この記事では初期の段階にある(アーリーステージの)アナリティクスにおける痛恨のミスの原因トップ5をご紹介したいと思います。

1. テストデータや偽のデータでデータベースを汚染する

テストアカウント、スタッフアカウント、異なるデータプログラム、テレパシー(2013年に発表された頭部装着型のウェアラブルデバイスを開発する企業および製品)を通しての注文など、ほとんどのクエリにおいて特定のイベントやトランザクションを無視しなければならないデータが含まれている企業が多々あります。

テストデータでデータベースを汚染することで、あなたの会社のすべての分析(および内部ツールの構築)に税金を導入することになります。この税金とトランザクションの効率性や開発者の生産性との間でのバランスをとることができます。この税金が価値あるものである場合もあれば、そうでない場合もあります。大企業であれば、トランザクションの効率化は大変重要な目標であり、結果を削除するためにエンジニアやアナリストにお願いしてもいいでしょう。

小規模な企業であれば、そのような余裕はないでしょうし、また、また別のところでトレードオフすべきでしょう。

2. 事後的にセッションを再構築する

ユーザーの行動、満足度、価値などに関する重要な問題のかなりの部分は、セッションのメトリクスが中心になっています。「セッション」、「カンバセーション」、「サポートコンタクト」など、呼び名はさまざまですが、これらのメトリクスは、ユーザーに関する個別のイベントを指しており、これらはまとめて1つの概念として扱われるべきものです。しかし、スタートアップ企業のデータモデルでは、ビジネスに関するこの基本的な概念を捉えられていないことが、おそろしく多いのです。

セッションはしばしば事後的に再構築されますが、これでは通常多くの場合、脆弱性を残し、ミスの原因になります。何がセッションを構成するかの正確な定義は、アプリ自体の変更に伴って変わるのが一般的です。さらに、クライアントやクライアントのリクエストを処理するサーバーには、ユーザーのセッションに関係する多くのコンテキストが存在します。セッションを事後的に再構築するよりも、アプリ内でセッション、サポートチケット、カンバセーションIDを割り当てる方がはるかに簡単です。

3. ソフトデリート

大きな負荷がかかった状態でデータベースの行を削除することは、大規模な場合には避けるべきことです。ソフトデリートはよく知られたスキーマツールであり、削除とそれに続く圧縮(またはバキューム)によるパフォーマンスヒットを軽減します。さらに、ソフトデリートは、行の削除解除を容易にし、(理論上は)削除されたデータの復元を可能にします。

一方、ソフトデリートでは、すべての読み取りクエリで、削除された記録を除外する必要があります。アプリケーションデータの呼び出しだけを考えれば、これはそれほど悪いことではないと思われるかもしれません。しかし、実行するすべてのアナリティクス クエリに広がると、除外したことが、すぐに重大な障害につながります。また、ソフトデリートでは、異なるユーザーが異なる仮定をする可能性があり、デバッグする必要のある一貫性のない数値につながる可能性があります。

4. 半構造化データの誤用

半構造化データ(例:JSONとしてエンコードされたフィールド)とは、時間の経過とともに様々な構造が存在する状況で有用です。また、データベースの大規模化に伴い、半構造化データを利用することで、読み書きの負荷が大きい大規模なテーブルを移行する際の煩わしさはなくなります。

しかし、半構造化されたデータは、データベースからデータを取り出そうとする際に、多くの問題を引き起こす可能性があります。一般的に半構造化データは、慣習的にしか適用されていないスキーマしか持っておらず、予測不可能な変更や一時的なバグによってオフになっている可能性があります。そのため、通常は事後的なクリーニングが頻回に必要となります。

また、半構造化されたデータフィールドは、必要な構造を考えるのを機能の開発が終わるまで先延ばしにするための言い訳にもなります。この場合、実際には構造化されたデータがありますが、それは強制されておらず、バグが発生しやすく、一般的には使いづらいものです。次のように簡単なテストをしてみるといいでしょう。JSONのフィールドに同じ4つのフィールドがある場合、おそらく構造を分解する必要があります。

5.「その仕事に適したデータベース」症候群

企業のテクノロジースタックで使用されている多数の異なるデータベースは、通常、次の3つのシナリオのいずれかを示しています。

  • 様々なニーズがあり、細分化されているものすごく巨大で複雑な企業
  • 非常に難しい問題に取り組んでいて、アプリのすべての側面を高度に最適化する必要がある、高機能でトップパフォーマンスのエンジニアリングおよびオペレーションチーム
  • (最も一般的なのは)あまり知識のない、技術面の問題解決に追われている小さなチーム

データベースを追加するたびに、運用面で多くのオーバーヘッドが発生します。そして、データベースを追加するたびに、分析用データベースに入れる必要のあるデータのセットが増えていきます。これらのデータベースには、微妙に異なるセマンティクス、データタイプ、自然なデータモデルがあり、それらを整理する必要があります。

だからこそ小さな機能を簡単に実装したいという衝動を抑えてください。全体的に運用や分析がより難しくなってしまいます。

アドバイス:ビジネス・メトリクスの入手を容易にすべし

データモデルが分析やトランザクションのニーズを満たしているかどうかを考える際には、次のような点を確認するのがポイントです。

  • ビジネスで重視される10の重要なメトリクス
  • アプリケーションから最もよく実行される10のアップデートクエリ
  • アプリケーションからの最も一般的な10の読み取りパターン

みなさんがこういった異なるクエリのすべてにおいて痛手を最小限に抑えるデータモデルを求めています。一般的には、ビジネス・メトリクスに対するクエリが最も重要です。アプリのアップデートや読み込みを多少の複雑にすることで、ビジネス・メトリクスに対するクエリが容易になるのであれば、そうすべきでしょう。アプリケーション側には、一般的なアナリティクスやビジネスインテリジェンスの問題に比べて、主力となるクエリがはるかに少ないのが普通なので、全体的な生産性を高めることができます。

また、アプリのクエリは通常、ソースコントロールで行われ、自動化されたテストに包まれており、一般的にはるかに強化されています。一方、ビジネス・メトリクスのクエリは、多くの人によって書かれたものであり体系的ではなく、一般的にはあまり管理されていません。そのため、ベターな意思決定を行うために必要なメトリクスを簡単に手に入れられるようにするためには、自分ができることをするのが一番です。

appstore
googleplay
会員登録

会員登録して、もっと便利に利用しよう

  • 1.

    記事をストックできる
    気になる記事をピックして、いつでも読み返すことができます。
  • 2.

    新着ニュースをカスタマイズできます
    好きなニュースフィードをフォローすると、新着ニュースが受け取れます。