皆さんこんにちは。『livedoor トレビアンニュース』で編集人をしているKJ（ケイジェイ）と申します。
今回はニュース配信において、掲載する記事がないときのために用意するストック記事の選び方と種類についてお話したいと思います。ちなみに、すべての媒体や企画、番組、連載に当てはまるわけではありませんので、あらかじめご理解いただければと思います。

■ストック記事とは
『livedoor トレビアンニュース』は、ユニークなニュースをメインに掲載している情報バラエティー報道コンテンツです。ときどきマジメなニュースも掲載しますが、基本的には記者が「これは載せたい！」と思ったニュースのみを掲載しています。そういった事情もあり、記事のジャンルが日によって偏ることもありますが、社内ではそれが「トレビアンらしさ」として認められつつあります（？）。

さて、インターネットでニュースを提供しているサイトは多々ありますが、『livedoor トレビアンニュース』のように笑えるニュース、過去の知られざるニュース、豆知識ニュースなどを載せているニュースサイトには、ストック記事というものが必ずといっていいほど存在します。もちろん、『livedoor トレビアンニュース』にもあります。

ストック記事とはどのような意味かといいますと、その名の通り“記事の蓄え”のことです。このストック記事は掲載する記事がないときや、一日の掲載本数が足りないときに掲載します。時間に余裕があるときに書き、時間に余裕がないときに掲載するというわけですね。


■ストック記事の種類
「でも、ニュースって古い情報になると価値と意味がなくなるんじゃないの？」とお思いの方もいることでしょう。確かに、速報性が求められるニュースはそうですが、『livedoor トレビアンニュース』はコラム的な記事も多く、いつまでたっても古くならないニュースを載せることもあるのです。そういうニュースを『livedoor トレビアンニュース』では“腐らない記事”と呼んでいます。特に以下のようなニュースがストック記事になりやすいです。
・「実は○○だった」「○○を調べてみた」などの真実を伝える系
・「この動画が笑える」「このサービスがイイ!!」などのコンテンツを伝える系
・「こうするとお得！」「こうすると便利」などの知恵袋系
・「恋愛で悲しまない方法」「こんな合コンは嫌だ」などの恋愛系


■実際のストック記事掲載例
以下のような記事がストック記事にあたります。
【Yabee!知恵袋】電気料金がチョー安くなる方法！
電気代を安くする方法ですね。東京電力には夜だけ電気代を60％オフにできるプランがあり、実際にそのプランを導入して体験情報を掲載しています。このようなニュースは豆知識系の記事として、古くなることはありません。もちろん、電気代を安くするためのプランが改定されてしまったり、なくなってしまったらボツになりますが、めったにないことでしょう。
http://trebian.livedoor.jp/archives/54339261.html

スターバックス症候群解決！？最も長いメニューを注文
こちらは豆知識ではなく、バカ知識の記事ですね。スターバックスでコーヒーにオプションを追加しまくったらどうなるかという記事です。この記事も、いつ出しても古いとは思われない記事のひとつだと思います。
http://trebian.livedoor.jp/archives/53489664.html

牛丼“つゆだく”は店の裁量で
牛丼の吉野家で「ゆつだくだくだくだく」を注文するとどうなるか試した記事です。「つゆだく」とは「汁をいっぱい入れてね」という意味なのですが「だく」をいっぱい言うことで、もっといっぱい汁を入れてもらえるのかを試しました。こういう記事も、バカ記事として古くなることはないでしょう。
http://trebian.livedoor.jp/archives/53188750.html

……なんだか バカ記事=ストック記事 と思われてしまいそうですが、あながち間違いではありません。しかし、『ゲームの歴史を変えた？ 任天堂のプレイステーション』のように、17年前の過去の知られざる社会的な出来事をストック記事として扱う場合もあるので、すべてがバカ記事とはいい切れないですね。


■まとめ
過去のストック記事例をご覧いただけばおわかりいただけるかと思いますが、いつ載せてもいい情報がストック記事になりやすく、芸能界に関連した記事や事故・事件はストック記事になりにくい情報といえます。「○○が妊娠！」という芸能ニュースを3日遅れで載せてしまってはヒンシュクものですよね。

腐らない情報をもっとかんたんに表現すると……
どのタイミングで読んでも「へぇ〜」と思える記事！
ということになります。

私も『livedoor トレビアンニュース』もまだまだ発展途上ですが、皆さんが創りだすおもしろいコンテンツに負けないよう、努力したいと思います。最後までご覧いただき、ありがとうございました。

こんにちは、小久保です。今回は受託開発事業と自社媒体事業におけるディレクターの意識の違いについて書きたいと思います。

弊社はもともとウェブ関連のSI事業から始まっており、私が入社した5年前もほとんどの仕事がウェブの受託開発・運用でした。

そこから紆余曲折がありながら、現在のメディア事業中心の会社へと変化してきたわけですが、その過程における組織変更はまさに試行錯誤の連続でした。

以前、面白法人カヤックの柳澤社長が「受託開発と自社開発の両立」という記事を書かれていましたが、この記事を読んだときに「やっぱりどこも同じような悩みをかかえているんだなぁ」と激しく共感したことを覚えています。

ところで皆さんは、受託事業と自社媒体事業について一般的にどのようなイメージを持たれているでしょうか？　弊社が事業シフトの過渡期にあったときに頻繁に出ていた声は以下のようなものでした。

受託 = クライアントに詰められて大変、常に作り続けないといけない辛さがある
自社 = ワイワイやってて楽しそう、納期意識とかトラブル意識が低そう

確かに、受託開発事業からシフトしていこうとするときに発生していた不公平感はこの点から生まれていました。ですが、本格的に自社媒体事業に力を入れれば入れるほど、そのシビアさが身にしみて分かってくるのです。

先の記事で柳澤社長は「やったことが自分にモロに跳ね返ってくる自社サービス」という表現をされておりましたが、自分たちですべて決めたサービスがまったく流行らないで赤字だった場合、それは誰の目から見ても明らかに自分たち自身の責任なのです。また、労働集約型の受託事業と違って、こうやれば必ず黒字化できるという理詰めで考えられるものではないのも自社媒体事業の厳しい一面です。

このようにまったく違った厳しさを持った両事業ですが、受託開発事業から自社媒体事業にシフトする際に、ディレクターとして必要な意識改革のポイントをまとめてみました。

【受託開発事業】
●求められる主な能力
・企画を仕様に落とし込む能力
・開発工数の見積もり
・対外的な折衝能力
・プロジェクト進行・納期管理

●意識のポイント
・開発工数を第一優先に考え、無駄な仕様は極力排除することが必要
・すべてにおいてロジカルに考えることが必要とされ、社内調整もロジカルに進められる
・サービスの仕様が本質的にイケてない場合でもクライアントの意向が尊重される
・最終的には「クライアントの要望だから」という免罪符が存在する

【自社媒体事業】
●求められる主な能力
・業界動向や競合サービスに関する情報収集能力
・多くのユーザーに使ってもらえるサービスを考える能力
・サービスの企画・仕様策定
・媒体の収益化施策
・プロジェクト進行・納期管理

●意識のポイント
・最終的にサービスレベルを決めるのは自分達自身。言い訳のしようがない。
・メンバーがいかに同じ目標を持って進められるかが重要
・根本的には周りから信頼されないと何も進められない

このなかでまず最初に頭を切り替えなければいけないのは、受託開発は仕様に落とし込む際に「いかに開発工数の膨張(めんどくささ)を排除するか」です。そういう方向で考えていきますが、自社媒体では「サービスが流行るためには何が必要か？」ということを最優先し、開発工数はその次に考える点だと思います。

私自身も、この最初のポイントでの頭の切り替えがなかなか上手くできずに苦労した経験があります。特に受託8割、自社2割ぐらいの状態のときが、いちばん頭の切り替えに苦労しました。空気を読まずに開発にアイデアをぶつけてみるというのが意識改革の第一歩なのではないでしょうか。

現在、受託開発事業と自社媒体事業を両方抱えているネット企業に働いているディレクターの方は非常に多いと思いますが、これらの私の経験が、何か仕事上のヒントになれば幸いです。

こんにちは、清水です。
今回は、私が担当している「クチコミPR」について説明します。

みなさんの中でマーケティングやプロモーションを仕事にしている方であれば、最近の流行として「クチコミPR」「バズ・マーケティング」（Buzz Marketing）というキーワードをご存じだと思います。

■クチコミPRとは
クチコミPRをご存じではない方に向けて、大まかな流れを図で説明します。

（１）メーカーからクチコミPRの依頼を受ける
（２）ブロガーに向けて、商品（事柄）の告知をする
（３）ブロガーからの応募
（４）運営側で抽選または選抜し当選したブロガーに商品（事柄）を提供
（５）ブロガーが体験したことを自分のブログに掲載
（６）参加ブロガー、メーカー、ブログの読者の３者がトラックバックやコメントを行う
　　――ここで「クチコミ」が発生――
（７）運営側で効果測定を行いメーカーにレポートを提出

この一連の流れは、「ある商品（事柄）に興味のあるブロガーに、その商品（事柄）を体験してもらい、感じた本音をありのままに記事にしてもらう」と言い換えられます。さらに、やや堅苦しい言葉に換えれば「消費者主導型のプロモーションにまつわるコミュニケーション」の流れだとも言えます。

ここで「クチコミPRってヤラセくさいんですけど……」と感じられた方は、なかなか深いポイントを突いています。
「クチコミPR」という言葉には、性質の異なる２つのプロモーション方法が含まれます。

■２つのプロモーション方法
まず１つ目が、ペイド・パブリシティ(Paid Publicity)です。これは「一見すると記事に見えて、実は広告である」という手法です。記事広告とも言われます。そして日本語の「クチコミ」は英語で「Word of Mouth」（WOM）といいますが、ペイド・パブリシティ型のクチコミPRを「ペイド・ワム」（Paid WOM）と呼びます。

もう一つは、消費者が自発的に商品（事柄）に惚れ込んで自然発生的にメッセージが伝わっていく「オーガニック・ワム」（Organic WOM）です。一般的に言われる「クチコミ」は、こちらイメージする場合が多いはずです。

両者は、報酬が「金銭」か「対価」（商品や事柄）という以上に大きな差違として「正直さ」の度合いが上げられます。実は、この“正直さ”こそが、クチコミPRの最重要ポイントになります。

■クチコミの本質
米国のWOMMA（Word of Mouth Marketing Association）という団体は、「クチコミの本質は『Honesty』（正直さ）である」として「ROI」というポイントを掲げています。
（１）Relation： あなたは誰の代弁者（誰が利益提供者）であるかを正直に言います。
（２）Observation: あなたは自分が信じている（感じた）ことを正直に言います。
（３）Identity: あなたは自分の身分（身元）に関して決して嘘をつきません。
クチコミPRが“ヤラセ”であるか否かは、記事や広告といった手法や、金銭や対価といった報酬の違いではなく、賞賛や批判をどこまでも“正直”な意見として語れるかの一点につきます。記事でありながら不正直な場合もあれば、広告なのにも関わらず正直さに胸を打たれる場合もあります。クチコミPRがヤラセにならないためには、仕掛ける側の「メーカー」と「PR組織」、それを受け止める「消費者」の双方向に“正直さ”という絶対的な誠実さが求められます。

冒頭に掲げた「消費者主導型のプロモーションにまつわるコミュニケーション」という言葉の“コミュニケーション”は、「フェア（公正）な対話」と置き換えられます。


■クチコミを成功させるためのポイント
さまざまな人が、それぞれの立場で自由に意見を発信できるのがCGMです。そして、CGMを土台にしているクチコミPRを成功させるには、以下のようなポイントが大切になります。

（１）メーカー：
　・お客さまに最大の満足をしてもらえるように努力する
　・商品（事柄）の使い勝手やレベルを常に改善していく
　・お客さまからの疑問、懸念、批判に常に誠意をもって応じていく
　・お客さまと常に対話をして、商品（事柄）に反映させていく
　・お客さまに応援団になってもらう（ロイヤリティーを確保する）ことに全力をつくす

（２）消費者：
　・自分が伝えたいと思ったら書く
　・自分が体験したことを書く
　・自分の本音を書く
　・体験した商品（事柄）の長所も短所も書く
　・普段の生活からの視線で書く
　・誹謗中傷はしない

（３）PR運営組織：
　・コミュニティーをつくる
　・専門家コミュニティーと接触する
　・意見を交わすための便利なツールを提供する
　・参加（行動）がしやすくなる動機付けをする
　・参加（体験）者、読者、メーカー、運営の四者で情報を共有する
　・クチコミPRをフォローするマス向けの広告や宣伝を行う
　・クチコミPRの効果を検証・報告し、実施期間中にリアルタイムな修正を行う

　以上のようなポイントをふまえて、それぞれの立場でフェアな対話をすることがクチコミPRでは大切になります。

どうも、2度目のユティです。前回よりは、若干マジメなことを書きます。
自分の担当しているコンテンツのサーバ台数が何台で、それぞれどんな動きをしているのか、ということを把握しているでしょうか。もちろん、ディレクターなので実際サーバを管理しているという方は少ないと思いますが、サーバのことを知っておくことは大変意味のあることです。その理由のひとつはコスト管理です。

■コスト管理
ライブドアは自社でデータセンター（IDC）を持っていますが、なにかサービスを始める場合には、新たに自分たちでサーバを立ち上げるか、どこかのIDCでサーバを借りなくてはいけません。いずれにしろコストが発生するということです（ライブドアも自社ではありますが、コストは発生しています）。サービスの安定性を高めたいときや、大規模なサービスを構築したいときなどは、それなりの台数が欲しいというのも当然なのですが、コストの面だけで見れば、出来るだけ少ないサーバ台数でサービスを運用したいというのは、誰もが考えるところだと思います。

■サーバ台数を削減する施策
ということで、ちょうど先日「livedoor 天気情報」でサーバ台数を削減する施策を行いましたので、参考までにつらつらと。具体的にいうと、これまでWebサーバ（www）、アプリケーションサーバ（app）、キャッシュサーバ（mem）というように分散していたものを1台ずつに収めるのと、コンテンツ本体に比べて相当アクセスの多かったAPI、Webservice、RSSの部分だけを、別サーバで処理するようにしました。

具体例
下記のように構成を変更したことでwwwサーバ5台分の削減が可能となりました
※IPアドレス、サーバ台数は全て例です。

旧構成(計12台)
www 10.0.0.[1-5]
app 10.0.0.[10-14]
mem 10.0.0.[20-21]

※wwwとappが1台ずつ対で稼動しています

これを以下のように↓

新構成(計7台)
www+app+mem 10.0.0.[10-14]
API（app） 10.0.0.[20-21]

※このときのAPIへのリクエストは、wwwのmod_proxy_balancerで負荷分散しています

実際にこの作業を行ったのはプログラマですが、ディレクターはなにがどうなるのかは理解しておく必要があります。自分で分かってないものを依頼してはいけません。このディレクターが学んでおくべきことについては、以前の『「エンジニアは魔法使い」という幻想』に詳しいかと思います。

■コンテンツの特性を考慮する
コストコスト言っていて切なくなりますが、CGMコンテンツのようにユーザーによって生成・熟成されていくコンテンツとは違い、天気・地図・路線のような外部サービスのASPを利用する、いわゆるメディア系コンテンツは必ず情報提供料としてコストがかかります。つまり、システム＋情報であり、無駄なコストは削っていかなくてはいけません。そして削れるのはシステムということになるわけです。もちろん、アクセス増などを考慮した安定運用が可能な範囲で、ですが。


サーバ構成を理解しておけば、トラブル時の状況判断もでき、その対応の早さも変わってきます。今回ご紹介したようなサーバ構成の変更以外にも負荷分散の方法はいろいろとありますが、mod_proxy_balancerやLVSの利用などの仕組みは理解しておくべきでしょう。


次回はサーバ構成関連の続きものということで、負荷分散について実例をあげてご紹介したいと思います。
(当ディレクターBlog初の連続掲載です！)


ライブドアではシステムの知識を兼ね備えた方をディレクターとして迎える準備があります。現在、ライブドアではディレクターを募集しています。

こんにちは、櫛井です。
webディレクターという仕事は色々な職種の方たちの間に入って調整をすることが多いのですが、一口で「調整」といっても結構難しいものです。webサイト開発に限らず、「言われたまま、言われた順にこなしている」という人が担当だと予定通りに物事は進みません。そこで今回は、webサイト開発時に頻繁に用いられるスケジュール作成方法についてお話してみたいと思います。
山ほどあるタスク、どれから手をつけるべきかを考えるためのヒントになれば幸いです。

■ステップ.1　タスクに優先順位をつける
まずはそれぞれのタスクに優先度をつけ、種類を決めて考えます。
・クリティカル・パス
　(絶対に遅らせてはならないもの。最優先として認識すべきもの)
　参照記事：プロジェクトマネジメントＯＳ本舗

・やらなければいけないこと
　(バグ解消、トラブル対策で必須なもの、社外との交渉など)

・やっておくといいこと
　(利便性の向上、企画モノの準備、過去のレポートまとめなど)

・やる必要はないがやりたいこと
　(担当のコダワリ、チームのモチベーション向上のための施策など)


■ステップ.2　スケジュールの期限を把握する
タスクに種類があるように、スケジュールにも種類があります。対外的な要因や、公開日だけが諸般の事情で決まっているものなど様々です。
・必ず守らなくてはならない期限があるもの

・やれればいい希望的期限を設定するもの

・いつでもいいけど早くやったほうがいいもの

・いずれやるかも知れないもの


■ステップ.3 そのタスクに必要なリソースを確認する
その作業を行うために３日かかるのか２０日かかるのかで事情は随分と変わりますので事前に把握しておく必要があります。
経験則で「これぐらい」というのもアリだと思いますが、自分の作業以外の場合は素直に聞くのがよいでしょう。


■ステップ.4 スケジュール表を作成してみる
というわけで、具体的な例として9月1週の段階でlivedoor PICSであがりそうなタスクを上記であげた内容にあてはめて作成してみます。



まずは今あるタスクを思いつく順に書き出してみます。



次に「優先順位」「期限」「リソース」を入れてみます。



「優先順位」が高いものから順に並びかえてみます。



タスクの一覧をもとにざっくりとしたスケジュール表を書いてみます。
まずはパッと見で雰囲気が伝わればいいのであまり神経質にならなくてもよいです。

さて、このスケジュール表に矢印を入れていきます。期限があるものは期限から逆算して必要と思われるリソース＋２〜４営業日付け加えたうえで予定をいれておくと余裕のあるスケジュールとなります。(可能であれば、ですが)

・「サーバ追加」は10月末までにやればよい。1週間ほどで出来るが余裕をもって2週前に依頼
・「A社キャンペーン」はページ数は少ないが確認なども入るので早めに素材を受け取っておきたいので1ヶ月前には届くように依頼しておく
・「インターフェース改善」は一旦置いておいて・・・
・「秋フォトコンテスト」はすぐに出来るので素直に設置
・「レポートファイル追加依頼」は手のあいている9月前半に片付けておこう
・「favicon差し替え」は秋フォトのタイミングくらいにしよう
・「インターフェース改善」は出来れば細部まで詰めたいから余裕をみて4週程度みておこう。9月4週から10月2週が作業がないからそのタイミングでやってしまおう。

という形で順番を工夫しながら置いてみたスケジュールがこのような形です。



ここまで出来たらプロジェクトチーム内で共有し、他に担当しているプロジェクトの進行具合や、スケジュール感に無理がある箇所がないかを確認しあい、最終的なスケジュールとして仕上げていきます。
チーム内全体で合意がとれたうえで作業に着手することで、コミュニケーションロスを防ぐことが出来るという効果があります。

■その他に留意すべきこと
・優先順位に関わらず、他に影響するものがないものは最優先でサクッとやったほうがいい

・既存のシステムに影響するものは上位にあるものから片付ける

・クライアントの確認や社外の調整が必要な場合、一度でOKが出る前提でえがちだがリテイクがある前提でスケジュールに余裕をもたせておく。

スケジュール作成や作成後の管理は難しいですが、それはまたの機会に。
他にも様々なノウハウが存在しますが、もっと知りたい方は「続きはwebで」！

初めまして、元（？）ディレクターの原といいます。ポータルサイト livedoor には現在、ニュースとブログを2本柱にさまざまなコンテンツが存在します。私は一応『livedoor ニュース』に関わるディレクター陣のマネジメントをする立場にありますので、その立場からディレクターについて書きたいと思います。

　『livedoor ニュース』には現在、70を超える情報提供元からの記事を掲載していますが、今から約4年前の立ち上げ当初は、毎日新聞の1社提供でコンテンツ全体のアクセス数が現在の記事1本のそれに満たないような状況でした。その後、扱うカテゴリも国内外の時事問題のほか、スポーツやエンタメなどさまざまな情報を横断的に扱うようになり、コンテンツ規模の大きさからも多くのディレクターが関わるようになりました。

　弊社では、プログラマー、デザイナー、マークアップエンジニア、ディレクター、営業のように職域ごとに分けて人員配置がされています。すべての職域と接点をもつディレクターのなかには、システムに関する知識が豊富な人、デザインセンスに優れている人、社外との営業交渉に秀でている人など、それぞれに得意不得意な分野があります。独自記事を提供する『livedoor ニュース』においては、自ら現場に赴き取材を行い、記事作成が行えるような行動力や編集・ライティング力も望まれる能力のひとつです。

■評価されるディレクターとは
　ディレクターの仕事内容はコンテンツによって多岐に渡りますが、さらに高い次元でいうと、デキル人というのは何をやらせても人並み以上の成果を上げることができます。何か仕事を任されたときに、A：期待以上の成果を上げてくれる人、B：言われたことだけはキッチリこなす人、C：言われたことすら満足にできない人。言うまでもなくデキル人はAで、Bは及第点のように思えますが、逆にその人でなければならない必要性もないので、価値が高いのは実際に業務を担当した人ではなく、指示を与えた人ということになります。Cについては論外ですよね。

　このブログにもディレクターと呼ばれる人が数多く登場していますが、スペシャリストとして誰にも負けない個性や専門性を高めつつ、オールラウンダーとして不得意を得意に変えていけるような人が優秀な人材と言えるでしょう。至極簡単な例としてニュースでいえば、政治・経済は詳しいけど芸能・スポーツには興味がない、その逆もしかりで、いずれも能力として評価すべき状態ではありません。

　優秀な人ほど自分の首を絞めるように新たな仕事を発見し、周囲からは多くの仕事を任されるので、同じディレクター職でもその仕事量はさまざまです。また大多数のユーザーにサービスを提供する以上、24時間365日気が休まる暇はありませんが、そんななかでも自分なりのやり甲斐を仕事に見出し、オンとオフとの切り替えを上手くできる人が、弊社には向いているのかと思います。

■最後に
　余談ですが、私は前職で音楽業界に在籍していたためウェブ業界は未経験でした。当時の面接官の「今後ディレクターになるためにも、まずは開発現場を知っておいた方がいい」という言葉に従い、マークアップエンジニアとして入社して経験を積みました。弊社には“習うより慣れろ”な風潮が少なからずあるので、ディレクターの仕事について誰からも教わったことがない私は、社内でいちばんディレクターとしての自覚が足りないのかも知れません……。

　ディレクター募集をしておきながら変な話ですが、能力とやる気次第では入社後の異動も可能な会社ですので、隣接する職域で現場を体験するのも将来、優秀なディレクターになるための第一歩だと思います。

『livedoor ニュース』にてIT（コンピューター）ニュースを担当している庄司です。日々の業務で向き合っている、ITニュースにおけるコンテンツ成長への取り組みと変遷について考察してみたいと思います。

■情報コンテンツの変遷
IT系情報ニュースは、ニュース（速報性）とレポート（取材やレビューなどの情報）をメインコンテンツとして形成されてきました。情報の早さと量を中心に成長してきたといってもよいでしょう。livedoor をはじめとするポータルサイトのITニュースは、今日までそうした記事の提供を受けて読者に配信をしてきました。

インターネットニュースが登場してから現在に至る過程で、インターネットにおけるニュースコンテンツは、上記の目的と内容において確立したといえるでしょう。しかし、Web2.0などの新しい時代への移行に伴い、1年ほど前からニュースコンテンツに求められている需要に、大きな変化が発生してきています。

■読者ニーズの変化
ニュースサイト運営にとって重要なのが、読者ニーズのベクトルです。これまでのニュースコンテンツに対する読者ニーズは、速報であり情報であったといえます。しかしながら、インターネット上のニュース情報は、現在ではいたることころで入手可能となっています。

読者にとってニュース（速報）という情報は、もはや特別なものではく、どこでもいつでも手にはいるものとなっています。また、現在の膨大なニュースの情報は、理解する前に流れては消えて行くため、読者の知識として定着しにくいものとなってきています。

ポータルサイトは情報を集約することで、複数のサイトを巡る手間を省くという利便性があります。しかし、これまで通りのコンテンツ運用では“読者が求める知識”としてのニュースという意味であれば、読者のニーズに応えることができません。サイトを成長させるためには、読者のニーズに応えるコンテンツ拡張と向上への施策が問われるわけです。

■求められるコンテンツとは
ポータルサイトの情報コンテンツは専門サイトとは異なり、幅広い情報が求められます。個人ブログレベルの情報からタブロイド誌、週刊誌、新聞など、既存の情報メディアも含む幅広いコンテンツが求められます。ひとつのサイトでインターネット上のすべてのコンテンツを提供することは、事実上は不可能といえますので、読者に応じた記事の導入から編成における運用の最適化まで、常に更新していくことが必要となります。

この際に重要なのが、読者ニーズの把握と自社コンテンツの分析です。読者ニーズは、ページビュー（PV）やユニークユーザー数（UU）、トラックバックや読者からのご意見などをもとに分析と解析を繰り返すことにより、指針を策定します。365日毎日アジャストを繰り返し、成長目標とコンテンツ強化の着地点を探りながら最適化に取り組まなければ、サイトの成長は実現はできません。

この解析と分析における強化の着地点を策定するノウハウが、サイト運営にとって重要な企業秘密ともなるわけです。

■二次元から三次元化する成長モデル
ここで情報サイトとしての成長モデルをみてみましょう。

・ニーズと開拓
サイトを成長させるには、「読者を増やす＝読者開拓」と「コンテンツ品質の向上＝記事開拓」に分けられます。読者を増やすには、読者が求めるものを調査または分析し、読者のニーズに対応できる記事コンテンツを確保・開拓しなければなりません。

では、読者が求める記事をすべて集めれば必ず成長できるのでしょうか？　答えは“ノー”です。ただコンテンツを集めるだけでは、読者にコンテンツを届けることができないからです。

・計画的なコンテンツ強化と運用による読者への提供
サイト成長をスムーズに進行させるには、時間軸に沿った読者開拓と連携するコンテンツ育成が必要となります。コンテンツは、下記のような段階的な軸線上での拡張ステップを、読者の反応を確認しながら進めていくことが要求されます。

記事量の確保　＞　記事（種類）の多様性の確保　＞　記事品質の向上（含む独自性）＞　読者への提示品質の向上

こうしたステップは一過性で完結はせず、これをひとつのサイクルとして繰り返す必要があります。その理由は、すべてのフェーズをクリアした段階で、いちばん重要な読者ニーズがスタート時点とは確実に異なっているからです。つまり、1サイクルを通す間に読者の成長や変化により読者ニーズに変化が生まれるということです。したがって、課題のフェーズをクリアした時点が現在の読者に対する次のフェーズのスタート地点となるわけです。

コンテンツの強化フェーズは二次元的なモデルから、スパイラル（螺旋）構造をもつ三次元的なモデルへと移行させていく必要があり、読者と向き合いながらスパイラルな展開を繰り返すことで成長という結果に近づくことができます。

余談ですが、コンテンツ強化を企業内で恒久的に実行することは、私たちの livedoor に限らず、多くのサイト運営者にとっても困難なことでもあります。企業内では、予算やマンリソースなど、サイト運営では多くのトラブルが発生するため、スパイラルな成長モデルを維持することも担当者の手腕として問われたりします。

では、コンテンツのスパイラルステップを無限に繰り返せば、サイトは無限に成長できるのでしょうか？　実は、これも“ノー”なのです。

■成長し続けるためには
スパイラルモデルで永久に成長し続けられない理由は簡単です。このモデルでは、“読者”と“コンテンツ”を結びつけている構造に限界があるからです。限界点までは、このモデルでも成長は可能ですが、それ以上の成長には新しい“読者とコンテンツ”のコンタクト構造を確立しなければなりません。つまり、三次元的なコンテンツモデルを内包し、読者動向に連携した多次元モデル化が必要となるわけです。

■次世代のニュースとは、どうあるべきなのでしょうか？
次世代のニュースサイトに求められるものは何か？　そのひとつが多次元的なモデルの形成ということになりますが、そのために必要なものは、ソーシャルコンピューティングへの転換ということになります。それはいずれまたの機会があればということで、今回はこの辺で失礼させていただきます。

こんにちは。livedoor でディレクターをしている有賀です。

今日のお題は、「人の目を引くクリエイティブ（ビジュアル基本編）」についてです。

前回の「ライティング編」でお話ししたように、私たちは日夜“一瞬で理解できるモノ作り”を試行錯誤しているわけですが、それとツートップとなるのが前回お話した「コピー（文字）」と、今回お話しする「ビジュアル（視覚表現）」です。
多くのユーザーは、ウェブページを見てから数秒で「見るべきものかどうか」を判断するというシビアなご時世。その数秒のほとんどは、実は、ビジュアルの印象で占められているのではないかと思います。

私もユーザーとしてサイトを見た場合、ページを開いてから一瞬で目にする構造（レイアウト）や色、形や動きなど、文字を読む前にインプットされる情報によって、多くの判断をしていることに気が付きます。

今回は、そんな「ビジュアル」についての概念を簡単にお話します。

【01】ファーストビューという一等地

ウェブサイト構築においての第一印象は、ファーストビューで決まると考えています。ファーストビューとは、そのページを表示したそのままの状態のことです。つまり、ブラウザで表示した最初に（スクロールせずに）見える範囲（＝First View）にあるもの、ということです。

ウェブでは、このファーストビューが第一印象そのものなので、ここに伝えたい重要な要素やイメージを凝縮することが、肝要になります。主要なナビゲーションなども当然、ここに配置されることが望ましいことになります。このファーストビューで気を引けない場合、当たり前ですがファーストビュー以外の部分や、訪れて欲しい次のページなどには、目を向けられないと考えなくてはなりません（とはいえ、ファーストビューになんでもかんでも詰め込み過ぎるのは得策といえません）。余談ですが、広告価値としてもファーストビュー内が一等地ということになります。



【関連リンク】livedoor.com の広告掲載について
〜livedoor の各コンテンツ毎の広告価格は媒体資料に掲載しています〜



さて、ここで問題になるのが閲覧者ごとに画面サイズが違うということ。これには“livedoor Blog PRO”などでもお馴染みの、アクセス解析が指標になります。利用者の大体の動向をアクセス解析結果からつかむことができます。この『livedoor ディレクター Blog』の場合、1280 x 1024ピクセル 環境での利用が4割弱、1024 x 768ピクセル 環境での利用が3割弱ということで、ブラウザのアドレスバーや余白を考慮すると、だいたい上部から600ピクセルぐらいが、大多数の利用者に向けてのファーストビューと定義してよいでしょう。

【02】第一印象はほとんど色彩で決まる

イタリア料理店の看板は、たいてい赤や緑ですよね。プールの底は水色、医療機関の内装は淡色……と、お決まりのような色使いは、どうやら偶然や慣習ではないようです。色彩にはそれぞれ意味があって、人間は直感でそれを察知します。

さらに美的・情緒的効果だけでなく、「理解しやすさ」や「見ていてストレスを感じない」など、色彩は機能的効果も持ち合わせています。ウェブ構築においても、当然それを計算しなくてはいけません。

livedoor には、各サービスカラーというものがあります。各サービス名の入ってる横に細長いバーがあり、それが基調色となっています。サービスカラーは、対象を想定しているユーザー層や関連ページとの関係を考慮して決めています。


【関連リンク】この色の名前はなに？　を教えてくれる『Name That Color』を紹介しているページ

【03】ポータルサイトのレギュレーション

ポータルサイトの運営には、多くのレギュレーション（制作規定）の遵守が義務付けられています。それは、livedoor 全体で一定の統一感を持たせることで利用者の使い勝手をよくしたり、開発自体をスムーズにする目的で制定されているのですが、一度決まったルールも、世情や技術進歩に合わせて日々議論を重ねて更新していくので、策定作業は終わりのない旅のようなものです。

そのなかでも、もっとも厳格なものが、livedoor ロゴのレギュレーションです。これは、サービスロゴの基本的な冠になると同時に、弊社のコーポレートロゴでもあるからです。

【04】人の気を引くビジュアル例

気を引くというと、「日付以外はすべて誤報」といわれるほどの『東スポ』に代表されるような、スポーツ新聞の見出しが真っ先に思い浮かびます。

これは、コピーワークの威力がものをいうデザインではありますが、やはり独特のテイストは視線を奪われます。ここでは、色彩の効果とともに、「ジャンプ率」という概念が奏功しているといえます。

ジャンプ率とは、もともと紙媒体の紙面レイアウトにおける用語ですが、簡単にいうと、「本文に対する見出しの大きさの違い」のことです。ジャンプ率とは、まさにメリハリのことで、重要でキャッチーな文字は極大で、それ以外を限界まで小さく、といった技法によって、躍動感や扇情感が醸成できるというものです。

【関連リンク】ジャンプ率とは（livedoor 検索）

【05】まとめ

ウェブページにおいて、人の目を引くためにビジュアルでできることとは？　ウェブの種類にもよりますが、「ファーストビューに流行のビジュアルモチーフを、色彩の意味を意識して、メリハリを効かせて」レイアウトすることだと思います。

もちろん、人の気を引いただけで、実効コンテンツが伴ってなくては本末転倒なわけですが、そもそも人の目を引いて認知してもらわないことには、どんなに素晴らしい（と思っている）サービスも意味がないわけです。ですから、ウェブディレクターは、サービス自体の設計の基幹部分に、「人の気を引くこと」を入れて、日夜、試行錯誤しているわけです。

今後とも、livedoor および『livedoor ディレクター Blog』をよろしくお願いします。