LASSIC Media らしくメディア
WBS(作業分解構成図)の自動化はどの手順で進めるか
監修・編集責任者:牛尾 昭昌(株式会社LASSIC 執行役員)

この記事の結論
- WBSの自動化は、作業の分け方・完了の定義・更新の入口をそろえてから、集計と遅れの通知を道具に任せる順で進めます。
- 完了の基準が人ごとに違うまま集計を自動にしても、数字が信用されず、会議の前の聞き直しは残ります。
- まず作業の分け方と完了の定義を1枚にまとめ、自動にする範囲(集計・通知・工程表の描画)を決めます。
※ 本記事は2026年11月時点の公式情報(省庁・公的機関、および製品やサービスを提供する事業者が公開している資料)に基づきます。
並行する案件のWBS(作業分解構成図。プロジェクトに必要な作業を細かく分けて一覧にした表)を表計算で更新し、会議の前には担当ごとの報告を集めて写している。この状態から自動化の手順を調べると、まず道具の比較に目が向きます。先にそろえるのは道具ではなく、作業の分け方、完了の定義、更新の入口の3点です。
答えを先に示すと、道具を選ぶ前にこの3点を1枚にまとめ、進み具合の集計と遅れの通知から一段ずつ自動にします。本記事では、現状の棚卸しから、どこを自動にするかの決め方、1つの案件で試して広げるまでの手順と、表計算か専用の道具かの判断の材料、費用対効果の見方、共有と情報の扱いの確認点を整理します。
目次
会議の前の集計が、毎週の手作業になっている
各担当の報告を手で写して集計していると、遅れに気付くのが会議の当日になります。集計が終わるのが会議の直前では、遅れた作業の原因を確かめる時間も、担当と打ち手を話す時間も残りません。並行する案件が3つあれば、写す作業も3つ分に増えます。

遅れそのものは、珍しい出来事ではありません。JUAS(日本情報システム・ユーザー協会)のソフトウェア・メトリクス調査2026は、企業IT動向調査の2015年度からの10年間の推移を考察した結果、予定通りの工期・予算で完了したプロジェクトの割合は減少傾向にあることが確認されたとしています。*1 遅れが出る前提で、気付くまでの日数を縮める仕組みを考えておく、という見方がとれます。
悩みごとに、先に読むとよい章を次の表にまとめました。
| 悩み | 読む章 |
|---|---|
| 更新が人によってばらばら | 自動化の手順 |
| 道具の候補が多くて決められない | 表計算か専用の道具かの判断の材料 |
| 会議の前の集計に時間がかかる | 費用対効果の見方 |
自動にする前に、WBS(作業分解構成図)のどの階層を誰が決め、誰が更新するのかを並べておくと、自動にできる所が見えてきます。次の図は、IPA(情報処理推進機構)の共通フレーム2013のプロセスの区分を参考に、本記事で整理したものです。
上の2つの階層は、案件の始まりに進行役が決めれば、週ごとに変わることは多くありません。毎週動くのは一番下の作業の進み具合です。ここが一か所に正しく入っていれば、集計と遅れの通知は道具に任せられます。
自動にできないのは道具ではなく「完了の定義」のばらつき
自動で集計した数字が会議で使われない原因は、道具の性能より、作業の粒度(一つの作業の大きさ)と完了の基準が人ごとに違うことにあります。ある担当は書き終えた時点で完了とし、別の担当は見直しが済んでから完了とする。この違いが残ったまま集計すると「完了」の中身がそろわず、結局は進行役が一人ずつ聞き直すことになります。

デジタル庁の実践ガイドブックは、定量値の観測で大切なことは、事前に進捗率の測り方を明確にしておくことだとしています。*2 測り方のルールを決めずに担当者の恣意性に委ねると、同じ数字のまま数週間が過ぎることにもなりかねない、という指摘です。*2 集計を自動にしても、入る数字の意味がそろっていなければ、会議の前の聞き直しは残ります。
自動化に進む前に、次の3つを確かめてみてください。
- 作業の粒度がそろっているか
- 完了の基準を文で書いているか
- 更新の入力を一か所に決めているか
手作業の集計と自動の集計で毎週の作業がどう変わるかは、WBS(作業分解構成図)の自動化で何が違う:作成・更新・集計のどこを自動にするかで整理しています。この記事は、その先の進め方に絞って説明します。
後半では、自動化の手順、表計算か専用の道具かの判断の材料、費用対効果の見方、工程の標準をもとにした分け方、共有と情報の扱いの確認点を確かめられます。
自動化の進め方を決める4つの基準
どこから自動にするかは、道具の機能を比べる前に、次の4つの基準で今のWBSを見て決めます。満たせていない基準があれば、そこを整えることが自動化の最初の一段になります。
| 基準 | 目安 | 満たせていないときの最初の一手 |
|---|---|---|
| 作業の粒度 | 1つの作業が数日のうちに終わる大きさにそろっているか | 数週間かかる作業を、成果物ごとに分け直す |
| 完了の定義 | 何がそろえば完了かを、作業ごとに文で示せるか | 「何ができたら完了か」を作業ごとに1行ずつ書き足す |
| 更新の入口 | 担当が進み具合を入れる場所が一か所か | メールや口頭の報告をやめ、入れる場所を1つに決める |
| 共有の範囲 | 社外の人も見るか、社内だけかで道具と設定が変わる | 社外に見せる作業と社内だけの作業を分けておく |
完了の定義は、システム開発の取り決めでも重く見られてきた項目です。IPAの共通フレーム2013のガイダンスは、契約遂行上の節目は、明確に定義した開始基準及び完了基準に基づくことが望ましいとしています。*3 社内の案件でも、作業ごとに完了の基準が書かれていれば、集計した数字の意味が担当の間でそろいます。
共有の範囲は、道具の選び方に直結します。協力会社も進み具合を入れるなら、相手が使える道具か、見せる範囲を分けられるかが条件に加わります。
3つの案件を並行する週の会議で
4つの基準を整えた後の、進行役の判断の流れを一例として示します。3つの案件を並行する進行役が、会議の前に遅れの一覧を自動で受け取り、会議では遅れた作業の打ち手だけを話す場面です。
| 段階 | 進行役の判断 |
|---|---|
| 会議の前 | 自動で届いた遅れの一覧を開き、予定の完了日を過ぎた作業と、完了の基準を満たさないまま期日が近い作業を分ける |
| 遅れの見極め | 遅れた作業が後ろの作業や節目の日付に響くかを見て、会議で取り上げる作業を絞る |
| 会議 | 一覧の読み上げはせず、絞った作業ごとに担当と打ち手(割り振り・範囲・期日)を決める |
| 会議の後 | 決めた打ち手を同じ表に書き、次の集計で効いたかを見る |
進み具合を聞いて回る時間がなくなる分、会議は報告の場から判断の場に変わります。反対に、集計を写す作業が残っている間は、この形には移れません。前の章の基準を整えることが、会議を短くする近道になります。
自動化の手順
分け方の統一、更新の入口、集計、遅れの通知、見直しの順に、一段ずつ自動にします。その前に今の作業を棚卸しし、どこに時間がかかっているかを数えておくと、自動にした効果を後で示せます。
| 段階 | すること | できたかの目安 |
|---|---|---|
| 1. 現状を棚卸しする | 毎週の更新・集計・報告の作業と、それぞれにかかる時間を書き出す | 誰が何に何時間使っているかが1枚で見える |
| 2. 分け方と完了の定義をそろえる | 作業を数日のうちに終わる大きさにそろえ、作業ごとに完了の基準を書く | 案件をまたいで、同じ作業が同じ名前と基準で並ぶ |
| 3. 更新の入口を一か所にする | 担当が進み具合を入れる場所と曜日を決める | 進行役が報告を写さなくても表が最新になる |
| 4. 集計を自動にする | 関数や道具の集計機能で、案件ごとの進み具合を一覧にする | 会議の前に集計の手作業が要らない |
| 5. 遅れの通知を自動にする | 予定の完了日を過ぎた作業を一覧にし、決まった時刻に進行役へ届ける | 会議の前に遅れの一覧が届く |
| 6. 1つの案件で試し、見直して広げる | 1つの案件で数週間回し、入れ漏れや基準のずれを直してから他の案件に広げる | 2つめの案件を、同じひな形と基準で始められる |
2段目の完了の定義は、作業の種類ごとに出来事で決めると、入れる人が迷いません。実践ガイドブックは、文書の作業について、レビューの完了や指摘の反映といった出来事ごとに進捗率を割り当てる例を示しています。*2
| 進捗率 | 文書の作業で数える出来事 |
|---|---|
| 0~50% | 事業者の担当者が実作業の進捗に合わせて計上 |
| 60% | 事業者内レビューの完了 |
| 70% | レビュー指摘事項の反映完了 |
| 80% | PJMOレビューの完了 |
| 90% | レビュー指摘事項の反映完了 |
| 完了 | PJMOによる最終確認 |
表のPJMO(Project Management Office)は、発注する側でプロジェクトを管理する組織です。社内の案件なら「事業者内」を担当のチーム内に、「PJMO」を進行役や依頼元に置き換えて使えます。出来事で決めておけば、自動の集計は「どの出来事まで済んだか」を数えるだけになります。
5段目の遅れの通知は、集計の数字が会議で使われるようになってから加えます。数字がずれたまま通知を始めると、届いた一覧が開かれなくなるためです。通知の条件は、予定の完了日を過ぎた作業、完了の基準を満たさないまま期日が近い作業、のように絞ります。
- 試す案件は、作業の数が多すぎず、担当が毎週入れられる案件を選ぶ
- 試す間は手作業の集計も並べて取り、数字が合うかを比べる
- 広げる前に、入れ漏れの多かった作業と基準を直す
表計算か専用の道具かの判断の材料
並行する案件の数と更新する人数、社外との共有の有無で決めます。今の様式を残す必要があるかも、移る手間を左右します。
| 条件 | 表計算の関数とマクロが向く | プロジェクト管理の道具が向く |
|---|---|---|
| 並行する案件の数 | 少なく、案件ごとの表で足りる | 多く、案件をまたいだ一覧が要る |
| 更新する人数 | 進行役と少人数が入れる | 担当の全員が自分で入れる |
| 社外の人との共有 | 社内だけで見る | 協力会社も入れる・見る |
| 今の様式 | 取引先や上長に今の様式で出す必要がある | 様式を変えてよい |
表計算でも、関数で進み具合を集計し、マクロ(表計算の操作を記録して繰り返す仕組み)で遅れの一覧を作ることはできます。ただ、同時に何人もが同じファイルを直すと、上書きや入れ違いが起きやすくなります。更新する人が増えてきたら、入れる場所を人ごとに分けられる道具を比べる時期です。
道具を比べるときは、製品名から入らず、前半の4つの基準を満たせるかで見ます。業務のシステムとして選ぶときの観点は、工程管理システムの選び方|実績の記録と進捗の見える化の基本でも取り上げています。
- 今の表で困っているのが集計だけなら、表計算のまま始める
- 社外と共有するなら、見せる範囲を分けられるかを先に確かめる
- 様式を残す必要があるなら、道具から今の様式で書き出せるかを見る
費用対効果の見方
道具の利用料と移る手間を、集計にかかる時間の減りと同じ期間で比べます。月の利用料と週の作業時間のように期間がずれたまま並べると、効果が実際より大きくも小さくも見えます。
| 項目 | 出し方 |
|---|---|
| 減る時間 | 集計と報告の写しにかかる時間×週の回数×案件の数を、1年などの期間でまとめる |
| 移る手間 | 分け方と完了の定義をそろえる時間、表や道具を作る時間、担当に入れ方を伝える時間 |
| 増える手間 | 担当が自分で進み具合を入れる時間(移る前は進行役が負っていた分) |
| 利用料 | 使う人数×月額を同じ期間でまとめる。表計算の関数で作るなら、今のソフトの範囲で始められる |
減る時間には、手順の1段目で棚卸しした値を使います。測らずに見込みだけで出すと、上長に説明するときに根拠を問われます。
もう一つ数えておきたいのが、遅れに気付く日の早さです。会議の当日に気付いていた遅れが前の日に分かれば、打ち手を選べる日が増えます。金額にはしにくい効果なので、時間の数字と並べて書き添えます。
- 比べる期間を1年などにそろえ、利用料と減る時間を同じ表に並べる
- 担当の入力の時間を、増える手間として入れておく
- 遅れに気付く日がどれだけ早まったかを、試した案件で記録する
工程の標準をもとにした分け方
公的な工程の標準を参考に分け方をそろえると、案件をまたいで比べやすくなります。IPAの共通フレームは、システムやソフトウェアの構想から企画、開発、運用、保守、廃棄に至るまでのライフサイクル全般にわたって、必要な作業内容を包括的に規定したガイドラインです。*4
共通フレームは、関わる人々が“同じ言葉”で話すことができる共通の枠組みを提供している、と説明されています。*4 工程の呼び方が案件ごとに違うと自動の集計はまとまらないため、この「同じ言葉」がWBSの分け方をそろえる土台になります。
| 区分 | 主なプロセス |
|---|---|
| テクニカルプロセス | 企画プロセス、要件定義プロセス、システム開発プロセス、ソフトウェア実装プロセス、保守プロセス |
| 運用・サービスプロセス | 運用プロセス、廃棄プロセス、サービスマネジメントプロセス |
| プロジェクトプロセス | プロジェクト計画プロセス、リスク管理プロセス、測定プロセスなど |
ただし、標準の区分をそのままWBSの行に並べれば済むわけではありません。実践ガイドブックは、WBSにはプロセスベースと成果物ベースの2種類があるとし、基本的には成果物ベースで作成することを推奨しています。*2 テスト工程の名称を並べただけのWBSについては、調達仕様書の中身をよく検討しなくても機械的に割り当てるだけで作れてしまう、と指摘しています。*2
ひな形からWBSを自動で作るときも同じで、工程の名前を並べただけのひな形では、遅れた作業を特定できません。進み具合の数え方について、実践ガイドブックは、工程ごとに進捗率を出すのではなく、100本の機能のうち、すべて済んだものが30機能、半分まで済んだものが20機能というように機能の単位で数える例を示しています。*2
細かく分けすぎても管理の手間が増えます。同じガイドブックは、むやみに作業を細分化して管理するのではなく、現場の行動に即して管理単位が決められているかを確認するよう求めています。*2 作業の分け方そのものの手順は、WBS(作業分解構成図)の作り方と、進捗の管理への使い方で説明しています。
- 上の階層の呼び方は、共通フレームの区分などを参考に案件をまたいでそろえる
- その下は成果物で分け、作業は数日のうちに終わる大きさにする
- 進み具合は工程ではなく、成果物や機能の単位で数える
共有と情報の扱いの確認点
社外の人と共有する範囲、外部の道具に置く情報、アカウントの管理を社内規程で確かめます。WBSには顧客名、案件の中身、担当者の名前、納期が並び、自動の通知はその一部をメールやチャットへ送ります。
| 確認点 | 確かめる中身 |
|---|---|
| 共有する範囲 | 協力会社や取引先に見せる作業と、社内だけの作業を分けられるか |
| 外部の道具に置く情報 | 顧客名・金額・個人名など、道具に置かない情報を決めているか。取引先との秘密保持の取り決めに合うか |
| 通知の宛先 | 遅れの一覧が、社外のアドレスや大人数のチャットに届かないか |
| アカウントの管理 | 案件の終了や担当の交代のときに、閲覧と編集の権限を外す手順があるか |
| 更新の履歴 | 誰がいつ進み具合を直したかの記録が残るか |
自動の通知は便利な反面、宛先の設定を誤ると、見せるつもりのない情報が届きます。通知の本文には作業名と期日だけを載せ、詳しい中身は権限のある人が道具の中で見る形にすると、送る情報を減らせます。
- 道具に置かない情報を、一覧にしておく
- 通知の宛先と本文に載せる項目を、試す段階で決めておく
- 権限を外す手順を、案件を閉じるときの作業に入れる
まとめ:分け方と完了の定義をそろえてから自動にする
WBS(作業分解構成図)の自動化は、道具を選ぶ前に、作業の分け方・完了の定義・更新の入口をそろえるところから始まります。そのうえで集計、遅れの通知の順に一段ずつ自動にし、1つの案件で試してから広げます。今日からは、作業の分け方と完了の定義を1枚にまとめ、チームに確かめてもらう日を決めてください。
よくある質問
最初に何を自動にすればよいですか
進み具合の集計と遅れの通知から始めます。どちらも会議の前の手作業を直接減らせるうえ、作業の分け方と完了の定義がそろっていれば、表計算の関数でも作れます。工程表の描画などは、集計の数字が会議で使われるようになってから加えます。
表計算のままでも自動化できますか
案件と更新する人が少なければ、関数とマクロで集計を自動にできます。同時に何人もが同じファイルを直すようになったら、入れる場所を人ごとに分けられる道具を比べる時期です。
作業はどの細かさで分けますか
1つの作業が数日のうちに終わり、完了の基準を文で書ける大きさにそろえます。工程の名前を並べただけでは遅れた作業を特定できないため、上の階層は工程、その下は成果物と作業で分けます。細かくしすぎると入れる手間が増えるため、現場の作業の単位に合わせます。
道具の費用はどう説明しますか
集計にかかる時間の減りと利用料を、同じ期間で比べて示します。減る時間は棚卸しで測った値を使い、担当が自分で入れる時間は増える手間として入れておきます。遅れに気付く日が早まった分も、試した案件の記録として添えます。
取引先と共有しても大丈夫ですか
共有する範囲と置く情報を社内規程で確かめてから設定します。見せる作業と社内だけの作業を分け、通知の宛先と本文に載せる項目も決めておきます。案件を閉じるときに権限を外す手順も、あわせて用意します。
プロジェクトの管理の見直しの相談
並行する案件の数と更新する人数、今の様式と更新の流れをお手元にご用意いただければ、自動にする範囲と順番からご相談いただけます。
Remoguとリラシクなら、リモートワークで働く社員の候補者も、業務委託で開発に加わる専門人材も探せます。
Remoguは、リモート前提で全国から即戦力のITプロ人材を調達するサービスです。リラシクは、扱う求人がすべてリモートワークのITエンジニア専門転職エージェントです。どちらもLASSICが運営しています。
出典
- *1 参考:一般社団法人日本情報システム・ユーザー協会(JUAS)「ソフトウェア・メトリクス調査2026 クラウド・パッケージ・アジャイル開発のメトリクス考案に向けた事前サーベイ」(2026年4月)(https://juas.or.jp/cms/media/2026/04/26swm.pdf)。出典:第1章 1.3 情報システム開発の多様化の意義と本質(企業IT動向調査報告書2025の10年間の推移の考察)を参照(確認日2026年11月6日)(2026年11月確認)
- *2 参考:デジタル庁「DS-120 デジタル・ガバメント推進標準ガイドライン実践ガイドブック」(2026年6月12日改定)(https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/0af5ce68/20260715_resources_standard_guidelines_guideline_05.pdf)。出典:第3編第7章 Step.3-1 A(定点観測こそ進捗・品質管理の要)・表7-7 進捗計上ルールのサンプル、第3編第6章 A(具体的な作業計画を評価する)の「WBSを精査する」を参照(確認日2026年11月6日)(2026年11月確認)
- *3 参考:独立行政法人情報処理推進機構(IPA)「共通フレーム2013」第3部 共通フレームとガイダンス(ガイダンス部分の抜粋)(https://www.ipa.go.jp/publish/qv6pgp000000107j-att/000062659.pdf)。出典:目次(プロセスの区分)と 1.1.1.13(契約遂行上の節目の開始基準及び完了基準)を参照(確認日2026年11月6日)(2026年11月確認)
- *4 参考:独立行政法人情報処理推進機構(IPA)「国際規格/JIS改訂に対応する「共通フレーム」の利用について」(2021年9月1日)(https://www.ipa.go.jp/publish/qv6pgp000000107j-att/000093137.pdf)。出典:「共通フレーム」の目的と意義を参照(確認日2026年11月6日)(2026年11月確認)