レスポンシブ ウェブ デザイン 提案の提案

レスポンシブウェブデザインとかスマートフォン系の記事を書くときにどこのカテゴリに書くか迷ってしまい、そろそろブログのカテゴリ分けの限界を感じてきました。 というか、早くブログを独自ドメインのサーバに移行したい･･･！

ということでさっそく本題ですが、 最近、レスポンシブウェブデザイン（以下、RWDと表記）の案件を2つほどやってみて、思うところがあったので書いてみました。今回は技術的なところというよりも、提案というか、案件の取り方というか、案件の流れについて書きたいと思います。 思いのほか長くなってしまいました･･･。

きっかけ

自分が関わった2つの案件のうち、一つは1ページもののキャンペーンサイト、もう一つは既存のデザインを変えずRWDにするというもの。
サイト構築を行ったわけではありません。
それでも、案件を進めていくうちに、自分のRWDに対する考え方が変わった部分もありましたし、もっとこうすればうまくいくのに、と感じた部分がたくさんありました。記憶の熱いうちに書き留めておかなければと思ったのがきっかけです。

タイトルの内容は一番下にまとまってますので、お急ぎの方はこちらを。

そもそもRWDとは

RWDとは、「Fluid grids」（流動的なグリッド）、「flexible images」（サイズ可変な画像）「media queries」（メディアクエリー）この3点を満たしたものだというのが、自分の頭の中にありました。

ただ、案件をやっている際に自分が感じたのは、RWDを『とりあえず、1つのHTMLがPCで見るとPC用の見た目に、スマホで見るとスマホ用の見た目になってればいいんだ』という考え方の人がいること。

自分はそれに納得が出来なくて、一応社内的には認識してもらえたけれど、お客さんには既にそのような感じで説明している手前、強く補足ができなくて悩みました。

ただ結局は、お客さんが満足すればいいんだ、という考えに到って考えるのをやめました。
自分自身はその考え方には納得していませんが、RWDはあくまで「方法」であり、ワンソースでマルチデバイスに対応するということが「目的」であるなら、「方法」にがんじがらめになって悩むのではなく、「目的」を達成するための「方法」は柔軟に考えていこうよ、という結論に落ち着きました。

本来は「PC用の見た目」「スマートフォン用の見た目」という考えは間違いで、あくまでデバイスのウィンドウサイズによって見た目を切り替えているのですが、以下では便宜的に「PC用の見た目」「スマートフォン用の見た目」等と表記しています。

葛藤1：ワイヤーフレームのチェック

普段、Webページを作るときは、あまりワイヤーを見ることはありませんでした。
ワイヤーの時点で、これは無理だろう･･･というような構成はほとんどないからです。

が、RWDでは別。PC用のワイヤーと、スマートフォン用のワイヤーをしっかり見ないと、
『PCではヘッダーにあるリンク群の一部が、フッターリンクの中に入ってるんだけど･･･』とか、
『気軽な感じで「PCサイトを見る」ボタンが入ってるんだけど』　（この案件RWDだよね？）
『スマートフォン用のワイヤーに、右上に開閉メニューっぽいボタンがあるんだけど』　（さらっとJS書け要求が）
みたいなことに。

ということで、自分で書いていないのなら、ワイヤーはちゃんと見ないとダメです。
1回コーディングしてみる、くらいの心持ちで確認しないと、こういった『実装つまづくポイント』を見落としがちです。
個人的には、ワイヤーができた時点で一回コーディングして、動くワイヤーにしてから、お客さん（だけじゃなくディレクターも）に見せたほうがほうがスムーズにいく気がしました。

葛藤2：デザインとパフォーマンスの間で

「画像を多用すると重くなる」というのはRWDに限ったことではないですが、RWDでは特に気にするべきこととされています。
なぜなら、RWDでは1つのHTMLでPC用の見た目・スマートフォン用の見た目を用意するため、ソースが肥大化しがちだからです。
また、スマートフォンの3G回線はPCのように高速ではないため、ページのファイルサイズを軽くして、表示を高速化することが求められます。（今はLTEがあるのでかなり速度が向上したみたいですが）

ここでは、デザインとパフォーマンスの間で、どっちを取るべきかにとても迷いました。
「画像を使わないほうが軽くなる」ということは理解しているんですが、具体的にどのくらい重くなるのか？がわからない。
「軽ければ軽いほど良い」というのも分かっていますが、「どのくらい速度に影響するのか？」をデザイナーにうまく説明できず、どっちを妥協するか迷いました。
この案件では結局パフォーマンスを妥協しました。

葛藤3：レガシーブラウザでもちゃんと見えるようにね

私は今のところIE8よりも古いブラウザ（主にIE6/7）に対応してくれ、という案件をやったことはありませんが、周りではちらほら聞きます。

1つめの案件に関しては、RWDについてお客さんに説明し、「テキスト情報がちゃんと見えさえすれば、レガシーブラウザで表示が崩れてもいい」というお言葉をもらったので、特に表示に関しては何か言われることはなかったのですが、問題はもう1つの案件。

自分は「メディアクエリーはIE8以下に対応していない」ことをディレクターに伝えたつもりだったのですが、それがうまく伝わっていなかった。

そんなわけで当然お客さん側にもその認識があるわけがなく、コーディングが終わって、確認に出した時点で、IE8で崩れちゃうのは絶対ダメみたいなことを言われて。
正直、そういった要望があるだろうなぁということは、コーディングしていたときから、自分が想定していたことではあったので、respond.jsで対応してどうにかしたのですが。

respond.jsにも限界があるので、何とかごまかしきったところはあります。
このあたりの「RWDしないブラウザでどう見せるのか？」はキチンと認識をあわせないとダメです。

葛藤4：レスポンシブの認識と調整

RWDはワンソースでマルチデバイスに対応する「方法」のひとつであり、ブレークポイントでデザインを切り替えます。
デザインの切り替わるメジャーブレークポイントに注目されがちですが、メジャーブレークポイントに到るまでの過程はどうなっているのか？の考え方に、個人差があるなと感じています。

1つ目の案件は、お客さんが『1つのHTMLがPCで見るとPC用の見た目に、スマホで見るとスマホ用の見た目になるんですよね』という考えだったので、その間の挙動は自分で適当に伸縮させました。

2つ目の案件は、RWDのサイトをかなり見ているお客さんで、PCでブラウザのウィンドウサイズを伸縮させて、動きについて細かく指摘されました。納品直前に『ウィンドウ幅を狭めたときに、この3カラムになっているところを2カラムにするのって時間かかるんですか？』と言われたり。

要件として、「ブレークポイントは一つでいきますよ」と元々決めていて進めていた案件だったのですが、
やっぱり実際に現物を見てみると、ここはカラムが狭すぎるから下に落として欲しい、という要望が出てくるのは当然かなと思いましたし、そこに関してもお客さんと相談して適宜変えていったほうが良いだろうなと感じました。
結局、今回は依頼が急すぎたので対応せずに終わったのですが。

1つ目の案件がそのあたりを握らなくてもすんなりうまくいってたので、同じように進めてしまったのが悪かったです。
こういう点は実際にやって分かることだったのでとても勉強になりました。

葛藤5：RWDで構築する必要あるの？

RWDは基本的に「モバイルファースト」で作るのが一番と言われています。自分自身、最初はなにそれ？という感じでしたが、いろいろな方のお話を聴いたり、実際に案件をやってみたりしてそのメリットがよく分かってきました。

お客さんの要望があって、それを踏まえてRWDでサイトを作るのであれば良いのですが、
周りではRWDありきの提案が多いような気がして、それが一番不安です。
RWDはあくまで「手法」の一つであり、それを前提として持ってくるのはよくないことだと思っています。

RWDの案件です、と話をいただいたのはいいのですが、お客さんから「IE6･7でもちゃんと見えるようにして欲しい」と言われたり、ディレクターからもらったワイヤーが、どう考えてもRWDを考慮されてなかったり。
ディレクターに関しては、社内的な問題なので自分でもフォローしきれるのですが、RWDということで自社から提案したにもかかわらず、お客さんからRWDには向かないような要望が出てくるのであれば、RWDで作るかどうか？から見直すべきだと感じました。
でも、既に「RWDでやるので」と提案しているし、自分にはそれを覆す力もなく。
ここをどうするかが自分の課題です。

---

レスポンシブ ウェブ デザイン 提案の提案

いろいろ書きましたが、以上を踏まえて、自分なりに『RWD提案の提案』リストを作ってみました。

以下、レスポンシブ（ワンソースでPCとスマートフォンサイトを構築）＝RWD、PCとスマホを分ける＝最適化　と表記します。

キャンペーンページを作るのであれば、最適化のほうがいい。

RWDだと、スマートフォンとPC版での構成を大幅に変えることは出来ず、ある程度の制約は出てくるが、最適化で構築した場合はレイアウトは自由。
キャンペーンページはどちらかというと、見た目のデザインに対するクライアントの要望が強いことが多い、というのも理由の一つです。
PCで画像を多用すると、スマートフォンではどうしても重くなってしまいますので。
キャンペーンページのように、ページ数が少なく、更新もほとんどないようなページなら、最適化のほうが満足度が高そうです。

ページの構成が、PCとスマートフォンとで既に決まっている場合は最適化のほうがいい。

上でも言いましたが、RWDは一つのHTMLを使用するので、レイアウト部分の制約があります。
既にお客さんとの間で既に構成が決まっていたり、お客さんから要望が出ていて、それを変えられないのであれば、最適化のほうが柔軟に対応できます。

パフォーマンス重視なら、最適化のほうがいい。

わずかな差かもしれないですが、最適化サイトよりもRWDが遅い、というのは事実です。RWDでも表示を高速化するための努力は出来ますが、それでもやはり「ワンソース」ですので、最適化サイトには適いません。表示速度が何よりも重要なクライアントであれば最適化サイトをすすめましょう。

レガシーブラウザ（IE6・7）でもちゃんと見えるようにするなら最適化に。

レガシーブラウザに対応するなら、最適化サイトのほうがいいと思います。わざわざRWDで苦労してレガシーブラウザに対応するメリットがない気がします。
（個人的にはIE8もレガシーブラウザに含めたいのですが、IE8はまだシェアもありそこまで強く言えないかなと。）

運用のことを考えるなら、RWDのほうがいい。

大規模な構成変更が頻繁に入るような場合だと、そうとも限りませんが、
RWDではHTMLがワンソースですので、ちょっとしたテキストレベルの修正作業の頻度が高いサイトほどRWD向きです。
ただ、CMSなどを使えば、最適化サイトでも更新の手間を減らすことが出来ます。

SEOに有効なのは、どちらかというとRWD。

Googleが推奨している＝SEOに有効と（短絡的に）考えるなら、RWDの方がSEOに有効と言えます。

Googleの見解では「PCとスマートフォンで同じ内容を提供するのであれば、URLは単一が望ましい」とのことなので、それを簡単に実装できるのはRWDです。
ただ、最適化サイトでも、サーバ側で処理をしたり、canonicalを指定すればカバーはできます。
参考文献：
スマートフォン向けサイトにはレスポンシブ・ウェブデザインを推奨、Googleが公開したスマホサイトの最適化 at #SMX Advanced Seattle 2012

個人的には「Googleが推奨しているのは、PCとスマートフォンのURLが一致しているということで、べつにRWDを推奨しているわけではない。」と解釈していたのですが、こちらの記事を見ると明確に「推奨」しているみたいですね。もちろん、「強制」はしていないですが。

RWDではPC/スマホの切り換えが簡単には出来ない

RWDと最適化サイトを混同している人がいるようで、RWDのワイヤーフレームに「PC版」「スマートフォン版」といったボタンやリンクがついていることがありました。
RWDはウィンドウ幅によって強制的にスタイルが切り替わるので、JSなどの別プログラムをかませない限りはPC/スマホの切り替えはできません。
最適化サイトのように、ユーザが見た目を選べないということです。
この点は確認しておいたほうが良いポイントです。

---

このリストを見るとRWDにするメリットが少ないように見えるかもしれませんが、
もっと長い目で将来のことを見ると、RWDはかなりメリットがあるように思います。

デバイスによって個別のページを作ることは、現状は簡単かもしれませんが、将来的にタブレットやスマートフォン以外の端末が出てきたとき、端末専用ページがどんどん増えて、サイト構築がかなり大変になる可能性もあります。

RWDには、やろうと思えばHTML側に修正を加えず、出来る範囲でCSSを調整して、端末のサイズや解像度に合わせて見た目を変えられるという可能性があります。

それを考えると、PCありきでサイトの見た目はそのままにしつつ、「このサイトだと、他のデバイスではこういう感じになりますが、どうでしょうか？」という提案をこちらからしていくのもいいかもしれないと思ってきました。（上のまとめと言ってることが真逆ですが）

もちろんリニューアルをするならモバイルファーストがいいと私は思いますが、今あるサイトは残しつつ、マルチデバイスに対応していくという方法（デスクトップファースト）もあるんだなと。

パフォーマンスという課題は確かに残りますが、『今あるサイトを生かして、できる限りのことをする』というのも、これからのWebサイト制作に対するアプローチとして悪くはないのではと感じました。