モックデータを実運用に即して設計し、チームの合意形成を進める

こんにちは。ウォンテッドリーでバックエンドエンジニアをしている小室 (@nekorush14) です。新たな開発を始める時、ビジネスロジックの実装やデータが揃う前に動くものをチームで確認しながら仕様を詰めていきたい場面が多くあります。今回は、開発初期でモック実装を作る際に私が意識しているモックデータの設計とチームでの合意形成にどのように繋げているかをお話しします。

はじめに

新規機能の開発初期では、バックエンドの長時間処理を伴う Job や、他のマイクロサービス側の応答がまだ揃っていない状態で、フロントエンドや UI の動作を先行して確認したい場面がよくあります。サーバ実装の完了を待たずに動くものをチームに示せると、その上で UI や仕様の議論を一足先に進めることができます。

このような場面では、多くの場合 API のスキーマ (リクエスト / レスポンスの I/F) を先に決めるスキーマファーストの進め方を取り、そのスキーマに合わせたダミーデータをモックとして用意します。特にウォンテッドリーの開発では protobuf によるスキーマ駆動開発を導入しているため、その境界線でモックを挟み開発を進めたくなることが多いです。

一方で、実際にモックで画面を動かしてみると、スキーマ定義の段階だけでは気づけなかった考慮漏れが見つかることがあります。本稿では、このような考慮漏れを早期に拾い上げ、チームで認識を合わせながら仕様をあるべき姿へ高速で修正するために実運用に即したモックデータを設計するアプローチを共有します。

モックデータを実運用に即して設計する

スキーマに合わせたダミーデータを用意するだけであれば、フィールドに型を合わせた何らかの値を指定すればエラーなく実行することは可能です。一方で、開発初期において本来モックで試したいのはスキーマに合わせたプログラム的な正しさだけではなく、データそのものの確からしさだと考えています。

データの構造と粒度を実運用に合わせる

データの構造・粒度・関係性などの画面表示や分岐のロジックで必要となる値をモックデータとして意図的に再現するようにします。値そのものは「モック」データなので架空のデータで問題ありませんが、可能な限り本番運用時に発生しうる値 (ビジネスロジックの演算結果や文字列) を推測して作成します。

私自身がモックデータを設計するときに意識している点は以下の通りです。

データ件数が数件の場合と数十件の場合で表示が崩れる・不自然になる可能性がある
画面遷移するときにデータが空で返却された場合の考慮が漏れる可能性がある
欠損したデータ返却を許容する仕様などの特殊なケースに対する考慮が漏れる可能性がある
画面操作と処理結果のデータの組み合わせがプログラム上は正しく動作するが挙動として違和感が生じる可能性がある
エラー発生時の画面表示が仕様として違和感のあるものになっている可能性がある

モックデータと言いつつ、実態はテストデータの側面が強くなっています。単純にスキーマを満たすためのデータではなく、システムの挙動が意図通りかを確認し、仕様の違和感に気づくためのデータを意識しています。

以下は架空の「ブログ記事作成アプリ」の記事一覧を想定した例です。

Goodなモックデータ

type ArticleListItem = {
  id: string;
  title: string;
  summary: string;
  author: { id: string; name: string };
  coverImageUrl: string;
};

const mockArticles: ArticleListItem[] = [
  {
    id: "1",
    title: "技術選定で迷ったときに見直す3つの観点",
    summary: "新規プロジェクトの技術選定では、トレンドより先に確認すべき要素があります。",
    author: {
      id: "1",
      name: "山田 太郎",
    },
    coverImageUrl: "https://example.com/cover-1.png",
  },
  {
    id: "2",
    title: "マイクロサービスアーキテクチャを採用するときに陥りがちな落とし穴とその回避方法を、実プロジェクトの経験から振り返る",
    summary: "サービス分割の粒度、トランザクション境界、運用負荷など、採用前に確認すべき論点を整理します。",
    author: {
      id: "2",
      name: "Taro Yamada",
    },
    coverImageUrl: "https://example.com/cover-2.png",
  },
  // カバー画像 URL が空: placeholder 表示と余白の検証
  {
    id: "3",
    title: "画像未設定の記事を一覧でどう表示するか",
    summary: "カバー画像が未設定のときにカードがどう見えるかを確認するための行。",
    author: {
      id: "3",
      name: "T",
    },
    coverImageUrl: "",
  },
];

Not goodなモックデータ

type ArticleListItem = {
  id: string;
  title: string;
  summary: string;
  author: { id: string; name: string };
  coverImageUrl: string;
};

const mockArticles: ArticleListItem[] = [
  {
    id: "1",
    title: "Article 1",
    summary: "Summary",
    author: {
      id: "1",
      name: "Author 1",
    },
    coverImageUrl: "https://example.com/1.png",
  },
  {
    id: "2",
    title: "Article 2",
    summary: "Summary",
    author: {
      id: "2",
      name: "Author 2",
    },
    coverImageUrl: "https://example.com/2.png",
  },
  {
    id: "3",
    title: "Article 3",
    summary: "Summary",
    author: {
      id: "3",
      name: "Author 3",
    },
    coverImageUrl: "https://example.com/3.png",
  },
];