昨日、ワイヤーフレームとは何なのか問題についてのスライドを公開した。非常にあっさりしたスライドなのでひとまず見てみてほしい。
前々から、ワイヤーフレームはスペック検討が主旨であり、デザインやレイアウトといった見てくれの検討をするものではないというのを必要に応じて述べているんだけども、その言説がパーマリンクを持ってないのが不便だなと改めて思ったからでもある。
ワイヤーフレームとは何なのか問題そのものだけでなく、関連して思っていることはいろいろあり、そうした背景のようなものの一部を以下に述べておきたい。
つい今週開催されてたMAX Japanで、Adobeが日本特有のデザインプロセスに対するソリューションとしてXD用にQuick Mockupなるものを発表したようだが、これも結局、ワイヤーフレームなのか、デザインの中間成果物なのかがはっきりしない印象がある。日本特有のデザインプロセスっていうのは、ビジネスユーザー（非デザイナー）がワイヤーフレームを書いてるから云々という話のようなのだが、そもそもの話として、ワイヤーフレームとは何なのか？ ワイヤーフレームで何をしたいのかに依存するのではないか。
Adobe、どの層にエスノやってるのかわからんけど、ワイヤーはスペック検討のためであってレイアウト検討のためではないというのが全く伝わってないようなので、リリースされるブツが常にずれてると思う。
— Morita, Yu (yuu) (@securecat) December 3, 2019
デザイナーのつくるワイヤーフレームは、それはデザインの中間成果物という色が濃く、えてして配置される要素群がその場面場面において都合のいいスペックに閉じている。これは実装者が参照する仕様という面ではまったく役に立たない。上層ステークホルダー向けのイメージボードとしては役に立つだろうが、そんなものをXDで作りこむ意味はあるのだろうか。また、XDでの成果物が仕様をしっかりインクルードしてないのであれば、そこをきちんと踏まえた仕様書が別途必要になるわけだが、それは何で作ったどのようなものなのか？ パワポかExcel等で画面仕様書があり、それを参照しながらXDでデザインの中間成果物としてのワイヤーフレームを作ったということだろうか？ 実装者は画面仕様書とワイヤーフレームの両方を参照しながら実装しなければならないのだろうか？
一方で、非デザイナー（というか、原則的にはインフォメーションアーキテクト。もしくはそのスキルを備えたWebディレクター等）のつくるワイヤーフレームはスペック検討のために作っている。コンテンツ仕様や、要素自体の許容範囲などの確定資料にもなり、すなわち要素設計としての仕様書となりうる。したがって、デザインやレイアウトといった見てくれにまつわる内容は排除したほうがいいのだが、XDで作るとどうしてもそうした見てくれ系の操作に時間を要することになるが、まことに無駄な稼働が増えているといえる。ここまで書いて思ったが、この無駄な稼働を少しでも短縮させようというのがQuick Mockupなのかもしれない。ただ、それなら最初からXDではなく、ワイヤーフレームはWordで要素の箇条書きでも問題ないような気がする。ただしその場合、渡されたデザイナーの強さ（抽象度をどこまで上げられるかとかの能力差）に左右される可能性はある。
また、チーム内の意思伝達がいまいちだと、非デザイナーのつくったワイヤーフレームが、デザイナーにとってはデザイン指示書として捉えられてしまうことがある。ワイヤーフレームをつくった非デザイナーがインフォメーションアーキテクトだったならばまだしも（インフォメーションアーキテクトはデザイナーを包含、ないしはデザインスキルを備えているはずなので）、真にビジネスユーザー（この文脈でいうと、クライアントの担当者などだ）が作ったワイヤーフレームの場合によく起きうる不幸な現象が、まさにそれだ。その結果、クライアントは、ワイヤーフレームに内包される仕様をしっかりおさえつつも、画期的なインタラクションを備えた素晴らしいデザインがあがってくることを期待しているにも関わらず、実際には「ワイヤーフレームに色をつけたもの」がデザイン成果物として出てくるのである。ワイヤーフレームを受け取ったデザイナーが、それをデザイン指示書だと受け止めていたからにほかならない。
このことからも、スペック検討のために作成しているワイヤーフレームからは、デザイン的・レイアウト的な情報をあらかじめ排除しておいたほうが安全であろうことは間違いない。しかし、見てくれの表現を利用して仕様を述べるというケース自体はありえるので、見てくれ情報を排除しにかかったとしても、完全にテキストの箇条書きだけになるのかというと、必ずしもそうではない。つきつめていえば結局はバランスだよねということになってしまい、ワイヤーフレーム作成者の力量、場数の量、経験値といったものに品質が帰結してしまう。熟練者が手掛けると精度が高まるということ自体は悪いわけではないのだが、チーム内の共通理解・統一規格としての品質は、属人性を低減し安定性にふったほうが健全である。
根本的な対策としては、成果物定義（用語定義を含む）やワークフローをある程度業界内で統一していくことが考えられるのだが、そのための道のりはとても遠いし、なんせ日進月歩なインターネット界隈である。やってる最中から陳腐化、化石化、故事成語化していきそうな懸念が大いにある。
そこで現状、どんな組織でも確実な成果を見込める対策となるのが「合意」である。本記事の冒頭でリンクしている、非常にあっさりしたスライドの最後で述べているとおり、当該プロジェクトにおいてのワイヤーフレームとは、何であって何ではないのかという「合意」をあらかじめ関係者間できっちりとっておきましょうということだ。
ワイヤーフレームにまつわる四方山話というかエトセトラというかアラカルトというか（謎）、この辺の話はけっこう組織論とかロールモデルの話とかにも通じうるネタで面白かったりもするので、これからももっと研究を重ねていきたいと思っている。
ちなみに、ワイヤーフレームの話も出るかもしれないSmall IAさみっちょ#4は12月16日19時から、たぶんまたFacebook Liveにて。ゲストも来るので、お暇ならばぜひ～。(^O^)／
創元社
売り上げランキング: 898,635
