WBSテンプレートは自分で作れる【2026年版】Excelの11列と記入例、分解の粒度と100%ルール

「WBSのテンプレートをダウンロードしたが、1行目から何を書けばいいのか分からない」——プロジェクトの計画づくりを任された方から、こうした相談をよく受けます。雛形が決めてくれるのは列の並びだけで、何を成果物とするか、どこまで細かく割るか、その行の完了をどう判断するかは、結局こちらで決めるしかありません。

結論から言うと、WBS(作業分解構成図)はテンプレートがなくても作れます。必要なのは、Excelに11の列を並べることと、分解の基準を3つ持つことだけです。列は、WBS番号・階層・作業名・成果物・完了の定義・担当者・開始日・終了日・予定工数・実績工数・状態。基準は、成果物を基準に分解する、100%ルールで漏れと重複を潰す、8/80ルールで粒度の上下限をそろえる。この2つがそろえば、今日のうちに1枚が仕上がります。

逆に、この決めごとを飛ばしたWBSは、作った翌週から更新されなくなります。原因はほぼ1つで、1行の意味が人によって違うからです。「画面設計」とだけ書かれた行は、画面遷移図まで含むのか、レイアウトだけで終わるのかが読み手によって変わる。意味が揺れる行は工数を見積もれず、担当も決まらず、完了の判断も自己申告になります。更新されないWBSは、作らなかったのとほぼ同じです。

本記事では、WBSが何を決める図でガントチャートとどう違うのか、作り方の5ステップと分解の3基準、Excelの11列の設計とそのまま写せる記入例、ワークパッケージとWBS辞書、WBSから工数と体制を出す流れ、機能しなくなる6つの失敗と更新運用、よくある質問の順に解説します。なお、この記事では配布用のExcelファイルはお渡ししません。代わりに、列の設計表と12行の記入例を本文の表で示します。そのまま写していただければ同じものができます。図解は、成果物基準の階層ツリーを1枚、WBSから工数と体制へつなぐ流れを1枚です。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。見せていただくWBSでつまずきが多いのは、「基本設計 一式 25人日」のように内訳のない行と、担当者の欄が「開発チーム」になっている行の2つです。この記事を読み終えるころには、自社のプロジェクトでWBSを1枚作りきり、開発会社から提示されたWBSの粗さも指摘できるようになるはずです。

WBS(作業分解構成図)とは——何を決める図で、ガントチャートとどう違うのか

WBSは Work Breakdown Structure の略で、日本語では作業分解構成図と訳されます。プロジェクトを完了させるために必要な作業を、最終成果物を頂点として段階的に分解し、階層構造で整理した図のことです。テンプレートを探す前に、この1枚が何を決めるための図なのかを押さえておくと、列を埋める手が止まりません。

WBSが決める3つのこと——作業の範囲、作業の単位、作業の持ち主

WBSが決めるのは、次の3つです。

プロジェクト管理ツールのBacklogは、WBS導入の目的を「プロジェクト完了までの全作業を抜け漏れなく洗い出すこと」と定義し、作業が明確化しないうちにスケジュールを策定すると失敗のリスクが高まると述べています。私の実感も同じで、WBSは作業表ではなく、着手前に射程と単位と持ち主を決めておくための取り決めだと考えています。この視点を持つと、後半で扱う失敗の直し方がすべて同じ理屈で説明できます。

ガントチャートとの違いと順番——構造が先、時間軸は後

WBSとよく混同されるのがガントチャートです。違いは、分解の軸にあります。

Backlogは「正確なガントチャートを作成するには事前にWBSを作成しておく必要がある」とし、WBSを下準備として位置づけています。Asanaも同様に、WBSで作業内容と優先順位を明確にしてからガントチャートで時間軸に落とし込む流れを理想としています。順番が逆になると、抜けていた作業を後から挿入するたびにスケジュール全体を引き直すことになり、要注意です。

「WBSを作って」と言われたら、どこまでを指すのか

ここで実務上の注意を1つ。厳密にはWBSにスケジュールは含まれませんが、日本の開発現場では「WBS」という言葉がスケジュール管理表そのものを指して使われていることが多いのが実情です。WBSの作成を依頼されたときは、スケジュールの作成まで含まれていると考えて進めたほうが、認識のずれが起きません。

そのため本記事でも、作業の分解に加えて、開始日・終了日・工数・状態まで1枚に持たせる形を前提にします。ただし、進捗をどの単位で測り、どの頻度で報告し、遅れをどう早く見つけるかという運用の設計は、別の話です。そちらは「進捗管理とは」の記事で詳しく扱っていますので、WBSを作り終えた後にお読みください。

次章では、そのWBSをどう分解していくのか、5つのステップで見ていきます。

WBSの作り方5ステップ——成果物を基準に分解し、粒度をそろえる

WBSの作成でつまずく場所は、ほぼ決まっています。「どこまで細かく割ればよいのか」と「そもそも何を1行にすればよいのか」の2つです。この2つは、分解の軸を成果物に固定し、粒度の基準を先に決めておくだけで解決します。順番に見ていきましょう。

5ステップの全体像(表)——範囲の確定から担当と期日の割り当てまで

ステップ1を飛ばして2から始める方が多いのですが、これが失敗のもとです。WBSを作成する前に、機能要件(画面・帳票・バッチ処理など顧客が求める機能)と非機能要件(24時間利用可能であること、ログの保管期間、対応ブラウザなど)の2つを明確にしておく必要があります。作るものが変われば必要な作業も変わるからです。

成果物を基準に分解する——動詞だけの行を作らない

分解の軸は2つあります。成果物型(最終成果物から逆算し、中間成果物ごとに割っていく)とプロセス型(要件定義・設計・実装・テストといった工程やフェーズで割っていく)です。成果が明確で期間の短いプロジェクトは成果物型、複数部門にまたがる中長期のプロジェクトはプロセス型が向くとされます。システム開発では、上位2階層をプロセス型(工程)、その下を成果物型(画面・帳票・バッチ単位)にする折衷が実務的です。

どちらを選ぶにせよ、守るべき原則は1つです。動詞だけの行を作らない。 作業を洗い出すときによくある間違いが、「○○画面の設計」とだけ書いてアウトプットが明確になっていない行です。同じ「画面の設計」でも、アウトプットは画面遷移図、画面レイアウト、画面機能仕様、画面入力チェック仕様と複数に分かれ、どこまでを含むかがPMと担当エンジニアでずれる。洗い出した作業のアウトプットが明確で、そのアウトプットに必要な工数が見積もれる程度まで書き出す。これが当社が案件で使っている基準です。

私も同じ考えで、1行を書いたら「この行が終わったとき、何が手元に残るか」を声に出して言えるかどうかを確認するようにしています。言えない行は、分解が足りていないか、そもそも作業として定義されていないかのどちらかです。

粒度をそろえる3つの基準(表)——100%ルール、8/80ルール、成果物基準

粒度の判断は、感覚ではなく基準で行います。実務で使われている代表的な基準は次の3つです。

Backlogは100%ルールと8/80ルールの両方を紹介し、「一番小さなレベルのタスクが数時間〜数日程度の作業に収まる粒度」を目安としています。Asanaも8/80ルールを分解の基準例として挙げつつ、作業が細かすぎると管理負担が大きくなり、粗すぎると精度が落ちるため、あらかじめ基準を用意しておくとよいと述べています。

なお、階層を深くしすぎるのも問題です。Backlogは、ツリー構造の階層を深くしすぎると、あるタスクが複数の親タスクにまたがったり、親子関係の定義に意識が割かれたりして、すべてのタスクを洗い出すという本質から離れがちだと注意を促しています。全体を無理なく把握できる程度まで割れたら、それ以上は無理に階層化しない。実務では3〜4階層で止まることがほとんどです。

洗い出しは1人でやらない——実作業者に聞く、AIはたたき台まで

最後にもう1点。WBSはPMが1人で作るものではありません。成果物の作成に必要な作業は、その領域の知識や経験がなければ洗い出せないためです。当社では、設計・実装・テストそれぞれの有識者に自分の担当範囲を洗い出してもらうほうが、効率がよく漏れも少ないと考えています。ただし丸投げすると工数にバッファが積まれすぎるため、作業1つ1つの内容を確認して妥当性を精査してください。

2026年現在は、タスクの洗い出しに生成AIを使う運用も広がっています。プロジェクトの概要・成果物・期間を渡せば、フェーズごとに分解されたタスクリストのたたき台が短時間で出てきます。Backlogもこの方法を紹介していますが、同時に「AIが生成したタスクリストはあくまでたたき台」であり、自社特有の作業や制約は反映されていないため担当者のレビューが必須だと明記しています。行数を増やすのは簡単になった分、粒度と完了の定義を人が決める重みが増した、というのが私の見方です。

ExcelでWBSを作る——11列の設計と、そのまま写せる記入例

ここが本記事の中心です。配布用のExcelファイルはお渡ししませんが、必要なのはファイルではなく列の設計と埋め方です。以下の表をそのままExcelの1行目に写し、記入例にならって埋めていけば、市販のテンプレートと同等以上のWBSができあがります。行にタスク、列に管理項目を並べた一覧表の形式が一般的で、これはExcelでもスプレッドシートでも変わりません。

最低限そろえる11列(表)——何を書き、書かないと何が起きるか

この11列のうち、市販のテンプレートに入っていないことが多いのがD列(成果物)とE列(完了の定義)です。Backlogが挙げる最低限の項目もWBS番号・大項目/中項目/タスク名・担当者・開始日/終了日・工数(予定・実績)・進捗率/ステータスで、成果物と完了の定義は「必要に応じて追加する列」の扱いです。しかし私の経験では、機能するWBSと2週間で放置されるWBSを分けているのは、まさにこの2列です。

なお、規模が大きくなったら次の2列を足してください。先行タスク(このWBS番号が終わらないと着手できない、という依存関係)と、備考(前提条件、決まっていないこと、確認先)です。依存関係の列があると、遅れが出たときにどこまで影響するかを即座に追えます。

WBS番号の振り方——1 / 1.1 / 1.1.1 で階層を表す

WBS番号は、階層をそのまま数字で表現します。第1階層が「1」「2」「3」、その配下が「1.1」「1.2」、さらにその配下が「1.1.1」という形です。Excelで扱うときは、番号列を文字列形式にしておいてください。標準形式のままだと「1.10」が「1.1」に丸められます。

採番は最初から連番で詰めず、間を空けておくのが実務的です。「1.1」「1.2」「1.3」ではなく「1.10」「1.20」「1.30」と振っておけば、後から作業が1つ増えたときに「1.15」を挿入するだけで済み、全体の採番をやり直さずにすみます。WBSは必ず後から行が増えるものなので、この一手間は効きます。

記入例(表)——小規模Webシステム開発のWBSを12行で書くと

問い合わせ管理の小規模Webシステム(画面3つ、帳票1つ)を例に、上位の階層と、要件定義・基本設計の配下だけを抜き出すと次のようになります。列が多いので、ここでは主要な7列で示します。

見ていただきたいのは3点です。1つめ、すべての行に成果物があること。「画面設計」で止めず、画面レイアウト図・画面遷移図・入力チェック仕様と、手元に残るものを書いています。2つめ、完了の定義が行ごとに書かれていること。「設計レビュー指摘0件」まで書けば、進捗が自己申告になりません。3つめ、予定工数が1〜4人日に収まっていること。8/80ルール(1〜10人日)の範囲内で、かつ遅れが週内に見える大きさです。

同じ調子で、詳細設計・実装・単体テスト・結合テスト・受入テスト支援・移行・リリースまで展開すれば、このシステムなら全体で80〜120行程度になります。受入テストは発注者側の工程なので、担当者列に発注者側の氏名が入る行が必ず出てきます。ここを空欄にしたまま進めると終盤で必ず詰まりますので、先に埋めてください。

Excelで作るときの実務上の注意4つ——版、並べ替え、稼働日、共有

1つめ、版数と更新日をシートの先頭に置く。WBSは必ず更新されるので、どれが最新版かが分からなくなるのが最大のリスクです。ファイル名ではなくシート内に持たせてください。

2つめ、並べ替えでWBS番号が崩れないようにする。作業名や担当者で並べ替えた後に保存すると、階層構造が失われます。並べ替えは必ずWBS番号昇順に戻してから保存する、というルールを決めておきます。

3つめ、稼働日を前提としてそろえる。日本とベトナムのように祝日が異なるチームが混在する場合、終了日を暦日で置くとずれます。当社が関わる案件では、ベトナムの祝日は2026年で年12日(労働法112条の法定は11日で、2026年からベトナム文化の日が加わります)、テト(旧正月)は2026年は2月14日〜22日で、この期間は稼働がほぼ止まります。時差は2時間なので日次の調整には支障がありませんが、期日の設定では両国の稼働日カレンダーを別列に持っておくと安全です。

4つめ、共有方法を最初に決める。Backlogも、Excel運用の課題として「ファイルが属人化しやすく、最新版がどれか分からなくなる」「複数人での同時編集や進捗のリアルタイム共有に向いていない」ことを挙げています。小規模・短期ならExcelで十分ですが、行数が200を超える、あるいは更新者が3名以上になるなら、共有ドライブでの同時編集か、プロジェクト管理ツールへの移行を検討したほうが早いです。

私が相談で見てきたWBSで、担当者列が「開発チーム」とだけ書かれているものは、例外なく終盤で遅れの所在が追えなくなりました。1行1名は、細かい規則ではなく、WBSが機能するための最低条件だと考えてください。

ワークパッケージとWBS辞書——1行の意味を固定し、工数と体制を積み上げる

ここまでで1枚のWBSはできました。ただ、実務で使い続けるには、もう2つ道具が必要です。1行の意味を固定する「ワークパッケージ」という単位の考え方と、図に書ききれない前提を逃がす「WBS辞書」です。この2つがあると、WBSは見積もりと体制づくりの根拠として使えるようになります。

ワークパッケージとは——WBSの最下層、見積もりと割り当ての単位

ワークパッケージは、WBSの最下層に位置する作業のかたまりです。それ以上分解しない単位で、工数の見積もり、担当者の割り当て、進捗の判定は、すべてこの単位で行います。前章の記入例でいえば「2.10 画面設計(問い合わせ一覧)」がワークパッケージにあたります。

ワークパッケージが満たすべき条件は3つです。

• 1人(または1チーム)に割り当てられること。 分割して複数名に配ると、完了の判断ができなくなります
• 工数を見積もれること。 見積もれないなら、まだ作業として定義できていません。Backlogも、内容が不明確なタスクは工数を推測で見積もらず、確定できない状態で残して実務の中で明らかにしていくべきだとしています
• 8/80ルールの範囲に収まること。 8時間以上80時間以下、つまり1人日から10人日程度

なお、WBSはウォーターフォール専用の道具だと思われがちですが、PMIの実務標準『Practice Standard for Work Breakdown Structures – Third Edition』(Project Management Institute、2019年7月発行、100ページ)は、第2版からの全面改訂にあたり、WBSをアジャイル、反復型、予測型、漸進型のいずれのプロジェクトライフサイクルにも適用する立場を取り、現在実務で使われている複数の分解方式を扱っています。アジャイルなら、スプリント単位で必要な範囲だけWBSを作り、イテレーションごとに更新していく使い方になります。

WBS辞書に逃がす6項目(表)——図に書ききれない前提を残す

WBS辞書は、各ワークパッケージの詳細を1件1行でまとめた別表です。Asanaは、WBSは視覚的に優れている一方で詳細な説明は省略されがちなため、補足としてWBS辞書を活用し、各タスクの目的・成果物・予算・マイルストーン・承認フローなどを簡潔にまとめて、誰が見てもタスクの中身が理解できる状態にすると説明しています。

実務で最低限そろえたいのは、次の6項目です。

「前提と除外」の行があるかどうかで、終盤の揉め事の量が変わります。口頭で合意したつもりの除外事項は、3か月後には全員が別の記憶を持っているのが実情です。

WBSから工数、工数から体制へ——積み上げの流れ

WBSを作る最大の見返りは、見積もりと体制の根拠が手に入ることです。流れは単純で、ワークパッケージの予定工数を足し上げると総工数(人日)が出て、月の稼働日で割ると人月になり、それを希望する工期で割ると必要人数が出ます。あとは工程ごとの必要スキルを見て、PM・BrSE・開発・QAの構成を決めます。

たとえば総工数が240人日で、1人月を20人日とすると12人月。これを4か月で終えたいなら、平均3名の体制が必要という計算になります。ただし全工程に3名が均等に必要なわけではなく、設計期に厚く、テスト期にQAを足す、といった波があります。WBSの各行に期日が入っていれば、月ごとの必要人数のグラフまで引けます。

工数の数え方、人時・人日・人月の換算、見積もり手法(類推・パラメトリック・ボトムアップ・三点見積もり)といった計算そのものは、本記事では扱いません。「工数とは」の記事と「工数計算のやり方」の記事で詳しく整理していますので、数字の作り方はそちらをご覧ください。また、算出した人数をどう図に落とすかは「プロジェクト体制図の書き方」の記事が担当です。

当社の場合、この計算の出口として最小構成をお示しすることが多く、日本人PMをフロントに置く形で2〜3人月、月額約80万円〜が目安です。単価は公開しており、実務3年目安で1,500USD(約22.5万円)、5年で2,000USD、10年目相当およびブリッジSEで3,000USDとしています(1USD=150円換算目安)。WBSから出た人月を、この単価表に当てるだけで概算が出せる形にしてあります。

次章では、ここまで作ったWBSが実務で機能しなくなる典型的なパターンを見ていきます。

WBSが機能しなくなる6つの失敗と、当社の更新運用

WBSは、作った瞬間がいちばん正確で、そこから現実とずれ続けます。ずれを取り込む仕組みがないまま2週間も経つと、誰も開かないファイルになる。ここでは、私が相談の中で繰り返し見てきた失敗を6つに整理し、それぞれの直し方と、当社がどう運用しているかをお伝えします。

失敗6つと直し方(表)——担当と期限がない、粒度がばらばら、更新されない

失敗5について補足します。5日で終わりそうな作業に手戻りのリスクを見て6日と書くやり方は、進捗遅延やコストオーバーの原因になるため当社では採りません。夏休みの宿題と同じで、人は工数やスケジュールに余裕があるほど作業を後ろへ寄せてしまうからです。バッファはタスクごとではなくプロジェクト全体で確保しておき、問題が発生したときに消費する。これはエリヤフ・ゴールドラットが提唱したCCPM(Critical Chain Project Management)の考え方で、当社もこの方針を採っています。Backlogも同様に、タスク単位でバッファを持たせると積み上げの過程で工数見積が膨張するため、まずクリティカルパスを正確に見極めてから必要に応じてバッファを設けるべきだとしています。

私が相談でいちばん多く見る2つ——「一式」の行と、担当者が「開発チーム」

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発に携わり、約100社の開発体制づくりを支援してきました。お客様から見せていただくWBSで、つまずきが多いのは次の2つです。

1つめは、「基本設計 一式 25人日」のような内訳のない行が並んでいるWBSです。発注側からすると妥当性を判断できませんし、率直に言えば、受注側も内訳を持っていないことが少なくありません。この行に出会ったら、「この行の成果物は何ですか」「完了はどなたが何を確認したら判断できますか」の2つを質問してみてください。答えが返ってこない場合、その工数は根拠のある数字ではありません。質問の形にすれば角も立ちません。

2つめは、担当者の欄が「開発チーム」になっているWBSです。作った時点では効率的に見えるのですが、遅れが出たときに誰の手元で止まっているかが最後まで分かりません。1タスク1担当者にしないと責任感が薄れ、最終的に誰が完了させるべきかが分からなくなる——これはBacklogも明確に推奨していない形として挙げています。

この2つに共通するのは、決めていないことが図の中に隠れている、という点です。WBSの欠陥は、たいてい図の不備ではなく、決めていないことが1つ残っている合図だと考えてください。

更新のタイミングと当社の運用——日本人PMが作成し、週次で更新する

当社のラボ型開発では、WBSの作成と更新を日本人PMが担当します。作成はプロジェクト開始前、更新は週次の定例に合わせる、という運用です。定例でお客様に決めていただくのは2つだけで、次の1週間の優先順位と、何をもって完成とするかです。この2つが決まれば、WBSの行の入れ替えと完了の判定は当社側で回せます。

介護記録SaaSのCareViewer様では、日本語対応のブリッジSE1名とフルスタックエンジニア2名の体制で、この週次の判断を続けています。ベトナムと日本の時差は2時間なので、午前に出た論点をその日のうちに調整でき、WBSの更新が翌週まで持ち越されません。品質面では、日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックの3点を標準にしており、これらがWBSの「完了の定義」列の中身になります。

体制の増減にも触れておきます。当社は1名から契約でき、最短2週間で開始、増員は約1週間、縮小や交代(リプレイスメント)は1か月単位です。人員の増減はWBSの担当者列と期日に直結するため、増減が決まった週の定例で必ずWBSを更新する運用にしています。

なお、進捗をどの単位で測り、どの頻度で誰に報告し、遅れを早く見つけるにはどうするかという運用設計そのものは、「進捗管理とは」の記事で詳しく扱っています。WBSは測る対象を用意する側、進捗管理は測り方を決める側、と役割が分かれると考えてください。

向く案件・向かない案件——WBSを細かく作る価値があるか

正直に書きます。WBSを11列で細かく作る価値があるのは、作るものが決まっていて、複数人が関わり、1か月以上続く案件です。要件が固まっており、工程が読め、担当を分ける必要がある。この条件がそろうほど、WBSは投資に見合います。

逆に向かないのは、1〜2名で2週間程度の改修、仕様が週単位で変わる探索的な開発、そして何を作るかがまだ決まっていない構想段階です。この段階でWBSを作り込むと、更新の手間だけが残ります。構想段階なら、まず作るものを1文で書き、MVPの範囲を決めるほうが先です。当社でも、構想段階からのご相談では、いきなりWBSを引くのではなく、範囲を絞った小さな塊を1つ作って様子を見る進め方をご提案することがあります。合わない案件には、その旨も率直にお伝えしています。

WBSテンプレートに関するよくある質問

最後に、WBSの作成と運用について、発注者の方からも開発会社の方からもよくいただく質問に5つお答えします。作図ツールの選び方、分解の階層数、アジャイルでの扱い、他社から提示されたWBSの見方、作成の分担という順です。

Q1. Excelとプロジェクト管理ツール、どちらで作るべきですか?

行数が200行以下で更新者が1〜2名なら、Excelで十分です。それを超えるか、複数人で同時に更新する必要が出てきたら、ガントチャートまで一元管理できるツールへの移行を検討してください。Excelは、追加や変更のたびにスケジュールの帯を手作業で引き直す必要があること、最新版がどれか分からなくなりやすいこと、同時編集に向かないことが弱点です。なお、顧客情報を扱うプロジェクトでは、クラウドツールの利用可否を先に社内で確認してください。

Q2. 何階層まで分解すればよいですか?

3〜4階層が目安です。最下層(ワークパッケージ)が8時間以上80時間以下、つまり1人日から10人日程度に収まっていれば、それ以上は無理に階層化しなくて構いません。階層を深くしすぎると、1つの作業が複数の親にまたがったり、親子関係の定義そのものに時間を取られたりして、作業を漏れなく洗い出すという本来の目的から離れます。

Q3. アジャイル開発でもWBSを作りますか?

作ります。ただし全期間を一度に分解するのではなく、スプリント単位で必要な範囲だけ作り、イテレーションごとに更新する形になります。PMIの『Practice Standard for Work Breakdown Structures – Third Edition』(2019年)も、WBSをアジャイル・反復型・予測型・漸進型のすべてのライフサイクルに適用する立場を取っています。なお、外注でアジャイルを回す場合の契約と体制は、別の論点になります。

Q4. 開発会社から提示されたWBSは、どこを見ればよいですか?

3点だけ見てください。1つめ、「一式」「その他」「調整」といった内訳のない行がないか。2つめ、担当者の欄が組織名ではなく個人または役割になっているか。3つめ、受入テストや資料確認など、発注者側が担当する行が入っているか。3つめが抜けているWBSは、こちらの作業時間が見積もりに入っていないため、後半で必ず詰まります。

Q5. WBSは誰が作るのですか?

原案はPMまたはPLが作り、実作業を担当するメンバーへのヒアリングで埋めるのが基本です。作業の洗い出しには知識と経験が要るため、PMが1人で完結させると漏れが出ます。当社のラボ型開発では日本人PMが原案を作成し、週次の定例で更新する運用。お客様に決めていただくのは、次の1週間の優先順位と、何をもって完成とするかの2点のみ。

まとめ: WBSは雛形ではなく取り決め——成果物・粒度・完了の定義を先に決める

WBS(作業分解構成図)が決めるのは、作業の範囲、作業の単位、作業の持ち主の3つです。テンプレートが決めてくれるのは列の並びだけなので、配布ファイルがなくても作れます。Excelに11列——WBS番号・階層・作業名・成果物・完了の定義・担当者・開始日・終了日・予定工数・実績工数・状態——を並べ、WBS番号は1 / 1.1 / 1.1.1 の形で振り、間を空けて採番しておく。これだけで、市販の雛形と同等以上の1枚になります。

作り方は5ステップです。範囲と最終成果物を確定し、成果物を基準に分解し、100%ルールで漏れと重複を潰し、8/80ルール(1人日から10人日)で粒度をそろえ、担当者と期日を1行1名で割り当てる。動詞だけの行は作らず、その行が終わったときに何が手元に残るかを必ず書いてください。図に書ききれない前提はWBS辞書に逃がし、目的・成果物・完了条件・前提と除外を1件ずつ残す。よくある失敗は、担当と期限がない、粒度がばらばら、更新されない、成果物がない、行ごとにバッファを積む、スコープ外が混ざるの6つで、いずれも決めていないことが1つ残っている合図です。

WBSができれば、ワークパッケージの工数を積み上げて総工数と必要人数が出せます。工数の数え方そのものは工数とはを、作ったWBSを使って進捗をどう測り報告するかは進捗管理とはをあわせてご覧ください。当社では日本人PMがWBSを作成し、週次の定例で更新しています。お客様に決めていただくのは、次の1週間の優先順位と、何をもって完成とするかの2点だけです。現在の体制と要件をお聞かせいただければ、WBSの粒度に合わせた体制案と概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。