ホーム " ブログ " 効果的なプロジェクト・スコープ管理への4つのステップ

数ヶ月前、プロジェクトマネージャー向けの有名なオンラインプラットフォーム「Project-Management.com」が、次のような記事を掲載した。 プロジェクト失敗の原因トップ10.この文章に目を通しただけでは、プロジェクトのスコープマネジメントについては何も書かれていない。しかし、よく読んでみると、著者が述べている要素が、プロジェクトのスコープを定義し、コントロールすることに非常に関係していることがわかるだろう。

この記事のおかげで何が得られるだろう：

準備不足 が故障の原因の第1位とされ、以下はそれに続いた。 不十分な文書化と追跡。 リストは以下のように閉じられる。 プロジェクトの警告サインを無視する。 このブログ記事は、プロジェクトのスコープを効果的に管理することで、これらの危険性を軽減または排除することを目的としているからだ。

スコープ・マネジメントは準備から始まり、適切な文書化とプロジェクト進捗のモニタリングと表裏一体であることをご理解いただきたい。プロジェクトの警告サインは？より不吉な兆候の一つがスコープクリープであることがおわかりいただけるだろう。幸いなことに、スコープマネジメントを成功させれば、それを避けることができる。

まず、このガイドで使用する最も重要な用語の定義から始めよう：

プロジェクト・スコープ・マネジメントとは何か？

スコープは？

哲学者たちがよく言っていたように、私たちが使う用語の理解なくして、理解などまったくないのだ。では、「スコープ」とは何を意味するのか？

まず、プロジェクトマネジメントのサークル外の機関、つまりオックスフォード辞典による定義から始めよう。この辞書のおかげで、プロジェクトマネジメントの2つの意味を知ることができる。 範囲 用語。第一に、スコープとは単なる可能性であり、機会であり、そして 資源容量変化する可能性、達成する可能性、何かをする可能性。しかし、2番目の意味は、プロジェクトマネジメントの社会と十分に近いので、引用する価値がある。スコープとは

(ある対象、組織、活動などが扱う物事の範囲

(オックスフォード辞典）

プロジェクト・マネジメントの範囲は？

上の定義と次の定義を比較すると、次のようになる。 プロジェクト・マネジャーの間ではよく知られていることだが、その関連性はおわかりいただけるだろう。

プロジェクトマネジメント協会（Association for Project Management）のおかげで、私たちは「スコープ」とは、結果、成果、利益の全体と、プロジェクトを実現するために必要な作業を指すことを知ることができた。つまり、プロジェクトの全要件をアウトプットする（つまり、製品を成功裏に納品する）ために必要な作業、および／または適切なスキルを持った従業員のことである。

誤解を避けるために言っておく。この意味は、「似ている」という響きよりもやや広い。 製品範囲。 製品スコープ - 一般的に言えば - 製品やサービスの特徴と機能の詳細。一方：

プロジェクト・スコープとは、製品のスコープ（必要な機能や特徴）に従って製品を提供するために行わなければならない作業のことである。

（Wrike.com）。

プロジェクトのスコープ管理とは？

プロジェクト・スコープ・マネジメントとは何か？プロジェクトマネジメント協会の場合

スコープ管理とは、アウトプット、成果、利益を特定し、定義し、管理するプロセスである。スコープ」とは、プロジェクトのマネジメントで使われる用語で、アウトプット、成果、便益の総体、およびそれらを生み出すために必要な作業を指す。

(APM知識体系第7版)

しかし、古いバージョンでは PMBOK®ガイド第6版 プロジェクト・スコープ・マネジメントとは、プロジェクトに以下のような要素が含まれていることを確認するためのプロセスです。 必要な仕事をすべて、必要な仕事だけをする。

簡単に言うと、第7版によるプロジェクトスコープ管理とは、プロジェクトのあらゆる側面に関する知識を獲得し、文書化するための時間と手順（プロセス）と解釈できる。そして、プロジェクトスコープマネジメントプロセスの結果は、プロジェクト計画に含まれるべきすべてのリスト（タスクとサブタスク、予算、責任など）である。

しかし、第6版では、必要な仕事（および／または、適切な経験を積んだ社員）、プロジェクトに必要な仕事を強調している。最後の観点からは、プロジェクトマネージャーは、期待された要件で期待されたプロジェクトを期待された時間内に遂行することができる（スキルと経験のおかげで）人材、あるいはリソースに焦点を当てるべきである。

この章の最後に、次の言葉を引用してまとめよう。 プロジェクトマネジメント知識体系への手引き

プロジェクトのスコープを管理することは、プロジェクトに何が含まれ、何が含まれないかを定義し、管理することに主眼が置かれる。

(PMBOK®ガイド第7版)

効果的なプロジェクト・スコープ・マネジメントはどのようなメリットをもたらすのか？

競合他社であり、また有名なプロジェクトでもある。 資源管理ソフトウェア プロバイダーは、プロジェクト・スコープ・マネジメント・プロセスの結果と目標をウェブサイトに掲載している。

プロジェクト・スコープ・マネジメントとは、プロジェクトの目標、タスク、成果物、期限、予算などのリストを決定し、文書化するプロセスである。

（キスフロー・ドットコム）

見てわかるように、これはプロジェクトプランが含むべきすべてのものの目録である。そして プロジェクトスコープ管理の主なメリットは、プロジェクトを成功に導くことができることです。このプロセスのおかげで、あなたは何をすべきか（そして何をすべきでないか）を知ることができ、より自信を持ってチームを管理することができる。

このプロセスの利点は他にもある：

 

PGAを開発する際に考慮すべき計画と手順プロジェクトのスコープ管理 

以下のステップは、プロジェクトマネジメント知識体系（PMBOK®）に基づいています。包括的なスコープマネジメントプランをお探しの方は、必ずその解説をご覧ください。以下では、スコープマネジメントのプロセスを紹介します。

プロジェクト・スコープ管理計画の作成

スコープ・マネジメントの計画は、前もって準備することから始めるべきだ。要件を収集し、プロジェクトのスコープを立案する前から、それをどのように進めるかを計画しておく。このプロジェクトのスコープについて発言する主なステークホルダーや人々を特定する。

チームとミーティングを行い、スコープを作成するプロセスがどのようなものかを確立する。プロジェクトのスコープを変更する可能性についても考えておくとよいでしょう。もちろん、この時点では、何が変更される可能性があるかはわからないでしょうが、変更が発生した場合にどうするかを決めることはできます。

ここで決定したことはすべて、スコープマネジメント計画にまとめましょう。これは、残りのプロセスを行うための指針となる文書となる。

要件を収集し、プロジェクト範囲を定義する

プロジェクト要件を収集する時期が来ました。プロジェクトの目標を達成するために行わなければならないことです。クライアントのところに行って、次のように尋ねるほど単純なことではありません。 最終製品をどのように見せ、どのように振る舞わせたいか？ 要求の収集は発見のプロセスであり、利害関係者はこの時点では、どの特定の機能を製品に含めるべきかさえ知らないかもしれない（特に、ソフトウェア開発関連のプロジェクトを管理する仕事を任されている場合）。)

もちろん、顧客は最終製品の正確なビジョンを持っていないかもしれないが、おそらくこのプロジェクトが達成すべきビジネス目標を認識しているはずだ。あなたは、ユーザーのニーズを明らかにするために一連のワークショップやインタビューを行い、その結果、要件を確立することができます。

データに基づく要件を収集するもう1つの方法は、プロトタイプを使って一連のテストを実施し、どの機能や特徴がターゲットユーザーから最も好意的な反応を得られるかを確認することである。

また、ベンチマークを行って、あなたの潜在的な要件と業界のベストプラクティスを比較することもできます。

さまざまな要件（特徴と機能、ビジネス目標、製品を提供するために必要なプロセス、受け入れ基準）のリストができたら、スコープを定義してみましょう。通常、最初に集めた要素のすべてが最終的なプロジェクトスコープになるわけではないことを覚えておいてください。

プロジェクトのスコープを定義することは、いわゆるスコープ・ステートメント文書を作成することを意味する。スコープ・ステートメントとは、プロジェクトのスコープを文書化したものです：

ヒント：スコープ・ステートメントにも除外事項を文書化するのは良いアイデアかもしれません(XとYはプロジェクト・スコープに含めない).後で期待値を管理し、スコープの変更を交渉しなければならないときに役立つだろう。

作業内訳構造（WBS）の作成

このステップは、スコープをよりよく視覚化し、より小さな要素に分解するのに役立つ。ワーク・ブレークダウン・ストラクチャーは、プロジェクトのアウトプットに対応する成果物の階層的な枠組みである。

伝統的に、WBSは以下のことを記述している。 何 そして どのようにそのため、アクティビティではなく、成果物に焦点を当てるべきである（例． 支払い よりも 支払い経路の設計、開発、テスト).もう一つの考え方は、WBSは "クライアントが受け取るもの "を記述するものであり、"プロジェクトチームがどのような行動をとるか "を記述するものではないということだ。しかし、プロジェクトマネジャーの中には、WBSをタスクとサブタスクの内訳のように扱う人もいる。

そもそも、なぜわざわざWBSを作る必要があるのか？まず、成果物が細分化されていると、スケジュールを立てやすくなります。また、頼りになるWBSがあれば、より快適にタスクを作成し、割り当てることができる。 

最後に、このような階層構造は、特に視覚的な思考をする人であれば、プロジェクトのスコープをより早く把握することができる。自分がそのタイプかどうかわからない？私たちのガイドをご覧ください Sプロジェクトマネージャーのためのケッチノッティング プロジェクト・マネジメントにおけるビジュアル・シンキングのメリットをご覧ください。

プロジェクト・スコープを検証し、プロジェクト・ライフサイクル中に管理する。

プロジェクトのスコープ・ステートメントとWBSができたので、プロジェクトに何が含まれるべきかがわかった。あとは、ステークホルダーがスコープを検証し、サインオフする必要がある。曖昧な点がないか確認し、プロジェクトが始まる前に最終的な形にする。こうすることで、スコープクリープの可能性を減らすことができる。

プロジェクトが進行しているときは、スコープをコントロールしなければならない。何が行われたのか、何が行われる予定だったのかを監視する。その過程で、おそらく以下のツールが役に立つだろう：

 

比較する プロジェクトレポート をスコープとプロジェクト管理スケジュールと照らし合わせ、タイムライン、作業量、完了したタスクなどが見積もりと一致しているかどうかを確認する。

プロジェクトのスコープを管理するプロセスは、特にその準備の多さを考えると、複雑に見えるかもしれません。しかし、一度試してみれば、プロセスのごく初期に作成する文書（スコープ・マネジメント・プランとプロジェクト・スコープ・ステートメント）が、この先大いに役立ち、チームが取り組んでいる製品やサービスを提供できるようになることがわかるでしょう。

[vc_column_text][/vc_column][/vc_row]。

プロジェクトスコープ管理プロセスを簡単に改善したいですか？

関連記事