プロジェクト管理の手法として知られるスコープマネージメントをご存じでしょうか。ビジネスにおけるプロジェクトを成功へ導く管理手法として有名ですが、詳しく理解している方が少ないのも事実です。
本記事では、プロジェクトスコープの概念や作成方法、注意点などを解説します。
プロジェクトスコープとは
「プロジェクト」とは、目的を達成するための計画を指し、「スコープ」は範囲を意味します。そして「プロジェクトスコープマネージメント」とは、プロジェクトの範囲を明確に定め、成功へと導く管理手法のことです。
プロジェクトが失敗してしまう原因は多々考えられます。しかし代表的な失敗原因は「スコープを定めていなかった」というものです。つまり、プロジェクトスコープマネージメントの失敗に由来するものです。
目的を達成するために遂行すべき業務の範囲を明確にしていなければ、無理や無駄が生じ、結果的にプロジェクト全体が失敗に至ってしまうでしょう。スコープが曖昧では、担当者もどこからどこまで手をつけてよいのかわからず、本来必要のない作業をしてしまう恐れが強まるのです。
プロジェクトのスムーズな達成には、遂行すべき業務の範囲を定め、そうしたリスクは軽減させることが重要です。
このような理由から、プロジェクトスコープは「PMBOK（プロジェクトマネージメントのフレームワーク）」における、行うべきプロセスの1つとして組み込まれています。PMBOKは、プロジェクトマネージメントの世界標準。そこへ1つの計画項目として定められていることからも、プロジェクトスコープの重要性が、国際的にも高く認識されていると理解できるでしょう。
プロジェクトスコープと成果物スコープとの違い
プロジェクトスコープは「やるべきこと」の範囲です。一方、成果物スコープは「何を作るか」を定めたものを指します。前者は作業範囲、後者は作るものの範囲と考えればわかりやすいのではないでしょうか。
例えば、自社で車を開発しようとしているのなら、基本コンセプト設計、テストカーの製作、製造、試乗テストなどが必要です。これらのプロセスをより細分化し、それぞれに必要な作業の内容をピックアップします。これがきちんとできていないと、無駄な作業の発生をはじめとしたさまざまなトラブルが発生しかねません。
では、このケースにおける成果物スコープは何なのでしょうか。テストカーの製作で考えれば、設計図や仕様書、テストカー本体などが挙げられます。何を作るかを決めておけば、現物でプロジェクトの進捗をチェックできることがメリットと言えるでしょう。
プロジェクトスコープ作成のステップ
プロジェクトスコープを作成するには、正しいステップを踏む必要があります。大まかな決め方や作成の流れとしては、「計画立案・要件の収集・スコープ定義・WBS作成・スコープの実証・スコープコントロールの実行」といった手順を踏みます。詳しく見ていきましょう。
スコープマネージメント計画
スコープの定義やマネージメントの方針などを作成します。計画以降のプロセスにおける、全体的な方針を定める段階、といえばわかりやすいでしょうか。例えば、次に紹介する「要件の収集」を行うにあたり、どのように収集するのかを決めることがスコープマネージメント計画の目的です。
このプロセスでは、スコープマネージメント計画書と要求事項マネージメント計画書を作成します。前者は、スコープの妥当性を確認する基準を明記し、後者にはどのように顧客の要求を収集するかを記載します。
要件の収集
クライアントや取引先など、プロジェクトに関わる関係者から要件の収集を行うプロセスです。収集するだけではなく、要求事項文書や要求定義書に文書化するまで、一連の流れとして実行します。
プロジェクトを完遂するには、利害関係者のニーズを満たさなくてはなりません。関係者のニーズや要望を基に見積もりも行うため、コストにも大きく関わります。そうした理由からも、非常に重要なプロセスと言えるでしょう。
利害関係者のニーズや要望を正確に汲み取り、プロジェクトへ反映させるには丁寧なヒアリングが必要です。そのため、実際の要件収集においては、インタビューや話し合いなどを通じて具体的な要望を抽出します。
スコープ定義
利害関係者たちから汲み取った要望、ニーズに基づき、作業や成果物の範囲を明確に定義するプロセスです。つまり、「何をするのか・何を作るのか」をここで初めてきちんと文書としてまとめるのです。
このプロセスでは、プロジェクトスコープ記述書を作成します。どのような作業を行い、どういったものを作るかを、記述書に記載します。
作業分解図（WBS）の作成
「WBS」とは、「Work Breakdown Structure」の頭文字をとって略したもので、日本語では作業分解図、もしくは作業分解構成図を意味します。このプロセスでは、プロジェクトスコープ記述書や要求事項文書を基に作業を分解し、WBSへ落とし込みます。
作業や成果物を、階層構造に分解することがWBSの特徴です。個人が引っ越しをするケースで考えてみましょう。この場合、「まず引っ越し先の決定→退去や入居のタイミングの決定→荷造りに必要な段ボール等資材の買い出し→荷造り→積載と運搬→新居への搬入」といった具合に作業を細分化できます。
このように、作業を細分化すれば、行うべき作業を漏れなく洗い出せます。また、作業を細分化することにより、ワークパッケージにまで落とし込むことができ、スケジュールをより明確に提示したり、細かく見積もりを出せたりするのもメリットと言えるでしょう。これは、利害関係者に安心感を与えられます。
スコープの実証
完成した成果物が、利害関係者のニーズに沿ったものに仕上がっているかどうかを検証するプロセスです。実際にクライアントに要素成果物を提示し、確認を受け、受け入れ済み要素成果物へと移行させる段階です。
この際、クライアントのニーズを満たせていない、もしくは何かしらの問題を確認した場合には、状況に応じてスコープの範囲を調整するなど、是正処置を行わねばなりません。
スコープコントロール
スコープを定めても、その状態が継続されるとは限りません。初期段階では問題なくプロジェクトを進められていても、途中で問題が発生してしまうことは十分考えられます。
そのため、スコープを定めてからも作業の範囲や成果物の品質を監視し、状況に応じて変更を行う必要もあります。計画時と作成段階での製品品質に差異が生じた状態でプロジェクトを進めても、クライアントのニーズを満たすことはできません。
プロジェクトスコープ作成時の注意点
プロジェクトスコープを作成するにあたり、いくつかの注意点を把握しておきましょう。大切なポイントはいくつかありますが、特に重要なのは関係者間における目的共有と、スコープの可視化による情報共有です。詳しく見ていきましょう。
プロジェクト関係者の目的共有
プロジェクト関係者全員が満足して、初めてプロジェクトは成功したと言えます。成功へ導くには、関係者間における目的共有が大切です。
クライアントの要求を一番に考えるのは当然であり、素晴らしいことですが、もしかするとその要求は目的に適していないかもしれません。クライアントの知識不足や勘違いにより、目的に適さない要求を伝えてくる可能性は十分あるのです。
「クライアントの意見が第一だ！」とそのままプロジェクトを進めてしまうと、失敗してしまう恐れがあります。このようなことが起きないよう、クライアントの要求が目的に即したものかどうか、しっかり判断しなければなりません。プロジェクト関係者間で目的共有を入念に行い、そのうえでクライアントの真の目的、ニーズを導き出しましょう。
スコープを可視化して共有
プロジェクトに関わる作業者たちはもちろん、クライアントともスコープを共有しましょう。可視化することにより、要件や要望をその都度確認できるからです。可視化していない状態でプロジェクトを進めてしまうと、要件漏れが生じる恐れがあります。
初期段階で要件漏れに気づけば小さなダメージで済みますが、終盤にさしかかって気づくと大変です。場合によっては初期のプロセスからやり直しせざるを得なくなり、大幅にスケジュールが遅延してしまう恐れもあります。
これまでの作業が無駄になってしまう可能性もあり、再度最初からやり直しとなるとコストもオーバーしてしまうでしょう。このような事態を招かないためにも、スコープを可視化して関係者全員で情報を共有しなければなりません。
スコープを可視化するといっても、それほど難しいことではありません。きちんと文書にして、関係者が確認できる体制を整えればよいのです。機密性の高いプロジェクトなら、電子文書としてクラウド保存し、関係者だけにアクセス権を付与するとセキュリティ面でも安心です。
認識の食い違いや、要件漏れの早期発見を防ぐため、必ずスコープの可視化を心がけましょう。
まとめ
スコープマネージメントは、プロジェクトをスムーズに成功へ導くために必要です。さまざまなリスクを回避するのにも役立ち、プロジェクトメンバーのモチベーションアップ効果も期待できます。クライアントのニーズをきちんと満たし、満足度を高めるためにも、スコープマネージメントは重要な役割を果たします。
このスコープマネージメントを容易にするためには、業務全体を可視化するツール、「Asana」を導入すると効率的です。Asanaは、仕事を一元化できるツールとして、既に多くの企業が導入しています。さまざまな外部ツールとも連携でき、プロジェクトチーム間でのコミュニケーションを円滑化します。無料トライアル期間もあるため、まずは気軽に試してみてはいかがでしょうか。
