新規事業のデータ設計｜最初に決めたい5つの持ち方
新規事業のシステムでは画面や機能に目が向きがちですが、後から事業の強みになるかどうかは「どんなデータを、どんな形で持つか」で大きく左右されます。この記事では、新規事業のデータ設計で最初に決めておきたい5つのことと、決めすぎないための線引き、プロトタイプ（実際に動く試作品）で確かめる方法を整理します。
新規事業で、データの持ち方を最初に考えたい理由
画面や機能は、使ってもらいながら作り直せます。一方でデータは、事業を動かした日から溜まり続け、その形は後から変えにくいものです。新規事業で最初にデータの持ち方を考えたい理由は、大きく2つあります。
取っていなかったデータは、後から取り戻せない
たとえば、サービスへの申込を「申込済み」「成立」のように最新の状態だけで上書きして持っていたとします。この場合、「申込から成立まで何日かかったか」「どの段階で止まる人が多いか」は、後から調べようとしても分かりません。記録していなかった事実は、あとで分析したくなっても遡れないからです。
新規事業は、仮説を立てて確かめ、方向を直していく取り組みです。確かめるための材料がそもそも残っていなければ、事業の判断は感覚に頼ることになります。
溜まったデータは、作り直しの足かせにもなる
データの形を後から変えるには、すでに溜まったデータを新しい形に変換する「データ移行」が必要です。項目の意味が曖昧なままだと、「この値は何を指していたのか」を一件ずつ人が判断することになり、手間もミスも増えます。
試作から本開発へ進む場面でも、データの形は引き継ぎの大きな論点になります。引き継げる部分と見直す部分の考え方は、MVPから本開発は作り直し？引き継げる部分と見直す点で整理しています。
「データが武器になる」とはどういう状態か
この記事で「事業の武器になるデータ」と呼ぶのは、次の3つが重なった状態です。
- 他の会社が簡単には用意できない
- 事業が回るほど自然に増えていく
- 次の判断や、次の機能づくりに使える
ただ溜めるだけでは武器になりません。使える形で、意味が分かる状態で持っていることが前提です。以降は、そのために最初に決めたいことを順に見ていきます。
最初に決めておきたい5つのこと
1. 事業の問いと、それに答えるデータ
最初に決めたいのは、「何を知りたいのか」です。データの項目から考え始めると、「とりあえず取れるものは全部取る」という発想になりがちです。順番は逆で、検証したい仮説を先に置き、それに答えるために必要なデータを逆算します。
たとえば「利用者は、最初の1週間で何をすれば定着するのか」を知りたいなら、登録日、各機能を使った日時、再訪した日時が必要になります。「どの顧客層が継続しやすいのか」を知りたいなら、顧客の属性と契約の継続状況を結びつけて持つ必要があります。
仮説と判断基準を先に決める考え方は、MVP検証の指標を先に決める方法｜判断基準の作り方で詳しく扱っています。指標が決まれば、必要なデータはおのずと絞られます。
2. 「誰が・何を・いつ」を記録する単位
次に決めたいのは、データを記録する粒度（細かさ）です。特に、状態を上書きするのか、出来事を積み上げて残すのかは、早めに決めたい点です。
- 上書きで持つ：現在の状態だけが分かる。構造は単純だが、過去には戻れない
- 出来事を積み上げて持つ：「いつ、誰が、何をしたか」が時間順に残る。履歴をたどれる
「ログ」と呼ばれる操作や出来事の記録は、後者にあたります。新規事業では、現在の状態に加えて、状態が変わった出来事も残しておくと、後から「なぜこうなったのか」を追えます。
サブスクリプション型の事業なら、契約、更新、解約、プラン変更が出来事の例です。マッチング型の事業なら、登録、検索、申込、成立、評価が出来事にあたります。サービスの種類ごとに先に決めたい事柄は、サブスク新規事業のシステム開発｜先に決める6つのことやマッチングサービス開発の進め方｜最初に決める5つのことも参考になります。
ただし、すべてを細かく残そうとすると、設計も保管も重くなります。1つ目で決めた「問い」に関係する出来事から残すのが現実的です。
3. 識別子と、データのつなぎ方
3つ目は、データを一意に見分ける番号（識別子、ID）と、データ同士のつなぎ方です。地味ですが、後から変えにくい部分です。
見直したいのは、次のような点です。
- 利用者の識別にメールアドレスや電話番号をそのまま使っていないか。変更される可能性があり、変わった瞬間に過去の履歴とつながらなくなる
- 個人と、その個人が所属する会社や店舗を、別のデータとして分けているか。1人が複数の組織に関わる場合に対応しやすくなる
- 将来、外部のサービスと連携する可能性があるか。連携先の番号と自分たちの番号を結びつける置き場所があるか
B2Bの事業では特に、「個人」「会社」「契約」を別々に持ち、それぞれを番号でつなぐ形にしておくと、事業の広がりに対応しやすくなります。最初は1社1アカウントの想定でも、後から「1社に複数の担当者」という要望が出ることは珍しくありません。
4. 項目の意味と、選択肢の決め方
4つ目は、各項目の意味と入力のさせ方です。同じ「ステータス」という項目でも、人によって解釈が違えば、集計した数字を信用できなくなります。
決めておきたいのは、たとえば次のようなことです。
- ステータスの種類と、それぞれが指す状態の定義（「成立」とは契約書を交わした時点か、決済が完了した時点か）
- 自由に文字を入力させる項目と、選択肢から選ばせる項目の区別。集計したい項目は、選択式にしておくと表記のゆれを防げる
- 日付や時刻の持ち方、金額の単位、税込か税抜かといった約束事
- 削除の扱い。データを物理的に消すのか、「削除済み」の印だけを付けて残すのか（後者は「論理削除」と呼ばれる）
こうした定義は、言葉だけで決めようとすると食い違いが残りがちです。要件の抜け漏れやズレを防ぐ進め方は、要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方で整理しています。
5. 取得の目的・同意・削除のルール
5つ目は、個人に関わるデータを扱うときのルールです。これは設計の問題であると同時に、事業を続けるための土台でもあります。
日本では個人情報保護法により、個人情報を取り扱うときは利用目的をできる限り特定することが求められます。また、病歴など「要配慮個人情報」と呼ばれる種類の情報は、取得にあたって本人の同意が原則として必要です。詳しい扱いは、個人情報保護委員会が公開しているガイドラインで確認できます。事業の内容によって求められることが変わるため、最終的には専門家への確認も視野に入れたいところです。
設計の面で最初に決めておきたいのは、次の点です。
- そのデータを何のために取るのか。目的に不要な項目は取らない
- 同意を得た事実（いつ、何に同意したか）を記録として残すか
- 利用者から削除を求められたとき、どのデータを、どの範囲で消せる構造になっているか
- 管理画面や運用担当者が、どこまでのデータを見られるか
「念のため取っておく」は、武器ではなく負債になることがあります。保管するほど、漏えいや管理の責任も重くなるためです。AIの開発ツールに事業の情報を入力する場面での注意点は、生成AI開発の情報漏洩を防ぐ確認点｜機密と事業アイデアにまとめています。
武器になるデータ、ならないデータ
5つを決めたうえで、そのデータが本当に事業の強みになるかも見ておきたいところです。見分ける視点を3つ挙げます。
事業を回すと、自然に溜まるか
武器になりやすいのは、サービスを使ってもらう過程で自然に溜まるデータです。たとえば、利用者がどの順序で操作したか、どの条件で選ばれたか、どの組み合わせが成立しやすかったか、といった記録です。外から買ってくるデータと違い、事業を続けた時間そのものが蓄積になります。
時間がたつほど価値が増すか
履歴として積み上がるデータは、期間が長くなるほど比較や予測に使いやすくなります。逆に、最新の状態だけを上書きしているデータは、何年たっても「いまの状態」しか分かりません。2つ目で触れた「出来事を残す」判断は、ここに効いてきます。
意思決定や機能改善につながるか
溜まったデータが、価格の見直し、機能の優先順位、営業先の絞り込みなど、具体的な判断に使えるかも重要です。使い道が思い浮かばないデータは、保管の手間だけが残ります。
AIを事業に取り入れる場面でも、データの質は効いてきます。意味が揃い、履歴が整理されたデータは、集計や分析、AIによる活用の材料にしやすくなります。反対に、表記がバラバラで定義が曖昧なデータは、AIに渡す前に整える作業が必要です。もちろん、どこまで活用できるかは目的と状況次第ですが、「後から使える形で持つ」ことが出発点になります。
決めすぎない、決めなさすぎない線引き
ここまで読むと「最初から全部を完璧に設計しなければ」と感じるかもしれませんが、そうではありません。新規事業は、仮説が外れて方向を変えることも多い取り組みです。最初から細部まで作り込むと、方向転換のときに足かせになります。
後から変えにくいものを、先に決める
優先して決めたいのは、変えにくいものです。
- 利用者・会社・契約といった中心となる単位と、その識別子
- 出来事として残すか、上書きで持つかの方針
- 個人情報の取得目的と、削除できる構造
後から足せるものは、後回しにする
一方で、後から足しやすいものは、最初から広げすぎないほうが安全です。
- 補助的な項目（自由記述のメモ、細かな属性など）
- 使うかどうか分からない集計用のデータ
- 画面の見せ方に関わる設定
最初に作る範囲の絞り方は、MVP開発の機能の絞り方｜最初に作るものと後回しの基準の考え方がそのまま使えます。機能を絞るのと同じように、データも「いま確かめたいこと」に必要なものから持つのが基本です。
データベース設計をAIに任せる範囲
AIを使った開発では、データベースの設計案をAIが短時間で出すこともできるようになっています。ただ、「この事業にとって何を残すべきか」「この言葉の定義は何か」といった意味づけは、事業を知る人が決める領域です。役割分担の考え方は、AI設計でDB設計はどこまで任せる？役割分担の考え方で整理しています。
プロトタイプでデータの持ち方を確かめる
データの持ち方は、項目の一覧表を眺めているだけでは、良し悪しが分かりにくいものです。動くプロトタイプに触れると、「この項目は入力が負担だ」「この区別がないと集計できない」といった気づきが早い段階で出てきます。
動く実物で確かめられること
プロトタイプでデータの持ち方を確かめるときは、次のような手順が有効です。
- 現実に近いサンプルデータを入れる。数件では見えないことが、数十件、数百件になると見えてくる
- 1つ目で決めた「問い」に、画面や集計で答えられるかを試す
- 入力する側の手間を体験する。入力が重いと、そもそもデータが溜まらない
- 運用側の画面で、必要なデータを見つけて確認できるかを試す
運用側の画面をどこまで作るかは、新規事業の管理画面開発｜最初に作る範囲の見極め方が参考になります。入力する側の反応を確かめる質問の立て方は、プロトタイプのユーザーテスト｜新規事業での確かめ方と質問で扱っています。
動くものがあると、社内の話もかみ合う
データの持ち方は、事業の責任者、現場、開発側で見ている景色が違います。責任者は「何を判断できるか」を、現場は「入力の手間」を、開発側は「構造の整合性」を見ています。同じ実物を前にすると、それぞれの観点を同じ土台で話せるようになります。企画書だけでは伝わりにくいことを実物で示す考え方は、新規事業のアイデア検証方法｜動くシステムで確かめる手順でも触れています。
相談前に整理しておきたいメモ
開発会社に相談する前に、次のようなメモがあると話が早く進みます。完璧に埋める必要はなく、空欄が残っていても構いません。
- 事業で確かめたい仮説は何か（上位3つ程度）
- その仮説に答えるために、知りたい数字や状態は何か
- 利用者、会社、契約など、事業の中心になる登場人物は誰か
- 状態の変化として、どんな出来事を残したいか
- 個人情報や機密にあたるデータを扱うか。扱うなら、何のために取るのか
- 将来つなぎたい外部のサービスや、既存の仕組みはあるか
- 作ったシステムのデータの取り出しや引き継ぎは、契約上どう扱われるか
最後の項目に関わる権利の考え方は、システム開発の著作権帰属は誰のもの？契約前の確認点も確認しておきたいところです。システム全体を事業の形としてどう組み立てるかは、新規事業のシステム設計とビジネスモデルの作り方で扱っています。
まとめ
新規事業のデータ設計で押さえたい点を整理します。
- データは後から変えにくく、取っていない記録は遡れない。だから、最初の設計が効いてくる
- 最初に決めたいのは、事業の問い、記録の単位、識別子とつなぎ方、項目の定義、取得目的と削除のルールの5つ
- 武器になるのは、事業を回すと自然に溜まり、時間とともに価値が増し、判断に使えるデータ
- 補助的な項目や集計用のデータは後から足せるので、最初から広げすぎない
- 項目の一覧表だけでなく、動くプロトタイプにサンプルデータを入れて、問いに答えられるかを確かめる
データの持ち方は、事業が走り出してからだと直しにくい分、最初に少しだけ時間をかける価値があります。ただ、最初から完璧を目指す必要はなく、変えにくい部分を先に決め、残りは確かめながら育てていく進め方が現実的です。
JustFit（株式会社LEGAREAが運営する完全オーダーメイドの受託開発サービス）は、「先に作って、後から決める（PROTOTYPE FIRST）」という考え方で、構想をもとに約1ヶ月で実際に動くプロトタイプを開発します。実物を見てから契約を判断できるため、データの持ち方のように言葉だけでは決めにくいことも、触って確かめながら詰めていけます。仕様が固まっていない段階でも相談できますので、詳しくはJustFitのサービス紹介をご覧ください。