GoogleスプレッドシートでつくるWBS｜無料テンプレ＆運用手順を徹底解説【小中規模プロジェクト向け】

「『WBSを作れ』と言われて形だけ整えたものの、管理は止まり、遅れが出ても気づけない」——小〜中規模のITプロジェクトでは、この状態が炎上の火種になります。Googleスプレッドシートなら共同編集・変更履歴・権限管理を活かして、更新が続くWBSを無料で組めます。本記事ではテンプレをコピーしてそのまま作る手順、タスク分解を生成AIに下書きさせる方法、専用ツールへ移すべき判断基準を整理し、AI経営総合研究所が​独自に取材した先行企業の活用実態​も交えて、運用が止まらない設計まで解説します。

タスク管理表そのものの作り方から確認したい方は、スプレッドシートでタスク管理表を作る手順から読み進めてください。

弊社では、生成AIの運用成功に役立つ資料を配布しています。導入設計やリスク対策、プロンプトの考え方が分かる内容です。AIでタスク管理を効率化するヒントになる内容ですので、興味のある方はぜひご覧ください。

スプレッドシートがWBS管理に向いている理由

Googleスプレッドシートは、共同編集・変更履歴・権限設定の3つが標準で揃っています。仕様変更が頻発する小〜中規模プロジェクトでは、この「軽く直せる」性質がタスク漏れと遅延の検知精度を左右します。

向いている理由は、次の3点に集約されます。

• ​同時編集で最新版が1つに固定される​​：メール添付でのバージョン違いが発生しません
• ​変更履歴で「誰がいつ何を変えたか」が残る​​：更新責任の所在が曖昧になりません
• ​権限を閲覧・コメント・編集に分けられる​​：全員編集による事故を防げます

Excelとの違い｜共同編集・履歴管理・権限設定がプロジェクト管理に効く

ExcelでのWBS管理は、編集ミスやバージョン違いが起きやすい一方、スプレッドシートならリアルタイムの同時編集ができます。「誰がいつ変更したのか」が残る履歴管理によって責任の所在が曖昧にならず、共有リンクだけで最新データにアクセスできるため、社内外のメンバーが関わる案件でもスムーズに進行します。閲覧のみ／コメントのみ／編集可能といった権限の細分化ができる点も、進行管理に直結します。

さらに実務で効くのは、範囲単位の保護です。数式が入った列だけを編集不可にできるため、「担当者が期間の計算式を上書きして集計が壊れる」という典型的な事故を構造的に防げます。

小〜中規模プロジェクトに最適化される理由

仕様変更や追加タスクが発生しやすいプロジェクトでは、WBSの更新頻度が高まります。スプレッドシートは軽く・早く・いつでも修正できるため、変更に強い構造を作れます。専用ツールの導入コストや慣れにくさを回避でき、既存のGoogleアカウント環境で即日始められることから、初めてWBSを運用するチームにも最短ルートでフィットします。

WBSとガントチャートの違い｜役割を分けると管理表が二重にならない

WBSは作業を漏れなく分解する構造図、ガントチャートは分解した作業を時間軸に並べる工程表です。役割を分けずに1枚のシートへ詰め込むと、タスクの追加漏れと日付のズレが同時に起きて、どちらの情報が正しいのか判別できなくなります。

観点	WBS	ガントチャート
目的	作業を漏れなく分解する	分解した作業を時間軸に並べる
見えるもの	成果物とタスクの親子関係、完了条件	開始日・終了日・作業の重なり・遅れ
更新のきっかけ	要件変更、タスクの追加・削除	日付の変更、進捗実績の入力
作る順番	先に作る	WBSが固まってから作る
スプレッドシートでの実装	行と階層番号、完了条件列	条件付き書式またはタイムラインビュー

ガントチャート側の作り方を先に押さえたい場合は、ガントチャートの基本と無料で使えるツールをあわせて確認してください。

WBSは作業の分解図、ガントチャートは時間軸への翻訳

WBSで決めるのは「何をどこまで作れば完了か」です。日付は入っていても主役ではありません。一方、ガントチャートで決めるのは「いつ着手し、どこで重なり、どこが遅れているか」です。

この分担が曖昧なままだと、タスク追加のたびにガントチャートを作り直す作業が発生し、更新が止まります。WBSを正本とし、ガントチャートはその表示形式のひとつとして扱う——この順序を固定すると、更新箇所が常に1か所に収まります。

WBSの2つの型｜成果物型と工程型を混ぜない

WBSの第1階層には、2つの置き方があります。

• ​成果物型​​：要件定義書、設計書、テスト報告書のように、納品・検収の単位を第1階層に置きます。抜け漏れに強く、検収範囲とWBSが一致します
• ​工程型​​：要件定義、設計、開発、テストのように、工程を第1階層に置きます。工程が定型化した社内プロジェクトで扱いやすい形です

外部への納品と検収がある案件は成果物型を選びます。両者を混在させると、同じ作業が「設計書」と「設計工程」の2か所に現れ、進捗が二重計上されます。プロジェクト開始時にどちらの型で組むかを1行決めておくだけで、後工程の混乱を防げます。

WBSを作る前に押さえる準備｜タスク漏れと遅延を防ぐ設計の基本

スプレッドシートを開く前に、タスクの洗い出し・階層構造・依存関係の3点を紙の上で固めます。この順序を飛ばして表から作り始めると、列の追加とタスクの差し込みが同時に発生し、序盤で構造が崩れます。

タスク洗い出しの4ステップ｜洗い出す→並べる→構造化する→担当を決める

準備工程は、次の4ステップに分けると迷いません。

1. ​洗い出す​​：成果物ベースで思いつく限り書き出します。この時点では順番も粒度も揃えません
2. ​並べる​​：時系列に並べ替え、他タスクの完了を待つものを後ろへ移します
3. ​構造化する​​：親子関係を付け、後述の100%ルールで抜けを埋めます
4. ​担当を決める​​：1タスク1担当を原則とし、共同作業は主担当を1名指定します

4ステップを分けると、「洗い出しの途中で担当者の都合を考えて手が止まる」という停滞がなくなります。洗い出しと判断を同じ時間に混ぜないことが、抜け漏れを減らす最短ルートです。

100%ルールと階層構造｜抜け漏れを起こさないタスク分解の軸

WBSでは、上位タスクが下位タスクの100%の集合になるよう分解します。これが「100%ルール」です。目的が曖昧な粒度のまま分解を進めると、担当者が迷い、完了条件も曖昧になります。まず成果物ベースで上位タスクを定義し、その後に作業単位へ階層を掘り下げます。タスクの完了形が明確になっているかを基準に、誰が見てもブレない構造を作ります。

第3階層の作業は「1〜3営業日で終わる大きさ」を目安に揃えます。1日未満に刻むと更新負荷が上がり、1週間を超えると遅れの発見が遅くなります。

遅延の波及を抑える依存関係の整理

タスクは単発ではなく、必ず前後関係を持っています。依存関係を曖昧にしたままWBSを作ると、1つの遅れが全体に波及し、対処が後手に回ります。

着手条件や成果物の受け渡しタイミングを洗い出し、クリティカルパス（納期を決める重要経路）を見抜いておくことで、注意すべきタスクが一目で判断できます。遅延が発生しやすいポイントを事前に押さえておけば、管理の負担は大きく下がります。

スプレッドシートでWBSを作る手順【テンプレと連動してそのまま再現】

以下のテンプレートをスプレッドシートに貼り付け、プロジェクト単位でコピーして使います。9列の構成をそのまま使えば、タスクの親子関係・依存関係・完了条件が1枚で追える状態になります。

WBS番号	タスク名	担当	開始日	終了日	期間（日）	依存タスク	ステータス	完了条件
1	成果物A				=E2-D2+1		未着手	完了基準を記載
1.1	タスクA-1	〇〇			=E3-D3+1	1	作業中	レビュー完了
1.2	タスクA-2	〇〇			=E4-D4+1	1.1	未着手	テスト完了
2	成果物B				=E5-D5+1		未着手	完了基準を記載

※表は横にスクロールできます（スマートフォンでは9列すべてが画面に収まりません） ※Googleスプレッドシートで開き、「ファイル」→「コピーを作成」で利用できます ※ステータスに応じた色分け（条件付き書式）を設定すると視認性が上がります

スマートフォンで確認する場合は、最初の4列（WBS番号・タスク名・担当・終了日）だけを見れば、誰の作業がいつ終わる予定かは追えます。依存タスクと完了条件はPCでの更新時に使う列です。

列構成の設計｜管理に必要な情報を過不足なく揃える

WBSは情報が多すぎても、少なすぎても管理が破綻します。スプレッドシートで扱う最低限の列は、タスク名・WBS番号・担当者・開始日・終了日・期間（自動計算）・依存タスク・ステータス・完了条件の9つです。とくに完了条件の明文化は、「終わったと思ったのに終わっていない」というズレを防ぎます。情報を詰め込みすぎず、意思決定に必要な内容へ絞ることが、運用を止めない一番の近道です。

判断に使わない情報（議事メモ、参考リンク、細かい作業ログ）は別シートへ分離します。WBSの列が12を超えたら、横スクロールが発生して更新率が落ちるサインです。

インデントとWBS番号付与｜階層を視覚的に理解しやすくする

タスクを階層化する際は、シート上でも一目で上下関係が分かる構造に整えます。インデントを段階的に下げ、番号を「1」「1.1」「1.1.1」と付けることで、レビュー時にどの成果物へ紐づく作業かを瞬時に把握できます。結果として確認漏れが減り、メンバー間の認識齟齬も起きにくくなります。

自動化の設定｜数式で進捗と期間をブレなく管理する

手入力が多いほど、更新漏れや計算ミスが起きます。開始日と終了日を入力すれば期間（日）が自動計算される数式（例：=E2-D2+1）を設定し、進捗率や遅延を判断できる材料を揃えます。ステータスと連動した色分けを行うと、優先確認タスクが直感的に浮き上がり、判断スピードが上がります。

数式列は「範囲を保護」で編集者を限定します。全員が編集できる状態のままだと、上書きに気づくのは集計が合わなくなった後です。

コピーと共有設定｜配布前に決める3点

テンプレートを配る前に、次の3点を決めておきます。ここを曖昧にしたまま共有すると、原本が上書きされたり、社外メンバーに見せるべきでない情報が渡ったりします。

1. ​コピー方法​​：「ファイル」→「コピーを作成」でプロジェクトごとに複製します。原本はテンプレート専用として残し、直接編集しません
2. ​共有範囲​​：「リンクを知っている全員」と「指定したユーザーのみ」のどちらかを選びます。社外メンバーが入る案件は指定ユーザーのみとし、アクセス期限を設定します
3. ​保護範囲​​：数式列（期間）とWBS番号列は編集者を限定し、ステータス列と実績日列だけ全員編集可にします

3点を決めてから配布すれば、「誰でも直せる」と「壊れない」を同時に成立させられます。

生成AIでWBSのタスク分解と粒度チェックを下書きする

タスクの洗い出しと粒度チェックは、生成AIに下書きさせて人が削るほうが速く進みます。ゼロから列挙する作業は抜け漏れが出やすく、逆にAIの出力は網羅的だが冗長になるため、「AIが広げて人が絞る」分担が噛み合います。

ただしAIの出力をそのまま貼り付けると、実在しない工程や根拠のない工数が混ざります。使う範囲を「分解の下書き」と「レビュー」に限定し、日付と担当の確定は人が行います。

Before / After｜指示文1行と構造化プロンプトで出力がどう変わるか

Before（指示文1行）​

ECサイトのリニューアルプロジェクトのWBSを作って

返ってくるのは「要件定義／設計／開発／テスト／リリース」といった5行程度の工程一覧です。階層も完了条件も担当もないため、そのままシートに貼れません。

After（役割・前提・依頼・出力形式の4要素）​

# 役割
あなたは小規模ITプロジェクトのプロジェクトマネージャーです。

# 前提
・対象：自社ECサイトのリニューアル（商品数約300点、決済システムは既存のまま流用）
・期間：2026年8月1日〜10月31日
・体制：PM1名、デザイナー1名、エンジニア2名、外部制作会社1社

# 依頼
上記を成果物単位で第1階層に分解し、各成果物を1〜3営業日で終わる作業まで第3階層まで掘り下げてください。

# 出力形式
次の列を持つMarkdownの表で出力してください。
WBS番号 / タスク名 / 階層 / 想定担当 / 想定工数（人日） / 依存タスク（WBS番号） / 完了条件
・完了条件は「〜が承認された」「〜のテストが全件パスした」のように、第三者が判定できる表現で書いてください
・工数や担当が前提から判断できない項目は空欄にし、推測で埋めないでください

Afterでは、第3階層まで分解された表がそのままコピーできる形で返ります。「推測で埋めない」の1行を入れておくと、もっともらしい数字が勝手に入る事故を防げます。

分解プロンプトの型｜4要素をそろえる

プロンプトは、次の4要素で組み立てると出力が安定します。

• ​役割​​：どの立場で考えるかを指定します（PM、品質保証担当など）
• ​前提​​：期間・体制・スコープ・除外範囲を書きます。ここが薄いと粒度がぶれます
• ​依頼​​：分解の軸（成果物型か工程型か）と、最小タスクの大きさを数値で指定します
• ​出力形式​​：シートの列名をそのまま並べます。列を指定すると転記工数がほぼゼロになります

WBS以外の用途は、そのまま使えるタスク管理プロンプト例から自社の業務に近いものを選べます。

粒度と抜け漏れをAIにレビューさせる

作成済みのWBSを貼り付けて、レビュー役として使う方法も効果が出ます。人のレビューでは「気になった行」しか見ませんが、AIは全行を同じ基準で走査します。

以下のWBSをレビューしてください。

1. 上位タスクと下位タスクの範囲がずれている箇所（100%ルール違反）
2. 1つのタスクに複数の成果物が混ざっている箇所
3. 完了条件が「対応する」「進める」など、第三者が判定できない表現になっている箇所
4. 依存関係が抜けていて、前工程の完了を待つはずの箇所

指摘は「WBS番号 / 問題 / 修正案」の3列の表で出力してください。該当がない項目は「該当なし」と書いてください。

【WBS】
（ここに表を貼り付け）

「該当なしと書いてください」を入れると、無理に問題を作り出す出力を抑えられます。

使う前に決める2つのルール｜機密情報と最終判断

社内で使う前に、次の2つを明文化します。

• ​入力してよい情報の範囲​​：顧客名、契約単価、未公開の製品名、個人情報は入れません。利用中のプランでデータが学習に使われるかどうかは、事前に管理部門と確認します
• ​最終判断は人が持つ​​：工数・担当・納期はAIの推測値をそのまま採用せず、担当者本人の見積りで上書きします

WBS作成に限らず、AIでタスク管理そのものを仕組み化する方法まで広げると、進捗確認や報告作成の手間も削れます。

ガントチャート連携｜遅延を即検知する視覚化

WBSはタスク構造を整理する土台ですが、そのままでは進捗の遅れが見えにくく、気づいた時には手遅れになりがちです。WBSとガントチャートを連携させると、現在地とリスクを直感的に把握でき、遅延対策を前倒しで打てます。

スプレッドシートでの実装ルートは、条件付き書式による手作りと、標準機能のタイムラインビューの2つです。

スプレッドシート標準機能でガントチャートを作成する方法

条件付き書式と期間データを組み合わせれば、追加ツールなしでガントチャートを作れます。開始日と日数に基づいて横方向に色を自動付与し、「いつ」「誰が」「どのタスクを」進めているのかがひと目で分かる管理表になります。

遅延が発生した場合は、終了日と実績を比較する仕組みにしておけば、色で逸脱が浮き上がり、優先対応すべきタスクを視覚的に検知できます。メンバー全員がブラウザだけで最新情報を共有でき、更新の停滞をなくせる点も利点です。

タイムラインビューを使う｜必須列とつまずきやすい2点

Googleスプレッドシートには、表からカード型の工程表を生成する「タイムラインビュー」が標準搭載されています。「挿入」→「タイムライン」からデータ範囲を選ぶだけで、条件付き書式を組まずに工程表が生成されます。

Google公式ヘルプによると、タイムラインビューの作成に必要な項目は次のとおりです。

区分	項目
必須	カードのタイトル／データ範囲／開始日（日付形式）／終了日（日付形式）
省略可	カードの色／カードの詳細／カードグループ

日付列に数式を使う場合は、出力が日付値になるようにします（文字列で返る場合はDATEVALUE関数で変換します）。また「終了日」の代わりに「期間」を指定すると週末が有効になり、「週末を含める」をオフにすれば週末を除いた表示に切り替えられます。

つまずきやすいのは次の2点です。

1. ​カードが1日分しか表示されない​​：日付の形式が日付として認識されていないか、開始日と終了日が同じ値になっています
2. ​カードの色を変更できない​​：ソースデータに条件付き書式を適用していると、カードの色を変更できなくなります

2点目は、前述の「条件付き書式で色分けする」手法と競合します。ステータス色分けを条件付き書式で作り込んでいるシートでタイムラインビューを併用するなら、色の指定はどちらか一方に寄せる設計が必要です。

対応エディションは、Business Starter・Business Standard・Business Plus・Enterprise各プラン、Essentials、Education各プラン、Frontlineなど広範囲に及びます。個人向けアカウントとの差異が出るため、社内配布前に自社の契約プランで表示を確認しておきます。

出典：Google Workspace ラーニング センター「タイムライン ビューでプロジェクトを追跡する」（https://support.google.com/docs/answer/12935277?hl=ja）

拡張ツール連携で効率化｜案件規模が大きくなったらシームレスに移行

プロジェクト規模が拡大すると、手動の更新や複雑な依存関係管理が負担になります。その場合は、BacklogやSmartsheetなどの管理ツールと連携させることで、ガントチャートの更新が自動化され、タスク遅延の検知と通知が仕組み化されます。

スプレッドシートで基盤を作り、案件が成長したらツールへ移行するハイブリッド運用は、初期コストを抑えながら負荷を段階的に吸収できる進め方です。スプレッドシートはプロジェクト管理の「入口」として、チームの成熟度に応じたアップグレードができる拡張性を持っています。

運用設計｜WBSが形だけにならない仕組みづくり

WBSは作った瞬間がスタート地点です。そこから更新と共有が止まれば、ただの管理資料に戻り、遅延や抜け漏れを防げません。更新を習慣化し、プロジェクト全体を動かす仕組みへ落とし込むところまでが設計範囲です。

権限管理と通知設定｜誰が更新するかを明確にし、停滞を防ぐ

スプレッドシートには「閲覧のみ」「コメント可」「編集可」の権限があり、役割に合わせて更新経路を設計できます。全員が編集できる状態は便利に見えて、ミスや属人化の温床になります。

更新責任者を決め、変更時に通知が届くよう設定すれば、情報の鮮度が自動で保たれます。リンクひとつで常に最新版にアクセスできる点も、会議資料への転記といった無駄な作業をなくします。

週次レビューとステータス更新｜遅延を気づける状態に維持する

タスクの進捗は感覚ではなく、ステータス更新という形で可視化します。週1回のレビューを定例化し、ステータスと完了条件の整合確認を行うことで、遅れの兆候を早期に察知できます。

「遅れそうだから手を打つ」という感覚的な運用は失敗の原因になります。遅延が出たら必ず対応策と期限をセットで更新するルールを明文化しておくと、プロジェクト全体の認識が揃い、負担の偏りや判断の遅れを防げます。

レビューを続ける文化ごと作りたい場合は、チームでタスク管理を定着させる方法に運用ルールの作り方をまとめています。

よくある失敗と回避策｜更新されないWBSから脱却する

WBSが機能しなくなる原因は、情報過多・粒度のブレ・属人化の3つにほぼ集約されます。いずれも「更新のコストが、更新で得られる情報より大きくなった」時点で発生します。

情報過多による形骸化｜管理項目は意思決定に必要な最小限に

列や情報を詰め込みすぎると入力負荷が上がり、更新が止まる最大の要因になります。管理項目は「誰が・いつまでに・何を完成させるか」が判断できる範囲へ絞り、意思決定に寄与しない情報は別資料へ分離します。管理を複雑にしないことが、継続運用に最も効きます。

タスク粒度のブレ｜完了条件が曖昧だと遅れの発見が遅れる

「これ終わった？」と聞かないと進捗が分からない状態では、遅延の表面化が遅れます。完了条件を数行で明文化し、「作業が終わった」ではなく「成果物が確認できた」をゴールに統一します。進捗判断が感覚ではなく事実に基づくものになり、遅れへの対応が早まります。

属人化と引き継ぎ崩壊｜更新責任の所在を曖昧にしない

WBSの更新が特定の担当者だけに依存していると、不在期間や退場時に管理が破綻します。更新責任者を明確にしつつ、最低2名以上で更新とレビューが回る体制を設計します。引き継ぎルールを事前に決めておけば、急な変更があっても運営は止まりません。

スプレッドシート運用の限界と専用ツールに移す判断基準

スプレッドシートが苦手なのは、依存関係の自動再計算・担当者ごとの負荷集計・タスク単位の通知です。手作業で補える範囲を超えたら、専用ツールへ移すほうが総コストは下がります。

判断の目安は、​​タスクが200行を超えた／依存関係の自動再計算が必要になった／期限リマインドを人の記憶に頼っている​​のいずれかに当てはまったタイミングです。1つでも当てはまれば、更新にかかる手作業が専用ツールの月額を上回り始めます。症状別に整理すると次のとおりです。

※表は横にスクロールできます

見えている症状	スプレッドシートの限界	移行を検討する目安
シートが重く、開くのに時間がかかる	数式と条件付き書式が増えるほど再計算が遅くなる	タスクが200行を超える、または並行案件が3本以上
前工程が遅れても後工程の日付が動かない	依存タスクは文字列で記録するだけで、自動再計算されない	依存関係が10本を超える、または週次で日程を引き直している
誰が過負荷なのか会議で毎回もめる	担当ごとの工数合計を手作業で集計するしかない	同一メンバーが3案件以上を兼務している
期限超過に本人しか気づかない	変更通知はシート単位で、タスク単位の期限リマインドがない	期限管理を担当者の記憶に依存している
社外メンバーに見せたくない行がある	保護はシート単位・範囲単位までで、タスク単位の可視制御はできない	外部パートナーが継続的に参加する
承認の証跡が追えない	変更履歴は残るが、承認フローは記録されない	発注・検収の証跡を管理表側に残す必要がある

移行先の候補を絞る段階では、無料タスク管理ツールと有料移行の判断基準で費用対効果の見方を確認できます。

なお、移行してもWBS自体は不要になりません。専用ツールへ登録するタスクの構造は、スプレッドシートで作ったWBSがそのまま元データになります。

目的別テンプレート紹介｜必要な管理レベルに合わせて最適化

プロジェクトの性質や規模によって、WBSに求められる粒度や管理項目は変わります。最初からすべてを盛り込むのではなく、目的に合ったテンプレートを選ぶほうが継続します。ここでは実務で使いやすい3タイプを紹介します。

シンプルWBSテンプレ｜初めての運用に最適

最小限の列構成で、まずはタスクと日付・担当を押さえるテンプレートです。導入ハードルが低く、「形にする」から素早く始められます。小規模案件や、WBS運用の定着が第一目的の場合に適します。

WBS番号	タスク名	担当	開始日	終了日	期間（日）	ステータス
1	成果物A				=E2-D2+1	未着手
1.1	タスクA-1	〇〇			=E3-D3+1	作業中
1.2	タスクA-2	〇〇			=E4-D4+1	未着手

WBS × ガントチャート連携テンプレ｜遅延の見える化を重視

タスク情報と連動してガントチャートが生成され、遅れが発生した瞬間に視覚で検知できるテンプレートです。レビュー工数の削減にもつながるため、期限遵守が最優先の案件に向きます。

WBS番号	タスク名	担当	開始日	日数	期間	依存タスク	ステータス	ガント表示
1	成果物A				=D2+C2		未着手	●
1.1	タスクA-1	〇〇			=D3+C3	1	作業中	●
1.2	タスクA-2	〇〇			=D4+C4	1.1	遅延	●

※表は横にスクロールできます

共有・レビュー運用組み込み型テンプレ｜属人化を防ぐ設計

ステータス更新やレビュー履歴など、運用ルールをテンプレートへ埋め込んだ構成です。チーム運営が前提のプロジェクトや、外部メンバーが関与する案件で威力を発揮します。引き継ぎ時にも情報の抜けがなく、品質を安定させられます。

WBS番号	タスク名	担当	開始日	終了日	期間	依存	ステータス	完了条件	レビュー担当	次回レビュー日	コメントログ
1	成果物A	PM			=E2-D2+1		進行中	〇〇が承認	MG
1.1	タスクA-1	メンバーA			=E3-D3+1	1	未着手	テストパス	MG

※表は横にスクロールできます（12列構成のため、スマートフォンでの一覧確認には向きません）

他社の取り組み｜ビズリーチ・昭文社ホールディングスに学ぶ「更新が続く管理」の作り方

管理表が形骸化する原因は、書式や列構成ではなく「動いているつもりで実態を確認していない」ことにあります。生成AIの社内展開でも同じ壁が起きており、実態を現場ヒアリングで掴んだ企業とサイクル前提で仕組みを作った企業の進め方が参考になります。

株式会社ビズリーチ｜活用率80%の内側を現場ヒアリングで確認した

同社では生成AIの活用率が約80%に達していた一方、その中身は「検索による情報収集」が9割を占めていました。推進担当者は当時の状況について「​​実際には、ほとんどがGoogle検索の延長でした​​」と語っています。

この確認があったからこそ、施策は「利用率を上げる」ではなく「使い方の質を変える」方向に切り替わりました。入社後1ヶ月で40人以上と1on1を実施して現場の実態を掴み、社内コンテストでは40〜50件の応募が集まり、Slackコミュニティは1,000人以上まで広がりました。全社では約4,000時間の削減と約1億円規模の価値創出につながっています。

WBS運用も構造は同じです。「更新されている」という見た目だけを追うと、実際にはステータス列だけが機械的に書き換えられ、完了条件と実態がずれた状態を見逃します。週次レビューでは更新率ではなく、完了条件の記述が判定可能な表現になっているかを1行ずつ確認します。詳細は株式会社ビズリーチへの取材記事で紹介しています。

株式会社昭文社ホールディングス｜行き詰まりの原因分析にAIを使った

同社はAI導入に1年半をかけてリスク管理・法務・セキュリティを整備した上で、Googleの契約プランを通じてGeminiを全社で利用できる環境を整えました。担当者は活用の実態を「​​自分たちがなぜ行き詰まっているかという分析もAIでできますし、行き詰まった時に生成AIに相談すると、別の担当部署を動かしたらどうかといった具体的な提案が返ってきます​​」と語っています。

実際にBCP策定プロジェクトでは3回のサイクルで根幹部分を完成させ、以前は2〜3ヶ月かかっていたイベント記事の文字起こしと公開が数日で回るようになりました。

WBSが止まる場面でも、詰まっている理由の言語化と次アクションの提示は担当者1人で抱えると進みません。遅延が出た行に対して「原因の候補」と「動かすべき関係部署」を洗い出す用途は、前述のレビュープロンプトがそのまま使えます。詳細は株式会社昭文社ホールディングスへの取材記事で紹介しています。

2社に共通する3つの設計思想

• ​実態は数字ではなく中身で確認する​​：更新率や活用率が高くても、中身がずれていれば管理は機能しません
• ​サイクルを回す前提で作る​​：完成させてから使うのではなく、3回程度の見直しで固める前提にすると着手が早まります
• ​止まった時の次アクションを人任せにしない​​：原因分析と関係部署の洗い出しまでを仕組みに含めます

まとめ｜WBSは更新が続く仕組みがすべて

WBSは、作った瞬間に成果が生まれるものではありません。スプレッドシートで管理するからこそ、軽く・早く・誰でも更新できる環境を活かし続けることが、遅延や抜け漏れを防ぎます。

今日から進めるなら、順番は次の3つです。

1. 本記事の9列テンプレートをコピーし、成果物型か工程型かを決めて第1階層を埋める
2. タスクの洗い出しと粒度チェックを生成AIに下書きさせ、工数と担当は担当者本人が上書きする
3. 数式列を保護し、共有範囲と更新責任者を決めてから配布する

まずは形にする。次に、共有とレビューで動かす。そして、運用を止めない仕組みにする。この3段で、炎上しないプロジェクト管理に切り替わります。

ここまでが、1つのプロジェクトを回すための設計です。次の課題は、この進め方を担当者個人の工夫で終わらせず、チームの標準ルールとして定着させることに移ります。タスク分解のプロンプトと更新ルールを組織の型として共有できれば、プロジェクトごとに管理表を作り直す作業自体がなくなります。

以下の資料では、生成AIの運用設計やリスク管理、プロンプトの考え方をより深く解説しています。AIで管理業務を効率化する基礎知識が分かりますので、ぜひご覧ください。

よくある質問