こんにちは、株式会社SINAPの守谷です。

今回は、2009年7月24日（金）19:00からSINAPのオフィス内にて行われた勉強会、「⁠ワイヤーフレームコミュニケーション研究会」第一回目の内容のレポートをお届けします。この研究会の企画をされたのは昨年「SINAP TALK Vol.2」でご講演いただいた株式会社エフエックスビイの原一浩さんです。

もともとこの研究会は、原さんがTwitter上で「デザイナーがひっぱられないワイヤーを素早く作る研究会をしたい」と発言されたのが開催のきっかけでした。

発言の瞬間には「ワイヤー」とは何かという言及はまずは置いておいて[1]⁠、原さんをTwitter上でフォローしているワイヤー（フレーム）を「作る」側のディレクターをはじめ、ワイヤー（フレーム）から「デザインを起こす」側のデザイナーももちろん、大勢の人達が是非研究会を開催しようと原さんに同調していったのが始まりです。

会当日に「ワイヤーフレーム」という言葉の指すもの、及び働きなどまで言及しましたので後述します。

研究会の主なる議題は以下の通り。

そもそもワイヤーフレームとは何を差すのか（参加者の認識集め／意識合わせ⁠）⁠、一言にワイヤーフレームとは言っていてもどんな種類があるのか（名称を含めての質問⁠）⁠、こういう悩みが出るのは何故なのか、など。あらかじめ原さんがTwitterに配信された声などを基にまとめて下さっていて、そこから生まれた議題を中心に研究会が進められて行きました。

参加者は30名以上。その参加者全員が前向きに議題に向き合えるように、スライドの最初には研究会の心得（不安な意見も恐れず挙手する／人の話はちゃんと聞く／間違った事を言ってもあとでブログなどで酷評しない、など）が差し込まれたり、最初の議題では全員からの意見を広く拾えるように記入式にて意見を集るなど、色々な工夫の施された会でした。

まだ「ワイヤーフレームコミュニケーション研究会」の開催自体が一回目ですので、「⁠ワイヤーフレームとはこうあるべき」という明確な意見や結論が出たわけではありませんが、第一回目の本会を見渡して印象的だった議題と見解を原さんが以下にまとめてくださいましたので、お届けします。

こんにちは、今回ワイヤーフレームコミュニケーション研究会を企画したエフエックスビイの原です。Twitterでワイヤーフレームに関する研究会がしたいとつぶやいたところ、あれよあれよという間に人が集まって開催された今回の会。まずは当日の参加者の割合から書いてみます。

ワイヤーフレームというと、デザイナーがディレクターから渡されるものというイメージがあります。ワイヤーフレームについて思い悩むことが多いディレクターが一番多い印象でした。デザイナーが3割くらい、発注側であるWeb担当者が1割ほどといった感じです。

会は、誰か知見者がノウハウを提供して話すセミナー形式ではなく、参加者全員で与えられた議題について話し合うフリーディスカッション形式で行われました。そのため、たまに脱線することは想定されましたし、用意されたテーマの順で進まないことは十分考慮されましたが、それはそれで良いかなくらいに考えてました。結果的には様々な意見が出、スムーズに進んだとおもいます。

今回話したトピックは以下の5つでした。

1. ワイヤーフレームって何ですか？
2. ワイヤーフレームにデザイナーが引っ張られてしまった経験は？
3. デザイナーが引っ張られないワイヤーフレームを作るにはどんな工夫が考えられるか？
4. コミュニケーションとしてのワイヤーフレームとドキュメントとしてのワイヤーフレームがある？
5. ワイヤーフレームの共通ガイドラインはあったほうがいいと思いますか？

流れとしては、ワイヤーフレームについて議論する前に、"ワイヤーフレームという言葉について皆がどう認識しているんだろう？"という定義を確認しておくべきということで「ワイヤーフレームって何ですか？」というテーマで、まずは皆に付箋にそれぞれどういうものとしてとらえているかを書いて紙に貼っていただきました。その中で印象的なものをピックアップしていきます。

ワイヤーフレームって何ですか？

大きく分けると、ワイヤーフレームの認識としては、提案用途、設計作業用途、情報伝達および共有用途、仕様書用途というものがあるというのが今回のワークショップで参加者の認識として持っているというのが浮かび上がってきました。もちろんワイヤーフレームの学術的方面での定義は様々あると思いますが、少なくても現場でワイヤーフレームを使用している人たちにとっては上記用途を全てもしくは一部を潤滑にするために使用していることが伺えました。

また、どういうものをワイヤーフレームと定義しているかについても、細かなニュアンスの違いとして、レイアウト要素をどの程度定義しているかについては違いがありました。共通しているのは、線を多用してなるべく抽象化するということ、加えて視覚表現の領域までは定義しないということでした。

※以下アンケート結果より印象的なものを抜粋

• ヒアリングで聞いたことをWebページで表現するとどうなる？と言う提案図
• クライアントとの意識合わせを行うために必要なドキュメントの一つ（画面要素、機能について）
• 画面内の要素群を定義し、クライアント、ビジュアルデザイナー、エンジニア等と確認を進めるためのドキュメント、レイアウトを規定する場合とそうでない場合がある
• サイトの「なんとなくな形」を共有するもの
• 1. 画面要素の整理：大きさ、場所（グーテンベルグダイヤグラム）
  2. 画面遷移の整理、チェック：ペーパープロトタイプとして。画面別の整理チェック。ナビゲーションのチェック
  3. 以上の共有、コミュニケーションツール
• 要素定義時のサイトの設計書
  開発時の原稿
  デザイナーへのレイアウト指示書
• 画面単位での設計図
  「⁠含む⁠」⁠：要素、配置
  「⁠含まない⁠」⁠：視覚表現
  他のものはケースバイケースで
• Webサイトのゾーニングを決めるもの
  デザインの土台となるもの
  要素を確定するもの（ほぼ）
  デザイン前にサイトの構造を共有するもの
• ページ（コンテンツ）に必要な項目、要素と、重要度などを視覚化するもの。それを共有するもの。
  大まかなレイアウトを検討するもの。
• 配置すべき情報を、可能なかぎり抽象化したもの。
  その、表現方法においての呼び名。
  （⁠目的から呼ぶときのストラクチャ、と場合によっては同じ意味となる）

ワイヤーフレームにデザイナーが引っ張られてしまった経験は？

さて、皆のワイヤーフレームの定義について確認した後は、本題の「ワイヤーフレームにデザイナーが引っ張られてしまった経験」となるわけですが、下記のような現場ならではという経験談がありました。

• リンクの時、左にブレットがあると、そのままデザインに取り込まる
• 画像と文字の比率がワイヤーフレームのまま
• 細かく作ってしまったワイヤーフレームのエリア別の優先度強弱の色がそのままビジュアル的な濃淡になってしまった
• 色がついた線は、ワイヤーフレームに慣れていない人はそのままの色でビジュアルに反映
• 比率もレイアウトもワイヤーフレームと同じになってしまった
• ワイヤーフレーム通りに作って欲しかったのに作られなかった
• 一案目のデザインはワイヤーフレームベースで、ワイヤーフレームを崩したデザインをもう一案にすることがある

まとめてみると、ワイヤーフレームに書かれていることが要素の種類を示す指示記号なのか表現の指示なのかの判別がつきにくいケースで多発しているようでした。また、伝える側としてのディレクター側の苦労と受け取り側のデザイナーの苦労についてもそれぞれ議論が行われ、うまくいっているケースについてはどんな時かなどが続いて語られました。

デザイナーが引っ張られないワイヤーフレームを作るにはどんな工夫が考えられるか？

ワイヤーフレームにまつわる制作サイドの問題を一通りリストアップしたところで、どんな風にこれらの問題を解決して行けばいいのかについて続いて話し合いました。様々な意見が出ましたが、「⁠書き方」「⁠方針」「⁠ワークフロー」「⁠コミュニケーション」の4つに分類してみます。

書き方の改善

ワイヤーフレームの書き方を改善することでよりよいコミュニケーションを実現しているという切り口での分類は下記のような意見がありました。

• まずは字コンテを書く
  • 見出しは黒丸など、wiki記号で似せて作る
  • 広告系はワイヤーフレームなしのほうが喜ばれることがある
  • エディトリアルはラフありのほうが喜ばれる
• H1とかの識別記号をしっかり書く
  • 色分けもしっかり意味付けする
• ワイヤーフレームを画像データにする
  • 色分けはグレーを使う

方針の改善

そもそも方針を改めるということもありなのではという点においての下記のような意見もありました。

• ワイヤーフレームすら書かない
• ワイヤーはちょっと足りないくらいにしておき、クリエイティブ魂をゆさぶるようにする
• ハイレベルのワイヤーフレームなのか、ローレベルの詳細ワイヤーフレームなのかはっきりさせる

ワークフローの改善

改善すべきは、ワイヤーフレーム自体ではなく、その使い方だったり生み出され方であるという側面から下記のような意見がありました。

• マークアップからはじめる
  • ワイヤーフレームからビジュアルデザインに行かずマークアップへ行く
• ワイヤーフレームで要件を決めてはいけない
  • インターフェース設計としてのみワイヤーフレームを使う
• ビジネス側から作成するのかUIの専門家が作成するのかは、サイトの構成手順によって異なるかもしれない

ただし、「⁠ワイヤーフレームで要件を決めてはいけない」という案に関しては「場所取りつまりゾーニングをどこで解決するか」という反論がありました。

コミュニケーションの改善

ワイヤーフレーム自体より、それを使ったコミュニケーション手法を改善するとうまくいくであろうという下記のような意見もありました。

• 渡されたワイヤーフレームを最適なワイヤーフレームに書きなおして提出するとよい
  • ただし、ワイヤーフレームを渡す時はすでに要件が決まっているときもあり
• ワイヤーフレーム単体で評価するのではなく、ちゃんとコミュニケーションがあるかどうかが重要である
  • フルFlashサイトではあまりワイヤーフレームを作らない
• IA、D、ADもそれぞれワイヤーフレーム作成に参加し、両方がぶつけ合うのが大事だ
  • ワイヤーフレームは、画面のレイアウトを規定するものではない
  • AD、マークアッパー同士でワイヤーフレームを組む
  • キャンペーン系コンテンツではDとADの関係が逆転することもあり
• レイアウト指示書として確実なものを渡すこと
  • ただし、変わる可能性があるものは伝える

コミュニケーションとしてのワイヤーフレームとドキュメントとしてのワイヤーフレームがある？

ワイヤーフレームと一口に言っても様々な目的があると思います。大きく分けると制作段階でWeb担当者やデザイナーとやりとりをするために使われるワイヤーフレームと、仕様書としてのワイヤーフレームがあるのではという部分に関して意見を聞いてみました。そのあときあがった意見を挙げておきます。

• ワイヤーフレームを成果物（納品物）に入れている？
• ワイヤーフレームは途中で破棄されるので入れていない
• 仕様書と違って最新版に更新はされない
• ワイヤーフレームは仕様書としては扱わない
• 仕様書として入れる場合はワイヤーフレームは実製作中でも更新があればバージョンアップさせていく必要がある
• ワイヤーフレームをブラッシュアップしたものがビジュアルに下りていく事はない
• ワイヤーフレームといっても様々な目的がある
• ビジュアルデザインのための利用
• コンテンツ仕様書としての利用
• インタラクションの検討材料として
• クライアントによって、ドキュメントとして使うかどうか決める
• 建築系で例えると
• 建築の図面はJIS的なもので決まっているがワイヤーフレームにはない
• ビルと建物で情報の粒度は違うかもしれないからワイヤーフレームでも案件によって記載内容は違ってくる
• SIer業界では画面設計図がある
• ただし、レイアウトがいらない点がワイヤーフレームと違う
• 機能単位での記載なのでページ単位ではないことがある

ワイヤーフレームの共通ガイドラインはあったほうがいいと思いますか？

コミュニケーションとしてのワイヤーフレームというのであれば、当事者同士がそれぞれ理解出来るニュアンスであればよいということになりますが、仕様書としてのワイヤーフレームとなった場合、第3者が見ることも想定しなければならないはずです。そうなったときに、ひょっとしたらワイヤーフレームにも共通のガイドラインがあったほうが読む側、作る側双方にとってメリットがあるのかもしれません。そんなことを皆に聞いてみたところ、賛否様々な意見がありました。

以下に印象的だった意見を挙げてみます。

○あるほうがいい

• 現状、ワイヤーフレームは作る人によってばらばらすぎる
• なんらかの決まりが必要ではないか？
• ワイヤーフレームのせいでコミュニケーションが阻害されているとよくない
• ボキャブラリーとしての統一ならあり。リンクの書き方一つにしても決まりがあるとよい
• ワイヤーフレームがコミュニケーションロスの原因になっていることもある

×無い方がいい

• ワイヤーフレームは共通化できない
• ワイヤーフレームっていう言葉の定義はあったほうがいい

×ないほうがいい

• Webの未来を閉ざす可能性がある。ディレクターが引っ張られることもある

○あるほうがいい

• 基準があったほうがいい。案件や会社の方針によってはそれらを無視すればいい

○あったほうがいい

• 目的による粒度が異なっていい
• 案件のタイプに応じて、仕様書による情報の粒度が異なるケースもある

○あったほうがいい

• ワイヤーフレーム作成で見積りが出せるくらいまであったほうがいい

？あってもなくてもいい

• ワイヤーフレームの作り手にはメリットはあるのでは？
• ワイヤーフレームの基準はデザイナーに分かりづらいかもしれない
• ワイヤーフレームのガイドラインをデザイナーに求めるのは酷。ガイドラインが読めない可能性がある

？どうだろう？

• システムが絡む要件があったときにワイヤーフレームの基準があると便利

○あってもいい？

• ワイヤーフレームはアジャイル性がメリット
• ワイヤーフレームによるコミュニケーションの仕方は案件サイズによる

SINAPにて研究会が行われた後には、会場を変えて参加者による懇親会も行われました。

そちらの会場でも、本会に引き続いてのそれぞれの意見交換や、次回以降の議題の検討などが行われました。

全体の共通の思いとして、やはり今回一度きりで「ワイヤーフレーム」についてのそれぞれの意見を語り尽くすにはあまりに時間が少なかったのと、また、これっきりで議論を終えたくないという意見が沢山上がっていたように思います。懇親会の最後には全員が、今後も第二回、第三回…と引き続き議題を変えながら「ワイヤーフレームコミュニケーション研究会」を開催して行こうという思いをひとつに、第一回目の「ワイヤーフレームコミュニケーション研究会」は終了となりました。

今回のこの「ワイヤーフレームコミュニケーション研究会」の発案者であり会をモデレートして下さった原さん、またご参加者の皆さん、おつかれさまでした！

議事録など下記のサイトにて公開されていますので、併せてご確認ください。

参考サイト一覧

• ワイヤーフレームコミュニケーション研究会
• ワイヤーフレームコミュニケーション研究会 : ATND