ベイジのウェブ制作ワークフロー2021年版（約100のタスクと解説）

営業、受注、制作、納品、運用と、ウェブ制作の活動は長期に渡り、そのタスクの種類と量は膨大です。だからこそ、基本的なプロセスや使用するドキュメントなどを明確に定義しておかないと、サービスの品質が担当者により大きく変わることになります。

ベイジは社員がまだ5名の頃、各人に委ねた進め方によって以下のようなトラブルが頻発していました。

• ミスが発生しても「次から気をつける」と精神論で終わらせてしまう
• 担当するディレクターやクリエイターによってタスクの抜け漏れが起きる
• 担当者それぞれが属人的な進め方をしてて品質が安定しない
• 役割が不明瞭なグレーゾーンのタスクが放置されてしまう
• 創造的な仕事の時間が、ルーチンや計画にないタスクに奪われてしまう
• 新しい社員が入る度に同じことを教えないといけない

これら問題を解決するため、2014年頃からワークフローを整備するようになりました。ちなみに私が入社したのはこれ以降です。

2017年には社員数10名を超え、同時進行するプロジェクトが増えると、それまでのワークフローでは足りないことが顕在化してきました。そのため、アップデートした「ベイジのワークフロー2018年版」を作りました。

しかしこれもまだ完成形ではありませんでした。社員数が30名に迫る中、さらなるワークフローのブラッシュアップを続けていった生まれたのが、ここで紹介する「ベイジのワークフロー2021年版」です。

このワークフローには私たちの組織特性が色濃く反映されています。一方で、普遍的・汎用的なウェブ制作のノウハウも多く含まれていると思います。このワークフローは同じ業界で働く人たちの役に立つのではと思い、今回も一般公開することにしました。

1.プロジェクト設計

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

1-1. プロジェクトチーム編成

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

1-2. WBS作成

プロジェクト全体の現実的なスケジュールを把握するため、Microsoft Projectで【WBS（Work Breakdown Structure）】を作成します。新規に作ることは少なく、契約前段階で作られた素案を調整して仕上げることが多いです。新規作成する場合も、すべてのワークフローを網羅したテンプレートが社内Wikiで配布されているため、30分～1時間程度で、WBSを作ることができます。ベイジではディレクターが担当します。

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

プロジェクトチームが決まった段階で、新プロジェクトの開始が社内にアナウンスされます。プロジェクト内で共通で使用されるプロジェクトコード、クライアント名、ウェブサイトの概要、予算、納期、スコープ、開発サーバ、セキュリティ関連の設定、プロジェクトメンバー、プロジェクト固有の前提条件など、プロジェクトに関する様々な基本情報を全社員に共有します。ベイジではディレクターが担当します。

1-4. プロジェクト環境の準備

WBSが決まったら管理ツールを準備していきます。ベイジでは、全体の進捗状況の把握に【プロジェクト管理シート】を、細かなタスクの管理に【Backlog】、細かな連絡にはチャットツールの【Typetalk】を使用しています。

プロジェクト管理シートとは、プロジェクトの進捗状況をタスク毎に細分化したシートです。WBSに似ていますが、WBSがクライアント提示用であるのに対し、プロジェクト管理シートは社内管理用で、進捗状況の更新に特化しています。週次で更新され、毎週金曜日のプロジェクトミーティングで共有されます。WBS同様にテンプレートが存在し、30分程度で新規作成可能になっています。ベイジではディレクターが担当します。

1-5. 開発環境の準備

プロジェクト開始が周知されると、担当エンジニアは、サブドメイン申請や開発環境、ファイル共有環境に関する設定などを行います。ファイル共有に関しては、近年はクライアント指定のクラウド環境を利用することも多いです。クライアントからの指定が特になければ、ベイジで契約しているGoogle Workspaceを利用します。

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

社内におけるプロジェクト準備が一通り完了したら【プロジェクト定義書】を作成します。プロジェクト定義書とは、プロジェクトの目的、スコープ、成果物、メンバー、セキュリティ関連情報、コミュニケーションルール、リスクや補足事項などをまとめたドキュメントです。プロジェクト定義書もフォーマットが用意されており、30分ほどで作成可能です。ディレクターが担当します。

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

契約締結後にクライアントと行う最初のミーティングです。プロジェクト定義書を中心に、プロジェクトの前提条件などの説明を行います。説明自体は質疑応答も含めて、15分程度で終了します。当たり前のことを改めて確認することも多いですが、このような事前の認識合わせやリスク共有の有無で、クライアントの心理的ハードルが変わり、その後のプロジェクトの進めやすさに大きな違いが生じるため、私たちはこの工程を重要視しています。プロジェクト定義書の説明が終わった後は、そのまま戦略フェーズのヒアリングを実施します。

2.戦略

ウェブサイトの戦略要件を整理するフェーズです。本来、ウェブサイトに影響するマーケティングの戦略や要件は、ウェブサイトの発注を決める前には決まっているべきです。しかしそんな理想の状態でウェブ制作のプロジェクトが始まることがほとんどないため、クライアントに代わって私たちが必要な戦略要件の整理を行います。

戦略フェーズは、大きくは調査と戦略立案に分かれ、それぞれでさらに詳細なタスクや検討項目が設定されています。独自に作り上げたメソッドやフレームワークを多く用いますが、クライアント固有の事情に合わせることも多く、プロジェクトごとに柔軟に進め方を変えていきます。

戦略フェーズは、戦略要件の整理だけでなく、私たちがクライアントを理解するインプットの場にもなります。約2か月に渡ってじっくりと時間をかけて調査と検討、議論を繰り返すからこそ、マーケティング視点の提案が可能になると考えています。

このフェーズは、ほぼすべてをコンサルタントが担当します。

※マーケティング目的と採用目的で工程が変わりますが、ここではマーケティング目的のウェブサイトであることを前提に解説します。

2-1. 調査

2-1-1. ヒアリング

〇概要ヒアリング
調査は関係者へのヒアリングからスタートします。契約前の話、RFP、IR資料、ウェブサイトなどを元に、Excel/Googleスプレッドシートで作られた【ヒアリングシート】にヒアリング項目をまとめます。これをキックオフミーティングの約2週間前にクライアントに提出し、回答してもらいます。

ヒアリングシートのテンプレートには、経営計画、事業課題、組織課題、市場特性、顧客特性、マーケティング施策、ブランディング、競合、技術環境など、50～100前後の質問が記載されており、クライアントの個別事情を反映してカスタマイズして用います。

〇詳細ヒアリング
ヒアリングシートの回答内容に従い、キックオフミーティングで追加ヒアリングやディスカッションを行います。1回のヒアリングで次工程に進むこともありますが、経営層、マーケティング、インサイドセールス、フィールドセールス、カスタマーサクセス、製品開発、人事など、部署毎に複数回のヒアリングを実施することもあります。またこの詳細ヒアリングの内容を元に、後続タスクの手順を調整します。

2-1-2. ユーザー調査

〇ユーザーテスト（ユーザビリティテスト）
被験者を3～5名アサインし、対象となるウェブサイトを実際に使ってもらい、フィードバックを得ます。発話法を基本とし、行動観察からインサイトを抽出します。特別な設備は用意せず、被験者、司会者、記録者の3名で実施します。かつては対面で行っていましたが、現在はZoomを使ったリモートユーザーテストがほとんどです。実施には以下のサブタスクが発生します。

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

なお、新しいウェブサイトでテスト対象が存在しない、現状のウェブサイトがあまりにも低品質でテストする意味がない、という場合は割愛することもあります。

〇ユーザーインタビュー
ユーザーテストと同じ被験者に対して、併せて1対1のデプスインタビューを行います。実施には以下のようなサブタスクが発生します。

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

〇アンケート
十分な量の定性情報が必要な場合には、インターネットリサーチのサービスを活用することもあります。生活者を対象とするウェブサイトで行いますが、BtoBサイトでは実施されることはほとんどありません。採用サイトでは社員を対象に数十人の小規模なアンケートを実施します。これら一連を実施するために、以下のようなサブタスクが発生します。

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

〇行動観察
フライオンザウィールやシャドーイングといった手法を用い、ターゲットの行動を観察します。一般的には生活者をターゲットとする場合に用いられますが、BtoBにおいても展示会やセミナー、商談に参加し、クライアントとターゲットのやり取りを観察することもあります。ウェブサイトを利用している様子を観察することも行動観察の一つですが、ベイジでは、ユーザーテスト以外の観察型調査手法を行動観察と呼んでいます。

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

2-1-3. アクセス解析

分析対象のウェブサイトが存在する場合には、アクセス解析を実施します。ベイジでは、最初に解析する8の基本項目を決めており、これに準じたGoogleデータポータルのテンプレートを用意しています。

このテンプレートとGoogleアナリティクスを接続して独自のダッシュボードを構築し、レポートをコンパクトに作成します。アクセス解析に多くの時間を割くのは不毛なことが多いため、ポイントを抑えた生産的な解析・観測を心がけています。

アクセス解析の「8つの基本項目」については、こちらに詳しく解説しています。

2-1-4. デスクトップリサーチ

〇キーワード調査
Googleトレンドやキーワードプランナー、Googleサーチコンソール等を使って検索キーワードを調査し、市場のニーズを探ります。Excelで作られた【キーワードリスト】に、キーワードをカテゴリ分けして分類し、検索順位や予想クリック率、予想訪問数、予想CV数などから、自然検索による流入ボリュームの最大値を推測することもあります。

〇ソーシャルメディア調査
Twitterやブログなどを調査し、対象ブランドに対してどのようなUGCが発生しているかを分析します。ポジティブ/ネガティブに分類する以外に、内容を観察した上で、人々が深層心理で考えていることを推測します。SNS上でUGCがほとんど発生しないBtoBではほとんど実施しません。

〇各種レポート調査
官公庁などが公開している調査資料など、インターネットで入手可能なデータから分析します。主に、ヒアリングやユーザーテスト、アクセス解析では見えてこない、マクロ環境の分析や動向の把握に用います。

2-1-5. 競合分析

〇競合ビジネス分析
競合企業の事業特性、マーケティング特性などを分析します。ウェブサイトやIR資料を中心に分析しますが、入手できる情報が少ない場合には、営業担当者などのヒアリングを中心に進めます。競合企業が存在しない、競合を意識せず事業展開している、分析してもあまり意味がない場合には、最小限度の分析に留める、もしくは割愛します。

〇競合コンテンツ分析
インターネット上での情報取得行動で競合化しているウェブサイトについて分析します。特に、タグライン、メッセージ、提供コンテンツ、ブランドイメージ、クリエイティブの方向性・質などを洗い出し、自社ウェブサイトのコンテンツ制作のヒントにします。なお、コンサルタントやデザイナーによるヒューリスティック分析以外に、ユーザーテスト・ユーザーインタビューの中で、第三者から評価を得ることもあります。

〇競合ユーザビリティ分析
インターネット上での情報取得行動を考えた時、競合化していると考えられるウェブサイトについて、主にユーザビリティの観点から分析します。ISO9241-11:1998が定義する有効さ（effectiveness）、効率（efficiency）、満足度（satisfaction）、利用状況（context of use）の観点から30～50ほどのチェック事項をリストアップしてレーダーチャート等にまとめ、コンサルタントが分析・評価します。

2-2. 戦略立案

2-2-1. ワークショップ

関係者が一堂に会して、アイデアや問題解決方法を議論します。テーマは「ターゲット」「強みと訴求方法」「ウェブサイトのコンテンツ」が選ばれることが多いですが、調査を通じて最適なテーマを決めていきます。参加人数は5名～40名まで様々ですが、人数が多い場合、4～5人で1つのチームを構成し、チームごとに議論した後、チーム間でアイデアを回しながらフィードバックするラウンドロビン方式を採用しています。一度のワークショップで議論が収集しない場合、複数回にわたって実施することもあります。

ワークショップの目的は大きく2つあります。1つは有益な問題解決法を導き出すことです。グループで2時間のブレインストーミングをすると、1人では不可能な量のアイデアが出てきます。これこそワークショップ最大の効果といえるでしょう。

もう一つは、関係者間の目線合わせです。日頃会話をすることがない、立場が異なる関係者同士が、同じテーマについて話し合うことで、認識の齟齬に気が付き、認識が共有され、相手の立場を理解しながら同じ目線で物事を考えられるようになります。これによって、プロジェクトが進行した時、バラバラの視点のフィードバックが来て混乱するようなことを防ぎます。

ワークショップの実施には、以下のサブタスクが発生します。

• テーマ選定
• 参加者の選定、会場の手配
• インプット情報の整理
• 進行資料の作成
• ワークショップの実施
• アイデアの取りまとめ

2-2-2. 経営課題の整理

経営課題の整理は、初めに議論するテーマです。中長期経営計画などから現状の経営課題を分類し、ウェブサイトの中で反映すべき要件を整理します。通常、マーケティングの課題と組織の課題に分類します。マーケティング分野については「強み/弱み分析のチェックリスト」（『コトラー＆ケラーのマーケティング・マネジメント』P.69）等を活用しながら、注力すべき課題を整理していきます。

2-2-3. 市場定義

ウェブサイトが扱う商材やブランドの市場戦略や顧客戦略の要件を整理します。STPの中のS(Segmentation)とT(Targeting)を主題とし、標的市場および顧客を明確にしていきます。特にセグメンテーションには決まった基準が存在しないため、組織デモグラフィックや課題タイプ、購買ステータスといった複数の変数を基準にしたセグメンテーションプランをベイジ側から提案し、それらを元にクライアントと議論して決定します。

2-2-4. 顧客特性の整理

定義した市場にいる顧客企業と所属する社員、ウェブサイトの現実的な利用者をより細かく定義していきます。ペルソナにする場合と、実在の企業/や人物をターゲットとして設定する場合、さらには共通の課題だけを整理してあえて具体的な企業像/人物像にしない場合があります。これらは状況によって判断します。またここでカスタマージャーニー/エクスペリエンスジャーニーを作成し、どのステータスでどのような課題が存在し、どのようなコンテンツが有効化を整理します。

2-2-5. 商材特性の整理

商材の特性を改めて整理し、ウェブサイトとしてどのように打ち出していくのが妥当かを議論します。BtoBの場合であれば、プロダクト/サービス、ヴァーティカル（業界特化）/ホリゾンタル（業界不特定）、エンタープライズ/SMB、グローバル/ローカル、単一商材/複数商材、低LTV多売型/高LTVオーダーメイド型、カテゴリリーダー/フォロワー、ニーズ/インサイトなどの様々な視点から、商材特性と訴求ポイントを整理していきます。また、ホールプロダクトを応用したニーズとインサイトの観点から強みを構造化した独自フレームワークやバリュープロポジションキャンバスなどを用いることも多いです。この段階でキャッチコピーやタグラインの原案が作られます。

2-2-6. ブランド特性の整理

クライアント企業側にブランドガイドライン等が明確に存在しない場合、私たちがクライアントに変わってブランド要件を整理します。ブランドの基本的な概念を啓蒙しつつ、社会課題から導き出されるステートメントの作成、それらとミッション/ビジョン/バリューとの接続、導き出されるコーポレートブランドのアウトラインからブレイクダウンしたプロダクト/サービスのブランドコンセプト、それを展開するためのコミュニケーション手法などを整理し、ブランドに一貫したコンセプトを与えます。また、イメージスケールを用いてトーン&マナーのポジションを定義し、ビジュアルコミュニケーションやコンテンツ表現の大方針を明確にします。

2-2-7. コミュニケーション設計

ここまでの検討結果を踏まえ、マーケティング＆セールスファネルを作成し、マーケティング・コミュニケーションの全体像を図式化していきます。ファネルのステージごとの顧客の行動シナリオを具体的に描くことで、必要なマーケティング施策と、それぞれの関係性や役割を定義していきます。

2-2-8. KPI設定

コミュニケーションの全体像を踏まえた上で、独自に持っている【KPI計算シート】を元に、売上目標→LTV/単価→必要な契約数→商談受注率→商談数→商談化率→ウェブサイトのコンバージョン数→必要なトラフィックといった、成果に繋がる数字上のマイルストーンを定義します。

2-2-9. ウェブ戦略の立案

マーケティングコミュニケーションの全体設計ができあがった後に、ウェブ戦略を立案していきます。コーポレートサイト、製品/サービスサイト、オウンドメディア、ランディングページなど、ウェブサイトのタイプ別にその役割を定義し、接続方法を明確にします。また、ウェブサイトのコンテンツ要件を概ね決めていきます。

2-2-10. コンテンツストーリー設計

ウェブサイトの中心はコンテンツであるべきです。ただ、ウェブサイトのコンテンツだけが突出し、マーケティング戦略全体との整合性がなければ、その効果は期待したものにならないでしょう。このような、マーケティングにおけるコンテンツの一貫性を維持するために、私たちはコンテンツストーリーというものを作成します。調査・戦略を踏まえた上で商材を訴求するための基本ストーリーを定めたものです。当然これはウェブサイトのためだけのものではなく、ホワイトペーパーや営業資料にも転用可能なものです。

コンテンツストーリーの設計にあたってはダイレクトマーケティングのセオリーを参考に、問題提起→結論→実証→信頼→安心という流れで基本構造を整理します。ただし、最終的には作るコンテンツによって流れや表現を組み替えて、定着させます。

2-2-11. コンテンツ設計

コンテンツストーリーをベースとしながら、経営課題、顧客特性、商材特性、ブランド特性、コミュニケーション設計、ウェブ戦略のすべてが満たされるよう、ウェブサイトのコンテンツを企画、編成します。この段階で【ハイレベルサイトマップ】と呼ばれる粗い粒度のサイトマップを作成し、後工程となる設計の基礎情報とします。

2-2-12. 改善提案

コンテンツ設計だけでは抽象度が高く、ウェブサイトの完成イメージが想像しにくいため、主要ページ/主要カテゴリをピックアップし、ワイヤーフレームの一歩手前まで落とし込んだ【改善提案書】を作成します。改善提案書の合意をもって、戦略フェーズは終了となります。

なお、この改善提案までがコンサルタントの職務範囲であり、以降の設計からはデザイナーの職務範囲となりますが、引き続きコンサルタントが支援し、戦略の基本方針がウェブサイトに実装されているかを確認していきます。

2-2-13. 戦略ミーティング（3～4回）

戦略フェーズの最終アウトプットは【戦略シート】と【改善提案書】としてまとめられます。ただし、これらの資料の情報量が非常に多いため、一気に提出するのではなく、複数回に分けてディスカッションをしながら段階的に進めていきます。この一連のミーティングを戦略ミーティングと呼びます。通常、以下のような段取りで議論を行っていきます。

第1回：経営課題、市場定義、顧客特性
第2回：商材特性、ブランド特性
第3回：コミュニケーション設計、ウェブ戦略、コンテンツストーリー
第4回：改善提案、設計準備関連（後述）

各回はコンサルタントがミーティングをリードしますが、デザイナーおよびライターも同席して、プロジェクトの概要を理解していきます。

なお、この進め方は現在も改善中であり、またお客様特性を踏まえて大きく変える可能性もあります。ベイジへのご発注を検討中の企業の皆様は、その点ご注意ください。

2-3. 設計準備

2-3-1. WBSの更新

設計以降の作業範囲が見えた段階でWBSを更新します。プロジェクト開始時に作成したWBSを元に、最新のウェブサイト構成案に合わせてタスクを細分化して、現実的な作業スケジュールに調整していきます。ディレクターが担当します。

2-3-2. コスト算出

戦略フェーズで理想像を描いた結果、コストが当初の契約時点と乖離することが生じます。そこで、戦略フェーズ終了時点の仕様に基づき見積書を改めて作成し、予算を超える部分については、追加予算を確保いただくか、元々の予算に収まるように仕様を削るかを検討します。ディレクターが担当します。

2-3-3. リスク管理

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

2-3-4. クライアントフィードバック

ベイジの進め方に対する要望や率直な意見を把握するために、戦略フェーズ終了時点でクライアントからフィードバックを受ける機会を設けています。満足度の5段階評価やベイジへの要望、不安に感じていることがないかなどを確認し、【フィードバックシート】に記載してプロジェクトに共有します。

このクライアントフィードバックは以下のタイミングでも実施し、プロジェクトに対するクライアントの不満や要望を常時キャッチアップできるようにしています。

1. 戦略ミーティング
2. 開発前ミーティング
3. テスト公開ミーティング
4. 運用ミーティング

余談ですが、クライアントの満足度が下がり、プロジェクトが危機的な状況に陥っているとディレクターが判断した際に、そのことを社内に共有する【プロジェクト警報システム】という仕組みがベイジにはあります。

プロジェクトの状態に応じて「注意報」「警報」を発令し、該当プロジェクトではクライアントの満足度が回復できるよう、細心の注意を払って進めていきます。（ちなみにこれまで一度だけ発令されたことがあります）

3. 設計

ウェブサイトの骨組みを決めるのが設計フェーズの主な目的です。設計という言葉は幅広く業務を指しますが、ベイジでは情報設計や画面設計、コンテンツ企画を主に取り扱っていきます。システムの要件定義や基本設計・詳細設計は、開発フェーズの中で行います。

3-1. 情報設計

コンテンツ設計で作成したハイレベルサイトマップを、ページ単位まで詳細化・論理構造化します。このドキュメントをサイトマップと呼んでいる会社も多いですが、ベイジでは【サイトストラクチャ】と呼んでいます。

ExcelもしくはGoogleスプレッドシートで作られたサイトストラクチャには、カテゴリ/ファイル構造、キーワード、ページ内容、実装搭載、CMSのスコープ、ビジュアル/静的モックアップの制作対象かどうかなどを記載します。ワークフロー上は設計フェーズに含めていますが、戦略フェーズの最終成果物として作られることも多いです。厳密にはインフォメーションアーキテクトの職域ですが、ベイジではコンサルタント、ディレクター、デザイナーのいずれかが担当します。

3-2. 画面設計

いわゆる【ワイヤーフレーム】です。画面の構造以外に、ページ内のコンテンツの大枠、具体的にはh2要素の具体的な文言まで定義します。

また、コンテンツ/カテゴリ毎のCTA（コール・トゥ・アクション）も画面設計の中で定義します。事例カテゴリであれば事例集ダウンロード、価格ページであれば価格表ダウンロード、セミナーカテゴリであればエントリーなど、カテゴリやコンテンツによってCTAが変わる場合、【CTA設計書】に整理することもあります。

ベイジではAdobe XDで作られたワイヤーフレームのテンプレートが用意されており、デザイナー以外でも完成度が高いワイヤーフレームがすぐ作れるようになっています。また必要に応じて設計意図や動線を言語化した図表を添付し、ユーザー視点で画面設計の議論ができるようにします。

ワイヤーフレームの制作は、他のウェブ制作会社ではディレクターが担当することも多いですが、ベイジではデザイナーが担当します。

なお、ベイジが使用している「BtoBサイト・ワイヤーフレーム」は、以下からダウンロードできます。

3-3. 設計ミーティング

画面設計で作成したワイヤーフレームを用いて、主要なページの設計意図をクライアントに説明します。各ページに掲載する情報の種類や方向性、優先順位、ページ前後で想定される動線などを一通り説明し、検討項目を議論しながら、認識を共有していきます。基本的にはデザイナーが担当します。

4. 制作

かつてはデザインフェーズ、デザイン制作フェーズなどと呼んでいた時期もありましたが、ライティングや撮影、イラストといったコンテンツ制作や素材制作もこのフェーズに組み込まれていることから、今は制作フェーズと呼んでいます。具体的なアウトプットの制作がメインとなるため、クオリティの追求が厳しくなる一方、戦略との乖離を起こさないためのチェックも頻繁に行われます。

4-1. ビジュアルデザイン

4-1-1. ビジュアルディスカッション

ビジュアルデザインの方向性について、担当デザイナー以外に、コンサルタント、担当外デザイナーも交えて、ワークショップ形式で議論します。

ベイジでは、アートディレクターがクオリティを一元管理するような00年代型の古い組織構造を廃し、自立したデザイナーが並列に存在し、お互いの知見やアイデアを集めて共創できるデザイン組織を目指しています。

そのため、ビジュアルデザインも担当デザイナー1人で考えるのではなく、担当外デザイナーも交えて複数人でディスカッションしてアイデアを出していきます。約2時間のディスカッションで生まれたアイデアが、担当デザイナーに委ねられ、ビジュアルデザインの初回提案の方向性となります。

共創のための仕組みとしては他に「デザインレビュー制度」を用意しています。完成したデザイン（途中段階でも可）をチャットの専用トピックに投稿すると、他のデザイナーからのフィードバックがもらえます。これをヒントに、担当デザイナーはデザインのブラッシュアップを行っていきます。このようにベイジでは、アートディレクターのような職能長がデザインの最終意思決定をするのではなく、各デザイナーが自ら考えて決定するという、自立した状態を維持しながら、お互いが協力しあって一つのプロジェクトを作り上げていく組織設計をしています。

4-1-2. スケッチング

ビジュアルデザインは、感覚的な判断を必要とする領域が多く、明確なイメージがなくベースデザインに着手すると、多くの時間と浪費する可能性があります。そのため事前に類似サイトを模写し、ビジュアルの感覚を掴んでから、ビジュアル制作に着手しています。タイミング的には、ベースデザインの前に行われることもあれば、ビジュアルディスカッションの前に行われることもあります。模写を担当するは当然デザイナーですが、その選定にはコンサルタントやディレクターが関与することもあります。

4-1-3. 基本ビジュアル制作

サイト全体のトーンを決定するビジュアルの制作です。ビジュアル表現は自由度が高すぎるため、最初は方向性を大きく変えたラフ案を2～3案提示した上で議論をし、方向性を絞り込んでから、より詳細な制作に入ります。PCおよびスマートフォンにおけるホーム、カテゴリトップ、詳細画面といった主要画面のビジュアルが確定するとこの工程は終わり、次の工程に移ります。デザイナーが担当します。

4-1-4. ビジュアルミーティング

基本ビジュアルの初案が完成した後に行われる、方向性を議論するためのミーティングです。ワイヤーフレームからビジュアルデザインに起こした時の変更点などを中心に、認識合わせと議論を行います。

4-1-5. ビジュアル展開

基本ビジュアルでトーン＆マナーについて合意が得られたら、必要なページのビジュアルデザインに進みます。多くの場合は、複数回に分けて制作を進行し、都度クライアントと合意を取っていきます。なお、全ページをビジュアルで再現することはせず、必要最小限のテンプレートだけを制作し、残りはHTML上で展開します。

4-1-6. ユーザーテスト

主要ページのビジュアルデザインが出揃った段階で、ユーザーテストを実施することがあります。Adobe XDのプロトタイプを用いることもあれば、HTML化して実施することもあります。戦略フェーズでユーザーテストを行っている場合は、同じ被験者でテストを実施し、問題が解決されているかを確認します。ユーザーテストの結果を複数回反映する機会を設けることで、ユーザーファーストなデザインを実現していきます。なお、予算や納期などの場合で、このユーザーテストが実施されないこともあります。

4-1-7. パーツ制作

図版、雑多なUIパーツ、エラーモジュールなどの制作です。細かく網羅的な作業が多くなるため、ページのテンプレートと切り分けて進行管理します。特に図版は制作負荷が高いため、デザイン展開やHTML化と並行し、時に別のデザイナーを立てて対応することもあります。

4-2. コンテンツ制作

4-2-1. コンテンツミーティング

コンテンツ制作に入る前に、戦略フェーズや設計フェーズで決定した内容を踏まえ、コンテンツの完成イメージ、ライティングのスコープ、元原稿の精度、進行上のリスクなどの認識合わせをするためのミーティングを実施します。コピー制作では表記ルールを定義する必要があるため、クライアント企業や業界において注意すべき表記ルールがないかもこの段階で確認します。

繰り返しになりますが、ウェブサイトにおいて最も重要な要素はコンテンツです。そしてもっとも進行が難航しやすいのもコンテンツ制作です。ベイジのライターが執筆する場合も、元情報はクライアントからの提供になりますが、それが十分に揃えられないことがスケジュール遅延の大きな要因になります。

クライアントがライティングを担当する場合には、公開できる品質レベルに到達せず、やり取りが発生することもあります。

コンテンツ制作についてはこのようなスケジュール上のリスクが多く存在するため、小まめにミーティングを実施し、クライアントをできるだけサポートするようにしています。ミーティングはディレクターおよびライターが担当します。

4-2-2. コピーライティング

ワイヤーフレームで、h2～h3レベルまでの見出しの原案までをベイジが考案し、それに合わせてコピーの元情報の収集が始まります。コンテンツの企画はクライアントに委ねず、マーケティングやコンテンツに精通したベイジが主導するようなプロセスを取っています。ビジュアルデザインと並んで属人性が高い工程ですが、以下のようにプロセスをある程度形式化しています。

〇計画
ウェブサイトに掲載するコンテンツは、戦略フェーズにおける経営課題・市場定義・顧客特性・商材特性・ブランド特性といった多角的な検討の中から、徐々に浮き彫りになり、ワイヤーフレームに収まった段階で、どの場所にどのような原稿がどのくらいの分量で必要になるかが見えてきます。

この段階まで来たら、【原稿管理シート】と呼ばれるExcelもしくはGoogleスプレッドシートで作られた管理用ドキュメントを作成します。クライアント側のコンテンツ担当者は、このシートに合わせて収集を進めていきます。原稿管理シートもテンプレート化されており、ディレクターやライターがすぐシートを作成できるようになっています。

〇表記ルールの設定
「お客様」と「お客さま」、「サーバー」と「サーバ」など、企業によっては表記ルールが定められていることがあります。そこで、ベイジ側で【表記統一ガイドライン】を作り、サイト内、プロジェクト内での表記ルールをあらかじめ定義しておきます。これもテンプレートがあり、案件固有の条件だけを更新していきます。クライアントからの指定がない場合には、ベイジ標準の表記ルールに従ってライティングを進めます。ルールの設定はライターが担当します。

〇ライティング
コピーを誰が作るかについては、契約条件によって、以下の4パターンに分かれます。

1. 最初から最後までベイジで作り切る
2. 最初から最後までクライアントで作り切る
3. クライアントが作ったものをベイジでリライトする
4. 外部のパートナーに依頼する

多いのは、1と3です。あについては「最初から最後まで」といいながらも、情報源を文字情報で提供される場合と、取材をして引き出す場合があり、それによって時間・費用が変わります。

2については、予算の関係で当初選択される場合もありますが、クライアント側にコンテンツ制作チームが存在しない限り、クオリティの問題でうまく行くことが少ないです。そのためクライアントが2を希望しても、3を推奨することが多いです。

4についても少数ですが、一部の案件で行われています。

ベイジには専門のライターが3名おり、編集経験があるディレクターも1名存在しています。コピーに関する知見をまとめたマニュアルもいくつか存在します。クライアントがコピー制作を担当する場合には、コンテンツ制作に関する勉強会を開催することもあります。このように、という考えに従い、属人性が高いライティング業務においても、安定したクオリティができる限り担保できるワークフローの整備に力を入れています。

〇クライアント確認
コピーが一通り完成したら、クライアントに確認します。文法的に破綻がないかどうかだけではなく、きちんとコンバージョンや顧客化に繋がる文章になっているかという観点から、確認を依頼します。

〇HTML反映
クライアント確認が終わりコピーが完成したら、CMSに登録してウェブサイトに反映していきます。コピー内容によっては、デザイナーが新しい図版やレイアウトを制作し、その後にウェブサイトに反映していくこともあります。

4-2-3. 撮影

商材やウェブサイトの目的を考えた時に、撮影の必要がある場合には、撮影のサブプロジェクトを立ち上げます。特に社員や職場を紹介する必要がある採用サイトでは、撮影はほぼ必須です。撮影は外部のフォトグラファーと契約して実施しますが、工程管理、現場でのディレクション、クオリティチェックなどはベイジで行います。デザイナーが中心となって進めますが、撮影当日などの人手が必要な場合は、ディレクターらがサポートに入ります。撮影のワークフローには以下のタスクが設定されています。

〇撮影前

• クライアントへのヒアリング
• カット数の確認
• 撮影スタッフのアサイン
• 全体スケジュールの作成
• 撮影計画（香盤表）の作成
• 撮影計画の共有
• ロケハン
• 撮影資料の最終準備
• 各種手配・リマインド

〇撮影当日

• 撮影準備
• 撮影中
• 撤収

〇撮影後

• 写真選定
• レタッチ
• 写真加工
• 公開連絡と事後処理

ベイジの撮影プロセスの詳細については、こちらの記事もご覧ください。

4-2-4. イラスト制作

素材としてイラストが必要な場合は、イラスト制作のサブプロジェクトを立ち上げることがあります。イラストは感覚的な領域が多く、作りこんでしまった後の修正が容易ではないため、以下のように段階的なプロセスで進行します。

〇方向性の確認

• 基本的方向性の決定（基本デザイン制作）
• イラスト作成点数の洗い出し
• モチーフや仕様をまとめた【モチーフリスト】の作成
• イラストレーターの選定
• イラスト制作費用の確認

〇イラスト制作

• ラフスケッチ制作
• 線画制作
• 彩色
• パターン展開

〇HTMLへの反映

• 画像化（SVG/PNG/JPEG）
• HTML反映

なお、イラストは外部のイラストレーターに依頼するケースと、ベイジのデザイナーが担当するケースがあります。最近はイラストが描けるデザイナーが増えていて、社内で制作する機会も増えています。

5. 開発

フロントエンドからサーバサイドまで、いわゆる開発全般を行うフェーズです。一般的にはコーダー、フロントエンドエンジニア、サーバサイドエンジニアなどと職能が分かれますが、ベイジではすべてエンジニアと総称し、開発工程を完遂するためのワークフローと能力開発を行っています。

近年は複数人での共同開発が増えてきていますが、元々は1つのプロジェクトに1人のエンジニアがアサインされることが多かったです。ベイジはシステム開発会社ではないため、大規模開発においてはフロントエンドまでを担当し、サーバサイドは外部のパートナー企業と協業します。

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

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

5-2. 開発調査

公開環境の調査あるいは技術要件の検証などを行います。特に既存のCMSを流用した改善プロジェクトを行う場合などは、技術的な制約などが把握していないと、スケジュールの遅延や予期せぬ不具合の多発などに繋がるため、数日かけて入念に調査を行います。その上でリスクが考えられる場合、【開発リスクシート】にまとめて、開発前ミーティングでクライアントに共有します。

5-3. CMSヒアリング

既存サイトのリニューアルの場合、現状の運用方法や課題を感じている点などについて、運用担当者にヒアリングする場を設けています。CMSの運用は担当者のリテラシーにも依存するため、カスタムフィールドの作成やプラグインの導入等も、こちらの判断で決定しまうと運用しにくいCMSになってしまいます。実情をヒアリングした上でシステム要件定義を作成します。ディレクターとエンジニアが担当します。

5-4. システム要件定義

CMSの導入やフォームの開発等にあたり、システムの要件を整理するための【要件定義書】を作成します。リニューアル後のサイトイメージを共有すると同時に、各画面ごとの機能要件やCMS要件、外部サービスとの連携、既存データの移行方法、セキュリティ対策等について詳細に記載します。エンジニアが担当します。

5-5. コーディングガイドラインの作成

プロジェクトの要件に合わせて、HTML、CSS、JavaScriptの記述方法、利用ライブラリなどをガイドライン化します。クライアント側からの要望があれば反映しますが、特に指定がない場合、ベイジで保有している標準ガイドラインをそのまま用います。エンジニアが担当します。

5-6. 開発前ミーティング（要件定義の確認）

作成した要件定義書をベースにして、クライアントとの認識合わせを行うミーティングを実施します。CMSをカスタマイズする際には、クライアントのリテラシーやサイトの更新範囲も踏まえて構築する必要があるため、前提に認識違いがないか等を入念に確認します。主にディレクターとエンジニアが担当します。なお、開発前ミーティングと合わせて、ここまでのベイジの進め方についての要望や不明点を洗い出すためのクライアントフィードバックを実施します。

5-7. 開発環境の整備

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

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

代表的な数画面をピックアップし、コーディングガイドラインに従ってベースのコーディングを進めます。レスポンシブウェブ対応などもこの段階で行い、ウェブサイト全体におけるソースコードの基本構造をこの段階で決定していきます。ソースコードをゼロから書くことは少なく、過去案件のソースコードを積極的に再利用したり、独自作成した共通ライブラリを用意するなどして、実装の効率化、品質の向上を目指しています。より多くの案件で同じソースコードが活用できるよう、さらなるテンプレート化を進めています。ベースコーディングは、エンジニアが担当します。

5-9. コーディング展開

ベースコーディングが確定したら、他ページに展開していきます。分量によっては複数人で分担することもありますが、ガイドラインやチェックシートが存在するため、途中からのプロジェクト参加も容易にしています。経験が浅い実装者が参加する場合もありますが、ガイドラインやチェックシートを使い、さらに経験あるエンジニアがソースコードをレビューすることで、クオリティを担保しています。

5-10. 開発状況共有ミーティング

コーディングがある程度進んだ段階で、開発の進捗状況を共有するためのミーティングを定期的に実施します。途中段階になるため、レイアウトが崩れていたり、CMSも一部の機能しか開発していなかったりしますが、要件定義で確認はしていたものの、認識が異なる点がないか等の懸念事項を早めにキャッチするための取り組みです。

5-11. デザインチェック

ベイジではコーディングの進捗は毎日報告され、プロジェクトの全メンバーが常時確認できるようになっています。コンサルタントは計画していた戦略やコンセプトが反映され、デザイナーはデザインが意図したとおりに実装されているかをその都度確認し、必要であれば随時フィードバックできるようになっています。「ビジュアルデザインやドキュメント通りにHTML化されていればよい」と安易に判断せず、ブラウザで表示された時に最適なUXが提供できるという観点から、ブラッシュアップをしていきます。

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

HTMLに対してマイクロアニメーションを実装します。デザイナーとエンジニアで議論しながらソースコードを改修し、約1～2日かけて調整します。モーションデザインはこの一度の工程だけで完全に終わることは少なく、後述するデザインチェック、テスト公開段階など、複数回に渡ってブラッシュアップを行っていきます。公開の直前まで、ユーザーの利用体験を向上させる適切なアニメーションを追求していきます。

5-13. フォーム開発

お問い合わせ、資料ダウンロード、セミナー申し込みなどに使われるフォームを開発します。かつてはスクラッチのメールフォームを開発することが多かったですが、近年はMA（マーケティング・オートメーション）等の浸透で、APIで提供されたフォームシステムの見た目だけをデザインすることが多いです。ウェブサイト本体からの動線を踏まえたレイアウト、エラーを最小化するインラインバリデーション、送受信されるメールのメッセージなど、EFO（エントリーフォーム最適化）およびユーザー体験の観点から、使いやすくストレスの少ないフォームの提供を目指します。

5-14. CMS開発

ベイジでは案件特性に合わせてCMSの提案を行っていますが、最終的にはWordPressが選択されるケースが多いです。WordPressの実績・ノウハウは非常に豊富で、プラグイン等を活用し、商用CMSに近い状態までカスタマイズして納品しています。また、WordPressで議論になりやすいセキュリティについても対策も行い、CMSとしては十分なセキュリティレベルを担保していきます。また、既存CMSとのデータ移行が発生する場合は、その調査・計画をあらかじめ実施するとともに、移行時のリスクを洗い出し、クライアントに共有します。なお、WordPress以外には、Movable Typeやその他CMSの実績も複数存在します。未知のCMSを扱うこと自体に慣れていることから、経験あるWordPressやMovable Typeに拘らず最適なソリューションを提案し、開発します。CMS開発については、以下のようなサブタスクが発生します。

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

WordPressのセキュリティ対策については、こちらの記事もご覧ください。

5-15. アクセス解析関連設定

Googleアナリティクス、Googleサーチコンソール、Googleタグマネージャーなどの各種設定とHTMLへの埋め込みを行います。戦略フェーズで定義されたKPIを参照しながら【アクセス解析設定シート】を作成し、このシートに基づいて、Googleアナリティクスのビューやコンバージョン設定、サーチコンソールとの連携、サーチコンソール上で表示されるエラーチェック、サイトマップXMLの登録などを行っていきます。また、ベイジがフォーマットを独自作成したデータポータルのテンプレートと連携し、主要な数値の推移に関しては、Googleアナリティクスにアクセスしなくてもすぐ確認できるようにします。最終的にはGoogleアナリティクス以外のタグも含めて、Googleタグマネージャーで統合管理し、Googleタグマネージャーのタグのみが実際に埋め込まれます。スクロール量計測などのカスタマイズも、基本的にはGoogleタグマネージャー側で設定します。これら一連の業務をベイジではコンサルタントが企画し、設定はエンジニアが担当します。また、以下のようなサブタスクが存在します。

• アクセス解析設定シート作成
• Googleアナリティクスのアカウント開設（存在しない場合）
• Googleアナリティクスのユーザー、ビュー、コンバージョンの設定
• Googleアナリティクスとデータポータルの連携と調整
• Googleサーチコンソールのアカウント開設（存在しない場合）
• GoogleアナリティクスとGoogleサーチコンソールの連携
• Googleタグマネージャーのアカウント開設
• Googleタグマネージャー上での各種設定
• HTMLソースコードへのタグ埋め込み
• 設定状況の確認

5-16. MA/SFA等の設定

MA（マーケティングオートメーション）やSFA（セールスフォースオートメーション/営業管理システム/CRM等）を導入している場合、ベイジにてウェブサイトに関係領域の設定をサポートします。スコアリング条件に応じたポップアップメニューの表示設定やフォームのカスタマイズなども提案し、設定作業を代行する場合もあります。またこれ以外に、各種計測タグ、広告関連タグなどの設定も状況に応じて代行します。コンサルタントやディレクターが計画し、実装はエンジニアが行います。

6. テスト

開発完了から公開まではテスト期間になります。通常は10～15日程度となりますが、1カ月近くをテストに費やすこともあります。内容の最終チェック、最終要望の抽出と反映、細かな不具合の改修、公開時点のステータス、公開後対応の切り分け、といった認識合わせを細かく行っていきます。公開までわずかですが、テストでの認識のズレが信頼関係に大きく影響を与えることがあるため、非常に重要なフェーズと位置付け、多くのタスクをワークフロー化して整備しています。

6-1. テスト公開ミーティング

公開までのプロセス、積み残し課題、クライアント側の残務や課題、クライアントへの要求事項、公開までに発生するリスク、スケジュール変更の可能性と判断基準など、テスト公開から公開までにやるべきことや注意事項のすべてを洗い出し、クライアントやプロジェクトチームに共有します。

この段階まで来ると、クライアント社内の意思決定者への報告・確認が行われることも多いため、現在の状況や今後の進め方をクライアント担当者としっかりと共有し、クライアント側で混乱が起きないように配慮します。

なおベイジでは、要望対応をすべて吸収してからブラウザチェックやバグフィックスを行うワークフローを採用しているため、最終確認時に検出されるエラーに対する心理的ハードルを事前に下げることも行います。その他、緊張感が高まる公開直前において、各メンバーの疑問点や不安を解消し、プロジェクトが混乱しないように配慮します。

ディレクターが主導し、クライアントも含めてプロジェクトに関わる全メンバーが参加します。なお、ここまでのベイジの進め方についての要望や不明点を洗い出すためのクライアントフィードバックも併せて実施します。

6-2. テスト公開

テスト公開ミーティングの翌営業日に、テスト版のウェブサイトを公開します。テスト版の各種設定はエンジニアが行いますが、クライアントとのコミュニケーションはディレクターが担当します。

6-3. クライアント最終確認

テスト公開の翌日から、クライアント側関連部署による最終確認を実施します。テスト公開ミーティングで共有されたチェック項目を中心に確認をし、その中で検出された不具合や要望は、ベイジがExcelもしくはGoogleスプレッドシートで提供する【要望リスト】にまとめていきます。確認期間はプロジェクトの規模によりますが、通常3～5日ほどとなります。クライアントの確認体制によっては、10日以上かかることもあります。

6-4. 第三者チェック

クライアント最終確認と並行して、戦略フェーズで定義したマーケティング要件を満たしているか、ウェブサイトやデザインがベイジで考える品質基準を満たしているかの最終チェックを実施します。

クライアントはウェブサイトの専門家ではなく、長いプロジェクトの中でプロジェクト関係者は客観的視点を失っている可能性があります。そこでここでは、あえてクライアントの要望やこれまでの経緯を汲み取らず、プロジェクトに関わっていないコンサルタントやデザイナーが、専門家の客観的な視点からウェブサイトのテスト版を評価し、「本来こうあるべきでは」というフィードバックを行います。

フィードバックは必ず反映するわけではなく、実施可否・実施時期といった観点から最終判断を行い、必要項目のみ反映します。

6-5. フィードバック対応

フィードバックリストにまとめられたクライアント最終確認や第三者チェックのフィードバックを確認し、対応方針を定めます。公開直前のフィードバック対応はプロジェクトの中でも特に混乱しやすいポイントですが、ベイジでは以下のようなプロセスで切り分けを行い、公開までの現実的な対応を決定していきます。

• スコープ内かスコープ外かを確認する
• スコープ外の場合、追加コストと、対応を公開前するか公開後にするか協議する
• スコープ内の項目は、公開までに対応必須か、公開後でもいいかを振り分ける
• 公開前に対応する項目は、必要な時間を積算する
• 公開に間に合わない場合、公開後に回せないか協議する
• 公開後に回せない場合、公開日の延期を検討する
• これらの仕分けが終わったら、ウェブサイトへの反映作業を開始する

フィードバック対応は、クライアントの意思決定者による強い要望などによって、プロジェクトが混乱しやすいポイントとなります。

この段階で時間的制約を踏まえた現実的な落としどころの交渉を行うためには、クライアントとの信頼関係、リスクなどの情報共有、心理ハードルのコントロールといったことが不可欠です。つまり、ここに至るまでのクライアントとの関係性が試されるのがフィードバック対応だと考えます。

6-6. コンテンツ最終チェック

フィードバック対応を実施し、対応内容のクライアント確認まで完了したら、コピーの最終チェックを行います。誤字脱字、表記の不統一チェックのほか、不自然な行送りの改善などを行います。クライアント確認が終わっている状態であるため、意味を変えるような変更は行わず、軽微な改修に留めたコピーの最終確認と調整を行いきます。通常この工程はブラウザチェックと同時に行われます。

6-7. 素材最終反映

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

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

クライアント最終確認が終わり、要望の反映がすべて完了した後、公開直前に網羅的なブラウザチェックを実施します。標準的な対象ブラウザは、PCはWindowsのEdge、ChromeとMacintoshのSafari、スマートフォンはiOS最新版のSafari、Android最新版とし、後は案件特性に合わせて追加・削除を行います。

ブラウザチェックはディレクターもしくはエンジニアが作る【テストシート】を用いて実施します。公開直前までサイトの品質を少しでも高めていきますが、多様なブラウザでの完璧な表示に固執するのは時間・コストの面で非現実的なため、ある程度の表示差異、挙動の違いは許容し、重篤な不具合があれば公開後に対応します。

7. 公開と運用

最終確認と調整を行いサイトを公開します。公開と合わせて運用準備も始めます。ウェブサイト制作のプロジェクトとしては一旦完了しますが、効果の検証、保守や改善など、引き続きクライアントを支援します。

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

公開前後にリダイレクト設定を行います。事前に【リダイレクト設計書】を作成し、テスト公開ミーティングでクライアントと共有します。その合意内容に基づき、公開直前にリダイレクト設定を施します。エンジニアが担当します。

7-2.リリース計画

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

7-3. 公開判定と公開

すべての準備が整い公開可能になった段階で、クライアントに最終の公開判定を依頼します。公開判定が曖昧な状態で公開してしまうとトラブルに繋がることがあるため、必ず電話・メール・チャット等でディレクターが直接確認をし、正式に公開の承諾が取れてから、公開作業を実施します。

7-4. 公開後テスト

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

7-5. 公開後フォローメール

公開テストが一通り完了した後は、無事公開されたことをクライアントに報告します。公開時点で残タスクがある場合には、タスクの内容と対応予定時期を明確にします。運用ルールやマニュアル作成など、今後予定しているステップについても連絡を行います。主にディレクターが担当します。

7-6. マニュアル作成

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

7-7. 運用ミーティング

公開後1週間前後を目途に、マニュアルをベースにして1～2時間のオリエンテーションを実施し、基本的なオペレーションを解説します。また、運用方法における懸念事項がないかをヒアリングした上で対策を検討します。ベイジでは、オリエンテーション後もメールや電話での質疑応答は可能です。自社でサイト運営ができるまでクライアントをサポートします。主にディレクターとエンジニアが担当します。なお、運用ミーティングと合わせて、ここまでのベイジの進め方についての要望や不明点を洗い出すためのクライアントフィードバックを実施します。

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

公開後1～2週間以内に、社内のプロジェクトメンバーを集めてクロージングミーティングを実施します。プロジェクトメンバーがプロジェクトを振り返り、感じた課題や問題点が【クロージングミーティングシート】にまとめられます。このシートを元に話し合いを行い、解決するための具体的なアイデアを導き出します。アイデアには明確な期限やタスクを設定し、ワークフローやドキュメントに反映していきます。このように、プロジェクトの中で失敗や課題を見つけるたびに、自律的に仕組み、組織、人が成長していくというのが、ワークフロー化することの最大の価値であり、それを実現しているのが、このクロージングミーティングです。

7-9. 検証ミーティング

公開後1～2ヵ月を目途に、リニューアル前後のアクセス解析上の変化を確認し、クライアントに報告を行います。主要画面における直帰率やコンバージョン率、流入チャネルの変化など、戦略段階で指標と決めた項目に対して考察し、今後の課題や改善アイデアを提案します。コンサルタントが担当します。

さいごに

このように今回、2021年版として大幅にアップデートしたものの、現在のワークフローでもまだ完成形とは思っていません。今後も継続的にアップデートを行っていきつつ、変更点がある程度まとまった段階で、また皆様に情報共有させていただきます。