入札運用型広告はインハウスで運用した方がいいと以前のエントリーで書いた。ブランド統合的にインハウスないしハウスエージェンシーでの運用がお奨めだ。リスティング広告をインハウス運用して、またアウトソースに戻してしまうケースもあるが、それは導入方法が悪かったからだ。ディレクションできるスキルを獲得できないで、作業に埋没してしまうと何も得る事のないまま、また完全アウトソースに戻すことになる。それでは意味がない。
そもそも「運用」とは何を「運用」するのかというと、事業部から預かった広告投資用の金を、求められる広告パフォーマンスに変換して返すという「運用」である。期待値を上回るパフォーマンスにして返して初めて「成果を出した」ことになる。
この際、売り手の論理で出来た「枠」を買うことももちろんあるだろうが、基本的に買い手が自在に入札するモデルを十分に活用することが前提だ。何故かというと、入札型であれば、買い付けてみて、期待されるパフォーマンスがとれない場合、すぐにでも止めることが出来るからだ。株を買って、株価が下がれば、場合によっては損切りしてでも売ってしまい、その分を他の株に投資して取り返すことを当然やるだろう。
広告の運用も株式の運用と考え方は同じだ。
従来の「枠」もの広告は、契約上買ってしまうと、途中でパフォーマンスが悪いことが分かっても「止めます」という訳にはいかない。(当然です。)
いくらPDCAを廻すとか言っても、「枠」を買ってしまう投資より、1配信づつを丁寧に入札するスキルを高めることが効果的だ。
そのためには、日々、リアルタイムの運用経過を共有し、知見を高めることだ。
事前に決めたバイイングプランで最後まで突っ走る時代ではない。反応はリアルタイムで把握できる。ユーザーレスポンスを見ながら、最も効果的かつ効率的なハンドリングをする時代なのだ。
リアルタイムでデータが把握できるのに、リアルタイムで手が打てないのでは意味がない。PDCAサイクルはもう極限まで短いものになっている。「一定のパフォーマンスが得られなければ中断して他の手段にしてみる、または期待以上のパフォーマンスがあれば追加予算を投入して、もっと押す。」という考え方にならなければだめだ。
「広告枠を買う」のではなく、「広告パフォーマンスを買う」のであり、そのためには自分自身でダイレクトに入札することで、いつでも「Go or Stop」を自在にコントロールするのが当然のこととなるだろう。
代理店に発注してしまうモデルはマージンを取られるからどうこうではない、代理店のマージンは当然あってしかるべきものだ。「枠」の投資成績が良ければ、代理店から「枠」を買うので良い。代理店にマージンを下げさせるのが効率の良い買い付け方なのではない。そもそも買い付け額とその配分を、買っている本人が自分で自在にコントロールした方がよいのだ。
「運用型広告」の「運用」とは、金融の「運用」と近い感覚のものである。もちろんかかるコストはPL上の費用ではあるが、だからと言って予定されたものは使ってしまうものとか、予備資金は全くないというのでは「運用」にならない。
Googleが何らかの特許を取得したからといって必ずしもその特許に書かれている仕組みを今利用しているとは限らないとGoogleのマット・カッツ氏は、SEOに取り組むウェブマスターに注意を促した。しかし特許はGoogleが目指す検索を理解するうえで非常に優れた学習教材であることも事実だ。
- Googleが取得した特許を学ぶことに価値はあるのか? -
Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM
2013年1月12日(土)、ベルサール半蔵門で開催したCSS Nite LP, Disk 26「CSS Preprocessor Shootout」のすべてのセッションのフォローアップ(スライド、音声)を公開しました。

2013年1月12日(土) 、ベルサール半蔵門で開催したCSS Nite LP, Disk 26「CSS Preprocessor Shootout」のフォローアップとして、小久保 浩大郎さん(Google)、高津戸 壮さん(ピクセルグリッド)、小山田 晃浩さん(ピクセルグリッド)の『CSSプリプロセッサーの登場・発展から考えるCSSデザインの過去・現在・未来』のスライドなどを公開します。
「CSSプリプロセッサ の登場・発展から考えるCSSデザインの過去・現在・未来」と題して最後のセッションを担当した小久保です。参加された皆様、長時間お疲れ様でした。長いイベントの最後ということで、具体的なテクニックではなく意味や意義について考えてみるセッションにしてみましたがいかがでしたでしょうか。個人的にもテクニカルな解説は過去にやっているので、今回は改めて別の視点から考えてみるいいきっかけになりました。セッションでも述べたとおり、およそほとんどの技術は、何らかの問題に対する解決として生まれてきています。今 CSS プリプロセッサを使うことは、決して無駄ではなく将来にも役立つ未来の先取りなんだ、というふうに思って取り組んでいただければ幸いです。
今回のセッションは概念的な内容でしたが、再利用可能な Sass ライブラリを構築する際の問題とその解決について書いた記事があるので紹介しておきます。今回のセッションの内容とは逆に、細かくて具体的なテクニックの話ですが、ライブラリが大きくなってくると必ず出てくる問題かと思います。記事を書いたあとで気がついたのですが、全く同様のテクニックを Sass の共同開発者である Chris Epstein 自身も薦めていました。そのことも記事中に追記してあります。

2013年1月12日(土) 、ベルサール半蔵門で開催したCSS Nite LP, Disk 26「CSS Preprocessor Shootout」のフォローアップとして、山田 あかね(グリー)の『GREEを支える技術フロントエンド版』のスライドなどを公開します。
グリーの山田あかねです。このたびはご参加いただきましてありがとうございました。
GREEの高速化にあたりSassで行っていることを中心にご紹介させていただきました。Sassでできることはもっとたくさんあるため、是非皆様も実際に触ってみて、楽しさを実感していただければ幸いです。
アンケートでいくつかご意見・ご質問をいただきましたので、回答させていただきます。
Q: ファイルの管理は基本的にローカル+Gitなのでしょうか?複数人でファイルを同時に触るさいに気を付けていることがあれば教えてほしいです。
A: ローカル+Gitにくわえ、エンタープライズ版のGithubを活用しています。Gitはおのおのの開発者で分散して開発できるのが魅力ですが、実際にリリースをする際にはSubversionのように中央集中型の管理をおこなうメリットも大きいため、Githubを使いながら両方の良さを取り入れて開発しています。
Gitを使えば、複数人でファイルを触る際にも「ブランチを切る」というかたちで、同時進行で異なる機能の開発が可能になります。個人的に、Gitを使ってしまうと、もう以前の開発スタイルに戻れなくなるほど便利だと思います。
少し古い記事になりますが、グリーの開発フローについての記事も参考にしていただければと思います。http://labs.gree.jp/blog/2011/05/3528/
Q: 使っているmixin群とかを見てみたいです。
A: 全て公開することはできませんが、一部ご紹介させていただきます。webkitにしか対応していないプロパティに対して、compassのexperimentalを読み込むようなことをmixinでやってたりします。
// デバイスを傾けたときの文字の大きさ調整
@mixin text-size-adjust($val:none) {
@include experimental(text-size-adjust, $val,
not -moz, -webkit, not -o, not -ms, -khtml, not official
);
}
// タップハイライトカラー
@mixin tap-highlight-color($color) {
$color: none;
@include experimental(tap-highlight-color, $color,
not -moz, -webkit, not -o, not -ms, -khtml, not official
);
}
// ボタンのスタイル
// ボタンの色関連:文字色・背景ハイライト色・背景シャドウ色・枠線色・枠線トップ色・枠線ボトム色・テキストシャドウ色・ボックスシャドウ色・内側のボックスシャドウ色の順に指定
@mixin button-colors
(
$color1: $button-text-color,
$color2: $button-top-bgcolor,
$color3: $button-bottom-bgcolor,
$color4: $button-line-color,
$color5: $button-top-line-color,
$color6: $button-bottom-line-color,
$color7: $button-text-shadow-color,
$color8: $button-box-shadow-color,
$color9: $button-box-shadow-inset-color,
$text-shadow-y: 1px
) {
border: 1px solid $color4;
border-top-color: $color5;
border-bottom-color: $color6;
color: $color1;
text-shadow: 0 $text-shadow-y 0 $color7;
@include background-image(linear-gradient($color2, $color3));
@include box-shadow-mix(0,1px,1px,$color8,0,1px,0,$color9);
}
このようなかたちで、mixinの中でも別のmixinをincludeして使っているものもあります。 デザインに秩序がある場合、特に仕組み化しやすいのではないかと思います。
Q: 変数の方面なども是非おうかがいしたいです。
A: 最初はLessやSassの機能を試してみたい好奇心で、色を変数化して、亜種の色を演算で表現したりもしていました。しかし実際にやってみてわかったのですが、デザインの方向性がしっかり固まっていないうちに色を変数にするとかえってややこしくなるという印象です。
それでも色を変数にするメリットは大きいです。たとえばトーン&マナーを保ちながら、カラースキームだけをがらっと変更したいようなときなどです。キーカラー、アクセントカラーなどを変数化しておけば、たった数個の変数の値を変えるだけでサイトの印象をがらっと変更できます。
また、レスポンシブに設計したいときには幅やグリッドのしきたりに対して変数をつけておくと運用しやすいかと思いますが、こちらもやはりデザインルールがしっかりしていないとかえってややこしくなってしまうと思います。プリプロセッサを使う使わないに関係なく、設計をしたり、長持ちする仕組みをつくるためにはデザイナーとのコミュニケーションは欠かせないと考えております。
以上、回答とさせていただきます。
ありがとうございます。

2013年1月12日(土) 、ベルサール半蔵門で開催したCSS Nite LP, Disk 26「CSS Preprocessor Shootout」のフォローアップとして、佐藤 歩さん(サイバーエージェント) の『Stylusが目指す“CSSプリプロセッサ”』のスライドなどを公開します。
「Stylusが目指すCSSプリプロセッサ」を紹介させていただいた、さとう歩(@ahomu)です。当日はご清聴いただきありがとうございました。
CSSプリプロセッサ3連チャンの最後ということで、Stylus自体に加えてプリプロセッサとCSSの関わりの概念的な領域も紹介してみました。
コミュニティによる支持においては、やはりSassが有力なように感じますが、どのCSSプリプロセッサを利用するとしても、今回ご紹介したプリプロセッサとCSSの問題にちゃんと向き合うことはマストだと思います。ご参考になれば幸いです。 以下、実行環境や、機能文法などについて改めてフォローします。
黒い画面のプレッシャーが全体通して強いイベントではありましたが、「まず始める」という意味では、ツール系セッションで紹介されていたGUIのソフトウェアがおすすめです。
自身は Grunt http://gruntjs.com/ というコマンドラインツールで、他のビルドプロセスと統合して自動化し、プロジェクト内でもpackage.jsonをベースに環境を共有しています。
公式のドキュメントや、セッション中でも紹介したTry Stylusのサンプルコードをみてもらうのが一番確実です(コードサンプルとして簡単に読めます)
私も参加しているenja-ossという翻訳コミュニティで、Stylusのドキュメント和訳が進んでいるため、こちらをチェックして頂くのも良いと思います。(始まったばかりですが、じきに内容が充実してくるはずです)
透過的なmixinが、機能の利用を明示しないという点が逆にどうなのよ、ちゃんと区別できたほうがいいんじゃな?というご意見もあったようです。私も明示的なインターフェースは大好きなので、少なからず共感するところです。
そんなときもStylusは柔軟なので、mixinも「border-radius(3px);」のように書ける選択肢があります。ちょっとLESSのmixinに似ている記法です。また、変数の冒頭に書く記号($)は付けてもよいし、付けなくてもよかったりします。
StylusでCSSから最も距離を取ったSyntaxを選ぶと、(明示的mixin・プレフィックスつき変数・CSS文法の記号を省略)以下のようになります。
border-radius(n)
-webkit-border-radius n
-moz-border-radius n
border-radius n
$radius-length = 5px
form input[type=button]
border-radius($radius-length)
このあたりも好みに合わせて、「ちょうどよく」なれるStylusであることを、頭の片隅に留めていただければ幸いです。
こちら、アンケートで頂いた質問ですが、できます!.cssも.stylも@importで読み込んで、コンパイル時には1ファイルに結合されるようにできます。

2013年1月12日(土) 、ベルサール半蔵門で開催したCSS Nite LP, Disk 26「CSS Preprocessor Shootout」のフォローアップとして、石本 光司さん(サイバーエージェント) の『パフォーマンスから考えるSass/Compassの導入・運用』のスライドなどを公開します。
Sassについてのセッション担当の石本です。
Sass+Compassは非常に高機能なCSSプリプロセッサーですが、だからといってその機能すべて使用・理解しようとすると大変なので、あくまで問題を解決するツールとして考え、必要になったら(なにか問題に直面したら)使用・勉強するといったスタンスで向き合っていけば良いと思います。事実、私も使ってない機能はいっぱいあります。
また、今回のイベントでSassが主流かのような印象を持たれた方も多いと思います。だからといってSassさえ出来てればよいのかというとそうでもないように思えます。時が立てば、またLessが盛り返してくるかもしれないし、全く別のあたらしいCSSに関する技術が出てくるかもしれません。そういった時に、食わず嫌いせずにどんどんそれらを取り込む姿勢(それが黒い画面を使うものだとしても)が今後重要だと考えます。
変化に対応できる柔軟な人材が求めらているなと感じたイベントでした。講演者としても大変勉強になった一日でした。ありがとうございました。
以下、フォローです。
スライドで紹介した、CSS Spriteのmixinの詳細な解説です。
パフォーマンスからみるSass/Compass 第2回:CompassによるCSS Sprite | MOL
私が作成したmixinはRetina対応した独自のものなので、普通にCSS Spriteする分にはもっと簡単に使えます。
スプライト画像のレイアウトに関しては$icon-layoutで変更可能です。
Sprite layouts | Compass Documentation
StyleDoccoの詳しい使い方に関しては下記を参考にしてください。
CSSプリプロセッサでスタイルガイド - inkdesign
「styleDocco」の導入とgrunt.jsでの自動化のメモ | Mnemoniqs Web Designer Blog
StyleDocco自体のスタイルは変更できるのか?
個人的には要望は出しているのですが、今のところできないようです。
Ruby製の別のスタイルガイドKSSではできますが、StyleDoccoよりも導入の敷居は高いです。
2013年4月21日(日)、 札幌パークホテル B2F パークプラザで CSS Nite in SAPPORO, Vol.9「いま必要なSEO」 を開催し、140名ほどの方にご参加いただきました。

ツイートは下記にまとめました。
次のブログで取り上げていただきました。ありがとうございます。
こちらは講演者のブログなど: