WBSの作り方と、作業を漏れなく分けるための手順

WBSの作り方を調べると、「作業を階層に分けましょう」という説明はすぐに見つかります。でも、実際に白紙の表を前にすると、どこから分け始めればよいのか、どこまで細かくすればよいのかで手が止まります。この記事では、WBSを「成果物から先に洗い出し、作業はその後に分ける」という順番で作る手順を、システム開発とWeb制作の例を使って整理します。作業の漏れを確かめる方法、細かくしすぎないための目安、Excelとプロジェクト管理のツールの使い分けまで扱います。

先に結論を書いておきます。WBSで漏れを防ぐいちばんの近道は、「何を作るか」を先に全部並べ、「どう作るか」はその後で考えることです。作業から書き始めると、慣れている作業ほど細かく、慣れていない作業ほど粗くなり、そこに漏れが生まれます。

WBSとは何か：作業を階層で分解した一覧

WBSは「Work Breakdown Structure」の略で、日本語では「作業分解構造」と訳されます。プロジェクトの目標を達成するために必要な作業を、大きなかたまりから小さな単位へと、階層に分けて書き出したものです。

プロジェクトマネジメントの国際的な指針であるPMBOKガイドは、第3版の時点で、WBSを「プロジェクトの目的を達成し、必要な成果物を作成するために、プロジェクトチームが実行すべき作業を成果物指向で階層的に分解したもの」と定義しています。成果物指向とは、作業ではなく「できあがるもの」を軸に分けていく考え方のことです。

WBSがよく混同されるものに、タスクリストとガントチャートがあります。違いを整理すると次のようになります。

名前	何を表すか	主な用途
WBS	プロジェクトの作業の全体を、階層で分けた一覧	作業の漏れを防ぐ、範囲を合意する
タスクリスト	やることを並べたもの（階層がないことも多い）	日々の作業を管理する
ガントチャート	作業を期間の横棒で並べた図	日程と作業の重なりを見る

順番で言えば、WBSで作業を出し切り、それに期間と担当を付けてガントチャートにし、日々の動きはタスクリストやカンバンで追う、という流れです。WBSを作らずにいきなりガントチャートを描くと、横棒の数が足りているかどうかを確かめる手段がありません。

Web開発の案件でも、要件定義の打ち合わせのあとに「全体の作業量を見積もって」と言われる場面がよくあります。そのときに手元にWBSがあるかどうかで、見積もりの精度は大きく変わります。逆に言えば、WBSを作れることは、受託の仕事で単価交渉の根拠を示せることでもあります。

作業から分けると漏れる理由

WBSの作り方には、大きく2つの進め方があります。作業（プロセス）を先に分ける「プロセス指向」と、成果物を先に洗い出す「成果物指向」です。

プロセス指向では、システム開発なら「要件定義」「設計」「実装」「テスト」と工程で大きく分け、それぞれをさらに細かい作業に分けていきます。工程の名前は決まっているので書き始めやすく、多くの現場で使われています。

ただし、この進め方には弱点があります。作業の名前だけでは、何ができたら完了なのかがはっきりしないことです。「画面設計」という作業があっても、どの画面の設計書を何枚作れば終わりなのかは書かれていません。その結果、作業がずるずると膨らんだり、後になって「この画面の設計書がない」と気づいたりします。

システム開発のコンサルティング会社が公開している解説では、成果物から先に考える進め方の利点が次のように整理されています。

①ステークホルダーと合意形成しやすい スコープをステークホルダが実際に見る「成果物」を示すため、作業（プロセス）で語るよりステークホルダーのイメージが湧きやすく、合意形成に役立ちます。 ②作業が膨らみづらい 作業だけでは完了の状態がステークホルダーとズレることが多く、作業が膨らむリスクが高くなります。一方、作業の完了条件を成果物にすればステークホルダー間で作業内容のズレがおきづらく作業工数が安定します。 出典: note.com

ステークホルダーとは、発注者や利用者など、そのプロジェクトに関わる人のことです。成果物で話すと、相手が「何ができあがるのか」を具体的に想像できるので、範囲の合意が取りやすくなります。

以前、あるWeb制作の案件で、工程だけでWBSを組んで進めたことがありました。テストの工程に入ってから、「管理画面の操作マニュアルも納品物に入っている」と発注者から言われ、マニュアルの作成がまるごと見積もりから抜けていたことが分かりました。工程の名前には「マニュアル作成」という言葉がどこにもなかったので、誰も気づけなかったのです。成果物の一覧を先に作っていれば、最初の打ち合わせで確認できた漏れでした。

WBSを作る前に集めておく情報

白紙の表を前に手が止まる原因の多くは、作り方を知らないことよりも、材料がそろっていないことにあります。WBSに取りかかる前に、次の情報を手元に集めておくと、作業がぐっと進めやすくなります。

・発注者の依頼の文面や提案書、見積もりの依頼書
・打ち合わせの議事録（何を作るか、何を作らないかの発言）
・納品物の一覧（契約書や発注書に書かれているもの）
・期限と、途中で確認が必要な日（社内の会議、決裁の日など）
・関わる人の名前と役割、作業に使える時間
・過去に似た案件をしたときの記録

特に大切なのが、契約書や発注書に書かれた納品物の一覧です。WBSの成果物は、ここに書かれたものと食い違ってはいけません。契約書に「操作説明書」とあるのにWBSに入っていなければ、その時点で漏れが確定します。

材料が足りないときは、WBSを作りながら発注者に質問する形でもかまいません。「この作業は誰が担当しますか」「この成果物は納品物に含まれますか」と聞くこと自体が、範囲の合意を進める作業になります。

WBSの作り方：6つの手順

ここからは、成果物指向でWBSを作る手順を順番に説明します。例として、小規模な会社のコーポレートサイトをリニューアルする案件を使います。

手順1：ゴールと範囲を1行で書く

最初に、このプロジェクトが何を達成すれば終わりなのかを1行で書きます。例では「既存のコーポレートサイトを、スマートフォン対応の新しいデザインで公開し、更新は社内でできる状態にする」です。

この1行に入っていないものは、プロジェクトの範囲の外です。「ついでにSNSの運用も」といった追加の要望が出たときに、範囲の内か外かを判断する基準になります。

手順2：成果物を全部書き出す

次に、プロジェクトが終わったときにできあがっているものを、全部書き出します。ここでは作業のことは考えません。

・公開されたWebサイト（ページ一式）
・デザインのデータ
・サイトの構成図（どのページがどこにつながるか）
・更新マニュアル
・サーバーとドメインの設定
・旧サイトからの転送の設定
・テストの結果の記録

ポイントは、形の残るものだけでなく、「設定」や「記録」のような目に見えにくいものも入れることです。漏れるのは、たいていこの目に見えにくい成果物です。

手順3：成果物を大きなかたまりにまとめる

書き出した成果物を、意味のまとまりで3〜6個程度のグループに分けます。これがWBSの第1階層になります。例では「企画・構成」「デザイン」「実装」「公開と移行」「運用の引き継ぎ」の5つです。

グループの分け方に正解はありませんが、「担当する人が違うもの」「発注者の確認が必要なもの」で分けると、後の工程で扱いやすくなります。

手順4：成果物を作るための作業に分ける

ここで初めて作業を考えます。第2階層の成果物ごとに、「これを作るには何をするか」を書き出していきます。

たとえば「更新マニュアル」なら、次のように分けられます。

・マニュアルの目次を決める
・画面の撮影をする
・本文を書く
・発注者に確認してもらう
・指摘を直して納品する

作業の名前は「動詞で終わる」形にそろえると、何をすれば完了なのかがはっきりします。「マニュアル」ではなく「マニュアルの本文を書く」と書く、ということです。

手順5：担当・期間・完了の条件を付ける

一番下の階層の作業ごとに、担当者、かかる時間の見積もり、完了の条件を付けます。完了の条件とは「発注者の確認が済んでいる」「テストの記録が残っている」のように、終わったことを誰でも判断できる状態のことです。

見積もりの単位は、時間でも日数でもかまいませんが、1つのWBSの中ではそろえてください。混ざると合計を出すときに間違えます。

手順6：抜けがないか確かめて、ガントチャートに展開する

最後に、次の節で説明する確かめ方で漏れをチェックし、作業の順番と期間をガントチャートに並べます。作業どうしの前後関係（Aが終わらないとBに入れない）もここで書き込みます。

ここまで終われば、WBSは「作業の一覧」から「日程の計画」に変わります。

例：コーポレートサイトのリニューアルのWBS

手順を通して作ったWBSが、実際にどのような形になるのかを見ておきます。前の節で使ったコーポレートサイトのリニューアルの例を、表にすると次のようになります（見積もりは説明のための例で、実際の案件では規模によって大きく変わります）。

番号	作業	担当	見積もり	完了の条件
1	企画・構成
1.1	現行サイトのページと問い合わせ経路を一覧にする	ディレクター	4時間	一覧を発注者と共有した
1.2	サイトの構成図を作る	ディレクター	6時間	発注者の合意が取れた
1.3	各ページの原稿の担当を決める	発注者	2時間	担当表が確定した
2	デザイン
2.1	トップページのデザイン案を作る	デザイナー	12時間	案を提出した
2.2	デザイン案の修正点を発注者と合意する	デザイナー	3時間	修正点の一覧が確定した
2.3	下層ページのデザインを作る	デザイナー	16時間	全ページの案を提出した
3	実装
3.1	共通部分（ヘッダー・フッター）を組む	エンジニア	8時間	確認用の環境で表示できる
3.2	各ページを組む	エンジニア	24時間	全ページが表示できる
3.3	更新の仕組みを組み込む	エンジニア	10時間	発注者がテスト用の記事を更新できた
4	公開と移行
4.1	旧ページからの転送を設定する	エンジニア	4時間	旧アドレスから新ページへ移る
4.2	表示と動作のテストをして記録を残す	エンジニア	6時間	記録を発注者に提出した
4.3	本番に公開する	エンジニア	2時間	公開後の確認が済んだ
5	運用の引き継ぎ
5.1	更新マニュアルを書く	ディレクター	8時間	発注者の確認が済んだ
5.2	更新の操作を説明する	ディレクター	2時間	説明会が終わった

表にしてみると、いくつかのことが分かります。まず、発注者が担当する作業（1.3の原稿の担当決め）も、WBSに入れておくべき作業だということです。受ける側の作業だけを並べると、発注者の作業が遅れたときに日程がずれる理由を説明できません。

次に、「合意する」「確認が済んだ」という完了の条件が、全体のあちこちに入っていることです。作る作業と同じくらい、確かめてもらう作業が日程を左右します。

そして、見積もりを合計すると、案件の全体の作業量が見えてきます。この例では合計が100時間を超えます。この数字があれば、「この期間でこの人数なら間に合うか」を判断でき、見積もりの金額を説明する根拠にもなります。

漏れを防ぐ確かめ方

WBSを作ったら、そのまま使い始める前に、漏れがないかを確かめます。現場で使いやすい確かめ方を4つ紹介します。

1つ目は、「100%ルール」と呼ばれる考え方です。下の階層の作業を全部足すと、上の階層の成果物がちょうど完成する、という状態になっているかを確かめます。足りないなら漏れがあり、はみ出しているなら範囲の外の作業が混ざっています。各グループについて「この下の作業を全部終えたら、本当にこの成果物はできあがるか」と問い直すだけで、かなりの漏れが見つかります。

2つ目は、成果物どうしのつながりを見ることです。ある作業の材料（インプット）になる成果物が、どこかで作られているかを確かめます。「デザインを作る」作業の材料には「サイトの構成図」が必要で、その構成図を作る作業がWBSにあるか、という確かめ方です。

3つ目は、「確認」と「修正」の作業を入れているかです。作業を書き出すと、作る作業だけが並び、発注者に確認してもらう作業と、その指摘を直す作業が抜けがちです。実際の日程では、この2つに意外と時間がかかります。

4つ目は、プロジェクトの最初と最後の作業です。キックオフの準備、契約の確認、公開後の引き継ぎ、請求の書類づくりといった、本体の作業の前後にあるものが抜けやすくなります。

確かめるときは、自分1人で見るより、作業を担当する人やほかのメンバーにも見てもらうほうが確実です。人によって見えている作業が違うので、「この作業はどこに入っていますか」という質問がそのまま漏れの発見になります。

見積もりの付け方：1つの数字で決めず幅を持たせる

WBSの作業に見積もりを付ける段階で、多くの人が悩むのが「何時間と書けばよいか」です。経験のある作業なら過去の実績から付けられますが、初めての作業では見当がつきません。そこで役に立つのが、1つの作業に3つの数字を付ける方法です。

3つの数字とは、うまく進んだときの時間（楽観値）、ふつうに進んだときの時間（最も起こりやすい値）、つまずいたときの時間（悲観値）です。この3つから、次の式で見積もりを出します。

見積もり ＝（楽観値 ＋ 最も起こりやすい値 × 4 ＋ 悲観値）÷ 6

たとえば、更新の仕組みを組み込む作業で、楽観値が6時間、最も起こりやすい値が9時間、悲観値が18時間なら、（6＋36＋18）÷6で 10時間 になります。ふつうに進んだときの9時間より少し長くなるのは、つまずいたときの重さが反映されるからです。

この方法の利点は、見積もりの根拠を説明しやすいことです。「10時間」とだけ書くより、「うまくいけば6時間、つまずくと18時間かかる作業なので10時間で見ています」と伝えるほうが、発注者も不確かさを理解できます。悲観値が大きい作業は、それだけ見通しが立っていない作業なので、早めに着手して不確かさを減らす、という判断にもつながります。

見積もりを付け終えたら、実際にかかった時間を作業ごとに記録しておきます。次の案件で似た作業が出てきたときに、その記録がいちばん信頼できる見積もりの材料になります。案件を重ねるほど見積もりの精度が上がり、受託の仕事で赤字を出しにくくなります。

細かくしすぎない：分解の目安とローリングウェーブ

WBSを作り始めると、真面目な人ほど作業を細かく分けたくなります。細かく分けると管理の精度が上がった気がするからです。ただ、細かすぎるWBSは、更新が追いつかなくなって使われなくなる、という結末を迎えがちです。

分解をどこで止めるかの目安として、現場でよく使われるのは次のような基準です。

・1つの作業が、1人の担当者で完結する
・1つの作業の見積もりが、数時間から数日に収まる（80時間を超えるものはさらに分ける、という目安もよく使われます）
・完了したかどうかを、誰が見ても判断できる
・それ以上分けても、担当や日程の判断が変わらない

もう1つ覚えておきたいのが、「ローリングウェーブ」という進め方です。先のことほど不確かなので、直近の作業だけを細かく分け、先の作業は大きなかたまりのままにしておき、近づいてきたら細かく分ける、という考え方です。

先に紹介した解説でも、全体はプロセスの中分類から小分類までにとどめ、直近1か月の作業だけを最小の単位に落とす、といった運用が勧められています。数か月先の作業まで細かく書いても、そのとおりに進むことはまずありません。書いた分だけ書き直しの手間が増えます。

フリーランスで受ける案件でも、この考え方は効きます。契約の段階では大きなかたまりで見積もり、着手してから2週間ごとに次の作業を細かくする、という進め方にすると、見積もりの精度と更新の手間のバランスが取りやすくなります。

作り方でつまずきやすいポイント

ここまでの手順を踏んでも、つまずきやすいポイントがいくつかあります。よくあるものを整理しておきます。

まず、階層によって分け方の基準が混ざることです。第1階層は工程で分け、第2階層は担当者で分け、第3階層は画面で分ける、というように基準が混ざると、同じ作業が2か所に出てきたり、どこにも入らなかったりします。同じ階層の中では、分ける基準を1つにそろえてください。

次に、作業の名前があいまいなことです。「調整」「対応」「確認など」といった言葉は、何をすれば完了なのかが分かりません。「デザイン案の修正点を発注者と合意する」のように、具体的な動作と相手を書きます。

3つ目は、管理のための作業を入れ忘れることです。定例の打ち合わせ、進み具合の報告、議事録の作成といった作業は、成果物を直接作るわけではないので抜けがちです。プロジェクト全体の時間の中では無視できない量になるので、「プロジェクト管理」というグループを1つ作って入れておくと安心です。

4つ目は、作ったWBSを更新しないことです。WBSは計画の段階で作って終わりではなく、作業の追加や変更が出るたびに直していくものです。更新されないWBSは、すぐに実態と食い違い、誰も見なくなります。

5つ目は、作業時間の見積もりを楽観的に付けることです。経験のない作業ほど見積もりは甘くなります。過去に似た作業をしたときの記録がある場合は、それを参考にし、ない場合は少し多めに見積もって、実績が出たら次の見積もりに反映させます。

6つ目は、1人の担当者に作業が集中していることに気づかないことです。WBSを作り終えたら、担当者ごとに見積もりの合計を出してみてください。特定の人だけ合計が大きく、しかも同じ時期に作業が重なっているなら、その人が遅れた時点で全体が止まります。作業を分け直すか、時期をずらすか、手伝える人を早めに決めておくと、日程の崩れを防げます。

7つ目は、休みや他の案件の予定を考えないことです。フリーランスで複数の案件を並行して受けている場合、1日に使える時間は8時間ではありません。WBSの見積もりを日程に直すときは、この案件に使える時間で割り算してください。

短い周期で進める開発でのWBSの使い方

ここまでの説明は、最初に全体を決めてから順に進める進め方（ウォーターフォール型）を前提にしてきました。一方で、Webサービスやアプリの開発では、1〜2週間の短い周期で作っては見直す進め方（アジャイル型）も広く使われています。この進め方でもWBSは役に立つのか、という疑問をよく聞きます。

答えは「形を変えれば役に立つ」です。短い周期で進める開発では、最初にすべての作業を細かく決めることはしません。その代わり、「この開発で最終的に提供する機能」を成果物として大きく並べ、それを周期ごとに取り組む単位に分けていきます。考え方としては、成果物を先に洗い出す成果物指向そのものです。

具体的には、次のように使い分けます。

・全体の見通しは、成果物（機能）の一覧として第2階層くらいまでで止めておく
・直近の周期で取り組む機能だけを、作業の単位まで細かく分ける
・周期が終わるたびに、成果物の一覧を見直し、追加や削除を反映する

これは前の節で触れたローリングウェーブの考え方と同じです。違いは、見直しの間隔が短く決まっていることだけです。

短い周期の開発で失敗しやすいのは、「毎回の周期の作業は見えているのに、全体でどこまで来たのかが分からない」状態になることです。成果物の一覧を全体のWBSとして持っておけば、「全体の機能のうち、いくつが終わったか」を発注者に示せます。受託で開発を請け負う場合、この全体の見通しがあるかどうかで、発注者の安心感は大きく変わります。

WBSを発注者と共有するときのコツ

業務委託で仕事を受ける立場では、WBSは自分の作業管理の道具であると同時に、発注者との約束を目に見える形にする書類でもあります。共有のしかたで、その後のやり取りのしやすさが変わります。

1つ目のコツは、共有するのは第2階層までにすることです。発注者が知りたいのは、細かい作業の手順より「何がいつできあがるか」です。一番下の階層まで見せると、作業の進め方に細かく口を出されたり、見積もりの1行ずつに値引きを求められたりすることがあります。

2つ目は、範囲の外の作業を明記することです。WBSの最後に「この案件に含まれないもの」として、SNSの運用、写真の撮影、原稿の執筆などを書いておきます。後から「それも入っていると思っていた」と言われるのを防げます。

3つ目は、変更があったら日付を入れて版を残すことです。追加の要望で作業が増えたときに、いつ、何が、なぜ増えたのかが残っていれば、追加の費用や日程の相談を落ち着いて進められます。

4つ目は、発注者の作業もはっきり書くことです。原稿の提出、確認の返事、素材の提供など、発注者が担う作業に期限を付けて共有しておくと、遅れたときの日程の調整がしやすくなります。

Excelで作るか、ツールで作るか

WBSは、Excelやスプレッドシートでも十分に作れます。列を「階層番号」「作業名」「担当」「見積もり」「開始日」「終了日」「完了の条件」「状態」にして、階層は番号（1、1.1、1.1.1）で表すのが一般的です。

Excelで作る利点は、追加の費用がかからず、発注者とファイルでやり取りしやすいことです。小規模で、関わる人が2〜3人までの案件なら、Excelで困ることは少ないはずです。

一方で、次のような場面ではExcelでは扱いにくくなります。

・関わる人が5人を超え、誰がどの版のファイルを持っているか分からなくなる
・作業の状態（着手前・作業中・完了）を毎日更新したい
・作業ごとにやり取りした内容を残したい
・WBSからガントチャートを自動で描きたい

こうした場面では、プロジェクト管理のツールに移すと楽になります。ツールの多くは、カードやタスクに親子関係を付けてWBSの階層を表し、期限を入れるとガントチャートに横棒として表示する仕組みを持っています。

選ぶときは、「ガントチャートが無料の範囲で使えるか」「階層をどこまで表せるか」「発注者など社外の人を招待できるか」の3点を確かめてください。ツールによっては、ガントチャートが有料プランだけの機能になっているものもあります。料金は改定されることがあるので、導入する前に必ず公式の料金ページで最新の内容を確かめましょう。

無料から試せるプロジェクト管理の選択肢

ここまでの手順でWBSができあがると、次は「作ったWBSをどこで管理するか」を決めることになります。Excelのまま進めるのも1つの方法ですが、5人前後のチームで、ガントチャートやカレンダーも見ながら進めたい場合の候補の1つとして、Pinatecaがあります。

公式の料金ページによると、Pinatecaのフリープランは5人まで・ボード10個までで、期限なしの無料です。クレジットカードの登録は要りません。無料プランの範囲で、カンバン・ガントチャート・カレンダー・リストなど全8種類のボードと、チャット・コメント・受信箱、カスタムフィールドが使えると書かれています。ファイル容量は1GBです。WBSで分けた作業をカードにし、期限を入れてガントチャートのボードで並べる、という使い方ができます。

6人目、または11個目のボードからはスタンダードプランになり、料金は1人あたり月額500円（年払いなら1人あたり月額400円）で、表示価格は税抜です。閲覧だけのゲストは人数に数えないと明記されています。発注者に進み具合を見てもらう用途なら、人数を抑えながら共有できます。

まずは無料の範囲で、この記事の手順で作ったWBSを1つ登録し、更新のしやすさを確かめるのが確実です。

Pinatecaは、@SOHOを運営する株式会社ライフスケープが開発・提供しています。

WBSを作れる人が受託の仕事で強い理由

最後に、WBSを作る力が、働き方や収入とどうつながるのかを整理しておきます。

業務委託で仕事を受けるとき、見積もりの根拠を示せるかどうかは単価に直結します。「この案件は40万円です」とだけ伝えるより、「作業はこの30項目で、合計でこれだけの時間がかかるので、この金額です」と示せるほうが、発注者は納得しやすくなります。追加の要望が出たときも、WBSにない作業だと示せれば、追加の費用を相談しやすくなります。

AIを使った業務改善の提案でも、同じ力が求められます。AIに任せる作業と人が担う作業を分けるには、まず業務を細かい作業に分解する必要があるからです。こうした仕事の中身はAIコンサル・業務活用支援のお仕事にまとまっています。開発の案件を受ける人はアプリケーション開発のお仕事で仕事の種類を確かめられます。

収入の目安は、ソフトウェア作成者の年収・単価相場で公的な統計をもとにした数字を確認できます。開発の現場では、作業を分解して見積もれる人ほど、上流の工程（要件定義やプロジェクト管理）を任されやすく、単価の高い案件に近づきます。業務の分析や改善の提案を体系的に学びたい人には、中小企業診断士の試験範囲も参考になります。

フリーランス・在宅ワークの市場を20年運営してきた立場から言えば、長く続く人ほど、最初の見積もりと範囲の合意に時間をかけています。WBSは、その合意を目に見える形にする道具です。仲介の手数料が乗らない直接取引では、発注する側は同じ予算でより多くを頼め、受ける側は手取りが厚くなります。その関係を続けるうえでの土台は、「何をどこまでやるか」を最初にそろえておくことです。

WBSは、一度作り方を身につければ、どの案件にも使い回せます。次の案件では、作業から書き始める前に、成果物の一覧を作るところから始めてみてください。

よくある質問

Q. WBSとガントチャートは何が違いますか？

WBSは、プロジェクトに必要な作業を階層に分けて全部書き出した一覧で、作業の漏れを防ぐためのものです。ガントチャートは、その作業に期間を付けて横棒で並べた図で、日程と作業の重なりを見るためのものです。順番としては、WBSで作業を出し切ってから、期間と担当を付けてガントチャートに展開します。

Q. WBSはどこまで細かく分ければよいですか？

1つの作業を1人の担当者が完結でき、見積もりが数時間から数日に収まり、完了したかどうかを誰でも判断できる単位が目安です。それ以上分けても担当や日程の判断が変わらないなら、そこで止めます。先の作業は大きなかたまりのままにして、近づいてから細かくするローリングウェーブの進め方も有効です。

Q. WBSの作り方で、作業の漏れを防ぐコツはありますか？

作業から書き始めず、プロジェクトが終わったときにできあがっているもの（成果物）を先に全部書き出すことです。そのうえで、下の作業を全部終えたら上の成果物が完成するかを確かめます。発注者の確認と修正の作業、キックオフや引き継ぎなど前後の作業、定例の打ち合わせなどの管理の作業は抜けやすいので、意識して入れます。

Q. WBSはExcelで作っても問題ありませんか？

小規模で関わる人が少ない案件なら、Excelやスプレッドシートで十分です。列を階層番号、作業名、担当、見積もり、開始日、終了日、完了の条件、状態にすると扱いやすくなります。関わる人が増えてファイルの版が分からなくなる、毎日状態を更新したい、といった場面ではプロジェクト管理のツールに移すと楽になります。