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

久しぶりに、ちょっとTipsめいたことでも。

デザインをクライアントへ提出する際、ちょっとしたことで後の進行がスムーズになる場合がある。お守り程度の効能かもしれないけれど、今回はその話を。

「趣意書」というのがある。要はコンセプトについて書いたものだ。大きな案件とかコンペ案件だと、デザインについて趣意書の提出が求められることがある。で、「趣意書」なんていうキチンとしたドキュメントでなくていいので、求められなくてもデザインを出す場合は「何を考えてデザインしたか？」を一言コメントでも添えて出すといい。特に2案以上出す場合、それぞれどこに注目して欲しいかがクライアントに伝わりやすい。

また、クライアントの担当者が上位承認者などに見せることがあるなら、往々にして上位承認者はそれまでの過程など知らないので、そうした簡単な説明があると「なぜそんなデザインなのか？」が理解しやすくなる。提出した担当者も「どうしてこういうデザインにしたのか？」と上位承認者などに尋ねられて、その場で四苦八苦して説明をでっち上げなくてすむ。

できればデザインした本人に簡単なコメントをもらい、必要ならディレクターがそれを補足して書くのがいいのだけれど、もしデザインした本人からコメントがもらえない場合は、ディレクターが（後に災いをもたらさない程度に）作文してしまってもいいかもしれない。まあ、まったくの嘘八百だとマズいだろうけれど。

「見りゃ解んじゃん！」と思うかもしれないけれど、ちょっと試してみて欲しい。もし有効な結果が出れば、教えてください。私も試してみるので。

前の記事の最後で書いたように、「Google Friend Connect」を取っ掛かりにして、日本におけるソーシャル・アクティビティ系のサイトやサービス全般について考えてみる。

と思って考え出したものの、話が錯綜してまとまらない上に、「だからなに？」的な印象がいつにも増して酷いので、曲折は省いて箇条書きにする。

1：日本国内において「Google Friend Connect」の登場で最もインパクトがあるのは「ソーシャル・アクティビティ系のサイトやサービスの構築」に低コストな選択肢が増えるかもしれないことくらい。実際のリリースを待たないとなんともだが。
　→Googleカレンダーみたいに自分のページへ複数の「Google Friend Connect」で参加しているコミュニティをマージして表示させられるなら、あるいはユーザ側が色々な「Google Friend Connect」のコミュニティにほいほい参加してくれるかもしれない。ブックマークするくらいの感覚で。

2：ソーシャル・アクティビティ系のサイトやサービスに対する日本の市場はとても小規模で、すでに飽和してるんじゃないか？
　→よほど驚天動地のサービスでもない限り、PC、モバイル共に高成長は見込めない。また、そうしたものが出てきても既存ユーザからの乗り換えであって、その意味では携帯電話市場とすでに似たような状態なのでは。

3：ソーシャル・アクティビティ系のサイトやサービス同士で情報を受け渡しするトレンドが日本でも伸びると、上記2と考え合わせて「どのサイトと情報を受け渡し、どのサイトと受け渡さないか」がビジネスとしての主題点になるんじゃないか。

4：アメリカでソーシャル・アクティビティ系のサイトやサービスの需要を生み出しているのは、リアリティ番組の人気や、その人気の原動力が影響しているのかも。

はしょると以上。あと、これだけだと何なので、断片的に考えていることを他にも列記してみる。

・中高生のネット利用がモバイル中心なのは「1日の大半をPCの前以外で過ごす」「かといってノートPCとLANカードを持ち歩くのは無理」ってだけなんじゃないのか。

・ビジネスとしてのサイトやサービスの成功には、凄いクオリティや凄いアイデアよりも、営業力の方が重要だと思う。凄いクオリティや凄いアイデアがあっても、営業力がないと偶然以外で大きな成功は見込みにくい。

・営業が「戦略的に」赤字っぽくなりそうな案件を持ってきたり、ある案件に対して「戦略的な値引き」を持ちかけてきたとき、自分の人事評価が最重要なら交渉の余地なく断った方がいい。そうした案件で人事評価が上がるのは営業さんだけ。

・子供とネットにまつわる問題は、今の子供が親の世代になる頃にはあらかた解決するだろうから、あんまり大規模な対応は必要ないと思う。

・国際競争力についてどうこう言うのは、だいたいの人が日本語以外に少なくとももう1カ国語くらいを読み書きできるようになってから。

・リキッドレイアウトにしたがるのはいいが、「ブラウザの幅を変えたらレイアウトが崩れた」ってクライアントに言われたら、あなたが全て説明＆説得するんだろうね？

・日本全国の旅館を転々としつつ、その旅館のサイトを作り直したり、立ち上げたりする仕事がしたい。すでにちゃんとしている旅館を除いても、数年は転々としていられるだろう。

・「Google 急上昇ワード」は「今、何が話題になっていて、何が流行っているのか、また世の 中の人々が何を知りたがっているのか、そんな情報を瞬時に垣間見ることができます」ということだそうだ。もし本当なら、テレビはまだまだ安泰ということなんじゃないか。というのは、前から思っていた。でないと、あの仕事で芸能人ネタが他の見出しに比べてああもクリックされる理由が判らない。芸能人ネタでも恋愛結婚なら、なおよかった。

・大多数のweb業界人にとって、FaceBookとか海外の大手SNSにそこまで熱い視線を注ぐ価値はない。だって、日本でそうしたサイトのユーザが無視できないくらい増える可能性ってまずないじゃん。軽く眺めるくらいで充分だ。

とまあ、断片的なことを書けばキリがないのでこの辺で。

mixiにTwitter、その他にも「ソーシャル・アクティビティ」を謳ったwebサービスは既にうんざりするほど存在している（筆者など、どれか一つでもう充分だ）。しかしGoogleからすれば、それでもまだ我々が「充分にソーシャル」ではないということなのかもしれない。

先日、Googleは「Google Friend Connect」を発表した。このサービスを使えばプログラミングの知識がなくても、誰でも簡単にユーザー登録、招待、メンバー ギャラリー、メッセージ投稿、レビューなどソーシャル・ネットワークの機能を自分のサイトへ実装できるという。

これが何をもたらすか、想像するのは簡単だ。あなたはある日、（愛犬と愛娘の写真がデカデカと貼られた）会社の上司のサイトからソーシャル・ネットワークへ参加するよう求められる。帰宅してみれば（愛犬と愛娘の写真がデカデカと貼られた）両親のサイトに設けられたソーシャル・ネットワークへ参加するよう求める、留守番電話のメッセージを聞かされることになる（彼らはメールが苦手なのだ）。マウンテン・ ビュー（注：Google本社があるカリフォルニア州の地名）がもたらしたのは、つまりそういうことだ。

おまけにこのサービスは、参加者がすでに利用している他のソーシャル・アクティビティ系サイトでの情報も表示できるらしい。こうした取り組み自体はすでに方々で行われているが、複数の友人や知人のグループがそれぞれ異なるソーシャル・アクティビティ系サイトに入っている場合にどうするか？という問題をある程度は解消してくれる。

しかしそれは、新しい厄介事の種にもなりかねない。たとえば「Google Friend Connect」ではFacebookなどから自分のプロフィールやフレンドリストといった情報を持ってくることが出来る。もし、あなたがFacebookユーザーで、知り合いから「Google Friend Connect」のネットワークに参加を求められた場合、まず最初にその知り合いがFacebookにアカウントを持っているかどうか調べて、持っているなら自分のフレンドリストに含まれているかチェックするべきだろう。そして、リストに含まれていなければ、「必ず」フレンド申請をしなければならない。さもなければ「Google Friend Connect」に追加したFacebookのフレンドリストへ、誘ってくれた本人が入っていないという気まずい事態になりかねない。

もちろん、このケースでは誘ってくれた本人に事情が筒抜けになる。だが「誘ってくれた本人の知り合いで、なおかつあなたの知り合いではない人」が同じネットワーク内であなたのフレンドリストを見た場合、誘ってくれた本人にバツの悪い思いをさせる事態は避けられる。

オーケー。確かにこれは読む方にとっても書く方にとっても、頭が痛くなるほど説明するには込み入った状況だ。上のケースについても、ちゃんと説明できているかさえ自信がない。だが、多くの人々がソーシャル・アクティビティ系のサイトやサービスを使うようになればなるほど、こういった事態やもっと込み入った事態をも想定しなければならなくなる。

こうした新たな脅威に対して、我々は今や「ネチケット」という大昔に廃れた言葉をガレージから引っ張り出してくる必要があるのかもしれない。ただし今回は「べからず集」としてのネチケットではなく、「気が乗らない相手からのGoogle Friend Connect参加要請を断るときのマナー」など、より実践的なマナー集として、だ（お望みならネチケット2.0と呼んでもいい。どこかのベンチャーキャピタルが投資してくれるかもしれない）。


えっと、海外ニュースサイトの翻訳記事っぽく書いてみたんだけれど、どうだろうか。それらしく書けているだろうか。次は「Google Friend Connect」を取っ掛かりにして、日本におけるソーシャル・アクティビティ系のサイトやサービス全般について、もう少しまじめに考えてみたい。

日頃から自分の実力も省みず「スカしたこと言ってんちゃうぞ！」というようなことを非常にオブラートに包まれた言い方で書いている当ブログですが、「広い意味で」似たような方向性で書かれ、全面的にではないものの、共感できる記事を読んだ。

MarkupDancing
ウェブ業界はどこを向いているのか・その1
ウェブ業界はどこを向いているのか・その2
ウェブ業界はどこを向いているのか・その3

興味がある人は読んでください。けっこう長めの記事だし、「おもてなし」とか仕事でもなきゃする気はないので、特に要約はしない。ウチは旅館じゃねえ。まあ、気が利かないだけとも言う。

ともあれ、そういうわけで以下に述べる話には上記記事からの引用がアチコチ出てくるけど「話の取っ掛かり」として引っ張ってきているだけで、必ずしも上記記事中の論旨などとは関係しない場合も多いので、その点は踏まえて欲しい。

自分にとっては実に頭と耳の痛い記事で、特に「その2」は自分がずっと悩んでいる部分でもある。ちなみに1は共感できる部分。3は「そういうものか」という部分。

で、だ。見苦しい言い訳を交えつつ、つらつらと考えたことなど。

いったいどれほどのウェブ制作プロダクションや開発会社が、ウェブサイトを顧客企業の事業計画の中に正しく位置づけて戦略的に設計できたり、顧客のヒューマンリソースを有効にディレクションしたり、サイト運営の経験を蓄積しているというのでしょうか

という点なのだが、確かにこれは難しい。超むずかしいな。だいたいそんなもん、他の業界でも簡単にほいほいお金取れるだけの水準で出来るわけでもないだろう。というくらいの難易度であるが、それをやったとしてクライアントが相応の対価を払ってくれるかというと、そうでもない。中小企業とかだと、払う気があっても払えない、というクライアントもいる。相応の対価がもらえないのに、そういう人を雇っておくためにはそれなりの環境と報酬を用意する必要がある。他業種以上にそうした人材は希少なのだから、他業種以上の好条件でないと需給的に無理がある。そして、それは資本体力のない中小web制作会社では無理な話である。というか、そんなことのできる人材はそれなりの制作会社などに行ってしまうだろう。もっとも、この相応の対価という点では「卵が先か鶏が先か」で、クライアントがその価値を認めるのが先なのか、制作会社がクライアントにその価値を認めるよう実績を出して見せるのが先なのか（これについては後述する）。また、責任の問題もある。制作会社がその際との戦略や事業そのものに深く関わるのであれば、それなりに責任も発生する。クライアントはその責任を制作会社と案分する気はあるのか？制作会社は案分された責任を引き受けられるのか？そう考えると、制作会社がそのリスクを負うのは難しいだろう。

自社でそうした能力のある人を育てる必要はあるだろう。しかし、

多くのウェブ制作プロダクションや受託開発会社に、ウェブサイトの戦略的な位置づけや、長期的な運用体制と手順を提案する力が根本的に欠けていると思える理由は、彼ら自身が自社でウェブサイトを業務として適切に運用し成功させた試しがなく、それゆえウェブサイトを「作って公開」することしかできないからだと言えます。

というのはアリなのだが難しいかもしれない。ちょっとつまづけば終わりという足元ヨロヨロな制作会社だと受託をやりつつ自社で事業を起こしてみる余裕がない、というのが言い訳ではなくわりと事実としてあるケースも多い。そんなのは座して死を待てというのも正論ではありつつ、当事者ならば「はいそうですか」と素直には言えないこともあるだろう。じゃあどうするか。どうにもしようがないのである。良し悪しで言えば「悪し」なのだが、私程度では具体的にどうすればいいか思いつけない部分だ。まあ、私にどうこう出来そうな話なら、とうにどうにかなっている。

で、上記記事ではweb制作業者が「立ち上げ」を主としていて「運用」がまともにできない原因を内的要因と外的要因から述べている。ここで言う運用とは、たんなるページの更新とかコンテンツの更新とか、そういう話ではないだろう。で、その理由というのは概ね賛同できるのだけれど、制作側から見ると、さらに4つの要因がある。

・資金的な問題
→前に書いたと思うのだけれど、運用業務はある程度の期間、安定した売り上げが見込める。ただし資本体力のない、それこそ「日銭を稼ぐ」ような会社が多いこの業界では、いきおい短期的な実入りが多い立ち上げ業務に人材が多く割かれるのは、それはそれで不自然な流れでもない。いいか悪いかは別として。

・発注がない
→ナショナルクライアント級とまではいかないまでも、大きな企業でなければサイト立ち上げで予算が一旦尽きてしまうケースも多い。その場合、どのような意味であれ「運用業務」は自社内で賄うしかない。ということで、発注されないケースも多いのだと思う。まあ、運用の必要性を最初から認識しているクライアント側担当者が少ないというのもあるだろうけど。あと、ディレクターなんかがちょっと気の利く人で、それこそ「長期的な運用体制と手順を提案する力」があると、リリース後の普通のサイト更新業務はクライアント側で対応可能で、いわゆる「手離れ」を起こしたりする。

・情報がない
→効果的な提案をするにはアクセス状況などなど様々なデータがないと難しい。そのためにはクライアント側でそのデータを把握していて、なおかつそれを制作側に開示してもらわなければならない。使い物になるデータをちゃんと持っているクライアントは少し前まで僅かだったし、今でも必ずどこにでもあるというわけではない。おまけに、それを開示してもいいとクライアントが思うだけの関係が双方に築けていないと無理だろう。これは「守秘義務契約書」を一枚交わせば済んだりもするけど。

・余裕がない
→たとえ制作会社側の担当者にやる気があったとしても、発注された以上の運用業務に踏み込んで効果的な提案をするだけの余裕がない場合も多い。

この3番目は特に企業としてweb制作をやっていると、いかんともしがたいジレンマを生む。さきほど「後述する」と書いた事柄もここに関係する。
上記記事で

制作会社や開発会社は発注側の利益になるような行動を勝手にとったりはしない

ということが書いてある。これはまさにそのとおりで、クライアントはしばしばそれを求めるものの、制作側としてはそんな時間的・人的な余裕はない。だいたいコチラが気を利かしてそうした行動をとってしまえば「そういうのは普通のサービス範囲内としてやってくれるものだ」と認識されかねないし、もっと酷いクライアントなら「勝手にやってくれてラッキー」くらいにしか思わないだろう。「そのおかげでコレコレの成果が出ましたので、成功報酬を出しましょう」と申し出てくれるクライアントなんて、先にそういう条件で契約を交わしていたのでもない限り、存在しないのだ。
もちろん、手がけたサイトは成功して欲しい。これも前にも書いた気がするが、それでクライアントの収益が10倍化したとしても、こちらの収益は10倍化しないのだ。若干増えたとしても、それで収支として見合うかといえば必ずしもそうとは言えない。

上に引用した文章の少し後で

社員個人がそのようなサービスを勝手に提供しているなら、会社の業務工数を勝手に非生産業務へ振り分けているのですから、その社員は労務規約違反を犯していると言えます。

という記述がある。労務規約違反とまでは考えてなかったが、つまりはそういうことで、1円にもならないサービスをクライアントへ「勝手に」提供している場合、それは会社からすれば損失をもたらす行動だろう。結果的にそれが何かいいことへつながったとしても、それまでは損失をもたらしているだけだ。（この点、フリーランスはもっと融通が利く。いい面悪い面あるけど）

とはいえ、それではいつまでたってもクライアントにこちらからの積極的な提案や踏み込んだ立案を体験し、評価してもらうことが出来ない。というわけで卵が先か鶏が先かなのだけれど、考えてみればそれはもうコンサルの領域であって、基本的に制作での領域ではないよなあ。まあ、これは上記記事でも

業務請負契約は奴隷契約でもコンサルタント契約でもありません。制作会社の方から何かを提案してもらいたければそのように契約すべきです。

とあるように、要は「どういう契約か？」に集約する話ではある。

とまあ、ことほど左様に書けば書くほど混迷してきた感があるけれど、結局まあ、アレだ。みんなその期その期を乗り切るのに精一杯で、それ以上の取り組みはいろんな意味で簡単じゃないね、ということで。

今日はGW明けなので2本立て。

ウェブサービスを作るときはBlank Slateを工夫しよう


という記事を読んだ。いいかげん何年かweb業界で仕事をしていれば「へえ！そうなんだ！？知らなかったよ。タメになるなあ!!」というほどの話ではないのだけれど。上記記事によると

Blank Slateとは「まっさらの状態」、転じて「利用開始直後の画面」でしょうか。会員登録してさぁ、使うぞ、というときの画面をどうデザインするか、というお話です。
ここがうまくデザインされていないと「む？で、ここで何やればいいんかいな？」となってしまい、ユーザーは逃げてしまいます。初めて使うユーザーにはある程度「最初にこれをやって慣れてちょうだいね」というメッセージをデザインする必要があります。

ユーザ登録が必要なサービスにおいて、登録したてのユーザが適切にサービスを享受できるようにする工夫はもちろん必要だ。それは上記記事のようにちょっとした工夫で解決できる場合もある。

ただ、その前にやっておく、検討しておくべきこと。

・登録したてのユーザが何をしたらいいか迷う場合、登録前の段階でそれがどんなサービスか、ユーザにちゃんと伝えられていない（理解してもらえていない）可能性があります。

まあ、可能性として。ちゃんと理解してもらえていても、上記記事のようなユーザに対するフォローはしておいて損じゃないし。

以上。それだけの話。

ユーザー参加型のサービスでも運営者によるデータベース提供は効果的

というブログの記事で、「CGMといえど立ち上がり時にデータベースを用意しておくといい」という趣旨の記事を見かけた。確かにこれはそのとおりで、たとえばラーメン屋のクチコミサイトを始めようと思ったとしても（今さらそんなこと思わない方がいいのはともかく）、運営側がラーメン屋のデータベースを用意しないと、ユーザはどこにどんなラーメン屋があるかを書くところからはいｚめなければならず、これではお話にならない。「そこからか？そこから書かないとダメか？」と怒られるだけだ。

で、まあデータベースはどこかから買ってきた方がいいのだけれど、受託案件でそうしたサイトを手がける側に立ってポイントをいくつか。

と、その前に。本当はデータベースというよりは「データベースに流し込む元のデータ」という方が正確なのかも知れないが、煩雑なのでデータベースと呼びます。

・それってお高いんでしょう？
→そう。データの件数や分野によるだろうけど買ってくるのだから、それなりにお金がいる。着手前に必ず、「こっちが買って実費で請求する」か「クライアントが買って提供してくれる」かのいずれかで話を決めておくこと。予算面で難色を示された場合まずはデータベースなしでリリースして、アクティブ率などが伸び悩んだ場合にあらためて提案すればどうにかなるかもしれない。が、タイミングを誤ると「買いたいけど、本当に予算がない」という状況になってたりするので注意。

・そもそも、どこで売ってんの？
→これが意外と難題。「これこれのデータベースをウチで売ってますよー」なんて声高に宣伝していることはあまりないだろうし、そもそもデータベースが販売されているものかどうか、不明なケースもある。たとえば「金は払うからサイトへ載せる用に、各メーカーから出ている釣具のデータベース買ってきて」とか言われたら、私は立ち往生する。クライアントが提供できず、コチラでも調達先のメドが立たないデータベースを求められたら、断るか調達先開拓費を請求してみた方がいい。

・それはデータベースか？
ちゃんと、いわゆる「データベース」に組み込めるのならともかく、そうじゃないものが「データベース」呼ばわりされていることも。データベースはクライアント支給と聞いていたのに、フタを開けたらカタログのデジタル原稿でした！なんてこともなくはない。QuarkXPressからCSVにデータを延々とコピペするハメに…というのは実際にあった。泣いた。

・その話は本当か？
→CGMではないのだけれど、とある案件でクライアントが色々と遊びにいく施設のデータベースを調達してきた。公式サイトへのリンクも含まれていたのでリンクチェックをしていたところ、ある時点でとある施設の営業時間が変わっていることに気付いた。背筋に寒いものが走るのを感じつつ他のも改めてチェックすると、料金が変わっていたり公式サイトのURLが変わっていたり（0秒リダイレクトされるので気付いてなかった）と、違っている点がちらほら。結局すべてのデータをチェックしなおすことになった。件数が多くてスケジュール的にも辛かった。内容が変わらないデータベースもあるだろうが、変わるものもある。たとえ有料で買ったものだとしても。

・変形合体できるのか？
→これも別の案件での話。とあるサイトで既存のデータベースに新たな情報を付加するということで、クライアントが元のデータベースを買ったのとは違うところから新規のデータベースを買ってきた。が、手元に届いてみると元のデータベースとは構成がだいぶん違って、簡単に組み込めない（と、システム会社に言われた）。泣いた（クライアントが）。複数の調達先から買ってきたデータベースを扱うときは、変形合体がどれくらい簡単か、大変かでずいぶん違ってくる。というか、そういう事態が起こりうる。事前に避けるのは難しいけど。


というわけで、「データベースを買って導入しよう！」というシンプルなお話の背後には、色々と注意すべき点があるわけです。