スコープマネジメントとは?|プロジェクト成功の条件をアップデートしよう

前回記事 では「知識体系:PMBOK」の概要について解説しましたが、今回からは PMBOK知識エリアの各項目について詳しい解説をお届けしたいと思います。

 

第一回目となる今回は、プロジェクトマネジメントにおいて最も重要な要素のひとつとも言える「スコープマネジメント」についてです。

突然ですが、プロジェクトマネジメントに取り組まれる上で こういった経験はありませんか?

  • お客さまの要望がコロコロ変わって振り回されている
  • 現場レベル(担当者 間)で決まったことが役員会議でひっくり返った

「日本国内のITプロジェクトの70%が失敗する」とさえ言われていますが、正しい「スコープマネジメント」が行われていないことが原因であるケースも少なくありません。

 

今回の「スコープマネジメント」に関する内容を通して、みなさまがプロジェクトを成功に近づけるヒントを見つけていただければ嬉しく思います。

似たような悩みをお持ちの方、興味がある方はぜひ参考にしてみてください。

  • スコープマネジメントとは?その概要について理解できる
  • 現場で必要になる 実践的なポイントがわかる
  • ゴール(完成)の見えない デスマーチ案件を作らない考え方



スコープマネジメントで「プロジェクトを確実に遂行」する

まず始めに、スコープマネジメントとは何か?について考えておきましょう。

前回の記事 でご紹介した「プロジェクト管理の知識体系:PMBOK」では、スコープマネジメントを次のように定義しています。

「プロジェクトの目標である “最終成果物” を作成するために、必要な作業が過不足なく確実に遂行されることを保証すること」

 

シンプルにお伝えすると 「5W1Hにおける「What」(=何を?)をマネジメントする営み」 とお伝えするとイメージ頂けそうでしょうか?

 

さらにPMBOKでは、具体的なアクティビティ(=やること)として、スコープマネジメントに必要なプロセスを以下のように定義しています。

  • 基本事項(PJ目標・概算見積りなど)の定義
  • 成果物、その遂行を目的としたタスクの定義
  • 成果物の検収
  • 成果物・タスクの見直し・最適化

 

いくつかのプロジェクトを経験された方の中には、

「スコープマネジメント」は、すなわち「何を?どこまで対応するか?を明確にすること」と理解されている方もいらっしゃるかもしれません。(いわゆる「PJの超上流工程における双方の合意」ですね。)

確かに「何を?どこまで対応するか?」を明確にする営みは、スコープマネジメントの重要な側面のひとつです。

しかし「何を?どこまで対応するか?を明確にすること」というのは、スコープマネジメントが持つ一部分の側面に過ぎません。

なぜならスコープマネジメントは、先に述べた通り「プロジェクト憲章作成」に始まり「定期的な見直しや最適化」さらには「検収フェーズ」に至る、全てのフェーズにおいて求められる営みだからです。

 

プロジェクトの羅針盤(ぶれない目的)を定義する

このように、スコープマネジメントを正しいアプローチで推し進めることには

「何をするか?」を明確にし、最新化することによって、プロジェクトを推し進めるうえでの指針を設定できる

という価値(=バリュー)があります。

 

なぜなら「何を?」が明確でない状態(=スコープマネジメントが適切でない)では、関係者全員が向かうべき方向性(=プロジェクト目標)を簡単に見失ってしまうことになるからです。(※いわゆる「糸の切れた凧(タコ)状態」ですね。)

向かうべき方向性を正しいアプローチでコントロールする(=スコープマネジメントを行う)ことで、「糸の切れた凧(タコ)になる」事態を避けることができる、というものです。

 

「予期せぬ事態」にも対応できるようになる

そもそもプロジェクトでは、「ユーザ要求の変化」や内外部の様々な要因などによって「予期せぬ事態」に直面するのは避けられません。

実際、身近なところに目を向けてみても、昨年(2019年)の時点で「2020年にパンデミックが世界的に流行し、東京オリンピックが延期される」ということを予想できていた人はいなかったのではないでしょうか。

 

・・・少し話がそれましたが、要するに世間の流れが変化し続けている中で目的(=そもそも何をするか?)が曖昧であったり、ゴールを最新化しない(当初に定義したスコープだけに執着してしまう)のは「状況への適応」を放棄していることと同義となってしまう、と言うことです。

スコープマネジメントはこのような「予期せぬ事態」にいち早く対応し、結果を最大化するための「ガイドライン」と言えるかも知れません。



スコープマネジメント 実践のための3つの勘所

ここまでで「スコープ管理とは?」「スコープ管理はナゼ必要?」「日本におけるプロジェクトの成功率」といった点についてお伝えしてきました。

では、実際の現場レベルではどのようなアプローチが必要なのでしょうか

 

当記事のメインコンテンツでもある「3つのポイント」を参考に、行動レベルに落とし込んで頂ければ嬉しく思います。

その3つのポイントとは

  • 期待値と成果を「定義する
  • 関係者からの「合意を得る
  • 期待値と成果を「アップデートする

の3つです。さっそくくわしい解説を見ていきましょう。

 

期待値と成果を「定義する」

まず最初のポイントは”期待値と成果を定義する“というものです。

いわゆるプロジェクトの最上流・超上流工程では「プロジェクト開始前に期待しているもの」と「プロジェクト実施後に得るもの」を一致させることでスコープを定義します。

 

・・・はい。言うのは簡単ですが、現実問題としてこの双方を一致させるのは容易なことではありません。

なぜなら「期待」はさまざまな要因(社会や業界の動向や社内人事など)がもとで変化したり、知識・認識が不十分なためにベンダーに正確に伝えられていない場合があるからです。

逆に「得られるもの」も、プロジェクトがスタートしてから当初の想定通りに実現・提供できないことが判明することもあるでしょう。(調達先ベンダーの倒産、プロジェクト発足後に発生した法的・技術的な制約など)

 

超上流の工程における「期待値の定義・コントロール」に興味がある方は、”ビジネスアナリシス”という考え方を参考にしていただけるとヒントが見つかると思います。

【関連記事】ビジネスアナリシスの考え方で 経営課題とITを繋ぐ

 

関係者からの「合意を得る」

次に、”関係者全員の合意を得る“という点について考えてみましょう。

“現場部門向けのシンプルなシステム導入プロジェクト”ひとつとってみても、多様な関係者(=ステークホルダー)が存在しています。

 

・・・具体的にステークホルダーを設定して考えてみましょう。

 

発注者側なら「実際に利用する現場部門」や「導入を支援する情報システム部門」、さらには「経営層」などが主要なステークホルダーとして挙げられます。

さらに受注者側においても「セールス部隊」や「デリバリー部隊」、その後ろには「外部ベンダー」を抱えるケースもありますし、プロジェクトの規模によっては「経営層」が関わることもあるでしょうか。

 

あえて理想を言うなら、ここで挙げたような「関係者”全員の合意”を得ること」です。

クライアントの「情報システム部門」とベンダーの「営業部隊」の合意だけで話が進んでしまい、「実際に利用する現場部門」が蚊帳の外であったりするケースが少なくないからです。

この状態は社内に不要なハレーションを起こしかねず、場合によっては現場部門からの協力が得られないまま導入プロジェクトが進んでしまうことになります。

当然ですが、導入部門の協力なしに「現場に即したシステム導入」を推し進めることはできません。プロジェクトを成功に導くためにも「合意を得る」というプロセスは避けては通れないのです。

 

期待値と成果を「アップデートする」

3つ目は、”期待値と成果をアップデートする“です。

真のスコープマネジメントの難しさはこの「常に最新化し続ける」と言う点にあるのではないでしょうか。

なぜなら、”定義する”のセクションでもお伝えしたように、顧客(=発注者)からの”期待値”と”成果”は常に変化するものだからです。

 

では、この3つの勘所:「定義する」「合意する」「アップデートする」を実践するために、どのような考え方・方法が必要なのでしょうか?

次のセクションから、これら3つをつなぐ「重要なキーワード」について考察していきます。

 

「定義・合意・アップデート」を繋ぐカギ?

結論からお伝えすると、期待値の「定義・合意・アップデート」をステークホルダー全員の共通認識にするための重要なキーワードとは「可視化=見える化」です。

 

何度もお伝えしている通り、「課題のある現状」を「期待値(=プロジェクト完了後に得られるもの)」に近づけるには、その間にある「ギャップ」を正しく理解する必要があります。

さらにその「ギャップ」を理解するためには「現状」を正確に把握しておく必要があります。

例)太った人が「痩せたい」と考えた場合、「期待値(=目標体重)」と「現状=(今の体重)」の把握から始まるのと似ています。

 

「関係者からの合意を得る」のセクションでもお伝えしたように、特定のプロジェクトメンバーだけが問題を理解している、という状況はあまり良い状態とは言えません。

言い換えると「ステークホルダー全員が現状を把握し、共通認識なっている」状況が望ましい、ということです。

これを実現するためにも「現状を正しく可視化」することで、全員が理解する(少なくとも状況を知っている)状態を作ることが求められます。

 

このあたりのアプローチ方法(可視化とギャップ分析)については「問題解決スキル」の記事でも詳しく解説しています。

■【関連記事】優秀なひとの共通点は”問題解決”にあった?

 

「現状を可視化」するメソッドとは

ここではシステム開発について例を挙げますが、「実装機能一覧」をリスト化することで可視化を実現する助けとなります。

「一覧化された機能」と「重要度」を併せて管理することで、事前に検討された優先順位をもとに「必須機能のみをリリースする」という(受発注者で合意した)マイルストーンを置き、プロジェクトをいくつかのフェーズで区切ることもできるでしょう。

(Phase.1では優先度:高および付随機能を実現、Phase.2では優先度:中を実現。など)。

 

発注者・プロジェクト推進者ともに「やってくれる”だろう”」「言わなくてもわかる”だろう”」というのは、プロジェクトを進める上では「危険な考え方」とも言えます。

小さなことでプロジェクトが躓かないためにも、たとえ”業界常識”といえるような前提条件でさえ、事前にしっかりと伝えておくことが大切なのかも知れませんね。

 

まとめ

今回は、PMBOKの知識エリアのひとつである「スコープマネジメント」を通して、プロジェクトを成功に近づける3つのポイント+αについてお伝えしました。

 

当サイトの「コンサルティング」カテゴリでは、ベーシックな「フレームワークの使い方」をはじめ、システム導入や業務改善で求められる「プロジェクト管理」の勘所などー。

現場で役立つ「実践的」な情報を幅広く発信しています。

 

今回の記事が参考になったという方は、ぜひほかの関連記事にも目を通してみてください。

■【徹底解説】”PMBOK”があればプロジェクト管理で悩まない?