WBSでプロジェクト完遂に必要なタスクをすべて洗い出す。その必要性とタスク項目例。

2020年12月13日 2021年06月01日

たぐと申します。
東京のweb制作会社でプロデューサーをしています。

今回は、webサイトのリニューアルに限らず、プロジェクトを進める場合、WBSを定義しておきましょう、という話をします。

WBSとはなんでしょうか。

これは、Work Breakdown Structureの略で
作業分解構成図と言われています。

WBSはプロジェクト完遂のためのタスクをすべて書き出したもの。

WBSとは何か？
要は、このプロジェクトを完遂するには、どのようなタスクが発生するのかを「すべて」洗い出したものです。

これがあると、作業の抜け漏れがなくなります。
そして、これをすべて完了させればプロジェクトは完了であるという定義でもあります。

WBSはスケジュールではありません。タスク一覧です。

ここでよくある誤解を2つほど挙げておきます。

WBSはスケジュールではありません。

WBSをスケジュール表と捉える人がいますが、ちょっと違います。
WBSの本質は、必要な作業を洗い出すことで、そちらが第一優先です。
いつからいつまでにやるかは二の次です。

粒度としては、クライアントが理解できるレベルのものです。
制作会社側の制作タスクではなく、クライアント側とすりあわせるために使うもの、と認識しておいた方がスムーズです。

余談ですが、私の経験上、クライアントは、詳細なスケジュールなど見てくれません。クライアントが言うのは常に
「何をいつまでにやればよいですか？」
です。
その前提で考えると、クライアントとのタスクや予定のすりあわせはWBSでやるのが自然だと思います。ページ単位のステータス管理や、日別のスケジュール管理は、制作側で管理しておければ問題ありません。（私の場合ですが・・・。）

WBSはサイトマップでもありません。

ページを作ることはタスクの一部でしかありません。
なのでページの一覧をWBSとは呼びません。

サイトマップは、ページの一覧であってタスク一覧ではないのです。
サイトマップはサイトマップとして別で定義しましょう。

WBSのタスクごとで定義する内容

WBSで定義するタスク例の前にもう１つ。
WBSで定義するタスクにはどういう情報が付随するでしょうか。
それも挙げておきます。

タスク名
タスクの具体内容
担当者
アウトプット
開始時期・終了時期

主にはこの5つをタスクごとに定義するイメージです。

これらもタスクにあわせて定義しておくと、クライアント側、制作側双方で認識の齟齬が起きにくいです。

WBSに含める具体的なタスク項目

次に、WBSで定義されるタスクには、どのようなものがあるでしょう。
プロジェクトフェーズごとで項目を挙げてみようと思います。
※あくまで一例としてご覧ください。

1. 要件定義・プロジェクト計画フェーズ

設計フェーズまでの定例ミーティング計画
制作体制構築
概算スケジュール策定
制作対象スコープ定義
コミュニケーション計画
現状サイト内容把握
現状サイトアクセス状況把握
コンテンツマップ定義
連携サービス選定
サイト基本仕様策定
機能要件定義
非機能要件定義
お見積

2. 戦略策定・設計フェーズ

ハイレベルサイトマップ定義
詳細サイトマップ定義
画面設計書作成
コンポーネント設計
CMS機能設計
システム設計（お問い合わせフォーム等）
サーバ環境準備（開発環境・本番環境）
ドメイン管理、設定定義
サーバ証明書契約・設定
アクセス解析設計
連携サービス契約
テスト・検証計画

3. 制作フェーズ

トップページデザイン
主要下層ページデザイン
コンポーネント定義
下層ページデザイン展開（コンポーネントベース）
画像パーツ作成
画像素材購入
ベースコーディング
主要下層ページコーディング
下層ページコーディング展開
CMSテンプレート開発
システム開発（お問い合わせフォーム等）
アクセス解析設定
表示検証・機能検証

4. 導入・テストフェーズ

コンテンツ移行計画
データ移行
CMSデータ投入
301リダイレクトリスト準備
CMSご利用ガイド策定
CMSご利用方法レクチャー会
コンテンツ検証
公開計画
開発環境・本番環境差分反映
旧サイトデータバックアップ

5. 公開フェーズ

TTL短縮設定
本番公開（DNS切り替え対応）
公開通知設定（サーチコンソールでのsitemap.xml配信）
公開後動作確認（パス参照、アクセスログ取得）
TTL復元設定
サーバ内不要データ削除

WBSはプロジェクト完遂に必要なタスク一覧。

今回はWBSがどういうものかについてまとめてみました。
発生するタスクを定義することは、ある意味

要件定義を「やることリスト」に昇華させたもの

とも言えるかもしれません。

最初にも述べましたが、プロジェクトというものは本来お見積を提示している段階でどういうことを実行するのか、発生するタスクは見えているべきです。

うまくいかないプロジェクトは、そこが曖昧でクライアントと握りきれておらず、想定外のタスクが次から次へと発生しがちです。

WBSはクライアントと、このプロジェクトが今後どのように進んでいくのかをイメージしてもらうためにもとても重要です。

WBSという言葉自体は、特にここ1、2年でよく聞かれるようになった印象がありますが、便利かつ、制作者、クライアント側双方において、心の平穏を保つため、本来やるべきタスクを見落とさないためにも有効ですので、ぜひ作成しておくことをお勧めします。