職種別WBSサンプル集：Web開発・デザイン・ライティング編
WBSの概念を理解していても、「いざ自分の案件に当てはめて書こうとすると手が止まる」という経験をしたことがある方は多いと思います。
特に、自分の職種に合った具体例が少ないとハードルが上がります。「WBSの教科書的な例」はプロジェクト管理の文脈で語られることが多く、エンジニア・デザイナー・ライターがそのまま使える形ではないことも珍しくありません。
この記事では、3つの職種に合わせたWBSサンプルをそのまま使えるような形で紹介します。それぞれ4階層（プロジェクト→フェーズ→成果物→タスク）で整理しています。
WBSの4階層おさらい
サンプルを見る前に、4階層の意味を簡単に確認します。
- プロジェクト層：案件・受注単位
- フェーズ層：時系列の段階（要件定義・設計・実装・テスト など）
- 成果物層：フェーズで生み出す具体的な納品物
- タスク層：実際に手を動かす最小単位の作業（時間を計測する対象）
この構造で整理することで、フェーズ別・成果物別に工数を集計できるようになります。
サンプル1：Webサイト制作（受託開発）
5ページ程度のコーポレートサイトを想定したサンプルです。
📁 コーポレートサイト制作
▾ 要件定義
▾ ヒアリング
□ ヒアリングシート作成（1h）
□ クライアントヒアリング実施（2h）
□ 議事録・要件書まとめ（2h）
▾ 要件確認
□ サイトマップ作成（2h）
□ クライアント確認・修正対応（1h）
▾ 設計
▾ ワイヤーフレーム
□ トップページWF（3h）
□ サービスページWF（2h）
□ 会社概要・その他ページWF（2h）
□ クライアントレビュー・修正（2h）
▾ デザインカンプ
□ トップページデザイン（6h）
□ 共通パーツ（ヘッダー・フッター）（3h）
□ クライアントレビュー・修正（3h）
▾ 実装
▾ 共通コンポーネント
□ ヘッダー・フッター実装（3h）
□ ボタン・フォーム等UIコンポーネント（3h）
▾ 各ページ実装
□ トップページ実装（4h）
□ サービスページ実装（3h）
□ 問い合わせページ・フォーム実装（4h）
▾ テスト・納品
▾ 動作確認
□ クロスブラウザ・レスポンシブ確認（2h）
□ フォーム送信テスト（1h）
▾ 納品
□ クライアントレビュー・最終修正（3h）
□ 本番環境デプロイ・確認（2h）
ポイント：「クライアントレビュー・修正対応」をWBSのタスクとして明示的に入れることが重要です。見積もり時にここが抜けると、後から工数が膨らむ原因になります。各フェーズにレビュー工数を含めることで、修正対応の実態が見えるようになります。
サンプル2：UIデザイン（SaaSプロダクトの新機能）
プロダクトの新機能UIをデザインする案件を想定したサンプルです。
📁 〇〇機能UIデザイン
▾ 調査・定義
▾ ユーザー調査
□ 既存ユーザーインタビュー準備（2h）
□ インタビュー実施・記録（4h）
□ インサイトまとめ（2h）
▾ 要件整理
□ 機能要件のデザイン変換（2h）
□ 制約条件・技術仕様確認（1h）
▾ コンセプト
▾ アイデア展開
□ ラフスケッチ・複数案作成（3h）
□ チームへの案提示・フィードバック収集（1h）
□ 方向性の決定（1h）
▾ デザイン制作
▾ ワイヤーフレーム
□ 主要画面のワイヤー作成（4h）
□ インタラクション設計（2h）
□ レビュー・修正（2h）
▾ ビジュアルデザイン
□ 主要画面のUIデザイン（8h）
□ エッジケース・エラー状態のデザイン（3h）
□ レビュー・修正（2h）
▾ デザインデータ整備
□ コンポーネント整理・命名（2h）
□ エンジニア向け仕様コメント（2h）
▾ 引き渡し
▾ ハンドオフ
□ エンジニアへの仕様説明（1h）
□ 実装確認・デザイン調整（3h）
ポイント：「エンジニアへの引き渡し後の調整」を明示的にタスク化しておくと、実装フェーズでの手戻り工数を事前に見積もれます。また「エッジケース・エラー状態のデザイン」を独立したタスクとして入れることで、この作業が抜け落ちるのを防げます。
サンプル3：Webライティング（オウンドメディア記事）
SEO記事を月4本執筆する案件を想定したサンプルです。
📁 〇〇社オウンドメディア運用（月次）
▾ 企画
▾ テーマ選定
□ キーワード調査・競合記事確認（3h）
□ 月次テーマ4本の選定・提案（1h）
□ クライアント確認・最終決定（1h）
▾ 執筆
▾ 記事A
□ 構成作成（1h）
□ 本文執筆（3h）
□ 修正・推敲（1h）
▾ 記事B
□ 構成作成（1h）
□ 本文執筆（3h）
□ 修正・推敲（1h）
▾ 記事C（記事A・Bと同様の構造）
▾ 記事D（記事A・Bと同様の構造）
▾ 納品・入稿
▾ 入稿作業
□ CMSへの入稿・画像設定（各記事30分 × 4本）
□ クライアント確認・修正対応（1h）
□ 公開確認（30分）
ポイント：ライティング案件では、1記事を「構成・執筆・修正」の3タスクに分けることで、どの工程に時間がかかっているかが見えやすくなります。執筆時間だけ見て見積もると、構成と修正の工数が漏れがちです。月次案件では1ヶ月を1プロジェクトとして扱うと、月ごとの工数比較がしやすくなります。
WBSサンプルを使うときの注意点
これらはあくまでサンプルです。実際に使う場合は、自分の案件の要件・規模・クライアントの関与度に合わせて調整してください。
コミュニケーション工数を忘れない：打ち合わせ・メール対応・確認作業はタスクに含めましょう。これが漏れると見積もりが実態より少なくなります。
修正対応は別タスクにする：「レビュー後の修正」は必ず発生します。作業自体のタスクとは分けて記録すると、どのくらい修正工数が発生するかの傾向が見えてきます。複数プロジェクトを経るうちに「この案件タイプはレビュー工数がX時間かかる」という感覚が数字として定着します。
初回は過去の案件と比較する：過去に類似案件の記録があれば、そちらを参照しながら今回のタスクの工数を調整します。WBSを同じ構造で記録し続けることで、過去との比較がしやすくなります。
4時間以内を目安にタスクを分解する：1タスクが大きすぎると、進捗の把握も難しくなります。「1日で終わるかどうか判断できる粒度」を目安にすると、適切な粒度に落ち着くことが多いです。
本記事で取り上げた「WBS4階層での作業分解と工数管理」は、LayerClock でも対応しています。 プロジェクト・フェーズ・成果物・タスクの4階層構造でWBSを登録し、タイマー計測で実績を積み上げられます。職種を問わず使える工数管理の仕組みを、無料から試すことができます。