Webサイト制作の標準WBSテンプレート——企画から公開後の運用まで

Webサイト制作のWBSは、案件ごとにゼロから書くより、標準テンプレートを持っておいて「削る」ほうが抜けが少ないと考えています。ゼロから書くと、書き手の頭にある作業しか並びません。私の場合、毎回抜けていたのは「公開後の作業」と「クライアント側の作業」でした。

以前の記事で分解の単位の決め方を書きました。今回はその単位で組んだ、私の標準テンプレートの中身を出します。

一段目は「企画・設計／制作／公開／運用」の4区切り

一段目は4つに切っています。工程で切っているように見えますが、狙いは契約と確認の区切りです。見積もりの分割、請求のタイミング、クライアントの承認がこの4つの境目で起きることが多いので、ここで切っておくと説明がしやすくなります。

制作の中身は、前回書いたとおり成果物（ページ・機能）を軸に割ります。一段目は区切り、二段目以降は成果物、という二層構造です。

WBSには、プロジェクトの範囲に含まれる作業を100%含め、範囲外の作業は含めないという「100%ルール」があるとされています（PMIの実践標準など）。テンプレートを持つのは、この「100%」に近づけるための手段だと思っています。

テンプレートの中身（抜粋）

実際には約30行ありますが、区切りごとに代表的な行を抜き出します。

区切り	主な行	抜けやすさ
企画・設計	ヒアリング／要件定義書（目的・対象・やらないこと）／サイトマップ／ワイヤーフレーム／原稿・素材の手配依頼	素材の「手配依頼」が抜ける
制作	トップのカンプ／下層テンプレートのカンプ／各ページ実装／フォーム実装／CMS設定／原稿流し込み	流し込みが実装に埋もれる
公開	表示・動作の検証／アクセシビリティ確認／計測タグ設置／ドメイン・SSL・DNS切替／リダイレクト設定／戻し手順の用意	戻し手順とリダイレクト
運用	サイトマップ送信／公開後1週間の監視／更新マニュアル／保守範囲の合意	ほぼ毎回抜ける

アクセシビリティの確認は、W3Cの勧告であるWCAG 2.2を参照先として置いています。全項目を検査するかは案件で決めますが、「どこまで見るか」を決める行があること自体が大事です。

サイトマップ送信は、GoogleのドキュメントではSearch Consoleのサイトマップレポートやrobots.txtでの指定が案内されています。数分で終わる作業ですが、行にしておかないと誰もやりません。

「クライアント側の作業」も同じ表に書く

テンプレートで一番効いているのは、クライアント側の作業を同じWBSに行として書くことです。原稿の提出、写真の手配、確認と承認、ドメイン管理画面へのアクセス権の共有。これらを「担当：クライアント」として並べます。

別の表に分けると、進行管理の対象から外れます。そして遅れの原因は、私の経験ではこちら側に集まりがちでした。同じ表に載っていれば、週次のレビューで制作側と同じ目線で確認できます。書き方も制作側と揃えて、「〜を提出する」「〜を承認する」と完了の条件が1文で書ける形にしています。

削るときは「理由」を1行残す

テンプレートは削って使います。多言語対応がなければその行を消し、CMSを使わなければCMS設定を消します。ただ、消した行は「やらないこと」として先頭に移すようにしています。

「リダイレクト設定：旧サイトなしのため対象外」と書いてあれば、あとで旧ドメインが見つかったときに、それが範囲外の追加だと双方が分かります。黙って消した行は、「含まれていると思っていた」の火種になります。

明日から試せる一手

直近で公開した案件のWBSを開いて、「公開」と「運用」の区切りに何行あるかを数えてみてください。0〜2行なら、上の表の公開・運用の行を足すところから始めると、次の案件のテンプレートの芯になります。テンプレートは一度で完成させるものではなく、案件のたびに「今回抜けた行」を1行ずつ足していくものだと思っています。