画像：pixabay

Paypay、LINE Pay、楽天Pay、Origamiなど「なんちゃらPay」が毎日のようにニュースで取り上げられてる今日この頃。
みなさんは使っていますか？

最近よく目にする「なんちゃらPay」の多くはスマホでのQRコード決済が多く、NHKの記事ではQRコード決済が急速に普及している背景として以下のように書かれています。

クレジットカードや電子マネーのように店側がコストのかかる読み取り装置を導入する必要がないので、小規模な商店や、屋台、観光地の人力車、球場でのビール販売といった場面でも活用できるのが特徴だ。

これ以外にも各社がQRコード決済に参入し拡大を目指す理由として「購買データの取得」「自社サービスの囲い込み」「他金融サービスへの入り口に」といった点が挙げられています。

利用する側としてはキャンペーンを行っている今、ポイントがもらえることもあって話題になっていますが、このままQRコード決済が主流となるかどうかは未知数です。
決済手段は他にも多数あり今後も新たなサービスが出てくると思います。今現在どんな決済手段があって今後どんな決済手段が出てくるのか、整理しておいてもいいかもしれません。

ビジネス特集 どれ選べばいい？乱立する○○Ｐａｙ | NHKニュース

決済を基礎から解説、7種類のオンライン決済と6種類のオフライン決済 誰でもわかるフィンテック｜ビジネス+IT

画像：pixabay

経済産業省が策定したキャッシュレス・ビジョンにおいて、2025年に向けてキャッシュレス決済比率を40%まで引き上げる目標をかかげています。
キャッシュレス決済にはSuicaやWAONなどの電子マネーやクレジットカード、スマホ決済などがあります。

QRコードを使ったスマホ決済ではAmazon Pay・楽天ペイ・LINE Pay・Origami Pay・WeChat Pay・Alipayなどがありますが、2018年10月にソフトバンクとヤフーの合弁会社として「PayPay（ペイペイ）」がスマホ決済に参入しました。

そのPayPayが12月4日から「100億円あげちゃう」キャンペーンを開始しました。
PayPayでの支払いでPayPayボーナスとして20%還元されるキャンペーンです。

「100億円」にインパクトがあったり、キャンペーンの内容が分かりづらかったり、初日からサービスが利用しづらい状況になったりなど、何かと話題になっていますがテレビでも特集が組まれたりしているので、キャッシュレス決済に興味を持つユーザーも増えているようです。

元記事では、ギャンブルにも見えるキャンペーンであっても広告の視点から考えると手堅い取り組みである、と書かれています。以下引用します。

実は、ネット広告の視点から裏を見ると、案外手堅い取り組みということもできるので、ご紹介しておきたいと思います。
ポイントは3つあります。
■決済アプリは利用までのハードルが非常に高い
■100億円宣言にはPRと財務リスク低減のダブルの効果
■ユーザー獲得と加盟店舗獲得の相乗効果

「このキャンペーン、なんか裏があるんじゃないの？」と個人的に思っていましたが、ビジネスで考えるととても納得するおもしろい記事でした。
キャッシュレス決済が進んでいない日本で、ユーザーと加盟店を早く多く獲得し、来年以降業界の主導権を握るのはどこになるのでしょうか？気になります。

ちなみにPayPayを店舗で導入する場合、現在は初期導入費・決済手数料・入金手数料はすべて無料ですが、入金手数料は2019年10月1日以降有償化の可能性があり、決済手数料は3年間無料・のちに有償化する場合があるそうです。

ペイペイ「100億円あげちゃうキャンペーン」には、どんな裏があるのか(徳力基彦) – 個人 – Yahoo!ニュース

スマホ決済を導入検討されている店舗様へ　PayPayなら0円で導入いただけます | PayPay株式会社

前回記事では、レスポンシブWebデザイン制作フェーズで課題となりがちな「表示速度の改善」のポイントをまとめました。
今回は、レスポンシブWebデザインにおける画像の扱いについてご紹介していきます。

画像の取扱い

高解像度ディスプレイが次々登場する中において、レスポンシブWebデザインでの画像の取扱いはとても悩ましい問題です。

レスポンシブWebデザインにおける画像の課題と問題

まず取り組まないといけない課題として、次の2つがあります。

• 高解像度ディスプレイへの対応
• アートディレクション

1つ目は分かりやすいですね。今や2倍だけでなく3倍、4倍のディスプレイも登場しています。 このような高解像度ディスプレイで解像度1倍用の画像を表示させた場合、画質が荒れてしまいます。 ユーザの環境によって異なるこれらにどのように対応すべきか、という課題です。

2つ目は主に写真画像の「トリミング」のお話です。大きなディスプレイ用に作成した写真を、小さなディスプレイでそのまま縮小表示させた状態で、果たしてコンテンツとして良いのかという課題です。
ディスプレイの大きさに合わせて最適にトリミングさせた写真を提供すべきでは、ということですね。

そして上記の課題に対応した結果、発生する問題が2つあります。

• 表示速度の低下
• 画像作成の負荷が高くなる

実際の対応方法

実際の対応方法としてどういったものがあるのか整理した表が次です。

大きな画像1つを使用する

多くのサイトで採用されているのが、1つ目の「大きい画像1つを全ディスプレイサイズで使用する」方法だと思います。

もともと大きなサイズを使用し、それを小さなディスプレイでも表示させることから、小さな高解像度ディスプレイでは画質がさほど気にならなくなります。
そして作成する画像が1つで済むということから、最も手軽にレスポンシブWebデザインに対応する方法ですが、不必要に大きな画像をモバイルで読み込むシーンが増えるため、表示速度への影響が大きくなります。

CSSやJSで複数の画像を出し分ける

1つ目と併用する形で採用されるのが、CSSで複数の画像を出し分ける方法です。

最も簡単なのは、デスクトップサイズ用の画像とモバイルサイズ用の画像を用意し、それらの表示／非表示をCSSで切り替えるやり方になります。しかしこれは見た目上隠しているだけで、モバイルでもデスクトップサイズ用の画像は読み込まれており、表示速度に影響します。

同じCSSでも、画像を背景画像として配置するやり方があります。この場合、メディアクエリで切り分けをしモバイルファーストの書き方で記述すれば、モバイルサイズではモバイルサイズ用の画像のみが読み込まれることになるため、上記に比べてエコです。

ただ、何でもかんでも背景画像にしてよいわけではありません。アクセシビリティを考えれば、コンテンツとして画像要素であるものは<img>として掲載されるべきだからです。

そして何より、画像の作成数が複数倍になり、HTMLやCSSの記述量も増えるため、初期構築・運用の負荷が全体的に増えることは間違いありません。

新しい方法：レスポンシブイメージ

比較的新しい手法に、HTML5で実装された<picture>要素と<img>要素のsrcset属性を使う「レスポンシブイメージ」があります。
このレスポンシブイメージは、高解像度対応とアートディレクションを解決し、表示速度に負荷を掛けない方法として、今後採用される場面が増えていくと思われます。

同じ内容で解像度が異なる画像を表示する場合は、<img>のsrcset属性を使う

<img src="/assets/img/img768.jpg" srcset="/assets/img/img768.jpg 768w,/assets/img/img1680.jpg 1680w" alt="">

異なる内容の（アートディレクションされた）画像を表示する場合は<picture>要素を使う

<picture>
　<source media="(min-width: 768px)" srcset="/assets/img/img1680.jpg">
　<img src="/assets/img/img768.jpg" alt="">
</picture>

ただしこの方法も、画像の多重管理は避けられません。むしろ「より良い形」を求める場合は避けてはいけないところなのでしょう。
さらに言うと、高解像度の画像を作るということは、高解像度の画像素材が必要になるということなので、撮影した場合はそのデータの取扱いも難しくなりますし、素材を購入する場合は高額になります。

何が正解ということではなく、さまざまな手法を知り、適したものを都度選ぶことが大切なのではと思います。

まとめ

この記事では、レスポンシブWebデザインについて「ある程度技術的なガイドラインになるもの」を目指し、弊社で採用している制作技術のポイントをご紹介しました。
実際の案件において、みなさまの指標の一つにしていただけると幸いです。

前回記事では、レスポンシブWebデザインを採用したプロジェクトの進行に関してディレクションのポイントを2つご紹介しました。

ここからはより具体的に、制作フェーズで課題となりがちな「表示速度の改善」と「画像の取扱い」について、技術的なガイドラインとなるものをご紹介したいと思います。

CSSの書き順もモバイルファーストで

先ほどモバイルファーストとデスクトップファーストの進め方について触れましたが、実はCSSにも「モバイルファースト」な書き方と「デスクトップファースト」な書き方があります。 レスポンシブWebデザインにおいて両者がどのように影響するか見てみましょう。

CSSの書き順による負荷の違い

簡単なサンプルとして、スクリーンサイズによって<h1>の文字色が変わるスタイルを作ってみます。 デスクトップファースト、モバイルファーストそれぞれの違いに注目してください。

まず、デスクトップファーストな書き方はこちら。

/* スクリーンサイズが480px以上のときは青 */
h1 {
  color: blue;
}
/* スクリーンサイズが480pxより小さいときは赤 */
@media screen and (max-width:479px) {
  h1 {
    color: red;
  }
}

そしてこちらがモバイルファーストな書き方です。

/* スクリーンサイズが480pxより小さいときは赤 */
h1 {
  color: red;
}
/* スクリーンサイズが480px以上のときは青 */
@media screen and (min-width:480px) {
  h1 {
    color: blue;
  }
}

表示結果はどちらも変わらないものの、480pxより小さいスクリーンサイズで表示した際のスタイルの当たり方が異なります。

• デスクトップファースト … 最初に適用された青を打ち消して赤を適用する
• モバイルファースト … 赤を適用する（青は480px以上のときにはじめて適用）

つまり前者は小さいスクリーンサイズにおいて、「スタイルを打ち消す」という余分な処理をするため効率が悪いのです。

通常、画面サイズが大きくなるにつれてレイアウトが複雑になったりデザイン要素が増えたりし、それに伴ってスタイルも増えていきます。 その際デスクトップファーストで記述すると、小さいスクリーンサイズに不要なスタイルや画像を余分にたくさん読み込むことになり、CSSの処理負荷を高めてしまいます。そのためスクリーンサイズの小さいものから順にスタイルを適用するモバイルファーストな書き方が適しています。

弊社ではプロジェクトの進め方自体はデスクトップファーストでも、マークアップの段階でモバイルファーストに切り替えて制作を進めています。

メディアクエリのスタイルはブレイクポイントごとにまとめる

ブレイクポイントごとのスタイル指定を別ファイルに分ける方法もありますが、CSSファイルはなるべく1つにまとめることを推奨します。 これは、次章で紹介する表示速度の改善と関係してきます。

CSSファイルを1つにした場合、その中で同じメディアクエリが何度も登場するケースがありますが、これらをブレイクポイントごとにまとめると、ファイルサイズの肥大化を防ぐことができ、軽量化につながります。

とは言え1つの要素に関するスタイルが離れた位置に書かれているとマークアップの作業効率が悪いので、弊社ではタスクランナー（Gulpなど）を使って完成形のCSSファイルでのみメディアクエリがまとまるようにしています。

表示速度の改善策いろいろ

上のCSSの書き方以外にも、表示速度を改善する対策は多数あります。 次の表は私たちが標準的に実施を検討する項目ですが、中でも「必須」とした項目は効果が大きめなのでぜひ取り入れてみてください。

アプローチ1：サーバへの通信回数を減らす

私たちはWebサイトを閲覧するとき、表示に必要なファイルを必要な数だけサーバへリクエストしています。
この回数をなるべく減らすように制作することが表示速度の改善に繋がります。

まとめられるものはまとめてファイルの数を減らす

CSS、JSといった外部ファイルは、必要以上に分けずまとめられるものは1ファイルにまとめます。 LPなど1ページで完結するものなら、そもそもこれらを外部ファイル化しない選択肢もあります。

CSSスプライトを使うと、画像も1枚にまとめることができます。
CSSスプライトとは、複数の画像を1枚にしたファイルを作り、CSSで「見せる範囲」を指定してWebサイト上に表示させる技術です。アイコンやボタンなど、汎用的なものに使うのが向いています。（最近ではアイコンをWebフォント化し、ボタンには画像を使用しないため、CSSスプライトを使う案件が減りましたが、この方法も効果が大きいです）

ローカルキャッシュを有効にする

サーバ側でできる対策の一つがローカルキャッシュをコントロールすることです。

ユーザが表示したページのデータが個々のブラウザに「キャッシュ」として保存され、再度同じページを表示するときにはそのキャッシュを利用します。こうすることで都度サーバからデータを取得する必要がなく、通信回数を減らすことができます。

これを実現するには、キャッシュの有効期限の設定が必要となります。
Apacheサーバなら.htaccessで設定が可能です。

<IfModule mod_expires.c>
ExpiresActive on

  # デフォルトのキャッシュ期限を1週間に
  ExpiresDefault                                "access plus 1 month"

  # ファイルの種類ごとに個別で期間を設定する
  ExpiresByType text/html                       "access plus 0 seconds"
  ExpiresByType text/css                        "access plus 1 year"
  ExpiresByType text/javascript                 "access plus 1 year

</IfModule>

※mod_expiresモジュールを使用します。
※上記は一例です。HTML, CSS, JS 以外にもファイルのMIMEタイプごとに指定ができるので、環境に合わせて設定してください。

参考）Apache モジュール mod_expires

ローカルキャッシュを使うときに注意したいのは、キャッシュの有効期限を待たずにファイルを更新した場合、以前のキャッシュが使われてすぐに更新が確認できないことです。

これを回避するため、CSSやJSの読み込み時はファイル名に更新の都度異なるパラメータを付けるようにしておきます。
毎回手作業で行うとミスが出るので、PHPなどでファイルの更新日時を自動取得し、パラメータとして付与するようにしておくと効率的です。

アプローチ2：サーバへの通信量を減らす

アプローチ1ではサーバへリクエストする「回数」に着目しましたが、次は一度のリクエストにかかる「通信量」を見ていきます。
通信量を減らす＝各ファイルのサイズをいかに圧縮するか？を考える作業です。

ファイルを圧縮する

圧縮方法はファイルの種類ごとにいろいろあります。大きく分けると次の3種類のツールが選択肢に挙がるのではないでしょうか。無料のツールも数多くありますので、合うものを探してみましょう。

• 方法1）圧縮ソフトをインストールする
• 方法2）Webサービスを使う
• 方法3）タスクランナーを導入する

圧縮方法：HTML、CSS、JSの場合

HTMLやCSS、JSのようなテキストで構成されるファイルであれば、改行やインデントを詰めて1行にすること（「ミニファイ（minify）」と呼びます）で圧縮します。 そもそも不要なコードを残さないこともファイルサイズ削減への第一歩です。

とは言え、マークアップ時にミニファイされた状態で作業することはもちろん現実的ではありません。
人が見やすいように改行やインデントの入った状態で制作をし、公開前に先述したツールを使ってミニファイされたものをサーバへアップロードします。
ただこれも都度人力で実行するのは手間で、忘れてしまうことがあるかもしれません。

そこで、これらの作業を自動化できる「タスクランナー」が重宝されています。
弊社ではGulpを使用し、CSSのミニファイに加え、前項で紹介したメディアクエリのまとめも合わせて処理しています。

圧縮方法：画像の場合

画像ファイルはその形式によって、メタデータと呼ばれるGPSの位置情報や日付データが含まれていることがあります。
このようなビジュアルとして見えない情報を削除したり、視認できない範囲で色数を減らしたりすることでファイルサイズを減らす作業が画像の圧縮です。

やりすぎると劣化してしまうので、仕上がりの画質を確認しながら条件に合う方法を選んでください。

サーバ側でも圧縮をかける

サーバの機能を使って圧縮する方法として「gzip圧縮」があります。
ここまではアップロード前のファイルを圧縮するという考え方でしたが、gzip圧縮はサーバ側で圧縮をかけたデータを転送するという方法です。

これも、Apacheサーバなら.htaccessで設定できます。
サーバ側にかえって負荷をかけてしまっては本末転倒なので、圧縮してほしいファイルの種類をあらかじめ指定しておきましょう。

<IfModule mod_deflate.c>
  <IfModule mod_filter.c>
    # 圧縮するMIMEタイプの指定
    AddOutputFilterByType DEFLATE "application/javascript" \
                                  "text/css" \
                                  "text/html" \
  </IfModule>
</IfModule>

# SVGをgzip圧縮した「svgz」の表示設定
<IfModule mod_mime.c>
  AddEncoding gzip                svgz
</IfModule>

※mod_deflateモジュールを使用します。 ※上記は一例です。

参考）Apache モジュール mod_deflate

アプローチ3：レンダリングの速度を低下させない

ブラウザはHTMLのソースを上から順に読み込みます。また、並行して読み込めるファイルの数には制限があります。

JSファイルを<head>内で読み込むと、JSの読み込みが始まった時点でそれ以降、つまり実際にページの要素として表示される<body>部分のレンダリングが止まり、結果表示が遅く感じられる可能性があるため、JSは</body>直前に読み込むのが主流です。

一方計測用のコードなど、中には<head>内での読み込みを必須としているJSもあります。
この場合は<script>タグの属性async、deferを使うことで、レンダリングを遅らせることなく処理を実行できます。

※ <head>内必須ではないものでも、スライダーなど見た目を整形するようなJSだと、読み込みが後回しになることで表示崩れが起きることもあります。優先順位をつけて選択しましょう。

(2)では、レスポンシブWebデザイン制作フェーズで課題となりがちな「表示速度の改善」のポイントをまとめました。
次回(3)では「画像の取扱い」について技術的なガイドラインとなるものをご紹介したいと思います。

今回、寄稿のお話をいただいた際の最初の切り口は「レスポンシブWebデザインについては検索してもさまざまなことが書いてあり、表示速度などを考えるとどれが正解か分からないから、ある程度技術的なガイドラインになるものがあるといい」ということでした。 ヒアリングを続けると、それは技術的な問題ではなく要件整理の段階で検討しておくことだな、というお話も多くありました。

そこで企画を2回に分け、「レスポンシブWebデザインを採用するにあたっての準備」として前回の記事『「レスポンシブWebデザインで行こう！」の、その前に』を書かせていただきました。
技術だけでは成功しない要素がたくさんあるので、本記事の前にぜひ前編もご覧ください。

本編はその2つ目となる「ある程度技術的なガイドラインになるもの」を目指します。
いざ着手してみると「情報が多くて何をどこまでやったらいいのか分からない」となりがちなレスポンシブWebデザインについて、制作の現場はどう対応しているのか、ディレクションと制作技術のポイントをご紹介します。「この辺りが標準的な対応かな」という判断の指標にしていただけると嬉しいです。

まずは、ディレクション（進め方）で押さえておきたいポイントを2つご紹介します。

「対応デバイス／ブラウザ」の決め方

前回の記事でも触れましたが、レスポンシブWebデザインは、あらゆるスクリーンサイズで一定の優れたUXを提供するために汎用化する技術です。
「どのサイズでも見られる」ように作る方法なので、きちんと「対応デバイス／ブラウザ」を定義しておかないと、あらゆるデバイス／ブラウザが対象になってしまうことになります。

よくある例が、

• スマホとPCの対応でいいと言われた（思っていた）が、タブレットの対応も必要で、予算もスケジュールも厳しい状況になった
• 「うちの子がゲーム機でサイトをみたらメニューが開かなかったよ」と言われて頭を抱えた

などです。

さらに、「対応デバイス／ブラウザ」を決めるだけでは十分ではありません。「メジャーなデバイスに対応」と言っても、全てを実機で確認することは（専用サービスを利用しない場合は）できないからです。 「特定のデバイスで表示が変だ」と報告があっても、そのデバイスが手元にないと再現ができないため、修正することは困難です。

「仕様上の対応デバイス／ブラウザ」と「検証するデバイス／ブラウザ」を定義する

このような状況でもプロジェクトメンバー間に認識のズレが出ないよう、私たちは「仕様上の対応デバイス／ブラウザ」と「検証するデバイス／ブラウザ」の2つを定義するようにしています。

仕様上の対応デバイス／ブラウザ

「仕様上の対応デバイス／ブラウザ」は、Web標準で定められた仕様に沿っていれば、問題なく表示・動作するであろうと思われるデバイス／ブラウザを指します。

案件では、アクセス解析を元にターゲットとするものが「仕様上の対応デバイス／ブラウザ」になります。特殊な環境・仕様でなければ対応できます、という範囲ですね。

検証するデバイス／ブラウザ

「検証するデバイス／ブラウザ」は、実際に表示と動作を検証するデバイスとブラウザです。多くの場合、制作チームまたは個人が所有するデバイスが検証機になります。時にそれは実機ではなくエミュレーターの場合もあります。

弊社ではAndroidの所有率が低いので、Androidの確認にはエミュレーターを指定します。IEの場合も、IE10以下は各種ツールを使って検証をすると定義します。

そして大事なのは、「検証するデバイス／ブラウザ」での表示・動作が問題なければ、試験（テスト）はクリアとする、という合否ラインを共有することです。
もちろん定義されたもの以外で何か症状があり、それを再現できる場合は可能な限り対応をしますが、その優先度は低く、次のステップに進むことを止めるものではないという扱いになります。

モバイルファースト／デスクトップファースト

レスポンシブWebデザインでの制作時に、モバイルを基準にコンテンツや操作性を設計する方法を「モバイルファースト」、デスクトップを基準にする方法を「デスクトップファースト」と表すことがあります。

モバイルファーストを意識する

モバイルファーストでは、小さな画面の中でいかに重要なメッセージを伝え、分かりやすいステップで操作に支障なく手続きを完了してもらえるかということを重視して設計するため、レスポンシブWebデザインで課題となりがちな、モバイル閲覧時の次のような症状を回避することができます。

• コンテンツ分量がモバイルで見るには多すぎる（精査がされていない）
• どこを押せば目的のページに行けるか分からない（遷移設計がモバイルに合っていない）

また、設計の流れのままモバイルサイズのデザインを先行させると、デザインがモバイルに合っていない（見にくい）といったことも起こりません。

デスクトップサイズはスクリーンが広いため、思いつく限りの情報を詰め込みがちです。情報量が多いことは良いことのように思えますが、整理されていない情報はユーザーを混乱させる可能性も高く、たとえデスクトップで閲覧しても「分かりにくい」かもしれません。

このように、モバイルファーストの考え方はデスクトップでの見やすさや操作性を犠牲にするものではなく、Webサイト全体の質を高める重要な考え方だと言えます。

必ずしもモバイルサイズから設計しなくてもいい

モバイルファーストの考え方をダイレクトに制作工程に反映した場合、モバイルサイズで作成した設計やデザインをデスクトップサイズに展開するフローになります。
このアプローチは制作工程として理にかなっていますが、プロジェクトメンバー間での合意形成が難しいため、特に関係者が多いと進行が止まりがちです。

「モバイルファースト＝モバイルサイズから設計しなければいけない」という考え方もありますが、デスクトップサイズから設計しても、並行してモバイルでの見え方・操作性を意識していれば、モバイルファーストの考え方を取り入れることはできるもの。そのため私たちは必ずしもモバイルサイズから設計しなくてもいいというスタンスで取り組んでいます。

なお、デスクトップサイズから設計する際は、次の点に注意するとより安心です。

• ナビゲーションを設計する際は、デスクトップサイズとモバイルサイズを並行して作成・レビューする
• ワイヤーフレームは、モバイルで実寸操作できるものを用意する（モバイルサイズ版は、ナビゲーション部分を含む数画面を作成）
• コンテンツエリアは、グリッド構造（ブロックを積み上げてレイアウトを構成する仕組み）を意識して要素の配置を決める

ここまでは、プロジェクトの進行に関してディレクションのポイントを2つご紹介しました。
曖昧になりがちな「対応デバイス／ブラウザ」の定義の仕方や、結果として表示速度にも影響する「モバイルファースト」の取り入れ方について、参考にしていだけたら嬉しいです。

次回以降、より具体的に、制作フェーズで課題となりがちな「表示速度の改善」と「画像の取扱い」について、技術的なガイドラインとなるものをご紹介したいと思います。

前回記事(2)では、レスポンシブWebデザインへの誤解やレスポンシブWebデザイン以外でのサイト構築の方法について解説しました。
今回は、レスポンシブWebデザイン導入にあたって事前に精査しておきたいポイントについてまとめていきます。

レスポンシブWebデザイン導入要件

ここからはより具体的に、レスポンシブWebデザインの導入に当たって事前に精査したいポイントをまとめます。

投資としてコストパフォーマンスが悪かったり、システムによって選択できなかったりする場合もあるため、これらをプロジェクトの始動時に検討すると、手戻りによる時間やコスト（人的を含む）の無駄遣いを防ぐことができます。

予算とスケジュール

前回記事(2)では、レスポンシブWebデザインの導入では「初期・運用ともに工期・コストを抑えられる」と書きましたが、それはあくまでも「レスポンシブWebデザイン」「アダプティブWebデザイン」「動的配信」の3つの方法を比較した場合のことです。

これまで、PC向けサイトとモバイル向けサイトを別々で用意したときは、それぞれのサイト構築は別のタイミング（同時プロジェクトでも少しずらして）で進行したと思います。
またモバイル向けサイトはPC向けよりコンテンツを削ったかもしれません。
それぞれは完全に独立していて、別の制作会社や別のチームで対応することもできました。

レスポンシブWebデザインで構築する場合は、全てを同時並行で進める必要があります。
それも、PC向け／モバイル向けの2種類ではなくあらゆるスクリーンサイズに対応するため、デザイナーや開発者は一般的ではないサイズであってもデザインの一貫性が保たれるように、実装しながら試行錯誤を繰り返していきます。

当然、チェックする量も増えます。
そのため、過去のサイト制作よりも工期と予算がかかることを想定しておきましょう。

モバイル向けにフォーカスする

たとえば「新規サービスで具体的なターゲットのデータはないが、明らかにPCを持たない世代に向けたもの。まだこれからなので多重管理は避けたい」といった場合は、対応するスクリーンサイズを減らし、モバイル向けにフォーカスすることで工数を抑えるのも一つの手です。

極端に言うと、スマートフォンではコンテンツが見やすくボタンの配置もわかりやすいが、PCではテキストが横に間延びして読みにくく、ボタンが画面の端にあるため押しにくい、といった状態です。

この例のように、モバイルでの使い勝手に予算を集中投下するといった判断も、ターゲットユーザーを把握していれば可能になります。

ターゲットユーザーと利用シーン

事業を複数持っている企業のコーポレートサイトはたくさんのターゲットユーザーが想定されます。

このように、ステークホルダーが多ければ多いほど、レスポンシブWebデザインに向いています。
なぜなら、多種多様なスクリーンサイズでアクセスされるからです。

このような場合は、すべてのユーザーに一定の優れたUXを提供することがサイトホルダーとしてのおもてなしであり、ひいてはその企業の姿勢を示すことになります。

ターゲットが絞られる場合／利用シーンが異なる場合

上記の「予算とスケジュール」で触れましたが、ユーザーの90％がスマートフォンなど、明らかにユーザーの偏りがあれば、そのスクリーンサイズで最も快適に閲覧できるように作ることを検討すべきです。

特にBtoCサービスを提供するサイトの場合、ターゲットユーザーが限定されることがあります。

管理の多重化を許容できるなら、既存のPC向けサイトはそのままに、モバイル向けサイトをアダプティブWebデザインで最適化する方法もありますし、PCとモバイルでユーザーの利用シーンが全く異なるなら、モバイルアプリを開発するという選択肢もあるでしょう。

モバイルファースト

繰り返しになりますが、レスポンシブWebデザインは、あらゆるスクリーンサイズで一定の優れたUXを提供するために汎用化する技術です。この「UX」にはコンテンツも含まれます。

レスポンシブWebデザインのデメリットとして、モバイル閲覧時の表示の遅さが挙げられますが、この大きな要因の一つが、旧来の「デスクトップから考える」という進め方にあります。

デスクトップはスクリーンが広いため、思いつく限りの情報を掲載することができ、見通しのいいメニューから深い階層に誘導することも難しくありません。
旧来のように画像での装飾にこだわることもできます。

PCサイトからサイトの設計・コンテンツの精査を始めてしまうと、いざモバイル向けのサイトにしたときに以下のような問題が出てくることがあります。

• コンテンツ分量がモバイルで見るには多すぎる（精査がされていない）
• どこを押せば目的のページに行けるか分からない（遷移設計がモバイルに合っていない）
• デザインがごちゃごちゃして見にくい（デザインがモバイルに合っていない）
• ごちゃごちゃをモバイルでは隠したけど表示が遅い（不要な要素をロードしていることに変わりはない）

といったことになり、モバイルユーザーを思って改修したのに、モバイルユーザーに不快感を与える結果になってしまいます。

これらの症状を回避するため、モバイルファースト（モバイル向けサイトから設計・コンテンツを考える）が推奨されますが、それが難しいとしても、常にモバイルでの見え方・操作を念頭に入れながら、並行して設計をしていくという考え方が必要です。

もしプロジェクトメンバーに「PC向けサイトのデザインをすぐ出して」という人がいたら、まずは、今から取り組もうとしていることはどういうことなのかを納得してもらってからスタートすることをお勧めします。

コンテンツ内容

少し制作寄りな話になりますが、レスポンシブWebデザインは「グリッド」と呼ばれるブロックを積み上げてレイアウトを構成し、そのブロックの積み方をスクリーンサイズに応じて可変させることで、あらゆるスクリーンサイズに対応します。

よって、一つのブロックの中身が非常に細かい場合、別の言い方をするとページ内のコンテンツがブロックに分解できないような内容を扱うサイトは、レスポンシブWebデザインに向いていません。

おそらくその場合は現状、PCでの閲覧が主だと思われるので、現在のPC向けサイトはそのままに、別のコンテンツ内容でモバイル向けサイトを作成する、アダプティブWebデザインが候補になります。

ECカートやCMSなどのシステムの仕様

ECシステムのショッピングカート

ASP型のECシステムでショッピングカートがレスポンシブWebデザインに対応しているサービスはまだまだ少ない状況です。むしろ、対応しているサービスの方が限られていると言った方がいいでしょう。

また、対応済みとしているサービスも実際には不完全な場合があるので、注意が必要です。
さらに、ECシステムの仕組み自体は対応していても、そのシステムを組み込むベンダーが不慣れなことも散見されます。

ASP型のECシステムの対応が遅れていることから、フルスクラッチでオリジナル開発したり、オープンソースをカスタマイズしたりすることも選択肢になりますが、プログラミングとUIを同時に担当できるベンダーは少なく、実際には分離して進められることが多いと思います。

この場合、デザイン会社から提供されたHTMLをシステム会社が組み込むフローになるのですが、相互の連携やUIへの対応不足により、表示速度の遅さやレイアウトの崩れ、ボタン等のタッチアクションの反応悪化、といった不具合がよく起こります。

これらを避けるには、開発に強いUI会社を選択するか、開発とUIデザインを橋渡しする会社（人物）を別途アサインするかを検討したほうがいいです。
ECサイトにレスポンシブWebデザインを適用する場合、このベンダー選択が重要な要素になります。

CMS

あまり多くはありませんが、CMSでも対応していないものがあります。
具体的に言うと、システムで管理しているテンプレートがPC用とモバイル用で分かれていて、振り分けを解除できない場合はレスポンシブWebデザインを実装することができません。

WordPressやMovableType等の一般的なものであれば気にする必要はありませんが、現在使っているCMSが特殊な場合は、事前の確認が必須です。

運用体制と運用予算

「レスポンシブWebデザインの優位性」として「二重（多重）管理を避けられる」点を挙げました。すべてのスクリーンサイズに対してテンプレートとなるHTMLは1つなので、共通部分の変更は一回で済みます。

ここで注意したいのは、そのHTMLは「レスポンシブWebデザインで制作されたHTML」だという点です。レスポンシブWebデザインはこれまでの制作技術と多くの部分で異なるため、HTML構造を変更する場合は、その技術への知識が必要です。

HTMLは1つでも、すべてをサイトオーナー側で管理することは難しいということを前提に運用体制を組み、運用予算を想定しておきましょう。
また同時に、事前に運用要件（担当者、リテラシーレベル、更新頻度、更新範囲、承認フローなど）を洗い出し、CMSの機能や範囲を適切に定めることと、プロの手を借りる範囲を決めておくことも重要です。

まとめ

この記事では、最近特に依頼が多くなったレスポンシブWebデザインでの構築について、それ以外の選択肢を踏まえつつ、採用する上での注意点をご紹介しました。
本記事がウェブ担当者のみなさまの「転ばぬ先の杖」となれば幸いです。

次回はより具体的に、レスポンシブWebデザインでの構築技術について、弊社が導入している方法をご紹介します。

前回記事(1)では、レスポンシブWebデザインで実装となる動機について考えました。
今回は、レスポンシブWebデザインへの誤解やレスポンシブWebデザイン以外でのサイト構築の方法について解説します。

レスポンシブWebデザインへの誤解

スマートフォンの急速な普及により、制作現場ではさまざまな課題が発生しました。
これを解決する手法としてはレスポンシブWebデザインが注目されるようになり、さらに前回記事(1)で説明したMFIへの移行が拍車をかけ、昨今ではレスポンシブWebデザイン一択のような潮流になってきました。

私たちはそこに少しばかり誤解が生じているのではと感じています。

というのも、レスポンシブWebデザインに期待される効果の中には、直接関係のないものや、レスポンシブWebデザイン以外の方法が合っている場合もあるからです。

MFIやSEOは直接関係がない

MFIは、「グーグル検索のために、モバイル版Googlebotがクロールしたページの情報を使う」ということ。
つまりモバイル向けサイトの評価を上げることが大事なのであって、レスポンシブWebデザインだからどう、ということではありません。

SEOについても、競合他社との相対的な評価でランクが変わるのであって、それが動的テンプレートの切り替え表示であっても、同一URLでありモバイル向けサイトが充実していれば自社の評価は変わらないはずです。

もちろん、「今PC向けサイトしかないが、モバイルでのアクセスがかなりある」という状態で、これからモバイル向けサイトを作ろうというタイミングであれば、MFIやSEOを考慮してレスポンシブWebデザインが選択肢に上がる、というのは大いにあると思います。

レスポンシブWebデザインはデバイスに最適化していない

レスポンシブWebデザインは「どのデバイス（端末・機種）でも見られる」と表現されることがありますが、これは語弊で、正しくは「どのサイズでも見られる」ように作ることができる手法です。
またデバイスに対して「最適化」するのではなく、どのサイズにも対応できるよう「汎用化」させる技術です。

本質的なデバイスへの最適化（さらに進めてユーザーへの最適化）が必要な場合は、他の方法を検討すべきです。

レスポンシブWebデザイン以外の方法

Googleは、MFI移行後も「動的配信」と「別々のURL」の構成をサポートするとしていますが、これから新規に構築／リニューアルする場合は「別々のURL」での構築は選ばないと思いますので、ここでは選択肢に入れずに進めます。

「同一URLでPC向け／モバイル向けサイトを実現する」主な方法に次の3つがあります。

（ここでの）アダプティブWebデザインとは

「アダプティブWebデザイン」という用語は実にいろいろな用途に使用されているため、一概に定義することができないのですが、ここでは【デバイスごとのHTMLとCSSを主にJavaScriptで切り替えて表示する手法】とします。

アダプティブWebデザインは、各種デバイスやユーザーのコンテクストに応じて、最適なコンテンツを最適なレイアウトで提供することで、デバイスへの最適化（さらに進めてユーザーへの最適化）ができる方法として、『amazon (amazon.com)』や『apple (apple.com)』 がいち早く採用したことで話題となりました。

また、アダプティブWebデザインはデバイスに対し必要なデータのみが送られるため軽量・高速です。

一番のハードルは、デバイスやコンテクストごとのレイアウトやコンテンツを設計・実装するため、初期構築も運用もかなりの負荷がかかりコストが高くなることです。

動的配信

動的配信は、レスポンシブWebデザイン・アダプティブWebデザインと違い、バックエンドのエンジニアリングも必要なため、法人の企業サイトレベルになってくると初期構築・運用共に負荷が大きくコストがかかります。

またフルサイズへ対応することや、タブレットを含む複数のデバイスに最適化することも現実的ではないので優位性は低いですが、PCとスマホのみの切り分けでよく、かつそれぞれに必要なコンテンツが異なる場合は選択肢に上がるかもしれません。

レスポンシブWebデザインの優位性

この3つを比較したときの、レスポンシブWebデザインの優位性は次の3つです。

他の2つに比べて初期・運用ともに工期・コストを抑えられる

リニューアル（新規構築）で、動的配信を選ぶ特別な理由がない場合は、レスポンシブWebデザインを選ぶべきだと思います。
アダプティブWebデザインでの新規構築は膨大な時間とコストがかかるうえ、ターゲットデバイスも定まらないので、「すべてのユーザーが一定の優れたUXを得られる」方法が合っています。

二重（多重）管理を避けられる

アダプティブWebデザインも動的配信も、二重（多重）管理が基本です。
更新頻度が高いなど、運用する上でこの点が課題になる場合は、レスポンシブWebデザインを選びましょう。

将来出る新しいデバイス（のサイズ）に対応できる

これはレスポンシブWebデザインが「汎用化」する技術だからこそのメリットです。

次回(3)では、レスポンシブWebデザイン導入要件についてのポイントを解説します。

私たちグランフェアズは、まだあまり一般的ではなかった2012年から、レスポンシブWebデザインでのサイト／システム構築をサービス提供してきました。

当時はこちらからご提案することが多かったのですが、ここ数年は「レスポンシブWebデザインで実装したい」とご要望をいただくことがほとんどです。
しかしながら、ご依頼いただいたサイトがレスポンシブWebデザインに向いていないこともあり、その場合は他の方法をおすすめするようにしています。

この記事では、「レスポンシブWebデザイン、思うようにプロジェクトが進まない…！」とならないための判断ポイントを、私たちが経験した事例を交えてご紹介します。

まずは、「レスポンシブWebデザインで実装したい」となる動機から考えましょう。

なぜレスポンシブWebデザインなのか

レスポンシブWebデザインが注目された理由は、大きく分けて2つあると思います。

閲覧デバイスの多様化

1つは、スマートフォンをはじめとする、閲覧デバイスの多様化です。

モバイル端末の普及により、インターネットの利用にパソコンを使わない人が増え、家電製品やゲーム機、ウェアラブル端末など、複数のデバイスを使ってアクセスすることが今や珍しくありません。
スマートフォン一つとってもそのスクリーンサイズは数えきれないほどのパターンになり、スマートフォンなのかタブレットなのか区別ができないものもあります。

引用：Android Fragmentation Report August 2015 – OpenSignal

従来のような、特定の幅（デバイス）のみに合わせたサイトでは、ユーザーに見にくさや操作のしにくさを与えてしまうため、多くのスクリーンサイズに対応できる作り方が求められるようになりました。

モバイルファーストインデックス（MFI）

2つ目は、モバイルファーストインデックス（MFI）の発表です。

2018年3月にGoogleは、モバイルファーストインデックスへ移行するという公式発表をしました。
これにより今後はモバイル向けページがインデックスの対象になっていく、つまりモバイル向けページの評価に基づいてランキングが決定されていくことになります。

MFIの大きなポイントは、モバイルを優先するということです。

みんながスマートフォンやタブレットでインターネットへアクセスする時間が多くなることが予想されるので、それに対してGoogleが対応するということなのですが、その大事な部分（モバイルでの閲覧環境の向上）を考慮せず、単純に検索結果の上位表示のためにレスポンシブWebデザインを導入しようとすることが多いように思います。

管理するファイルの数が減る恩恵も加えて、簡単に書くと次のような動機でしょうか。

• 全てのデバイスに対応できる
• 検索順位が上がる・下がらない
• 運用・更新が楽になる

ここで大事なのは、これらは全て正しいけれど、正しくないということです。

次回(2)では、レスポンシブWebデザインへの誤解やレスポンシブWebデザイン以外の方法について解説します。

この記事では、昨秋発表になったAdobe製品の最新情報についてご紹介します。普段みなさんが使っているアプリは、たとえばPhotoshopやIllustratorなど、ごく一部かもしれません（現に筆者もすべてのアプリを使っているわけではありません）。しかしながら、Adobe社に代表されるアプリベンダーの動向を追うことは、私たち制作がこれからどうクリエイティブの進化と向き合っていくのかを考える上でも意義のあることです。

Adobe最新アップデートからクリエイターの未来を占う

前半では（１）生まれ変わった Adobe Lightroom CC、（２）Dimension CCの登場について説明いたしました。

（３）ついに正式リリース Adobe XD

Web制作者として最も大きなトピックは、ついに正式版リリースとして本格始動した「XD」の発表でした。

新しいWebサイトやアプリを制作する方には、非常に力強い味方になることでしょう。このXDをご存知のない方は、まずはこちらをご覧ください。こちらは、スマートフォンで閲覧すことを想定したダミーサイトです。

AdobeXD:プロトタイプ埋め込みデータ

クリック（タップ）すると、次のページへ遷移することがわかると思います。XDでは、「プロトタイプビュー」というモードを使って、ページやオブジェクト単位でのリンクを直感的に設定できます。

こういった動きや画面遷移については、従来はコーディングをしないと実現不可能でしたが、XDをはじめとしたプロトタイピングツールの出現により、ここ数年は特に、「使ってみながら改修していく」という、アジャイル型の開発手法に注目が集まっています。

ディレクター、デザイナー、エンジニアが協業するためには、コミュニケーションのためのツールが欠かせません。XDは積極的にアップデートされており、たとえばWeb制作におけるコミュニケーションツールのひとつとなり得る「デザインスペック」と呼ばれる機能を公開しています。

「デザインスペック」では、コード化に必要な情報（カラーやテキスト、オブジェクト同士の距離など）が集約されているURLを発行できるため、Web制作に必要な仕様を書き出すことなくエンジニアに情報を渡すことができます。

xd.adobe.com/spec/f8082b54-7ab3-489a-bba3-02a766555f79
AdobeIDをお持ちの方は、上記URLへアクセスの上、ログインしてみてください。

アプリの習得コストが非常に低いのもXDの特徴です。IllustratorやPhotoshopよりもツールが絞られており、初心者の方にも扱いやすいと感じます。PowerPointを扱えるレベルのリテラシーの方であれば、基本的なワイヤーフレーム程度ならすぐに作成できることでしょう。

URLベースだけではなく、もちろんpdfや各種画像フォーマットにも対応しているので、これまでの仕事上のコミュニケーションを損なうことなく、さらに柔軟なやり取りを模索できます。ご自分がデザインされない方であっても、外注の方へ指示を出す際などに使用してみてください。

“Adobe Sensei”はどこにいる？

2017年はAIがもてはやされた年でした。第三次AIブームと言われる背景には、データの取得が安易になったこと（ビッグデータ）が指摘されています。インターネットで繋がったCreativeCloudはまさにビッグデータを活用するにふさわしい舞台だと言えるでしょう。

そのAdobe社のAIこそ、”Adobe Sensei”なのですが、特定のアプリとしてわかりやすく私たちの目の前にあるわけではありません。

そのため、Adobe Senseiの恩恵を強く実感する機会が少ないのかもしれない、というのが筆者の実感です。

しかしながら、同時に「いつの間にか便利になっている」というアップデートが多いのも事実。先日のPhotoshopに搭載された「被写体を選択」という機能も、単純なピクセル同士の色情報の差分だけではなく、Adobe Senseiが被写体を解釈・解析した結果なのだそうです。
また、AdobeStockの類似画像を検索は、抽象的な色・形のイメージを探し出すのに絶大な効力を発揮します。

（詳しい手順などは著者が一昨年公開した記事Photoshopユーザーが使って感じたCCのお役立ち機能をご紹介！2017リリースはどう進化した？を御覧ください。）

ボイスアシストや自動運転など、AIの活用で私たちの生活は便利になりつつあります。一方で、AIが私たちの仕事を奪うのではないかという危惧があることもまた事実です。

しかしながら、Adobe社のAIに対する考え方は、”AIはクリエイターのクリエイティビティを広げていく”というもの。あくまで主役は我々クリエイターなのです。クリエイティビティに関係の無い部分、たとえば先程あげた選択範囲の作成や、画像の検索など、繰り返しのつまらない作業はAIにゆだね、人間にしかできない本来の仕事にしっかり集中すべきだと、Adobe Senseiは諭してくれているのかもしれません。

この記事では、昨秋発表になったAdobe製品の最新情報についてご紹介します。普段みなさんが使っているアプリは、たとえばPhotoshopやIllustratorなど、ごく一部かもしれません（現に筆者もすべてのアプリを使っているわけではありません）。しかしながら、Adobe社に代表されるアプリベンダーの動向を追うことは、私たち制作がこれからどうクリエイティブの進化と向き合っていくのかを考える上でも意義のあることです。

Adobe最新アップデートからクリエイターの未来を占う

2017年秋のAdobeのアップデートは「全方位アップデート」をコンセプトに、Creative Cloudの主要なアプリケーションがほとんどアップデートされたことで話題となりました。その中から新登場を遂げた3つのアプリについてご紹介しましょう。

▼Adobe MAX 2017: Day 1 General Session
youtu.be/E_l1rQHHpjc

（１）生まれ変わった Adobe Lightroom CC

Lightroom（ライトルーム）という写真管理・現像アプリをご存知でしょうか？10年以上の歴史があるので、活用している方も多く、写真を扱う方に人気の高い製品なのですが、昨秋のアップデートで「Lightroom CC」が”誕生”しました。10年以上の歴史があるのに、”誕生”？と思われるかもしれません。

▼Lightroom CC
www.adobe.com/jp/products/photoshop-lightroom.html

実はこの「Lightroom CC」は従来製品のアップデートではなく、ゼロから開発された「まったく新しいLightroom」なのです。

もっとも注目すべきは、クラウドベースでの管理が可能でオンライン連携が可能である、という点です。「Lightroom CC」はPCはもちろん、手元のデバイスでも閲覧が可能です。AdobeIDでクラウド管理されている写真をさまざまなデバイスで呼び出したり、保存したりすることが可能になります。

LightroomCCの単体プランには、なんと1TBのストレージがついています。膨大になりがちな写真データの管理やバックアップにも最適ですね。

また、こうした写真の管理には話題のAdobe Senseiを活用した自動タグ付け機能が活躍します（現状はまだ日本語への対応が不十分な部分もありますが）。テーマごとにアルバムを作ることなどには非常に役立つでしょう。

このアプリからは、クリエイティブは今後デバイスの壁を越えて、シームレスになっていくという「未来」が読み取れます。誰でも・どこでも写真を撮影できるようになった今日、その写真のクリエイティブも、PCで椅子に座ってじっくり行うとは限りません。より手軽に、より早く、よりキレイに仕上げるためのテクノロジーが、この「Lightroom CC」には詰まっているのです。

従来の Lightroomは、「Lightroom Classic CC」という名称になりました。今秋以降のアップデートでは、ハイアマチュア?プロが愛用するアプリとして、より精細なチューニングがなされています。

▼Lightroom CCとLightroom Classic CCの機能比較
www.adobe.com/jp/products/photoshop-lightroom-classic/lightroom-cc-vs-lightroom-classic.html

（２）Dimension CCの登場

Dimension（ディメンション）CCというアプリが初登場しました。2016年のAdobe MAX 2016で「Project Felix」として発表されたアプリですが、「Dimension」と名称を変えての正式リリースとなりました。
Dimension CCは、平面を専門とするグラフィックデザイナーでも、3Dモデルを簡単に扱え、製品モックアップのイメージを手軽に作ることが可能なアプリです。

イチからモデリングする必要はありません。

ここでは、コスメのチューブのモデルを作ってみましょう。DimensionCCを起動した上で、素材のサービスサイトであるAdobeStockから「3D」を選び、”tube”や”Bottle”と検索すると、イメージに近いモデルがすぐに見つかります。

しかし、色などは当然違いますので、ダウンロードして、色を変更します。
DimensionCCでは、色や、光沢感（たとえば、テカリのあるツルツルな肌理なのか、マットな風合いなのか）などを簡単に変更可能です。ベースの色と形を決めたら、PhotoshopやIllustratorで作ったロゴやイメージをCreative Cloudライブラリに登録しておいて、ドラッグ＆ドロップで適用します。

作った3Dデータのpsd化なども簡単に可能です。

Web担当者の皆さんの中には、こういったプロダクト系のお仕事を任されている方もいらっしゃると思います（筆者はWeb担時代そうでした…）。プロダクト系の入稿用データは、あらかじめ着色してある容器に対してロゴ部分だけを印刷するケースが多く、実際の商品イメージと入稿データの見た目がかけ離れている場合も多くあります。そのような場合にこういったアプリがあれば、実際の見た目を簡単にシミュレートできるので、上司やクライアントとのコミュニケーションが取りやすいですね。

3D系のアプリは動作が遅い部分もあり、Dimension CCも例外ではありません。そういった点に関しては今後のアップデートに期待したいところです。