トップページを考える

Webディレクター解体アドベントカレンダー23日目の記事です。今日はWebサービスの顔、トップページについて考えてみます。

Webサービスを設計するにあたって数あるページの中でも、トップページというのは考えることがトップクラスに多い、設計の難しい領域です。その主な要因は、サービスの成長に合わせて担う役割を変化させる必要があるからだと思います。

たとえばこれはYouTubeサービス開始時から数年前くらいまでのトップページの変遷を2分程度の動画にまとめたものです。

最初はシンプルなログインするためのフォームと検索窓1つというツールっぽいトップページからスタートして、だんだん Featured とか Popular とか Trending とかそういう人気の動画が並ぶメディアっぽいトップページになっていき、最近はパーソナライズが強まってユーザーの興味に沿ったコンテンツがおすすめされるトップページになっています。これは非常に分かりやすい例で、大量のコンテンツや商品を扱うWebサービスの場合、多くがYouTubeと似たような変遷を辿っています。

まずツールの時代です。Webサービスの立ち上げ当初はコンテンツも少なくトップページに掲出するものがあまりない。そういう時はシンプルな投稿ツールに振り切った形にするか、ランディングページやガイドページのようなサービスの紹介に振り切るということをよくやります。

次にメディアの時代です。立ち上げれば多かれ少なかれコンテンツは増えてくるので、コンテンツを紹介する枠が生まれます。その枠が広がってページの大半を占めるようになると、メディアのようなトップページになります。メディア型のトップページは人気やトレンド、ランキングのようなサービス内で人気のコンテンツを紹介することが主な役割です。ただ、ここで問題になってくるのは人気コンテンツの品質と流動性のバランスを取りながら、如何に新規コンテンツを発掘して人気コンテンツに押し上げるかという循環系の設計です。

循環システムの設計

伝統的に古くから取り入れられてきたのが階段型の構造です。例えば最近投稿されたり更新された新規コンテンツを紹介する欄を設け、そこで瞬間的に人気の出てきたコンテンツをトレンドとして取り上げてバズを生む種にし、最終的に人気の出たコンテンツをランキングとか人気コンテンツの欄で大々的に取り上げるというような形。各段階ごとに枠を設けて、徐々に階段を登るように人気コンテンツへの道を用意します。

f:id:nmy:20201222202358p:plain

この構造の課題は評価システムが一本道になっており、そのレールに乗れなかったら脱落してしまい、誰にも注目されないコンテンツが大量に生まれることです。基本的に徐々に脱落していって少数のコンテンツのみが勝ち残る構造になっているので、ほとんどのコンテンツはそのレールから外れてしまいます。これはUGC系サービス共通の課題であり、各社がそれぞれのコンテンツ特性に合わせた工夫をしています。

例えばTikTokは、動画の尺が短く見る側のコンテンツ消費コストが低いことを利用して、人気やパーソナライズされた動画の合間に新規投稿された動画やまだほとんど見られていない動画を挟み込んで、作った動画が誰からも見られないという状況をなるべく防ごうとしています。これは尺が短くコストが低いサービスならではの設計ですが、サービスの特性を活かしたうまいやり方だと思います。

興味を細分化してコンテンツの出る面を増やし、同じ興味を持つ人たちに見てもらう場を作るという方法もよくとられます。よく使われるのはハッシュタグです。サービスのトップページは1つしかないので掲載されるコンテンツには限りがありますが、タグやカテゴリやその他何かの興味に基づいた面を増やすことで、より多くのコンテンツを紹介できるようになります。

あとはパーソナライズですね。ユーザーごとの興味の傾向を分析して、レコメンドの中にその興味に沿った新規コンテンツを混ぜ込みます。ハッシュタグの場合は閲覧者が自らそのタグを選択して能動的に見に行かないといけませんが、パーソナライズされたトップページでは受動的にコンテンツを提示できます。最近のWebサービスのほとんどが、程度の差はあれどトップページに何かしらのパーソナライズ要素を導入しています。トップページという限られた掲載枠を最大限効果的に生かすため、ユーザーの興味に応じて最適なコンテンツを機械が判断して提案しているわけです。

メディア or パーソナライズ

メディア型かパーソナライズか。このバランスを如何にとるのか。この匙加減や移行タイミングの見極めも、トップページを考える上で欠かせないポイントです。

メディア型の良いところは、サービスの色が出やすいのでターゲットユーザーに刺さりやすことです。トップページに掲出された人気コンテンツは、そのサービスの特徴を雄弁に語ってくれます。例えば同じ動画投稿サービスでも、ニコニコ動画とTwitchとTikTokではターゲットとなるユーザー属性がそれぞれ異なりますが、トップページに載っているコンテンツをいくつか見れば自分の好みにあっているかすぐわかると思います。

パーソナライズされていないトップページには、みんなが同じ物を見ているが故の良さがあります。それは共通の話題になれること。ヤフートップに載ったとか、はてブのホットエントリーに入ったとか、Twitterのトレンド1位になったとか、そこに掲載されることが1つのステータスになり、みんなの話題に登りやすくなります。そしてそれがそのサービスを特徴づけ、サービスそのものの顔になっていくわけです。

ただしこうしたメディア色というのは、成長の足枷になることもあります。メディアというのは特定のターゲットユーザーに向けた媒体ならではの色があるものですが、その色が合わない人にはなかなか受け入れられません。特定のターゲットユーザーの間に留まって更に深化を目指すのか、さまざまな属性のより多くの人たちに広く受け入れられるプラットフォーマーを目指す道へと進むのか、その方向に応じてトップページが担う役割が変わってきます。

前者を指向するサービスはよりメディア色を強め、後者を指向するサービスはパーソナライズの道に進みます。TwitterやFacebookなどのSNSはフォローとタイムラインという形式で個人に最適化されたトップページを維持してきました。冒頭にあげたYouTubeのトップページの変遷動画は、まさにメディアを脱却してプラットフォーマーとしてパーソナライズ色を強めてきた歴史を表しています。

コンテンツの循環やサービスの目指す立ち位置によって担う役割を常に変化させていく必要のあるトップページ。他にも考えるべき軸はサービスごとに様々だし、奥が深くて設計のしがいがありますね。トップページを考えるのはいつも楽しいです。

メディアとツールとコミュニティ

Webディレクター解体アドベントカレンダー22日目の記事です。今日はWebサービスを構成する3つの要素、メディアとツールとコミュニティについて書きます。

Webサービスの三要素

Webサービスの企画を考える時、いつも意識している3つの要素があります。だいたいのWebサービスにはこの3つの要素が含まれているので、どの要素にどれくらい力を入れるのかそのバランスを意識しながら全体の設計をします。3つの要素というのは、メディアとツールとコミュニティです。

f:id:nmy:20201219183508p:plain

メディアは通常媒体を指す言葉ですが、ここでは情報に出会う場くらいの意味で使っています。UGCだったらユーザーの投稿したコンテンツに出会う場所で、ECサイトなら商品を探す場所。例えば新着一覧とかランキングとか検索とかです。

ツールは使っていて便利さを感じる道具のような機能を指します。UGCだったら投稿するためのツールだったり、更新を追いかけるための購読ツールもあるでしょう。ECサイトだったらショッピングカートとか、閲覧履歴やウィッシュリストのような便利さを感じるものをツールと呼んでいます。

コミュニティはユーザー同士の交流が発生する場です。コメントとかレビューとか、テキストでユーザーがやりとりするケースもありますし、お気に入りやいいね!のような非言語で好意を伝えるものもあります。

もちろんサービスのドメインによっては、ほぼ1つの要素しかないものもあります。例えばクラウド会計ソフトはツールの要素しかないし、新聞社のサイトはメディアの要素しかない。でもメディアサイトでもコメント欄があるとコミュニティの要素が入ってくるし、閲覧履歴があればツールの要素が入ってくる。

あえてそういう要素を排除してメディア一本で行くというのも判断ですし、ツールかコミュニティの要素を入れて差別化しようというのも一つの判断です。だからメディアとツールとコミュニティの3つの要素を、自分たちのサービスではどういうバランスで行くべきなのかを考える時の枠組みに使っています。

ユーザー体験の流れ

サービスが提供する範囲を定義するときに使える3つの要素ですが、ユーザー体験の流れを考える時にもガイドになってくれます。もちろんユーザー体験の流れはサービスによってそれぞれですが、定番の流れがあります。

メディア > ツール > コミュニティ

トップページに掲載されたランキングや新着欄からコンテンツに出会い、そのコンテンツが気に入ったので購読して、そのコンテンツの提供者とコミュニケーションを取る。わかりやすい例ですが、この流れに沿って体験がデザインされていることが多いです。

どういう経路からユーザーを獲得し(Acquisition)、最初にどんな良い体験をしてもらって(Activation)、何をきっかけに再訪してもらうのか(Retention)。AARRRのモデルに沿って体験のデザインをする時にも、それぞれのポイントをメディアとツールとコミュニティの何が担うのかを意識すると考えやすいんじゃないかと思います。

自分は何タイプ?

3つの要素は面白いことに、人によって得意な分野が結構偏ってるなと感じることがあります。メディアの構築が得意なタイプ。ツールの作り込みが得意なタイプ。コミュニティの設計が得意なタイプ。

昔のはてなで例えると、はてブを作ったなおやんはメディアタイプで、Mackerelを作ったしんじさんがツールタイプ、そして近藤さんはコミュニティタイプでした。僕が勝手にそう感じてただけかもしれないけど、でもきっとそうです。

実際なおやんはよく既存のメディアに対するカウンターのメディアを作るんだという話をしていたし、しんじさんはエンジニア出身のディレクターに多いツールの使い勝手に拘るタイプでした。近藤さんの考えた記事と記事を間接的にキーワードで繋ぐというはてなダイアリーのユニークな設計は、人と人との繋がりを設計する才能がなかったら出てこない発想だと思います。

それが個人的な嗜好によるものなのか、右脳左脳みたいなその人の生まれ持った特性のよるものなのかわからないのですが、ほんと人によって結構違うんです。面白いですよね。

ディレクターとしてサービスの方向性を決める時、自分が何タイプなのか意識してみるのも良いと思います。せっかく天から授かった武器があるのなら、それを活かした方が成功確率が上がると思います。

思いついた5つの格言

Webディレクター解体アドベントカレンダー21日目の記事です。今日は箸休め回です。今さっき思いついた格言とその蛇足を5個書きます。

1. 水は低きに流れ、情報は狭きに流れる

情報って放っておくと絶対閉じる方向に向かいますよね。だから日々気が抜けない。すぐ閉じようとするんだから。意識してオープンに持っていかないと、油断ができないんですよ。プライベートチャンネルとかDMの方が話しやすいしね。グループウェアも閲覧権限絞っておいた方が書きやすいよね。どっかからツッコミ飛んできたら嫌だしね。でも勇気を持って公開しないと風通しの悪い組織になってしまう。ユーザー向けの情報だってそうです。情報を公開すればするほど炎上リスクが高まるから、ついつい最小限の事務連絡になってしまうんですよね。事実だけ伝える告知文とかね。でもちゃんと背景を説明して、想いを込めないと伝わらないですよ。だから意識して、なるべく多めに広めに公開していきましょう。

2. リニューアル炎上、防ぐ事前公開

今年もリニューアルして炎上したサービスが後を断ちませんでした。いつも思うんですけど、絶対事前に画面とか公開して意図をちゃんと説明した方がいいですよ。それしないケース多いですよね。なんでだろうね。先に画面のイメージ公開してこうなりますって発表しておけば、その段階で炎上できるんですよ。そしたら実際にリリースして炎上するより良いじゃないですか。切り戻さなくてもいいんだから。先に画面見せて、ここがこうなります、こういう意図です、ご意見くださいってお願いしたら、沢山フィードバックもらえるんですよ。だからリニューアルする時は事前に公開した方がいいと思います。

3. ペルソナは幻想、ユーザーは現実

サービス開発でよくペルソナ作りましょうって説く本あるんですけど、個人的にペルソナあんまり好きじゃないんですよね。やっぱりどこかユーザーのことなんて理解できない、理解できたと思うのはおこがましいっていう考えがあって。なんか20代女性で事務職のOLで都内のワンルームのマンションで猫を買っててみたいなの、失礼じゃないですか。人間そう簡単に分類できるほどシンプルにできていないっていうか、もっと複雑で理解したくてもできないものだと思うんですよね。だからいつもペルソナを作るんじゃなくて、実際のユーザーさんに会って、開発チームで会話するときはそのユーザーさんの名前を呼ばせてもらっています。この前のインタビューで田中さんがこう言ってたからこうしよう、みたいに。作り上げられたペルソナのA子よりも、現実の田中さんの話をしましょうよ。

4. 小さなことから、コツコツと

ディレクターって偉そうですよね。エンジニアやデザイナーのような、専門性が高くてその道をずっと極め続けている職人に対して、ああしろこうしろって指図するんですから。何様やねんと。わけわからん素人がギャーギャー指図してくるの地獄だしね。だからチームメンバーから信頼を得られるかどうかというのが死活問題です。だけど信頼って、一朝一夕に得られるものじゃない。信頼貯金っていう言葉がありますけど、コツコツちょっとずつ貯めていくものです。しかも結構減るしね。無茶な依頼した時とか、的外れなことを言った時とか、ゴッソリ減る。日々まじめにコツコツとチームのために頑張らないとすぐに破産ですよ。世知辛い世の中だね。でも仕方ない。コツコツがんばろう。

5. 立ち合いは強くあたって、あとは流れで

サービス開発の工程の中で、一番ディレクターの頑張りが成果に反映されるのって序盤なんですよ。一番最初の企画の部分。次に設計の部分で、その次が開発中の細かな判断で、最後がリリース前の確認とか調整。もちろん最後の確認や調整だって頑張れば品質上がりますよ。でも品質が良くはなるけど、需要がないものがあるものに変わるわけじゃない。作るものがちゃんとユーザーに使われるかどうかの一番大きなターニングポイントは、やっぱり工程の最初の方にあるんですよ。だからディレクターっていうのは、一番最初に一番頑張るべきなんです。わかりますよ、一番最初のまだプロジェクトが始まる前は孤独だからね。テンションあげにくい。チームメンバーが集まって、開発が始まって、徐々にエンジンがかかってリリース前にピークを迎えるんですよ、開発チームのテンションってやつは。そんな中で1人、一番最初のみんながしらけてる時に頑張らないといけないわけだから、大変だよね。だけども歯を食いしばって、立ち合いは強く当たりましょう。

f:id:nmy:20201220093007p:plain

UGCにおける鶏が先か卵が先か問題

Webディレクター解体アドベントカレンダー20日目の記事です。今日はUGC(User Generated Contents)系のサービスでよく議論になる、鶏と卵のジレンマについて書きます。

作者 or 読者

文字や画像や動画など、ユーザーが作成したコンテンツを投稿するサービス開発においてよく議論になるのが、投稿する人とそれを見る人、どちらに力を入れるのかという問題です。作者向けか、読者向けか。

コンテンツを投稿する人というのは、そのコンテンツを見てくれる人がいる場所に投稿します。インターネット上で公開するのですから、多かれ少なかれ、誰かに見てもらいたいという気持ちがあるからです。見てくれる人がたくさんいて賑わっているサービスに、投稿する人は集まりやすいです。

一方、コンテンツを見て楽しむ人たちも投稿する人がいるサービスに集まります。見る人は誰が投稿したかや、そのコンテンツ自体の魅力に引き寄せられて集まってきます。コンテンツが大事であり、それを生み出す投稿する人が大事なわけです。

ここにジレンマが発生します。作者と読者、どっちが先か。もちろん両方大事です。作者は読者がいる場所に集まるし、読者は作者の投稿したコンテンツに集まります。どっちが欠けてもいけません。

でも、最初の立ち上げ時点はどちらもゼロ。そこからどう立ち上げるのでしょうか。そして立ち上げた後は、どっちにどれくらい力をかけるべきなのでしょうか。この問題はUGC系サービスの企画をする時にはいつもつきまとう問題です。

f:id:nmy:20201218000937p:plain

立ち上げ時は作者

立ち上げ時は作者が先です。それが私なりに考え続けた結論です。もちろん同時に読者も集められたら良いでしょう。でもどちらかと言えば作者です。作者がいないと何も始まらないからです。コンテンツも生まれない。だから最初は、読者がいない場所に如何に作者を呼んでくるのかという作戦が必要になります。

圧倒的に使いやすい投稿ツールを作ってツールとして使ってもらうとか、例えば大規模な投稿コンテストを開催するとか、例えば読者はいなくても編集者がいて全部見てるとか。そういう読者以外の部分で何とか使ってもらおうとします。

結局どんなに読者にとって読みやすくて表示スピードが早くて使いやすいサービスでも、面白いコンテンツがなかったら人は集まりません。だから読者を集めるためにもまずは作者なんですね。

潮目が変わる時

立ち上げる時はとにかく作者。もちろん両方に向けた施策を打てるといいけど、やっぱり作者を大事にしないサービスは立ち上がりもしないと思います。だけどどこかで、読者に向けた施策の比重を上げるべき時がやってきます。それはいつでしょうか。そのあたりのさじ加減が難しいところではありますが、一つ目安となる数字があります。それは、PV増に占める支配的な要因がUUかPV/UUかです。

立ち上げたばかりのサービスの場合、まだまだ読者の数が少ないと思います。そういうサービスでは、PVがドーンと上がる時、それは新規流入が増えた時です。端的に言えば、Twitterでバズった時。何か1つのコンテンツが話題になって、SNSからの流入や検索流入がどかんと増える時があります。それに引っ張られてPVが上下する。

この状態の時は、PVを左右する支配的な要素は読者の数であり、読者1人あたりの見たコンテンツ量ではありません。まだまだ読者の数が少ないから、お客さんの数が増えると全体の数字が上がります。サービスの立ち上げ時はだいたいこういう状態になっていると思います。そして、その場合はやはり大事なのは作者です。作者の生み出すコンテンツが、読者を呼んでくるからです。

しかしこれが、だんだんと新規UUの流入増減よりも、1人あたりの見たコンテンツ量が支配的になってきます。読者がだんだんと増えてくると、読者が定着して新規の流入に頼らなくてもよくなってくるわけです。そうすると、読者が見るコンテンツ量が増えれば増えるほど、PVが上がるようになります。PV増に占める主な要因がUUからPV/UUに移ってきます。

そうなったら、今度は読者を重視すべきでしょう。1人あたりの再訪率を改善したり、訪問あたりの閲覧数を改善したり、そうした改善がダイレクトにサービスの成長に繋がってきます。そうなったらしめたものです。後は数字を見ながら改善のサイクルを回し続け、サービスの成長を加速させていけば、更なる成長が待っています。読者も増えるし、作者も喜んでくれます。正のスパイラルです。

でもそこに至るまでは作者の方々の声を聞きながら、地道に実直に作者のために尽くすべきです。作者が先か、読者が先か。私は作者が先だと思います。

リモートワークをスイッチに使う

Webディレクター解体アドベントカレンダー19日目の記事です。昨日までで最初に立てた目次の内容については一通り書いたので、今日からはWebディレクターの仕事に関係していたり関係していなかったりする雑談で25日まで埋めていきます。今日はすっかりお馴染みになったリモートワークについてです。

私は去年の8月に福岡に引っ越してきて、リモートで仕事をしています。元々は3年くらい前、新しい働き方に挑戦したいと思って週に1日家から働くという試みを始めたのがきっかけでした。

ディレクターというのは仕事の内容が多岐に渡るし、担当しているサービスがあるとその対応で手一杯になってしまい、なかなか新しいことを考えたり挑戦したりしづらくなってしまうという課題を感じていました。サービスの方向性を決めるべき立場の人間がそれじゃだめだと思い、何か良い方法がないかと思って取り入れたのが週1回のリモートワークです。

会社に出勤している時は普段の定常業務を中心にやり、週1日のリモートワークの日は家やコワーキングスペースなどに通って新しいことを考える時間にあてる。そうしてメリハリをつけようとしたわけです。この試みを半年くらいやってみて、目論見通りそこから新しい事業のアイデアが生まれ、その後実際のリリースにまで漕ぎ着けることができました。環境を変えることで気持ちも切り替わり、良いスイッチを手に入れたと思いました。

それから家庭の事情もあって福岡に引っ越すことになり、本格的なリモートワークが始まりました。何も工夫しなければずっと家の中で過ごすことになるので、ここでも環境を変えることで思考もスイッチするという手法を取り入れることにしました。去年の段階ではまだコロナも流行っていなかったので、毎月出張の予定を入れ、切り替えのスイッチにしたのです。

当時開発チームは京都で働いている人が多くて、クライアントは東京にいました。そこで毎月1回京都に出張して開発チームとのコミュニケーションの機会にあて、もう1回は東京に出張してクライアントと一緒に会議をしたりブレストしたりユーザーインタビューをしたりというインプットの機会にあてました。これがすごく良くて、隔週で新しい刺激をもらって福岡に帰ってきて、1人家に籠っていろんなことを考え、また2週後に次の刺激をもらいに行くという循環が回るようになったのです。これは良い仕組みだ、良いスイッチを手に入れたと思いました。

だけど皆さんご存知の通り、今年の新型コロナウィルス感染症の流行によって、出張自体がなくなってしまいました。切り替えのスイッチを失って今に至ります。この流行が落ち着いたら、また以前のようにスイッチをパチパチ切り替えながら仕事をしていきたい。そう思うものの、なかなか出口は見えません。

仕方がないので、もっと潜って内省の時期だと割り切ることにしました。もう少し長いスパンで考えて、今しばらくは自分を見つめる時期なんだと。こうして毎日記事を書いたり、長々と自分語りを続けているのもそうした活動の一貫です。

世の中の流れに合わせながらも、それをうまく自分のモードを切り替えるスイッチに使う。そんな柔軟さを大事にしていきたいと思います。

f:id:nmy:20201202142730j:plain