PMPは、米国のプロジェクトマネジメント協会であるPMI（Project Management Institute）が、プロジェクト管理の専門家であることを認定する国際資格です。資格を取得するにはプロジェクト管理の知識だけではなく経験も必要となります。また、取得後も3年ごとに必要単位を取得の上、更新が必要となる実務重視の資格です。
そのPMIがプロジェクト管理に関する知見を体系的にまとめたガイドブックがPMBOK（Project Management Body of Knowledge）です。PMBOKには、プロジェクト管理に必要なプロセスが定義されており、現在、プロジェクトマネジメントの世界標準となっています。そのPMBOKでは、プロジェクト管理の目的を「プロセス管理によるQCDの達成」と定義しています。
Quality（品質）、Cost（コスト）、Delivery（納期：スケジュール）の略称で、プロジェクトで達成すべきゴールです。従来のプロジェクトでは、QCDのみを管理することに焦点が当てられていましたが、QCDのみの管理ではプロセスを管理することができず、結果的にQCDも満足に達成できません。そのため、QCDに加えプロセスもしっかりと管理するという考えが広がりました。PMBOKでは、プロジェクト管理のプロセスを10の管理エリアと5つのプロセス群に体系立て整理して知識がまとめられています。
10の管理エリアは、「品質」、「コスト」、「デリバリー」、というQCDに加え、「スコープ」、「資源」、「コミュニケーション」、「リスク」、「調達」、「ステークホルダー」、さらにすべてを取りまとめる「統合管理」で構成されています。また、「立上げ」、「計画」、「実行」、「監視・コントロール」、「終結」という5つのプロセスを定義し、10の管理エリアと5つのプロセス群にプロセスを分類しています。
今回は、10の管理エリアの中でスコープに関する知識をまとめているプロジェクト・スコープ・マネジメントに焦点を当て、その中でWBSの作成を実践していきます。
プロジェクトを立ち上げ最初に計画するのがプロジェクトのスコープです。
プロジェクト・スコープ・マネジメントの目的は、プロジェクトを成功させるために必要なすべての作業、かつ必要な作業のみがプロジェクトに含まれることを確認することです。プロジェクトの立ち上げの際に定めたプロジェクト憲章やプロジェクトマネジメント計画書等を元にスコープ・マネジメント計画書を作成し、スコープを管理するプロセスを定義します。そのスコープ・マネジメント計画書に従って、ステークホルダーのニーズや要求事項を収集し、プロジェクトのスコープを定義します。定義したスコープは、プロジェクト・スコープ記述書という形で成果物や必要な作業をまとめますが、そのプロジェクト・スコープ記述書等を元にスコープを具体的な作業としてスケジュールを立て進捗を管理できるレベルにまで階層的に分解します。この分解したものをWBSと言います。
日本語では作業分解構成図と言われることもあります。プロジェクトの各工程を作業者が担当できるレベルまで分解し構造化してまとめたもので、WBSを作成することによって、やるべき作業が明確になり、スケジュールの計画やコストの見積をすることができます。
PMBOKでは、WBSを作成し、スケジュールを立て進捗を管理できるレベルである最下層の構成要素（ワークパッケージ）まで分解するために、次の活動を行うと定義されています。
それぞれの活動についてもう少し詳しく見ていきましょう。
まず、WBSを作成する際のインプットとなるプロジェクトの成果物やその成果物を生成するために必要な作業をプロジェクト・スコープ記述書等から特定します。
特定した情報をベースにWBSを作成していきます。WBSは成果物や必要な作業を階層的に要素分解しますが、その際に、ロジックツリーを活用して分解していくと整理がしやすくなります。ロジックツリーは構造上、上位要素と下位要素、同レベルの横串の要素間を把握しやすい構造になっています。上の階層と下の階層の項目で上下関係が成り立つか、横串で見た時に他に何か項目がないかを発想しやすくなります。
また、ロジックツリーを使って要件を整理することで、「森（全体）」として見た時によさそうでも、「枝（部分的）」として見た時に検討しきれていない等、部分的にフォーカスして検討しやすくなるという利点もあります。
WBS作成の中で上位のレベルから下位のレベルにより詳細に要素分解していく際には、MECEであることを意識して上位レベルの構成要素＝下位レベルの構成要素群となるように構造化すると良いです。MECEは、Mutually Exclusive and Collectively Exhaustiveの略で「漏れなく、ダブりなく」ということです。物事を考えるときに、必要な要素を漏れなく抽出しつつ、抽出した要素が重複しないようにする考え方です。
要素を階層化し終えたら、各要素に識別コードを割り当てますが、WBSの構成要素に付与される一意の識別子をWBSコードと呼びます。WBSコードは、コストやスケジュール、資源等を集計するために使用します。
最後に完成したWBSが必要十分であるかを検証します。成果物が網羅されているか、スケジュール管理できるレベルに作業が落とし込まれているかを確認することは勿論のこと、作成時点で要素分解しきれないところはないか、WBSの見やすさも検証します。その際に役立つルールを2つご紹介します。
「将来のことは分からない」ことを前提に、予測がつきにくい将来のことは大まかな計画で留め、直近の作業の計画を詳細に検討するという段階的詳細化の考え方です。要素分解の際に詳細化するのが難しい将来に作成する成果物は、その時点で分解できるまでで留めておき、時間の経過とともにより正確に検討できるようになったら分解しましょう。
またをミラーの法則と言います。人間が瞬間的に保持できる情報の数は「7±2」であるという理論で、1つの親の要素にぶら下がる子の要素数は7つまで、WBS全体は7階層までという子の数と、階層の深さについての目安となる考え方です。階層、数が多くなるとWBSが見づらくなり、実用性が低くなります。階層や数が多くなる場合は、あらたな枝を作る、またはプロジェクトを分けることを検討しましょう。ただ、あくまで「目安」ですので、必ず7つまでに納めなければならないわけではありません。
それではここまでご紹介したWBS作成の活動を踏まえて実際にWBSを作成してみましょう。テーマは「カレーを作る」です。WBSのインプットとなるプロジェクトの成果物やその成果物を生成するために必要な作業は、本来であればプロジェクト・スコープ記述書等から特定しますが、今回はレシピ本をプロジェクト・スコープ記述書に見立てます。
WBSを作成する際の活動にもあるように、WBSを構造的に作っていくためにロジックツリーを使いましょう。ロジックツリーを用いて構造的にかつ組織的に、上位の下位のWBSレベルへとより詳細な構成要素へ分解します。今回は、弊社のiQUAVISというツールを使って要素分解をしていきます。
カレーの作り方を、レシピ本を元に下位要件に要素分解していくと「材料準備」「下ごしらえ」「調理」「盛り付け」の工程に分解できそうです。要素分解の際に意識するのがMECE（「漏れなく、ダブりなく」です。上位＝下位を意識して、「カレーを作る」＝「材料準備」＋「下ごしらえ」＋「調理」＋「盛り付け」であるか確認します。
さらに各工程を下位のWBSレベルに要素分解していきます。各要素をスケジュール管理できるレベルの作業まで落とし込みます。また、現時点で詳細化するのが難しい要素は、その時点で分解できるまでで留めておきます。ローリング・ウェーブ計画法、段階的詳細化の考え方です。
今回は、「盛り付ける」の際のイメージがまだ固まっていないので、以降の要素分解は一旦ストップすることにします。
一通り要素分解ができたら、分解した要素に対してWBSコードを割り当てます。WBSコードは一意である必要がありますので、重複しないように気を付けます。また、要素が途中追加されることも想定して枝ごとに区別できるように割り当てるとよいでしょう。
すべての要素にWBSコードを割り当てられたら、最後に完成したWBSが必要十分であるかを検証します。漏れなく、ダブりなく分解できているか、また、今後プロジェクトの中でコストやスケジュール、資源等を集計するためにも使っていきますので見やすさも確認しましょう。最も重要なことは、ベースラインがスケジュール管理できるレベルの作業まで落とし込まれているかです。ベースラインとなっている要素が担当者に割り当てられるレベルの作業になっているか確認しましょう。
確認ができたらWBSの作成は完了となります。この後、それぞれのベースラインに対してアクティビティを定義していきます。WBSは様々なパターンがあり、実践したものはその中の一例となりますが、ご参考になれば幸いです。
最後に、今回のWBSの作成には弊社のiQUAVISを用いています。iQUAVISはISIDが開発した「開発の見える化」をコンセプトとしたツールです。あるテーマに関連する情報をツリー図やブロック図、二元表、日程表など様々な画面を用いて、体系立てて管理、共有、活用することができます。今回はカレーの作り方をテーマにiQUAVISを用いて要素分解しましたが、そもそもお客様に満足いただくにはどのようなカレーにすればよいのか、そのためにはどのような特徴があればそのカレーを実現できるのか、といったテーマの要件や、そのカレーを作るためにはどのような材料や調味料の分量が必要かといった、テーマを実現する手段の因果関係を導くことにも適しているツールです。本サイトにもiQUAVISの紹介ページや操作体験のワークショップ等をご用意しておりますので、ぜひご覧ください。
入社以来長らくPLM「Teamcenter」を担当し、お客様のPLM導入による設計・製造データ管理の最適化を支援。現在はPLM担当時の経験を活かし、iQUAVISを用いたお客様のプロジェクト管理、製品の成り立ちの見える化、不具合未然防止活動を支援。2019年にPMPを取得。
