スコープマネジメントと計画書の違いは説明できますか?<サンプル付き>

スコープマネジメントとは

本章ではスコープマネジメントとは何かについて以下の4つの項目で説明していきます。

<スコープマネジメントを説明する4つのトピック>

  • スコープマネジメントはゴールを明確にするために行う
  • スコープマネジメントは計画の最初に行う
  • スコープマネジメントがプロジェクト成功を決める
  • スコープ定義との違い

スコープマネジメントはゴールを明確にするために行う

スコープマネジメントを行う目的はゴールを明確にすることです。プロジェクトは期間内に今までの通常業務とは違うことを行うものです。ゴールが不明確だとチームのメンバーがどこに向かっていけばよいかが分からなくなってしまいます。

プロジェクトは不確定要素が多いのでメンバー自身が自ら考え、動くことが求められます。そうしたときに目的や目標があいまいだとメンバーの自発性をつぶすことになります。

スコープマネジメントは計画の最初に行う

それではスコープマネジメントはいつ行うのでしょうか。プロジェクトには5つのフェーズがあります(下図:プロジェクトライフサイクル)。

そのうち、スコープマネジメントは計画のファーストステップにあたります。

プロジェクトマネジメントの知識体系PMBOKによると計画フェーズでは以下の8つを行うと定義されています。

<計画フェーズでの8つのマネジメント>

  • スコープマネジメント
  • タイムマネジメント
  • コストマネジメント
  • 品質マネジメント
  • 人的資源マネジメント
  • コミュニケーションマネジメント
  • リスクマネジメント
  • 調達マネジメント
  • ステークホルダーマネジメント

このほか全体をまとめる統合マネジメントがありますが、それは各計画工程の統合です。

スコープマネジメントがプロジェクト成功を決める

ここではスコープマネジメントの重要性を説明したいと思います。

例えば、長距離走を考えてみましょう。いつ終わるかもわからず終了の合図があるまでひたすら走らされ続けるのは非常につらいものですよね。

逆にゴールが明確であれば、そこを目指して走ることができますし、もしつらくても給水所や休憩所がどこにあるかわかっていれば、まずはそこまでを目標にできます。

これがスコープマネジメントの効果です。

スコープマネジメントはプロジェクト成功のカギとなるとよく言われます。

それは組織が期限内にゴールにたどり着くための地図の役割となるのです。

スコープ定義との違い

スコープマネジメントとスコープ定義は少し意味が違います。スコープマネジメントはスコープ定義も含めたスコープに関する一連の作業やアウトプットをどういう基準で行うか、どういう方法で行うかを定義したものです。

もちろんスコープの定義はとても大切です。しかし、スコープマネジメントも同様かそれ以上に大切です。

スコープマネジメントがうまくいかなければスコープ定義の工程がおざなりになってしまうからです。

スコープマネジメントの構成要素

ここからはスコープマネジメントの構成要素とアウトプットを説明していきます。

<スコープマネジメントの工程>

  • スコープマネジメント計画
  • 要求事項収集
  • スコープ定義
  • WBS作成
  • スコープ妥当性確認
  • スコープコントロール

スコープマネジメント計画

まず最初にスコープ定義のための管理方法の定義を行います。具体的には以下の2つのアウトプットを作成することとなります。

ここで注意していただきたいのはスコープマネジメントが要求事項収集やスコープ定義などの次に続くものも含めた作業群なのに対して、スコープマネジメント計画はそれらの管理手法を指すことです。

<スコープマネジメント計画工程でのアウトプット>

  • スコープマネジメント計画書
  • 要求事項マネジメント計画書

スコープマネジメント計画書

まずスコープマネジメント計画書とはスコープマネジメント全行程の管理方法を計画する資料となります。

スコープ定義の体制や方法、WBSの作成方法などもこちらに記載します。

メンバーに対して上記のようなタスクをどの手法で行うか、承認や報告のタイミングなどを定義すると考えておくと良いでしょう。

要求事項マネジメント計画

要求事項収集マネジメント計画は特に要求事項に対するメンバーの行動方針や収集の方法等を記載します。

例えば、顧客からヒアリングをするのか、アンケートをとるのか、デスクトップリサーチの絞り込むを最初に行うか等です。

さらに要求の品質管理基準もこちらで定義します。

顧客から上がってきた要求は最終的に委員会や会議体などで正式に承認されて初めて、要求とする。などです。

こちらがあいまいだと今後の要求変更の対応で要求が発散してしまい、プロジェクトが炎上してしまいます。

要求事項収集

次に要求事項の収集を行います。

アウトプットは以下の2種類です。

<要求事項収集におけるアウトプット>

  • 要求事項文書
  • 要求事項トレーサビリティマトリックス

要求事項文書

要求事項文書はその名の通り顧客の要求を文書にまとめたものです。具体的には以下の6つのカテゴリごとにまとめていきます。

要求の分類詳細
ビジネス要求事項組織のなりたい姿や経営ニーズなど
ステークホルダー要求事項今回のプロジェクトにおけるステークホルダーのニーズ
ソリューション要求事項プロダクトやサービスのニーズ。機能要求や非機能要求なども。
移行要求事項導入や規制の変更ニーズ
プロジェクト要求事項プロジェクトのプロセスや資料形式のニーズ
品質要求事項品質におけるニーズ

また要求の収集方法はインタビューやフォーカスグループインタビュー、ワークショップ、アンケート、プロトタイプ、ベンチマーク、文書分析などがあります。

これらの方法で集まった情報を上記のカテゴリごとにまとめていきます。

要求事項トレーサビリティマトリックス

要求事項文書で承認された要求事項をプロジェクトのライフサイクルを通して追跡することが求められます。そしてその追跡表のことを要求事項トレーサビリティマトリックスと呼びます。

スコープ定義

要求が収集出来たら次はスコープ定義を行います。スコープ定義では前提や制約となる条件や、プロジェクトのスコープと除外事項をスコープ記述書を作成します。

以下の記事に詳細をまとめてあるのでこちらもご確認ください。

WBS作成

スコープの定義を行った後はWBSを作成します。必要な作業を機能や製品、成果物、タスクと順に落とし込んで構造化していきます。

それを作業分解構造図(WBS:Work Breakdown Structure)と呼びます。

WBSに関してはこちらの記事のテンプレートをご確認ください。

スコープ妥当性確認

スコープ妥当性確認とは完成した成果物を正式に受け入れるプロセスです。

具体的には以下の2つをアウトプットとします。

  • 受け入れ済み成果物
  • 変更要求

これらは正式に受け入れられたのが「成果物受け入れ」に記述され、受け入れられなかった成果物が理由とともに「変更要求」として処理されます。

スコープコントロール

最後にスコープコントロールで変更を追跡、可視化して制御します。

以下の2つの情報を確認します。

  • 作業パフォーマンス情報
  • 変更要求

ここでのポイントは承認を経ない変更をさせないことです。

たとえ簡単な要求や、メンバーの気遣いだったとしてもメンバーレベルでの変更が出てしまうとプロジェクト全体への影響を考慮できておらず後々プロジェクトの遅延や炎上につながります。

現場で顧客と接する機会が多いメンバーは「顧客のために」や「簡単な修正だから」と考えてしまいがちですが、上記のような理由から必ず変更は管理するようにしましょう。

スコープマネジメント計画書の作成方法とサンプル

それではここからスコープマネジメント計画書の作成方法をご説明していきます。サンプルはこちらからダウンロード出来ます。

スコープマネジメント計画書テンプレート<新規事業開発ノート>

具体的には以下の2つのマネジメント計画書をご説明します。

  • スコープマネジメント計画書
  • 要求事項マネジメント計画書

スコープマネジメント計画書

<スコープマネジメント計画書の項目>

  • プロジェクトスコープ記述書作成プロセス
  • WBS作成プロセス
  • WBS維持承認プロセス
  • 受け入れプロセス
  • 変更要求コントロールプロセス

プロジェクトスコープ記述書作成プロセス

プロジェクトスコープ記述書の作成方法を記載していきます。

チーム内での役割分担や作成のための参考情報やアウトプットフォーマット、承認はどのタイミングで誰にもらうのかなどをまとめます。

WBS作成プロセス

プロジェクトスコープ記述書からWBSを作成するプロセスのマネジメント方法を決める箇所です。

こちらも同様にチーム内での役割分担や作成のための参考情報やアウトプットフォーマット、承認はどのタイミングで誰にもらうのかなどをまとめます。

WBS維持承認プロセス

WBSを維持し承認するための方法を確立するプロセスです。

こちらに関してはWBSを維持するための方法と承認するための方法に分けて記述します。

維持プロセスに関してはタスクの追跡方法や割り振るための方法について記述し、承認プロセスに関してはタスクの完了報告の管理などを記述します。

受け入れプロセス

完成したプロジェクトの成果物を公式に受け入れるプロセスです。

受け入れの基準や受け入れ時のステップ等を記述する箇所です。

変更要求コントロールプロセス

プロジェクトスコープ記述書への変更要求を処理する方法をコントロールするプロセスです。

要求の変更が上がってきた際にそれを誰に報告し、どういった会議体を経て、どんな影響に対する検討方法を用いて、承認するかを定義する箇所です。

要求事項マネジメント計画書

ここからは要求事項収集の管理計画について記載していきます。

具体的には以下の5つの項目となります。

<要求事項マネジメント計画書の項目>

  • 要求事項収集プロセス
  • コンフィギュレーションマネジメント
  • 要求事項優先順位付けプロセス
  • プロダクトの評価基準
  • トレーサビリティ構造

要求事項収集プロセス

要求事項収集プロセスでは要求事項に関する活動の計画、追跡、報告の方法を定義する項目です。

例えば、要求事項の収集法についてはアンケートなのかインタビューなのかや誰に対して行うかなどを定義します。

コンフィギュレーションマネジメント

次にコンフィギュレーションマネジメントではプロダクトの起案方法や、影響の分析方法、変更の確認、追跡・報告の方法などを定義します。

つまり要求事項の承認フローを定義していきます。

要求事項優先順位付けプロセス

そして要求事項優先順位付けプロセスでは承認された要求の優先順位付けを行います。

タスクの計画をする際に必要となります。

プロダクトの評価基準

そして出来た成果物を受け入れるための基準を定義するのがこちらの項目です。

受け入れ承認のフローと、もし基準に満たなかった場合のフローを定義します。

トレーサビリティ構造

そしてそれらの要求事項を分類し、追跡する仕組みとフォーマットを定義します。

まとめ

今回はスコープマネジメントに関してまとめました。ほかにもプロジェクトマネジメントに関する記事はこちらにまとめてあるのでご覧ください。

プロジェクトマネジメント関連記事へのリンク

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA