Webサイト制作をどれくらいの粒度で分解してタスク化するか
プロジェクトが始まるときにかなり初期の段階でWBSを作ることは多いとおもいます。そのWBSの作成、プロマネやディレクターに任せっぱなしになっていないでしょうか。WBSはスケジュールをガントチャートで表したものを指していると思われがちですが、実はスケジュールだけでなく見積もりやアサインを精度高く行うためにも重要なものです。
たとえば「Webデザイン作成」というスコープにどのような実作業が含まれているかはWBSを作ることによって見える化しプロジェクトメンバーやクライアントと共有できるようになります。ときどき下記のように書かれたWBSを見ることがあります。
Webデザイン作成
・作成
・確認
・修正
・確認2
・修正2
・確定
しかし、これでは「Webデザイン作成」に必要な知識、さらには作業量・スケジュール・予算も分かりません。Webデザイン作成の例を続けると、下記のように「作成」のスコープを分解してデザイナーが行う実作業を見える化することによって作業工数の確保や専門的な知識の必要性をプロジェクトメンバーやクライアントへ正しく伝えることができます。
Webデザイン制作
・コンセプト・トンマナの検討
・色彩検討
・タイポグラフィ、Webフォント検討
・画像、イラストレーション検討
・レイアウト・UI設計
・ページデザイン制作
今回は「Webサイトリニューアル」のプロジェクトを例として、要件定義〜公開までの全フェーズで、私たちがどれくらいの粒度でスコープを分解しWBSを作成しているかまとめてみます。
1. 要件定義
ここではリニューアル方針を決定するためにクライアントへのインタビューとワークショップを行うと仮定しています。ターゲットユーザー像はRFPに詳細がまとめられているため追加調査はナシとします。
1. 要件定義
1-1. 提案依頼書（RFP）等の読み込み
・RFPの共有・確認
・会社案内や経営計画資料の共有
・質問・確認事項シートの作成・確認
1-2. アクセス解析
・閲覧権限の設定
・アクセス解析実施
・レポート作成
1-3. インタビュー
・インタビュー日程調整
・インタビュー項目作成
・インタビュー項目事前共有
・インタビュー実施
・インタビュー議事録作成
1-4. ワークショップ
・ワークショップ目的とゴールの設定
・ワークショップ参加メンバー日程調整
・ワークショップ当日進行資料作成
・ワークショップ利用ツールの事前ログイン確認
・ワークショップ実施
・ワークショップレポート作成
1-5. 要件定義書
・これまでのインプット情報の整理と統合
・リニューアル方針のキーワード・コンセプト作成
・ベストプラクティスとしての参考サイト検索
・要件定義資料作成
2. 構造設計
構造設計は大規模サイトになるほど重要になります。たとえば「大学サイト」の制作で「受験生サイト」との仕分けが必要な場合や「ホールディングスのサイト」で「コーポレートサイト」との整理が必要な場合など、構造設計をしっかりと行うことで次の情報設計における迷いが少なくなります。またWebサイト全体にCMSを導入する場合には特にテンプレート設計は大切なポイントとなります。
2. Webサイト構造設計
2-1. サイトマップ
・現状サイトマップ作成
・リニューアルサイトマップ案作成
・テンプレートマップ案作成
・ユーザーナビゲーションフロー作成
・新規コンテンツ作成箇所の確認
2-2. ページリスト
・全ページ階層リスト作成
・リニューアル後URLの決定
・metaタグ内テキストの整理
・GA・GTMなどの導入タグの確認
2-3. 機能要件リスト
・ログイン機能・マイページの有無の確認
・サイト内検索・問い合わせフォームの有無の確認
・位置情報の利用有無の確認
・SNSシェアボタンの利用有無の確認
・PUSH通知の利用有無の確認
2-4. コンテンツリスト
・リニューアルコンテンツの新規作成／移行登録／削除の方針確認
・新規作成コンテンツの制作時期・点数を確認
・移行登録コンテンツの画像・図版の制作箇所を確認
3. 情報設計
ワイヤーフレームはレイアウトや装飾要素を作り込むと次のデザインがやりにくくなるため、あくまで情報の優先度や量を確認するための資料としてシンプルに仕上げることが重要です。ワイヤーフレームの作り方については以前noteに書いた記事 Webサイトのワイヤーフレームの作り方 - XDを開く前の3ステップ も参考にしてみてください。
3. Webサイト情報設計
3-1. フォーマットワイヤーフレーム
・情報量確認
・情報優先度設計
・ページ回遊設計
・仮レイアウト設計
・フォーマットワイヤーフレーム作成
3-2. テンプレート・汎用ワイヤーフレーム
・主要ページワイヤーフレーム複数案作成
・共通要素・個別要素の確認
・共通要素のテンプレートパーツ化
・個別要素の抜け漏れ確認
・テンプレート・汎用ワイヤーフレーム作成
3-3. 素材整理
・素材管理票作成
・素材不足、またクオリティ不足箇所の確認
・新規作成・ブラッシュアップが必要な原稿・文言の作成
・新規作成・ブラッシュアップが必要なイラスト・写真などの制作準備
・デザインに利用する画像・動画等の整理
4. デザイン
要件定義で言語化したキーワード・コンセプトと、情報設計で作成したワイヤーフレームを統合してデザインを作成していきます。基本的には色、文字、形、動き、配置などデザインの要素がリニューアルの目的に則した選択となっていることを説明できるように作成します。
4-1. デザインコンセプト
・1-5. 要件定義書のキーワード・コンセプトを受けたトーン＆マナーの確認
・トンマナ確認用としてのムードボード作成・参考サイト検索
・デザインコンセプト資料作成
4-2. フォーマットデザイン
・色彩設計
・タイポグラフィ、Webフォント検討
・画像、イラストレーション検討
・レイアウト設計
・フォーマットデザイン作成
4-3. テンプレート・汎用デザイン
・共通テンプレートパーツデザイン確認
・個別要素デザイン確認
・テンプレート・汎用デザイン作成
4-4. インタラクションデザイン
・インタラクション指示書作成
・エラー表示などのバリエーション要素デザイン作成
・OGP、favicon、汎用サムネイルなどのパーツ要素デザイン作成
5. コーディング
依頼されたスコープが「デザインまで」の場合でも、コーディングチェックはデザイナーも一緒に担当できないか必ず打診をしたほうが良いです。 文字やマージンの指定を全て抜け漏れなくコーディングに反映させるのはほぼ不可能な上、コーディングを見たうえで視認性を上げるなど細かな調整を行うことも多々あります。
5. コーディング
5-1. 実装方法確認
・コーディングガイドラインの有無の確認
・URL・meta・Alt表記ルールの確認
・SNS利用の確認
・開発環境の確認及び構築
5-2.フォーマットコーディング
・HTML/CSSコーディング作成
・Webフォント適用
・インタラクション実装
・デザイン整合性確認・調整
・インタラクションの気持ち良さの確認・調整
・表示速度確認・調整
・動作検証・調整
5-3. テンプレート・汎用コーディング
・記事セット作成
・文字数可変箇所の調整
・埋め込み・RSS読み込みパーツの確認
・テンプレート・汎用コーディング作成
6. CMS開発
ここではWebサイト全体にWordPressを導入すると仮定します。WordPressは特にセキュリティに気をつけなければならないため、ログインURLの変更、ユーザーパスワードの複雑化、プラグインの設定などを仕様書に細かく記載するようにします。
6. CMS開発
6-1. CMS仕様書
・使用想定プラグインの整理
・テンプレートページの投稿／固定／アーカイブページの方針確認
・WYSIWYGツールバーの設定
・カスタムフィールドの定義
・meta・RSS・ヘッダー・フッターなど共通モジュールの定義
・commonテンプレート・各ページテンプレートの定義
6-2. WordPress開発
・テーマの作成
・カスタムフィールド・記事セットの作成
・common・テンプレートの作成
・個別ページの作成
・運用を想定した登録・調整
・イレギュラー登録・調整
・モンキーテスト登録・調整
7. 移行
移行登録を進めると、記事セットが連続した場合のマージンの間隔に違和感がある、レイアウトが単調になってしまうなど、デザイン時に検証しきれなかった箇所が浮かび上がってくることがあります。数百ページを超える大規模サイトになるとデザイン時に全てのページを検証するのは難しいため、移行時に多少の調整を行うことを予めチームメンバーやクライアントにも了承してもらうことで下層ページの細部まで仕上げることができます。
7. 移行
7-1. 移行計画書
・移行対象ページの整理
・移行URL、metaの整理
・リダイレクト方針の確認
・使用記事セットの方針確認
7-2. 移行登録
・本文登録、画像登録
・PDFなどのファイル登録
・必要に応じてデザイン・コーディング微調整
・表示確認
8. 公開
ここでは公開はDNS切り替えを持って公開すると仮定します。新サーバーへのDNS切り替えのためリニューアル前の状態のWebサイトにメンテナンス画面などを表示する必要がない想定です。
8. 公開
8-1. 公開手順書
・公開タイムテーブル作成
・担当者緊急連絡先の明記
・プレスリリース・SNSシェアの有無の確認
8-2. 公開作業
・公開前データのバックアップ取得
・リダイレクト設定
・basic認証の解除
・DNS切り替え
8-3. 公開直後作業
・公開後問い合わせメールアドレスの送受信テスト
・公開後全ページの表示・URL確認
・公開後SNSシェアの確認
・公開後RSSリーダーの確認
・公開後GA・GTMの計測確認
●WBSを作成する際のポイント
スコープを分解する際に「作るプロセス」に含まれる「考えるプロセス」も制作工程として見える化させることがポイントです。そうすることでスコープに対して必要な知識や作業工数を共有することができます。
もしスコープを分解せず実作業内容がブラックボックス化してしまうと作業工数を低く見積もられ、スケジュールの短期化や予算の低下につながる可能性も生まれてしまいます。
またスコープを適切に分解することでプロジェクトが進んでいった際に何か上手くいかないことが起きたとき、どこに問題があるか特定することも容易になります。たとえばコーディング後にクライアントから「基本的に良いんだけどなんかグッとこない」と言われたとき、それを「デザインの問題」とせずに、問題点は「キャッチコピーのメッセージ」なのか「配色のバランス」なのか「インタラクションの気持ちよさ」なのか、と分けて検証することで的確に問題点を探り当てることができます。
WBSをしっかりとつくるメリットをまとめると下記のようになるでしょうか。
・作業工程が見える化するため、スケジュールの精度が上がる
・作業工数が見える化するため、見積もりの精度が上がる
・必要な知識が見える化するため、アサインの精度が上がる
・上記が見えることにより、プロジェクトへの理解度が上がる
スケジュールだけでなく、見積もりやアサインといったプロジェクト全体計画の重要項目を精度高く行うためにも、WBSはプロジェクトに関わるメンバー複数人、場合によってはクライアントも一緒に作成できるとベストです。
またWBSはプロジェクトマネージャーやディレクターが作成することが多いためデザインやコーディングのスコープを上手く分解出来ないというケースもあるかと思います。そういう場合にも担当するデザイナーやエンジニアに一緒に作成してもらうのが一番ですね。初期段階からメンバーを上手く巻き込んでいくのもプロジェクトを上手く進める重要なポイントの１つだと思います。
Shhh inc.は「大切となるものをつくる」を理念に掲げ、よく尋ね、よく対話をすることを通して、物事に備わる美質を深く理解することを大事にしています。Webサイト制作のご依頼や、ご相談がございましたらお気軽にご連絡ください。様々な事例とともに、私たちの強みや、制作フローについてご案内します。
● Shhh inc.のWebサイト
https://shhh.jp/
● 連絡先
info@shhh.jp
🤫