プロジェクトマネージャー（以下PM）のchakiです。
開発案件に入ると、こんな瞬間があります。
UX「体験設計は終わりました」
エンジニア「どんな画面になります？」
UX「それはこれからUIで詰めます」
エンジニア「じゃあAPIまだ決められないですね」
PM「……」
ここから、要件定義が始まります。
会議室が、少し静かになります。
UXはちゃんと準備してきています。
ユーザーストーリーも整理されている。
でも、開発の話をしようとすると、
会話が一瞬止まる。
この沈黙、見たことありませんか？
おかしいわけではないんです。
UXは体験を設計する言葉で整理しています。
開発はシステムを実装する言葉で考えています。
同じプロジェクトにいるのに、話している言語が違う。
なぜかみ合わないのか
UXが整理するのは、体験の言葉です。
- ユーザーは誰か
- どんな価値を届けるか
- どんな体験を提供するか
一方、開発が必要とするのは、システムの言葉です。
- どの画面で
- どんな情報を表示して
- その情報はどこから取得して
- 更新はどのAPIで行うのか
つまり、
UXと開発は同じものを見ているのに
整理している言葉が違います。
その関係を図にすると、こんなイメージです。
UXの成果物は「間違っている」わけではありません。
ただ、UXの言葉はそのままでは
開発の議論に使えない。
UXの言葉を、システムの言葉に
翻訳する工程が必要でした。
UX Requirements Bridge
（ユーエックス・リクワイアメンツ・ブリッジ）を作った
あるプロジェクトで、現場メンバーが作ってくれた要件定義のスケジュールを見たとき、体験設計で止まっていることに気づきました。
UX/UIのアウトプットはある。
でも、要件定義書の項目が埋まらない。
「このままでは、お客様が求める要件定義が完了しない。そして開発にも渡せない。」
そう気づいたとき、やったのはひとつ。
UXの成果物を、要件定義の言葉に置き換えることでした。
やってみると、こんな対応関係が見えてきました。
| UXの言葉 | 要件定義の言葉 | 何を満たすべきか |
|---|---|---|
| ユーザーストーリー | サービス要件 | ・ユーザーができることの一覧 ・サービスの提供価値 |
| ユーザーシナリオ | 業務フロー | ・ユーザー側の操作フロー ・管理画面側の操作フロー ・登場人物の整理（ユーザー・管理者・運用） |
| ユースケース | 機能要件 | ・画面ごとの機能一覧 ・条件分岐の整理 |
| ワイヤーフレーム | 画面要件 | ・表示条件 ・エラー状態 ・空の状態 |
| UI表示情報 | API要件 | ・どの情報をどこから取得するか ・登録・更新・削除の操作 |
| 体験の質 | 非機能要件 | ・対応デバイス・ブラウザ ・フォントサイズ基準 ・アクセシビリティ方針 ・性能要件（速度・可用性） |
UXの成果物を、そのまま開発に渡しても
実装にはつながりません。
UXと要件定義のあいだには、
成果物をシステムの言葉に変換する工程が必要です。
例えば、ユースケースを機能要件に変換すると、こうなります。
ユースケース（UXの成果物）
美容師が予約を確認する
↓
予約をタップ
↓
予約詳細を見る
機能要件 （要件定義）
予約一覧画面
・予約一覧取得API
・予約詳細画面への遷移予約詳細画面
・予約詳細取得API
・予約ステータス更新
UXの成果物が、画面とAPIを含む機能要件へ変換されているのが分かります。
私はこの工程を UX Requirements Bridge
（UXから要件定義への橋渡し）と呼ぶことにしました。
この問題は海外でも議論されています
UXの成果物が、そのまま開発に渡らない問題は 日本のプロジェクトだけで起きているわけではありません。
海外でも、UXと開発のあいだのギャップは よく議論されています。
例えば、UXから開発へ成果物を渡す工程は
「Design Handoff」と呼ばれることがあります。
（参考：Nielsen Norman Group Design Handoff: Delivering Designs to Developers）
Design Handoffでは、
- デザイン仕様
- コンポーネント
- 状態パターン
- インタラクション
などを整理して、エンジニアに渡します。
ただ、この議論の多くは
UI仕様の受け渡しにフォーカスしています。
今回のプロジェクトで直面したのは、 もう少し手前の問題でした。
UXの成果物を、
要件定義として成立する形に翻訳する工程です。
その翻訳の役割を担うものとして、 今回私は UX Requirements Bridge という整理を作りました。
UXが整理していたものは、
要件定義と無関係だったわけではありません。
ただ、開発の言葉に
翻訳されていなかっただけでした。
この対応関係を整理してみると、
もう一つ気づいたことがあります。
表の中に、抜けやすい場所がある。
例えばユーザーシナリオ。
UXが整理できるのはユーザー側の操作フローです。
管理画面の操作や、運用者の動きは
別途整理が必要になります。
UXの成果物は
体験の入り口を描いている。
でもシステム全体を描いているわけではない。
もう一つ問題があります。
UIデザインが始まると、モーダルが追加されたり、
状態パターンが増えたりします。
画面の機能が増える。すると、API設計が終わったあとに「この情報も必要ですね」という話になります。APIが足りなくなる。
誰かが悪いわけではありません。ただ、整理されるタイミングがずれている。その結果、手戻りが発生します。
だから、順番が必要だった
表だけでは足りませんでした。
問題は、UXの成果物が足りないことではありませんでした。
順番が整理されていないことでした。
必要だったのは、要件定義の項目を埋めるための道筋でした。
要件定義書の各項目を埋めるために、どの順番で、誰が、何をアウトプットするのか。逆算して整理しました。
結果、こういう順番になりました。
- ユーザーシナリオ（ユーザーの行動）
- 画面遷移図（画面構造）
- ワイヤーフレーム（挙動確定）
- 機能要件（できることを定義）
- 画面項目詳細 / API整理（必要データ整理）
そのまま開発設計に入ってしまうことでした。
UIデザインの工程でモーダルや状態、導線が追加されると、
必要な機能やデータも変わります。
その結果、先に進めた設計やAPI要件が足りなくなり、
手戻りが発生します。
だから、開発設計に入る前に
機能要件と画面 / API要件を整理する順番が必要でした。
機能要件を確定させるには、WFで挙動が決まっている必要があります。
WFを作るには、画面遷移図が必要です。画面遷移図を作るには、ユーザーシナリオが必要です。
後ろから逆算すると、
前工程で何をFIXさせるべきかが見えてきます。
UXのアウトプットを、
開発が扱える要件に翻訳するには、この順番が必要でした。
整理してみて見えたこと
この構造を整理してみると、
少なくとも自分の中では
要件定義の進め方がかなりクリアになりました。
UXのアウトプットはすでにある。
でも、それをそのまま開発に渡すだけでは、
要件定義として成立しない。
UXの言葉を、開発が扱える要件の言葉に翻訳する。
そして、その翻訳が成立する順番を整える。
そう考えると、
要件定義で何を整理すればいいのかが
かなり見えるようになりました。
もちろん、これが唯一の正解というわけではありません。
プロジェクトやチームによって、
進め方は変わると思います。
でも今回のプロジェクトでは、
UXと開発のあいだにある「翻訳」と「順番」を整理したことで、
少なくとも自分の中では
納得できる構造を見出すことができました。
UXと開発は
対立しているわけではありません。
ただ、そのあいだには
UX Requirements Bridge が必要だっただけでした。
UXの成果物を要件定義へ翻訳する橋。
それが UX Requirements Bridge です。
goodpatch-tech.hatenablog.com
goodpatch.com
general editor：@inininin-design
