スプレッドシートで使えるWBSテンプレートと、更新が追いつかなくなる理由

2026年3月26日

＠SOHO編集部

この記事のポイント

✓WBSのテンプレートをスプレッドシートで作るときに入れる列
✓関数と条件付き書式で進捗を見える化する手順
✓表の更新が追いつかなくなる理由と対処

WBSのテンプレートをスプレッドシートで用意しようとしている人の多くは、「とりあえず形のある表がほしい」「チームで同じ表を見ながら進めたい」という段階にいます。結論から言うと、スプレッドシートのWBSは、列の設計と更新のルールさえ決めておけば、数人から10人程度のプロジェクトなら十分に回ります。一方で、作った直後はきれいでも、2週間ほどで実態と表がずれ始めるのもよくある話です。

この記事では、WBSのテンプレートに入れる列、Googleスプレッドシートで作る手順と関数、進捗の見える化のしかたを具体的に紹介したうえで、表の更新が追いつかなくなる理由と、そうなったときの対処までを順に整理します。開発の現場でWBSを作っては崩してきた経験から、テンプレートを選ぶ前に知っておきたいことを中心に書きます。

WBSとは何か、なぜスプレッドシートで作る人が多いのか

WBSは「Work Breakdown Structure」の略で、日本語では作業分解構成図と呼ばれます。言い換えると、プロジェクトで成し遂げたいことを、担当者が1人で手を動かせる大きさの作業まで、上から順に分けていった一覧表のことです。たとえば「コーポレートサイトの改修」という大きな目標を、「要件定義」「デザイン」「実装」「テスト」「公開」に分け、さらに「実装」を「トップページ」「お問い合わせフォーム」「お知らせ一覧」に分けていきます。

よく混同されるのがガントチャートとの違いです。WBSは「どんな作業があるか」を洗い出した一覧で、ガントチャートは「その作業をいつからいつまでやるか」を横棒で表した日程表です。順番としては、先にWBSで作業を洗い出し、そこに日付を入れてガントチャートにします。スプレッドシートでは、この2つを1枚の表の左右に並べて作ることが多く、テンプレートの多くもその形になっています。

WBSがあると、抜けている作業に気づきやすくなり、誰が何をいつまでにやるかを全員が同じ表で確認できます。見積もりの根拠にもなるので、発注する側と受ける側の認識のずれを減らす効果もあります。

では、なぜ専用のプロジェクト管理ツールではなく、スプレッドシートで作る人が多いのでしょうか。理由は大きく3つあります。

1つ目は、追加の費用がかからないことです。Googleスプレッドシートは、Googleアカウントがあれば無料で使えます。Excelも、多くの会社ですでに導入されています。新しいツールを入れるための稟議や、社外メンバーのアカウント発行の手間がいりません。

2つ目は、誰でも触れることです。表計算ソフトは、エンジニアでも営業でも、ほとんどの人が一度は使ったことがあります。新しいツールの操作を覚えてもらう必要がないのは、社外のメンバーやパートナー企業を含むプロジェクトでは大きな利点です。

3つ目は、形を自由に変えられることです。列を追加したり、色を変えたり、関数で集計したりと、自分たちの進め方に合わせて表を育てられます。

ただし、この「自由に変えられる」ことが、あとで更新が追いつかなくなる原因の1つにもなります。この点は後半で詳しく見ていきます。

スプレッドシートのWBSテンプレートに入れる列

テンプレートを探す前に、どんな列が必要かを決めておくと、選ぶときに迷いません。ネットで配布されているテンプレートは、列が多すぎて使いこなせないものと、少なすぎて進捗が分からないものに分かれがちです。開発の現場で実際に使ってきた経験から、最低限入れておきたい列を表にしました。

列の名前	入れる内容	ないと困ること
WBS番号	1、1.1、1.1.1のような階層番号	親と子の関係が分からなくなる
作業名	動詞で終わる具体的な作業	何をすれば終わりか曖昧になる
担当者	1つの作業に1人	誰も手をつけない作業が出る
開始予定日	作業を始める日	日程の重なりが見えない
終了予定日	作業を終える日	遅れに気づけない
工数	人日や時間	見積もりと実績を比べられない
進捗率	0%、50%、100%など	全体がどこまで進んだか分からない
ステータス	未着手、進行中、完了、保留	止まっている作業を探せない
備考	前提条件や関連する資料の場所	判断の経緯が残らない

この9列が基本形です。ここに、プロジェクトの性格に応じて「依存する作業」「実績の開始日と終了日」「成果物」などの列を追加していきます。

注意したいのは、最初から列を増やしすぎないことです。列が多いほど、1つの作業を更新するたびに見直す項目が増えます。更新の手間が増えると、更新されない表になります。私が以前参加した案件では、最初に20列近いWBSを作った結果、担当者が「進捗率」だけを書き換え、「実績の終了日」や「残工数」は誰も触らなくなりました。結局、半分以上の列が空欄のまま放置され、表の信頼性そのものが落ちました。

列を決めるときは、「この列は週に1回、誰が更新するのか」を1つずつ確認すると、本当に必要な列だけが残ります。更新する人を決められない列は、最初から作らないほうが表は長持ちします。

Googleスプレッドシートでテンプレートから作る手順

ここからは、Googleスプレッドシートを使ってWBSを作る手順を紹介します。ゼロから作ることもできますが、テンプレートを土台にすると、見た目を整える時間を短くできます。

手順1は、テンプレートを選ぶことです。Googleスプレッドシートを開き、新規作成の画面からテンプレートギャラリーを表示すると、プロジェクト管理向けのひな形が並んでいます。実務では、タスクの一覧とガントチャート風の日付欄が最初から用意されているものを選ぶと、手直しが少なく済みます。配布サイトのテンプレートを使う場合も、前の節の9列がそろっているかを確認してから選びます。

手順2は、列をプロジェクトに合わせて整えることです。不要な列は削除し、足りない列は追加します。このとき、列の順番は「番号、作業名、担当者、日付、進捗」の順にしておくと、左から右へ目で追うだけで状況がつかめます。

手順3は、作業を上から分解して書き出すことです。いきなり細かい作業から書くと抜けが出やすいので、まず大きな工程を5個から7個程度書き、それぞれを分けていきます。

手順4は、担当者と日付を入れることです。担当者の列には、データの入力規則でプルダウンを設定しておくと、表記ゆれを防げます。「田中」「田中さん」「たなか」が混ざると、担当者ごとの集計ができなくなるからです。

手順5は、共有の設定をすることです。全員に編集権限を渡すと、うっかり列や関数を消されることがあります。関数の入った列や見出しの行は、保護されたシートと範囲の機能で編集できる人を限定しておくと安心です。

ちなみに、スプレッドシートの範囲を表形式（テーブル）に変換すると、行の追加や絞り込みがしやすくなります。表の見た目がそろうので、行が増えても読みやすさを保ちやすくなります。

作業の分け方を実例で確認する

テンプレートの列がそろっても、作業の分け方がうまくいかないとWBSは役に立ちません。ここでは、小さなWebサイトの改修を例に、上から順に分けていく流れを見てみます。

最初に、成果物の単位で大きな工程を書き出します。

要件の整理
デザイン
実装
テスト
公開と引き継ぎ

次に、それぞれの工程を「誰が、何を作れば終わりか」が分かる大きさに分けます。たとえば「3. 実装」は、次のように分けられます。

3.1 トップページのマークアップ
3.2 お知らせ一覧の表示と絞り込み
3.3 お問い合わせフォームの入力と送信
3.4 管理画面からのお知らせの登録
3.5 表示速度の調整

さらに「3.3 お問い合わせフォーム」が大きいと感じたら、「入力欄の作成」「入力内容の確認画面」「送信後のメール通知」「迷惑な送信の対策」のように、もう一段分けます。どこまで分けるかの目安は、担当者が見積もりを出せるかどうかです。「フォームを作る」では何日かかるか答えにくくても、「入力内容の確認画面を作る」なら、1日か2日かの見当がつきます。

分けるときのコツは、作業名を動詞で終えることです。「お問い合わせフォーム」ではなく「お問い合わせフォームの送信処理を作る」と書くと、何をすれば完了かがはっきりします。もう1つのコツは、成果物が残る作業と、打ち合わせや確認のような成果物が残らない作業を分けて書くことです。確認の作業を書き忘れると、実装は予定どおりでも、確認待ちで全体が遅れる原因になります。

最後に、親の工程の工数が、子の作業の工数の合計と合っているかを確認します。合っていなければ、どこかの作業が抜けているか、見積もりが甘い可能性があります。この突き合わせを最初にしておくだけで、見積もりのずれをかなり減らせます。

関数で日付と進捗を自動で計算する

WBSの更新の手間を減らす一番の方法は、人が入力する項目を減らし、計算で出せるものは関数に任せることです。ここでは、Googleスプレッドシートでそのまま使える関数の例を紹介します。列の配置は、A列がWBS番号、B列が作業名、C列が担当者、D列が開始予定日、E列が終了予定日、F列が工数（日）、G列が進捗率、H列がステータスという前提です。

まず、開始日と工数から終了予定日を出す式です。土日を除いた営業日で計算したい場合は、WORKDAY関数を使います。

=WORKDAY(D2, F2 - 1)

祝日も除きたいときは、祝日の一覧を別のシートに作り、3つ目の引数にその範囲を指定します。

次に、進捗率からステータスを自動で決める式です。今日の日付と終了予定日を比べ、遅れている作業を目立たせます。

=IF(G2>=1, "完了", IF(AND(G2<1, TODAY()>E2), "遅延", IF(G2>0, "進行中", "未着手")))

この式を入れておくと、担当者は進捗率だけを更新すればよくなり、ステータスの書き換え忘れがなくなります。

プロジェクト全体の進捗率は、工数で重みづけして計算すると実態に近くなります。

=SUMPRODUCT(F2:F100, G2:G100) / SUM(F2:F100)

単純に作業の数で割ると、1時間で終わる作業も10日かかる作業も同じ重さで数えてしまいます。工数で重みをつけるだけで、「作業の数では8割終わっているのに、実際の残りは半分以上」というずれに早く気づけます。

最後に、担当者ごとの残りの作業数を数える式です。

=COUNTIFS(C2:C100, "田中", H2:H100, "<>完了")

担当者ごとの数を並べると、特定の人に作業が偏っていないかがひと目で分かります。

条件付き書式でガントチャート風に見える化する

WBSの表の右側に日付の列を並べ、条件付き書式で塗りつぶすと、ガントチャートのような見た目にできます。Googleの公式ヘルプでは、条件付き書式について次のように説明されています。

条件付き書式を設定して、特定の条件（例: 特定の単語や数字を含む）を満たすセル、行、列のテキストや背景色を変更することができます。出典: support.google.com

具体的には、1行目のJ列から右に日付を並べ、2行目以降の範囲を選んで、カスタム数式で次のルールを設定します。

=AND(J$1>=$D2, J$1<=$E2)

これで、開始予定日から終了予定日までのセルに色がつきます。ドルマークの位置が大事で、日付の行は「J$1」で行を固定し、開始日と終了日は「$D2」「$E2」で列を固定します。ここを間違えると、色が斜めにずれて表示されます。

さらに、今日の列だけ縦に色をつけるルールも追加しておくと、遅れている作業が分かりやすくなります。

=J$1=TODAY()

親タスクの行を色分けしたい場合は、WBS番号に小数点を含まない行だけを対象にするルールを作ります。たとえばA列の番号に「.」が含まれない行を太字と薄い背景色にすると、大きな工程の区切りが見やすくなります。

ただし、条件付き書式のルールは、増えるほど管理が難しくなります。誰かが行をコピーして貼り付けたときに、ルールの適用範囲が分割されて、同じようなルールが何十個も並んでしまうこともあります。ルールは3個から5個程度にとどめ、誰がどのルールを作ったかを備考のシートに残しておくと、あとから直す人が困りません。

スプレッドシートでWBSを管理するメリット

ここまでの内容を踏まえて、スプレッドシートでWBSを管理するメリットを改めて整理します。

1つ目のメリットは、費用がかからず、すぐに始められることです。テンプレートを開いてから作業を書き出すまで、早ければ30分ほどで形になります。小さな案件や、プロジェクト管理の方法がまだ固まっていないチームにとって、この始めやすさは大きな価値です。

2つ目のメリットは、社外の人とも共有しやすいことです。Googleスプレッドシートなら、共有リンクを送るだけで相手のブラウザで開けます。業務委託のメンバーや取引先に、新しいツールのアカウントを作ってもらう必要がありません。

3つ目のメリットは、集計と加工の自由度です。工数の合計、担当者ごとの負荷、見積もりと実績の差など、関数を使えば欲しい数字をその場で出せます。見積書や請求書の根拠として、工数の集計を別のシートに転記するのも簡単です。

4つ目のメリットは、変更の履歴が残ることです。Googleスプレッドシートには版の履歴の機能があり、誰がいつどこを変えたかを後から確認できます。誤って消してしまった行も、以前の版から戻せます。

5つ目のメリットは、ほかの資料とつなげやすいことです。要件の一覧や課題の一覧を同じファイルの別シートに作り、WBSの作業と番号で結びつけておけば、1つのファイルでプロジェクトの全体を追えます。

これらのメリットが生きるのは、関わる人数が少なく、作業の数が数十個程度に収まるプロジェクトです。この範囲なら、専用ツールより速く、安く回せることも珍しくありません。

テンプレートを選ぶときに見るポイント

配布されているWBSのテンプレートは数多くあり、見た目だけで選ぶと、使い始めてから困ることがあります。選ぶときに確認しておきたいポイントを挙げます。

1つ目は、階層の表し方です。WBS番号の列で階層を表すもの、インデント（字下げ）で表すもの、親の行に色をつけるものなど、いくつかの方式があります。並べ替えや絞り込みをしても階層が分かるのは、番号の列を持つ方式です。インデントだけで階層を表すテンプレートは、絞り込むと親子の関係が分からなくなります。

2つ目は、日付の欄の作り方です。ガントチャート風の日付欄が1日単位で横に長く並んでいるテンプレートは、3か月を超えるプロジェクトでは列が100を超え、画面の横移動が大変になります。期間が長いプロジェクトなら、週単位の日付欄を持つものを選ぶか、自分で週単位に作り直します。

3つ目は、関数が見える形で入っているかです。セルの中に複雑な式が隠れているテンプレートは、どこかを直したときに計算が壊れても気づきにくいものです。関数の入った列が分かるように色や見出しで区別されているもの、または自分で式を読めるものを選ぶと、あとで直しやすくなります。

4つ目は、印刷や書き出しを想定しているかです。取引先に進み具合を報告するときに、PDFで渡す場面があります。印刷の範囲や改ページが考えられていないテンプレートは、書き出すと表が途中で切れます。

5つ目は、自分たちの言葉に直せるかです。テンプレートの列名が英語のままだったり、業界の用語が多かったりすると、チームのメンバーが入力をためらいます。列名を自分たちが普段使う言葉に直してから配ると、入力の抵抗が小さくなります。

テンプレートは完成品ではなく、たたき台です。この5つを確認して、手を入れやすいものを選ぶと、長く使える表になります。

更新が追いつかなくなる理由

一方で、スプレッドシートのWBSには、時間がたつほど表と実態がずれていくという弱点があります。理由は1つではなく、いくつかの要因が重なって起きます。

1つ目の理由は、更新が「わざわざ開いて書き換える作業」になっていることです。担当者が実際の作業を進めているのは、エディタやデザインツール、チャットの中です。WBSの表は、その作業とは別の場所にあります。作業が終わったあとに表を開いて進捗率を書き換えるのは、忘れやすい二度手間です。

2つ目の理由は、会話と表が分かれていることです。仕様の変更や作業の追加は、多くの場合チャットや会議の中で決まります。決まった内容を誰かが表に反映しない限り、表は古いままです。「あの件はチャットで決まったはず」と表の外を探す時間が増えるほど、表は見られなくなります。

3つ目の理由は、予定の変更が連鎖することです。1つの作業が3日遅れると、その後に続く作業の開始日もずれます。スプレッドシートでは、依存関係を自動でたどって日付を動かす仕組みは標準ではないので、後続の行を手で1つずつ直すことになります。作業が50行を超えるあたりから、この手直しが大きな負担になります。

4つ目の理由は、人数が増えると書き換えがぶつかることです。複数の人が同時に同じ行を直したり、誰かが並べ替えをしたりすると、意図しない上書きが起きます。版の履歴で戻せるとはいえ、戻すべき版を探すのにも時間がかかります。

5つ目の理由は、表が育ちすぎることです。最初は9列だった表に、要望のたびに列やシートが追加され、関数や条件付き書式が複雑になっていきます。作った人しか直せない表になると、その人が忙しくなった時点で更新が止まります。

私自身、受託開発の案件で、立ち上げ時にきれいなWBSを作ったのに、3週目にはチャットのスレッドのほうが正しい状態になっていた経験があります。原因を振り返ると、表を更新する担当者を決めていなかったことと、変更をチャットで決めて表に戻すルールがなかったことでした。表の作り方より、更新の仕組みのほうが大事だと痛感した出来事です。

表が古くならないための運用ルール

更新が追いつかなくなる理由が分かれば、対策も見えてきます。スプレッドシートのまま続ける場合に効果があった運用ルールを紹介します。

まず、更新する日と時間を決めます。たとえば「毎週月曜日の朝会の前に、各自が自分の行を更新する」と決め、朝会ではWBSの表を画面共有しながら進めます。表を見ながら話す場が毎週あれば、更新しないと会議で困るので、自然と更新されます。

次に、変更を表に戻す担当を決めます。チャットや会議で決まったことを表に反映する役割を、プロジェクトの管理者か、その週の当番に割り当てます。誰の仕事でもない作業は、誰もやりません。

3つ目に、人が入力する列を絞ります。関数の節で紹介した式を使い、ステータスや全体の進捗率は自動で出るようにして、担当者が触るのは「進捗率」と「備考」だけにします。入力する項目が2つなら、1行の更新は10秒で終わります。

4つ目に、作業の粒度をそろえます。1つの作業が2週間以上かかるような大きさだと、進捗率が「50%」のまま何日も動かず、遅れに気づけません。目安として、1つの作業は1日から5日程度で終わる大きさに分けると、進み具合が週単位で見えるようになります。

5つ目に、終わった作業は別のシートに移すか、フィルタで隠します。完了した行が増えるほど、まだ終わっていない作業が埋もれて見えにくくなるからです。

6つ目に、保留の作業の扱いを決めます。相手の返事待ちや、別の作業が終わるのを待っている作業は、ステータスを「保留」にして、備考に「何を待っているか」と「いつ確認するか」を書きます。保留の理由が書かれていない作業は、誰も追いかけないまま期限を過ぎてしまいがちです。週に1回の確認の場で、保留の行だけを絞り込んで見る時間を数分とるだけでも、止まったままの作業を減らせます。

これらのルールを入れても、作業の数が100行を超えたり、関わる人が10人を超えたりすると、スプレッドシートだけでは手が回らなくなってきます。その段階が、専用ツールを検討する目安です。

実績を記録して次の見積もりに生かす

WBSは、プロジェクトの最中に進み具合を見るためだけの表ではありません。終わったあとに見返すと、次のプロジェクトの見積もりの精度を上げる材料になります。そのために、予定の列とは別に「実績の工数」の列を1つだけ追加しておくことをおすすめします。

使い方は簡単です。作業が完了したら、担当者がかかった日数や時間を実績の列に入力します。予定の工数と実績の工数の差を出す列を関数で作っておけば、どの作業が見積もりより膨らんだかがひと目で分かります。

=IF(I2="", "", I2 - F2)

プロジェクトが終わったら、差の大きかった作業を並べて、理由を備考に1行ずつ書いておきます。「仕様の確認に時間がかかった」「外部のサービスとの連携の調査が想定より長かった」といった理由は、次に似た作業を見積もるときの貴重な手がかりになります。

私が開発の案件でこの記録を続けてみて分かったのは、見積もりがずれるのは実装そのものより、確認待ちや調査の時間だということでした。WBSに「確認」「調査」の作業をあらかじめ書いておくようにしてから、見積もりと実績の差は目に見えて小さくなりました。

実績の記録は、受ける側にとっては見積もりの根拠として、依頼する側にとっては予算の見通しとして役立ちます。毎日つける必要はなく、作業が完了したときに1回入力するだけで十分です。人が入力する列が1つ増えることになりますが、その代わりに次のプロジェクトの計画が楽になるので、手間に見合う価値があります。

専用のプロジェクト管理ツールに移る目安

スプレッドシートで続けるか、専用ツールに移るかは、次のような状態がいくつ当てはまるかで判断できます。

状態	スプレッドシートで続ける	専用ツールを検討する
関わる人数	5人前後まで	10人を超える
作業の数	数十個	100個を超える
予定の変更	月に数回	毎週のように発生する
会話の場所	会議で十分	チャットで日々決まる
社外メンバー	閲覧が中心	一緒に更新する

専用ツールに移る利点は、作業のカードとコメント、期限の通知が1か所にまとまることです。作業の画面で話したことがそのまま残るので、「表の外で決まったことを表に戻す」手間がなくなります。ガントチャートの棒をドラッグすれば日付が変わるツールなら、予定の変更も表を1行ずつ直すより短時間で済みます。

一方で、専用ツールにも注意点があります。多くのツールは、ガントチャートやカスタムの項目を有料プランに限っています。たとえばTrelloの公式の料金ページでは、無料のFreeプランはワークスペースあたり10人のコラボレーターと10枚のボードまでで、タイムラインやカレンダーの表示はPremiumプランの機能として案内されています。Asanaの料金ページでも、タイムラインとガントの表示はStarterプラン以上の機能で、無料のPersonalプランはユーザー2人までと書かれています。Backlogは、2027年1月1日からプランを改定し、フリープランのユーザー上限を10名から5名に変えると公式ブログで告知しています。

ツールを選ぶときは、「無料でどこまで使えるか」だけでなく、「自分たちが使いたい表示が、どのプランから使えるか」を料金ページで確かめておくと、移ってから困りません。

表の更新が負担になったときの候補

スプレッドシートのWBSから移るときの候補の1つが、国産のプロジェクト管理ツールのPinatecaです。公式の料金ページによると、フリープランは5人まで、ボード10個までで、期限なく無料で使え、クレジットカードの登録も要りません。無料の範囲でも、カンバン、ガント、カレンダー、リストなど8種類のボードと、チャット、コメント、カスタムフィールド、権限ロールが使えると案内されています。ガントのボードでは、カードの期間が横棒で並び、バーをドラッグすると開始日も締切もその場で変わります。6人目、または11個目のボードからはスタンダードプランで、1人あたり月額500円（税抜、年払いなら1人あたり月額400円）です。

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

なお、移ったからといって、スプレッドシートを完全にやめる必要はありません。工数の集計や見積もりの計算はスプレッドシートで続け、日々の作業の進み具合と会話だけを専用ツールに移す、という分け方も十分に成り立ちます。WBSの作業の分け方そのものは、どちらのやり方でも同じように役立ちます。

WBSが作れる人に頼まれる仕事と、運営者が見てきたこと

最後に、WBSを作る力を仕事の面から見てみます。WBSは、プロジェクトの全体を見渡して作業に分ける力そのものです。この力は、エンジニアやディレクターだけでなく、業務改善の支援や、社内のIT化を手伝う仕事でも求められます。

フリーランスや在宅ワークの市場を長く運営してきた立場から見ると、継続して依頼を受ける人ほど、作業そのものより「進め方を見える形にする」ことに時間を使っています。WBSを最初に共有し、週に1回進み具合を報告するだけで、依頼する側の安心感は大きく変わります。発注する側と受ける側が直接やり取りする形なら、中間のマージンが乗らない分、同じ予算でより多くの作業を頼め、受ける側の手取りも厚くなります。進め方が見える人ほど、そうした直接の関係を長く続けやすいというのが、運営者として見てきた実感です。

開発の仕事でWBSを作る機会が多いのは、アプリやシステムの受託開発です。どんな仕事があるかはアプリケーション開発のお仕事で、職種ごとの報酬の水準はソフトウェア作成者の年収・単価相場で確認できます。生成AIを業務に取り入れる支援の仕事でも、導入の手順をWBSに分けて提案する場面が増えています。その内容はAIコンサル・業務活用支援のお仕事で紹介しています。

また、中小企業の業務改善を体系的に学ぶ方法の1つに、経営の診断と助言を行う国家資格があります。試験の範囲には業務の流れを整理する考え方も含まれるので、プロジェクトの進め方を仕事の強みにしたい人は中小企業診断士の内容も確認してみてください。テレワークで複数のメンバーとプロジェクトを進める会社向けの支援制度は、テレワーク助成金 2026で整理しています。

スプレッドシートのWBSは、作ることよりも、使い続けることのほうが難しい道具です。列を絞り、関数に任せ、更新の時間と担当を決める。この3つを押さえておけば、テンプレートはどれを選んでも、チームの役に立つ表になります。

よくある質問

Q. WBSのテンプレートはスプレッドシートとExcelのどちらで作るのがよいですか？

社外のメンバーと同じ表を見ながら進めるなら、共有リンクを送るだけでブラウザで開けるGoogleスプレッドシートが扱いやすいです。社内だけで使い、すでにExcelで見積もりや工数の集計をしているなら、Excelで作ると既存の資料とつなげやすくなります。どちらでも、列の設計と更新のルールの考え方は同じです。

Q. WBSの作業はどのくらいの細かさまで分ければよいですか？

目安は、1人の担当者が1日から5日程度で終えられる大きさです。2週間以上かかる大きさのままだと進捗率が長く動かず、遅れに気づくのが遅れます。反対に、数時間で終わる作業まで細かくすると行数が増えすぎて、更新の手間が大きくなります。大きな工程を5個から7個に分け、そこから順に分けていくと抜けが出にくくなります。

Q. スプレッドシートのWBSの更新を忘れないようにするにはどうすればよいですか？

週に1回、WBSの表を画面に映しながら進み具合を確認する場を設けるのが効果的です。あわせて、担当者が入力する列を進捗率と備考の2つ程度に絞り、ステータスや全体の進捗率は関数で自動計算にすると、1行の更新が短時間で終わります。会議やチャットで決まった変更を表に反映する担当者を決めておくことも大切です。