ベイジのweb制作ワークフロー2018（140のタスクと解説）
ベイジで社内のワークフローを整理しだしたのは確か2014年頃です。その頃はまだ4～5人しか社員がいない状態で、タスクの粒度も粗く、いくつかのタスクは各人の能力に委ねたものでした。しかし10人を超えて関わる人が増えたあたりから、仕事の進め方も徐々に変わり、ワークフローの綻びも色々と出始めてきました。そこで今年の春に、全社員参加のもと、これまでの進め方の問題点を話し合ったうえで、ワークフローの大幅な刷新を行いました。本エントリーはそのご紹介です。
刷新にあたって、受注から納品までをサブタスクを含めて約140に分解しました。また、各タスクで用いられるドキュメントもできるだけフォーマット化し、効率よくドキュメントワークができるようにしました。
合わせて、タスク毎の職能の再定義を行いました。プロデューサー、ディレクターといった業務範囲が曖昧な職能は、より厳密な職能の定義を試みました。例えばディレクターは、web制作業界では何でも屋のようになりがちですが、タスクごとの職能を明確に定めることで、各人の希望に合わせた経験を積み、各人が望むスキルセットの構築を可能にしたかったためです。このように、サービス向上だけでなく、スタッフのスキルアップやキャリアプランも考慮した刷新となっています。
このワークフローには、私たちの組織特性が強く反映されています。しかしこれは決して画期的なものではないとも思っています。多くは、web制作に共通する当たり前のタスクを当たり前に積み上げただけのものです。そしてこれを公開することは、web制作に従事する人や会社のマネジメント上の悩みを少しでも解消できるのでは思いました。また発注企業や代理店など、制作会社と付き合う企業にとっても有益な情報になるではないかと思いました。項目は以下の通りです。
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制作に関わる多くの方々の働き方をより良くする何かのキッカケになれば幸いです。