刷新にあたって、受注から納品までをサブタスクを含めて約140に分解しました。また、各タスクで用いられるドキュメントもできるだけフォーマット化し、効率よくドキュメントワークができるようにしました。

合わせて、タスク毎の職能の再定義を行いました。プロデューサー、ディレクターといった業務範囲が曖昧な職能は、より厳密な職能の定義を試みました。例えばディレクターは、web制作業界では何でも屋のようになりがちですが、タスクごとの職能を明確に定めることで、各人の希望に合わせた経験を積み、各人が望むスキルセットの構築を可能にしたかったためです。このように、サービス向上だけでなく、スタッフのスキルアップやキャリアプランも考慮した刷新となっています。

このワークフローには、私たちの組織特性が強く反映されています。しかしこれは決して画期的なものではないとも思っています。多くは、web制作に共通する当たり前のタスクを当たり前に積み上げただけのものです。そしてこれを公開することは、web制作に従事する人や会社のマネジメント上の悩みを少しでも解消できるのでは思いました。また発注企業や代理店など、制作会社と付き合う企業にとっても有益な情報になるではないかと思いました。項目は以下の通りです。

• 1. プロジェクト設計
• 2. 戦略
• 3. 設計
• 4. 制作
• 5. 開発
• 6. テスト
• 7. 公開と運用準備
• ワークフローを作る意義

1.プロジェクト設計

契約締結後にまず行うのがプロジェクト設計です。チーム編成からプロジェクトのルールを定義して社内外に共有し、スムーズなプロジェクト進行のための土台作りを行います。

1-1. チーム編成

スケジュールの空き状況やメンバーの適性、希望などを考慮し、プロジェクトチームを編成します。ベイジでは戦略から納品まで一気通貫で行うプロジェクトがほとんどで、それを実行する全ての職能が社内に揃っているため、全工程のプロジェクトメンバーをここの段階で決定します。厳密にはプロジェクトマネージャーの担当業務ですが、ベイジではプロデューサー、ディレクターおよびアサインされるメンバーで協議した上でチームを編成します。

1-2. WBS作成

Microsoft Projectで【WBS（Work Breakdown Structure）】を作成します。実際には契約前の見積段階で作られていることもあります。厳密にはプロジェクトマネージャーの担当業務ですが、ベイジではプロデューサーやディレクターが担当します。フルメニューのプロジェクトを想定したテンプレートがあり、このテンプレートを改変して30分～1時間程度でWBSを作ることができます。

1-3. プロジェクト開始連絡

チーム編成が決まると新プロジェクトの開始が社内に告知されます。プロジェクト内で共通で使用されるプロジェクトコード、クライアント名、webサイトの概要、予算、納期、スコープ、開発サーバ情報、セキュリティ関連の設定情報、プロジェクトメンバー、プロジェクト固有の前提条件など、プロジェクトに関する様々な基本情報を全社員にメールで共有します。厳密にはプロジェクトマネージャーの担当業務ですが、ベイジではプロデューサーやディレクターが担当します。

1-4. プロジェクト管理の準備

ベイジでは、社内のプロジェクト管理は【プロジェクト管理シート】を中心に行っています。プロジェクト管理シートとは、プロジェクトの進捗状況をタスク毎に細分化したシートです。Googleスプレッドシートで作られ、全メンバーが更新できるようになっています。WBSがバッファ等も見込んだ顧客提示用のスケジュールであるのに対し、プロジェクト管理シートは社内用で、より具体的かつ現実的な作業予定が書き込まれます。これらは週次で更新され、毎週金曜日のプロジェクトミーティングで共有されます。タスク毎の目標工数・実績工数・累計工数を記述する欄もあり、プロジェクト全体の消費工数が分かるようにもなっています。WBS同様、フルメニューを想定したテンプレートが用意されており、30分程度でプロジェクト管理シートを作ることが可能になっています。これも厳密にはプロジェクトマネージャーの担当業務ですが、ベイジではプロデューサーやディレクターが担当します。

1-5. 開発環境等の整備

プロジェクト開始のメールを受信すると、サブドメインの申請や開発環境、ファイル共有環境に関する設定やサーバ会社への申請を行います。開発環境に関する情報は最終的に、セキュリティに配慮した方法で社内共有されます。ベイジではエンジニアが担当します。

1-6. プロジェクト定義書の作成

社内の準備が一通り完了したら、顧客向けの【プロジェクト定義書】を作成します。プロジェクト定義書とは、プロジェクトの目的、スコープ、成果物、メンバー、セキュリティ関連情報、コミュニケーションルール、リスクや補足事項などを一通りまとめたWordで作られたドキュメントです。プロジェクトに関する共通認識を持ち、エビデンスとして残すことが目的です。プロジェクト定義書もフォーマットが用意されており、30分ほどで作成可能になっています。厳密にはプロジェクトマネージャーの担当業務ですが、ベイジではプロデューサーやディレクターが担当します。

1-7. キックオフミーティング

プロジェクト開始後、顧客と行う最初のミーティングです。プロジェクトに関する前提の共有を目的とし、プロジェクト定義書を中心に説明が行われます。認識共有自体は質疑応答も含めて15分程度で終了することがほとんどですが、これをする・しないで、その後のプロジェクトの進めやすさに大きな違いが生じるため、私たちはこのタスクを非常に重要視しています。プロジェクト定義書の説明が終わった後は、そのまま戦略フェーズのヒアリングを実施していきます。

2.戦略

web制作の上流、UX5階層モデルにおける戦略と要件のレイヤーを検討するフェーズです。本来はwebサイトの検討以前にマーケティング戦略は決まっているべきです。しかしそういったケースは少なく、私たちがリードして戦略要件の整理を行っているのが現実であるため、重要なパートとしてワークフローに組み込まれています。また戦略フェーズは、私たちがビジネス視点でデザインをするためのインプットの場にもなっています。戦略の理解と認識合わせに約2～3か月といった時間を費やすからこそ、プロジェクトを通じてマーケティング視点を持った提案が可能になります。

2-1. ヒアリング設計

まずヒアリングすることを、ExcelもしくはGoogleスプレッドシートで作られた【ヒアリングシート】にまとめます。ヒアリングシートには、経営、マーケティング、ブランディング、ターゲット、競合、事業上の課題、プロモーション方法、組織体制など、webサイトに限らず経営、マーケティングも含めて、100前後の質問が記載されます。ヒアリングシートもテンプレートが用意されていますが、市場特性、企業特性、事業特性を反映させる必要があるため、ほぼ一から書き直すことも多いです。ヒアリングシートはキックオフミーティングの約1週間前に顧客に共有し、事前に回答を用意してもらいます。厳密にはマーケティングコンサルタントの担当業務ですが、ベイジではプロデューサー、もしくはディレクターが担当します。

2-2. ヒアリング

ヒアリングシートの内容に従って、ヒアリングとディスカッションを実施します。顧客にはキーマンを始め主要なメンバー全員の出席を依頼します。2～3時間ほどの時間が設定されますが、足りない場合には、第2回のヒアリングが実施されます。この段階ではwebサイトの話よりも経営やマーケティングに関する話題が中心となります。これも厳密にはマーケティングコンサルタントの担当業務ですが、ベイジではプロデューサー、もしくはディレクターが担当します。

2-3.ビジネス設計

ヒアリングが終わると、その内容を元にビジネスの前提条件の整理とアイデアをまとめた【ビジネス設計書】を作成します。複数のフレームワークを用いることで様々な角度からビジネスを観察し、webサイトの方向性や具体的なアイデアを発案します。非常に属人的な工程であり、顧客個別に作り替えることも多く、あまりフォーマット化できていないタスクとなります。アウトプットとなるビジネス設計書は主にPowerPointで作られ、30～50ページほどの分量となります。やはり厳密にはマーケティングコンサルタントの担当業務ですが、ベイジではプロデューサー、もしくはディレクターが担当します。主に以下のような情報がまとめられます。

■経営戦略／事業戦略
経営戦略と事業戦略の方向性を整理します。経営戦略では横軸に義務と意思、縦軸に社会と会社を置いた【BMVV】というフレームワークを用い、ミッション、ビジョン、バリューを整理します。事業戦略では、ボストン・コンサルティング・グループが開発した【アドバンテージマトリクス】、イゴール・アンゾフ考案の【事業成長マトリクス】、マイケル・ポーターの【競争優位戦略】を改変したフレームワーク、フィリップ・コトラーの【競争地位戦略】などを活用し、webサイトの前提となる事業戦略のアウトラインを再確認します。

■ビジネスモデル
ビジネスモデルを図式化し、収益化の仕組み、ビジネスにおけるwebサイトの役割、サイト改善の影響範囲、期待できる現実的な成果を見定めます。独自にカスタマイズした【サービスブループリント】や【ビジネスモデルキャンバス】を用いて検討します。

■強み・弱み、価値
企業やブランド、製品、サービスの強みと弱みや価値を整理します。価値の定義は【バリュープロポジションキャンバス】を用います。強味・弱みは【SWOT】を用いることもありますが、競合やターゲットによっても変わるため、複合的な観点から強みと弱みを浮き彫りにすることも多いです。強み・弱みの把握を通じて、ケイパビリティやコアコンピタンス、事業上の制約条件などを洗い出していきます。

■競合
マイケル・ポーターが考案したファイブフォース分析を改変した【コンペティターマップ】を用い、競合に関する情報を整理します。直接競合だけでなく、間接競合から代替品と複数の視点で競合関係にある企業やブランド、製品、サービスを整理します。またそれぞれの競合への対策や方針、競合への対応方針を確認していきます。

■セグメンテーションとターゲティング
狙うマーケットを4象限や9象限、あるいはファネル状にセグメントし、ターゲットを明確にします。また事業上のターゲティングを元に、webサイトの役割を踏まえたwebサイトのターゲットを定義します。webサイトで独自にターゲティングを行うのは、事業上のメインターゲットがwebサイトのメインターゲットになりえないケースが多々発生するためです。またこのタスクはペルソナの前段階となるため、属性情報・行動情報・インサイトなど、UXリサーチを進めるうえで必要な仮説ベースの情報を整理します。

2-4.UXリサーチ

ユーザー体験、顧客体験をより深く理解するためのUXリサーチの進め方はプロジェクトごとに大きく異なりますが、これまでの経験に基づいて、ワークフローとして定義しています。厳密にはUXリサーチャーの担当業務ですが、ベイジではプロデューサーもしくはデザイナーが担当します。

■エスノグラフィ
主に生活者をターゲットとするwebサイトを制作する時に行われます。フライオンザウィールやシャドーイングといった手法で生活者の行動を観察することでニーズやインサイトを発見し、【UXリサーチレポート】としてまとめます。webサイトに関する行動観察というより、マーケティングリサーチの一貫として実施されます。実施には以下のようなサブタスクが発生します。

• 目的の確認
• フィールド選定
• 観察
• デブリーフィング
• レポーティング（考察）

■インタビュー
想定ターゲットに近い被験者を集め、インタビューを行います。1対1のデプスインタビューの場合と、複数人に同時に質問するグループインタビューの場合があり、後述のユーザーテストと合わせて実施されることもあります。ターゲットを集めにくいBtoBビジネスの場合には、ターゲットを知る関係者へのインタビューが中心となります。実施には以下のようなサブタスクが発生します。

• 目的の確認
• インタビュー設計
• 被験者リクルーティング
• インタビュー項目の詳細設計
• インタビュー実施
• レポーティング（考察）

■アンケート
クライアント側で把握している定性情報が不十分な場合、ネットリサーチ会社を用いるなどして、ターゲットに関する情報を収集します。エスノグラフィと同じく、生活者対象のwebサイトで行われることが多く、BtoBサイトではあまり実施されません。実施には以下のサブタスクが発生します。

• 目的の確認
• アンケート方法の決定
• 被験者の属性定義
• アンケート設計
• アンケート実施
• アンケートの集計
• レポーティング（考察）

■ユーザーテスト
被験者を3～5名アサインし、webサイトやアプリケーションを実際に使ってもらい、フィードバックを得ます。発話法を基本とし、被験者、司会者、記録者の3名構成で実施します。専門企業に委託して、リモートユーザーテストを実施する場合もあります。実施には以下のサブタスクが発生します。

• 目的の確認
• 被験者の選定
• テストシナリオの設計
• テストの実施
• テストの集計
• レポーティング（考察）

■デスクトップリサーチ
ネット調査を中心としたリサーチです。インタビュー記事や統計データなどを収集し、ターゲットに関する情報を入手していきます。UXリサーチではなく、ビジネス設計の一環として実施されることもあります。

■認知的ウォークスルー
マーケティングコンサルタントやデザイナーなどの専門家がwebサイトやアプリケーションを使ってフィードバックをします。いわゆるヒューリスティック評価です。UXを想定したシナリオを立てて実施します。ベイジでは後述のエクスペリエンスストーリーを作成しながら認知的ウォークスルーを行う場合もあります。

■ペルソナ作成
収集したリサーチ情報を元に【ペルソナ】を作成します。ペルソナの粒度は案件により異なりますが、インターネット上の情報取得行動に関係する属性を中心に定義してきます。なお、ターゲットがあまりにも幅広いフルマーケティング型の商材の場合には、あえてペルソナを定義せず、共通要素の洗い出し、ニーズや行動パターンの定義に留める場合もあります。

■ストーリー作成
ペルソナとジャーニーマップを繋ぐものとして、ベイジでは【エクスペリエンスストーリー】という2000～3000文字ほどの文章を作成します。ペルソナやジャーニーマップでは難しい細部の描写を行うためです。似たものにストーリーを絵で描くストーリーボードという手法もありますが、絵の上手下手でバイアスが生まれる、細かな描写が難しい、修正が容易でない、等の理由から、文章という最もシンプルな方法で体験のストーリー化を試みています。ストーリーには現在と未来の2つの視点があり、いずれを描くかはケースバイケースですが、どちらをストーリー化するほうが有意義かを考え、事前に決めておきます。

■体験のマッピング
エクスペリエンスストーリーは文章の羅列であり、描写としては詳細ですが情報としては整理されていないため、【ジャーニーマップ】を作り、体験にまつわる情報整理を行います。ジャーニーマップで重視しているのは各ステージにおけるwebサイトの役割や要件を定義することです。ジャーニーマップを作ること自体を目的とせず、webサイトのコンテンツ、機能、デザインといった具体的なアイデアに結び付けていきます。

■サイト内行動の整理
エクスペリエンスストーリーやジャーニーマップは体験全体を描写したものでしたが、その体験を前提としたうえで、webサイトをどのように使って行くかを、【サイト内行動シナリオ】と呼ばれるチャート図に起こしていきます。また、シナリオが正しく機能していることを証明できる指標を洗い出し、後工程のKPI設定の参考情報としていきます。

2-5. ログ解析

分析できるサイトが存在する場合はログ解析を実施します。ベイジではUXリサーチの後工程でログ解析を行い、理想とするユーザー行動に対して現状がどのくらい乖離しているかを把握します。サマリーをなぞるような表面的な解析ではなく、セグメント機能やセカンダリディメンジョンを駆使したり、CSVで出力して別のツールで加工するような詳細な分析を中心とし、セグメントされた情報からユーザーの心理を炙り出していきます。最終的にはPowerPointの【ログ解析レポート】およびExcelの【分析シート】にまとめます。厳密にはアナリストの担当業務ですが、ベイジではプロデューサーもしくはディレクターが担当します。

2-6. キーワード分析

キーワードプランナーを使って検索キーワードを調査し、クエリの種類によってカテゴリ分けして、ユーザーニーズと市場性を探ります。Excelで作られた【キーワードリスト】には、検索順位や予想クリック率、予想訪問数、予想CV数などから、自然検索による流入ボリュームの最大値が記載されます。これを元にSEOを重視するか、広告を併用するかをジャッジしていきます。厳密にはアナリストもしくはマーケティングコンサルタントの担当業務ですが、ベイジではプロデューサーもしくはディレクターが担当します。

2-7. 競合分析

競合企業、競合商材、もしくは競合サイトの分析を行います。競合の企業や商材そのものに関してはマーケティングリサーチを行い、競合サイトに関しては私たち主導でヒューリスティック評価を実施します。後者における調査項目はケースバイケースですが、主にコンテンツ、コピー、構造、機能、デザイン、ユーザビリティなど、ログ解析などでは判断できない定性的な質を評価していきます。評価はスコアリング・グラフ化した上で、参考にできる箇所・そうでない個所を分析してPowerPointで【競合分析レポート】を作成します。厳密にはアナリストもしくはマーケティングコンサルタントの担当業務ですが、ベイジではプロデューサー、ディレクター、あるいはデザイナーが担当します。

2-8. ファネル設計

主にBtoBサイトで実施します。Sirius Decisionsのデマンドウォーターフォールをカスタマイズした独自のデマンドウォーターフォールを作成し、ステージごとのプロセスを明確にして、各ステージにおける課題とwebサイトでできることを洗い出し、【ファネル設計シート】としてまとめます。またMA（マーケティングオートメーション）を導入している場合には、各ステージにどのようなコンテンツを配置し、どのようなデータを取得するかを定義していきます。厳密にはマーケティングコンサルタントの担当業務ですが、ベイジではプロデューサーもしくはディレクターが担当します。

2-9. ブランド設計

ブランディングの指針が明確でない場合、私たちが顧客に代わって整理します。ファクト、ベネフィット、パーソナリティ、コンセプト、ユーザーニーズで構成されたブランドピラミッドというフレームワークを用い、【ブランド設計シート】としてまとめます。ここで定義された内容をベースに、コピーの方向性、デザインのトーン＆マナーを決定していきます。デザインのトーン＆マナーを決定するためには、さらにブランドキーワードの抽出とイメージスケールを用います。厳密にはマーケティングコンサルタントの担当業務ですが、ベイジではプロデューサーもしくはデザイナーが担当します。

2-10. ストーリー設計

エクスペリエンスストーリーは顧客目線の体験のストーリーでしたが、ここでは企業目線のストーリーを策定します。一つは【マーケティングストーリー】と呼ばれるもので、ダイレクトマーケティングのセオリーを参考にしたものです。問題提起→結果→実証→信頼→安心で構成され、顧客の信頼を勝ち取り説得するためのストーリーになります。もう一つは【ブランドストーリー】と呼ばれるもので、企業や商材の世界観を作りために、アイデンティティやビジョンから設計されます。前者は主にコンテンツプランに、後者はコンテンツやコピー、デザインの方向性を決めるために用いられます。厳密にはマーケティングコンサルタントの担当業務ですが、ベイジではプロデューサーもしくはデザイナーが担当します。

2-11. 目標設計

ここまでの検討結果を踏まえて、プロジェクトが追うべきKPIを設定します。KPIはプロジェクト開始前から顧客に提示されることもありますが、現実的でなかったり、適切でなかったりすることもあるため、戦略フェーズを通じてその妥当性を検証し、最終的に【KPI設定書】としてまとめます。なお、KGIからの逆算が可能な場合には目標数値まで定義することもありますが、KGIと相関する適切な指標を定義した上で、予算の中でその最大値を狙っていく、ということも多いです。厳密にはマーケティングコンサルタントの担当業務ですが、ベイジではプロデューサーもしくはディレクターが担当します。

2-12. アイディエーション

戦略フェーズの目的は分析ではなくwebサイトの具体的な改善アイデアを出すことです。そのためこのアイディエーションこそ、戦略フェーズのゴールといえます。戦略フェーズを通じて発案されたアイデアはExcelもしくはGoogleスプレッドシートで作られた【アイデアリスト】にまとめられ、属性（コンテンツ、機能、デザインなど）、適応場所（サイト全体なのか、特定ページなのか）によって仕訳けられます。こうしてまとめられたアイデアリストが後の設計やデザインにおける要件となります。厳密な担当が存在しない業務ですが、ベイジではプロデューサーもしくはディレクター、デザイナーが担当します。

2-13. 改善提案

フルリニューアルではなく改善プロジェクトの場合には、アイデアリストの内容を元に施策の優先順位付けをした【改善提案書】を作成します。施策毎に費用やスケジュールを提示し、改善フェーズ・開発フェーズのスコープを決定します。コンサルティングのみを担当する場合には、改善提案書が最終成果物となります。ベイジではプロデューサーもしくはディレクター、デザイナーが担当します。

2-14. WBSの更新

設計・開発フェーズのスコープが見えた段階でWBSを更新します。プロジェクト開始時にMicrosoft Projectで作成したWBSを元に、タスクをさらに細分化して、現実的な作業スケジュールに落とし込みます。厳密にはプロジェクトマネージャーの担当業務ですが、ベイジではディレクターが担当します。

2-15. コスト算出

WBSを更新するとともに、設計フェーズ以降の見積書を作成します。プロジェクト開始時に全体予算が決まった中で契約した場合でも、この時点でコスト面でのギャップが生じてないか確認します。戦略フェーズで考案されたアイデアをすべて実施すると予算を超えてしまう場合には、追加予算の交渉かスコープの削減を検討します。厳密にはプロジェクトマネージャーの担当業務ですが、ベイジではディレクターが担当します。

2-16. リスク管理

設計フェーズ以降に引き継ぐ注意事項を、ExcelもしくはGoogleスプレッドシートで作られた【リスク管理シート】にリストアップします。戦略フェーズで検討した内容や注意事項が、設計フェーズ以降で抜け落ちることを防ぎます。最終的には各種チェックシートのチェック項目に反映します。ディレクターが担当します。

3. 設計

webサイトの骨組みを決めるのが設計フェーズの主な目的です。UX5階層モデルでいうところの構造から骨格がメインになります。コンテンツ企画、システムの要件定義から基本設計といった、要件のレイヤーも一部ここで扱います。設計という行為は、厳密には制作や開発の一部といえますが、システム開発やweb制作の慣習に倣い、ベイジでは独立したフェーズとして取り扱っています。

3-1. サイト全体設計

アイデアリストからコンテンツ部分を抜き出し、ツリー状に統廃合した上で、ディレクトリやページ化してサイト全体を定義していきます。サイト構造を定義したドキュメントはサイトマップと呼んでいる会社も多いですが、ベイジでは【サイトストラクチャ】と呼んでいます。ExcelもしくはGoogleスプレッドシートで作られたサイトストラクチャにはページごとにターゲットキーワード、ページの大まかな内容や搭載される機能、CMSやデザイン、HTML化の対象かどうかなどを記載します。工程としては設計フェーズに含めていますが、戦略フェーズの最終成果物として作られることも多いです。厳密にはインフォメーションアーキテクトの職域ですが、ベイジではプロデューサー、ディレクター、デザイナーのいずれかが担当します。

3-2. CTA設計

ジャーニーマップのステージ別にコンテンツを分類し、各コンテンツのCTA（コール・トゥ・アクション）を定義します。サービス紹介であれば資料ダウンロード、セミナーであればエントリーと、コンテンツによってターゲットのステータスが変わり、CTAが変わることも多いため、改めてCTAのみにフォーカスし、【CTA設計書】としてまとめます。CTA設計書もPowerPointで作られたテンプレートが用意されています。厳密にはマーケティングコンサルタントもしくはUXリサーチャーの担当業務ですが、ベイジではUXリサーチを実施したプロデューサー、ディレクター、デザイナーのいずれかが担当します。

3-3. 設計ブリーフィング

設計を担当するメンバーのための社内ブリーフィングです。ベイジでは戦略系の資料が膨大で目を通すのに時間がかかるため、要点を1～2枚にまとめた【設計用ブリーフィングシート】を作成し、ブリーフィングを行います。このシートもテンプレートをWordで用意しており、必要事項を記入すれば完成するようになっています。プロデューサーもしくはディレクターが企画し、設計を行うデザイナーに説明します。

3-4. 画面設計

いわゆる【ワイヤーフレーム】です。ベイジではAdobe XDで制作しています。画面の構造以外に、ページ内のコンテンツの大枠、具体的にはh2要素までここで定義していきます。ベイジでは必要なUIパーツと詳細な解説が付いた画面設計用のテンプレートが用意されており、デザイナー以外であってもすぐに画面設計ができるようになっています。厳密にはインフォメーションアーキテクトの担当業務であり、一般のweb制作会社ではディレクターが担当することも多いですが、ベイジでは画面設計はデザインの一部と考え、基本的にはデザイナーが担当します。

3-5. 画面設計の解説

Adobe XDで制作したワイヤーフレームだけでは設計意図が言語化できないため、PowerPointで【設計コンセプト資料】も合わせて作ります。ページ中心の動線を再整理し、UXリサーチの内容を踏襲したページ毎のシナリオを定義していきます。ページの細部に至るまで戦略の意図を踏襲して言語化し続けることで、戦略から乖離しないユーザー視点の画面設計を行っていきます。これもベイジではデザイナーの職域と捉え、デザイナーが担当します。ベイジでは、デザイナーといえども高いドキュメント制作および言語化能力を求められます。

4.　制作

ここでは主に表層のデザインが行われます。デザインフェーズ、デザイン制作フェーズなどとも呼んでいた時期がありましたが、デザインという言葉の解釈の広がりから、シンプルに制作フェーズと呼んでいます。また、コンテンツ制作に伴うコピーライティングや撮影もこのフェーズに組み込まれています。目に見える部分の制作がメインになり、クオリティの追求が厳しくなる一方、戦略との乖離を起こさないためのチェックも頻繁に行われます。なお、デザインという言葉の解釈の広がりから、ベイジでは「アートディレクター」のような、広告業界の慣習に由来する職名は徐々に廃止し、「デザイナー」に統一する傾向にあります。

4-1. デザインブリーフィング

設計フェーズ以前の内容を元に、デザインを担当するメンバーのための社内ブリーフィングを行います。ベイジでは設計をデザイナーが担当することが多く、その場合は設計に続いて表層のデザインをデザイナーが担当するため、ブリーフィングは行われません。設計とデザインで別メンバーが担当する時のみ実施します。設計用ブリーフィングシートをベースに、画面設計時のポイントを追記して、【デザイン用ブリーフィングシート】を作成します。プロデューサーもしくはディレクターが企画し、デザイナーに説明します。

4-2. デザインディスカッション

表層のデザインについては感覚的・主観的な領域も多く含まれることから、事前に必ず顧客を交えたディスカッションを行います。参考デザインの紹介以外に、デザイントレンド、技術的な背景、戦略フェーズの要件、ブランド戦略の確認、競合との差別化、ポジショニングなどが話し合われます。顧客との間で前提知識や感覚的で曖昧な要望を共有することで、誤った方向性のデザインを作ったり、適切でないジャッジをしてしまうことを防ぎます。この工程を経るため、ベイジでは後述のベースデザインは基本的に1案しか作りません。デザインディスカッションは【デザインディスカッションシート】を中心に行われ、デザイナーが担当します。

4-3. デザインコンセプトメイク

デザイン提案時には、デザインだけでなく、論理的な理由付けに基づくコンセプトの提案も行われます。ただし、デザインの全ての要素をロジカルに説明することは難しいため、コンセプト提案をベースにディスカッションを行い、顧客と合意していきます。コンセプト資料と提案はデザイナーが担当します。

4-4. ベースデザイン

サイト全体のトーンを決定するために、最初に制作するデザイン案です。ホーム、カテゴリトップ、詳細画面など、主要な2～3画面をピックアップしてデザインを制作します。前述のようにベイジでは通常1案のみを提案ですが、色やビジュアルのバリエーションは初回提案に含まれます。ベースデザインは社内でのフィードバックも多く、初案完成から1週間近く社内でブラッシュアップすることも珍しくありません。顧客からのフィードバックは2回を想定してスケジュールが組まれますが、基本的な方向性が変更になることはほとんどなく、一回目の提案で合意し、他画面への展開に進みます。ベースデザインはデザイナーが担当します。

4-5. デザイン展開

ベースデザインで決まった方向性に従い、その他の画面にデザインを展開していきます。ベイジではモバイルファーストのサイトでも、PCでのビューを先にデザインすることが多く、この段階でモバイルのデザインも行われます。多くの場合は、複数回に分けて制作を進行し、都度クライアントと合意を取っていきます。ただし、全画面をデザイン化することはなく、必要最小限のテンプレートとパーツだけを制作し、残りはHTML上で展開していきます。デザイン展開はデザイナーが担当します。

4-6. デザインチェック

表層のデザインがある程度進むと同時に、戦略やUX、設計を担当したスタッフによるデザインチェックが始まります。デザインのフィードバック対応を行う中で、戦略やUXの意図から外れていってないかなど、ビジネス視点での妥当性のチェックとクオリティチェックを実施します。【デザインチェックシート】が標準で用意されており、プロジェクトごとにカスタマイズした上で、このシートに従ってチェックが行われます。チェックを担当するのは表層のデザインの上流を対応した全メンバーですが、主にプロデューサーやディレクターです。

4-7. デザインパーツ制作

図版、アイコン、イラストの制作です。UIパーツと比べると制作負荷が高いため、個別に進行管理を行います。制作前にExcelもしくはGoogleスプレッドシートで作られた【モチーフリスト】を作り、どのようなモチーフや構成にするかを顧客と合意します。例えばイラストであれば、モチーフリストによるモチーフ確認の後にラフスケッチ→線画制作→彩色と、段階を踏みながら制作することで、無駄な手戻りの発生を極力抑えます。図版はデザイナーが担当しますが、アイコンやイラストは外部のパートナーに依頼し、デザイナーがディレクションだけを行うことも多いです。

4-8. コンテンツ制作

コンテンツ制作の中心は主にコピーです。webサイトの成功を握るのはコンテンツの質であり、その中心になるのはコピーであり、web制作の最重要パートの一つと考えています。プロトタイプ制作時において、H3レベルまでの見出しの原案をベイジが考案し、それに合わせて情報収集を開始します。コンテンツの企画を顧客に委ねず、web戦略に精通したベイジが主導することで、戦略性の高いwebサイトを実現していきます。コンテンツ制作は属人性が高い仕事ですが、そのプロセスはある程度フォーマット化されています。多くの工程をディレクターが中心に行います。

■コンテンツ制作計画
コンテンツの初案はベイジで検討します。プロトタイプで定義されたコンテンツのフォーマットに従い、【原稿管理シート】と呼ばれるExcelもしくはGoogleスプレッドシートで作られた管理用ドキュメントを作成します。原稿担当者はこのシートに合わせて原稿を準備します。また原稿管理シートもフォーマットがあり、シート作成にすぐ着手できるようになっています。

■表記ルールの設定
ベイジでは【表記統一ガイドライン】を作り、サイト内、プロジェクト内での言葉の表記ルールをあらかじめ定義します。これも雛型が元々あり、案件固有の表記ルールを反映していきます。厳密にはコピーライターが作るべきものですが、ベイジでは主にディレクターが担当します。

■コピーライティング
コピーに関しては
① ベイジで作る
② クライアントで作る
③ クライアントが作ったものをベイジでリライトする
④ 外部のパートナーに依頼する
4つの選択肢がありますが、多いのは①と③です。②はクライアント側でコピーが制作できることがほとんどないため、④はマーケティング戦略やUX、SEOなどを考慮したwebならではのコピーが制作できる人材が外部に少ないために、あまり選択されません。ベイジではコピーライティングに関する知見をまとめたマニュアルが存在します。主に「言葉を削る」「言葉を選ぶ」「言葉を整える」という観点で書かれたこのマニュアルに従い、担当者がコピーを制作していきます。顧客にてコピー制作を担当する場合には、マニュアルを使った勉強会が開催されることもあります。

■原稿反映
仕上がった原稿は順次HTMLに反映していきます。原稿内容によっては、デザイナーが新しいレイアウトパターンを制作し、その後HTML化していくこともあります。原稿完成時点でHTMLがWordPress化されている場合には、WordPressの管理画面から投稿していきます。

4-9. 撮影

被写体が存在しにくいサイトでは有償の写真素材を使うことも多いですが、そうでない場合には撮影を行います。特に採用サイトでは撮影はほぼ必須です。撮影は外部のカメラマンと契約して実施しますが、工程管理はベイジで管理します。デザイナーもしくはディレクターが担当します。撮影には、以下のサブタスクが設定されています。

• 撮影計画
• 参考写真調査
• カメラマン選定
• ロケハン
• 香盤表作成
• 撮影（同行・ディレクション）
• データ確認
• 写真選定
• 写真加工
• HTMLへの反映

5. 開発

フロントエンドからサーバサイドまで、いわゆる開発全般を行います。一般的にはコーダー、フロントエンドエンジニア、サーバサイドエンジニアなどと職能が分かれますが、ベイジではすべてエンジニアと総称し、一人で開発工程を完遂できるワークフローと能力開発を行っています。なお、ベイジはシステム開発会社ではないため、大規模な開発は外部のパートナーと協業して進めていきます。

5-1. 開発ブリーフィング

設計フェーズ以前の内容を元に、エンジニア向けの社内ブリーフィングを行います。【開発ブリーフィングシート】に記述される内容は設計やデザインのブリーフィングで用いた情報に加えて、開発上のポイントや注意事項、リスクなどを追記したものです。ディレクターが企画します。

5-2. 開発前チェック

開発開始前に【開発前チェックシート】を確認し、必要な情報が不足していないか確認します。開発前チェックシートには解析コードやソーシャルボタンの有無、設定方法、サーバ環境の情報など、開発に必要な事前情報があらかじめ記載されており、情報が抜けたまま開発が進行することを回避します。チェックシートの更新およびチェックはエンジニアが担当します。

5-3. ルールの定義

コーディングのルールを定義します。【コーディングガイドライン】にはHTML、CSS、JavaScript等の記述方法、フォルダやファイルの命名ルール、マルチデバイスの方針など、コーディングに関するルールを約17ページに渡って詳細に記載します。これも雛型が用意されており、案件固有の条件を反映させてカスタマイズして使います。エンジニアが担当します。

5-4. 開発環境の整備

開発中に使用するサーバの初期設定を行います。また、ファイルのバージョン管理に使用するGitの準備を行います。開発環境の情報は【サーバ情報シート】にまとめてメンバーに共有します。

5-5. ベースコーディング

代表的な数画面をピックアップし、ガイドラインに従ってベースのコーディングを進めます。レスポンシブweb対応などもこの段階で行い、コーディングの基本構造をこの段階で決めます。エンジニアが担当します。

5-6. モーションデザイン

ベースコーディングに対してアニメーションを実装します。デザイナーとエンジニアが画面を見ながら1～2日かけて調整します。モーションデザインは一度では終わらず、後述するデザインチェック、テスト公開段階など、複数回に渡ってブラッシュアップを行い、ユーザーの利用体験を向上させる適切なマイクロアニメーションを追求していきます。

5-7. コードレビュー

ベースコーディングが完了したタイミングで、実装者とは別のエンジニアがHTML、CSS、JavaScriptを確認してレビューします。第三者によるコードレビューを実施することで、ソースコードを洗練化させるだけでなく、エンジニア同士の情報交換や相互スキルアップ、モチベーションを図ります。

5-8. コーディング

コーディングガイドラインに沿ってHTML、CSS、JavaScriptの実装を行います。下層画面の展開は複数人で分担することもありますが、ガイドラインやチェックシートが存在するため途中からのプロジェクト参加も容易です。コードはすべてをゼロから書くことは少なく、過去案件のブラウザチェックを通過したコードを積極的に再利用することで、実装の効率化、品質の向上を目指しています。現在はより多くの案件でコードを使いまわせるようコーディングテンプレートの作成も進めています。

5-9. リファクタリング

すべての実装が終了した段階で、不要なコードの削除、命名の見直し、ファイル整理などを行います。リファクタリングで整理されたコードの一部は次案件でも再利用され、以後の実装速度、精度の向上に繋げます。公開後の更新も考慮し、読みやすくて修正が容易なコードへの改編も行います。ソースコードの洗練化だけでなく、公開後の運用コスト軽減も目指します。

5-10. デザイナーチェック

ベイジではコーディングの進捗は毎日報告され、プロジェクトの全メンバーが常時確認できるようになっています。プロデューサーとデザイナーは元々意図した戦略が反映され、デザインがきちんと実装されているかをその都度確認し、必要であれば随時フィードバックします。「プロトタイプやドキュメント通りにHTML化されていればよい」とは判断せず、常により良いUIになるようブラッシュアップを繰り返していきます。

5-11. フォーム開発

フォームを開発します。近年のフォーム開発はMA（マーケティング・オートメーション）等の浸透で簡素化されていますが、入力フォーマットやインラインバリデーションの設定、送受信されるメールなど、EFO（エントリーフォーム最適化）の観点から、使いやすくストレスの少ないフォームを目指します。フォーム開発には以下のようなサブタスクが存在し、いずれもエンジニアが担当します。

• 要件定義書作成
• 要件定義書レビュー
• 実装
• 単体テスト

5-12. CMS開発

ベイジでは案件特性に合わせたCMSの提案を行っていますが、最終的にWordPressが選択されることは非常に多いです。WordPressの実績は多く、ノウハウも豊富で、商用CMSに近い状態までカスタマイズして納品しています。運用も含めたセキュリティ対策も行い、商用CMSに近いセキュリティレベルを目指します。CMS開発には以下のようなサブタスクが存在し、いずれもエンジニアが担当します。

• CMSソリューション選定
• 要件定義書作成
• 要件定義書レビュー
• CMS初期設定
• テンプレート開発
• プラグイン導入およびカスタマイズ
• 個別データ入力
• 既存データ移行
• 単体テスト

5-13. ログ解析設定

ログ解析タグの埋め込みと各種設定を行います。戦略フェーズで定義されたKPIを参照しながら【ログ解析設定シート】を作成します。このシートに基づき、ログ解析のビューやコンバージョンの設定が行っていきます。厳密にはGoogleタグマネージャーで一元管理し、スクロール量計測などのカスタマイズもGoogleタグマネージャーから設定を行います。厳密にはアナリストの担当業務ですが、ベイジでは計画自体はプロデューサーもしくはディレクターが企画し、設定はエンジニアが担当します。以下のようなサブタスクが存在します。

• タグマネージャー設定
• ログ解析設定シート作成
• HTMLソースコードへのタグ埋め込み
• ログ解析の各種設定およびカスタマイズ
• 設定状況の確認

5-14. MA設定

BtoBサイトでMA（マーケティングオートメーション）を導入している場合、ベイジにてwebサイトに関係する領域の設定をサポートします。スコアリング条件に応じたポップアップメニューの表示設定やフォームの設定等も、アクセス権限をもらい設定を代行する場合があります。厳密にはマーケティングコンサルタントの担当業務ですが、ベイジではプロデューサーもしくはディレクターが主導し、実装はエンジニアが行います。以下のようなサブタスクが存在します。

• MA設定計画
• HTMLソースコードへのタグ埋め込み
• MA各種設定

5-15. サーチコンソール設定

サーチコンソールの設定を行います。登録開始されていない場合には、一連の作業も代行します。サイトマップXMLの生成と登録、各種メッセージの確認と、エラーの通知がある場合の対応を行います。ディレクターとエンジニアと分担して行います。

6. テスト

開発完了後はテストに入ります。通常は10～15日程度となりますが、1カ月近くをテストに費やすこともあります。不具合の改修や公開までの認識合わせを行います。公開まで僅かですが、認識のズレが信頼関係に繋がるため、非常に大事なフェーズと位置付けています。

6-1. リリースミーティング

公開までの手順、積み残しているイシュー、顧客側の課題、顧客への要求事項、公開までに発生するリスク、スケジュール変更の可能性と条件など、テスト公開から公開までにやるべきことや注意事項の全てを洗い出し、プロジェクト内で共有します。時間が迫り、緊張感が高まる公開直前において、プロジェクトが混乱しないように万全を期するのが目的です。ディレクターが主導し、プロジェクトに関わる全メンバーが参加します。

6-2. テスト公開

顧客にベータ版を公開します。テスト公開までに最低限必要な単体テストを行います。またテスト公開直前には、顧客に対してテスト公開前オリエンテーションを行います。ここではテスト公開の目的、注意事項、公開までのタスク、要望対応と前提条件、顧客への依頼事項、発生しうるリスクなどを顧客と共有します。テスト公開では経営層への報告・確認が行われることも多いため、現状のステータスをしっかりと担当者と共有し、無用な混乱が起きないようにします。ベイジでは、要望対応をすべて吸収してからブラウザチェックやバグフィックスを行うため、顧客による最終確認時に検出されたエラーに対する心理的ハードルを事前に下げておきます。顧客とのコミュニケーションはディレクターが担当します。テスト公開前確認やテスト公開作業はエンジニアが担当します。以下のようなサブタスクが存在します。

• テスト公開前チェック
• テスト公開前オリエン
• テスト公開

6-3. 顧客による最終確認

テスト公開後は、顧客による最終確認が行われます。テスト公開前オリエンテーションで共有されたチェック項目を中心に、顧客内で最終確認が行われます。確認期間はプロジェクトの規模に寄りますが、通常3～5日ほどとなります。最終確認で検出された要望は、ベイジから提供する【要望リスト】にまとめられます。

6-4. UXテスト

顧客による最終確認と同時に、UX要件を満たしているか最終チェックを社内で実施します。UXリサーチを担当したメンバーがシナリオを作成し、プロジェクトに関与していないスタッフが招聘され、シナリオに基づいてテストを実施します。シナリオの遂行に障壁となった箇所を記録し、改修要望としてまとめます。長いプロジェクトの中でプロジェクト関係者は客観的視点を失っている可能性がありますが、この時点で大規模なテストを実施するのは現実的ではないため、必要最小限の第三者チェックとしてUXテストを行います。

6-5. 要望対応

顧客による最終確認で上がってきた要望とUXテストで上がってきた改修項目を反映します。顧客の要望対応はプロジェクト終盤で最も混乱するポイントですが、ベイジでは以下のようなプロセスで要望の仕分けを行っていきます。

• スコープ内かスコープ外かを振り分ける
• スコープ外の場合は追加費用と公開後対応を打診する
• スコープ内の要望は公開までに対応必須かどうかを振り分ける
• その上で、各要望の対応時間を積算する
• 公開に間に合わない場合、対応必須ではない要望を公開後に回す
• それでも間に合わない場合、公開延期、代替案提示を行う
• これら仕分けが終わったら、要望対応を開始する

また、要望対応で混乱せず、適切な主張を行うためには、ここに至るまでの顧客との対等な関係構築、認識の共有、心理的ハードルのマネジメントが不可欠です。

6-6. コピーの最終確認

要望対応を実施し、対応内容の顧客確認まで完了したら、コピーの最終チェックを開始します。誤字脱字、表記の不統一チェックのほかに、不自然な行送りの改善などを行います。顧客確認が終わっている状態であるため、意味を変えるような変更は行わず、軽微な改修に留めたコピーの最終確認と調整を行っていきます。通常この工程はブラウザチェックと同時に行われます。なお、ベイジでは現在、WordPress等で使われているDB内を直接参照して自動で表記チェックを行い、置き換えることができる表記チェックツールを開発中です。

6-7. 素材最終反映

有料写真を用いている場合、写真購入を実施します。【写真管理シート】に記載した条件で写真の購入処理を行い、画像補正やレタッチを行ったうえで、HTMLに反映します。購入前のサンプル写真が混在したり、間違った写真が適応されたりしないよう、デザイナーを中心に最終確認を行います。

6-8. ブラウザチェック

ベイジではブラウザチェックは顧客の最終確認が終わった後、公開直前に実施します。顧客の最終確認前に行うと、要望対応時にソースコードの改修が発生し、新しいエラーを生むリスクがあるためです。このタイミングで実施するには、テスト公開時の不具合発生を顧客に許容いただくマネジメントも必要になります。ブラウザチェックはディレクターもしくはエンジニアが作る【テストシート】を用いて実施します。ブラウザチェック以外に、表記チェックやユーザビリティやアクセシビリティも確認します。公開の直前までサイトの品質を少しでも高めていきます。

7. 公開と運用準備

最終確認と調整を行いサイトを公開します。公開と合わせて運用準備も始めます。webサイト制作のプロジェクトとしては一旦完了しますが、保守や改善の契約がある場合は、引き続きプロジェクトが継続します。

7-1. リダイレクト設定

公開前後にリダイレクト設定を行います。SEO戦略などを反映した【リダイレクト設計書】を作成し、テスト公開オリエンテーションで顧客と共有します。合意内容に基づき、公開直前にリダイレクト設定を施します。エンジニアが担当します。

7-2.リリース計画

公開当日のタスクおよび確認項目などを【リリース計画書】としてまとめます。リリース計画書に基づき、当日の公開作業を実施していきます。エンジニアが担当します。

7-3. 公開判定から公開

公開可能になった段階で、顧客に公開判定を依頼します。公開の承諾が取れ次第、公開作業が実施されます。エンジニアが担当します。

7-4. 公開後テスト

公開直後にもテストを実施します。開発環境と本番環境で差異が生じることがあるため、リダイレクト、ログ解析やMA、フォームなど、クリティカルな箇所を中心に最終確認を行います。ディレクター、デザイナー、エンジニアが手分けして行います。

7-5. 運用ルール策定

ベイジで運用を行う場合、公開までに運用ルールの策定を行います。運用上の基本ルールや実施タスクを定義した【運用設計書】、および更新等を依頼するときの【作業依頼書】といったフォーマットを共有し、運用開始ミーティングを行って、スムーズな運用開始を目指します。主にディレクターが担当します。

7-6. マニュアル作成

CMSを導入して顧客側で運用を行う場合は、必要な手順を記載した【運用マニュアル】を納品します。CMSの設定方法以外に、必要に応じてサムネイル画像の制作ルールやコピーの記述ルールなども記載します。担当者の交代やサポートメンバーの増員にも対応できるマニュアルとして作成します。主にエンジニアが担当します。

7-7. オリエンテーション

マニュアル納品時に1～2時間のオリエンテーションを実施し、基本的なオペレーションを解説します。ベイジでは、オリエンテーション後もメールや電話での質疑応答は可能です。自社でサイト運営ができるまで顧客をサポートします。ディレクターもしくはエンジニアが担当します。

7-8. クロージングミーティング

公開後1～2週間以内に、プロジェクトメンバーを集めてクロージングミーティングを実施します。プロジェクトの課題や問題点が話し合われ、具体的な改善策を導き出します。改善策には期限を設定し、それまでにワークフローやドキュメントに改善を加えていきます。こうして新しいタスクやドキュメントが作られ、組織は成長していきます。このように失敗から学んで成長するためには、細かくタスク化されたワークフローだけでなく、常に改善を加えていくクロージングミーティングが不可欠です。これにより、仕事をするほど洗練化され、メンバーのノウハウが強化され、人も組織も成長していく仕組みを目指します。

ワークフローを作る意義

web制作で実施されるタスクを細かく分解し、整理し、ワークフロー化していくことは、工場の製造工程を設計する行為に近いものがあります。だからといって、私たちは全ての工程で機械的に仕事がしたいわけではありません。確かにワークフローの根底には『ザ・ゴール』で描かれた生産性を重視する考え方があります。しかし私たちが重視したいのは、クリエイティブで属人的で定型化できない仕事により多くの時間を割くことです。

仕事を細かく分解していくと、定型化しているタスクと定型化できないタスクに分かれます。前者のタスクは、テンプレート化し、属人性を廃し、品質に影響を与えない範囲で時間を削り、生産性を高めるべきです。一方の後者は、クオリティやクリエイティビティを重視し、プロジェクトの中で許される限り時間を使っていくべきです。前者のようなタスクの時間が減れば、後者のようなタスクに割り当てる時間も増えます。

これが私たちが狙っていることです。これは働き方の改善にも繋がります。有効な時間の使い方こそ、ワークフローの整備を通じて私たちが目指していることです。そして、ここで共有したノウハウが、web制作に関わる多くの方々の働き方をより良くする何かのキッカケになれば幸いです。

解析ツールの設置自体は非常に簡単です。正しく設置すればすぐデータは収集されます。しかしデータの扱い方、解釈の仕方を適切に捉えることが難しく、このことがアクセス解析の活用を困難にしています。

ここでは、私が今まで実際で聴いたアクセス解析に対する誤解とその解説を10個ピックアップしました。本エントリーを通じて、アクセス解析に対する理解が少しでも進めばと思っています。 

1. 機能が多すぎて使いこなせない
2. サイトのページビューを2倍にしたい
3. サイトの直帰率が50%を超えていてどうにかしたい
4. リニューアルで操作性が向上したかを確かめたい
5. 検索キーワードはもう分析に使えない
6. 離脱率を改善したのにお問い合わせが増えなかった
7. リニューアルしたら直帰率が1桁になって大成功
8. 改善したのにコンバージョン率が下がって問題だ
9. 一番アクセス数が多いホームから手直ししたい
10. SEOをやってもコンバージョンに繋がらない

1. 機能が多すぎて使いこなせない

アクセス解析を持て余している企業から「機能が多くて複雑で使いこなせない」という話を聞くことが多いです。確かに解析ツールには様々な種類のメニューが並んでいます。このメニューを上から順に選び、それぞれの画面上に表示されるすべての機能を使おうとすると、確かに「機能が多すぎてとても全部は使いこなせない」と思うでしょう。しかしまずは「全部使いこなすべき」という考えを捨てるべきです。全部の機能を使いこなせなくてもいいのです。

アクセス解析は仮説検証のための手段です。つまり、解析の元となる仮説がない人にとっては、そこに並んでいるのはただ数字の塊です。解析を始める前に、課題・問題の仮説を立て、その仮説の裏が取るために、どういう数字を知りたいのか、まずそれを決めておく必要があります。

例えば、大規模なサイトリニューアルであれば、事業課題から導き出されるサイトの課題、ペルソナ、カスタマージャーニーからサイト内の行動動線が事前に設計されることでしょう。ベイジで手掛けたあるアクセス解析のプロジェクトでは、アクセス解析を始める前に、以下のような資料を用い、ターゲットやサイト内動線、商材特性、外部要因、コンテンツ戦略などの整理を行いました。

こういった青写真ができた段階で、理想のサイトと現サイトとの乖離を検証するために、アクセス解析ツールを用いるのです。このとき、アクセス解析ツールのすべての項目をチェックするわけではありません。ホームにはどのチャネルからどのくらい流入しているのか、相性がいいチャネルはどれか、コンバージョンに繋がっているユーザーと繋がってないユーザーで、最初に着地するページやその後経由するページにどういう違いがあるのか、PCとスマートフォンでは見ているページや時間帯などにどういう違いがあるのか。

事前に仮説やシナリオがあれば、確かめたいことがいくつか出てくるはずです。その調べたいことだけを見ればいいのです。そのための操作が分からないときは、ネットで検索すればだいたいのことは分かります。

アクセス解析においてまず大切なことは、目的を明確にすることです。目的を達成するのに最低限必要な機能だけ使えばいいのです。最初から多くの機能を使いこなす必要はなく、分からないことは調べながら使っていけばいいのです。

2. サイトのページビューを2倍にしたい

この類の目標設定は、企業から提示されるRFP（提案依頼書）でよく見かけます。とても勇ましい目標に見えますが、ページビューというものに関する大きな誤解を含んでいるように思えます。

何が目的のサイトかによりますが、ページビューの数字は、例えばお問い合わせ数や資料請求数などと相関することはほとんどありません。つまり、ページビューが多い／少ないことと、サイトが成果を出している／出していないこととは、ほとんど関係がないというわけです。

例えば、ページを分割して数を増やすだけでページビューは簡単に増えます。しかしページを分割してページビューを2倍にしたからといって、問い合わせが2倍に増えたりはしないでしょう。

またそもそも情報獲得意欲の高いユーザーは、UIの出来が悪くても迷いながらも耐え忍んで操作するため、訪問あたりのページビューは大きくなりがちです。このようなサイトを使いやすく改善すると、全体的にページビューが下がるという現象が起こりえます。しかし、ページビューが下がったとしても、サイトが使いやすくなってユーザーを適切に誘導できるようになったなら、それは好ましいことではないでしょうか。

このように、ページビューの増減はKPIとほとんど相関しません。ページビューは広告モデルのwebサイト以外では参考にならないと考えてしまってもいいでしょう。こういった成果と相関しない指標を目標にしても意味がありません。リニューアル後も成果と関係ない数字を見て一喜一憂するだけです。

3. サイトの直帰率が50%を超えていてどうにかしたい

「直帰率を下げたい」というのもよく聞く話です。サイト全体の直帰率が50%を超えているのは確かにやや高いかもしれませんが、それだけでサイトに問題があるとは言い切れません。

例えばサイトが全体で100ページあり、そのうち80ページがブログだったとしたらどうでしょう。ブログは一般的に直帰率が高く、80%を超えることも珍しくありません。直帰率が高いコンテンツが多くを占める場合、サイト全体の直帰率は当然高くなります。しかしだからといって問題というわけではありません。

また質が低い広告を大量に打っている場合にも、サイト全体の直帰率は高くなるでしょう。しかしこの時にまず見直すべきは、webサイトではなく広告です。

アクセス解析ツールにログインすると、多くの場合は以下のようなダッシュボードが真っ先に表示され、サイト全体の状態が目に入ってきます。そこにはサイト全体の直帰率も表示されています。

しかしこのような「サイト全体の数字」は、ほぼ参考になりません。ページ、カテゴリ、チャネル、ユーザー種別などでセグメントされた情報を複数見比べないと、まともなことはほとんど分かりません。ダッシュボードだけを見て何かを判断するのではなく、情報をセグメントして細かく見ていくのが、アクセス解析の適切な使い方と覚えておいた方がいいでしょう。

4. リニューアルで操作性が向上したかを確かめたい

リニューアルの成果を実証するため、このようなことを相談されることもしばしばあります。しかし厳密にいえば、アクセス解析で操作性が向上したかを確かめることはできません。なぜならアクセス解析には「操作性」という指標が存在しないためです。これを知りたいのであれば、アクセス解析上の別の数字に置き換えて類推しなければなりません。

例えば操作性であれば、以下のような数字を追うことで、それに近い評価ができるでしょう。

• 対象となるプロセスの平均ページビューが減った
• 対象となるプロセスの平均閲覧時間が減った
• 対象となるプロセスの完了率が上がった

上記の複数の指標がすべて満たされることで、操作性が上がったと判断するわけです。このように、直接的な指標がない場合には、代替する指標の組み合わせで類推していきます。それは例えば、以下のような図で表すことができます。

ただしこれらが本当に「操作性」を表すのか、冷静に考える必要もあります。平均ページビューや平均閲覧時間が減らなくても、「操作性が良くなった」とユーザーが感じる可能性はないでしょうか。突き詰めれば、本当に操作性が向上したか知る手段として、アクセス解析は適切ではなく、同じ定量系の調査ならヒートマップ分析、あるいは定性に切り替えてユーザーテストで検証すべきかもしれません。

このように、アクセス解析では分からないこともたくさんあります。そのことが本当に知りたいなら、アクセス解析上の指標だけで無理やり考えるのではなく、別の手段を考えてみる柔軟さも大切です。

5. 検索キーワードはもう分析に使えない

Googleにログインしたユーザーは常時SSL化されているため、webサイトの訪問に使った検索キーワードも暗号化されてしまい、アクセス解析では集計されなくなっています。多くのwebサイトでは、90～95%くらいのキーワードが(not provided)と表示されているのではないでしょうか。代替手段としてSearch Consoleやランディングページを使った分析も行われていますが、キーワードグループごとの直帰率やコンバージョン率が確かめられないため、解析の効果は未知数といえます。

しかし、アクセス解析にも統計の基本的な考え方である「部分から全体を推測する」は当てはまります。例えば自然検索からの流入が月間10万セッション以上あるwebサイトであれば、その1%でも1,000前後のキーワードが見えているはずです。これらのキーワードをグルーピングし、グループごとのコンバージョン率や直帰率を比較することはできます。一か月に1万セッションしかないwebサイトでも、計測期間を1年にすれば、12万セッションになり、この1％であれば1,200のキーワードが取得できます。このくらいの数があると、部分から全体を類推することが可能になります。

アクセス解析は基本的に「正しい数字を把握する」ためのツールではなく、「大雑把な数字の傾向を見る」ためのツールです。そのため、「見ることができなくなった→分析できなくなった」と安易に考えるのではなく、見ることができる情報を活用して推測できないか、という視点を持つとよいでしょう。そうることで、より活用の幅が広まるはずです。

6. 離脱率を改善したのにお問い合わせが増えなかった

クライアントの口からこのような言葉が出てきた場合、まず直帰率と離脱率の区別がついているか確認しましょう。理解したうえでこのように考えている場合には、離脱率に対する認識や期待が間違っているということになります。理由は単純です。離脱率は、コンバージョン率／数と関係ない、というだけのことです。

離脱率とは、離脱数をページビューで割った数字です。この場合、分子の離脱数は訪問数だけ発生します。100の訪問があれば100の離脱が起こります。一方、分母のページビューは、訪問数と相関しません。100の訪問に対して200なことも1000なこともあります。離脱率は、単にページビュー次第で増えたり減ったりします。そしてページビューは先ほどお話ししたように、コンバージョンとほぼ相関しません。その場合、ページビューから抽出された離脱率もまた、コンバージョンと相関しないのです。このケースでは、離脱率に目を付けて改善した行為自体が適切ではなかった、ということになります。

アクセス解析は、いくらオペレーションに習熟し、用語の意味を理解していたとしても、その指標が持つ意味や特性が分かってないと、有益な結論が得られません。意味や特性を理解し、それは果たして成果と相関する指標なのか？と常に疑問を持ちながら考え続けることが必要です。

7. リニューアルしたら直帰率が1桁になって大成功

きちんとリニューアルを行い、それが狙い通りの成果を出せば、当然数字が良い方向に変わるでしょう。直帰率は分かりやすい数字であり、リニューアルが成功して改善することも多いです。しかし、過去に数件、リニューアルによってサイト全体の直帰率が10%以下に急落したケースを見たことがあります。

担当の方は「大幅な効果が出た！」と喜んでいましたが、私はすぐに「これはおかしい」と思いました。いくら効果が出たとはいえ、サイト全体の直帰率が1桁というのは異常と思えたからです。サイト全体では参考にならないのでセグメントして見たのですが、やはり極端に低い直帰率ばかりでした。設定ミスを確信して再調査を求めたところ、案の定、Google Analyticsのタグが2重に設定されていることが分かりました。（ちなみにこれは、お客様側でタグ設定した案件です）

このようにタグの2重計測は分かりやすい例ですが、間違った分析をしているのに、気付かずに解釈してしまうケースはしばしば起こりえます。

例えばセグメント機能は間違いやすい機能の一つです。セグメント機能はカスタマイズできるのですが、集計の基準をユーザベースにするか、セッションベースにするかで、数字が大きく変わります。セグメント機能には以下のように、右側にそのセグメントのユーザー数が表示されるようになっていますが、これも意図しない設定をしてしまうからこその機能でしょう。しかしそれでも複雑なカスタマイズをしたときは、いくつかのレポートを表示し、意図した計算結果になっているかを確かめる必要があります。

このように、アクセス解析ツールが出力している数字を単純に見ているだけでは、判断を誤る可能性もあります。設定を変えたとき、セグメントを変えたときなどは、それが意図した設定になっているか確認する必要があります。特に極端な数字や想定と大きく外れた数字が計測された場合には、すぐに一喜一憂するのではなく、まずオペレーションミスを疑ってみましょう。

8. 改善したのにコンバージョン率が下がって問題だ

コンバージョン率は目標にされやすい指標ですが、コンバージョン率を目標にすべきケースは、実はそれほど多くないと感じます。

例えばサイトを改善して流入が増え、本来顧客にならない訪問者が増えると、コンバージョン率は下がります。それでも同じコストのままコンバージョン数が増えているのであれば、事業上は成功のはずです。例えば以下の図のような状況は、企業にとって望ましい状況のはずですが、コンバージョン率を基準にすると、事業への貢献度が下がったかのように見えてしまいます。

また、流入が減る様なリニューアルを行ってしまい、結果的に購買動機の強い訪問者だけが残るような特性のwebサイトになると、コンバージョン数は下がるがコンバージョン率は上がる、という現象も起こります。

ページビューほどではありませんが、コンバージョン率も基本的には事業上のKGIと相関しにくい数字であり、多くの場合、真に気にすべきはコンバージョン数です。もしくは、コストに対するコンバージョン数（CPA）です。このように、事業上の成果をきちんと相関する指標を設定しないと、せっかくのアクセス解析も事業に活かすことができないでしょう。

9. 一番アクセス数が多いホームから手直ししたい

ホーム（トップページ）というのは、サイトの顔になるページであり、多くのサイトでは最もトラフィックがあるページとなっていることでしょう。それ故に、webサイトのパフォーマンスに問題があると、真っ先に改善対象にされてしまいがちです。しかし、ホームを優先的に改善すべきかどうかは、訪問の多さだけで決めるべきではありません。

例えば、ホームへのランディングは訪問の40%を占めるが、直帰率は30%以下、一方のサービス紹介の各ページへのランディングは訪問の15%ほどだが、直帰率は70%を超えているような場合。

ホームは直帰率が既に30%以下であり、これ以上の改善効果は見込めません。一方サービス紹介は直帰率に改善の余地があり、ここから手を付けた方がコンバージョン数の増加に繋がる可能性が高いでしょう。

しばしば、「ホームからのコンバージョン率が高いので、やっぱりホームの改善が最優先だ」といった話になることもあります。しかし改めて分析すると、問い合わせ目的で再訪問する人がホームを使うから結果的にホーム経由のコンバージョン率が高くなっているだけ、ということも多いです。こういうユーザーはホームがどんな出来でもそれなりにコンバージョンしてしまうので、やはり改善して大きな効果は望めません。

このように、単純に訪問数が多い、サイトの顔となるホームだから大事、と安易に決め付けるのではなく、トラフィックの規模、改善の可能性、改善の容易さなどを総合的に判断して優先順位を決めなくてはなりません。

10. SEOをやってもコンバージョンに繋がらない

ユーザーや集客レポートにもコンバージョン率やコンバージョン数を表示した列があります。例えば「チャネル」を選ぶと、以下のように右側にコンバージョンの列が表示されます。

これを見ればチャネルごとのコンバージョン率/数が手っ取り早く確認できます。しかし注意しなければならないのは、ここで見えている数字はコンバージョンが発生したセッションのみの集計結果ということです。

例えば、再訪問してからコンバージョンすることが多いサイトの場合、コンバージョンしなかった1回目の訪問はコンバージョンの数字として当然ながらカウントされません。しかし、再訪問時にコンバージョンしているのなら、1回目の訪問とそれに使われたチャネルも評価されるべきでしょう。

例えば一回目の訪問で自然検索がよく使われて、二回目の訪問ではあまり使われない場合、自然検索で訪問するユーザーはコンバージョンに寄与していない、と見えてしまう可能性があります。

こういった複数の訪問をまたいだ分析をするために、コンバージョンするまでの複数の訪問経路をレポーティングした「コンバージョン経路」や、コンバージョンの起点・終点を詳細に分析できる「モデル比較ツール」といった機能が用意されています。

しかしこの2つの存在を知らないと、単純にコンバージョンしたセッションだけでチャネルの価値を判断し、改善の優先度・重要度を見誤ってしまうでしょう。

アクセス解析は、レポートの意味をきちんと理解していないと、誤解する可能性があります。なんとなくメニューを触って、それっぽい数字やグラフを見て満足するのではなく、言葉の定義や各メニューの使い方などをきちんと理解して使わなければ、本当に有用な情報を引き出すことができません。

冒頭では「すべての機能を使いこなす必要はない」というお話をしました。それは確かにそうなのですが、これは言葉の意味や成果への影響を短絡的に判断してもいいという話ではありません。「これはどういう意味なのだろう？」「もっと他に相応しいレポートがないのだろうか？」と疑問を持って、調べながら使っていく必要があります。

まとめ

現在は、あらゆる職種において、データの裏を取ることが求められる時代です。デザイナーもエンジニアなどは、アクセスログの見方をある程度知っておかなければ、まともにディスカッションに加わることができないことも多いでしょう。

アクセスログを見ること自体は簡単です。しかし難しいのは「適切に見ること」と「良いアイデアを導き出すこと」です。これは一朝一夕で身に付くわけではありませんが、上記のような誤解や失敗の例から、そのコツを少しは掴めたのではないでしょうか。このエントリーがその一助になれば幸いです。

そんな中、最近気になっているのが、新たなデザインツールとして徐々に広まりつつあるSketch。海外ではPhotoshop並みに使われているという調査もありします。そこでPhotoshop歴10年（途中3年ほどFireworks）の弊社アートディレクター兼デザイナーの荒砂が、PhotoshopとSketchの機能を比較し、最終的にどう判断すればいいか、スライドにまとめてくれました。

詳細はスライドを見ていただくとして、特に異なっている点だけを表にまとめて比較すると、以下のような感じになります。

○：機能として存在し、優れている
△：機能として存在するが、やや劣っている
×：機能として存在しない、もしくは大きく劣っている

結果として、Sketchは機能を絞り込んでいるため、Photoshopのようになんでもできるツールにはなっていませんが、UIデザインやWebデザインに特化している分、より使いやすく軽量というのが最大の特徴になっています。位置づけとしては、Photoshopに対するかつてのFireworksに近いものを感じました。

複雑な画像編集を必要とせず、書体もOSやWebフォントで用意されているものを呼び出すだけで、画像テキストをほとんど作らないようなアプリケーションのUIデザインでは、非常に重宝するツールであると感じます。

Photoshopの優位性であるテキストや画像の編集機能は、フラットデザインやマテリアルデザインのようなシンプルなデザインが主流になっている今の時代には、使用頻度は低い機能ではないかと思います。そう考えると、ますますSketchが魅力的に見えてきます。

ただ、結果として弊社ではSketchの導入を見送りました。一番の理由は「Windows版が用意されていない」という根本的な問題です。Sketchのメリットを享受するには、少なくともデザイナーとフロントエンドエンジニアはSketchを使う必要があり、そのためにはメインマシンをMacに変えなくてはなりません。

ところが、直クライアント案件が多く顧客から提供される資料はほどんとがWindowsで作られている、作るのはPCサイトがまだまだ多くそのターゲットはほとんどがWindowsユーザである、クロスワークを推奨しておりデザイナーが設計やエクセル仕事やディレクションをするなどの作業が想定されるなど、弊社ではWindows環境であることが不可欠です。それに対し、制作スタッフ全員をMacへ乗り換えさせるほどではないかな、と判断して導入を見送りました。

つまり、Photoshopが劣っている面は確かに多々あるものの、それはそれほど致命的ではなく、他の方法で解消可能である、という結論になったということです。

私としては、もしすでに開発環境がMacに統一されているような会社で、テキストや画像をゴリゴリ編集するような仕事が少ない場合には、制作環境をSketchにしてしまってもいいように思います。

しかし、Windows環境に統一もしくは混在していたり、あるいは画像加工系の仕事が結構多かったりする会社の場合には、無理をしてまでSketchに移行する必要はないかな、と感じました。最終的には、チーム全体の生産性を総合的に考えたうえでの判断でよいでしょう。

ただ、UIデザインの流れを考えるとSketchは非常に魅力的なツールで、Windows版がリリースされるか、別の理由で弊社の制作環境をMacに統一するようなことが将来あった場合には、再びSketchに乗り換えることを検討してみたいと思います。

その冒頭でも触れたのですが、私自身はWebデザイナーとしてこの業界に入り、Webデザイナーとしての影響力を高めるためにディレクションやプロデュースに足を踏み入れただけで、今も昔も、Webプロデューサーという仕事を目指したことはありません。

そのため、私は果たしてWebプロデューサーなのか？と問われるとよく分からなくなります。自分が行っている業務内容でいえば、デザイナーでもあるし、アナリストでもあるし、インフォメーションアーキテクトでもあるし、UXデザイナーでもあるし、営業マンでもあるし、経営者でもあります。それを分かりやすく説明できる職種が「Webプロデューサー」という気がして、この曖昧な肩書を利用しているだけだったりします。

なので、これが正しいWebプロデューサーだ、と主張するつもりはまったくなくて、あくまで私の場合はこんなことを意識しています、というレベル感で読んでもらえると幸いです。

その１　クライアント担当者に流されない

Webプロデューサーといえば「クライアントに貢献する」みたいなことを最大のミッションにすることも多いと思いますが、これは「クライアントの要求通りに動く」ことではないと思っています。

クライアントが生業としているビジネスについては、私たちよりもクライアント担当者に知見があることがほとんどですが、一方で必ずしもWebのプロというわけではありません。また大きな会社になると組織の力学が働き、本来目指すべきことが歪められて別の目的にすり替わることもあります。

こういったクライアント自身が抱えている問題や矛盾を正し、本来の目的に軌道修正させることもまた、Webプロデューサーの役割ではないかと思っています。言い換えるなら、「自分がクライアントの担当者だったら」という視点ではなく、常に「自分がビジネスオーナーだったら」という視点で物事を客観的に、ある面では冷徹に判断しなければならないと考えています。

その２　制作スタッフに流されない

Webプロデューサーなら、Webの制作スタッフと関わることも少なくないでしょう。その時、クリエイター経験があったり、クリエイティブに深い造詣があったりする場合、どうしても制作者の視点が強くなることがあります。

それ自体が悪いわけではありませんが、私たちの会社の場合、Webプロデューサーに求められる本当のゴールは「素晴らしいビジュアルデザインを作ること」「最新のテクノロジーを実装すること」ではなく、「ビジネス上の課題を解決する」であることがほとんどです。クリエイティブはそのための手段であり、本当のゴールを見失ってはならないといつも意識しています。

時間とお金をかければいわゆる「良いもの」に仕上がる可能性も高まりますが、投資に対するリターンとのバランスを見極めるのもWebプロデューサーの役割です。その１と合わせていえば、クライアントの担当者の味方にも、制作スタッフの味方にもならず、独立した思考で状況を俯瞰するのがWebプロデューサーの仕事ではないかと考えています。

その３　営業をかけない

トークセッションでは「Webプロデューサーは営業をしてはいけない」と発言したのですが、これは偽らざる私のポリシーです。Webプロデューサーが営業的な役割を兼ねることも珍しくはないと思いますが、プロデューサーは営業的視点をもってはいけない、と私は思っています。

前述のように、Webプロデューサーは独立した視点で状況を俯瞰し、ビジネスゴールに対してどうするのがベストか、という視点で常に動かなければいけません。そこに営業という「邪念」が加わると、本来必要ないソリューションをねじ込むように提案したり、プロジェクトの予算規模を拡げたりといったことを優先して行動しがちです。

Webプロデューサーの本来の仕事を考えると、できるだけ少ない予算で最大限の成果を生み出す方法を考える、という視点も必要です。営業ノルマ達成のために1000万円の売上げが必要だから、1000万円になる提案をする、などという発想であってはいけません。ビジネス特性や現実的なリターンから考えられる妥当な金額が800万円であれば、800万円の提案をすべきでしょう。

だからこそ私は「営業しない」「売り込みはかけない」「本当に必要なことだけ、必要な分だけを提案する」というポリシーを強く持つようにしています。

その４　知識は広く深く、マーケティング中心で

Webプロデューサーには当然Webに関わる幅広い知識が必要ですが、それを結びつけるのはマーケティングの知識でしょう。

私自身、元々はWebデザイナーでしたが、マーケティングを意識的に学ぶようになってから、デザインの美観やユーザビリティ起点ではなく、その上位にあるマーケティングを起点に物事を捉えるようになりました。プロジェクトを俯瞰する仕事だからこそ、ビジネスを俯瞰できるマーケティングの知識は不可欠です。

一方でWebプロデューサーはテクノロジー、コピー、デザインの専門家でもなければなりません。その知識が多いほど力が増す仕事です。そのため私も、デザインやフロントエンド、サーバサイド、制作ツールに至るまで、専門スタッフとの勉強会などを通じて、最新トレンドを幅広く収集しようと努めています。この分野は苦手だから自分はいいや、ではなく、Webに関わることは幅広く関心を持ち、できるだけ深く掘り下げなければWebプロデューサー職は務まらないと感じます。

その５　データドリブンになる

Webが他のメディアと大きく違うのは、データが取りやすい点でしょう。だからこそWebプロデューサーはデータの取り扱いに長けているべきです。

サイト全体の数値であれば誰もがサラっと見ると思いますが、全体を平均化したサマリーにほとんど価値がないことをWebプロデューサーは知っておかなくてはなりません。大事なのは仮説を持ち、データをセグメントして細かく見て確認すること、細かなデータからインサイトを得ることです。

企画を立てるなら、その成功の指標を定義すべきでしょう。データ取得を目的としたコンテンツの企画も時には必要になります。そして公開後は、計画が実行されているか数値で確認し、うまくいってなければ、改善の指針を打ち出す。ここまで関与するのがWebプロデュース業なのだと思います。

Webプロデューサーが解析ツールを触るべきか、という点については議論が分かれるところでしょうが、私は自身でツールを触り、できるだけ自分の目で確かめるようにしています。なぜなら、数字を自分自身の目で確かめることで、ユーザーの行動が肌感覚で予測できるWebプロデューサーになれると考えているためです。

その６　一般論や成功事例ではなく、現実を見る

理論や事例は、勉強していて楽しいものです。ためになる理論や事例に触れると、自分も同じ成功を手にできるのでは、という想像が膨らみます。もちろん、こうした勉強が非常に大事な基礎を築くことは間違いありません。

一方でWebプロデューサーには「現実を見る」という使命もあります。限られた予算、差別化しにくい製品、見えないターゲット、硬直化した社内体制、リスクを嫌う社風、戦略と矛盾するトップの意向など。個別の事情を見つめれば、理論や事例の使いまわしは役に立たないと気付きます。

先駆的な最新事例や海外事例を紹介するのは、あえて言えばエバンジェリストの役割であり、Webプロデューサーの主体業務ではありません。ビジネスが本当に求めていることに対して、理想と現実との調整を効かせ、クライアントのビジネスにきちんとフィットするアウトプットまで導くのがWebプロデューサーの重要な責務の一つと考えています。

その７　却下ではなく代替案

クライアントの希望に必ずしも応えられないケースが出てきます。この時に「できない」と却下するか、代替案を提案するかで、Webプロデューサーの成長を大きく変えます。

計画通りで何も起こらずにプロジェクトが進むことは稀です。戦略実行の社内合意が取れない、技術的には可能だが政治的問題で実現が難しい、ブラウザやハードウェアの問題でアイデアがそのままでは実現できない、力のある部署から予期せぬ追加要望が生まれてコンセプトが揺らぐ。Webプロデューサーとは、次々と出現するこういった障壁に対して、常に新しいカードを切りながらゴールを目指す仕事ではないでしょうか。

そのために必要なのが広く深い知識であり、状況をコントロールするコミュニケーション能力です。こうした次々と現れる障壁を乗り越えるときに、「却下ではなく代替案」というマインドがなくては、考えたことの1割も実現できない、ということになるのだと思います。

その８　フェアプレイに徹する

Webプロデューサーが「もう一人のビジネスオーナー」であるということは、自分には不利な情報も明らかにする、という姿勢が不可欠です。これを伝えたら難色を示す、リスクを伝えるとわずらわしいタスクが増える、弱点を明らかにすると意見が覆り売上げが減少する、などといった判断でネガティブな情報を隠すことはあってはなりません。

また、機能やデザインを過大評価したり、大げさに効果を強調したりするような伝え方も控えるべきでしょう。脚色された情報ばかりを話していては、やがて話を信じてもらえなくなります。

リスクを隠して一時的に時間的・経済的メリットを得ても、リスクが顕在化した瞬間、そのWebプロデューサーの信頼は失われます。短期的に利益を得ても、長期的には不利益になります。結局、プロデューサーが長期間にわたり評価されるには、フェアであることが一番の近道なのだと私は考えています。

スマートフォン向けのWebサイトのデザインを考える上で、アプリのUIデザインの定石を知ることは重要です。なぜなら、スマートフォンにおいてはWebサイトをブラウズする機会は14％しかなく（comScore調査／2014）、多くの時間をアプリの中で過ごしているためです。さらにユーザは「これはアプリ」「これはWebサイト」という区別はしていません。そのため、一般的なアプリとWebサイトの振る舞いが異なると、ユーザを戸惑わせる原因になりえます。

AppleとGoogleのガイドラインを比較する目的は、両者に共通する部分、いずれかが優れた部分を抜き出し、スマートフォン向けのWebデザインにおけるセオリーを学習するためです。

以下は、主な比較項目をまとめたスライドです。詳細はスライドを見ていただくとして、要点のみをこのエントリーでは記載しておきます。

1. 文字

1-1. 最小サイズ

欧文＝11pt、和文＝13pt

Apple、Googleともに文字の最小サイズに関する具体的な指定があります。双方を判断し、欧文は11pt相当、和文は13pt相当を最小サイズとするのが良いでしょう。

1-2. 見出し

13pt←15pt（基準）→17pt→21pt→24pt→34pt→45pt→56pt→112ptでサイズ変化

Appleには指定がありませんが、Googleでは、 欧文・和文ごとに、サイズ、ウエイト、行間についてかなり細かく指定されています。Googleのガイドラインはあくまでマテリアル・デザインのためのガイドラインであるため、厳密に踏襲する必要はないでしょう。ただ、デザインをシンプルにするためには、見出しの装飾を極力抑える必要があり、そうなると、文字サイズの違いで見出しレベルを表現しなければならなくなります。その参考値として、Googleが規定している文字サイズを捉えておくとよいのではないでしょうか。

1-3. 行長

欧文＝60字以内、和文＝30字以内

Appleに指定はありませんが、Googleには欧文のみ、本文は60文字以内、見出しは40文字以内で折り返すという指定があります。これを参考とし、欧文では60字以内、和文は30字以内を行送りの基準と捉えるといいでしょう。

1-4. 字間

大きな文字は狭く（-5～-10）、小さい文字は広く（+5～+10）

Apple、Googleともに、文字が小さいほど字間を広くし、大きいほど狭くすべきと書かれています。Googleではトラッキングの値も明確にされています。こちらも厳密に踏襲する必要はありませんが、大きな文字は狭く（-5～-10）、小さい文字は広く（+5～+10）、という定石があると捉えておくとよいでしょう。

1-5. 書体

書体の種類、ウエイトはできるだけ少なく

Appleでは書体を一つに絞る、Googleでは決められた書体を使う、と規定されています。書体はCIやブランド戦略が優先されるべきであり、やはり厳密に踏襲する必要はありません。ただし、書体数、ウエイト数はできるだけ少なくする、というのがセオリーであることは、念頭に置いておくとよいでしょう。

1-6. 色

文字色と背景色の輝度を「4.5:1」以上に

Apple、Googleともに、文字色と背景色のコントラストに関する具体的な規定があります。Googleは色の指定まで行っていますが、これを遵守するとブランドに合わせた配色ができなくなります。ここではAppleのガイドラインを優先し、輝度を「4.5:1」以上の比にする、と捉えておくと良いでしょう。

2. ボタン

2-1. サイズ

横96px×縦96px以上（物理サイズ9mm×9mm以上）

Apple、Googleともに、ピクセル数や物理サイズの規定があります。やや大きめのGoogleを参考値とするのがよいでしょう。

2-2. 形

一般的な形状で、種類は3つ以内に

Apple、Googleともに、形状に関する記述があります。Appleはテキストのみの表現としていますが、これは難しい制約でしょう。フラット（文字のみ）、ライズド（長方形）、フローティングアクション（円形）と3種類の形状を設定しているGoogleのガイドラインの方がより現実的といえます。厳密に守る必要はありませんが、一般的な形状を採用する、種類は3つ以内に押さえる、と捉えておくとよいでしょう。

2-3. 装飾

立体表現を用い、最低限の装飾を施す

Appleではグラデーションやドロップシャドウなどの立体表現を非推奨とし、Googleでは立体表現の活用を推奨しているのが対照的です。フラットデザインのミニマリズムは継承しながら、より分かりやすいUIを規定したのがマテリアル・デザインという歴史に習うわけではありませんが、やはりGoogleのガイドラインの方が現実的でしょう。装飾過多になるは避けながらも、立体表現も活用し、リンクをリンクと認識できるルールをサイト内に敷設すべきです。

2-4. マージン

ボタン同士は16px以上離す

Googleのみ、隣接するボタン同士は16px相当以上空ける、という規定があります。基本的にはこれを参考値として捉えるとよいでしょう。

2-5. ラベル

シンプルな動詞を用いる

ボタンのラベル（文字）について、Appleのみがシンプルな動詞を用いるべきという記述があります。Webサイトもこれに準じるのが良いでしょう。

2-6. 配置

目的を達成するボタンを右、行動を取り消すボタンを左に

行動を選択させるボタンを左右のどちらに配置するか、ということについて、Appleでは破壊的かどうか、Googleでは肯定的かどうかを基準としています。UXに従って考えるべきで、通り一辺倒のルール化は禁物ですが、多くの場合、目的を達成するボタン（「確認」、「実行」など）を右側、行動を取り消すボタン（「キャンセル」「クリア」など）を左側に置くのが基本と捉えておくのがよいでしょう。

3. 配色

3-1. 原則

色を多用せず、基本色は2色以内に。機能上の必然性に従いルール化

Appleでは、色は対話の手段であり使いすぎてはいけない、と記述されています。Googleではプライマリカラーとセカンダリカラーの2色を選び、さらにその各色から3色相を選ぶ、という具体的な規定がなされています。色もブランド戦略の影響を受けるものであり、何も考えずAppleやGoogleに従うべきではありませんが、色は機能を補完するもの、ユーザフレンドリーなUIにはシンプルな配色が望ましい、という基本は押さえておくべきでしょう。

3-2. コントラスト

前景色と背景色の輝度を4.5 : 1以上に

Appleには数値化された明確な規定があり、Googleには「コントラストを確保する」という緩やかな記述があります。様々な光量下での閲覧が想定されるスマートフォン向けのWebサイトでは、コントラストがユーザビリティに大きな影響を与える可能性があります。ここではより厳密なAppleを踏襲し、前景色と背景色の輝度比を「4.5 : 1」以上に保つと考えておきましょう。

4. アイコン

4-1. 形

シンプルで分かりやすいものに

両社ともにシンプルであるべきと規定されています。Appleではストロークについて、Googleではベースの形状にまで言及していますが、シンプルという大きな指針のみ、参考にするのが良いでしょう。

4-2. 色

基本は単色。非選択時は塗り方とコントラストも調整

Appleでは、選択時と非選択時の色の塗り方に関する言及があります。Googleでは、色の濃度を%で指定しています。双方とも厳密に守る必要はありませんが、単色が基本であるというのは、意識しておくとよいでしょう。

4-3. モチーフ

誰もが分かるモチーフに

Googleの、無生物に人間らしさを与えない、という記述が特徴的ですが、これに従うべきかは議論の余地があるでしょう。Appleが規定している「ユーザが認識しやすい普遍性」というのは順守すべき基準になりえるでしょう。独創的なアイコンはNGということです。

4-4. サイズ

アイコン本体は24 x 24 px～50 x 50 pxの間、タッチエリアは44 x 44 px以上

Apple、Googleともにサイズに関する規定があります。両者を統合し、アイコン本体は24 x 24 px～50 x 50 pxの間とし、タッチエリアは44 x 44 pxを最小値とするのがよいでしょう。

5. その他

5-1. イメージ

必然性のある自然で具体的な画像

Googleのみ、画像は飾りではなくツールである、という考え方が述べられています。厳密や制約事項はありませんが、目的に対して明確に機能する自然で具体的な画像であるべきという考え方は、一つの指針にできるでしょう。

5-2. レイアウト

左上が起点。グルーピングと階層化を活用。8がグリッドの最小値

Apple、Googleともに、それぞれ異なる視点からレイアウトに関する言及があります。双方を統合して参考にするのが良いでしょう。

5-3. ライティング

ユーザの知識に合わせた簡潔な表現

Appleでは術後を用い、Googleでは簡潔さを満たすいくつかの基準が示されています。いずれも普遍的なことであり、UIに載せるコピーの参考にできるでしょう。

そこでこのエントリーでは、現在スマホ対応ができていないWebサイトが、今回のアルゴリズム変更をどう判断すべきかのポイントを整理してみました。

企業サイトにおけるモバイル訪問比率の現状

弊社で実施している数多くのWebサイトに対するログ解析やヒアリング内容から、サイトタイプ別のモバイル流入比率はだいたい以下のようになっていると考えられます。

比率の少ないWebサイトでも20～30%に達し、モバイルと親和性の高いWebサイトでは80%前後まで至ることもある。ただし実際にはビジネスモデルやターゲット特性、掲載コンテンツによっても大きく変わるため、あくまで参考程度。

このうち、比率が60%を超えるゾーンAは当然のことながら、ゾーンBで50％前後を記録しているWebサイトの多くは、おそらくすでにスマホ対応をしていることでしょう。逆に、まだPC向けのWebサイトしか用意していないのだとしたら、Googleのアルゴリズム更新と関係なく、早急な対応をしないといけません。

今回のアルゴリズム更新を脅威に感じているのは、ゾーンBでモバイル比率が40%を切っている、もしくはゾーンCに属するWebサイトでしょう。例えば多くのB2Bサイトではモバイルユーザの割合が少なく、スマホ対応が見送られてきました。このようなモバイルユーザが多いのか少ないのか判断しかねるWebサイトを運営する企業では、今回のGoogleのアルゴリズム更新に困惑しているのではないでしょうか。

今回のアルゴリズム更新で気にすべき点

今回のアルゴリズム更新に対して、様々な専門家が様々な解説を行っていますが、以下のGoogleの公式情報およびGoogle社員による発言が、もっとも信頼できる情報源となるでしょう。

• 検索結果をもっとモバイル フレンドリーに（Googleウェブマスター向け公式ブログ）
• モバイルフレンドリーについての疑問にGoogleが直接答えてくれた！ ～The 13th In-house SEO Meetupレポート

これらの情報を整理すると、4月21日のアルゴリズム更新に対する判断基準となるのは、特に以下の点です。

• モバイル検索にのみ適応される
• 評価はページ単位で行われる
• ナビゲーショナルクエリには影響しない
• モバイルフレンドリーテストで使われている基準だけで判断される

言い換えれば、デスクトップ検索には影響せず、サイト全体の評価が落ちるわけではなく、企業名やブランド名、商品名を指名するような検索には影響を与えず、評価基準はシンプルで改善箇所は明確である、と捉えることができます。つまり、早急なスマホ対応が必要なWebサイトは限られており、対策が必要であったとしてもそれほど難しくはない、というわけです。

緊急性を見極めるポイントと応急処置の方法

前述の話から、Googleの新しいアルゴリズムをどう判断し、スマホ対応をどう実施すべきかをまとめたのが以下のチャート図になります。

図の中で数字の付いている個所について、以下でより詳しく解説します。

1. モバイルユーザはビジネス上重要か？

モバイルでの訪問比率は判断を決める一つの指標ではありますが、大事なのは%の大小ではなく、モバイルでWebサイトに訪問するユーザがビジネス上重要かという点です。例えばモバイルユーザは既存顧客やパートナー企業がほとんどで、売上げ等へのインパクトがほとんどないのであれば、対応を急ぐ必要はありません。一方、モバイルユーザにリード（見込み顧客）が多く含まれてたり、人材獲得に影響がありそうであれば、対応は急ぐべきかもしれません。ちなみに、ビジネス上重要かどうかは、モバイルユーザがどのコンテンツにアクセスしているか、どういう検索キーワードを使っているか、Webサイト内でどのような行動経路を辿る傾向があるかなど、経験則や「そんな気がする」ではなく、データを元に判断しなければなりません。

2. SEOはWebサイトへの流入施策として重要か？

そもそもの話として、Webサイトへの流入経路として自然検索が重要でないのであれば、今回のアルゴリズム更新に合わせた対応は不要でしょう。広告などのペイドメディアでの流入、イベントや営業で接触してからの訪問、SNSからの流入がほとんどを占めるようなWebサイトでは、少なくとも現時点では、モバイル向けのSEO対策は戦略上重要ではありません。もちろんユーザ体験を高めるためのスマホ対応は将来的に重要になってくるでしょうが、4月21日に向けての早急な対応は不要と考えられます。

3. モバイル検索には、一般キーワードが多いか？

ログを解析した上で、モバイルユーザが使うキーワードが企業名やブランド名、製品名ばかりであれば、新アルゴリズムを恐れる必要はありません。なぜなら、ナビゲーショナルクエリと呼ばれる類の検索には影響しないためです。例えば現在、企業名で1位に表示されていれば、新アルゴリズムでもおそらく1位に表示されるでしょう。ユーザが求める情報に適切に誘導する、というGoogleの本質を考えると当然のことです。一方、具体的な固有名詞が入らない一般キーワードでの検索流入が多い場合には、アルゴリズム更新によって流入が減少する可能性があり、早急な対策を講じる必要があるでしょう。

4. 競合サイトもスマホ対応が進んでいるか？

SEOを考える場合、内部要因／外部要因だけでなく、検索結果における競合サイトとの関係も重要です。上位表示を狙いたいキーワードでモバイル検索をした時に、競合サイトの多くがスマホ対応されておらず、あるいは対応に時間がかかりそうなWebサイトばかりであれば、急ぐ必要はないかもしれません。Webサイトの活用が遅れている業界では起こりえることです。一方、ほとんどの競合サイトがスマホ対応を終えている場合には、4月21日以降に順位が急落する可能性があります。4月21日までに対策を実施していく必要がでてくるでしょう。

5～6. モバイルユーザにおけるランディングページの把握とスマホ対応ページの決定

アルゴリズム更新に向けて、なんらかの対応を早急に実施する必要がある場合、まずはログを確認し、モバイルユーザがランディングしているページを把握しましょう。新アルゴリズムはページ単位でしか反映されないので、Webサイト全体をスマホ対応させる必要はありません。つまり、モバイル検索でよくランディングされるページをまず気にしておけばいいわけです。

ランディングページを確認したら、訪問比率と作業負荷から、対応ページを決めましょう。例えばモバイル検索で7割以上がホームにランディングしているようなWebサイトであれば、まずホームだけをスマホ対応するでいいかもしれません。また、利用頻度は高くないが、動線上重要であり、かつ構造的に簡単にスマホ対応できるページが存在するなら、改善対象に含めてもいいでしょう。

7. モバイルフレンドリーテストと改善個所の把握

スマホ対応するページが決まったら、Googleが提供しているモバイルフレンドリーテストにかけて、改善ポイントを改めて把握しておきましょう。ちなみにモバイルフレンドリーテストでは、以下の4点についてチェックされます。

• テキストの大きさ
• リンク同士の近さ
• モバイル用viewportの有無
• 画面幅の大きさ

逆にいえば、この4つを押さえておけば、アルゴリズムが更新されても評価を落とすことはありません。4月21日に向けての応急処置としては、まずはこの4点の改善に集中すべきで、それ以外のデザインのディテールやOSによる表示差異などは、対応に時間をとられるのなら後回しにしましょう。

8～9、レスポンシブデザインにするか、独自ページ+リダイレクトにするか

SEOを意識したスマホ対応というと、ソースコードやURLが一つのレスポンシブデザインの方が有利と誤解するかもしれませんが、必ずしもレスポンシブデザインにする必要はありません。モバイル専用の独自ページを用意し、そこにリダイレクトをかけても、きちんと評価されるようになっています。

では、どちらがいいかということですが、まず、PCとスマホでコンテンツを変える必要があるか、というのが最初の判断基準になります。PCとスマホで見せる情報を変えるのであれば、独自ページ+リダイレクトで対応した方がいいでしょう。逆に、PCとスマホで情報を変えない（もしくはどう変えていいかまだわからない）ということであれば、基本はCSSの改修だけで、画像生成やHTML改変は最小限に抑えられるレスポンシブデザインの方がいいでしょう。

なお、古いWebサイトの場合、構造上の制約でレスポンシブデザイン化が難しいケースがあります。その場合にも、独自ページ+リダイレクト対応にした方がいいかもしれません。

まとめ

本エントリーでは、Googleのモバイルフレンドリー・アルゴリズムに対して、もし応急処理が必要であればどうすべきか、という話を中心に解説しました。しかし誤解していけないのは、スマホ対応は、SEO対策の一環でやることではありません。スマホ対応とは、スマートフォンを使うユーザのメリットのために行うもので、本タイトルにあるような「グーグル新アルゴリズム向け」という観点は、本質ではありません。

弊社経験では、スマホ対応をしていないWebサイトでは、デスクトップユーザに比べてモバイルユーザの直帰率が高く、1訪問あたりの平均閲覧ページ数も低くなる傾向があります。またスマホ対応を行うと、デスクトップとほぼ同レベルにパフォーマンス改善されることがほとんどです。

さらに、同一コンテンツを提供するレスポンシブデザイン化されたWebサイトのログを見ると、閲覧ページ数も閲覧しているページの種類も、デスクトップとモバイルでほとんど変わらないことが多いです。ユーザ特性やコンテンツ構成に依存しますが、スマートフォンでもPC並みに積極的に情報取得をするユーザが増えている証ではないでしょうか。

このようにスマートフォン利用が一般化する中で、モバイルフレンドリーではないWebサイトをそのまま放置することは、機会損失を意味します。もちろん、ビジネスへのインパクトや対応の優先順位、Webサイトに求められる役割等を総合的に判断して対応を決めることになりますが、スマホ対応はすでに「やってて当たり前」のものとなっています。

今はまだ30%未満だから大丈夫、うちはB2Bだから関係ない、と単純に考えるのではなく、この先の利用動向の変化も見据えつつ、今回のアルゴリズム変更を一つの契機として、スマホ対応をどうすべきか考えていくと良いのではないでしょうか。

ハードウェア的に大きな変化のないPC向けのWebデザインというと、ノウハウは固定化されている印象もありますが、実際には時代の流れを受け、今も変化を続けています。特に以下のような環境変化が、PCサイトのUIデザインにも大きな影響を与えています。

• 表示デバイスの多用化
• スマートフォンアプリの一般化
• タッチスクリーンの普及

トレンドに合わせれば成功、というではありませんが、その根底に流れているユーザ動向の変化については、十分に理解しておく必要はあるでしょう。そこでこのエントリーでは、PCサイトのUIデザインにおける最新動向を、その背景の推測を含めてまとめてみました。

1. Big UI / Low Density / Long Pageの潮流

かつてPCサイトといえば、限られた領域にいかに要素を詰め込んでいくか、という設計が多かったように思います。しかし現在では、UIパーツは大型化し（Big UI）、密度は低くなり（Low Density）、ページは長くなる（Long Page）傾向にあります。

元々は海外のクリエイティブ系、スタートアップ系のWebサイトを中心に採用されていたこのような設計は、海外企業の日本進出や、先駆的な目を持つWebデザイナー、それを採用する企業のWebサイトによって、徐々に日本でも広まってきました。この流れはフラットデザインとも呼応し、2013年以降にリニューアルされたWebサイトの多くが、このBig UI / Low Density / Long Pageに基づいた設計思想になっています。

2014年にリニューアルされたLIXILのWebサイトは近年のトレンドを踏まえた設計、以前から存在する東京メトロのWebサイトは、密度が高く情報が詰め込まれていたやや古い設計であるといえる。

このようなトレンドには、単に見た目を今風にする、ということだけでない、合理的な理由がいつか存在します。開発側の思惑としては、レスポンシブWebにしやすいという点があげられますが、ユーザ側の立場に立つならば、見やすい、わかりやすい、迷わない、ということ以外に、タッチスクリーンで利用しやすいサイトになることも、メリットとして大きいのではないでしょうか。

近年はタブレットのみならず、ノートPCでもタッチスクリーンの実装が当たり前になってきました。スマートフォンサイトを用意しない場合には、スマートフォンでの閲覧もある程度許容できるUIが求められてきます。

タッチスクリーンでは、指でのタッチが基本操作となるため、細かな操作はできません。そのため、UIを大きくし、要素間のスペースもゆったりさせる必要が出てきます。UIが大きく、密度が低くなれば、当然画面に映し出される要素が少なくなるため、ページは長くなり、スクロールが前提となってきます。

このエントリーで以降に紹介するトレンドの多くは、このBig UI / Low Density / Long Pageの潮流から派生したものです。これはファッションとしてのトレンドではなく、現在のユーザ行動に最適化された設計思想であるといえます。

2. 1カラムレイアウト

Big UI / Low Density / Long Page に適したレイアウトとしてよく採用されているのが、1カラムレイアウトです。

かつては、右もしくは左にメニューバーやバナーなどを設けた2カラムのレイアウトがPCサイトのUIの主流でした。ECサイトなどの情報量が多いサイトでは、3カラムレイアウトも多くみられました。しかし現在では、左右のカラムを取り去り、コンテンツ部分だけにフォーカスする、1カラムレイアウトが増えてきています。

ユーザからすると、不必要なノイズが目に飛び込んでくることがなくなり、本当に必要なコンテンツに集中できるようになりました。文字はより読みやすく、画像はより大きく表示されるようにもなりました。

一方、目に飛び込んでくる情報量が減り、バナーなどを散りばめることによる偶発的な出会いは演出しにくくなりました。そのため、ユーザ動線の設計は、より慎重に行わなければならなくなりました。

また、サイドカラムにローカルナビゲーションを設置する手法は、他階層化したWebサイトにおいて、ユーザを迷わせないという大きなメリットがありました。これを取り去ってしまうということは、サイト全体を低階層化し、さらにメニューをできるだけ少なく絞り込むなど、1ページ内のレイアウトにとどまらず、サイト全体の設計の考え方を、見直すことを意味します。

逆にいえば、多階層化が前提のメガサイトにおいては、1カラムレイアウトが適切な解でないことも多く、その判断は慎重に行わなければなりません。

グリーのコーポレートサイトでは、1カラムレイアウトを維持するために、ローカルナビがヘッダ下に並んでいる。これだけの数のメニューを改行してまで並べているのは珍しい。一方、KDDIのコーポレートサイトでは、従来型の2カラムレイアウトを併用している。

3. 中央揃え

1カラムレイアウトの問題の一つは、文字の改行でしょう。文字が横幅いっぱいまで伸びるようになり、レイアウトを美しく保つのが難しくなりました。1行の文字数が40を超えると、人は読みづらいと感じるとも言われています。１カラムになったからといって、何も考えず、横幅いっぱいに文字を表示させるのは、避けたいことです。

これを解決する一つのアイデアが、中央揃えの併用です。横幅が広い１カラムレイアウトでは、中央揃えと左揃えをいかにうまく組み合わせるかが、デザインのポイントになってきています。

1カラムを採用する多くのサイトでは、中央揃えと左揃えを上手に混在させ、ストレスなく文字を読ませることが求められている。

中央揃えの活用には、いくつかの注意点があります。まず、ユーザの目線を無視した中央揃えは避けなくてはなりません。例えば、長文を中央揃えにすると、文章の開始点が行によって変わるため、読みにくくなってしまいます。もし中央揃えを使うのであれば、あまり改行されない短い文章、長い文章であれば左揃えにする必要があります。

また、近接する要素との関係性にも配慮が必要です。近接要素が横幅いっぱいの時は、中央揃えで配置しても、収まりの良くまとまります。しかし、近接要素が横幅いっぱいに存在しない場合、中央揃えは中途半端な位置に浮遊しているように見えてしまいます。そのため、ボックスやボーダーなどを駆使して、中央揃えを違和感なく見せる工夫が必要となります。

1や2のように、周辺に「中央である」と認識できる要素があれば、中央揃えの混在もキレイに見える。一方、3のように、周辺要素との関係で中央と認識しにくい場合、中途半端な位置に表示されている印象を与えやすい。また4のように、長すぎる文章は、見た目はシンメトリーでキレイに整列しているように見えて、読みにくくなることもある。

4. 固定ヘッダとヘッダの薄型化

固定ヘッダも、すっかり一般化してきました。多くの場合、ここにはグローバルナビゲーションが搭載されます。ページ内のどの位置にいてもすぐに主要コンテンツに横移動できる固定ヘッダは、サイドナビを持たず、ページが長くなる傾向の現在のUIにおいて、ユーザビリティを担保する合理的な機能です。

固定ヘッダは、数多くのサイトで採用されている。トヨタのように、ヘッダ全てではなく、ヘッダの一部（ローカルナビ）のみを固定化させるケースも多い。

ただし、固定ヘッダには、必要がないときにもそのエリアを占拠してしまう、というデメリットがあります。そのため、ヘッダはできるだけ薄く仕上げなければなりません。かつてのPCサイトでよく見かけたような、多段式の分厚いヘッダは採用しにくくなります。

このことは、ヘッダ内に配置する要素の絞り込みが必要になることを意味します。格納する要素が多いと、ヘッダはぶ厚くなり、固定化させづらくなります。メニュー数は絞るべき、というのは以前から言われてきたことですが、このことをより強く意識していく必要が出てきています。

5. 固定式の左ナビゲーション

近年、グローバルナビを左側に配置するレイアウトを見かけるようになってきました。といっても、かつての2カラムレイアウトが主流だった時代の左ナビとは、構造や機能が異なっています。

画面左に固定されて、スクロールに追随させるのが最近多いパターンです。また、メインコンテンツ部分は、基本的には1カラムレイアウトで、画面幅に合わせて伸縮させるリキッドレイアウトが採用されることも多いです。

様々な企業が導入し始めている左メニュー。固定式で、マウスオーバーやクリックでメニュー展開するものが多い。

このような設計は、アプリライクな操作感をもたらします。また、マルチデバイス対応にしやすくなる特徴もあります。スマートフォンファーストで設計し、レスポンシブWebやリキッドレイアウトでPCにも対応させるような場合に、このような構造が採用されやすい傾向があります。

ただし、注意しておかなければいけないのは、このような新しいレイアウトは、一般ユーザにはとっつきにくい印象を与える危険性もあります。また、メニューを多階層化させる際には、クリックやマウスオーバーで下層メニューを引き出すような操作も必要となるため、操作の難易度は上がります。

固定左ナビのデメリットも踏まえ、ユーザのリテラシー、全体の構造などから、導入の妥当性を見極める必要があります

6. リキッドレイアウト

デバイスが多様化する中で、画面解像度はかつてないバラエティとなってきています。以前は、横幅960～980pxあたりに収めていれば概ね問題なかったですが、この定石は通用しにくくなってきました。このような解像度の多用化に対する一つの回答が、画面幅に合わせてレイアウトを伸縮できるリキッドレイアウトです。

リキッドレイアウトは、要素や画像をピクセルではなく、%で指定します。そのため、どのようなサイズ、解像度の画面で見ても、ある一定のバランスでレイアウトされます。小さな画面に合わせた時のデメリットと、大きな画面に合わせたときのデメリットの両方を吸収することができます。

ビーナスベッドのサイトでは、画面の幅に合わせてレイアウトや画像が可変する。ロゴや文字サイズは変わらず、あくまでレイアウトと画像の伸縮だけでバランスをとる構造になっている。

留意しないといけないのは、これは各画面に「最適化」されたレイアウトではない、ということです。様々な解像度の画面を想定し、一番破綻が少ないと思われる最大公約数的な妥協点をまとめ、レイアウトする手法です。ある特定のサイズで感じるバランスの悪さは、ある程度許容しないといけない、ある意味非常にWebらしいレイアウトともいえます。

7. 立体表現への回帰

MicrosoftがWindows 8で、AppleがiOS7で提唱したフラットデザインは、それ以前に支配的だった装飾過多なスキューモフィックに対するカウンターとして強いインパクトを残し、アプリUIの世界では瞬く間に一般化しました。この流れはPCサイトにも波及し、2013年以降にリニューアルされているPCサイトの多くが、フラットデザインを取り入れています。

一方で、ここにきて行き過ぎたフラット化の問題も表出してきました。フラット化は、デザインの機能的側面に大きな足かせを与えることになります。特に画面要素が多いWebサイトにおいては、立体表現がないことで、クリック要素と非クリック要素の区別がつきにくくなったり、情報の重みづけや関連性が分かりにくくなったりするケースも出てきました。フラットデザインは、見た目のシンプルさや親しみやすさとは裏腹に、難易度の高いデザインであるともいえます。

不動産賃貸のエイブルのサイトは、意欲的にフラットデザインを取り入れているが、クリックできる場所とそうでない場所の区別が付きにくく、やや学習が必要なUIといえる。

このような行き過ぎたフラット化の反省から、最近では立体表現を再び取り入れる動きが出はじめてきました。その象徴と言えるのが、Googleが提唱するマテリアルデザインです。マテリアルデザインでは、レイヤーや影などといった現実世界に存在する3次元表現の積極的な活用をうたっており、UIは再び立体に回帰すべき、というメッセージとして受け取ることができます。

AndroidのWebサイトでは、UIのテクスチャはフラットが基本でありながらも、クリッカブル要素には積極的に影が用いられている。

UIはファッションではないので、流行に合わせてフラットデザインにしたり、マテリアルデザインにしたり、という判断は誤っているといえます。ただ、PCサイトのUIとして求められる目的を改めて考えた時に、フラットデザインに課せられた制約に大きな意味があるとは考えにくく、再び立体表現へ回帰していく流れになっていることは、妥当であると感じます。

8. スクロールと連動したギミック

PCサイトのページも長くなり、スクロールが必須の行為となる中で、スクロールに反応するようなUI上の工夫も多く見られるようになってきました。

数年前に流行したパララックス（視差効果）を使った表現も、この流れの一つといえます。ただ、現在はパララックスほどの大掛かりな仕掛けは少なくなっており、スクロールに合わせてメニュー要素が動いたり、ある位置に来るとポップアップが展開したり、文字がフェードインしたり、といったもう少し控えめなギミックが目立ちます。

スクロールに合わせて要素が動くことで、もっとスクロールさせてみよう、というユーザ心理が生まれくる。運送会社のリクサスのサイトでは、長い1ページに対して、トラックの旅を想起させるような仕掛けが施されている。

これは、JavaScriptのライブラリの普及、CanvasやCSSアニメーションの一般化で、UIを動かすことがより簡単になり、アニメーションを用いたUIの心地よさを追求しやすくなったためと考えられます。

ただし、動くUIは、人の目が動くものに反応してしまう生理的特性に訴えかけるものです。それゆえに、計画なく過剰に動かすと、目が休まらない、落ち着かない、本来の情報に目が留まらない、といったことを引き起こしかねません。やたらと動かしてしまうのではなく、確実に効果が得られる個所への、最小限度の利用に留めるのが得策でしょう。

9. シームレスな画面遷移とトランジション

Webサイトとアプリの違いの一つに、画面遷移がシームレスに行われるか否かという点があります。Flashが衰退し、HTMLのサイトが再び圧倒的な主流になり、画面遷移は画面もリフレッシュされて切り替わるもの、というのが常識になりました。

しかし、アプリライクな画面遷移を実現するpjaxのようなJQueryプラグインが生み出され、PCサイトでもシームレスに画面遷移するサイトを再び見かけるようになってきました。

pjaxは、Webサイトのファイル構造は維持したまま、画面遷移時に特定のソースコードだけを入れ替える動きを実現します。つまり、ページはきちんと存在しているため、FlashやかつてのAjaxを使ったワンスクリーンサイトでの「SEOに不利」といった欠点を回避しています。

最近ではさらに進化し、画面遷移時のトランジションもバラエティ豊かになってきています。

アーキタイプのサイトでは、CSS3のtransformプロパティを使い、3D的な画面遷移を実現している。

現在のところ、このような技術はデザインの情緒的側面を強化する演出としての要素が強く、サイトの目的や構造によっては、このような演出が適切ではないケースもあります。見た目の新規性にとらわれるのではなく、導入効果を十分に考慮したうえで、採用を決める必要があります。

10. Webフォントの活用

Webフォントを採用すれば、OSにはない書体の表示が可能になります。画像テキストを生成する必要がなくなり、更新性が高いサイトであっても、文字表現の幅が広がります。

海外ではGoogleなどがフリーで使える質の高い欧文Webフォントを積極的に公開しています。欧文の場合、26×2種類（大文字・小文字）＋記号しかないので、書体も比較的豊富で、現実的な選択肢となり、急速に普及しています。

日本国内でもその影響で、日本語のWebフォントを用いるケースが見られるようになってきました。

ミクシィのコーポレートサイトでは、全面的にAXISのWebフォントが使用されている。文字量の多いコーポレートサイトでここまで採用される例はまだ珍しい。

ただ、Webフォントは確かに今のPCサイトのトレンドではありますが、日本語Webフォントには、欧文ほど簡単には普及しない障壁があります。

日本語は欧文と違い、数万の文字データを必要とします。そのため、必要なフォントだけを引っ張ってくるようなサーバ側の仕組みが必要となりますが、これにより、表示が一瞬遅れたり、奇妙な挙動をしたりするケースが見受けられます。

また、アンリエイリアスが美しくないものが多く、特にWindows環境では汚いアウトラインの文字が多い点も、大きな問題です。欧文と違って文字が多いゆえに、カーニングをルール化することも難しく、文字詰めなどはほぼ、あきらめなければなりません。つまり、見た目にこだわるためにWebフォントを採用するのに、Webフォントを採用することで見た目が劣化する、という矛盾が起こるのが、今の日本語Webフォントの実状です。

普及を阻む要因はほかにもあります。それは、今までと支払い先が変わることです。前述のように日本語のWebフォントには、サーバ側の仕掛けがどうしても必要となるため、欧文のような無償提供が難しい実情があります。

そこで、日本語のWebフォント提供会社はトラフィックによる課金を行っているのですが、これにより、今までとお金の出所が変わってしまいました。インストール型のフォントであれば、制作会社がフォントを買いきってしまえば、クライアント企業が美しく個性的な文字を自由に扱えました。それに対してWebフォントでは、クライアント企業がフォントに対して対価を支払わないといけません。

もちろん商流的には制作会社が仲介して支払うこともあるでしょうが、有償である以上、普通の企業であれば費用対効果の説明を求めてくるでしょう。しかし、Webフォントとビジネスの相関関係が説明できない上に、上記のような、「必ずしも美しくなるわけではない」というデメリットも存在するため、導入に強い説得力を生む出すことができないのが実情です。それゆえに、Webの新しい技術に寛容な企業でのみ使われる、という現状になっているのではないでしょうか。

Webフォントは今後の潮流であると思いつつも、日本語に関しては制約やデメリットが多い、一般的な普及には大きな課題があると言えます。

11. SVGの利用

Web上の画像はでは長らくJPEG、GIF、PNGが主流でしたが、ここに来て増えているのがSVG形式の画像です。

SVGの最大の特徴はベクターデータである点です。これにより、大きさや解像度に依存せず、どのような環境でも、どのくらい拡大しても、常になめらかに表示させることが可能になりました。サイズも軽く、アニメーションさせることも可能で、モバイル＆マルチデバイスを前提とした閲覧に適した画像フォーマットといえます。

アップルサイトのグロナビやロゴは、どこまで拡大しても美しいアウトラインを維持するが、これはSVGを用いているからである。

SVGを利用するうえでネックとなるのが、対応ブラウザです。Internet Exploreでは、バージョン8以下はSVGに対応していません。そのため、IE８以下もターゲットとするPCサイトでは、代替手段の用意が必要です。一方、IE8以下を切って、モダンブラウザにフォーカスできる場合には、SVGの積極的な利用が可能になります。

画像の特性としては、色が少なく単純な図形の描画に向いていうという点があげられます。一方、写真のようにリアルな表現のものは、SVGには不向きです。そのため、すべてをSVG化するのではなく、画像の特性に合わせてJPEGやPNGを併用することになります。

12. 動画の活用

Flashが成熟期に入ったころ、UIと映像の融合が積極的に試みられていた時期がありました。Flashの衰退とともに、PCサイトは動きのない表現が一般的になりましたが、ここに来て再び、動画をUIに組み込んだようなWebサイトが増えてきつつあります。

最近では、背景に動画を組み込み、前面にキャッチコピーやボタンを配置する様なデザインが多くなっている。

HTMLでプラグインを使わずに動画を表示させるためには、基本的には<video>タグを使う必要があります。このタグはHTML5以降で提供されたものであり、HTML５をサポートしていないレガシーなブラウザでは、用いることができませんでした。しかし、近年HTML5を前提としたモダンブラウザが主流となり、HTML５での実装が前提となる中で、再び動画を積極的に用いやすい環境になっているのが、動画活用が加速している一因として挙げられます。

また、以前に比べて、動画を容易に作ることができるようになっている点も忘れてはいけません。かつての映像制作のような高額な支払いをせず、映像制作を請け負う会社が出てきています。質を求めなければ、スマートフォンなどで個人でも簡単に動画撮影ができるようになっているのも、一つの要因でしょう。

スマートフォンと異なり、PCサイトでは、回線速度にあまり神経質になる必要はありません。動画を用いることで、より効果的な訴求ができるのであれば、積極的に用いていきたいところです。

まとめ

というわけで、いくつかトレンドを紹介しましたが、注意点としては、「トレンドだから」という安易な理由で採用しないことです。UIがトレンドであるかどうかは、Webサイトが追っている使命とは関係ありません。もし、Webサイトが追求すべきビジネスが、トレンドではなくレガシーな技術を求めるのであれば、それを採用するのが、デザイナーの役割です。

トレンドを知ることで一番重要なことは、その背景にある外部要因やユーザ動向の変化の把握です。その本質を理解せず、トレンド・オリエンテッドでWebサイトのデザインを考えていくと、トレンドはキャッチアップできているけど、成果は全然出ない、といいことになりかねません。

トレンドは理解しながらも、それに使われるのではなく、選択肢の一つとしてうまく接していくことが、デザイナーには求められます。

Web制作者を悩ませる問題に、「Webを熟知したコピーライターがいない問題」があります。特にメディア型のWebサイトの場合、文章の質がコンテンツパワー、ひいてはWebサイトの集客力・訴求力そのものになってきます。しかし現状、プロジェクトメンバーにコピーライターが参加しないのは当たり前になっています。

また、もしコピーライターをプロジェクトに参加させたいと思っても、Web特有のユーザ行動や設計思想、SEOなどに精通し、Webに相応しい文章を作ってくれるコピーライターは、この市場にごくわずかしか存在しないのではないでしょうか。

このWebのコピー問題は、考える以上に深刻です。なぜなら、文章の良し悪しで、コンバージョン率もユーザの満足度もブランドイメージも、簡単に変わってしまうためです。そして、その問題に対する私たちの結論は「全員でコピーをチェックして校正しよう」ということです。

私自身は今まで、プロデューサー、ディレクター、IA、アートディレクター、デザイナーなどといった立場でプロジェクトに参加していましたが、コピーにはどんどん手を入れていくスタイルで仕事をしてきました。大抵、クライアント支給の原稿の質が低かったのが、最大の理由です。

その経験から考えても、結局、Webのマーケ的特性・技術的特性の両方を理解している制作者がライティングの基本スキルを身に付け、文章に手を入れていくというのが、質とスピードを両立できる一番いい方法だと感じています。

物書きの仕事や、専業のコピーライターになるには、それ相応の障壁と努力が必要です。しかし、分かりやすく破たんの無い文章ということであれば、ある程度の訓練で、誰でも実用レベルの文章が書けるようになります。

このスライドは、その考えのもと、コピーライターでもない人が、Web用のライティングができるようになる上で押さえておくべき、基本的なルールをまとめたものです。

スライドの中にも書いてありますが、文章というのは今の時代にもっとも頻繁に使われているコミュニケーション手段であり、良い文章が書けるということは、クリエイターにとっては大きな武器になります。

私たちの会社では、各人の文章力の強化という目的も意識しながら、「全員コピーライター主義」を掲げて、Webのコピー問題に全社員で立ち向かっていこうと考えています。

• 2種類のハサミと2種類のWebデザイナー
• Webデザインの特殊性
• ビジュアルのディテールに神が宿らないWebデザイン
• 美しいが使えないWebデザインをしてしまう理由
• Webデザイナーを支配する「強固な固定観念」と「裏の動機」
• 美しいビジュアルの根底にあるデザインの本質
• 本当に「最近のWebデザインはつまらない」のか？
• ミスマッチが生む不幸なWebデザイン
• Webデザイナーに求められる自らのスタンス
• Web制作会社にも求められる明確な価値観

2種類のハサミと2種類のWebデザイナー

例えば、以下のような2種類のハサミが存在するとします。

1. 工芸品のように美しいが切れ味はよくないハサミ
2. 見た目はそれなりだが非常によく切れるハサミ

1は、ハサミとしては売れないでしょう。ただ、それが刺激的で斬新なビジュアルであった場合には、特別な賞を取ったり、美術館に展示されたりはするかもしれません。あるいは、部屋に飾るオブジェとして売れるかもしれません。そう狙って作られたのであれば、それは「素晴らしいデザイン」といえます。

2は、工業デザインの考え方です。切れ味には細心の注意を払います。見た目もなるべく美しくしますが、納期やコストを鑑み、現実的なところで妥協します。例えば、価格を低く抑えるために、安い材質の持ち手にするかもしれません。それでも、抜群の切れ味が受けて大ヒット商品になれば、それもまた「素晴らしいデザイン」になります。

この話をWebデザインに置き換えるなら、1はマーケティング的機能よりもビジュアルが優先されたWebサイト、2はビジュアルよりもマーケティング的機能が優先されたWebサイト、ということになるでしょうか。

もちろん、この両方の究極を狙うケースもあるでしょうが、現実には、どちらかの価値観をより重視し、バランスを取ることの方が圧倒的に多いでしょう。

Webデザインの特殊性

Webというメディアには、デザインを施すにあたってのいくつかの特性があります。もっとも特徴的なのは、ビジュアルのディテールをあまりコントロールできない点でしょう。

例えば、紙のグラフィックのように、仕上がりの発色を入念に調整することは、スクリーンメディアではあまり意味をなしません。なぜなら、スクリーン設定やメーカーの違いなどで、色味が変わるためです。

紙のデザインでは非常に重要となるコンポジションも、スクリーンの縦横比や左右のマージンがその都度変わり、ブラウザによって数ピクセルのずれが生じることが当たり前のWebでは、ある程度は割り切らないといけません。

文字詰めに命を懸けるWebデザイナーは多いですが、デバイスフォントは文字詰めができません。普通のユーザは、画像テキストとデバイスフォントの区別を付けず、文字詰めされていないテキストが混在した画面を自然に見ていることを考えると、Webデザインにおける文字詰めという行為にはどの程度の価値があるのでしょうか。

HTMLの核となる要素は、そこに収められているデータです。しかし、データのままでは人には識別しにくいので、分かりやすく読めるよう、CSSでデザインできるようになっています。ただしそこでは、ビジュアルの完成度よりも、より多くの環境での表示や素早いデータ転送の方が優先されます。PCだけでなく、タブレットやスマートフォンでも問題なく閲覧できることを求められるケースも多くなっています。

そのため、ビジュアルコントロールの面では、他のメディアのデザインと比べると、制約がかなり多くなっています。

つまり、冒頭で例にあげた「工芸品のように美しい」というビジュアルを突き詰める価値観は、Webデザインの世界ではなかなか実現しにくいものなのです。

そして、「見た目はそれなりだが非常によく切れるハサミ」を求められる仕事なのに、Webデザイナーが「工芸品のような美しさ」の価値観を優先させると、ビジネスをしたい企業やプロデューサー、ディレクターとの軋轢を生む一因となります。

ビジュアルのディテールに神が宿らないWebデザイン

「ディテールに神は宿る」という言葉をデザイナーは好みます。

ディテールまで丁寧に作りこまれたデザインを見ると気分が高揚し、その仕事に憧れを抱きます。デザイナー自身も、ディテールを詰める作業を好み、できればディテールを詰め続けたいと考えます。

これはデザイナーという職業を選ぶ人間の性でしょう。

そして、自分が没頭したディテールの価値を認めてもらいたいという気持ちが、「ディテールに神は宿る」という言葉によって代弁されます。ただしこの言葉は、時に、誰にも価値のない無駄な作業に時間を使うことを正当化するためにも使われます。

特に、Webデザイナーのいう「ディテールに神は宿る」は、空しい結果になることも多いのではないでしょうか。前述の通り、ディテールを完全にはコントロールできないメディア特性があるからです。せっかく手間をかけても、ユーザに伝わらず、なんの効果も生まれない、ということが往々にしてあります。

あるいはもし、デザインの神がWebの世界にもいるのだとすると、それはビジュアルのディテールではなく、別のディテールに宿るようにも思います。

例えば、CVRを上げるためにボタンを（やや不格好でも）数ピクセル大きくしてコピーを動詞にするとか、不意にマウスオーバーしたときに誤作動させないために実行までに数秒のインターバルを置くとか、検索エンジンを意識して全てのページのDescriptionを丁寧に変えていくとか、そういった部分です。

それはもはやビジュアルが大好きなWebデザイナーたちが憧れる世界ではないのですが、Webデザインにおいては、そういったディテールの方がより意味があるというのが、現実なのです。

美しいが使えないWebデザインをしてしまう理由

Webデザインでは、「見た目はそれなりだが非常によく切れるハサミ」という考えの方が重宝される世界であることは、実は多くのWebデザイナーはよく知っています。それは、この業界で働いていれば当たり前のように言われることだからです。にも関わらず、多くのWebデザイナーが「工芸品のように美しいが切れないハサミ」に心を奪われ、つい、判断を誤らせてしまいます。

その理由は、実に単純です。

多くのWebデザイナーはビジュアルが大好きなのです。美しいビジュアル、ユニークなビジュアル、斬新なビジュアル。それに憧れ、仕事にしたいと思い、Webデザイナーになった人が多いのではないでしょうか。

私自身もかつてはそうでした。私がWebデザイナーになった当初はFlash黎明期で、アニメーションを多用した刺激的なビジュアルのWebサイトが、国内外で立ち上がり始めた時期でした。グラフィックや映像との境界も曖昧な時代だったため、例えばTOMATOやHi-ReS!、designer’s republicのような、作家性の強いデザイナーたちに強く憧れ、その流れでWebデザイナーを志しました。

そんな駆け出しのころの私は、今思えば、やはりビジュアル至上主義でした。ビジネスとの親和性、機能性、ユーザビリティの大事さは、分かっているつもりでした。でも、美しくなければ意味がない。だから、トレードオフの状況になると、ビジュアルへのこだわりを優先させてしまいました。気持ちがどうしても、そちらに揺らいでしまうのです。

私自身がそうだったので、ビジネス上の役割やマーケティング的機能よりビジュアルを優先したい、という誘惑に負けてしまう若いWebデザイナーの気持ちは、よく分かります。

Webデザイナーを支配する「強力な固定観念」と「裏の動機」

ビジュアルが大好きであるが故に「見た目はそれなりだが非常によく切れるハサミ」が作れなくなる、というときの心の動きをもう少し深く考えてみると、そこには、Webデザイナーを支配する「強力な固定観念」と「裏の動機」が、大きな影響を与えているのではないかと思います。

特に若いWebデザイナーには、以下のような考えを持つ方も多いのではないでしょうか。

• 本当にイイものなら、アレコレ言わなくても、分かってくれるはずだ
• デザイナーたるもの、できあがった作品がどう見えるかがすべてだ
• デザイナーならデザインで勝負すべきだ。理屈を語らず、黙々と仕事すべきだ
• デザイナーなら、自分の感性で人を振り向かせるべきだ
• デザインを勉強していない人たちより、デザイナーの方が本当に良いものを分かっているはずだ

もしこれを読んで、「それは固定観念じゃないだろう、デザインをする上での真っ当な考えであり、真理だ」と感じた方は、やはり固定観念に強く支配されているといっていいでしょう。そればかりが、デザインのすべてではないからです。

また、「企業とユーザのために、コミュニケーションを最適化する」というWebデザインの本来のミッションを言葉では理解しながらも、実は、以下のような「裏の動機」を強く抱いてデザインしている方もいるのではないでしょうか。

• 自分が本当に良いと思うデザインで、評価されたい
• ロジックではなく、自分のセンスを褒められたい
• 業界内で話題になるような実績を作りたい
• 同業者からすごいと言われ、羨望の眼差しで見られたい
• 海外のデザインポータルに載って、世界中から注目されたい

こういった固定観念や裏の動機が、すべて悪いわけではありません。これらが、デザイナーの創作意欲を刺激し、あるレベルまでのスキルアップを強く促す側面があります。駆け出しのデザイナーなら、これくらいの野心家、理想家でなければならないとも思います。あるいは、デザイナーのこういった固定観念や動機が、絶妙なバランスでビジネス戦略と掛け合わさることで、意外なケミストリーを生み出すこともあります。

しかし、それはやはりバランスと扱われ方が適切だった場合においてのことです。

あまりに強い固定観念や裏の動機は、「見た目はそれなりだが非常によく切れるハサミ」という観点でWebデザインを捉えるときに、大きな弊害を生み出します。ビジネスロジックやユーザニーズより、つい自分の感性を優先させてしまう、あるいは、自分の美意識にそぐわない仕事を「面白くない」と感じてしまう、といったことを引き起こします。

上記のような固定観念や裏の動機を持ったWebデザイナーにとって、「見た目はそれなりだが非常によく切れるハサミ」を作る行為は、理屈では理解できても、気持ちが付いてこないのです。

気持ちが付いてこないから、デザインにマーケティングやブランドや経営戦略の知識もある程度必要だと言われてもそれを勉強する気にはならないし、もしデザインにビジネス的なロジックを持ち込んできたとしても、客観的な判断ではなく、自分の好きなデザインを通すための都合のいい解釈に落ちていってしまうのです。

これが、Webデザイナーがある時点で陥る、ジレンマの一つではないかと思います。

美しいビジュアルの根底にあるデザインの本質

例えば、Webデザイナーにデザインの根拠を尋ねたときに、以下のような答えしか返ってこない、ということはないでしょうか。

• 青がよく映えるように、差し色で赤を使った。
• 硬い印象を減らすため、角丸にした。
• もっともキレイな構図になるよう、写真の縦横比を変えた。
• より繊細な印象にするため、フォントのウエイトを1段下げた。
• ゆったりした印象を与えるため、マージンを広く取った。
• トレンドだからフラットデザインを採用した。
• 操作して気持ちいいからアニメーションを入れた。

どれも、間違ってるわけではありません。ただ、これらの根拠はいずれも「美しいビジュアルを仕上げるため」という視点でしか語られていません。そして、こういった根拠しか出てこないのだとしたら、やはりそのWebデザイナーは、キレイなビジュアル作りという観点でしかWebデザインを捉えていない、ということになります。

多くのWebデザイナーは、まずはPhotoshopなどのデザインソフトのオペレーションを学び、配色やレイアウトなどの、主にグラフィックデザインの分野で使われてきたデザイン理論を学び、成長していきます。

ただし、それはあくまで「美しいビジュアルを作るスキル」に留まったものです。しかし、現実のWebデザインでは、以下のような判断が求められます。

• 高級ホテルのサイトだから、上質な写真と落ち着いた色調で構成したが、コンバージョン率を少しでも上げるため、予約ボタンは目立つよう、あえて全体と馴染まない異質な色にした。
• 競合に対して親しみやすさで勝負しているサービスだから、都会的で洗練された写真ではなく、野暮ったく素人くさい写真をあえて採用した。
• 野菜がたくさん食べられることが最大の強みの飲食チェーンだから、緑を徹底的に押し出したトーン&マナーとした。
• 見た目が美しく質が良い商材だが、知名度が無く、SEOに頼った集客が不可欠なため、テキストをできるだけ盛り込んだWebサイトにデザインした。
• リテラシーの低い運用者によって更新されるので、回り込みなどのレイアウトは廃止し、更新時にトラブルが起きにくい単純なレイアウトにした。
• デザインに疎い一般人が多く使うWebサイトだから、分かりにくいフラットデザインではなく、多少野暮ったくても、より誤解が少ない、少し古くさい立体的なデザインに仕上げた。
• デバイスにかける負荷を軽くして処理速度を上げるため、余計な装飾や動きはすべて排除した。

これらの判断は、ビジュアルの美しさと相反することも多いです。一方で、ユーザのリテラシーや行動動線、市場における強み、SEO、ハードウェア特性に至るまで、様々な知識に基づき、多面的にWebサイトの役割を捉え、バランスを取りながら、デザインにまとめあげようとしています。

そして、これこそが、Webデザインという仕事の本質ではないでしょうか。

本当に「最近のWebデザインはつまらない」のか？

数年前から、「Webデザインはつまらくなった」という人が増えてきたように感じます。

10年ほど前、Flash全盛のころは、ビジュアルのインパクトが強いWebサイトが評価され、企業もそこに費用を投じていました。

しかし、やがてWebサイトのマーケティング的役割が強くなり、ビジュアルリッチなWebサイトの効果が疑問視され、Flashも使えなくなり、タブレットやスマートフォンへの対応も求められるようになって、ビジュアルを作りこむ仕事の意味合いは、かなり変質してきています。

確かに、ビジュアルへの関心をモチベーションにしているWebデザイナーからすると、今のWebデザインは面白くないかもしれません。

ただ、私自身は、この考えに共感できないな、と思っています。なぜなら私は、今のWebデザインがつまらないとは、微塵も思っていないからです。

元々、ビジュアル優先でWebデザインを捉えていた私は、SEOやログ解析、ブログやSNSなどの、ビジュアルとは切り離されたWebの評価軸を経験する中で、その考えが大きく変わりました。Webはビジュアル至上主義であってはいけない、という当たり前のことが、理屈ではなく、思考回路や価値観の中に深く根付いていきました。前述した、強力な固定観念や裏の動機から、自分自身をある程度解き放つことができるようになりました。

マーケティング的要件、技術的制約、ユーザ行動、競合との関係性、そしてクライアントと自分の主観的な感性も含めてビジュアルを組み立て、A/Bテストを行い、その成果をアクセスログで検証し、「思い通りの成果が出た」「これはうまくいかなかった」などといったPDCAを回すという、広い意味でのWebデザインという仕事は、本当に楽しいもので、今現在、私自身は、このことに大きな魅力を感じています。

ただやはり、この楽しさを、理屈ではなく、感情として受け入ることができないと、今のWebデザインという仕事は、確かに退屈なのかもしれません。

ミスマッチが生む不幸なWebデザイン

Webデザイナーのビジュアル偏重が、不幸な結果を招くこともあります。

例えば、著名なWebデザイナーがリニューアルしたWebサイトのコンバージョン率が10分の1以下に落ちたり、デザイナーの間で評判を集め賞を取るようなWebサイトだったのに、Webサイトへの流入が激減して問題になった、といった話をクライアントから聴いたことがあります。これらは、Webデザイナーだけの責任ではなく、発注企業の意思決定、指示の出し方にも大きな問題があると思われますが、少なくとも、Webデザイナーの美意識と、ビジネスの実情は、大きくかい離していました。

一方、デザイナーの間では評判の悪いデザインが、実は大きな問題もなく、企業がWebサイトに与えた役割をきちんと全うしていたり、ユーザをスムーズに目的のコンテンツまで誘導していたりするケースもあります。

このように、表面的なビジュアルを重視してWebサイトの価値を判断するデザイナーの感覚は、Webに具体的な成果を求めるクライアント企業や一般ユーザと、大きくずれていることが多々あります。

ビジュアルが大好きなWebデザイナーにとって、醜いビジュアルが成果を出すという状況は、受け入れがたいものでしょう。それ故に、デザイナー受けの悪いビジュアルが施されていると「これはブランドイメージを棄損している」と辛辣な評価を与え、デザイナー受けの良いデザインには、それがビジネスとしても成功するはずという断定から、最大限の賛辞を送ります。

こういったWebデザイナーの評価には「ブランド」という言葉がよく用いられます。ビジュアルがいい→ブランドイメージが良くなる→ビジネスに貢献する、というのが、ビジュアルを重視したいWebデザイナーの基本的な発想です。

しかし残念ながらWebデザインの世界とは、そんな単純なものではありません。外からビジュアルを見ただけの一面的な評価で、ブランド戦略を語ることなどできず、大抵は的外れな論評をするだけだったりします。

経験豊かなデザイナーでも、Webサイトのビジュアルを見ただけで、その本当の価値は測れないものです。しかし、なぜか自分には正しい審美眼があり、多くのことがよく見えている、と感じてしまうのが、Webデザイナーという職業の悪い癖でしょう。（私自身も、油断をしていると、そういった考えに侵されることがあります）

このようなWebデザイナーにありがちな感覚のズレが、Webデザイナーと企業とのミスマッチを生み、Webデザイナーには成果が生み出せないと判断され、その価値を低く見積もる（Webデザインにお金を出さない／出しても意味がないと考える）空気を生み出しているのだとしたら、非常に残念なことです。

Webデザイナーに求められる自らのスタンス

とはいうものの、実のところ、Webデザインも細分化されていて、「これがWebデザインである」と一概に言えない状況にもなっています。

例えば、「工芸品のように美しいハサミ」のような、ビジュアルのインパクトを最優先においた、作家性の高いWebサイトのニーズも、一定数存在します。ビジネスとしての活用方法は発注企業が考えるとして、Webデザイナーは、自らの感性と審美眼に基づき、自分の世界を追及することを求められます。こういう案件では、企業はあまり口を出さない方がいいかもしれません。

これはこれで、とても魅力的な仕事です。ただし、その市場は極めて狭く、競争も激しいでしょう。その世界を極めるには、いわゆるWebデザインとは異なるアプローチをしなければなりません。ビジュアル志向が非常に強いWebデザイナーは、この世界を目指していくのも一つの選択肢だと思います。

一方、そういったビジュアルの支配力が強い世界を目指さないのだとすると、Webデザイナーというのはやはり、ビジュアル以外の知識も豊富に身に付け、ビジュアル一辺倒の価値観を変えていかなければなりません。

つまり、マーケティング、心理学、SEO、データサイエンス、ハードウェア、プログラミング、サーバサイド、論理的思考、ビジネスコミュニケーション、あるいは経営や法務に至るまで、Webと相関する幅広い知識をバックボーンに持ちながら、決して器用貧乏という訳でもなく、専門分野であるデザインに関してはスペシャリストであるような、そんなWebデザイナーを目指す必要があるのではないでしょうか。

また一方で、ビジュアル以外の価値観も重視して仕事をしている会社、ビジュアル以外の幅広い価値観をWebデザイナーに教えてくれるような会社で働くことも、これらのWebデザイナーには必要なことではないかと思います。

Web制作会社にも求められる明確な価値観

Webデザイナーたちの未来を背負うWeb制作会社もまた、そのポリシーを明確にしておく必要があります。

私の会社では、ビジュアルの前にビジネスを考えなければならない、と口を酸っぱくいいながらも、画像テキストの文字詰めはきちんと行いますし、写真もできる限り綺麗に見えるよう調整します。一本の線を加えるかどうか、もっともバランスよく見えるマージンにも、細心の注意を払って、社内でブラッシュアップします。

しかしこれは、同じ手間で作れるのならより綺麗に仕上げた方がいい、明確な効果が分からない領域はデザイナーの審美眼に委ねた方がいい、という判断からです。ただし、ビジュアルの追及が、マーケティング的機能、あるいは制作時間やコストへ悪影響を与えかねない場合には、ビジュアルの追及をやめ、本来優先すべき事項にフォーカスします。

つまり、あくまで、「見た目はそれなりだが非常によく切れるハサミ」のアプローチです。そして、冒頭の例で挙げた「安い材質の持ち手に変える」に相応するような、一連の意思決定、判断こそが、Webデザインの本質であると、スタッフに伝えています。

先ほども述べたように、Webデザインと言っても様々なニーズ、様々な価値観があります。これはわが社の価値観であって、会社によっていろいろな見方があってしかるべきです。ただ、多様な世界だからこそ、Web制作会社としてのデザインの価値観を一貫させて、スタッフに対して明確にしていくことが、非常に大事なのではないかと思います。

例えば、以下のようなWebデザイナーが混在する会社だと、現場はどうなるでしょうか？

• とにかく見た目重視で、徹底的に見た目にこだわるデザイナー
• マーケティング的機能を最優先に考え、最終的には見た目は優先しないデザイナー
• 定時内に帰ることが最優先で、そのためには見た目も機能も妥協するデザイナー

こういった価値観の違いを放置したまま、啓蒙や教育もなく、採用においても一貫したポリシーがない環境で働くと、解消できない混乱や衝突が起こり、それに起因する不平不満が大きくなりがちだと、経験的に思います。

私が会社を作るときは、「私たちが考えるWebデザインとは、こうだ」ということを明確にし、一貫した価値観でアウトプットを評価し、採用においてもこの価値観へコミットできるかどうかを重視することをしよう、と強く決めていました。それが今後どう働くかはわかりませんが、少なくとも現時点では、基本的な価値観のところでデザイナーたちとのかい離が生まれるシーンがほとんどないと、強く実感しています。

まとめ

ここでは、Webデザインに特化したお話をしましたが、これらは、アプリやソフトウェアを含むUIデザイン全般、あるいはプロダクトデザイン、商業デザイン全般に通じる内容ではないかと思います。

デザイナーという仕事は奥が深く、環境は厳しく、正解がない世界で試行錯誤しなければならない、非常に難しい仕事だと思います。しかし、今の社会に決して欠くことのできない職業でもあります。デザイナーがいなければ、どんなに素晴らしいアイデアも形にはならず、人々にその価値を届けることはできません。

だからこそ、デザイナー、あるいはデザインを生業とする会社が、ここに書かれているようなことを真剣に考え、デザインの社会的価値が少しでも高まるような活動ができるようになればいいなと思い、現時点の自分の考えをまとまりなく文章にしてみました。

人々の注目は、iPhone6とApple Watchだったと思いますが、Web制作者としてちょっとした驚きだったのは、発表と同時にWebサイトがスマートフォン対応したことです。

現在、多くの企業サイトで、スマートフォンからのアクセスが急増しています。スマートフォンユーザが直接的なターゲットとは考えにくい企業サイトでさえ、スマートフォンからのアクセスが3～4割を超えることが当たり前になってきました。

モバイルファーストという言葉も生まれ、スマートフォン対応をしているかどうかを、検索アルゴリズムの評価項目に加えているとGoogleが公言するほど、「スマートフォン対応＝正しいWebサイト」とさえいえるようなムードの中で、アップルだけは、頑なにWebサイトのスマートフォン対応を行なってきませんでした。

このアップルの選択は、「アップルでさえスマートフォン対応をしていないのだから」という理由で、企業がスマートフォン対策を見送る際の理由の一つにもなっていました。

しかし、ここに来てのアップルのスマートフォン対応は、この流れに少なからず影響を与える気がします。

このエントリーでは、まず、今までアップルがスマートフォン対策をしなかったいくつかの理由を推測しています。そのうえで、アップルがこの段階でスマートフォン対応を行った理由を考察します。

しなかった理由1：スマートフォンユーザが重要でなかったから

こう書くと当たり前っぽくなってしまうのですが、まず、アップルのWebサイトは、購入前の顧客をターゲットにしています。そのうえで、スマートフォンを使って訪れるユーザには、発売済のiPhone利用者と、他社スマートフォン利用者の2種類が存在します。

前者は、すでにiPhoneを使っていて、その上でWebサイトに訪れていることから、アップルへの信頼は十分で、購入確度は高いといえます。アップルに懐疑的ならそもそも選択肢にならず、Webサイトにも来ないでしょう。そう考えると、わざわざスマートフォン対応をしてまで出迎える必然性はないかもしれません。

一方、Androidなどを搭載した他社スマートフォンを利用しているユーザはどうでしょうか。アップルにとって、こういったユーザは、競合製品を使っているユーザです。アップルが、競合製品でのユーザ体験を、自社サイトで高めてあげる必要はあるでしょうか？

このようにスマートフォンでWebサイトに訪問するユーザを詳細に考えていった結果、結局スマートフォン対応の必要はない、と判断していた可能性は十分にあります。

しなかった理由2：戦略上の課題ではなかったから

アップルの戦略をかなりざっくりとらえると（実際はもっと複雑ですが）、このような構造になっているのではないでしょうか。

この中で、売上げ／利益に直接的な影響を与えているのは、主に金色の部分となります。一方、Webサイトは広告戦略の中でのタッチポイントの一つではあり、必ず経由すべきタッチポイントではありません。例えば、あなたの身の回りにも、アップルのWebサイトに訪れず、友人の口コミやテレビの認知、あるいはショップの体験で、iPhone購入の意思決定をした人は多いのではないでしょうか。

iPhone、iPod、Mac、iPadと、製品によって戦術は異なりますが、基本的な戦略構造に違いはありません。アップル製品は、Webサイトよりもはるか上位レイヤーが主戦場であり、ここでの成果で、大きな売上げをあげていると考えられます。

そう考えたときに、スマートフォン対応がどの程度重要でしょうか。ここで大事なのは、スマートフォン対応が戦略上、下位にあることではありません。全体の戦略に与えるインパクトの大きさです。

もちろん、「ないよりあった方がいい」という考えもあるでしょう。スマートフォン対応をすることで、顧客に転換するユーザもいないわけではないでしょう。しかしそれは、全体の戦略の中では、些細な誤差の範疇に入るレベルの話ではないでしょうか。

と、このようにアップルの戦略構造を考えていくと、スマートフォン対応にこだわる必要はなかった、という考えに至ったことも推測されます。

しなかった理由3：強いブランド力があったから

いうまでもありませんが、アップルは非常に知名度の高いブランドです。彼らの販売する製品をはじめ、ビジネスのスタイルから、故スティーブ・ジョブスの残した言葉に至るまで、あらゆる文脈が強固なブランドを形成しています。「ユーザの声を聴かない」などという言葉も、彼ららしいマーケティング論として知らせています。

世の中の主流に「No!」を突きつける姿勢は、彼ららしく感じます。強いブランドを持っているから、スマートフォン閲覧時に多少不便でも、致命的なブランド体験にはなりません。そもそも、彼らのメインターゲットは、彼らへのロイヤリティが高く、リテラシーも高いため、そんなことでアップルを否定するようなユーザも少ないでしょう。

このように、彼らのブランド力を評価すると、スマートフォン対応をすべき必然性は見つからなかったのかもしれません。

しなかった理由4：ビジュアルを大きく見てほしかったから

アップルのWebサイトを見ると、ビジュアルが非常に大きく扱われているのがわかります。PCで見たときに、画面から溢れんばかりに製品写真が飛び出してきます。

アップルにとっては、プロダクト自体がタレントです。これら製品の魅力の一つは美しいプロダクトデザインであり、それは大きな画面でなければ伝わりにくいものです。

もしもスマートフォン対応をした場合、これらの写真は小さく収まってしまい、魅力を伝えにくくなるでしょう。ピンチして拡大して見ればいい、という考えもありますが、PC向けにレイアウトされたサイトならともかく、スマートフォンに最適化さえてしまっていると、拡大せず、小さいままで見て判断するユーザが増えるのではないでしょうか。

このように、アップル製品にとって、プロダクトデザインというのは強力なアドバンテージの一であり、これをスマートフォン上でもっとも効果的に見せる方法が、PCサイトのまま、拡大してみてもらう、という判断だった可能性もあるのではないでしょうか。

しなかった理由5：ポリシーがあったから

さて、最後の理由は、スマートフォン対応そのものに対する批判です。スマートフォン対応＝正しいWebサイトな風潮がある、と冒頭に書きましたが、スマートフォン対応に批判的な見解も、一部では存在します。例えば、スマートフォン対応をしてしまうと、以下のようなデメリットが発生する、という意見です。

• PCサイトとの違いで戸惑うユーザが発生する。
• 情報の一覧性がなくなる。

個人的には、これらは、ある限られた条件下でのみ露見するデメリットであり、実際には、PCサイトをスマートフォンで見せることのデメリットも含めて、判断しなければならないと思います。が、いずれにしろ、アップルがアンチ・スマートフォン対応派であった可能性は十分にあります。

これは、技術的なメリットは多々あったにもかかわらず、完全否定したFlashに対する態度ともどことなく似たものを感じます。また、前述のブランド力という前提があるからこそ、アンチなポジションでいることができたとも言えます。

いずれにしろ、合理的な判断だけでなく、「私たちはこう思う」という強い信念やポリシーを持っていることも、アップルがスマートフォン対応をしなかった理由の一つとして考えられます。

今さらスマートフォン対応をした理由

上記のように、スマートフォン対応を見送る理由はいくつか考えられるのですが、この段階でスマートフォン対応をしたということは、これらの前提条件が変わった、もしくは誤っていた、ということなのだと思います。

考えられる理由は、大きく2つあると思います。

1つ目は、競争の激化と戦略の変化です。

既に伝えられている通り、日本では好調なiPhoneも、世界ではシェアを大きく落としてきています。コストリーダーシップは端から考えていないアップルにとって、Android系スマートフォンの全てが競合というわけではないしょうが、iPhone6でAndroid系スマートフォンへの対抗措置をいくつか打ってきたことを考えると、これ以上のシェア低下は避けたい、という思惑が見えてきます。そうすると、絶対的なブランド力を背景に唯我独尊を貫くというより、レッドオーシャンの中で死闘を繰り広げるような戦略を選ばざるをえなくなります。

こういう状況で勝つためには、ランチェスター戦略に乗っ取って考えれば、強者（アップル）は徹底的に弱者の差別化に追随することです。つまり、見劣りする部分は模倣して対抗する、というのが基本的な行動様式になります。Webサイトのスマートフォン対応自体が、Android系スマートフォンにおける差別化戦略ではまったくありませんし、それによってiPhone6が大きく売れるようなことはないと思いますが、局地戦化している現状において、できることはやっておこう、という判断が働いたと考えられます。

また、別の見方をすれば、アップルのイノベーションの質が変わったともいえます。

イノベーションには破壊的イノベーションと持続的イノベーションがありますが、iMac、iPod、iPhone、iPadと立て続けに既存カテゴリを壊す新製品を発表してきたアップルの基本戦略は、明らかに破壊的イノベーションでした。しかし今現在のアップルの基本戦略は、持続的イノベーションです。革新的な製品で既存市場を破壊していく攻めの戦略ではなく、成功した製品をより洗練させて競合の攻撃を防ぐ守りの戦略です。

こういう戦略において重要なのは、やはり細かな弱点を潰しながら、ディテールをアップデートさせていくことです。それは製品に対してだけではなく、戦略、戦術においてもいえることです。売上げに影響の大きい上位戦略のみならず、より下部に位置する戦略・戦術に至るまで、細かな改善を加えていくことが、主なアクションになってきます。

こういった諸々の戦略的背景の中で、Webサイトが非スマートフォン対応であることに目を向け、スマートフォン対応をするという判断に傾いたのは、容易に想像できることです。

2つ目の理由は、スマートフォンの大型化と画質向上ではないでしょうか。しなかった理由4にあたる部分ですが、iPhone6の大型化、そして今後もその傾向が続くと考えると、スマートフォンで、アップルの美しい製品を魅力的に伝える環境が整った、アップルブランドが許容できる表現が可能になった、と解釈したのかもしれません。

些細なことですが、さすがアップルだなと思ったのは、例えばPCでは横向きの画像を、スマホでは縦向きの画像に変えるなど、デバイスごとにきちんと画像を用意していることで、このあたりに、ブラウザでできるだけ製品を美しく見せるんだ、というアップルの強い意志を感じることができます。

iPhone6特設ページのリードビジュアルは、PC版（上）では横置き画像だが、スマートフォン版（下）では縦置き画像になっている。「Keynoteを見る」の表示順も調整されており、機械的なレスポンシブではなく、スマートフォンでの見え方をきちんと考慮したスマートフォン対応になっている。

まとめ

さて、こういったアップルの動きから私たちが学ばなければならないのは、「他社の戦略を安易に模倣しない」ということです。

アップルが今までスマートフォン対応をせず、ここに来てスマートフォン対応をした理由は、上記のようなことを複合的に判断したからでしょう。これらはすべて、アップルというブランド、置かれている環境が前提の判断です。

認知の低いブランドであり、さらに「お客様最優先」がコンセプトの会社だったら、また状況は異なります。BtoC向けのグローバル企業と、BtoB向けのローカル企業では、判断基準も大きく変わるでしょう。

個人的には、ほとんどの企業、ブランドはスマートフォン対応をすべき、というのが私の考えです。しかし、そこにはコストという制約がどうしても生まれくるので、投資に対するリターンを見極めて、優先順位を付けていく必要があります。そのときに、アップルがスマートフォン対応をしないからわが社もしない、アップルがしたからわが社もする、という安易な追随は、間違った判断、見合わない投資をしてしまう可能性もあります。

上記のような、スマートフォン化すべき背景を自社になぞらえて考え、そのうえで、スマートフォン対応を実施するのか、しないのか、するのであればレスポンシブなのか、そうではない方法を取るのか、などを決断しなければならないのだと思います。