UIを先に作って確認してからDB接続へ｜手戻りを減らす開発の進め方

「動くものを見てから話したい」——非エンジニアのプロダクト担当者にとって、これは自然な感覚です。この記事では、画面を先に「見た目だけ」で作り、人が確認してからデータ接続に進む開発の流れを解説します。読み終えると、なぜ手戻りが減るのか、どう指示すればよいかが分かります。

この記事の結論

• 先に画面(見た目)を作り、人が確認してからデータを接続すると、作り直しが減る
• 見た目づくりに使う「仮のデータ」を Mock(モック) と呼び、これが早期確認のカギ
• Frontend(画面) と Backend(裏側) を分けて進めると、担当者ごとに並行作業できる
• プロダクト担当者は「見た目の確認」段階で仕様の齟齬を潰すのが最重要タスク
• AIツールを使えば、Mock画面の生成や仕様チェックを一部自動化できる

この記事が役立つ人

• エンジニアに開発を依頼する非エンジニアのプロダクト担当者・企画担当
• 「完成してから想像と違った」という手戻りに悩んだ経験がある人
• 開発の流れを理解して、適切なタイミングで確認・指示を出したい人

前提知識は不要です。専門用語はその都度やさしく説明します。

なぜこの問題が起きるのか(背景と原因)

多くの手戻りは「完成品を見て初めて認識のズレに気づく」ことで起きます。仕様書や口頭の説明だけでは、画面の使い勝手やボタンの位置まで正確には共有できません。

とくに画面(Frontend)と裏側(Backend)を同時に作ってしまうと、後から「やっぱりこの項目いらない」となったとき、両方を作り直す羽目になります。

> 用語メモ

> - Frontend(フロントエンド)=利用者が実際に見て触る「画面」の部分。

> - Backend(バックエンド)=画面の裏で動く「データの保存・計算・処理」の部分。データベースやAPIがここに含まれる。

> - API=画面と裏側がデータをやり取りするための「窓口」。

図: 開発の流れ

```mermaid

flowchart LR

A[要件・仕様の整理] --> B[Mockで画面を作る<br/>見た目だけ]

B --> C{人間が確認<br/>プロダクト担当}

C -->|修正あり| B

C -->|OK| D[Backend接続<br/>DB・API]

D --> E[結合テスト]

E --> F[リリース]

```

このように「画面OKが出てから裏側へ」進むことで、裏側の作り直しコストを避けられます。

解決するための5つのポイント

1. まず「Mock」で見た目だけの画面を作る

結論: 本物のデータをつながず、仮のデータで画面を先に作ります。これを Mock(モック)＝見せかけの仮データ・仮画面 と呼びます。

具体例: 商品一覧画面なら、実際のデータベースを用意せず「商品A ¥1,000／商品B ¥2,000」といった固定の仮データを埋め込んで表示します。

実践方法: エンジニアに「まずMockで画面を作って、確認させてほしい」と依頼します。この段階では動作の速さやデータの正確さは求めず、レイアウトと項目に集中します。

2. 人間の確認を「接続前」に必ず挟む

結論: 画面ができた時点で、実データをつなぐ前にプロダクト担当が確認します。ここが最大の手戻り防止ポイントです。

具体例: 「金額の横に税込表示が要る」「並び順は新着順にしたい」といった気づきは、画面を見て初めて出てきます。Mock段階なら修正が数時間で済みます。

実践方法: 確認では「項目の過不足」「操作の流れ」「表示ルール」の3点を見ます。後述のチェックリストを使ってください。

3. FrontendとBackendを分けて並行作業する

結論: 画面担当と裏側担当が同時に別々の作業を進められる体制にすると、開発が速くなります。

具体例: 画面担当がMockで見た目を詰めている間に、裏側担当はデータベースの設計を進める、という並行作業が可能です。

実践方法: 両者が「APIの仕様(どんなデータをどんな形で渡すか)」を先に合意しておくと、後の接続がスムーズです。プロダクト担当はこの合意の場に同席し、必要な項目が漏れていないか確認します。

4. 確認OK後にDB・APIを接続する

結論: 画面が承認されてから、裏側の本物のデータ処理(Backend)をつなぎます。

具体例: Mockの「商品A ¥1,000」の部分を、実際のデータベースから取得した本物の商品情報に差し替えます。画面の形は変えず、中身だけ本物にするイメージです。

実践方法: この段階での確認は「データが正しいか」「エラー時にどう表示されるか」に移ります。見た目の議論はすでに終わっているので、論点が絞られます。

5. 変更は「どの段階か」で影響を見極める

結論: 同じ変更依頼でも、Mock段階か接続後かで作業量が大きく変わります。早い段階の変更ほど安上がりです。

具体例: 「項目を1つ追加」も、Mock段階なら画面だけの修正。接続後だと画面・API・データベースの3箇所を直す必要があります。

実践方法: 変更を思いついたら、まず「今どの段階か」をエンジニアに確認します。緊急でなければ次のMock確認まで待つ判断も有効です。

| 変更のタイミング | 直す範囲 | おおよその手間(目安・推測) |

|---|---|---|

| Mock段階 | 画面のみ | 小 |

| 接続後 | 画面＋API＋DB | 大 |

| リリース後 | 上記＋データ移行・告知 | 特大 |

※手間は開発規模により変わります。上表は相対的な目安です。

AIやツールで自動化する方法

AIツールを使うと、Mock画面の生成や仕様の抜け漏れチェックを一部効率化できます。特定の製品に依存する必要はなく、手元の環境に合うものを選べば構いません。

• Mock画面の生成: v0、Figma Make、Cursor、Claude Code などに「〈画面の説明〉のMockを仮データ付きで作って」と依頼すると、見た目の叩き台が短時間で出ます。
• 仕様チェック: 生成AIに仕様書を渡し、「不足している項目・矛盾を指摘して」と頼むと、確認前の下ごしらえになります。
• 接続後の確認自動化: GitHub Actions などで、表示崩れやエラーを自動テストする仕組みを組めます(エンジニア担当領域)。

そのまま使えるMock作成依頼プロンプト

生成AIツールにそのまま貼って使えるプロンプトです。〈〉部分を自分の案件に置き換えてください。

```text

【役割】あなたはUI開発のアシスタントです。

【依頼】以下の画面を、実際のデータベースには接続せず、

仮データ(Mock)を埋め込んだ見た目だけの画面として作成してください。

• 画面名: 〈例: 商品一覧画面〉
• 表示したい項目: 〈例: 商品名・価格・在庫状況・カテゴリ〉
• 仮データ: 各項目のサンプルを3〜5件、それらしい値で用意
• 表示ルール: 〈例: 価格は税込・カンマ区切り、在庫0は「品切れ」表示〉
• 操作: 〈例: カテゴリで絞り込み、価格で並び替え〉

【出力の条件】

1. データ接続はまだ不要。仮データは画面内に直接埋め込む

2. レイアウトと項目の分かりやすさを最優先

3. 後でデータ接続しやすいよう、仮データ部分をまとめて記述

4. 確認者(非エンジニア)向けに、画面のポイントを箇条書きで補足

```

実践チェックリスト

Mock画面を確認する際のチェック項目です。

• [ ] 必要な項目がすべて表示されているか(過不足の確認)
• [ ] 表示ルール(税込・日付形式・並び順)は意図どおりか
• [ ] 操作の流れ(ボタン→次画面)が自然か
• [ ] エラーや空データ(該当0件)のときの表示を決めたか
• [ ] この画面で「本物のデータ」として何が必要かを裏側担当と共有したか
• [ ] 変更依頼は接続前に出し切ったか

まとめ

「見た目を先に作り、人が確認してからデータをつなぐ」——この順番を守るだけで手戻りは大きく減ります。カギは、仮データ(Mock)の段階でプロダクト担当が仕様のズレを潰すことです。

最初の一歩: 次の開発依頼で「まずMockで画面を見せてほしい」と伝え、上のチェックリストで確認してみてください。

次に読む記事

• 基礎: 「FrontendとBackendの違いを図解｜開発依頼で困らない基本用語」
• 実践: 「API仕様の合意で失敗しない｜非エンジニアが確認すべき5項目」
• 発展: 「GitHub Actionsで画面の表示崩れを自動検知する仕組み」

よくある質問

Q. Mock段階のデータは本番でも使われますか?

いいえ。Mockはあくまで確認用の仮データで、接続時に本物のデータへ差し替えられます。仮データの内容がそのまま公開されることはありません。

Q. 画面確認のとき、非エンジニアは何を見ればいいですか?

「項目の過不足」「表示ルール」「操作の流れ」の3点です。動作の速さや技術的な正確さは接続後の確認対象なので、この段階では気にしなくて構いません。

Q. FrontendとBackendを同時に作ってもらった方が速くないですか?

一見速く見えますが、仕様のズレが出たとき両方を直すことになり、結果的に遅くなりがちです。画面の承認を挟むことで、裏側の作り直しリスクを抑えられます。