ITじゃないプロジェクトも！WBSの書き方再入門【テンプレートあり】

今回のテーマは「WBS」

　いわゆるプロマネ、プロジェクトマネジメントといえば「WBS」というものが代表的なツールとして知られています。Work Breakdown Structureの略語で、作業を細かく分解し、構造的に整理する、という意味です。工程表とも呼ばれます。

　WBSとは、最初に必要な作業の洗い出しを行い、可能な限り細分化し、それぞれの作業に必要なコストや人員配分を割り出して、スケジュールを配分する、ということです。WBSの基本的なイメージとしては、よく「カレーを作る」といったものを題材として、以下のように表現されます。

　WBSには以下のようなメリットがあります。

（1）やるべき作業が明確になる
（2）スケジュールの構築が綿密になる
（3）役割分担が明確になる
（4）工数見積りがしやすくなる
（5）進捗管理がしやすくなる
（6）作業範囲や責任範囲が明確になる

　WBSを書くことは、さほど難しいことではありません。基本的には「成果物を、中間成果物や部品、タスクに分解する」「期日を決める」「担当者を割り当てる」という３つのことをすればいいだけの話です。
　しかし、いざやってみると、なかなかうまくいかない、どう書けばいいかわからない、という人も多いのです。

WBSのよくある悩み

　WBSにまつわる悩みとして、よく聞くものを例示してみます。

WBSって、そもそもどう書けばいいのか、よくわからない

なんとなく書いてみても、本当にそれでいいのか、不安が残る

ちゃんと書いたつもりも、タスクが漏れていたり、遅延したりして、更新が大変

せっかく一生懸命書いても、誰も見てくれない

ネットや書籍で色々と勉強しても、自分の取り組みと違う例しか載っていないので、参考にしづらい

　そんな悩みを持っておられる方には、「書き方」以前の問題として、まず、大前提としてご理解いただいたいことがあります。

　それは、以下の大前提です。

どんなプロジェクトでも、とりあえずWBSを書けばうまくいく、というわけではない。

世の中には、２通りのプロジェクトがある。

WBS管理がしやすいプロジェクトと、そうじゃないプロジェクトだ。

　では、WBSによる「管理」が適したプロジェクトとは、どういうものか。先行する事例知識が豊富で、工程や先読みが容易なプロジェクトです。

　考えてみれば当たり前ですが、先読みができない、未知の要素が多すぎる取り組みに対して、いくら自分の都合で工程表を書いたところで、ものごとはその通りになるはずがないのです。

　そもそも、その取り組みが、どんな目的のもとにあり、どんな成果物を生み出すことで、どんな効果を生み出したいか、ということが、シャープに語れないようでは、WBSは、引いたところで意味は生じません。例えば以下の整理は、プロジェクトマネジメント用語でいわゆる「ODSC」と呼ばれるものですが、こうした話について確信をもって語れれば、その取り組みのプロセスをゴールから逆算し、WBSを引くことが可能になります。

目的　Objectives
（このプロジェクトを通して、どんな未来をもたらしたいか）

成果物　Deliverables
（目的を叶えるために生み出す具体的なモノはなにか）

成功基準　Success Criteria
（目的がかなったかどうかを判断するための基準はなにか）

　つまり、そもそもWBSというものは、「何を作るべきかが見えていて、どうなれば終わるのか、過程としてなにをすべきか」が既知である場合に、それをヌケモレなく進めることに適している、ということです。言い換えれば、なぜWBSを引くのことが簡単なのかというと、その取り組みについて、よくわかっているからだった、ということです。

　「どこを向いて走り始めたらいいかよくわからないプロジェクトでも、とりあえずWBSとやらを書けば、なんとかなる」ということは、決して、ありません。（そういう場合は、プ譜を書いてください。）

WBSはITプロジェクトでも、そうでないものでも書ける

　たとえばIT開発プロジェクトは、社会的に見ると実に豊富な事例のある分野です。
　なかでもとくに、いわゆるウォーターフォール型のプロジェクトマネジメントにおいて、ITソフトウェアやWebサイト、アプリケーションなどを作るにあたって、その成果物や工程をどう分解すれば進めやすいか、ということは、わりとよく知られています。よく語られているものを、ざっくりとしたイメージとして表現すると、以下のようなものとなります。

　WBSは、とても偉大な発明です。適切な状況で、適切に活用すれば、とても大きな利便性を与えてくれます。
　複雑な要素があれこれと絡み合う、内部構造の複雑な成果物であっても、適切に分解さえしてあげれば、ひとつひとつの作業は人間が扱うことができるようになります。そして、ひとつひとつの簡単な作業を積み上げていけば、驚くほど高機能な成果を手にすることができるのです。

　ちなみに、ITじゃないプロジェクトでも、考え方の基本は同じです。複雑な成果物であっても、適切に分解してあげれば、取り扱いはとても簡単になります。まさに上の図もそうですが、どうしても世の中のプロマネ指南書や情報サイトには、ITプロジェクトを題材とした話が多く、IT以外の例もあるといいなと思って作ってみたのが、下の図です。

　キーワードは「要素分解」と「再結合」です。基本的にいって、どんな人工物であれ、かならずそれを構成する要素同士は複雑に関係し合うものですが、それでも、キレイに分けると、個別に作業をしてから組み上げるということが、やりやすくなります。

WBSの書き方は、大きく分けると3通り

　さて、そんなWBSですが、「モノ」の話と「プロセス」の話を、どんな塩梅で表現してあげるのか、というところが、最大のコツとしてあります。

　どういうことか。先述の例もそうですが、まず基本的には、WBSは「成果物＝モノ」を分解する、ということが第一義です。

　引き続き「カレー」を題材に取ってみると、例えば以下のようなイメージです。

　カレー作りに慣れている人であれば、このような格好でモノとしての材料と、それら同士の関係性が表現されていたほうが、完成させたいカレーのイメージはよくわかります。分量や材料を加工する仕様が正確に表現されれば、精度はさらに高まります。

　一方で、カレーを作り、みんなで美味しく食べるイベント全体をプロジェクトとして捉え、その進行プロセス全体を表現したい、となると、まったく異なる切り口の表現をする必要が生じます。

　実際のビジネスプロジェクトの現場でも、このような格好で、いわゆる「マイルストン」を軸としたプロセス表現がされていることも多いです。これもこれで、確かに、WBS表現のいちパターンであると言えます。
　このパターンのメリットは、確かにプロセスがよくわかるところですが、その表裏一体のデメリットとして「具体的になにをどう作るか」が見えてこないところにあります。

　というわけで、３つめの例をご紹介します。上記の①と②の中間的な表現方法です。ある程度、プロジェクトの進行プロセスも表現しつつ、そのなかで部品や作業の具体的な内容も表現していく、といった形です。

　このような３つめのパターンで表現すると、全体的な作業の流れと具体的にどうするかが、直感的にわかりやすく表現できます。それは大きなメリットですが、一方で、いわゆるロジカルシンキングの世界でいう「MECE」さが不足しがちなところがあります。

　WBSの３つの作成パターンのメリット、デメリットをまとめますと、以下の通りとなります。

	メリットとデメリット	向いている状況や局面
イメージ１ 成果物を分解	◯成果物を正確に表現することができる △プロセスのイメージが湧きにくい	プロジェクトの最終盤。 「ゴールは決まった。あとはいかに正確にやるか」 といった場合
イメージ２ プロセスを分解	◯全体の進行の流れを表現できる △モノや作業の具体的な内容が見えにくい	プロジェクトの序盤や上流 「全体として、いつまでに、どう進めたいか」 といった場合
イメージ３ いいとこ取り	◯直感的に、バランスよく表現できる △ヌケモレがでやすい	小～中規模の取り組み 社内プロジェクトのようなもの ある程度の進め方の目線合わせには十分

実際の業務をイメージした作成例

　さて、以上、おおきく３つの作成の方向性をご紹介しましたが、業務現場においては、見せる相手や状況にあわせて、様々な角度から表現し、アレンジしていくことが必要となります。IT開発ものからそうでないものまで、できる限り幅広いイメージをご覧いただければと思います。
　実際に筆者が携わってきた案件で、実際に作成し運用したものをベースとして、具体名などは架空のものにアレンジした形となっています。

プロジェクトの序盤で、全体的なマイルストンや想定期日、想定期間を示すもの

　ある程度複雑な機能を持つITソフトウェアや多機能Webサイトなどは、その取り組みの序盤において「だいたいこういうものを作りたいが、企画の内容によって後段の工程やスケジュールが変動しやすい」ということが多いです。そんな場合に、厳密なWBSをいきなり引いて、それ通りに進めるというのも、現実問題として難しいところがあります。
　また、そうした序盤の状況では、コミュニケーションを取る相手は予算の意思決定者や事業における決裁者など、必ずしも、技術的な話に明るくないことも多いものです。そんなときには、下図のような「ざっくりとした進行ステップやマイルストン」と「それがいつまでに終わらなければならないか、あるいは想定としてどの程度の期間を見ておく必要があるか」といったものがあると意思疎通がしやすくなります。

IT開発やWeb開発の際に、具体的な成果物の構成を示すもの

　企画が煮詰まってくると、実際に成果物としてどんな要素があるのか、各要素に対してどの程度の労力が求められるか、ということを明確化する必要に迫られます。そんなときにはやはり、「モノ」に着目したWBSが力を発揮してくれます。

進行中の作業のヌケモレ防止や期日管理、進捗状況を把握するためのもの

　個別の中間成果物や部品を作るために、どんな段取りや作業が必要か、ということを示すとなると、やはりいわゆるガントチャート的なWBSの出番、ということになります。

期日や時系列の要素を視覚的にわかりやすくした場合

　プロジェクトの規模感がさほど大きくもなく、最初からある程度精度の高いスケジュールや作業工程を想定できる場合は、先述のイメージ③のようなものを、いきなり作って回してしまう、ということも可能です。

非ITプロジェクトのWBS例（研修運営）

　非ITプロジェクトのなかで、WBS管理が一番やりにくいイメージがあるのは「イベント」や「研修」のような、形のある成果物を伴わない取り組みではないかと思います。
　以下は、日程の要素を一旦考慮から外して、取り組みのフェーズごとに、どのような具体的な中間成果物が必要なのかを列挙してみた例です。

カテゴリごとに、何月のいつ頃に、何をするかという全体観の表現をする

　ある程度、スケジュール的な要素も含めて見通しを立てたい、となった場合、時系列の要素を足して、該当する箇所に必要なアクションや中間ゴールをマッピングしていく、という方法もあります。
　研修やイベントの場合は、日次ベースというよりは週単位、隔週単位ぐらいで表現したほうが、進捗がわかりやすくなることもよくあります。

そのなかで、個別の作業の期日や状況、ヌケモレ防止のためのリスト

　とはいえ結局のところは、重要な作業やアクションが抜けてしまっては困るので、重要なものについてはチェックリストのような形で補助的なWBSも持っておけば、万全です。

まとめ

　実際の作例をご覧いただくと、スタイルも内容も様々なので、戸惑われるかもしれません。しかし、あらゆる取り組みに通用する、「WBSの正しい書き方」があるわけではないのです。「WBSには、いろんな書き方がある。その場その場にあわせて、物事の交通整理がしやすくなるように、工夫して書く」というふうに、お考えください。

　一般論や最低限の原則として、語り得る真理のようなものがあるとすれば、WBSとは「詰め将棋」的なものである、ということです。つまり、ゴールに向けて、手順を読み切る、ということ。
　そのためには、第一義としてはやはり「作り上げるべきモノ＝成果物」を内部構造も含め、できる限り、正確に表現することが重要です。加えて、その場で関わり合う人たちの状況や役割、要求、リテラシも踏まえること。

　それらの考察の結果として、適切に相手を行動を導くために「その場に合わせた書き方」を心がける。時間的な要素や作業の前後関係の表現が重要な場合は、時間を表すバーをつけて、いわゆるガントチャート的なものにしてもいいですし、逆に、進め方の根本的なステップやマイルストンを強調したければ、思い切って少ないテキスト量で、表現してもいいのです。

　WBSの書きぶりや運用方法を調整する観点には、大きく分けて４つほどあります。

自身の立場

決定権や主導権の有無
当事者なのか、協力者か
依頼や相談をする側か、される側か
自分自身のマネジメントスキルレベル

成果物の影響範囲

最終的なユーザーの数（エンド、中間）
関連する業務、組織、情報システム等
経営戦略上の重要度
規模（費用、人員、期間等）

取り組みの新規性の度合い

課題やユースケースは当該案件独自の特有なものか
用いる技術は社会、業界にとって新しいか
既存資産を活用できるか
カスタマイズか、新規開発か

リソースや状況的な有利不利

物・金・時間・知識等の資源の有無や多寡
プロジェクト組織内部の意思統一の容易性
外部環境に対する知見へのアクセスのしやすさ

　よく「正しいWBSの作り方ができているか、不安」「我流になってないか心配」という質問をいただきます。その気持も重々わかりますが、そんな不安がよぎったら、「そもそもなんのために、WBSを書くのか」を考え直してみてください。

　WBSやマイルストンを作成するそもそもの目的は、作業や責任範囲の交通整理です。関係者がストレスなく必要なアクションや作業を起こすことができていて、スケジュール通りに中間成果物があがっているなら、我流かどうかを心配する必要は、ありません。

　ただやはり、その場その場にあわせたWBSを作るには、いろんなプロジェクトに関わって、場数を踏むことも大事です。ぜひ、このコラムの内容をご参考いただき、またテンプレートもご活用のうえ、試行錯誤してみていただけますと幸いです。

テンプレートのダウンロードはこちら

　以下のイメージのような、基本的なWBSの作成フォーマットに加え、本文中で紹介した各WBSパターンも掲載しているテンプレートを配布しています。

　下記のリンクより、ダウンロードください。

https://www.gotolab.co.jp/wp-content/uploads/2025/06/WBS_gotolabSpecialTemplate.xlsx

本テンプレートの利用にあたりまして

●原則として、本テンプレートは無償で、自由にご利用いただけます。ただし、本テンプレートの販売や改変したものの再配布など、営利目的での無許可での利用は禁止します。

「PMのためのキャリア相談」お引き受けします！

　SIerやSaaS、Web制作・広告などの、いわゆるデジタル・IT企業だけでなく、メーカーや金融などの事業会社、インフラ企業や通信、ゼネコン、エネルギー業界、教育企業まで、大手・超大手から中堅、中小、ベンチャースタートアップまで、実務から育成まで、幅広いテーマで人や法人とお付き合いしてきた後藤ならではの「土地勘」のようなものが、あります。

・形式　　　：一回90分、オンラインで開催します。
・曜日と時間：平日、土日含め、いつでも自由に設定可能です。候補時間をお伝え下さい。
・費用　　　：一旦、実験的な試みとして、当面、無料でご対応します。

　やってみたい！という方は、メールかFBメッセンジャー宛に、ご連絡ください！(*^^*)
info@gotolab.co.jp
https://www.facebook.com/gotoYohei