刷新にあたって、受注から納品までをサブタスクを含めて約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制作に関わる多くの方々の働き方をより良くする何かのキッカケになれば幸いです。

• 設計者がコーダーに文書構造の意図を説明する時間の無駄
• 設計者が考えたファイル構造やヘッダ情報を定義するためのドキュメントの無駄
• コーディング時にWFやPSD上のテキストをコピペして移し替える無駄
• リンク構造や動き、使い勝手を紙面上で表現しようとする努力の無駄
• 共通パーツに修正が入った時に各ページごとに修正を入れていく無駄
• PC用とスマホ用の2種類のWFを作る無駄
• 更新するたびに新しいWFを印刷する紙の無駄

いずれも工夫次第で軽減できる問題でしたが、意思疎通のための中間成果物の体裁を整えるための多くの時間が無駄では？という疑問は常に頭の片隅にありました。そこで、アプリ界隈で勃発したプロトタイプで設計をする流れに乗っかり、1年半ほど前にWFの撤廃とHTMLプロトタイプへの移行を決めました。

今現在、WFを作ることはほとんどなくなり、HTMLプロトタイプがすっかり定着しました。こうなるまでに私たちが取り組んだことや移行して感じたことなどをここで共有したいと思います。

ワイヤーフレームを捨てるためにしたこと

プロトタイプで設計をする場合、まずペーパープロタイプを作り、それから専用ツールでプロトタイプを作るという流れが一般的ではないでしょうか。ペーパープロトタイプを作るのは私たちも同じですが、実は専用ツールは特に使わず、テキストエディタなどを使い、ソースコードベタ書きでプロトタイプを作っています。非効率に思える方法を選択したのは主に以下のような理由からです。

1. できればそのままコーディングの工程で使える精度の高いソースコードにしておきたい
2. 設計者とコーダーの制作・実装環境を統合したい
3. 設計者も基本的なHTMLなら自分で書けるくらいに理解しておいてほしい
4. 個別性の高いUIは、都度カスタマイズできる柔軟性がほしい
5. 私たちの会社では設計者がHTMLを扱えたので、そのスキルを活かしたい

最近はプロトタイプツールも多様化しており、すでに私たちの希望を満たすツールも存在しているかもしれませんが、1年半前の時点では、上記のような理由からソースコードベタ書きでプロトタイプを作るという選択になりました。とはいえ、毎回一からプロトタイプを作るのはさすがに効率が悪いため、基本テンプレートを用意してすぐに使えるようにしました。

このように数種類のレイアウトパターンのテンプレートが用意されています。

パーツごとにソースコードが用意されており、ソースのコピペでプロトタイプが作れるようになっています。

マルチデバイス対応されているので、スマホ用に（PC用に）わざわざ何かを作る必要はありません。

メモ機能があり、デザイナーやコーダーへの連絡事項があればページごとに書き込めるようになっています。

設計者はこのテンプレートを使って設計をします。以下は一番最近作ったプロトタイプですが、作る時間だけでいえば、だいたい30ページほどのプロトタイプを1日程度で作っています。（作る時間よりもその前に考える時間の方が長い）

DTJプロジェクトのプロトタイプ

ちなみにペーパープロトタイプもこんな感じの印刷用テンプレートを用意してて、印刷して使っています。

スマートフォン用のテンプレートと実際にスケッチしたサンプル

PC用のテンプレートと実際にスケッチしたサンプル

ペーパープロトタイプについては、私たちの場合はクライアントに見せる機会はほとんどありません。というのも、私たちは直請け案件が多く、大抵は担当者や意思決定者がWebに詳しくなく、ペーパープロトタイプを見せられてもどう判断していいかわからない、となりがちなためです。そのため、ペーパープロトタイプは主に社内での議論や意思疎通を目的に作っています。

ワイヤーフレームを捨てて良かったこと

ワイヤーフレームを捨ててHTMLプロトタイプに移行したことはメリットの方が多かったと感じています。具体的には以下のような点です。

• 設計時のファイルがコーディング時に流用できるため、制作全体の生産効率が少し上がった。
• 設計者が考えたことがHTMLに反映されていない、ということが減った。
• titleタグやMetaタグなど、わざわざそれを指定するためのドキュメントを設計者が作り、そこからコーダーがデータを入力する、といった余計な手間が減った。
• ヘッダやフッタなどの共通パーツの外部ファイル化やエディタの一括置換が使えるようになったことで、変更が速やかに行えるようになった。
• クライアントのリテラシーによっては、提出用にわざわざ印刷物を用意する必要がなくなった。
• リンク構造、画面サイズや文字量、レスポンシブの振る舞いなどは、プロトタイプを見れば理解してもらえるようになった。
• 設計が終われば、CMSの基本テンプレート作成などをビジュアルデザインと同時並行で進めることも可能になった。（ただし手戻りのリスクが高まるので基本的にはやらない）

ワイヤーフレームを捨てても変わらなかったこと

一方で、HTMLプロトタイプも完全ではありませんでした。以下のような部分は、WFと大差ありませんでした。

• プロトタイプで作ったHTMLをそのまま活用してコーディングはCSSとJSに集中できる、というところまではいかなかった。コーディング時に作り直す箇所は多く、プロトタイプ段階でHTMLの精度にこだわってもあまり意味がなかった。
• 「完成したデザインを見なければ判断できない」というクライアントも多く、結局はビジュアルデザインが仕上がってから設計に関するフィードバックが来ることが多かった。
• 一見レイアウトが完成しているように見えるため、デザイナーがそれに引っ張られて、安易にそのレイアウトを踏襲するという「完成度の高いWF」と同じ問題が起きがちだった。
• 1ページだけのランディングページやミニサイトの場合は、WFを作った方が早いこともあった。

Web制作の場合、プロトタイプ化によってクライアントの意思決定がよりスムーズになるのでは？という期待は大きいと思いますが、ペーパープロトタイプにしろ、HTMLプロトタイプにしろ、WFにしろ、未完成のものから完成品を想像するのは結構リテラシーが必要で、これができるクライアントは少なく、やはりビジュアルを見てから色々と気になってきて要望が来る、ということは非常に多いのが実情です。

そのため、WFをやめてプロトタイプにすることでビジュアルデザイン以降の差し戻しが減るんじゃないか、というのはあまり期待しない方がいいと思います。

クライアントからのフィードバックで作り直しなどの手間は増えないのか？

Web制作でWFを捨ててHTMLプロトタイプにするときの一番の懸念は、いきなりHTML化してしまうと、修正や要望が出た時にWFよりも手間がかかるのでは、という点ではないでしょうか。結論からいうと、恐れることはまったくありませんでした。以下のようなことがその理由です。

• どういうページを作るかを事前に入念に協議してから着手するため、HMTLプロトタイプを大幅に作り直さないといけないような大きな認識違いがそもそも起きにくかった。
• WebサイトのUI設計は割とパターン化しているところもあり、クライアントの想像を大きく超えるようなことにはほとんどならなかった。
• クライアントの関心はWebサイトの目的と、それを達成するために掲載されるコンテンツ内容に向かうことがほとんどであり、設計やUIの細部の判断は任せられることが多かった。
• ビジュアルデザインまでいかない段階では、クライアントも細部を入念に見ないことが多かった。
• 建設的な議論だけしてあとは前に進むようなディレクションをすることで、設計段階での不毛な試行錯誤や時間の浪費を防いでいた。
• 検索や置換が容易に行える開発用のエディタを用い、また共通パーツをテンプレート化するなどしているため、むしろ速やかに要望を反映できることも多かった。

課題とまとめ

というわけで、私たちの会社ではHTMLプロトタイプへの移行はメリットの方が圧倒的に多く、今後もWFは極力作らないつもりですが、今の私たちのやり方の最大の課題は、設計者にHTMLのスキルをそれなりに求める点でしょう。

たまたまHTMLが分かるメンバー構成だったから実現できましたが、HTMLは扱えないが設計業務はできるというメンバーが入社した際には、やり方を考えなくてはなりません。HTML自体は1か月もやれば習得できますが、PowerPointのWFと同じ速度で自在に思考し、オペレーションするにはもう少し時間がかかりそうな気もします。

ただこのあたりは、ツールで解決できるかな、とも思っています。先日AdobeからXDというプロトタイピングツールがリリースされたように、今後はプロトタイピングツールがますます多様化・充実してくることが予想されます。私たちもおそらくどこかの段階で、ツールを使うワークフローに移行するでしょう。そうなれば、HTMLを書けないといけないという私たちの問題は、自然に解決されるのではないかと思います。

というわけで、結論としてプロトタイプへの移行はおすすめです。WFを作っている制作会社の方々も、是非積極的にチャレンジしてみてください。

その冒頭でも触れたのですが、私自身は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プロデューサーの信頼は失われます。短期的に利益を得ても、長期的には不利益になります。結局、プロデューサーが長期間にわたり評価されるには、フェアであることが一番の近道なのだと私は考えています。

以下のスライドは、実際に使われたスライドです。公開用に細部は少し変えましたが、内容はほとんどそのままです。

クライアントは、株式会社マネジメントサービスセンター（以下、MSC）という企業の人事戦略や人材育成の支援を行っているB2B企業です。ターゲットは人事部や経営層などで、前段として戦略、設計が完了し、ベースとなるデザイン案を初めて提案する際に使ったものです。こちらを元に、ステップごとに細かな解説をします。（スライド中に出てくる検討プロセスは4段階ですが、本エントリーでは6つのステップとします）

ステップ１：デザインの役割を定義する（P.２～P.3）

「先進的な印象を与えたい」「親しみのある印象も与えたい」など、デザインとして相反する方向性の要望で中途半端な方向に行くことはないでしょうか。こういったことは、デザインの役割を定義していないために起こりえます。ユーザはデザインだけですべての印象を決めるわけではありません。コピーや写真のモチーフなどで受け取る印象は大きく変わります。

そのため、まずはこれから議論するデザインとはWebサイト全体の構成要素のどれを指し、デザインにはどういう役割を与え、どういう役割は与えないのか、ということを明確に定義します。これによって、デザインを確認する時の基本的な視点を共有します。

ステップ２：ターゲット像を描く（P.4～P.7）

デザイン提案で失敗するのは、クライアント企業の担当者とデザイナーの主観で議論を進めてしまうことです。デザイナーが勝手に信じている「私はこう思う」（I）の視点ではなく、デザイナーがクライアントの顔色を窺った「あなたはこう思いますか？」（You）の視点でもなく、「顧客はこう思うだろう」（They）の視点で、双方が議論しなければなりません。そのために必要なのがThey、つまりターゲットの定義です。

このプレゼンでは、ターゲットとなる人事担当者のユーザ特性と価値観を整理しています。氏名や性別、年齢までを細かく定義したペルソナにしていないのは、デザインに影響を与えるであろう特性にのみフォーカスするためです。この内容の妥当性は、顧客を知るクライアントへのヒアリングから行います。

ステップ３：ターゲットに与えるイメージを決める（P.8～P.10）

描いたターゲットに対して、どういうイメージを与えたいかを整理し、方向性を導き出します。この提案では、まずは企業のブランドイメージを解体してキーワード化し、優先順位を付けています。その後、優先度の高いキーワード群をイメージスケールに落とし、全体の配色やトーン＆マナーの大きな方向性を決めています。配色を決めるときは、CIとの兼ね合いもあるので、ポジショニングしたい領域の中で、CIと相性が良い配色を選んでいきます。なお、選定から漏れたキーワードの中で重要なものは、デザインではなく、コンテンツやコピーで実現していくことになります。

ステップ４：参考サイトから共通パターンを抽出する（P.11～P.20）

参考サイトの抽出は、多くのデザイナーがすでに行っていることでしょう。しかし、その抽出基準を「自分が提案したいデザイン」あるいは「顧客が作りたがっているデザイン」に置いて、デザインポータルから見映えがいいサイトを選んでいないでしょうか？

これだと、前述でいうところのIやYouの視点であり、誰かの主観に委ねた決定を促すことになります。そしてその主観が折り合わずにデザインが決まらず、スケジュール遅延やデザイナーの疲弊を招きます。そうではなく、ここでもTheyの視点を基準とし、参考サイトを選ばないといけません。

MSC様の場合は、信頼感の訴求が情緒的役割における最重要課題でしたので、「ターゲットが信頼を感じるのは、実際のところどういうデザインなのか？」という視点から参考サイトを選びました。ここでは参考サイトを「誠実な企業賞」を受賞した企業のWebサイトから選定しています。ポイントは、「信頼できるイメージを持ったWebサイト」ではなく、「信頼できるイメージを持った企業」を起点に選ぶという点です。

例えば、青を採用すると信頼感が増す、と一般的には考えられています。しかしこれは、信頼感のある企業の多くが青い色を採用しているから、青→信頼感と人々が認識しやすい、とも考えられます。色の場合はある程度配色理論が存在するのでこの方法でも通用しますが、レイアウト、書体、形状といった他の要素になると、明確な理論があるわけではありません。例えば、明朝とゴシックと、どちらの方が信頼感を訴求できるでしょうか？個人的な感想以上のことをきちんとは答えられる人はいないでしょう。

さらに、「信頼できるWebサイト」を基準に選定すると、その時点からWebデザイナーによる「信頼できるデザインはこれ」という固定観念によってフィルタリングされてしまいがちです。これもまた、結局はWebデザイナーの主観的なイメージを起点にすることになり、Webデザイナーの固定観念を超えるアイデアを導き出すことが難しくなります。

このあたりを突き詰めると完全に客観的になることはできませんが、できるだけ客観的な評価や指標を交えながら、「ターゲットが信頼感を抱くであろう企業」を選び、その企業が採用しているデザイン要素を分解し、共通パターンを見つけ出し、それを採用する、という方法をとっています。

なお、こういう選び方をすると、クオリティの低いデザインが含まれることが気になるかもしれません。しかしそのことは問題ありません、参考サイトは模倣するために選んでいるわけではないからです。あくまで、「印象の方向性」を掴み、信頼感を与えている企業が採用しているデザイン上の共通パターンを導くために選んでいるためです。

ステップ５：啓蒙する（P.21～P.25）

参考サイトのみを基準にした方向性の絞り込み方をすると、過去を基準にしてしまう、正しくない方法を正しいと解釈してしまうリスクがあります。そのため、最新のトレンドと一般的な理論も検討材料に含めます。

トレンドに関しては、以下のような領域について採用する、と意識する必要があります。

• 採用することに機能的なメリットが明確にあると考えられる領域（積極的採用）
• 明確な効果は分からないが、企業側にも強い要望がない領域（消極的採用）

トレンドに従うことにメリットがあるのであれば、当然それは積極的に採用すべきでしょう。一方で消極的な理由でトレンドに従うという判断もあり得ます。つまり、誰も正解が分からないのであればひとまずみんながやっていることに従ってみよう、という考え方です。そして、デメリットやリスクがある、他に優先すべきことがある場合には、トレンドの採用は見送ります。間違っても「トレンドだから従うべき」といったような思考停止状態でトレンドに追随してはいけません。

また、トレンド以外に、一般的なユーザビリティのセオリーについても少し触れています。ここでのはシンプルな説明に徹しています。それは、クライアントの担当者はユーザビリティの勉強をしたいわけではないからです。制作者は時に、紙面と時間を使った啓蒙活動をしてしまいがちですが、過度な情報提供は本当に理解すべきポイントを見失わせます。デザイン提案の趣旨はあくまで円滑なコミュニケーションと認識の共有であり、勉強や講義ではないので、ポイントのみをシンプルに解説するのが良いでしょう。

最後に、デザイン決定で陥りがちな注意事項を整理し、間違った方法でデザインの意思決定をしないようアドバイスを行っています。

ステップ6：実際のデザインに落とし込む

このように、ブランドとして追求したいトーン&マナー、似たような印象を与えている企業におけるデザインの共通パターン、トレンドやユーザビリティのセオリーなどを踏まえて作った最初のデザイン案の一つが以下のようなものです。

資料内で定義した諸条件に即しながら、実際の見え面として綺麗に収まるように微調整を加えていきいます。例えば、参考サイトから導き出した共通パターンでは、メインビジュアルは直接的なモチーフで、キャッチは明朝体であることが多い、ということでしたが、デザイナーの判断でこのバリエーション案においてはそこを変えています。

これは、理屈だけで固めたデザインが必ずしも良いデザインになるわけではないためです。料理に例えるなら、概ねレシピ通りに作りながらも、味見をしながら塩加減を調整は入れる、といったことに近いでしょうか。ただし、いくら塩加減が足りないからといってレシピにはない調味料を加えると味が壊れてしまうように、論理的に詰めた基本的な前提条件を無視すると、ビジネスへと繋がるデザインのコンセプトを見失ってしまうため、あくまで行うのは微調整の範囲とします。

このようなプロセスで行った一番最初のデザイン提案の後、クライアントからの意見を吸収し、最終的に公開されたのが以下のデザインになります。（実際のサイトはこちら）

クライアントとの協議の後、やや冷たく暗い印象を軽減するために青を追加したり、メインビジュアルの変更や調整は行いましたが、デザイン提案の基本からは外れることなく、できるだけ客観的な視点で調整を加えていきました。結果、デザインの基本的な方向性で躓くことはなく、スムーズにその後のデザイン展開に入っていきました。

このようにクライアントに対して、「なぜ私たちはこういうデザインに至ったのか？」という思考のプロセスを説明することは非常に大切なことなのではないかと思います。クライアントから与えられたインプット情報からデザイナーが頭の中で考え至ったことを追体験してもらえれば、主観や感情に流されずにデザインを受け取ってもらえることも多いでしょう。

もちろん、デザインを一発で通すのが目的ではなく、最終的には、様々な制約のもとにもっとも合理的な判断をするのが目的です。だから、デザイン提案の後に議論やフィードバック、軌道修正が発生することは悪いことではありません。それでも、このように前提条件の共有がきちんとできていれば、議論やフィードバックも建設的なものになるのではないかと思います。

この提案の課題

さて、ここで紹介したデザイン提案方法は、あるプロジェクトで実際に行ったものですが、これも万能ではなく、いくつかの課題や弱点があります。例えば、以下のようなことです。

１．斬新なアイデアが出にくい

特に参考サイトを抽出するプロセスでは、発想の起点を既存の他社サイトに置いています。またトレンドの採用には妥当性を加味し、ユーザビリティーの最低限のセオリーにも従っていきます。そのため、今までに見たことのない驚きのあるデザイン、画期的なデザインにはなりにくい傾向があります。エッジの立った斬新なデザインを求められる場合には、これとはまったく異なるプロセスでの検討と提案をしなければならないでしょう。

２．意思決定権者不在では意味がない

いくら丁寧に説明を行っても、それを聴くのが担当者だけで、最終的な意思決定権者に届かなければあまり意味はありません。デザインのコンセプト提案時には、必ず意思決定者を同席してもらう必要があります。

３．デザイナー側が論理的でなければならない

デザインをロジカルに提案するということは、デザイナー自身が日ごろから論理的にデザインしなければならない、ということを意味します。ディレクターがいくらがんばって付け焼刃的に説明資料を作っても、デザイナーにその意識がなければ、議論の末に前提条件が変わったり、新しい要望が出てきたりするたびに、コンセプトとデザインが壊れていってしまいます。大事なのは、クライアント主導でもディレクター主導でもなく、デザイナー主導で提案を行うことです。

４．スピード感がなくなる

例えば「明日までにデザインを作ってくれ」というような要望には、このような提案は不向きでしょう。なぜならコンセプトや調査に最低でも2日はかかるからです。それなりの検討時間が取れるプロジェクトでなければ、こういった提案はできません。ただし、クライアントが協力的で、デザイナーとディスカッションしながらともにコンセプトを作り上げるというフローが可能であれば、スピードの問題は少しは解消されるかもしれません。

最後に

弊社では、デザイン提案はあまりパターン化すべきではない、と考えています。実際、クライアントとの関係性、担当者のリテラシー、プロジェクトが置かれている状況、デザインの役割などによって、私たちの提案内容は大きく変わります。デザインの方向性について既に十分に握れていて合意形成できている場合には、デザインだけを提案することもあります。また、もう少し大規模な案件であれば、リサーチにもっとコストと時間を費やすこともあります。ここで紹介した提案はまだまだヒューリスティックの範疇であり、客観性については完全ではないと弊社でも考えています。

いずれのやり方を取るにしろ、このような資料を作る目的は一発でデザインOKをもらうことではありません。最終的にもっとも合理的な判断をするために、もっとも効果的でコンパクトな方法で認識の共有化を図るのが目的です。そのため、最初のデザイン提案の後に、フィードバックや軌道修正が発生することは悪いことではありません。それでも、このように思考のプロセスを明示し前提条件を押さえておけば、主観や思い込みの衝突が減り、議論もずいぶんと建設的になるという実感があります。

というわけで、ここで紹介した方法はあくまで一例であり、例えばこのような提案の仕方もあります、というくらいの気持ちで参考にしてもらえれば幸いです。

先日、プリンタのトナーが切れてしまい、ちょっとバタバタしてしまいました。

トナーが少なくなってることは、アラートが出たタイミングで気付きました。しかしその時は、トナーをオンラインで注文という、実に簡単な作業を面倒と思い、また、すぐにはなくならないだろうという読みから、後回しにしました。

そして、大事な打ち合わせの直前。大量に印刷しなければならない段階で、トナーが切れてしまいました。クライアントにPDFをメールで送り、事情をお話したら、快く代わりに印刷してくれました。ただ、その翌日も打ち合わせがあって印刷が必要だったので、渋谷の量販店に在庫があるかを電話で確認し、急きょ店頭に買いに行き、という感じで、なんだかトナー1つに行動を振り回されてしまいました。

この件は、気づいたときにすぐに頼んでいれば以下のタスクで実行できました。

1. ネットでトナーを注文する（1分）
2. トナーが切れたら新しいのに入れ替える（1分）

でも、私がこれを後回しにしたがために、タスクが以下のように膨れ上がりました。

1. トナーがなくなったことを知って、アタフタする（1分）
2. クライアントに連絡して、代わりに印刷するように打診する（2分）
3. 資料をPDF化して、クライアントにメールで送る（5分）
4. 近所の量販店に電話し、在庫があるか確認する（3分）
5. 打ち合わせ後、量販店に寄り道し、店頭でトナーを購入する（30分）
6. トナーを入れ替える（1分）

タスクは2つから6つに増え、2分で済むはずの作業に、42分も費やすことになりました。しかも、ハラハラしたり、クライアントに頼み込んだり、時間以外に神経も使いました。しっかりものという弊社のブランドイメージにも、多少傷がついたかもしれません。

後回しばかりしてると仕事ができなくなるカラクリ

でもこれって、象徴的な出来事だな、と思います。

というのも、多くの仕事は、こうやって後回しにすることで、タスクが増えていきます。全体のタスクの関連性を意識せず、刹那的に仕事をしている人は気づきにくいでしょうが、後回しにすると、だいたいはタスクが増えます。

実際、後回し癖のある人には、いつも忙しそうで、仕事に追われてて、時間のイニシアチブを握れていない人が多くないでしょうか？タスクが増えるということは、8時間で達成できる成果が減るということです。必然的に忙しくなりますし、精神的余裕も減っていきます。じっくり考えて仕事できなくなります。質も落ちていきます。

後回し癖というのは、日々の業務以上に、長期的なスキルアップ、キャリアアップにも大きな影を落とします。

キャリアに影響を与えるような大事なタスクというのは、緊急性が低いものが多いです。後回し癖のある人というのは、こういう、重要だけど緊急性が低い仕事を後回しにします。ずっと後回しにし続けます。その状態で、1年、2年と過ごしていきます。すると結局、何も変わらないまま、日々の業務に追われる毎日を過ごしていくだけになります。キャリア的には大きな進歩もなく、時間を浪費してしまいます。

「やんなきゃいけないのはわかってるけど、忙しくて・・・」というのが口癖の人は要注意。この負のサイクルから抜け出すには、どこかで踏ん張って、緊急性は低いが重要性の高いタスクをこなす時期を過ごし、正のサイクルに切り替えなくてはなりません。

後回しにすべき仕事、そうでない仕事

後回し癖が抜けないのは、今の快楽を優先し、苦痛を未来に先送りする現実逃避を望むからでしょうが、それと同時に、どんな後回しも正当化しようと思えばできてしまうのも、理由の一つでしょう。仕事の中には「後回しにした方がいい仕事」も存在するため、後回しを正当化するのは、たいして難しくありません。

今やった方がいいか、後回しにした方がいいの見極めは、時に難しいものではあります。しかし、本当に後回しにすべきタスクというのは、実は結構少ないのではないでしょうか。具体的にいえば、後回しにするメリットがハッキリしてて、その効果が大きい場合だけです。そうではない、「これはもしかして後回にした方がいいかな？」程度のことは、後回しにする価値がないケースがほとんどではないでしょうか。

具体的に言うと、メールの返信、上司への報連相、スケジュールの調整、打ち合わせの打診、クライアントへの連絡、部下への声掛け、成果物の中間レビュー、プロジェクトメンバーへの周知、飲み会の設定、友達への声かけ・・・。

ついタイミングを見計らって、などと思ってしまいますが、ほとんどのことは、後回しにするよりも、先に動いた方がメリットが大きいものばかりです。後回しにした方がいい理由というのは、結局は後回しにしたい気持ちを正当化するためにとってつけたもので、冷静な判断に基づいていないことが多いのではないでしょうか。

まとめ

先に上げた、「プリンターのトナーは後で注文しよう」という私の気持ちを正当化したのは、その時に行っていた仕事の流れを止めない方がいい、という直感的な思い込みだけでした。

しかし、たった2分であれば、それはすぐに取り返せたでしょうし、44分のロスにはならなかったでしょう。結局このときの私も、「ちょっとめんどくさい」という気持ちを優先させて、未来に起こりうるリスクをちゃんと考えなかったために、失敗してしまったわけです。プリンタのトナーだけの問題であればたいしたことはないかもしれませんが、仕事全般でこういう考えをしていて、後回し癖が体に染みついたら、などと思うとぞっとします。

こういった自分自身の反省を含めて、後回し癖のある人は仕事ができない人だ、ということを改めて肝に銘じしておきたいと思います。

説得力のある会話。説得力のある資料。説得力のある論理。説得力さえ身に付ければ、仕事のほとんどはこなせちゃうんじゃないか、ってくらい強力なスキルです。

デザインも同じです。特にクライアントの存在する商業デザインには、「説得力のあるデザイン」が求められるものです。では、説得力のないデザインと、説得力のあるデザインとは、どこが違うのでしょうか？

説得力のないデザインは、だいたい考察が浅かったりします。一方、説得力のあるデザインは、色々なことを深く、広く考察したうえで、最終的なデザインに到達しています。浅い考察、深い考察を、もう少し分かりやすくすると、以下のように表現できるでしょう。

●浅い考察
→ Aという要望があった
→ それに対して、Bと思った
→ だから、Xというデザインにした（結論）

●深い考察
→ Aという要望があった
→ それに対して、Bと思った
→ しかし視点を変えると、Cかもしれない（視点の変化）
→ あるいは条件を変えると、Dかもしれない（条件の変化）
→ もしかすると、Bと思ったのは間違いで、本当はEなのかもしれない（自己否定）
→ しかし、Eに対して、ある人はF、ある人はGと評価するかもしれない（評価のふり幅）
→ Fと評価された場合に備えて、Hを考慮しなければならない（リスクヘッジ）
→ Gと評価される場合は、割り切ってしまい、考えなくてもいいかもしれない（割り切り）
→ そういう諸々を考えると、Yというデザインにするのがベストだと思う（結論）

浅い考察から生み出されたデザインは、あまりいろいろ考えていないので、否定的な評価や意見が出てくると、すぐに結論が揺らぎます。また、事前にあまり考えていないので、ディスカッションをしても良い議論にならず、クライアントの主観的な好みをひたすら聴くだけになってしまいがちです。

深い考察に基づくデザインは、あらかじめいろいろなことが考えられているので、結論に隙が少ないです。想定外のことが少なく、ちょっとした反論にびくともしません。また、事前に色々と考えているので、デザインにブラッシュアップが必要であっても、すぐに建設的な議論を展開することができます。こういう一連の思考を乗り越えたデザインに、人は説得力を感じます。

説得力を持たせられないデザイナーの結論への道程は、どちらかというと前者の「浅い考察」に留まっていることが多いでのではないでしょうか。結論に至るまでの頭の中の思考の体操が、まだまだ足りないのだと思います。

色々な経験を積むことで、深い考察はある程度できるようになります。しかし、流れに身を任せた学習では時間がかかるし、元々深く考える癖がない人は、それだけではあまり成長しないかもしれません。

その場合は、深い考察に至る思考のプロセスを自分なりに考え、チェック項目を作ってはどうでしょうか。一旦思いついたデザインについて、視点や前提条件を変えたり、自己否定を繰り返してから、結論を出すような、思考訓練をしてみるといいのではないでしょうか。

そんな、私たちのBtoBサイトに関する豊富な経験から、今回は、よくあるBtoBサイトの失敗パターンをまとめてみました。多くの項目に当てはまるwebサイトは、是非これを機に、リニューアルを考えてみてください。

1.　新規顧客ではなく既存顧客向けに作る

BtoBビジネスでは、売上げの大半を既存顧客から上げていることも多いです。だからといって、webサイトのターゲットを安易に既存顧客にしてはいけません。特に既存顧客対応は人的営業の役割で、webサイトでできることはあまりない場合、Webサイトは新規顧客の獲得を主目的とすべきです。そこを見誤り、既存顧客のリテラシーに合わせたようなコンテンツでwebサイトを作ると、当然、成果を上げることは難しくなります。

2.　ブランディングを主目的にする

知名度の低いBtoB企業では、ブランドイメージの定着や転換を図る段階にないことも多いです。その場合のwebサイトの主な役割は、集客と理解促進です。一見かっこいいけど、サービスを直接説明しないビジュアルやコピーより、多少泥臭くても、検索にかかりやすく、読んで理解しやすいwebサイトの方が、確実に成果を生みます。知名度のないBtoBサイトでは、ブランディングという観点は一度捨て去ることをおすすめします。

3.　投資対効果を考えないで予算を決める

webサイトは、100万円で作って3年間で300万円利益を出すより、300万円で作って3年間で1000万円利益を出すほうがいい、という発想で作られるべきです。将来を正確に見極めることはできなくとも、成功の可能性を高めることはできます。BtoBサイトは利益計画が立てやすいにも関わらず、その視点もなく、根拠のない予算でwebサイトを作ることも多いです。結果、最初は安くても、長い目で見て損をしてしまいます。

4.　目標が現実的でない

顧客単価が高いB2B商材だと、月間数千の訪問数や1%以下のCV率でも十分に利益をあげることができます。また、対象者が少ないため、訪問数が数万までいかないことも多いです。にも関わらず、C向けのECサイトなどと安易に比較し、非現実的な目標設定をしていることがあります。非現実的な高い目標は、施策の優先順位を見誤ったり、成果を失敗と判断したりするリスクがあります。リニューアルを計画する前に、webサイトの現実的な目標値はどこなのか、というのはあらかじめ理解しておく必要があります。

5.　ビッグワードしか狙わない

SEOが主な流入源なのに、キーワード選定で失敗してるBtoBサイトも非常に多いです。多いのがビッグワードだけを狙ってるケース。ビッグワードは競合が多く、適切なターゲットを見定めにくいため、必ずしも投資対効果が高いとは限りません。例えば「クラウド」でSEOを実施しても、競合が多い上、多種多様なユーザを含むため、成果は上がりにくいでしょう。闇雲にビッグワードを狙うのではなく、バランスのとれたキーワード選定が重要です。

6.　検索ニーズのないキーワードを狙う

逆の失敗パターンです。ニッチなサービスを提供しているBtoB企業は、ニッチなキーワードをメインキーワードにしがちです。しかし、そもそも検索されていないキーワードでSEOを行っても、やはり成果は出ません。例えば「クラウド　人事」というようなキーワードでSEOを施しても、この類のキーワードの検索は限りなくゼロに近いため、集客効果は薄いでしょう。SEOで集客するのなら、顧客が使っているキーワードに合わせるという発想も大切です。

7.　社名やサービス名で、検索上位に表示されない

一般用語を用いた企業名やサービス名だと、検索エンジンでの上位表示が難しくなりますが、これはビジネスをする上で大きなハンディとなります。しかし、その原因を調べると、そもそもSEO向きではない、つまり、適切なマークアップ、内部被リンク対策などが行われていないだけ、ということも多いです。逆にそれを抑えれば、問題が解決することも少なくありません。SEOの理解がない制作会社に丸投げしている企業にありがちな失敗例です。

8.　専門用語を連発する

BtoBの商材は専門性が高く、必然的に専門用語を多用しがちです。しかしそのことで、分かりにくいwebサイトになってることがよくあります。新規顧客は、リテラシーが低く、判断基準が存在しないことも多いです。専門用語で埋め尽くされたWebサイトでは、そういったユーザを排除してしまいます。専門用語を多用して得することはありません。できるだけ平易な言葉で、webサイト内のコピーを作り上げるようにしましょう。

9.　ユーザー目線のコピーになっていない

BtoBサイトではつい説明を難しくしがちですが、例えば「10種のファイル形式で出力可能」ではなく「フォーマットが豊富ですぐ資料化できる」というように、ユーザに何の得があるのか？という視点の文章でなくてはなりません。また、サービス名をメニューに並べてるケースも目立ちますが、サービス名だけではその内容が理解できないため、結果ユーザを逃がしてしまいます。webサイトの隅々に至るまで、ユーザ目線のコピーを徹底する必要があります。

10.　トップページで企業理念を見せる

多くの顧客は企業理念に関心がありません。にも関わらずトップページの特等席に「未来に繋がるイノベーションを」「私たちはコミュニケーションをデザインします」といった曖昧な企業理念を掲げ、風景のような抽象的なビジュアルを設置しているBtoBサイトは少なくありません。顧客がターゲットなら、トップページは「顧客に対して何を提供しているのか？」をきちんと訴求しなければ、せっかく来たユーザに逃げられるでしょう。

11.　強みをきちんと説明しない

BtoBサイトは専門的なテーマを扱うが故に、強みの説明が曖昧になってることが多々あります。BtoBでは顧客が多層構造で、意思決定は時間をかけて合理的に行われるため、論理的で納得感のある説明を行わなければなりません。実績、お客様の声、シェア、設備や体制、第三者評価など、ユーザにとって分かりやすく強みを証明できる情報は色々とあるはずです。これらを、できるだけアクセスしやすい場所に配置することが重要です。

12.　デザインを重視しない

「うちは地味な会社だから」とデザインに消極的な会社も目立ちます。しかしBtoB企業こそ、webサイトのデザインには配慮すべきです。知名度が高い企業やブランドは、webサイトだけで印象が決まることはありませんが、あまり知られていないBtoB企業は、Webサイトのデザインだけで、企業の印象を判断されるからです。デザインを派手にする必要はありませんが、競合や世の中の平均的なwebサイトよりは「きちんとした会社だ」という印象を残せる「中の上」以上のデザインが、BtoBサイトには必要です。

13.　オフラインでの検討プロセスを考慮しない

BtoB商材では、購入までに社内稟議などが必要になることが多いです。このような、ネット外での検討プロセスへの配慮も、BtoBサイトには必要です。例えば、資料ダウンロードは、社内検討を進める担当者を強くサポートするでしょう。印刷にも対応できた方がいいでしょう。Webサイト内の文章は、知識がそれほど豊富ではない上司の存在も意識しなければなりません。このように、オフラインでの検討プロセスも想定した設計やコンテンツが必要なのもBtoBサイトの特徴です。

14. 選定基準を示さない

BtoBの商材は、その場の気分で購入されることはほとんどありません。しかも、多くの顧客は、どれを選んでいいかわからない、という状況です。そのため、BtoBサイトでは、サービスの特徴を語るだけではなく、どういう基準で選べばいいかまでサポートすべきでしょう。選定基準を明確することで、購買の意思決定は前進します。また、役に立つサイトとして、顧客からも評価されるでしょう。顧客に喜ばれることを目指すのであれば、選定基準の掲載はおすすめです。

15. やたらとページを分割する

説明が多岐にわたると、ついページを分割してしまいがちです。しかしページの分割や格納は得策ではありません。一般的なBtoBサイトの1訪問あたりのPVは3～4ページ程度です。つまり、3～4ページ以内で理解してもらわなければならないのです。長すぎても見れもらえなくなりますが、別ページに隠されているよりはマシです。読んでほしい情報はできるだけ1ページにまとめ、なるべく少ない閲覧で理解できるよう構成しましょう。

16.　営業をサポートしない

BtoBビジネスでは、最終的な成約は、人的営業に委ねられることも多いです。もしそうならば、Webサイトは顧客をフィルタリングし、効率よい営業活動に繋げなくてはなりません。メールフォームなら、営業が事前に聴きたい情報も収集できたものがいいでしょう。価格や制約事項をきちんと提示しておけば、無駄な営業活動を減らすこともできるでしょう。BtoBサイトは、顧客視点であると同時に、営業を強力にサポートするツールでなければなりません。

17.　連絡先がすぐに見つからない

「余計な問い合わせに対応したくない」という社内の声から、連絡先が隠されることがあります。しかし、余計な問い合わせを恐れてはいけません。それは、フォームの作り方などである程度フィルタリングできますし、電話なら、断ればいいだけです。お問い合わせが全然来ないと悩んでいる時に「たくさん来たらイヤだ」と回避策に思いを巡らす必要はありません。連絡先をできるだけ露出させることに注力しましょう。

18.　よくある質問がない

専門的なBtoB商材ほど、詳細を説明しきれないことが多いです。しかしだからといって、情報を隠し過ぎては、せっかくの見込み顧客を逃してしまいます。その対策として、顧客視点で必要な情報を再整理している「よくある質問」は非常に重要なコンテンツです。その動線は、サービス紹介のコンテンツ末尾や、お問い合わせ近くに設置することをおすすめします。よくある質問をうまく使うだけで、ユーザの理解度が上がり、お問い合わせ増に繋がります。

19.　FacebookやTwitterを安易に運営している

FacebookやTwitterをやっているBtoB企業も増えてきました。しかし、そのBtoB商材は、ソーシャルでの販促に適したものでしょうか？知名度がない商材だと、Facebookページを見つけてもらうのは難しくなるでしょう。顧客がファン化する商材でなければ、フォローはされません。Twitterも同様です。もし、トレンドという以外の戦略も理由もなくSNSをやってるのなら、まずそれらは全てやめて、別のことに注力することをおすすめします。

20.　内輪受けのブログを運営している

SNS同様、ブログ運営に苦心しているBtoB企業も多いです。何を更新していけばいいか分からず、内輪ネタを延々と更新しているものも目立ちます。採用目的であれば、それでも一定の意味はあるかもしれません。しかし、BtoB企業のブログは、顧客に役立つ情報提供であることが基本です。顧客にどういう情報を提供すると喜ぶだろう、どういうことに困り、それを解決する自分たちのノウハウはないか、という視点でブログを運営するのが正攻法です。

21.　専任の担当者がいない

人的営業中心のBtoB企業にとって、webサイトは「副業」であり、通常業務の合間に運営されてることが多いです。当然、専任の担当者を置いてあることも少ないです。しかし専任の担当者がいなければ、webサイトは更新されなくなり、やがて風化し、結局、利益貢献しなくなります。Webサイトの規模、更新頻度などにもよりますが、webマーケティングを理解する責任者とともに、運用を担当する専任担当者の配置を、リニューアルと合わせて検討することをおすすめします。

22.　安易にスマートフォン向けサイトを作る

BtoB企業でも、スマートフォン対応を検討するケースも増えてきましたが、その商材が、スマートフォン上でどう見られているかは、冷静に分析する必要があります。レスポンシブwebのように、PCとまったく同じ情報を提供するのは適切でなく、専用サイトを立ち上げた方が良い場合もあります。ログを見れば、スマートフォンユーザはどういうコンテンツを見てるかなどの傾向もわかるでしょう。やみくもに作るのではなく、ニーズや商材の特性を踏まえて、判断しましょう。

23.　ビジネスを考えられない制作会社に丸投げしている

BtoB企業の中には、Webへの苦手意識からか、制作会社に丸投げしているケースも多々あります。Web制作会社は、もの作りに特化している反面、ビジネスが考えられるとは限りません。中小のBtoB企業であれば、ビジネスを考えられる会社の選定は生命線とも言えます。方法は色々ありますが、ビジネスプランをきちんと提案させるのも一つの方法です。逆に、ビジネスを考えられるWeb制作会社をきちんと選ぶことができれば、出遅れたwebの取り組みを挽回することもできるでしょう。

24.　webサイトは変えても自分たちは変わらない

自分たちは変わらず、webサイトだけ変えれば成果が得られると考えている企業は案外多いです。BtoBの購買プロセスは、webサイトだけで完結しないからこそ、webサイトだけでなく、仕事のやり方も最適化しなければなりません。集客やお問い合わせの動線を強化しても、窓口が対応できなければ、成果に繋がりません。営業がwebサイトを把握していなければ、掲載されている情報が十分に活かされません。webサイトを変えるのであれば、それに合わせて、仕事の仕方も変えていかなければなりません。

25. ネットを重視していない。

いくら優秀なweb制作会社を選定し、どんなにいい提案を受けても、企業側がインターネットの価値を理解していなければ、成果に結び付けるのは難しいです。インターネットの重要性は分かっていても、日々の業務を優先し、webサイトは後回し、大事なところは制作会社任せではいけません。きちんと成果を上げたいのであれば、まずは企業側もインターネットにきちんと向き合い、webサイトの可能性と限界を知り、自社のビジネスに還元できることは果たしてなんなのか、ということを真剣に考えることが、なによりも大切です。

まとめ

これらの25のあやまちは、全てクリアしていなければいけない訳ではありません。ちゃんと考えがあれば、既存顧客をターゲットにしてもいいし、ブランディングを主目的にしてもいいし、トップページで企業理念を見せてもいいのです。一番大事なのは、「きちんと考える」ということです。そういう意味では、25番目のあやまちに、全ては集約されるのかもしれません。BtoBビジネスは、まだまだネットの可能性を引き出しきれていない業界、企業が多いです。是非、これらのチェックポイントで自社サイトを評価してみてはどうでしょうか。

ログ解析ツールのオペレーションを解説した書籍などは多数存在しますが、ログ解析の難しさとは、必ずしも作業をフォーマット化できないことにあります。なぜなら、業態やWebサイトの特性で、プライオリティや判断基準が変わり、それによって深堀すべきデータ、無視していいデータが大きく変わるからです。つまり、ビジネスの核心に近づく分析をしようとすればするほど、ケースバイケースの判断が重要になってきます。

ここでは、ログ解析歴5年の私が、クライアント向けにログ解析レポートを作る際に、そういったログ解析の難しさに立ち向かうため、主に気を付けている6つの点をまとめてみました。

１：データは必ずセグメントする

ログ解析に不慣れな担当者は、サマリーされた情報だけで成否を判断しがちです。しかし、統合され、平均化されたデータを眺めていても、有益な示唆を得られることはほとんどありません。膨大なデータの中に隠されたヒントを掘り起こすためには、データを細かくセグメントする作業が必要です。ログ解析の大半はこのセグメント作業といっても過言ではありません。

例えば、ログ解析ツールでは、流入に使われている検索キーワードの総合ランキングが表示されますが、ここから具体的な課題や対策に繋がるアイデアが出てくることはほとんどありません。検索キーワードを分析するのであれば、指名ワードか一般ワードかをまずはセグメントし、一般ワードであれば、ニーズの種類に合わせてさらにセグメント化していきます。このセグメント化されたグループごとに見ていくと、直帰率や訪問あたりのPVや閲覧時間、リピート率に違いがあることが分かってきます。このようにセグメントしてはじめて、有望なターゲットや気付かなかった顧客ニーズを、具体的に想像することができるようになります。

これは検索キーワードの例ですが、参照元サイト、ユーザ属性、コンテンツなど、あらゆるデータに対しても同様のセグメントを行います。まとまったデータでは隠されていたWebサイトやビジネスの特性が、セグメント化することで、露わになってきます。

セグメント作業は、もちろん解析ツール上の機能だけで行えることもありますが、私の場合、エクセルなどにデータを移し、クライアントのビジネスやWebサイトの特性などを考慮して、手動で作業を行います。セグメント化は、人間の経験と知恵とセンスが試される領域で、ツールが自動的にソートするデータだけでは不十分なことがほとんどです。しかし、自動化できないからこそ、この作業を入念に行うか、怠るかで、せっかく収集したデータが活かされるか、無駄になるかを大きく左右しているとも言えます。

２：数字の正確さに固執せず、傾向を重視する

数字が見えていると、どうしても情報の正確さにこだわりがちですが、実際、細部の数値の正確さは、それほど重要ではありません。本当に重要なのは、その情報がいかに正確であるかではなく、そのセグメント特有の傾向がきちんと反映されているか、ということです。この傾向はわずかなアクセスで影響を受けるようなものではなく、もっと大きなグループの中で、共通して見える傾向である必要があります。

データそのものは、人間の本当の心理や行動の本質を完全に掴めるものではなく、あくまで推論を促すためのものにすぎません。そこには多種多様なノイズが入ってしかるべきであり、逆にいえば、細かな数字の違いで上下するような小さい情報を眺めていても、有益な示唆が生まれてこないことも多いです。

もちろん、大雑把に、雑に捉えていい訳ではありませんが、例えば、セグメント作業をする際、いかに正確に、いかに正しく、というところにこだわって時間を費やしてしまうのは得策ではありません。時間はいくらでもなくなり、結果、コストに見合わない作業になってきます。丁寧なセグメント作業とは裏腹に、細かい誤差やグレーゾーンはある程度割り切って分析を行うという思い切りの良さも、ログ解析には必要です。

３：事象が普遍的なのか、例外的なのかを見定める

データをセグメント化して、セグメント毎の傾向を見ていくと、思ってもいなかったような示唆を得られることがあります。時には、リニューアル前の仮説をひっくり返すような仮説が見えてくることもあるでしょう。しかし、そういった仮説は、本当にターゲット共通でいえる普遍的なことなのか、あるいはある特殊な状況における例外事例なのかは、理解しておく必要があります。

特に、母数の少ないセグメント内での平均値は、ある特定のユーザの特殊な行動によって大きく数字が変わることがあります。例えば、10訪問程度のセグメントグループで、1訪問あたりのページビューが10ページを超えていても、それはある特殊なユーザが一人で100ページ近く閲覧し、全体の平均値を押し上げているようなこともあります。

そのことを見過ごし、そのセグメントグループを今まで気付かなかった新しいターゲット層であると判断してしまうと、改善の方向性を大きく見誤ってしまいます。各セグメントから見えてくる傾向が、本当に共通していえることなのか、ある条件によって成り立っている特殊な事象なのかは、明確に意識しておかなければなりません。

ちなみに、こういった例外的な行動をするユーザをどう扱うかというのは、データマーケティングの難しい部分です。例えば、クレームをいう顧客というのは少数派で、クレームに合わせて製品やサービスを改変していくと、本当のターゲットを見失ってしまう、ということのはよく言われることです。一方で、イノベーションに繋がるようなユーザの潜在的なニーズは、平均的な数値ではなく、ある特殊な事象からこそ見えてくるものである、ということもよく言われるます。

いずれも事実です。そして、こういった特殊なユーザが、無視してよいユーザなのか、注目すべき潜在ユーザなのかは、残念ながらログの数字を見ているだけでは判断できません。より多角的に分析し、結果的にはリーダーによる独断的な意思決定によってのみ証明されるようなこともあります。

そういった難しさを秘めているという点も踏まえて、セグメント化されたデータの普遍性／特殊性というのは、いつも強く意識しておく必要があるといえます。

４：矯正された数値ではなく、本来の力を評価する

トラフィックを増大させるために、広告を出稿することは非常によくあります。あるいは、展示会などのイベントと連動して、Webサイトへの流入を促すことも頻繁に行われていることでしょう。しかし、こういった「矯正されたトラフィック」と、Webサイトが自然に集めているトラフィックを混在させて分析すると、Webサイトが本来持っているパフォーマンスを見誤ってしまいます。

例えば、ある旅行業界のWebサイトでは「平日よりも週末にWebサイトに訪問する」という仮説に基づき、毎週金曜日の夕方に、集客のためのキャンペーンを打っていました。当然、金曜日の夜から週末にユーザが多く流入することになります。データだけを見ていると、「週末にWebサイトに訪問する」という仮説が正しいように思えてきます。しかしこれは、仮説に基づく流入施策があった上での結果です。実際、このWebサイトで、キャンペーンからのトラフィックを全て排除して分析してみると、実は週末にトラフィックが特別集中している訳ではなく、むしろ平日の昼および夕方以降のトラフィックもかなり存在することが判明しました。このような事実は、矯正されたトラフックを混在させて分析していても、知ることができないことです。

またあるWebサイトは、CV率が0.5%しかなく、それを改善するために、Webサイト内の動線を見直そうという話になっていました。しかし、バナー広告やリスティング広告からの流入を排除してCV率を検証してみると2%以上あり、広告からの流入が極端にCV率を下げていることが判明しました。こういった場合には、当然ながら、Webサイト内の動線改善よりも、広告の出稿の仕方を見直した方がいい、という判断になってきます。

ログ解析は、広告などの効果検証にも絶大な力を発揮します。しかし一方で、トラフィックが自然流入なのか、矯正されたものなのかで、Webサイト自体の評価が大きく変わり、改善の方向性が全く異なってしまうことも少なくありません。

ログを解析する際には、単純にセグメントされた数字を見るのではなく、Webサイト本来のパフォーマンスを見極めるというのも、非常に大事な視点です。

５：ログ解析ツールだけにとらわれない

他社が作成した解析レポートを見る機会がたまにあるのですが、多くの場合、ログ解析ツールから得られることしか書かれていません。有料サービスということで、ある意味仕方のないことかもしれませんが、Webサイトの分析は、解析ツールでできることの中で行わなければならない、というルールはどこにもありません。本質的な目的が、Webサイトのパフォーマンス向上であると考えると、むしろログ解析の内容だけにとらわれていてはいけないともいえます。

例えば、トラフィックの改善を考えているのであれば、解析ツールの中の流入キーワードの情報だけで判断するのではなく、SEO系ツールの被リンク数の増減を確認したり、あるいはGoogle Trendで検索動向をチェックしたりすることで、より意味のある分析にすることもできます。解析ツールでは苦手としている定性的な分析は、Twitterなども併用して収集することもできます。

ログ解析からは、確かに多くのヒントを得ることはできますが、本当に大事なことがそこから見えてくるとは限りませんし、ログ解析だけでは見えないことも数多く存在します。ログ解析はあくまで手段の一つであり、ビジネスに影響を与える本当の改善策を導き出すのがゴールであるからには、ログ解析ツールだけにとらわれず、様々なツールや分析手法を併用して、検討することも重要です。

６：必ず仮説とアクションに結びつける

経験の浅い担当者が陥りやすいのが、ログ解析のデータをまとめただけで終わらせてしまうことです。しかし、データから見える断片的な考察を列挙しただけの解析レポートでは、片手落ちです。

なぜログ解析をするのかというと、Webサイトの課題や問題をアクセスログから導きだし、具体的な改善策を導きだすためです。そこで必要になるのが、データから導き出される仮説です。検索エンジンからの自然流入が増えないのであれば、ボトルネックとなっている箇所をデータから推測し、仮説を立てるのです。そしてその仮説から、具体的に取り組むべき改善策を導き出してはじめて、ログ解析という作業が一旦ゴールになります。

いくら丁寧にログを分析し、セグメントされた情報が綺麗に並んでいても、「で、どうすればいいの？」という質問に答えられないうちは、その解析レポートはまだ価値を生み出していない状態なのです。

ちなみに弊社では、ログ解析レポートの作成は、Webサイトの立上げや設計にかかわったメンバーが必ず行います。これは、背景にあるビジネス戦略、Webサイトの設計意図を理解していなければ、有用性のある仮説や具体的な改善策が導き出しにくいと考えているからです。

また、企画や設計をした本人が、ログ解析を行うことで、自身が考えたことが本当に実現しているのか、あるいは思ったほど成果を上げていないのかを、つぶさに確認し、企画力、設計力の向上に繋げることができるとも思っているからです。別の見方をすれば、リリース後のログ解析をしない企画者、設計者というのは、いくら経験を積んでいっても、ただ単に机上の空論作りを研ぎ澄ませていくだけになりがち、とも感じています。

まとめ

ログ解析という作業で陥りがちなのが、ツールに使われて、自動化できる部分だけで済ましてしまうことと、ログ解析の本当の目的を忘れ、解析そのものを目的にしてしまうことです。そのことを回避するための6つのポイントともいえるものでしたが、いかがでしたでしょうか。ログ解析とは根気を必要とする頭脳労働で、決して簡単な作業ではないかと思いますが、この記事でログ解析を少しでも効率よく、有意義に行うことができるようになれば、幸いです。

キーワードの抽出

配色の決定にあたり、まずは学習塾のパンフレットや広告、既存のWebサイトなどの情報を収集し、ブランドキーワードの抽出を行いました。結果として、以下のようなキーワード群を抽出しました。

安心、安全、堅実、真面目、確実、知的、本物、楽しい、明るい、健全、のびのび、元気な、豊か、丁寧、親切、誠実

ここでは、「塾」や「教育」といった単語ではなく、抽象的な心理イメージを抽出します。また、Webサイトのリニューアルによって印象を変えたい場合には、現在の印象ではなく、今後与えたい印象も考慮して抽出します。ここで網羅的に抽出しすぎると方向性が定まらなくなるので、Webサイトとしての優先度を念頭に置きながらキーワードを選定していきます。

言語イメージスケールへの落とし込み

さて、これらのキーワードをもとに言語イメージスケールに落とし込んだものが以下となります。赤い点線で囲まれた部分がさきほど抽出したブランドキーワードに近いキーワードが属するエリアです。

言語イメージスケールには、対になる配色イメージスケール（©小林重順／日本カラーデザイン研究所）が存在します。言語イメージスケール上でのポジションをもとに、配色イメージスケールで配色を確認しながら、最終的なカラースキームを決定していきます。（配色イメージスケール上での配色サンプルについては、『配色イメージワーク』などの書籍をご覧ください）

競合のポジショニングと前提条件の考慮

本プロジェクトの場合、競合になりうる企業がいくつか存在していました。そこで、それら競合企業のCIやサイトの配色も言語スケジュール上に配置して検討の対象としました（緑の丸で囲まれたA～H）。これは競合との印象の差別化を行うために重要なプロセスとなります。さらに学習塾のCIカラーである濃紺を変えることはできないため、濃紺と調和する配色というのも、配色決定の条件となっています。こうした条件を踏まえて、最終的には以下の4種類の配色を提案しました。

その後、クライアントのブランド担当者と協議し、最終的にはクリア系の配色に決定。この方向性をもとに、実際に入ってくる写真や素材のテイストに合わせて、トーンの調整や色の取捨選択などの調整を行いながら、Webサイトに定着させていきました。

まとめ

色をこのように決定していくと、Webサイトの配色とブランド戦略をうまくマッチングさせることができます。また、完成された配色イメージスケールを用いるため、デザイナーの感覚的なセンスだけに頼ることなく、目的に合った論理的な配色を行うことができるようになります。さらにこのような論理武装を行っていると、クライアント企業内での社内調整やデザインの説明もスムーズに行うことができます。

Webサイトの配色を考える際には、イメージスケールを活用し、感覚的ではなく、論理的に決定してみてはいかがでしょうか。

仕事ができる人の条件、みたいな記事をしばしば見かけますが、私の中では「仕事ができる人＝メールの返事が早い」というイメージがあります。100%そうとは言い切れませんが、仕事ができる人は結構忙しいはずなのにメールの返事が早い、というのはある程度の確率で当たっているように思います。

では、仕事ができる人は、頭の回転が尋常ではなく、意思決定が超高速だったり、あるいはそもそものタイピング速度が通常の3倍だったりと、超人的な能力を持っているということなのでしょうか。

きっと、そうではありません。仕事ができる人というのは、フィジカルにスピードが速いわけではなく、仕事ができる人特有の「思考パターン」を持っているからだと思います。「メールの返事が早い」というのは、その「思考パターン」がみちびく現象の一つにすぎないのでは、というのが私の考えです。特に、重要度の高くないメールの扱い方に、仕事ができる人の行動パターンが顕著に表れるようにも思います。

もう少し具体的に考えてみましょう。

打ち合わせの出席を打診するメールが来ました。内容は、打ち合わせの趣旨、他の出席者と、それに対する出席可否の回答を求めるものです。出席は必須ではないため、重要度はそれほど高くありませんが、人数を確定させる必要があるため、返信は必ずしなければなりません。内容とスケジュールを確認して返信するまで、5分もかからないような作業です。

受け取った人が、このメールをすぐに返信する場合と、すぐに返信しない場合の、メリットとリスクをまとめると、以下のようになります。

ご覧のように、些細なこととはいえ、メリット、デメリットの差は歴然です。

仕事ができる人にすれば「いつやっても同じなら今やった方がいい」というだけのことかもしれません。しかし、意識しているしていないに関わらず、仕事ができる人というのは、こういう合理的な意思決定が自然とできる人であるように思います。

ここで評価されるべきは、すぐにメールを返信するかどうか、という表面的な行動ではありません。些細なことでも合理的な判断をできるかどうか、という点です。逆にいえば、合理的な理由付けができる状況では、仕事ができる人でもメールの返信を後回しにすることはあるでしょう。

一方、いつもメールの返信を後回しにする人、すぐ返せばいいメールをいつまでたっても返さない人、というのはどうでしょうか。そういう人は、合理的な判断よりも、その場の気分を優先する傾向が高いのではないでしょうか。

メールの返信を後回しにする理由には、メールを出した相手ではなく、自己都合のものが多いです。一方のデメリットを見ると、目の前のことにとらわれて長期的な作業効率を考えることができず、メールを出した人に対する配慮の欠如も見受けられます。自己都合で物事を考え、他者の気持ちを汲み取らない人が、仕事ができる人である確率は、当然低くなるでしょう。

繰り返すようですが、すぐにメールを返信しないから、仕事ができない人だというわけではありません。仕事を効率化するために、あえてある時間帯以外メールの返信をしない人もいますし、当たり前ですが、外出が多い職種の人、立場上、打ち合わせや会議が多い人、他の行動をせず集中することを求められている職種の人などでは、メールの返信がいつも遅くなって当然でしょう。

ただ、メールの返事が早い人には合理的な判断ができる人（＝仕事ができる人）が多く、理解できる特段の理由もないのに、メールの返事がいつも遅い人の中には、自分主体で気配りができない人（＝仕事ができない人）が多く含まれやすい、というある程度の傾向はあるように思うのです。