現場で使える！WBSの作成手順とそのコツ 【PMの道具箱#4】
みなさん、こんにちは！
今回はWBSの作成です。
今までなんとなくWBSを作っていた方、部下にWBSの作り方を教えたい方、はじめてプロジェクトマネージャーになりWBSの作り方に迷っている方必見です。
WBSを作成する手順をコツと共に説明します。
はじめに
WBSとは
WBS とは「 Work Breakdown Structure 」（作業分解構造）の略称です。
Work
プロジェクト目標を達成するために必要な作業をBreakdown
漏れなく要素分解したStructure
上位から下位に階層的に詳細化した構造
構造化（Structure）とは
「成果物」と「作業（プロセス）」で要素分解し可視化することです。
構造化された状態の例
ソフトウェア開発（ウォーターフォールでは）下図のようなツリー形式で表現されます。（Lv6が成果物、それ以外は作業）
2種類のWBS作成アプローチとその違い
本稿では成果物指向とよばれる、成果物を中心に考えるアプローチを推奨しています。これは、最初に成果物を定義し、次に成果物を作成する作業（プロセス）を定義する進め方です。
一方、作業（プロセス）を中心に考えるプロセス指向という進め方もあります。こちらは作業（プロセス）を先に考え、次に成果物を定義します。
システム開発を例にすると、プロセス指向では、まず要件定義・基本設計・実装に大きく分解します。次に要件定義を業務要件定義とシステム要件定義、基本設計を画面設計とバッチ設計などに分解します。最後に業務要件定義では業務フロー、システム要件定義でユースケースと成果物を設定します。
このようにプロジェクトを作業の観点で細分化してから、各作業の成果物を決める進め方です。
一方、成果物指向はプロジェクトのゴール時点で作成されているであろう、成果物の全体像を先に定義し、そこから逆算して作業を決める。という違いがあります。
成果物指向のメリット
本稿で推奨する成果物指向のアプローチをプロセス指向と比較すると３つの利点があります。
①ステークホルダーと合意形成しやすい
スコープをステークホルダが実際に見る「成果物」を示すため、作業（プロセス）で語るよりステークホルダーのイメージが湧きやすく、合意形成に役立ちます。
②作業が膨らみづらい
作業だけでは完了の状態がステークホルダーとズレることが多く、作業が膨らむリスクが高くなります。一方、作業の完了条件を成果物にすればステークホルダー間で作業内容のズレがおきづらく作業工数が安定します。
③抜け漏れが発生しづらい
作業間の繋がりを成果物の構造（繋がり）を可視化することで、成果物の抜け漏れがチェックできます。
後から作業のInput（成果物）の不足に気付くことを防げます。
逆に、本稿の成果物指向のデメリットは、最初に成果物全体を定義しなければならない点です。しかし、その手間と比較しても上記のメリットの方が大きいため、本稿では成果物指向のアプローチを推奨しています。
プロセス指向VS成果物指向
PMBOKでは第3版の時点から成果物指向を推奨しています。
WBS Concepts
A WBS, as defined in the PMBOK® Guide—Third Edition is “a deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables.”
WBSの概念
PMBOK®ガイド第3版で定義されているWBSとは、「プロジェクトの目的を達成し、必要な成果物を作成するために、プロジェクトチームが実行すべき作業を成果物指向で階層的に分解したもの」である。
しかし、世の中のWBS作成アプローチはプロセス指向が多いように見えます。これは、スコープマネジメントとしてのWBSとタイムマネジメントとしてのスケジュールが密接な関係にあることに加え、現場の関心事が何（成果物）を作るより、どう作るか（作業）だからだと考えます。
しかし、作業⇒成果物という順序では、成果物間の整合性がおざなりになりがちです。もし、プロジェクト開始後に成果物の漏れが見つかると、そのままスケジュール遅延やコスト増につながります。これを防ぐためにも、作るモノである成果物を洗い出し、成果物間の整合性を担保した成果物指向の進め方がリスクが少ないと考えています。
1.成果物全体を可視化する
以降では、システム開発プロジェクトを例に説明を進めます。
1-1.成果物の構成とそれぞれの繋がりを可視化
まず、成果物関連図を作成します。
所属している会社や顧客でソフトウェア開発標準がある場合はそれを使います。
Tips：成果物関連図の作成ポイント
①成果物一覧を作る
プロジェクトで作成するもの（ドキュメント、データ、プログラム、環境）をリストアップします。
②成果物間の繋がりを可視化する
成果物間のつながりを可視化する作業を通して、成果物のヌケモレや無駄をチェックすることができます
③ドキュメントを分類する
ドキュメントを成果物として定義し始めると、あれもこれもと、作りたくなります。
ドキュメントは「一時的に必要なもの」と「恒久的に使う物」を分類しておくことで、後続の作業物の調整（成果物のテーラリング）の仕込みとします。
1−2.成果物の調整（成果物のテーラリング）
さあ、成果物の素案ができあがりました。ここからが腕の見せ所です。
1-2-1.総作業量を試算する
成果物毎にそのボリューム（本数）と1本当たりの標準的な作成工数を設定し総作業量を試算します。
1-2-2.成果物をダイエットする
試算した結果、予算内であればそのままでも良いでしょう。
が、あれもこれもと定義していくと、予算を超えると思いますので、最低限の成果物にダイエットさせます。
Tips：ダイエットのポイント（ECRSの観点）
業務改善の手法でECRSという考え方があります。
Eliminate（排除）、Combine（統合）、Rearrange（順序入替）、Simplify（簡素化）の観点で業務を見直す考え方です。この観点で成果物を絞ります。
①作らないドキュメント・やらないテストを決める（Eliminate（排除）、Rearrange（順序入替））
メンバースキルや求められる品質を踏まえ、ドキュメントやテスト内容を極力しぼります。
例
・少人数開発で意思疎通ができていれば内部設計書を省く（込み入ったクラス構造だけに絞る）
・社内利用で利用者数も少なく、いつでも再起動可能なシステムであれば、ロングランテストを省く
（ロングランテスト：長時間の連続稼働によって処理能力やレスポンスに問題が生じないかを確認するテスト）
②ドキュメントテンプレートをカスタムする（Combine（統合）、Simplify（簡素化））
ドキュメントの内容を変えることで成果物1つに掛かる工数を減らします。
例
・テーブル定義書はER図で代用する
・内部設計書がプログラムの処理過程を記述するような物であったら、使うデータとその関連、IN/OUTの定義だけにする
1-2-3.スコープ（機能）を減らす
上記のダイエットをしてもまだ予算超過している場合は、スコープ（やりたい事）の削減を検討します。
ここで、ビジネスサイドからスコープ削減が許可されることはまれだと思います。（大体の場合、「頑張れ」「生産性上げろ」となりがちです。）
しかし、事前に早い段階でステークホルダーに規模感を伝えることで、短期間で実行するリスクを会話できるため、成果物の可視化は有効的なアプローチになります。
2.プロセスを定義する
ここまでで成果物が定義できました。ここからは、成果物を作る作業（プロセス）を考えます。
2-1.全体のアプローチを決める
プロジェクトの特性にもとづき、全体のアプローチを決めます。
たとえば、とにかく早く世に出したいWebサービス系のシステム開発であれば、最小限の重要な機能を優先的に作成し、それ以外の機能を別フェーズで作成する。などです。（下図:Lv2）
2-2.成果物の作成プロセスを定義する
まず、「1-1.成果物の構成とそれぞれの繋がりを可視化」で作成した成果物関連図の各成果物をどういった作業で作るか成果物関連図上で分類します。
次にその分類をWBSツリーに当てはめます。
下図のWSBツリーでは、成果物をLv6、成果物を作成するプロセスをLv3〜5で定義します。
Tips：あえて成果物関連図にプロセスを記載しないケース
成果物を作成するプロセスで分類する時、同じ成果物（ドキュメント）でも分類したい場合があります。
例えば、要件定義の成果物で、ヒアリング先の部門ごとの分類、既存業務/あるべき業務、基本設計の成果物であれば機能別の分類をしたい時です。
ただ、これら分類を成果物関連図に記載してしまうと、関連の線が増え成果物関連図の可読性が著しく低下します。よって下図のWBSツリーLv5のような分類をしたい場合は、WBSツリーにのみ表現し、成果物関連図には登場させない事を推奨します。
最後に成果物をアウトプットするプロセスをLv7に定義します。
下図では、ドラフトを作成⇒レビューを実施⇒レビューの指摘内容を修正し、修正確認をして完成。というプロセスにしています。
Tips：成果物のアウトプットプロセスはメンバーのスキルを考慮する
アウトプットプロセス（上記のWBSツリー（Lv7））の基本形は、図示したドラフト作成⇒レビュー⇒修正・修正確認です。
しかし、メンバースキルによっては以下のように、レビューを多段階にわけることを推奨します。せっかく作ったあとに全部やり直し。という手戻りを防げます。
①章立てレビュー
②箇条書きレベルで記載内容レビュー
③文章レビュー
③図のレビュー
④日本語（てにをは）レビュー
最後に、プロセスを設計する時に注意が必要なことが1つあります。
それは、最初から全体を成果物のアウトプットプロセスのレベルに落とさない。ということです。（上記のWBSツリー（Lv7））
人は細かくすればするほど“管理の精度が上がる”と錯覚し、さらにやりきった感も生まれます。真面目な人ほど詳細化をしがちです。特にウォーターフォール型のアプローチを取った際にこの罠にはまりがちです。
しかし、未来になればなるほど不確実性は高くなります。
せっかく、精密に作成したWBSがメンテナンスしきれず、形骸化し利用されなくなったり、ひたすら修正するはめになったことはないでしょうか？
これを防ぐコツは、プロセス定義は直近の活動までにとどめ、未来の活動を段階的詳細化（progressive elaboration）する、ローリングウェイブ技法を使うことです。
Tips：ローリングウェイブのポイント
・全体の可視化はプロセス（中分類〜小分類）までに抑える（上記のWBSツリーのLv4〜5）
・直近1ヶ月分の作業だけ最小単位に落とす（上記のWBSツリーのLv7）
・最小単位にしていないプロセスは、いつ詳細化するか（Lv7まで落とすか）決める（次のプロセス開始の2週間〜1ヶ月位前が良い）
3ヶ月以上先の作業のWBSに「初版作成⇒レビュー⇒修正⇒修正確認」などの1つずつの成果物を仕上げるプロセスが登場したら要注意です。本当に今時点でそこまで詳細化が必要か考えましょう。
おわりに
WBSは成果物＋プロセスという複合的な情報から成り立ちます。
作業がなんとなく見通せている状況におかれると、見えている情報から、ついプロセス指向でWBSを作成したくなります。しかし、作業開始後に抜け漏れが見つかると手戻りが発生します。
急がば回れ。はじめは成果物を可視化することから始めましょう。
もちろん先に作業（プロセス）の枠組をきめて、最小の成果物を定義するというトップダウンのアプローチを否定はしません。しかし、このアプローチで抜け漏れのないWBSとスケジュールを作成できる人は、その領域での経験が豊富な熟練のPMです。慣れないうちは本稿で説明したボトムアップの成果物指向のアプローチで始めることをお勧めします。
この「現場で使える！コンサル道具箱」では、その名の通りすぐに現場で使えるコンテンツを無料でご提供している note です。あなたの欲しい道具が探せばあるかも？ぜひ他の記事もご覧ください！