サイトを作成する際、WordPressを利用することが主流になってきました。
便利なプラグインも多種開発されています。
よく使うプラグインは気軽に導入しますが、攻撃対象になることもあります。
また、もうちょっと便利に使いたいと思うこともあります。

「Contact form 7」もWordPress用のプラグインです。
ja.wordpress.org/plugins/contact-form-7/
手軽に複数のお問い合わせフォームを設置できるので、使っている方も多いのではないでしょうか。
自分の備忘録も兼ねて、導入後に設定したいポイントをまとめます。

迷惑メール対策

「Contact form 7」はメジャーなプラグインなので迷惑メールの対象として狙われやすく、海外からの迷惑メールが大量に届くこともあります。
迷惑メールは手動ではなくBotと呼ばれるプログラムで送信されています。なので、Bot対策として「reCAPTCHA」を設定します。

画像：Google reCAPTCHA

reCAPTCHAとは

▼reCAPTCHA|出典: フリー百科事典『ウィキペディア（Wikipedia）』
ja.wikipedia.org/wiki/ReCAPTCHA

フォームからメールを送信するときに、ゆがんだ英文の画像が表示されることありますよね。
「表示されている文字を入力してください」とパスワードのように入力します。
Botでは判読できない文字を利用して、人間かBotかを区別する仕組みです。

現在は「reCAPTCHA v3」と呼ばれるシステムで、複雑な文字を入力しなくても人間かBotかを自動で判別しています。

reCAPTCHA機能の設定

reCAPTCHA機能は、Googoleのサイトから「サイトキー」と「シークレットキー」を取得し、自身のWordpressに設定します。
キーを取得したら、コピー＆貼り付けで簡単に設定できます。

1. Googleにログインし、reCAPTCHAのページを開く
   www.google.com/recaptcha/about/
2. 「v3 Admin Console」から新しいサイトを登録
3. サイトキー、シークレットキーを取得
4. WordPressのダッシュボードから「お問い合わせ＞インテグレーション」を開く
5. 「reCAPTCHA」からインテグレーションをセットアップ

解説はこちら
▼reCAPTCHA (v3)｜Contact Form 7
contactform7.com/ja/recaptcha/

reCAPTCHバッジをフォーム画面のみに表示

reCAPTCHAの設定を完了すると、デフォルトの設定ではサイトの全ページにreCAPTCHAのバッジが表示されます。
バッジが表示されていると、ページスピードに影響が出たり操作の妨げになることもあるので、Contact form 7を使用しているページだけに適用させます。

下記サイトを参考に、テーマのfunctions.phpへコードを追加します。

※ご注意
functions.phpの編集はWordpressの動作に影響が出ます。
必ずバックアップを保存してから作業してください。
下記スクリプトは公式ではありませんが、私の運用している複数のサイトで利用しています。今のところ問題なく稼働しています。

解説はこちら
▼ContactForm7のキャプチャをお問い合わせページだけに表示｜ワードプレス・ドクター
wp-doctor.jp/blog/2021/05/14/contactform7キャプチャをお問い合わせページだけに表示/

承諾確認の追加

「個人情報の保護に関する法律についてのガイドライン（通則編）」（個人情報保護委員会）によると、「本人による同意する旨の確認欄へのチェック」することにより「本人の同意」を得ていると判断されます。

また、承諾確認チェックボックスを設置することで、海外からのスパムメールをある程度防ぐ効果もあります。

Contact form 7では簡単にチェックボックスを設置できます。

解説はこちら
▼承諾確認チェックボックス｜Contact Form 7
contactform7.com/ja/acceptance-checkbox/

便利に使いたい

デフォルトの設定でも使えますが、こうだったらいいな…と思うこともあります。
見た目と使いやすさについて参考サイトを紹介します。

CSSで見た目をわかりやすく

スタイルシート（CSS）で見た目を整えると、必須項目や入力箇所が分かりやすくなります。
コピーして使えるCSS、HTMLを公開しているサイトも多数あります。

メールフォームのデザインは、テーブル（table）、定義リスト（tl）、ブロックレベル（div）などを利用してカスタマイズされています。
最近のCSSではレスポンシブにも対応しているので、サイトの用途やテーマに合ったCSSを選んでください。
CSS、HTMLの知識があれば、カラーの変更なども簡単にできます。

▼【Contact Form 7】CSSでデザイン カスタマイズ（コピペOK・レスポンシブ対応）｜ツッチーブログ
tsutchii.com/cf7-design-customize

▼Contact Form 7のカスタマイズ（コピペOK、レスポンシブ対応）｜webicon
webicon.jp/wordpress/contactfoam7-setting/

▼Contact Form7をCSSでおしゃれにカスタマイズ【コピペ用】｜misaMAG
shimamisa.com/contact-form7-css/

郵便番号から住所を自動入力

WordPressのプラグインです。
郵便番号を入力すると、自動で住所が入力されます。

【zipaddr-jp】
wordpress.org/plugins/zipaddr-jp/

Contact Form7を利用していると設定がより簡単にできます。

▼Contact Form 7 が、より簡単に利用できます。｜ZipAddr2
zipaddr2.com/contactform7/

「都道府県」「市区町村」など命名ルールから次の入力項目を判断する方法と、入力項目に既定のname属性を設定する方法があります。
入力項目の数やレイアウトで設定は違うので、それぞれのサイトに適した方法を利用してください。

確認ページがない

Contact Form7は確認ページがないんですよね。
プラグインで表示させることもできるようですが、更新がされていないものや、レイアウトに手間がかかるものや、いまいちコレ！というおすすめがありません。
もしおススメあれば教えてください^^;

トラッキングのために

トラッキングとは、サイトにおけるユーザーの行動や情報を収集する機能です。
ユーザーがフォームを書き込んで、送信したか離脱したか、解析することもあります。

Googleアナリティクス対応のためにサンキューページへリダイレクトさせたい方もいるでしょう。
Contact Form7のサイトではリダイレクト方法も掲載されていますが、「トラッキングする簡単な方法」を推奨しています。

▼送信後に異なる URL にリダイレクトさせるには｜Contact Form 7
contactform7.com/ja/redirecting-to-another-url-after-submissions/

▼フォーム送信を Google Analytics でトラッキングする｜Contact Form 7
contactform7.com/ja/tracking-form-submissions-with-google-analytics/

今後、GA４に変わった場合は対応どうなるのかしら…。
なんだか面倒そう…。
と思ったあなたには、WordPress公式プラグイン「QAアナリティクス」をおススメします。
タグやコードの設定は不要、導入するだけでアクセス解析できますよ。

HTTPでは動作しなかった話

余談ですが。
WordPressで新しいサイトを構築中、Contact Form7で作成したメールフォームから送信テストをしても、アイコンがくるくる回るだけで動作しないことがありました。
新しくページを作って設置すると送信できるのに、お問い合わせページからはくるくる…

プラグインの干渉？
バージョン？
何か設定がおかしい？

しばらく悩んでから、アドレスバーの違いに気づきました。
お問い合わせページへのリンクをうっかり「http://～」に設定していたため、「保護されていない通信」になっています。
「https://～」でテストしたら、すんなりと送信できました。

サイト構築中でサーバーやBasic認証の影響かもしれません。
調べても原因がわからず悩んだので、おまけで書いておきます。

きちんと成果の出る広告を作る！

「パソコン得意なんでしょ? ちょっと,チラシ作ってよ」なんて簡単に言われて困った経験はないでしょうか。
専門知識が必要なはずのデザイン制作はツールやサービスの進化によって,ずいぶん敷居が下がってきていますが,きちんと成果の出る広告を作るために,どこからどうやって手をつけるべきか悩んでいる,という人が多いのもまた事実のようです。
本書はこういった,グラフィックデザイナーではない人の「広告や販促ツールを作らなくてはいけないけれど,何からはじめたらいいかわからない」といった声に応えたものです。実践型の入門書として「考え方」と「作り方」について,実例を交えながら解説しています。

目次

画像：pixabay

「スマホアプリの課金で売り上げを上げたい」と思っている方は多いかもしれません。
元記事では、DropboxやEvernote・マネーフォワードなどサブスクリプションモデルのスマホアプリでの課金UIについて、UIパターン・規約表示パターン、サービスパターンに分けてそれぞれ良い点、悪い点などをまとめています。

最後のまとめのところに書かれていますが、サブスクで売り上げを伸ばすためにはUI以外にも考えることはたくさんあります。
サイトで申し込みページなどのデザインをするとき同様に、サブスクUIを検討するときには、サービスとユーザー心理を考えてUIデザインすることが大切ですね。分かりやすい記事で個人的に勉強になりました。

課金 UI まとめてみた。｜あき / UIUX デザイナー｜note

画像：pixabay

アドビ社は、Adobe Creative Cloud・Document Cloud・Captivateの製品群の価格を、2019年2月初旬から新規ならびに契約更新時に順次改定していくことを発表しました。

サブスクリプション契約中の方には2019年1月9日に新価格の案内が届くそうです。

「価格改定に関するお知らせ」のページを読むと値上げしそうですね…

価格改定に関するお知らせ – Adobe Blog

前回記事では、レスポンシブ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つご紹介しました。
曖昧になりがちな「対応デバイス／ブラウザ」の定義の仕方や、結果として表示速度にも影響する「モバイルファースト」の取り入れ方について、参考にしていだけたら嬉しいです。

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

画像：pixabay

ニュース記事などを読んでいるとき、タイトル・大見出し・中見出しって最後まで読んでいますか？
元記事によると、多くのユーザーは見出しを最後まで読むことはなく、見出しの最初の2単語だけを見て本文の内容を推測しているそうです。

つまりユーザーが興味をひく言葉を見出しの最初に持ってくる必要があるのですが、本文でユーザーに伝えたいキーワードが入らないことがあります。
このような場合など「アイブロウヘッドライン」という手法を使うことがあります。アイブロウヘッドラインについて以下引用します。

ユーザーが本文の概要を理解するために必要なキーワードを伝える、アイブロウヘッドライン（Eyebrow headline）という手法があります。アイブロウヘッドラインとはメインの見出しや本文の上に、キーワードや主張を置くものです。小さなフォントで表示し、文章全体の内容を数単語で要約します。

アイブロウヘッドラインはすべての見出しにあったほうがいいわけではなく、キーワードが含まれていない長い見出しの上につけるのが効果的だそうです。

ユーザーに内容を読んでもらえるタイトルや見出しを考えるのはとても難しく悩んでいる方も多いと思います。「アイブロウヘッドライン」というテクニックを使ってみるのもユーザーに読んでもらうためのひとつの方法かもしれません。

見出しを最後まで読まないユーザーのためのアイブロウヘッドライン | UX MILK

前回記事(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デザイン導入要件についてのポイントを解説します。