✨ はじめに

昨今、アジャイル開発やリーンスタートアップの潮流により、ユーザー体験(UX)を第一に考えるプロダクト開発が注目を集めています。特にToC/ToB問わずサービスを展開する場合や、受託開発でクライアントが要件定義に慣れていないケースでは、**「画面ありき」**で考える「UXドリブン型開発」こそが大きな威力を発揮します。

本記事では

UXドリブン型開発 とは何か
どんなフローで進めるのか（Mermaid図付き）
各ステップでの成果物や進め方
デザイン重視ならではの注意点（工数・予算への影響）

などを、より深く掘り下げて解説します。デザイナーとエンジニアの連携が成功のカギとなる理由にも注目してください。

💡 1. UXドリブン型開発とは？

UXドリブン型開発とは、従来の「機能要件 → データ構造 → 画面設計」という順序を逆転させ、
まずはユーザーが触れるUI／画面(=プロトタイプ)をデザインし、そこから必要な機能やシステム要件を導き出す開発手法です。

一般的には「デザインプロセスドリブン」「UX先行」「画面先行」などの呼び方をされることもあります。

🎯 なぜ画面先行・UX先行なのか？

ユーザービリティを早期に検証できる
→ 使いづらいUIや不要な機能を、実装前に見直せるため手戻りが減る
ステークホルダーがシステムに詳しくなくてもイメージしやすい
→ プロトタイプを見ながら「こんな操作が欲しい」「ここを変えてほしい」と具体的な要望が出やすい
要件のブレを最小化
→ ドキュメントだけでは見落としがちな点も、実際に触れる画面で確認することで発見が早まる

🤝 2. 受託開発や要件定義が苦手なクライアントにも有効

2.1 クライアントが要件を言語化しづらい場合

受託開発では、クライアントが「何を作りたいのか」を整理できていないケースが珍しくありません。
UXドリブン型であれば、

FigmaやSketchなどのデザインツールで仮の画面を作り
それを見せながら「こんなイメージでしょうか？」とヒアリング

といった形で、会話ベースで仕様を固められるメリットがあります。

2.2 コミュニケーションコストの削減

文章だけの要件定義書だと、読むだけでも負荷がかかり、認識のズレが生じやすいもの。
画面モックを使えば、

クライアント：「ここがわかりにくい」
開発側：「では、ボタン配置をこちらに変えましょう」

といった直感的なやり取りができます。

2.3 ビジネスサイドも納得しやすい

社内にエンジニアが少ない企業では、**「画面を起点とした要件すり合わせ」**が圧倒的に有効。

画面遷移・入力フォームの項目が明確になると、予算やスケジュール感も想定しやすい
変に余計な機能を盛り込むことを防ぎ、本当に必要な部分を優先実装できる

🌏 3. なぜToC/ToB問わず有効？

区分	特徴	UXドリブン型の利点
ToC	一般ユーザーが対象。多様なユーザー属性 UIへの要求が高い	ユーザーの操作性への不満が直ちに離脱率に繋がりやすい。画面デザインを先行して検証することで離脱を防げる
ToB	業務システムや社内ツール。効率や正確性が重要	従業員が日常的に使うツールは UIが悪いと業務効率が大幅に落ちる。事前に運用フローを画面で共有し、実際の業務イメージを確認できる

ToCサービス
- UIや操作性が悪いと即座にユーザーが離脱してしまう
- 事前にプロトタイプで「これならわかりやすい」という感覚を確立するのが大事
ToBサービス
- 特に業務フローと紐づくため、運用担当者や現場担当者のヒアリングが肝
- 画面を見せながら「ここで在庫を確認して、次に◯◯を登録する」といった詳細フローを可視化できる

✨ 4. UXドリブン型開発の全体フロー (Mermaid図)

以下のMermaid図は、AからDの間でループすることを意識した形にアップデートしました。
ユーザーテストやフィードバックをもとに、画面デザインや要件を何度も見直すサイクルがポイントです。

💡 ポイント

A（ユーザーリサーチ）→ B（プロトタイプ作成）→ C（ユーザーテスト）→ D（機能要件化） の工程を何度も繰り返すことにより、要件が曖昧な段階でも少しずつ具体化できる。
要件が固まったら E（開発・実装） へ進むが、開発中も必要に応じてデザインやプロトタイプに戻る場合がある。
最終的にリリースしても、**運用フェーズ（G）**でのフィードバックを新たに反映し、さらなる改善サイクルが続く。

📝 5. 各ステップで作る成果物と進め方

5.1 ユーザーリサーチ

成果物
- ペルソナ資料 (「どんなユーザーが、何を求めているのか」)
- ユーザーストーリー (例：「○○なユーザーが、△△を達成するためにこのサービスを使う」)
- 優先度リスト（ターゲットと機能候補の整理）
進め方
- ユーザーインタビュー、アンケート、業務フローの観察などで、実際の課題や潜在ニーズを洗い出す
- ここで発見された問題点や希望がプロトタイプ作りの出発点になる
- 重要なのは“技術的に実現できそうか”も頭の片隅に置くこと。エンジニアにもリサーチ段階から参加してもらうとベター。

5.2 画面プロトタイプ作成 (Figma)

成果物
- Figmaで作ったワイヤーフレーム/モック
- 画面遷移図やコンポーネント定義 (デザインシステムを意識すると尚良い)
進め方
1. ざっくりとしたワイヤーフレームをまず作る
2. 必要に応じてハイファイUI（実物に近いビジュアル）まで落とし込み
3. クライアントやチームに共有し、「こんなイメージですか？」と確認

ポイント:

Figmaの「コメント機能」を使うと、画面上に直接フィードバックを書き込めるので便利

エンジニアから「このアニメーションはかなり工数がかかる」などの実現可否フィードバックを早めにもらうようにする

5.3 ユーザーテスト / フィードバック

成果物
- テストレポート (どこでつまづいたか、どの機能が不足か)
- Figmaのコメント欄でのフィードバック一覧
- 優先度別の改善リスト
進め方
- 社内外のテスターやクライアント、時にはエンドユーザーに近い人へプロトタイプを触ってもらう
- 「どこが使いにくかったか」「何を期待していたか」をヒアリングし、画面または要件を修正
- 大掛かりな変更が必要になった場合は再度ワイヤーフレームへ戻る

5.4 画面を軸に機能要件化

成果物
- Issueリスト (GitHub, Jira, Redmineなどで管理)
- ユースケース定義 (例：「A画面でxxボタンを押す → △△のデータをDBに登録」など)
- API仕様書 / ER図 (データベース設計)
進め方
1. Figma上の画面や操作フローを参照しながら、必要な機能を洗い出す
2. 「誰が・どの画面で・何をするか」から逆算して、裏側のデータ構造やビジネスロジックを決定
3. Issueに落とし込み、**受け入れ基準(AC)**を明記
  - 例：「購入ボタンを押したら在庫が正しく減算され、購入履歴が登録される」
4. 必要に応じて再度プロトタイプを更新し、UXと実装可能性のバランスをとる

🔧 6. 開発・リリース・運用の流れ

6.1 開発・実装

成果物
- コード (フロントエンド/バックエンド)
- テストコード / CI/CD 設定
- スプリントごとのデモ資料 (開発チーム内やクライアント向け)
進め方
- 短いスプリント(例：2週間)単位でバックログのIssueを消化
- フロントエンド: Figmaのレイアウトを参考にコンポーネント実装
- バックエンド: API・DB・業務ロジックの実装 → テスト
- 実装中に技術的課題が発生した場合は、再度デザインと調整して画面/仕様を修正

6.2 検証・リリース

成果物
- テストレポート (単体・結合・受け入れテスト)
- リリースノート (どのIssueが実装されたか)
- インシデント/障害対応レポート (必要に応じて)
進め方
- ステージング環境などでQA担当がテスト → 問題なければ本番リリース
- **MVP（最小限の機能）**での早期リリースを行い、ユーザーから実際の使用感をフィードバックしてもらうのがおすすめ

6.3 運用・継続的フィードバック

成果物
- アクセスログ・ユーザー問い合わせ
- 改善要求や追加機能のロードマップ
- 次回スプリント用のIssue
進め方
- リリース後に得られるデータやユーザー声を分析して、次の改善施策を検討
- 必要に応じて再びFigmaでモックを更新 → 開発のスプリントに取り込む
- このサイクルを回し続けることで、生きた仕様としてどんどん磨かれていく

⚠️ 7. デザイン重視による注意点

UXドリブン型開発では、デザイナーが中心となり華やかなUIや多彩なアニメーションを提案するケースも多いです。しかし、美しいデザインがそのまま実装可能とは限りません。ここで気をつけるべきポイントをまとめます。

実装難易度と工数の見積もり
- デザインは理想を描きやすいが、実現には高度な技術や長い工数がかかる場合がある。
- 例: 複雑なアニメーションやインタラクション → パフォーマンスやブラウザ互換性の問題。
- エンジニアに早期に相談し、「どれくらいコストがかかるか」を見積もってもらうことが大切。
予算オーバーとスケジュール遅延のリスク
- こだわりすぎるあまり、当初の予算や納期をオーバーしてしまう可能性がある。
- デザイナーとPO/PMが密に連携し、優先度を明確にする（必要なところにリソースを割き、不要な部分は割り切って削る）。
エンジニアのフィードバックを随時取り入れる
- 「この操作フローはサーバー側で大幅に改修が必要」など、技術面の制約はデザイナーにとって盲点になりがち。
- 日々のデイリースクラムやデザインレビューでエンジニアの意見を拾い、デザインを適宜修正。
- ここが疎かになると「見た目は良いが全然動かない」「予算を超過した」状態に陥りやすい。
プロトタイプと実装版が乖離しすぎないようにする
- Figmaのモーションやコンポーネント設定が、そのままコードベースで再現できるとは限らない。
- **「プロトタイプ = 実装のベース」**という意識を共有し、無理な部分は調整する。

🔍 8. 従来型開発との比較表

以下の表は、従来型の「要件定義 → 設計 → 開発 → テスト」（ウォーターフォール的）と、**UXドリブン型（画面先行型）**の違いをまとめたものです。

項目	従来型 (機能先行)	UXドリブン型 (画面先行)
要件定義の流れ	ビジネス要件・機能要件からスタート UIや画面設計は後回し	まずUI/画面プロトタイプを作りそこから機能要件を逆算
ステークホルダーとの合意形成	ドキュメントベースで説明しがちシステムに詳しくない人には理解が難しい	画面を見ながら説明できるため、合意形成が早く、認識ズレが少ない
手戻りリスク	画面が完成してから「イメージと違う」と指摘されるリスク大	プロトタイプ段階でユーザーやクライアントが確認手戻りを実装前に最小化
開発期間	最初に厳密な仕様を固めようとする分、初期に時間がかかり、変更にも弱い	仕様が変わってもプロトタイプベースで柔軟に修正でき、アジャイルとの相性も良い
最終的なUX品質	後工程でUIに注力するため、 UXの問題が末期に発覚しがち	常にユーザー視点からデザインを検証するため、最終的なUX品質が高くなりやすい

🌟 9. まとめ

なぜこのプロセスが必要か？
1. ユーザーのリアルな反応を最速で把握 → 不要機能や使いづらさを実装前に洗い出せる
2. ステークホルダー/クライアントが要件を出しやすい → 画面を見ながら話すため、理解しやすくアイデアも出やすい
3. ToC/ToB問わず競争力に直結するUXを先行設計 → 業務効率やユーザー満足度を左右するUIを短いサイクルで改善し続けられる
4. 繰り返しのループで仕様を徐々にブラッシュアップ → 画面プロトタイプと要件定義を行き来することで、要件が曖昧なままでもスタートでき、徐々に確実な設計に仕上がっていく
気をつけるべき点
- 理想のデザインを追い求めすぎると、実装不可・工数超過・予算オーバーに陥る危険性
- エンジニアとのコミュニケーションを密に取り、実現可能性を常に確認しながら進めることが成功のカギ
Figmaを使ったプロトタイプ駆動
- Figmaでワイヤーフレーム → ユーザーテスト → 改善 → 画面ごとの機能要件化 → Issue化、という流れが王道
- 画面が事実上の仕様となり、手戻りコストを抑えられる
リリース後も「生きた仕様」として進化させよう
- 運用中のユーザーデータや問い合わせ内容を蓄積し、FigmaやIssueに随時反映
- 必要に応じてプロトタイプを更新し、短いスプリントでリリースを継続する

🎉 おわりに

「画面ありきでシステムを考える」UXドリブン型開発は、特に要件定義が難航しがちなプロジェクトや、UI/UXが成果に大きく影響する事業で力を発揮します。
Figmaなどのプロトタイプを使うことで、ビジョンと設計を繋ぎやすく、開発チーム・クライアント・ユーザーが同じ未来像を共有できるのが最大のメリットです。

ただし、美しいデザインがそのまま技術的に再現できるわけではなく、工数や予算を圧迫する場合も十分ありえます。
エンジニアとの連携をしっかり行い、「ここは外せない」「ここはコストに見合わない」など常に調整し続けることが、UXドリブン型開発成功のコツです。

もし「プロジェクトの初期段階で要件がうまくまとまらない」「クライアントの要望が毎回変わってしまう」といったお悩みがあれば、ぜひこのUXドリブン型のアプローチを試してみてください。より短いサイクルで価値を提供でき、最終的なプロダクトの満足度も高まるはずです。