Webに携わる人なら非エンジニアも知っていて欲しい、HTTPのCookieとSession
前回の記事の続きです。
今回はHTTPのCookie（クッキー）とSession（セッション）について書いてみます。
やっぱりこれも理解していないと様々な弊害があります。
非エンジニアだから関係無いとは言い切れません。
- CookieとSessionがわからないことによる弊害
- もしHTTPにCookieとSessionが無かったら
- Cookieとは？ Sessionとは？
- 広がるCookieの用途、3rd Party Cookie（サードパーティクッキー）
- 最後に
※.前回の記事を理解している前提で書いていきます。
CookieとSessionがわからないことによる弊害
まず、わからないことによってどんな弊害があるか、例をあげてみます。
例というか実は全て私の経験談です。恐ろしー(‘Д’)
- （昔のガラケーのサイトで多い話ですが）URLにSESSIONのIDを書くようなシステムで、SESSION ID付きのURLをメルマガなどで送信してしまう。
結果：下記サイトのセッション乗っ取りと同じ状態です。セキュリティ的な大事故です！
- Sessionに入れるべき会員番号をCookieに入れてしまい、Cookieの書き換えで個人情報が抜けてしまう。
結果：これもセキュリティ的な大事故です。
エンジニアはもちろんWebサイトのセキュリティについて勉強すべきです。 IPAの「安全なWebサイトの作り方」は理解する必要があります。
非エンジニアの方もエンジニアがせっかくセキュリティ対策を行っても、人為的な穴を空けてしまいますので、基本的なことは理解しておく必要があります。
もしHTTPにCookieとSessionが無かったら
セキュリティ的な穴が開く危険性があるのに利用するわけですから、やっぱりCookieとSessionは便利なんです。 GetとPost同様、CookieとSessionもHTTPに定義されているもので、Webサーバとブラウザ間のやりとりの一部として規定されています。
Webは基本的には情報をGetする（取得する）、Postする（送信する）ものですが、状態によって画面の表示を変えたい場合があります。
例えばAmazonような通販サイトでは
- 会員登録をすると「こんにちは〇〇さん」というような個人に合わせた表示をする。
- 会員が過去にチェックした商品を表示する。
- カートに入れた商品情報を表示する。
この時、ユーザを特定するときに使われるのがCookieであり、Sessionです。
これらの説明は「CookieとSessionのおかげで、ステートレス（状態がない）からステートフル（状態を持てる）になる」と一言で言い換えられます。
「ガラケーの時代はWebサイトをステートフルにするのが大変だったなー(‘Д’)」という言い方だと「歴戦の猛者」感を演出できます！
Cookieとは？ Sessionとは？
当たり前の話ですが、Webサーバはたくさんのユーザからのアクセスがある前提で出来ています。
そしてユーザごとに画面表示を変えたい場合どうするか？なのですが、
Webサーバにアクセスがあったブラウザに対してCookieを発行する。そのCookieがユーザに対して一意のIDであればそれはSessionのIDとも言える。
ブラウザが次回以降、そのWebサーバにアクセスする際はサーバから発行されたCookieを含めて通信する。 これによってWebサーバ側ではどのユーザからアクセスがあったかを理解することが出来る。
Webサーバ側でユーザの情報を保持する仕組としてSessionがある。例えばカートに入れた商品の情報やユーザの閲覧履歴など。CookieにSessionのIDが含まれている間はユーザを特定し続けられる。
※.システム構成にSessionの管理方法は大きくことなります。大規模なサイトではSession管理だけで1冊本が書けそうです。
そして注意点としては、
Sessionの情報はあくまでWebサーバ側の情報であってブラウザ側には存在しないものです。ブラウザはCookieの仕組みでSession IDを送信するのみです。
ブラウザがWebサーバにCookieを送信する際は別のサーバで発行されたCookieを送信することはありません。送信してしまうとセキュリティ的な大問題です。
WebサーバがCookieを発行するときに、有効期間を設けられます。Session IDを保持しているCookieに有効期限を付ければ、それはSessionの有効期間となります。
Cookieよりも大きな容量のデータを保持できるWeb Storageというものもあります。
- Session IDをCookieに保存する方法もあれば、URLで送信する方法もあります。これはCookieが使えないガラケーのサイトで良く用いられた方法です。これを用いる際はセッションが乗っ取られないように、セキュリティ的な対策を講じておく必要があります。
広がるCookieの用途、3rd Party Cookie（サードパーティクッキー）
3rd Party Cookieは既に広がって久しいですね。アドテクには必要不可欠なものです。
例えばAmazonで商品を物色して、そのあとYahooニュースでAmazonで見た商品が表示される広告も3rd Party Cookieがあるからこそです。
アドテクの話をすると長くなりそうなので、アドテク以外にも3rd Party Cookieが使われている例を挙げますね。
メディアサイトでFacebookのいいね！やTwitterのフォローが簡単に行える。 これはブラウザにFacebookやTwitterのCookieが保存されていれば、わざわざログイン作業が必要無いということですね。 いいね！したときの動作としては、ブラウザとFacebookのWebサーバ間の通信で、この通信にはメディアサイトのWebサーバは登場しません。
ユーザの行動履歴を取ってマーケティングに活用。 MA（Marketing Automation）で行われていることですが、サイトにユーザをトラッキングするためのタグを貼り、その情報をもとにマーケティング活動（広告の出稿をチューニングしたり、自動でメルマガをしたり、スコアリングして重要な顧客からタッチしたり、いろいろあります）を行います。
3rd Party Cookieはユーザが意図しないところで通信が発生するケースが多いので、セキュリティ的な問題を指摘されることがありますが、もうInternetの世界では必要不可欠になってしまっている技術とも言えます。
最後に
HTTPのGet、Postに始まり、今回はCookieとSessionを説明しました。
非エンジニア向けに簡単な文章にしたつもりですが、簡単に説明するっていうのは本当に難しいですね。 今回のはそんなに難しい技術ではないんですが、、、
そしてなぜ難しいか、理由を考えたんですが、恐らく1個の技術を説明しようとしたときに、前提が多いとか、関連する技術がまた2個、3個と出てくるからかなとも思いました。
挫折する人ってそういうところで挫折するのかなー
Webに携わる人なら非エンジニアも知っていて欲しい、HTTPのGetとPost
Webの仕事をしている人はHTTPのGet、Postは絶対覚えるべきです、エンジニア以外も。
反論は受け付けません。なぜなら弊害があるからです。
HTTPとは？
HTTPというのはHyper Text Transfer Protocolの略になり、Webサーバとブラウザ（ChromeやSafariなど）とのデータフォーマット、通信方法、ルール・手順を定義したものになります。
最後のProtocolというのは規約とか手順といった意味があるので、
「あいつとはコミュニケーションのプロトコルが合わない」
って言っとけばIT業界人っぽく見せることが可能です(´▽｀)
HTTPのデータフォーマット
その中のデータフォーマットでメジャーなのが、みなさんご存知のHTMLになるわけです。
もちろん画像や動画なんかもデータとして認められているので、文字だけじゃなくて綺麗な写真がみえたり、Youtubeで動画が見れたりするわけです。
HTTPの通信方法
そして通信方法の中に今回のテーマのGet、Postが定義されています。 そして通信というのは、Webサーバとお使いのPCやスマホで利用しているブラウザ間の通信を指します。
Getとは？
これは文字通りですが、情報を取得する（ゲッツ！）という意味です。
この時、
- ブラウザがWebサーバに対して目的のURLの情報（www.hogehogehoge,xyz/get.html）を要求する。
- Webサーバがブラウザに対して、要求された情報を送る。
すごく当たり前のように聞こえますね。 そして我々がブラウザでやっている操作のほとんどはGetになります。
大事なのはPostとの違いなので、先に進みます。
Postとは？
Postとはサーバに対して情報を送信することを指します。 ここで気付いたと思いますが、GetやPostの主語はブラウザなどのクライアント側になります。 ブラウザがGetする（情報を取得する）、ブラウザがPostする（情報を送信する）ということです。
Postを使う時の代表的な例として、通販サイトで商品を購入するために、メールアドレスや住所などの個人情報を入力するケースがあります。 もちろんテキストだけでなく、HTTPは動画や画像も扱えますから、最近はそれらを送信することが多いかもしれません。
この時の動きとして、
- 会員情報を入力するための画面（www.hogehogehoge,xyz/post.html）を要求する。
- Webサーバがブラウザに対して、要求された情報を送る。ここまでGetと一緒。
- メールアドレスや住所などを入力して、Webサーバに対して情報を送信する。そのときのURLは1.と同じかもしれないし、違うかもしれないが、URLには入力した情報は含まれない。
- Webサーバ側で受け取った情報をもとに、新たな情報を返却する。入力情報が間違っているかもしれないし成功するかもしれないので、入力内容によって返却内容は異なる。
GetとPostの違い
Getで情報を取得する際に、情報を区別するためのキーは基本的にURLだけです。 そしてWebの特徴であるリンクはURLで情報がユニーク、一意ということでが成立しています。
ですから
“www.hogehogehoge,xyz/a.html”
と
“www.hogehogehoge,xyz/b.html”
で同じ情報を表示されても困りますし、アクセスするたびに違う情報を送信されても困ります。
当たり前ですけど、ちゃんとルールがあるから気軽にリンクが張れるわけです。
一方Postは、ユーザが入力した情報をもとに画面の情報を切り替えて返却します。ただし、入力情報によってURLが変わるわけではないです。
URLが変わらないのに、表示されている画面が違うとも言えます。
Postのありがちなミスとその弊害
楽天の検索画面を思い出して欲しいのですが、検索条件に商品のカテゴリやブランド、あとフリーのキーワードや送料無料の条件など、いろんな条件が入力できると思います。 それらの条件は確かにユーザが入力するものですが、基本的には情報を取得する、Getする行為なので、Getで書くのが正しいです。
これをユーザが入力するからといって、Postで書いたらどんな弊害があるか？
先に述べた通り、ユーザが入力した情報はURLには含まれませんから
- リンクを友人などに共有しても同じ情報が見れません。
- ブラウザの閲覧履歴というのは基本的にはURLの履歴です。ブラウザの[戻る]ボタンで前の情報を出そうとしてもうまくいきません。使いにくいUIになってしまいます。
- Googleなどのクローラがサイトを巡回しても、URLで一意な情報が作れないわけですから、適切にインデックスを作成できません。つまりSEO対策が出来ていません。
- URLで一意にならないわけですから、どの画面が良く見られているかなどのアクセス解析が出来ません。
結構な弊害がありますよね。Webサービスとしては完全にアウトです。
今ではほとんど見かけなくなりましたが、これを理解していないエンジニアがいることもまた事実です。
なのでエンジニアに発注する側も理解すべきです。
また、Postはブラウザの[戻る]ボタンに弱いことも言及しました。 例えば会員登録などの仕組みは複数画面にわたる場合があり、[戻る]ボタンをユーザが使ってしまうケースがあると思います。 その対策にPRGパターン（Post Redirect Getの略）と手法があります。
これ非エンジニアに理解はつらいんですが、これも見ておくことをお勧めします。
もう一声！
HTTPのCookieとSessionについても書きました。 これもWebに携わる人は理解すべき内容です。
理解すると、むしろ武器になりますので是非ご一読ください！
メディアをビジネスとして理解する一番の近道は「媒体資料」を読みまくること
私が初めてWebメディアの仕事をしたとき、とりあえずメディア事業について学ぼうと試みるのですが、メディアビジネスそのものの情報って意外と少ないんですよね。
メディアを概念的なものとしてではなく、商売としてどう成立させようか考えたときに、一番参考になったのが「媒体資料」です。
媒体資料とは、業界の人には釈迦に説法ですが、主にはそのメディアの各広告の価格表と、購読しているユーザの数・属性について書いているものです。
稲森和夫の言葉に「値決めは経営」という言葉がありますが、その言葉にならうと、「媒体資料をどう定義するかということは、メディア事業の経営そのもの」と言えるかと思います。
この「媒体資料」ですが、Webで公開されているものも多いので、今回はそれを見ていきたいと思います。
※.2017年5月調べ
TechCruchの媒体資料
TechCrunch
まずは私も読者のひとりである、TechCrunch日本版の媒体資料から見ていきます。
IT業界の人間なら一度は見たことがありますよね。海外の事情はSNS経由でTechCrunchをチェックすることも多いと思います。
媒体資料は下記のページからダウンロードできます。
http://advertising.aol.jp/techcrunch/
TechCrunch日本版のユーザ属性
TechCrunchの冒頭に端的にユーザ属性が書いてあります。
- 首都圏に住む、20代～40代の男性ユーザー中心
- 起業意欲が高く、米国と日本の最新IT関連情報を日々チェック
とあります。何となく納得。
そして、媒体資料を見ていて興味深いのは、
- ユーザの役職で経営者・役員クラスの割合が15.2%もある。
- 情報をシェアする方の割合が多い。
とあります。
経営者・役員の方々はソーシャルの世界でもインフルエンサーな場合が多いと思いますので TechCrunchのシェアが回ってくるよなーという私の体感とも一致します。
TechCrunch日本版の広告の価格
比較的メジャーなPCのレクタングルバナー（300×250）の価格だけ抜粋します。
レクタングル（PC）：100万（75万imps想定）2週間
広告の種類としてはPC4種類、SP1種類存在します。ビジネス系なので、あまりSPを重要視していないのかな。
意外に思ったのがネイティブアドが無いんですよね。
で、TechCrunch本体の方を見るとやっぱりネイティブアドありました。
ネイティブアドも含めて日本版にない広告もいろいろありそうです。
ただし、残念ながら価格まではわかりません。
https://techcrunch.com/advertise/
これは私の考察ですが、TechCruchは世界で通用する技術やサービスの情報がベースだと思われるので、日本で閉じた内容の記事広告というのは、TechCrunch日本版を見ている読者の期待と合わない、だから日本版ではネイティブアドが無いのかと想像しています。
AppBankの媒体資料
APP BANK
スマホアプリ・ゲームとかガジェット系がメインのメディアです。
現代らしいメディアですよね。
下記ページから「【AppBank】2017年4-6月媒体資料」の媒体資料がダウンロードできます。 http://www.appbank.net/2009/10/26/iphone-news/59019.php
AppBankのユーザ属性
月間1,200万UUのモンスターサイトですね！
メインユーザーは20・30代の若手サラリーマンのようで、男性が78%と偏ってますね。 携帯ゲームのコンテンツが多いのですが、やっぱり男性の方が攻略方法を調べるところから、この男女の偏りは来るのかな？とも思いました。 ガジェットのコンテンツもありますし、男に偏るのは納得です。
Twitterのフォロワー数も26万超えていて、Facebookの6倍近くあります。
これは若い人が多いからFacebookよりTwitterの方が圧倒的に多いよなーという考察もできますし、TwitterはFacebookよりは匿名性が高いのでゲームというジャンル上、相性がいいのかなとも思います。
AppBankの記事広告の価格
- ネイティブ広告（SP）：15万（600万imps想定、1週間）
- インリード動画広告（SP）：30万（100万imps想定、1週間）
広告資料を見ていると携帯ゲームがメインの媒体だけあって、スマホの広告が充実しています。
動画広告もゲームには相性がいいかもしれません。
ELLE ONLINE日本版の媒体資料
もともと紙から発生した歴史のあるファッションメディアです。
メディア事業は海外の方が10年進んでいるという考え方があります。 日本の出版社の場合、紙媒体からWeb媒体を作るのって苦手なイメージがありますが、ELLE自体は元々海外のメディアですから、やっぱり上手ですよねー。
下記ページから「エル・オンライン媒体資料 2017.03-06 ver1.0」の媒体資料がダウンロードできます。
http://www.hearst.co.jp/brands/elle/media_kit_digital
ELLE ONLINE日本版のユーザ属性
- ユーザの平均年齢は32.9歳。
- 約7割が未婚の女性。
- 3割が東京在住のユーザ。
- 6割以上が有職者。
私はELLEのユーザでは無いので、ふーん( ´_ゝ｀)って感じなんですけど、うがった見方をしちゃうと、6割以上が有職者→有職者が7割以下だと仮定すると、既婚でも有職者の方もいらっしゃいますから、未婚なのに働く必要が無い人がいるぞ！と嗅ぎつけちゃいました。
ちなみにショッピングエリアのランキングがあり「1位：銀座、2位：表参道、3位：渋谷・新宿」です。
男性誌の場合は購買力を表現するために、媒体資料にユーザの年収分布を入れているのをたまに見かけますが、ELLEの場合はショッピングエリアで表現出来ていますね。 お金の匂いがプンプンです！
ELLE ONLINE日本版の記事広告の価格
プレミアムジャック広告（1週間、58万imps想定）の640万に溜息が出てしまいますが、 おもしろいのはカテゴリごとに価格が全然違うバナー広告です。
- レクタングル or マウスオンエキスパンド
- ファッション：60万（10万imps想定、1週間）
- ビューティー：60万（10万imps想定、1週間）
- グルメ：45万（15万imps想定、1週間）
- インテリア：8.4万（2.8万imps想定、1週間）
- ウェディング：5万（2.5万imps想定、1週間）
ファッションとビューティーのimps単価が一番高いのがわかります。 単純にELLEに掲載するとファッションやビューティーが売れるというのもあるかもしれませんが、個人的には、業界ごとの予算における広告費の割合、の感じもしないではないです。 私自身はコスメ業界になぜか縁が多いのですが、コスメは他の業界と比べて広告費の割合は大きかったですしね。
まとめ
今回はターゲットもコンテンツも全く違う媒体資料を3つ見ました。
我ながらうっすい考察だなーと思いましたが、to Bだからimp単価が高いとか、ハイファッションだからimp単価が高いとか、そんな単純なものではなく、各媒体ごとにユーザのこと、広告主のことを考えて広告メニューを作っている、というのは伝わってくるかと思います。
あと、デジタルマーケティング的には媒体資料でユーザ属性が詳細にわかるわけですから、その属性にはどんな広告が良いのか、そこも参考になりますよね。
次回はコンテンツくくり、ターゲットくくりで見ていった方が、各社の違いが見えると思うので、もっと深い考察を目指しつつ、当記事は入門編として参考にして頂ければ。
そして、媒体資料を探すのに良いサイトを見つけたので、それも共有しておきます。 media-radar.jp
最後にメディアビジネスを理解するのに一番おすすめの本を記載しておきます。
冒頭の言葉と矛盾するようですが、メディアの仕事をしていて、これを読んでない人は本当に損をしています！
MEDIA MAKERS―社会が動く「影響力」の正体 宣伝会議 https://www.amazon.co.jp/dp/B00AQZLZ2G/
５年後、メディアは稼げるか―Monetize or Die? https://www.amazon.co.jp/dp/B00DZF2HBC/
コミュニケーションコストを下げる、技術・方法論についてのまとめ
私は転職が多いのと、ひとつの会社でもたくさんのプロジェクトに関わることが多かったので、様々な人と様々な現場で仕事をしてきました。
で、やっぱりあるわけですよ、無駄な会議や効率の悪いメールが！
前の記事でも書いたのですが、
コミュニケーションはコスト
会議も成果物が必要
だと考えています。
私は人一倍人見知りで合理主義なのでやっぱりコミュニケーションコストが気になります。 今回はコミュニケーションコストを下げ、成果物を効率的にアウトプットするための技術、方法論についてまとめてみようと思います。
ロジカルシンキング：建設的で論理的な議論の入り口
頭のいい人って教えられなくても、たぶんこれ出来ていると思います。
私が初めて「ロジカルシンキング」という考え方に出会ったのは、その当時在籍していた会社が行かせてくれた、セミナーだったと思います。 たしかトーマツのセミナーだったかな。
そう、私が学んだのはコンサル由来の「ロジカルシンキング」です。
Wikipediaを見るとそれ以外の意味もあるらしいのですが、ここではコンサル由来の「ロジカルシンキング」に限定します。 そしてロジカルシンキングについて詳しく語るのは有用な本にお任せして、「ロジカルシンキング」の触りだけ紹介します。
演繹法（えんえきほう）：「AだからXである」
これは結論を導き出すための方法論です。議論が収束しないときに、いろんな条件、前提をもって結論を導きだします。 議論が収束しないということは、実際はこんなにシンプルではなくて、事象が複雑な場合が多いので、実際使うときは「Aもあるし、Bという状況もあるし、Cが足りないし、だからXにしよう」という言い方になるかもしれません。
「こんなの当たり前じゃないか！」と思われる方は恐らく最初から演繹法が身についています。説明責任をしっかり果たす人は好きです。
しかし、議論において自分の主観だけを語り、要因の説明が乏しい人も残念ながら存在します。 どちらかと言うと、このテクニックは議論にならない人を説得する場合に使えるかもしれません。
「Xという結論にもっていきたいので、A、B、Cという材料で肉付けする」
こちらがXという結論を出すためにA,B,Cとい要因を説明しているわけですから、相手も自分の希望を通すためには説明責任が発生します。
三段論法に近いというか、ほぼ三段論法ですね。
三段論法のプロと言えば弁護士さんです。
弁護士の裁判もクライアントの希望ありきで戦うわけですからね。
ロジカルシンキングはそのほかにも帰納法、ロジックツリー、MECEなどなどの方法論があります。
ぜひ書籍を読んでみることをお勧めします。
クリティカルシンキング：目的に立ち返る
ロジカルな人が集まれば議論が収束するかというと、そう簡単にいかないこと多いですよね。 むしろ頭がいい分、いろんな粗が見えてしまって、批判だらけになってしまうケースは多いと思います。
「クリティカルシンキング」は「ロジカルシンキング」を前提としていて、考え方が近い部分も多いんですが、大きな違いとしてクリティカルシンキングは「目的に立ち返る、その目的を達成するための課題を設定する」ための考え方になります。
「そもそも達成したいのは〇〇ですよね、△△の課題の方が重要で■■のご指摘は大きな問題ではないのでは？」
細かい粗探しに終始するようなケースで、こんな風に言えれば議論が収束すると思います。
クリティカルシンキングもビジネスマンには覚えて欲しい重要な技術だと思います。
ぜひ書籍を読んでみることをお勧めします。
ファシリテーション
「ロジカルシンキング」や「クリティカルシンキング」は考え方の技術だとすれば「ファシリテーション」は会議の技術そのものです。
ファシリテーションでは「ファシリテーター」という会議の段取りを行う人を設定します。 この段取りが非常に重要で、会議が始まる前の準備からファシリテーションは定義しています。
会議の前の段取り
- 会議の議題・目的を設定する。→クリティカルシンキングが生きてきます！
- 議題を議論するのに必要な情報を集める。→ロジカルシンキングの演繹法そのものですね！
- 会議のタイムテーブルを決める。→時間内に結論を出すようになります。
- 会議の参加者を設定する。→発言する必要のない人は参加する必要がありません。
この段取りがしっかり出来ていれば議論は発散しにくくなります。 もちろんファシリテーションは会議中のことも定義していますが、それは有用な本にお任せします。
あなたがもしチームのリーダーであればこの「ファシリテーション」の技術は非常に役に立つはずです。
ぜひ書籍を読んでみることをお勧めします。
最後に
ここまでコミュニケーションを下げる技術を取り上げましたが、一番下げる方法があります！ それはコミュニケーションを取らない、合意形成さえ取らないという方法です。
“許可を求めるな、謝罪せよ”
許可というか合意を取る作業というのは結構大変です。 しかも私が属しているIT業界の仕事というのは複雑で巨大なものも多いわけで、全ての作業について合意を取るのはそもそも無理があると思います。
何かあったときにお客さんに多大な迷惑がかかるようなことは合意を取るべきですが、目的から外れていなければ、作っちゃって問題があったら謝る、というスタンスは全然アリです。 これはコミュニケーションの技術というより、実行力の方が重要になりますが、実行力のある方ならきっと上司の信頼も得ているでしょう。
コミュニケーションコストを下げて、どんどん作っちゃいましょう！
紙からWebのデザインを始めるデザイナーさんに知っておいて欲しいこと
今までたくさんのWebデザイナーさんと一緒に仕事をしてきましたが、中には紙のデザインしか経験が無い・Webデザインの経験が薄い方もいました。 その経験をもとに、ノンデザイナーの私が偉そうに書いてみますね！
- Webは紙と違い、デバイスが複数あることを認識する
- Webはクリックされて始めて見られる
- コーダーの仕事、HTML・CSSを理解する
- Webは更新できる
- 広告のサイズを頭に入れておく
- 納品物がいろいろある
- 見る・読むのは人間だけではない
- Webはすぐ参考にできる、マネできる
- Webは計測できる！
- Web業界、IT業界のコミュニケーションを理解する
- 最後に
Webは紙と違い、デバイスが複数あることを認識する
WebはPC、スマートフォン、タブレットという形で複数のデバイスで表示することが前提です。 なので紙で言う台割にあたるワイヤーフレームもPC、スマートフォンで2種類作るケースが多いわけです。 これはたぶん頭ではわかっているとは思いますが、実際にどんなところに影響してくるかというと、
- 各デバイスのデザインで画像の縦横比はなるべく揃える
これをやっておかないと、画像の加工の手間が半端なく増えます。 もちろんクリエイティブに拘るサイトは手間をかても良いと思いますが、 どんどんコンテンツを増やしていくようなサイトだと運用の手間も増えてしまいます。
- 今の時代の主流はスマホ、「スマホファースト」
BtoBのサイトは除外しますが、スマートフォンの流入の方が多いサイトが主流となっています。 Googleの検索数も2015年にはスマートフォンがPCを上回っています。
Yahoo Japanは「スマホファースト」を数年前にうたい、今では業界の常識となっています。 でも我々は普段PCで仕事をしますから、この常識を忘れてしまうことが多々あります。 実際、PCのワイヤーフレームから書き始めてそれをスマートフォンにした際に、要素が多くなりすぎて入りきらない、ゴミゴミしてしまうことがまだ見受けられますよね。
Webはクリックされて始めて見られる
書店に置いてある雑誌はお客さんが手に取って見てくれますし、電車の中吊り広告もたくさんの通勤者に見てもらえますし、会社案内のパンフレットは営業が配ってくれます。
ただしWebの場合は
Googleの検索をクリックする。
Facebook、Twitterのシェアをクリックする。
広告文、バナーをクリックする。
だいたいこのクリックを経由して始めてサイトが見られるわけです。
また紙であれば、その紙媒体を買った人はページをめくってくれることを期待できますが、サイトに来た人にいろんなページを見てもらうには、やはりクリックしてもらわなければいけません。
何が言いたいかというと、クリエイティブのこだわりがこのクリックと喧嘩しちゃダメってことです。 「格好良い！」けど「わかりにくい」ナビゲーションやUIを作ってしまうとクリックを促がせない、サイトを回遊させられません。
コーダーの仕事、HTML・CSSを理解する
まさかIllustratorでデザインを渡しているデザイナーはいませんよね！？ まさかレイヤーがぐちゃぐちゃなまま渡してないですよね！？ これはどんな仕事でもそうですが、チームの他メンバーの仕事を理解していないと良い仕事は出来ません。
そしてデザイナーのデザインをWebの形にするのがコーダーです。デザインを構造化してコードにするとも言い換えられます。
これは見出しなのか、小見出しなのか、ナビゲーションなのか、コーダーが一目でわからないデザインはユーザにとっても優しくありませんし。 私がデザイナーさんを探すときにも、これかなり重要視しています。
Webは更新できる
これは本当大きいですよね。 コンテンツの量も無限大に足すことができますし。 更新出来るメリットとして他には、例えば納期がもし厳しい場合、フェーズ１のデザイン、フェーズ２のデザインみたいな形で分割して納品することも可能です。
あとサイトを作ったら終わりではなく、むしろ始まりという考え方なんですよね。 デザインも更新出来る前提が求められます。
広告のサイズを頭に入れておく
サイトによっては広告エリアを設けるサイトがあると思います。また広告を出稿してサイトに集客する場合もあると思います。 どちらの場合でもこの広告のサイズにならってサイトをデザインしておくと運用が楽になります。 広告はたくさんのクリエイティブを作ってパフォーマンスを上げていくものですからね。
あと、この広告のサイズには名前が付いていて「レクタングル」とか「スカイクレイパー」とか言えるようになると、ちょっと格好良くなれます。 ぜひ「おれ、わかってる感」を演出してください。
納品物がいろいろある
どんなものがあるかというと、
サイトのデザインデータはpsd形式で。
ピクトグラムなどはsvg形式で。
PCサイトのfavicon、スマホのアイコン
FacebookやTwitterのアイコン、カバー写真。
などなど。これ、頼んでもないのに納品してくれるデザイナーさんは惚れちゃいます。
見る・読むのは人間だけではない
紙媒体を見るのはほぼ人間ですが、Webの場合はクローラもサイトを見ます。Googleで検索したときに該当するページを結果として返すことが出来るのはこのクローラがサイトを巡回しているからです。
そしてこのクローラと人間の大きな違いは画像に対する認識です。クローラは画像を理解する力がどうしても人間よりも弱いわけです。 SEO対策という言葉を聞いたことがあると思いますが、言い換えるとクローラにサイトを理解しやすくするということです。
例えばファッション雑誌の場合はタイトルと写真だけで成立するものが、Webの場合はクローラが画像の認識が弱いため、説明するための文章が必要になります。
誰かの言葉を借りて私はよく「Webは紙より説明的に」という話をしますが、その理由のひとつにこのクローラの存在があります。 SEO対策的にクリエイティブがNGということもありますので、そのときはディレクターやマーケッターと相談してデザインを作ると良いと思います。 クリエイティブのためにSEOを捨てて良いというサイトはほとんどないですからね。
私もSEOの仕事をしていて、たまに意見が割れることがあるので「デザインとSEO」については深堀したいなーと思うところです。 アンカーリンクのテキストは英語の方が格好良いけど、SEO的には日本語の方が良いことが多いよーとか、h1はなるべく上にもっていきたいよーとか、デザインに絡むことって結構あるんですよね。
Webはすぐ参考にできる、マネできる
もちろん紙でもマネが出来ると思いますが、Webはこのコストがすごく低いです。 競合のチェック、デザインの方向性の詰め、サイトの構成、すぐ参考に出来ます。
「僕らのターゲットはこんな属性だけど、競合がこんなテイストだから、我々はこのテイストでいこうか。」
みたいな伝えるのが難しいことが、PCでいろんなWebサイト見ながら会話が成立します。 これ、当たり前みたいに聞こえるかもしれませんが、デザインのディレクションで出来ている人は意外と少ないです。
Webは計測できる！
Webの良いところとしてWebは計測出来るという大きなメリットがあります。
やはり結果が数字として出てくるのはモチベーションんにつながります。
Webのアクセス解析と言えばGoogle Analyticsがデファクトスタンダードですが、ぜひ基本的な使い方を覚えていただきたいです。
例えばどんなシチュエーションがあるかと言うと、
- 直帰率の高いページがデザインの力で低くなった！
- バナーのCTRが倍になって広告の流入が増えた！
これ、感動しますよ！「より多くのターゲットの心が掴めた」ってことですから。
Web業界、IT業界のコミュニケーションを理解する
それなりの規模のサイトを作るとなると、スキルの異なるメンバー間でコミュニケーションが多数発生します。そしてこのコミュニケーションはコストという考え方をします。
コミュニケーションコストについては当記事でも書いています。
そのコストをなるべく減らすためにBacklogやRedmineなどのタスク管理ツールや、チャットワークやSlackなどのチャットツールが存在し、チームの中でルールを決めてそのツールを使います。 それも効率的に良い成果物をアウトプットするためです
会議の考え方も異なります。会議も成果物をOutputする場として考え、無意味な定例会議みたいなものを嫌います。 意思決定、成果物の定義、設計のFixなどなど、これらは非常に大事な成果物です。 そのせいか、他の業界と比べてIT業界は会議の技術であるファシリテーションやロジカルシンキングを理解している人が多いと思います。
あと心に留めた方がよいことは、
会議中の内職、チャットが結構許される。
電話嫌いが多い。
メールの件名がわかりにくい、メールが検索しにくい人はキレられる。
「さん」付けが結構許される。お客様に対しても。
こんなところでしょうか。礼儀よりも合理性を重視する文化だと思えば理解しやすいと思います。
最後に
ここまで読んでて、もしかしたら「Webは表現の制約が多いなー」とか「ルールが多くて覚えるのが面倒だなー」と感じたかもしれません。
ただ一方でインターネットがなぜここまで普及したかというと、情報を流通するコストがすごく低い、伝えやすいわけでです。
デザインも人に見られてナンボです。 ぜひこの制約を武器に変えていただけたらと思います。
あとこの文章を書いていて思ったのは、これはデザインをレビューしてもらう際にレビュアーにも知っておいて欲しいことだなと思いました。レビューアーは経営陣だったり、営業さんだったりWebを知らない人も多いですからね。
編集さん向けにも書きました！
