プロジェクトマネジメント（第4回）です。
自分の経験上、プロジェクトが迷走することがありました。どんどんプロジェクトの目的が増えてきてしまったり、たいして重要でない目的に多大な労力をかけてしまったり、いつまでたってもプロジェクトが終わらなかったり。それを防ぐためにはこの「Project Scope Management」が有効です。
プロジェクトチャーター（プロジェクト骨子）
を作ったら、次はプロジェクトのスコープをマネジメントするための計画を作ります。自分で書いていても「プロジェクトのスコープをマネジメントする」とは何のことかよく分かりませんね^^;
１．プロジェクトスコープマネジメントとは
「プロジェクトに求められるニーズ（requirements）を明確にし、それをもとにプロジェクトの成果物（deliverables）を定め、その成果物を生み出すためにすべきこと（Scope）を明確にし、何をプロジェクトに含めるのかを決めること」です。
補足：
以前スコープとは「要件」と訳せるのではないかと書きましたが、この言葉は１）product scope（プロジェクトにより生み出される製品やサービス、結果に求められる要件）に加え、２）project scope(その要件を満たすためにしなければならないすべての作業）という2つの意味を含んでいます。
２．Scope statement
プロジェクトスコープマネジメントはいくつかの項目を含んでいますが、ここでは「Scope statement」の作成のみを取り上げます。このスコープステートメントは、プロジェクトの目的を明確にした文書のことですが、以下の5つを含んでいます。
- Product scope description：プロジェクトにより生み出される製品やサービス、成果の詳細。これが最も重要で、プロジェクトにかかわるすべての人が共通認識として、また具体的なイメージが持てるようにすべきです。例えば、ゲームプロジェクトで、担当者は敵キャラクターのデザインだけを担当しているとしても、どのようなゲームを世に送り出すのかといったところは当然認識していなければなりません。
- Deliverables：成果物。１．が最終的な成果であったのに対し、このdeliverablesは中間成果物や、最終的には表に出ないプロジェクト報告書といった内部文書など、あらゆる成果物を含みます。この成果物の一覧をもとに、このあと必要な作業を洗い出していくことになります。
- Acceptance criteria：２）で列挙したそれぞれの成果物が完了したとみなされる基準。これには、例えば、あるビルを建てるのであれば建築基準のような法令も含まれます。
- Project constraints：プロジェクトをする上での制約（予算、人員、資材等）
- Project exclusions：何をプロジェクトから除外するか。この項目は大切です。例えば、あるソフトウェアの開発において、もともとはカレンダーを共有することを主目的としていたのに、データ交換機能を追加したりとどんどん機能が追加され、いったい何のためのプロジェクトであったのかがぼやけてしまったり、費用や時間がかかりすぎてしまうといったことが起こりがちです。こういったことを防ぐために、「関係者からこういったニーズは上がっているけど、このニーズについては今回のプロジェクトでは扱わないこととする」と決めておくわけです。通常、プロジェクトでやることは当然明記されるわけですが、やらないことも明記しておく必要があります。特にプロジェクトが長期にわたり担当者が変わる可能性のある場合は、なぜこのニーズを扱わないことにしたのかという理由も残しておいた方が良いでしょう。
３．WBS（Work Breakdown Structure）
WBSとは「全ての成果物を完成させ、プロジェクトの目的を達成するために行わなければならない作業の一覧表」です。作業の一覧表ではありますが、ピラミッド状に大きな成果物を細分化（Break down）して細かな作業の項目に分けていくところがポイントです。
そして、一つ一つの作業について、作業の内容、担当者、期限、制約、成功の条件、関連する作業（上位下位、前後）等を定めていきます。
このWBSにおいて重要なのは、階層的に作ることが重要です。大きい作業から小さい作業までをごちゃまぜに横一列に並べては意味がありません。例えば、成果物ごとにまとめる、作業の工程ごとにまとめるといった工夫が必要です。
また、このWBSを作るにあたっては、MS Projectなどのソフトウェアの助けを借りた方が良いです。WBSをもとにガントチャートなどの工程表も自動で作成してくれますし、修正も容易です。私の経験では、ExcelでWBSのようなものを作ったことがありますが、とても大変でしたし、修正も大変でした。
４．最後に（自分の感想）
プロジェクトチャーターに次いで、このプロジェクトスコープはすべての作業の発端となるものであり、重要だと感じました。あるプロジェクトを任されるといろいろとやらなければならないことばかりが浮かんできて焦ってしまったり、偉い人にいろいろ言われてどんどん目的が増えてしまったりしますが、まずはスコープステートメントを各項目数行ずつで良いので作成し、関係者の合意をとりつつ、少しずつ作業を階層的に分割していくようにしたいです。
参照：
Project Management Institute. (2017). A guide to the project management body of knowledge (PMBOK guide) (Sixth ed.). Newtown Square, Pennsylvania: Project Management Institute, Inc.
Schwalbe, K. (2015). Information technology project management (Eighth ed.)
