泥臭いWEBの底から～WEBディレクター覚書～

webサイトの完成までには数々の難所がある。なかでも厄介なものの一つがデザインだ。デザインというのは特に専門的な知識がないクライアントでも意見を言いやすい（ような気になる）し、そもそも好き嫌いがある。普通の人はソースコードに好き嫌いなんかない。

というわけでデザイン提出は難しい局面だ。流れとしては「デザイナー→webディレクター→クライアント」という順でカンプが渡っていく。
カンプが上がってきたとき、webディレクターがデザイナーにそれを差し戻す理由は、大きく分けて二つ。
・ワイアフレームにあった要素が抜けてる、誤字脱字がある
・とてもじゃないが出せるシロモノじゃない
最初の理由はミスによるものなので、戻すことに問題はないと思う。ただ、二つ目はちょっと悩ましい。

これは新米のデザイナーや、初めて使う外注で発生することがある。手を抜いていることが明確なら、毅然として戻せばいい。ただ、本人が一生懸命にやってそれなら、戻してもどうにもならない。可能なら人を代えるのが一番だろうけれど、「自社内の新米」の場合はそれも気まずい。外注でも気まずい。おまけに、本当に代えてくれるか不確か。「事前にその制作会社のサンプルを見ればいいじゃないの？」という意見はもっともだけれど、サンプルに出ているデザインをしたデザイナーと同じクオリティの人が担当してくれるかどうかは神のみぞ知る、だ。指名する手もあるけれど、頼み方を間違えると「ウチのクオリティを信用できないとでも？」といったことになりかねない。

というわけで、クオリティが低くてどうにもならない場合は行き止まりに突き当たる可能性が高いのだけれど、わりといかんともしがたい。せいぜい
「全然ダメだ」というコメントと共に差し戻してみるくらい。

すでにあるサイトのほかのページとテイストがあまりに違う、という場合もある。これも差し戻す必要があるけれど、これはディレクターがちゃんとその点について注意喚起をしなかったのも問題ではある。

他に、クオリティとして一目でダメだと解る程度ではないけれど、ディレクターが気に入らない、という場合もある。ディレクターによってはこれをクライアントへ出す前に出し戻ししてしまう。
これはいかがなものかと思う。最終的にはクライアントが気に入ればいいので、客観的な問題がない限り、そのページに対してディレクターの好みを反映するのは筋が違う。もちろん、それが自社運営サイトなら別だけれど、それでもディレクターが自分の好みで云々するのはいただけない。個人サイトじゃないんだし、自分の意のままにする必要はない。そのデザインを自分で気に入らなくても、ユーザが気に入ればいいじゃないか。「気に入る、気に入らない」を判断に含めてもいいのはデザイナーとアートディレクター（いれば、だけど）、あと（受託案件なら）クライアントだけだろう。本当はクライアントも担当者の好き嫌いでは判断して欲しくないけれど。

でまあディレクターをしていると、時として「自分の好き嫌い」を判断に含めてしまうことがある。最近、自分では大分減ったけれど、ポイントは以下の二つだけ。

・客観的に正しくないといえるか。
・こうした方が良い、という説得力のある修正指示が出せるか。

客観的に何が問題か言えないのなら、それは個人の好みだ。既存のデザインに対して「こうした方が良い」という指摘に説得力がないなら、それも個人の好みである可能性が高い（デザイナーが意固地になっている可能性もないとはいえない。そういう場合はさらに別の人の意見を聞いてみるのもいい）。

たとえば前者なら「文字が背景に埋もれて読みづらい」、後者なら「ボタンのデザインはある程度の統一性があったほうが、画面内でどれがボタンか理解してもらいやすい」など。

付け加えるなら
・クライアントや上位承認者の修正指示を減らせる見込みがあるか。
というのもある。

ともあれ、最初の2点を心がけるだけで減る修正もあるはずだ。確かに、ディレクターの好き嫌いで修正を入れることがデザインのクオリティを上げたり、そのディレクターの手がけたサイトの評価向上につながる場合もあるだろう。ただ、そういうことはデザイナーのことを第一に配慮した上でやるべきことだ。

それでなくてもデザインに掛けられる時間は短く、クライアントや上位承認者からの差し戻しで、イヤというほど修正なんて発生するんだし。

前回の記事で、自分が疑っていたのは

「直感的であること」ではなく、往々にして「直感的であるとされているもの」の方だった

と書いた。「直感的であるとされているもの」には、さらに疑わしい点がある。

多様なのだ。「何が直感的か」は人によって異なるし、テストや実験によって最大公約数を導いたとしても、それをどう具体化するかは非常に多用だ。

そもそもインターフェースとは、体系内（一つのサイトや製品）で考え方に一貫性を持っていた方が望ましい。その点では言語に似ている。英語は英語という体系内においてそれなりに一貫性を持っているし、日本語だって同様だ。言語は「文法」と「語彙」というインターフェースを持っているといえるかもしれない。

この言語のインターフェースは基づいている考え方の体系にそこそこ一貫性があるから、ある言語が分かれば、（その言語による）初めて見る文章でも理解できるんじゃないだろうか。翻訳の文章が読みづらいというケースも、元の文章が「違う考え方の体系」に基づいたインターフェースで構成されているからかもしれない。
さらに言えば、同じ事柄を言語で表現するのでも、考え方の体系ごとに違った表現となるだろう。

話を戻すと、私は「何が直感的か？」という答えを具体的なサイトなり製品なりに落としこむとき、それは設計者の考え方によって言語以上に多様化するんじゃないか、という疑いを持っている。「同じ事柄を表現するのでも、考え方の体系ごとに違った表現となるだろう」というわけだ。

これを推し進めると、同じ「直感的であること」を目指していても、製品やサイトごとに大きく違った実装がなされることになる。想像して欲しい。「直感的に運転できること」を目指した結果、車種やメーカーごとに自動車のインターフェースが全く違ったら、と。免許を持っていればどんな時代やメーカの自動車でもさして戸惑わずに基本的な運転操作ができるのは、なにも自動車のインターフェースがこの上なく直感的に作られているからではない。標準化された規格で統一されているからだ。

また、「直感的である」とされているものの語られ方にも納得できない点がある。そうしたインターフェースは「子供や全くの初心者」でもすぐ扱えるようになったということを、まるで「既存のありがちなインターフェースより優れている点」であるかのように書く。しかし、実際にそうしたインターフェースを使うのは、その製品なりサイトなりを使うにあたって「経験と学習によって何らかの先入観を持っている」人間がほとんどだ。だから、「子供や全くの初心者」に直感的だからといって、メインユーザである「経験と学習によって何らかの先入観を持っている」人間にとっても直感的なインターフェースである保障にはならない。「既存のありがちなインターフェースより優れている」とは言えないのだ。

もちろん、ここまでの話は分かりやすいように極端な書き方をしている。実際の現場で、たいていのインターフェース設計者は「経験と学習をしている」ことを踏まえたうえでの分かりやすさを目指しているはずだ。意識しているにせよ、していないにせよ。だから、自分の中でなにか心配や気がかりがあるわけではない。ただただ疑わしいのだ。

それとiPhoneやiPod touchのインターフェースがダメだ、と言うつもりもない。前の記事の冒頭にも書いたけれど、使い方を理解してしまえば、あれは非常に魅力的だ。

もし私がサイトのインターフェースをiPhoneやiPod touchに代表される類の「直感的な」ものにすることがあるなら、それはそうしたインターフェースが充分に普及したときくらいだろう。それともちろん、クライアントがそれを望んだとき。

昨日今日と、実際のディレクションには何ら役立たないことを長々と書いてしまった。普段から「お役立ちTips」みたいなものは書かない方だけれど、今回は特に実際的でない度合いが大きい。「で、なに？」とか言われたらそれまでの話だもんなあ。まあ、いいんだけど。いいんだけど、何だろう、この気恥ずかしさは。

前に「マジョリティユーザ視点のweb標準化」という記事で

マジョリティユーザの視点でweb標準化すべきなのは、技術的な事柄でもなければユーザビリティなどで「最適解を工夫すること」でもなく、「ほどほどの落しどころでいいから、とにかく同ジャンルのサイトは同じような構造、ページ内要素にすること」だ。

と書いたように、webサイトのインターフェースについてはなるべく標準化されていたほうがいいと考えている。ところが、こうしたインターフェースを超えるものとして、「直感的なインターフェース」というのがしばしば（たいていは賞賛と共に）取り上げられる。だが、自分はこうした「直感的なインターフェース」というものをいまいち評価できない。それどころかユーザビリティという視点から疑いすら抱いている。

「直感的なインターフェース」というのは、（なんの説明や補足、言葉がなくても）何が起こるか理解できる、すぐに使いこなせるということだろう。具体例として、「直感的なユーザインターフェイスって何？」という記事では「iPhoneやiPod touchの「左右に指を滑らせることで画像を切り替えるUI」」というのが取り上げられている。確かにあれはユーザインターフェースとして素晴らしいとは思うが、操作性に優れたものであるかは疑問だ。

たとえば。上記記事では実際のものと、ボタンによるユーザインターフェースだった場合とを図で並べ、前者に軍配を上げている。

『次の画像に移動するには「次」ボタンを押すんだな』という判断が余分に必要になります。

というわけだ。しかし、これは逆なんじゃないだろうか。何の予備知識もなく初めてiPhoneやiPod touchを見たユーザはまず、「あれ？ボタンがない。どうやって操作するの？」というところで戸惑うはずだ。偶然画面に触れて指を動かすと画像がスライドするのでやっと、「ああ、指で左右にスライドさせればいいんだな」と理解する。しかし、また別の機能やアプリを立ち上げると、またボタンも何もない。そこでまた、「今度はどうやって操作するんだ？」と考え込む。慣れるまではこの繰り返しである。これのどこが便利なんだろうか？

プロダクトの分野だけではない。webサイトでも同様である。「直感的な～」とされているサイトにアクセスすると、まず「メニューがない」場合がままある。インターフェースとしてのテキストリンクもない。「どこから操作するの？」である。でたらめに触っていると「偶然に」操作方法がわかる。すべての必要な操作方法を理解するまでは、偶然頼みの試行錯誤を繰り返すことになる。ボタンやテキストリンク、あるいはメニューをちょっと設ければ解消されそうなものなのに。

そもそも、私の「直感的なインターフェース」に対する理解が間違っているのだろうか。その可能性はある。しかし「なにが直感的か？」という部分にこそ、誤解があるんじゃないだろうか。

iPhoneやiPod touchに代表される類のインターフェースというのは、人間がそれを使う時点で「経験によってある程度の学習をしている」という事実を無視している気がする。そりゃあ、子供のように経験による学習が圧倒的に少ない場合は別だが、そうでなければ、たいていの人はなにがしかを学んでいる。「あれ？ボタンがない。どうやって操作するの？」と戸惑うのだって、「こうしたものは操作するボタンやメニューがあるもの」という経験と学習があってこその話だ。そうした先入観を打破したいならともかく、使い勝手を考える上ではその先入観に合わせることが大事なんじゃないだろうか。

ひとたびこうした経験と学習をしている人ならば、「一見するとメニューやボタンといったインターフェースが何もない」デバイスよりも、「メニューやボタンがある」デバイスの方が「直感的に」使いやすい（テレビのリモコンがどんなメーカーのものでも、だいたいは初見ですぐに基本的な操作ができるのも、このためだろう）。そして、こういった人の方が実際のユーザにはずっと多いのだ。

これはサイトにも当てはまる。あるサイトにアクセスしている人がこれまで他に一つ以上のサイトを見ている可能性は、そうじゃない可能性よりはるかに高い。前者の人はサイトにアクセスしたとき、そのサイトのインターフェースをこれまでの経験と学習から理解しようとする。ところがiPhoneやiPod touchに代表される類のインターフェースはそうした認知の流れに従わない。するともう、戸惑うわけだ。

というわけで、自分が疑っていたのは「直感的であること」ではなく、往々にして「直感的であるとされているもの」の方だったことが分かる。こうした「直感的であるとされているもの」には他にも疑わしい点があるのだけれど、それはまた次にでも。

基本的なことだけれど、まとめ。

運用業務も当然タダというわけにはいかないので、それなりにクライアントからお金をいただくことになる。その場合、以下のようなパターンが考えられる。

・月額固定

月々の作業量の多寡によらず、事前に契約した金額が支払われる。金額とその額での対応範囲は四半期ごとや半期ごとの見直しとしておくと、双方にとって運用しやすい。
その運用費で吸収できない作業が発生したら、別途、追加の見積りを出す。テキストの打ち換えや画像の差し替えなど、細かい作業が多い場合に適している。

・作業ごと

運用業務において、新規ページの作成や新規コンテンツの作成が多い場合に適している。ただ、テキストの打ち換えといった細かい作業が請求しづらい。CSSをちょっと変えるだけとか。

・月額半固定

新規のページ作成などが多いものの、作業量が決まっているので実質的に「固定」の金額が支払われる。たとえば、あるサイトで毎月2回、1ページ分の特集記事を更新する場合など。同一コンテンツ内のシリーズで「全○回」など回数がハッキリ決められるなら、前払いという手もある。


以下に、クライアント側・作業者側から見たそれぞれの長所、短所をまとめる。

・月額固定の場合

クライアント（長所）：ちょっとした修正を依頼するさい、あまり費用を気にしなくて済む。事前に予算を組みやすい。
クライアント（短所）：作業が多くても少なくても、費用が変わらないので、月によっては割高に。

作業者（長所）：見積りを立てづらい作業からキチンとお金がもらえる。月々のそのサイトからの収益予測が立てやすい。作業量に関わらず、安定した収益が見込める。
作業者（短所）：細かい作業がバラバラと降って来やすくなる。どこまでを固定の金額で請け負うかの線引きが難しい。

コメント：作業量が少ないと、クライアントにとっては割高に、作業者側からすれば得に感じられるものの、実際には作業量の多い月もあるので、長期的には相殺されることが多いと思う。「制作」というより「更新」が主な運用の場合は双方に便利。

・作業ごとの場合

クライアント（長所）：月ごとの更新が少ない場合に、月額固定より費用が抑えられる。何に幾ら掛かったかを把握しやすい。なに食わぬ顔で細かい作業を頼んでも、請求されない場合がある。ただし、それを期待しているとキッチリ請求されて（あるいは作業側が不服を申し入れて）思わぬ事態に発展することも。
クライアント（短所）：細かい作業で妙に割高な請求になることがある。テキスト打ち換え程度でも、作業側としては100円なんて請求してたら赤字になるため。予算組みも月額固定より幅が出るので難しい。

作業者（長所）：作業ごとにきちんと請求できる。固定費吸収分がないため、「制作」が多い場合、月額固定よりも収入が良い。
作業者（短所）：細かい作業をちゃんと請求しようと思うと面倒。かといって細かい作業をある程度は無償サービスで対応するなら、どこまで無償でやるかを判断するのが難しい。おまけに、いざそうした作業を請求しようと思うと、どうしても割高になるので費用設定の点でも面倒。

コメント：月額固定と違って「今月は多めだけど、先月の作業が少なかったから固定費内で対応してよ」といった話が出てこない。「制作」より「更新」が多い場合は双方にとって煩雑なだけ。

・月額半固定

コメント：目だった長所、短所は特にない。双方にとって費用が予測、把握しやすいくらいか。

こうした特長を踏まえて、「どのような運用作業が中心か」ごとに適した契約を交わすと双方にとってやりやすい。逆に、運用業務を始める前に「どんな作業が中心か？」が読みきれないと、双方にとってやりづらい契約内容になってしまうので注意。特に新規サイトを立ち上げた後、そのまま運用に移行する場合は読みづらい。その場合、どういうタイプにせよ「三ヶ月経った段階で見直し」としておくのが無難。

コンペについて、気になることが書いてあった。

Web担当者Forum
ここが変だよウェブマーケティング第3回　失敗リニューアルをしない！

Web担当者Forumはサイト名からして、クライアント側の担当者を念頭においているはずだろう。だから、上記記事は「リニューアルの際は課題の把握とその解決が大事であって、見た目を変えることが本質ではない」という啓蒙記事なんだと思う。

この記事はコンペの際にデザインを提出しなかったら担当者から「他と違ってなぜ出さないのか？」と連絡があったというエピソードからはじまる。続いて筆者は

一般的にリニューアルコンペの際、多くの制作会社はデザイン案を出す。しかし私は、なぜコンペの段階で具体的なデザイン案をなぜ出せるのか、常々疑問に思っている。現行サイトの課題をきちんと分析せずに、またサイトのコンセプトを検討する前に、なぜデザインだけ先に提案できるのだろうかと。

と述べている。気になったのはここ。もちろん筆者も本当に「なぜコンペの段階で具体的なデザイン案をなぜ出せるのか」皆目見当も付かないわけじゃないだろうし、きじの糸としては枝葉末節なんだろうけど、せっかくなのでこの話を膨らませてみる。

まず、コンペでデザイン案を出す理由として「みんな出すから」というのが挙げられる。コンペティターが出している中で自分たちだけ出さないと「やる気がない」とかなんだとか、他の内容がよくっても、その1点だけで落とされるリスクがある。そもそもコンペの要件に「デザイン案の提出」が盛り込まれていることも珍しくない。

また、デザインというのはwebについてあまり知識のない人にアピールしやすいというのもある。IT系以外の多くの企業で、意思決定をしている（年代の）人は、あまりwebについての知識を持っていないことがザラである。そういう人は「数字」と「デザイン」以外に判断基準を持つことが難しい。判断しようという気があっても、二つの提案でどちらがいいか、知識のない状態で見極めるのは簡単じゃないと思う。（余談に近いけれど、たとえば自分が今の状態で「工場で使う専門的な用途の工作機械」の購入判断を求められたら、近い状況なんじゃないだろうか）

これはまあ、改善されればいいような状況だけれど、そうなってないのが現状なので仕方ない。

あと、「なぜコンペの段階で具体的なデザイン案をなぜ出せるのか」という問いに対しては、コンペのデザイン案は「仮説の具体化」だという回答もある。
対象サイトの現状を「（ブラウザを通して）把握できるだけの情報に基づいて分析し、提案内容を考え、その結果という仮説をデザインに落とし込むとこうなりますよ」ということ（勘違いかもしれないけど、建築関連のコンペで出されるデザイン案もそういうことなんじゃないか。それがそのまま採用されることもあるにせよ）。

ともあれ提出されたデザイン案から、クライアントはコンペティターについて以下の判断材料を得られる。
・デザインのセンスやテイスト
　→会社や対象サイトのこれまでのテイストと近いかor遠いか？意思決定者の好みかor違うか？他のコンペティターに比べてデザインが見劣りするかor優れているか？など。また、クライアントのそうした要素を把握している（しようとしてる）か？も。
たとえば極端な話だけれど、キッズ向けの学習サイトでファッションブランドのサイトみたいなデザイン案を出してきたら、よほどの理由がない限りその提案者はどこか問題がある、とか。

・提案内容を実際の形に落とし込む力量
　→提案書にある現状認識に基づいているかどうか。ちゃんと仮説として挙げられた問題点の解決を意図したデザイン案になっているか？など。
たとえば「デザイン案はいいんだけれど、それ以外で提案されている部分（課題設定や解決策など）が盛り込まれているように見えない」となれば、やはりその提案者にはどこか問題があるだろう。

また、デザイン案の有無から、以下のように判断しようとするクライアントもいるはずだ。

・準備期間内でどの程度の作業ができるか
　→デザイン案がないのは力量や人材の不足で、そこまで手が回らなかったのかもしれない。

コンペ時の提案内容は基本的に仮説なので、そのデザイン案はぶっちゃけ受注後に白紙となる可能性もある。受注後に「アクセスログ分析」や「ユーザビリティテスト」によって新事実が判明するかもしれないわけだし。白紙とまでは行かなくても、さらなる調査で大幅な変更の必要でが出てくることだってある。普通、受注前のコンペでは「ヒューリスティック評価」オンリーだから。

というわけで、ここまでこの記事で書いた諸々を考慮すると、やはり辛くても何でもコンペでは「仮説を具体化してみせる」ためのデザイン案なら誠実さを持って出せるはずだし、出した方がいいと思う。

だって、よっぽどそこへ発注したい理由や、提案内容を気に入ってくれたのでもなければ、わざわざ「デザインないんですけど…」なんて連絡してくれる担当者はまれだから。「デザインが出てない」という理由のみで、他は一切評価せず無言で落とす人も珍しくないし。

けど、実際コンペの（たいていは）短い準備期間でデザイン案までちゃんとデザイナーさんに作ってもらうのって、けっこう大変なんだよなあ。

長々と書いたわりに、ずいぶん普通のことばかりになってしまった。まあ、私の話は「細かく、クドく、長いわりに内容は平凡だ」って言われることあるしな。

何度か書き直してみたけれど、上手くまとまらないのでそのまま。

失敗から学ぶ、反省から学ぶ、という過程でよく「あのとき、ああすれば…」という想いが浮かぶ。この場合「ああすればよかった」ではなく「ああすればどうなってただろう」という意味だ。

で、そうした「ああすれば…」の積み重ねで進行が2、3日は早められたというなら、その「ああする」は「まずまず」だ。2、3日が重要な違いを生むこともあるけれど、それくらいの日数は偶然によって打ち消される可能性が高い。そもそも、運次第でそれぐらいは勝手に伸び縮みする。最初から作業期間が1週間程度の中で2、3日縮められそうだというなら、たいしたものだけれど。

一方で1週間以上は早められたというなら、それはなかなか価値のある「ああする」だ。ただ、3週間も4週間も縮められそうだったというなら、これは反省どころか自分の進行管理になにか重大な問題があるんじゃないかと思う。病気や事故、クライアント側の事情でもない限り。

なんで日数の短縮をあとから反省するさいの指標にするかというと、新規立ち上げ案件のディレクションはまだサイト実績があるわけでもないので（だから新規案件なわけだけど）、進行管理が評価を測る重要なファクターになるからだ。

そして、制作スタッフやクライアント側担当者の能力や自発的ながんばりによらず進行が早まるなら、それはwebディレクターの手腕によるものだと考えられる。例外はあるだろうけれど、「他の誰でもない、webディレクターの手柄」として他に具体的な部分が自分には思い浮かばない。基本的には制作してくれる人がいてこそのwebディレクターだから、なかなかディレクター本人の手柄を割り出すのは難しいのだ。仮にクライアントから高く評価してもらえたとしても、その要因はたいてい制作スタッフのおかげである。

本来的には立ち上げ直後のサイト実績も評価の指標にできるけれど、これはクライアントのネームバリューや、既にクライアントが抱えているユーザの数、プリプロモーションなどの影響が運用後しばらく経ってからに比べて大きいので、対外的にはともかく、自分で自分の評価をする、実力を測るといった場合だとアテにならないといえばアテにならない。

「だからどうした？」と問われれば、「どうもしない」としか言えない話で、だからこそ上手くまとめられていないわけで。ただまあ、乱暴にまとめるなら「他の誰でもない、webディレクターの手柄と言える事柄は少ない」「サイトなりサービスなりの新規立ち上げ案件だったら、進行のスムーズさが評価の指標になる」という2点だろうか。そうだろうか。

【余話】
他にwebディレクター本人の能力を評価する指標として
・コンペでの勝敗
・提案した企画の（クライアント＆ユーザ＆世間的）評価
がある。たぶん。ただ、コンペでの勝敗は営業さんの力量やら大人の事情やらもあるので、指標としては違うのかも。