こんにちは！みむらです。
新卒で入社してWebディレクターという肩書をいただいてから、
気づけば丸３年が経ち、今は「4年目の人」になってしまいました（苦笑）

ディレクターは「これをやればOK！」みたいな教科書が無い
仕事のように感じていますが…
そろそろ自分の学んだことを整理していきたい思い、
せっかくならとnoteの記事として作ることにしました。

今回はWebサイト制作でディレクターがやらないといけないことを、
自分の「あ、これやるの忘れてた！」防止も兼ねて作ってみたいと思います！

今回の設定

受注前

この時期に必要なのは見積もりに必要な情報整理だと思います。

• リニューアルの要件確認

• ドメイン、サーバー要件の確認

• サイト構成の整理

• ブラウザ保守範囲

• スケジュールの作成

+α　進行管理ツールについて確認

「リニューアルの要件確認」では、現行サイトの課題や
CMSの条件、デザイン要件を伺います。
デザインでアニメーションやイラスト制作も行う場合は
工数が変わってくるので注意が必要です。

「サーバー要件」も、特にリニューアルの場合は重要です。
現行サイトと同じドメインを使う場合、
切り替え作業で気を付けないといけないポイントがたくさんあるので、
それについてもいつか記事にしたいです。

また、社内リソースを抑えるためにも、スケジュールの作成が必要です。
クライアントのリリース希望時期と、
弊社側が安定して作業を進められる日数の確保、
を両立できるよう、頭を悩ませる作業です。

要件定義

無事受注したら、要件定義が始まります。
弊社で作成したワイヤーフレームをもとに、
各ページの掲載要素や、テキストを決めていきます。

あわせて、受注前の「リリース要件」からさらに具体的な
要件の確認もしていきます。

• サイトマップの作成

• meta title、meta descriptionの作成

• デザインイメージ確認

• 写真等素材の受領（いただける場合）

• 保守範囲確認

• GA4他、計測用タグ確認

• 既存サイトから新サイトへ引き継ぐデータがある場合、データの取捨選択

• 納品形式

ワイヤーフレームをディレクターが作る場合、
この期間が一番バタバタと忙しい気がします。

クライアントと定期的にMTGをして要件を決めていくので、
MTGの資料作成や議事録のアップなど、細々とした作業もディレクターの仕事です。

既存サイトから新サイトへ引き継ぐデータがある場合、データの取捨選択

例えば、既存サイトに「ニュース」などの記事コンテンツがあり、
既存サイトから新サイトへデータを引き継ぐ場合、
何年前のものまで引き継ぐのかや、
当時のレイアウトをどこまで再現するかなど、
このタイミングで確認しておくと、後がスムーズです。

デザイン制作

ワイヤーフレームが完成したら、デザイン作成に移ります。
今回はデザインの作成自体はデザイナーの方が担当する設定なので、
ディレクターはデザインの確認作業が中心になります。

要件定義で決めた内容に沿っているか、
サイトを訪れるユーザーが使いやすいデザインになっているか、
テキストの表記ゆれはないか…などに注意します。

コーディングで実装可能なデザインかどうかも注意ポイントです。
デザインが確定した後に実装できないことが判明すると
再度修正しないといけないし、クライアントもがっかりしてしまいます。

OGP画像の作成も忘れないよう注意。

コーディング、CMS構築

今回、作業自体はフロントエンジニアの方が行う設定なので、
ディレクターは進捗確認がメインになります。

またフロントエンジニアの方から要件やデザインについて
質問があった場合は適宜回答、確認していきます。

GA4などの計測タグを設置する場合は、
フロントエンジニアの方への共有を忘れないようにしましょう。

あと、ここで社内テスト時のテスト項目書を
作っておいた方がいいかもしれない…と考えています。
あまり自作したことがないのですが、次の案件では作りたい！

操作マニュアルについて

管理画面があるサイトを制作する場合、
クライアントが管理画面を操作できるよう、マニュアルを作ることがあります。

細かい部分は実際に出来上がった管理画面を見ないと書けないですが、
このタイミングでマニュアル作成の準備をしておくと、あとが楽だと思います。
※社内テストと並行してマニュアルを作成する場合

社内テスト

フロントエンジニアの方が作ってくれたサイト、管理画面が問題なく動くか、
要件定義で決めた通りの仕様になっているか確認する作業です。

これは本当に難しいですね…。
今回の設定でいくと、既存サイトから記事コンテンツのデータを移行をしているので、
過去の記事が新サイトでもきれいに表示されているか、
リンク切れが起こっていないかなども細かくチェックする必要があります。

ブラウザも、このサイズなら綺麗に表示されているけど、
スマートフォンの小さい端末だと挙動が変、などいろんな事象が発生します。

仕様の確認も、様々なケースを想定してテストしないと、思わぬところに穴があったり…
あらゆる可能性を考慮したテスト項目書を作るAI、とか開発されたら人気が出そうですね。

受入テスト

社内テストが終わったら、受入テストといってクライアント側のテストに移ります。
※マニュアルもこの時お渡しします。

ここで修正依頼をいただいた場合は対応して、リリースまでの最終調整を行います。

• 公開スケジュール設定

• リリース手順確認

先述の通り、既存サイトと同じドメインを使用して新サイトを
公開する場合、DNSの切り替えやSSLの移行などで一歩間違うと大惨事なので、綿密にスケジュールの確認をとらないといけません。

ポイント

• 誰が（どの会社が）何を対応するか整理し、明確にしておく

• サイトへのアクセスが少ない時間帯で対応する

• 万が一不具合が発生した場合の対処法を想定しておく

• 緊急時の連絡体制を作っておく

公開

上記で組んだスケジュールをもとに、サイトを公開します。
無事公開できた暁には、以下対応を忘れないようにしましょう。

• サーチコンソールにサイトマップを送信

• GA4での計測ができているか確認

• サイト公開と別に納品物がある場合は送付

私なりに、自分の経験や失敗を踏まえてまとめてみました。
これを参考に仕事を進めてみて、
気づいたことなどをまたアップデートしていけたらなと思っています！