モックアップの落とし穴

こんにちは。STARUPで製造業向けのプロダクト「ARCHAIVE」のプロダクトマネージャーをしている山下です。もともとフロントエンドエンジニア兼デザイナーとして、機能のモックアップを、ひたすら作ってfixしたものから実装していました。

この記事は、要件を固めるためにモックアップを使う人向けです。その他にも、モックアップが要件定義の入り口になっている人はたぶん心当たりがあるはずです。

ここ数年で要件定義のやり方が変わりました。AIに指示すると、動くモックアップが数分ででき上がります。ダミーデータを入れれば、その場でクリックできる画面になる。私も、新しい機能を検討するときは、まずモックアップを作って関係者に見てもらうことが多くなりました。

モックアップを見せると、打ち合わせで意見が出やすくなります。実際に動く画面を見ると、「ここはこうしたい」「この項目も要る」といった具体的な指摘が出てくる。早く要件を固められる感覚があって、便利です。

そこにある落とし穴

ただ、その打ち合わせの内容を持ち帰って実装しようとすると、うまくいかないことがあります。会議では、同じ画面を見ているのに、人によって話している内容がばらばらでした。見た目の話をする人、操作の話をする人、その機能自体が要るかを問う人。どれも妥当なのに、議論が噛み合わないまま進んでしまう。

この問題を、私は長いあいだうまく説明できませんでした。

5層UXデザインという補助線

最近になって、この違和感をうまく説明してくれる考え方に出会いました。UXデザインの古い定番モデル、Jesse James Garrettの「5層UXデザイン（The Elements of User Experience）」です。もちろんこれが唯一の正解というわけではなく、物事を整理するためのアイディアのひとつなのですが、私にはこれがよくしっくりきました。

良い体験は5つの層の積み重ねでできている。下ほど抽象的で、上ほど目に見える。

5層UXデザインとは、「良い体験は5つの層の積み重ねでできている」という考え方です。下ほど抽象的で、上へいくほど具体的な見た目になります。しかも上の層は下の層の上に乗っているので、下がずれると、その上は全部ずれます。ここではネットショップを例に、下から順に見ていきます。

戦略（Strategy）：なぜ作るか

一番下の土台。そのプロダクトは誰の何のためにあるのか、を決める層です。ここでは2つを同時に見ます。事業として何を達成したいか（ビジネス目標）と、ユーザーが本当は何を解決したいのか（ユーザーニーズ）です。ニーズはリサーチやペルソナ、行動観察から探ります。ネットショップなら、「売上を伸ばしたい」という目標と、「探している商品に早くたどり着きたい」というニーズを、ここですり合わせる。ここがずれると、上に何を積んでもずれます。

要件（Scope）：何を作るか

戦略を実現するために、何を用意するかを具体的に決める層です。どんな機能を持たせるか（機能仕様）と、どんな情報を載せるか（コンテンツ）の両方を洗い出します。ネットショップなら、「お気に入り登録」「レビュー投稿」といった機能や、商品写真・価格・在庫といった情報がここで決まる。同時に「今回はやらないこと」も決めておくのがコツで、これが曖昧だと要件は際限なく膨らみます。

構造（Structure）：どう組み立てるか

決めた要件を、どう並べてつなぐかを設計する層です。情報をどう分類するか（情報アーキテクチャ）と、操作にどう反応するか（インタラクション設計）を決めます。サイトマップやフロー図で、「どのページからどこへ行けるか」「エラー時にどうなるか」を描く。ネットショップなら、商品一覧→商品詳細→カート→購入という導線の骨組みが、この層です。

骨格（Skeleton）：どう配置するか

構造を、具体的な画面の配置に落とす層です。ボタン、入力欄、ナビゲーション、画像、テキストを、画面のどこに置くかを決めます。まだ色や装飾はつけず、ワイヤーフレームで「要素の並び」だけを固める。ネットショップの商品詳細なら、上に写真、その下に価格と購入ボタン、さらに下にレビュー。こうした配置を、見た目の前に決めておきます。

表層（Surface）：どう見せるか

一番上、目に映る見た目そのものを仕上げる層です。色、タイポグラフィ、余白、質感を決め、骨格で並べた要素に視覚的な優先順位をつけます。狙いは、ただ美しく仕上げることではなく、大事な情報や次の操作が自然と際立つようにすること。ネットショップなら、購入ボタンを目立つ色にして、迷わず押してもらう、といった調整がこの層です。

実際には、層を行き来する

実際には、これらの層はきれいに順番通り進むわけではなく、下と上を行き来しながら重ねていくものです。それでも、いま自分がどの層の話をしているのかが分かるだけで、設計の議論はぐっと整理されます。

こう考えると、あれは何だったのか

まず、モックアップという道具の性質です。AIが作るモックアップは、いきなり一番上の表層まで立ち上げてしまう。本当はまだ握れていない戦略や構造が、あたかも決まったことのように、色のついた画面になって出てきます。

そう考えると、あの意見の噛み合わなさも納得がいきます。人が返してくれる意見は、見えているもの、つまり表層に自然と偏る。特にクライアントに見せるときは、それが顕著に出ます。「この情報は一緒に見たい」。でも本当の食い違いは、その下の構造や要件にあることが多い。表層で出た声を表層のまま直すから、下のずれは温存されて、あとで辻褄が合わなくなる。会議で全員がバラバラだったのも、それぞれが違う層の話を、同じ画面を指しながらしていたからでした。

モックアップには情報が多すぎるのです。

じゃあ、どう付き合うか

先に言っておくと、モックアップをやめる気はありません。実際に触れる画面があるからこそ、本音が出る。強力な道具です。問題は使い方のほうで、私がいま試しているのは、2つの動きと、1つの心構えです。

何を、どの順で見せるか

まずやるのは、モックアップの前に「地図」を用意することです。

情報量を落として全体像だけを示した「地図」。画面が何枚あって、どこからどこへ繋がるのか、業務フローと情報設計が一目でわかる。

Figmaなどで、色や装飾を削ぎ落として、画面のつながりと業務フローの全体像だけを描いた情報の地図を先に共有する。「どこからどこへ繋がるか」を握ってから、締めにモックアップをその一部としてチラ見せする。順番を入れ替えるだけで、みんなが同じ全体像の上で話せて、議論が安定します。

複数の選択肢を用意する

その上で効くのが、案を1つに絞らないこと。一枚だけ見せると、それが「決定」に見えてしまう。だから方向性の違う案を2〜3個並べて、「どうですか」ではなく「どれが近いですか」と聞く。すると議論が、細部ではなく「どっちの方向か」という一段深いところに立ち返ります。

どのレベルで話すか

出てきた意見を、その場で表層のまま直さない。「なぜ？」まで下りて、それが本当はどの層の話かを見極め、できるだけ深いところで食い止めてから具体へ降ろす。たとえば「本質的な課題はデータの持ち方では？」と、一段深い問いを口にしてみる。自分がいまどの層の話をしているかを声に出すだけでも、あの錯綜はかなり減ります。

仕様書ではなく叩き台

モックアップのコードを捨てること自体には抵抗がありません。実装する時にはどうせ書き直します。厄介なのは、一度見せた表層が、みんなの頭に“決まったこと”として残ること。だから「これは仕様書ではなく叩き台です」と宣言して、粗いまま見せる。「表層がそのまま要件になる空気」を脱却しないといけません。

運用してみて

5層を意識するようになって変わったのは、打ち合わせの途中で「今のは表層の話で、決めたいのは要件のほうだ」と引き返せるようになったことです。そのぶん、あとから前提がひっくり返って要件を作り直す、という後戻りは減りました。打ち合わせの後に残る「なんか噛み合わなかったな」というモヤモヤも、ずいぶん小さくなった気がします。

ですが正直、これで全部うまくいくわけではありません。地図を先に作る手間は、やっぱりめんどうです。モックアップのほうが早く盛り上がるので、つい飛ばしたくなる。「今どの層の話か」を毎回意識して喋るのも、慣れるまでは手間です。解像度を落とすさじ加減も難しくて、粗すぎると反応が鈍るし、作り込みすぎると、結局は見えすぎに逆戻りしてしまう。このあたりは、いまも手探りです。

まとめ

AIでモックアップが一瞬で作れるようになって、要件定義はぐっと速くなりました。でも、速くなったぶん、表層だけが先に走って、土台の合意を置き去りにしやすくもなった。

モックアップは情報を載せすぎて、それ自体は全体の地図になりません。だからこそ、見せる情報を確からしさで絞って、地図を先に、モックアップは最後に。意見はすぐに表層で直さず、一度深いところまで掘り下げてから、具体へ降ろす。そして語り手は、いまどの層の話をしているのかを、意識して口に出す。

それだけで、モックアップの「いいですね」は、ずっと確かなものに変わっていく気がします。

参考文献

1. Jesse James Garrett『The Elements of User Experience: User-Centered Design for the Web and Beyond』（New Riders）
2. Jesse James Garrett "The Elements of User Experience"（原典エッセイ、jjg.net）