第2回 みんなを幸せにするスコープマネジメント

第2回　みんなを幸せにするスコープマネジメント

杦岡充宏（スカイライトコンサルティング）
2004/4/14

　前回（「第1回　プロジェクトメンバーを1つにまとめる」）は、プロジェクトマネージャの本質的な役割について解説した。それは、「プロジェクトを成功という1つのゴールに向かって導く」ということであった。プロジェクト関係者との情報共有を通じて、みんなの気持ちを1つにすることは大変重要である。これさえうまくいけば、プロジェクトはよいスタートを切れるといえるだろう。

　実際にプロジェクトを推進していくうえで、プロジェクトマネージャが具体的に取り組むプロジェクトマネジメント（PM）の仕事には、どんなものがあるだろうか。PMBOKでは、これを9つの要素に分類し、「知識エリア（Knowledge Area）と呼んでいる。


スコープ
時間（スケジュール）
コスト
品質
組織
コミュニケーション
リスク
調達（人・モノ）
統合（上記すべての統合、という意味）

　今後の連載では、これら9つの各領域について、現場でよく見られるシチュエーションを取り上げながら、PMの実践的な勘所を解説していきたい。今回はプロジェクトの成功／失敗に大きな影響を及ぼすといわれているスコープマネジメントについて解説する。

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

　まず、スコープマネジメントの定義を確認しておこう。その名前から受ける印象で、プロジェクトの初期段階において「何を」「どこまで」やるかを決定することだと思っている方が多いかもしれない。しかし、「何を」「どこまで」やるかを決定することはスコープマネジメントの一部分でしかない。マネジメントというからには「Plan-Do-See-Action」のサイクルが必要である。つまり、プロジェクト期間中、スコープは常に見直され、最新の状態に保たれていなければならない（なお、これはスコープに限らずスケジュールや予算などほかの要素においても同様である）。

　PMBOKの定義に簡単に触れておくと、スコープマネジメントとは「プロジェクトの目標である最終成果物を作成するために必要な作業が過不足なく確実に遂行されることを保証すること」であるとしている（表1）。

スコープマネジメントのプロセス 主要成果物 説明
プロジェクトの立ち上げ プロジェクト憲章
（チャーター） プロジェクトの基本事項（目的・目標・主要成果物、概略予算・見積もりなど）を定義
スコープ計画 スコープ記述書 必要な成果物を定義
スコープ定義 WBS 成果物を遂行するためのタスクを定義
スコープ検収 検証（検収）後成果物 成果物の検証（検収）
スコープ変更管理 変更後スコープ 成果物とタスクの見直し（変更）
表1　PMBOKでのスコープマネジメント（概要）

　つまり、スコープマネジメントとは、


プロジェクトの目標を達成するために必要な成果物とタスクを定義する
プロジェクト期間を通じて、必要に応じてその定義を見直していく
必要な成果物とタスクが完成されていることを保証する

ということである。

　次に、冒頭で述べた「スコープマネジメントがプロジェクトの成功／失敗に大きく影響を及ぼす」ということに簡単に触れておく。

■スコープマネジメントがプロジェクトの成否を分ける

　プロジェクトが成功裡に終了するのは全体の約20～30％、厳しい見方をする人によると1000に3つともいわれる。いかに多くのプロジェクトが失敗に終わっているか、お分かりいただけるだろう。こうした中でプロジェクトの失敗は、スコープマネジメントのまずさによる場合が多いといわれている。なぜだろうか。

　このことを考えるに当たり、まず「プロジェクトの成功」について整理しておく必要がある。

　プロジェクトの成功とは、しばしば当初定められた「期間どおりに」「予算どおりに」「品質を満たすこと」といわれるが、果たして、これらを満たせばプロジェクトは成功なのだろうか？

　当初定められた品質は満たしたが、結果としてユーザーに使ってもらえなかった。または、プロジェクトメンバーが長期間にわたり過酷な労働に陥り、健康を害するメンバーが続出するといったプロジェクトは成功といえるのだろうか？

　筆者は、本質的にプロジェクトの成功とは、

「プロジェクトにかかわるすべての利害関係者に満足する結果をもたらすこと」

であると考えている。ここで利害関係者とは、顧客サイドの経営層、スポンサー、発注者、ユーザーなどに加え、受注サイドの営業部門、開発部門、協力会社などの人々を指す。

　すべての利害関係者に満足する結果をもたらすためには、「プロジェクト実施前に各関係者が期待するもの」と「プロジェクト実施後に各関係者が得るもの」を一致させなければならない。しかし、両者を一致させることは難しい。「期待」は常に変化するし、「得るもの」は思いどおりに提供できるわけではない。これを実現するためには、「何を」「どこまでやるか」を具体的に決め、実行し、常に見直していくしかない。すなわち、プロジェクトの目的と目標を明確にし、必要な成果物・作業を明確にし、実行計画を策定し確実に遂行するしかないのである。これは先に説明したスコープマネジメントそのものであることがお分かりいただけるだろうか。文字どおり、スコープマネジメントはプロジェクトの成功へ直結するのである。

　それでは、スコープマネジメントを「スコープを決める」「決めたスコープをコントロールする」という2つの観点から、実践的な勘所ケーススタディを通じて紹介していくことにしよう。

■スコープの決定にはプロジェクト関係者全員の合意と理解が不可欠

　あなたの部署に2つのシステム開発案件が舞い込んできた。どちらの案件も、営業サイドとしては何としても受注したかったため、予算も納期もかなり無理をして取ってきたようである。

　あなたの部署の「矢見雲マネージャ」と「出来杉マネージャ」がそれぞれの案件を担当することになり、プロジェクトがスタートした。あなたは、どちらかのプロジェクトに配属されることになり、2人のマネージャからそれぞれのプロジェクトの説明を聞くことにした。

矢見雲マネージャの発言
　 「私も提案書については、正直、現実的ではないと感じている。提案時にもそういった。しかし、会社の上層部からも受注しないといけない重要なプロジェクトということで念を押されているので、腹をくくって何とかしてやるしかないと思っている」
「ただ、顧客と実現すべき機能や仕様については大枠合意が取れているので、そこは救いだな」
「さっきも話したけど、このプロジェクトはわが社としても非常に重要な案件なので、ぜひ君に力を貸してほしい」
「じゃあ、よろしく頼むよ」

出来杉マネージャの発言
　 「私も提案書については、正直現実的ではないと感じたので、まず営業サイドに提案書の見積もりの根拠を確認した」
「すると、受注のために明確な根拠なく見積もりを作成していたことが判明したので、急きょ、プロジェクト計画を作り直すことにした」
「まず顧客の要望に使用頻度と重要度が低いと考えられる要望が多く盛り込まれていたので、顧客の要望を再確認した」
「営業サイドからは機能・仕様は、顧客と大枠合意されていると聞いていたが、実はこの顧客、ユーザー部門とは別部署のメンバーで、ユーザー部門に確認する必要があることが判明した」
「再度、ユーザー部門を交えて要望を整理したところ、当初の3割程度が不要な機能であることが判明した」
「それでも再見積もりの結果、当初見積もりの2割増になったが、顧客と営業サイドと上層部に見積もりの根拠を説明するとともに、元の予定でいくと結果的に納期遅延や予算オーバー、そしてプロジェクトが混乱に陥り、成果物の品質も落ちて顧客満足が得られないこことが危惧（きぐ）されることを指摘して納得してもらった」
「正直、これでも楽な計画ではないが、われわれはこの計画に自信を持っている。そしてこの計画の達成には君の力が必要だ。ぜひ、このプロジェクトを一緒に成功に導こうではないか」

　先に触れたように、プロジェクトの成功とはプロジェクトにかかわるすべての利害関係者に満足をもたらすことである。プロジェクトの利害関係者とは、顧客サイドにおいても、経営層、スポンサー、発注者、ユーザー、そのほか関係部署と多岐にわたる。また受注サイドにおいても、営業部門、開発部門、場合によっては経営層などが関係する。

　これら関係者は、それぞれ立場が異なるので利害を異とすることが一般的である。利害を異とする関係者の満足を達成するには、まず「何をいつまでにいくらで達成すれば満足するか」というプロジェクトの基本事項について、関係者全員の合意と理解を得ずして成し遂げられないことはご理解いただけるであろう。

　重要なことは、一部の関係者ではなく「関係者全員」の合意と理解である。

　先の矢見雲マネージャの例では、見積もりについて顧客サイドの発注者と受注サイドの営業部門、経営層は合意しているが、開発部門と合意されているとはいえない。また、機能・仕様については、顧客サイドの発注者と受注サイドの営業部門は合意しているが、顧客サイドのユーザーは合意していない。

　ここで挙げたケースは、PMBOKでいうところの「プロジェクトの立ち上げ」においてプロジェクトの基本事項を定義する段階の話しであるが、ちまたにあふれる失敗プロジェクトには、プロジェクトの開始時点ですでにこのような全員の合意が得られていないプロジェクトが多いように考えられる。

　あなたの周りのプロジェクトではこのようなことが起こっていないだろうか……。

　実際にすべての利害関係者の合意と理解を得ることは容易ではないが、読者がもしこれまでこのことを意識していなかったとすれば、まず第一歩として、プロジェクトの利害関係者をすべて洗い出し整理しておくことをお勧めする。話を通すべき相手が分かっているだけでも結果は大きく変わってくるといえよう。

　また今回の例では、プロジェクトの初期段階を取り上げたが、関係者全員の合意と理解を得ることは、プロジェクト期間を通じて行わなければならないことを付記しておく。

■スコープを可視化する

　先に紹介したプロジェクトはその後数カ月がたち、現在はユーザーによるテストフェイズを迎えている。ところが、この段階でユーザーから数多くの追加要求の声が上がってきた。システムの稼働まではもう1カ月しかない。このような状況における2人のマネージャと顧客側担当者とのやりとりを見てみることにしよう。

矢見雲マネージャの発言
　 矢見雲：「今回ご指摘いただいたご要望は前フェイズまでにご確認いただいた要件にはありませんでした。これからの追加となるとスケジュール的にも予算的にも厳しいのが正直なところです」
顧客：「困ったなあ。当然盛り込まれているものと思っていたのにどうして入ってないの？」
矢見雲：「われわれとしては要件として明確に確認させていただいたことについて対応させせていただいています。しかし、今回の場合、そういう要件があるということは認識しておりませんでした」
顧客：「そんなのいわなくたって分かっているだろう。いずれにしても、今回の要件は絶対必要なんだよ」
矢見雲：「分かりました。対応方法を検討させてください」

出来杉マネージャの発言
　 出来杉：「今回ご指摘いただいたご要望は、今回のシステムで実現する機能を網羅的に整理した『機能要件一覧』には含まれていませんでした。これからの追加となるとスケジュール的にも予算的にも厳しいのが正直なところです」
顧客：「そうだったか。ちゃんと確認したつもりだったが漏れていたようだね。でも、いずれにせよ必要な機能なので何とか対応しなくてはならないんだ。何とかならないものか」
出来杉：「分かりました。対応方法を検討させてください」

　ポイントは、スコープを「可視化」することにある。矢見雲マネージャの例の問題点は、要件定義の段階で、顧客と双方でスコープ（要件）を確認できる共通の成果物がないことだ。顧客側は要件として当然含まれていると認識しているが、開発側は要件として明確になっていないために、当然スコープには含まれていないと考える。ここで認識のズレが生じていたのである。

　出来杉マネージャの例では、「機能要件一覧」を使って、双方でスコープを確認している。例えばスカイライトコンサルティングでは、対象とする「業務」または「システム機能」を階層的に整理し、一覧表の形式にしている。「機能要件一覧」によって顧客側、開発側双方が網羅的にスコープを確認できるため、「抜け漏れを防ぐ」点と「万一、抜け漏れがあった場合の責任の所在が明らかになる」という点で大きな効果がある。

要件の優先順位付けは、個別に見れば全部重要となってしまう

　次に、上の例の続きで、実際によく見られるスコープコントロールのケースを紹介しよう。

矢見雲マネージャの発言
　 矢見雲：「今回ご指摘いただいた要件は3件あります。これら全部に稼働までに対応することは正直困難ですので、優先順位を付けて重要度の高いものから対応していき、そうでないものは稼働以降に対応させていただきたいと考えております」
顧客：「致し方ないな。それでお願いすることにしよう」
矢見雲：「ありがとうございます。では、早速それぞれの要件の検討を進めていきましょう。まず1番の要件ですが……」
顧客：「それは必須だな。それがないと業務が回らない」
矢見雲：「では2番の要件ですが……」
顧客：「それも重要だな。それがないとユーザーの負荷が著しく増加する」
矢見雲：「では3番の要件ですが……」
顧客：「それは当然必要。ないと取引先にも影響を与える。結局、全部必要なんだよ」
矢見雲：「いったん持ち帰らせてもらって開発側でなんとか押し込めないか検討してみます。返事は社に戻って検討した後、ご連絡します」

出来杉マネージャの発言
　 出来杉：「今回ご指摘いただいた要件は3件あります。これら全部に稼働までに対応することは正直困難ですので、優先順位を付けて重要度の高いものから対応していき、そうでないものは稼働以降に対応させていただきたいと考えております」
顧客：「致し方ないな。それでお願いすることにしよう」
出来杉：「ありがとうございます。では、早速どういう基準で優先順位を付けるかということを検討させてください。まず、取引先など対外的に影響を与えるものは、やはり最優先かと考えていますがいかがですか？」
顧客：「そうだな。外に迷惑をかけることはできないな」
出来杉：「では、これを『重要度：高』としましょう。次にユーザーに与える影響ですが、これは、その要件により影響を受けるユーザー数と業務量に応じて影響の大きさは変わってくると思うので、影響の大きいものは『重要度：中』、そうでないものは『重要度：低』ということでいかがですか」
顧客：「分かった。それでいこう」
出来杉：「そうすると3つの要件はどうなりますか？」
顧客：「3番は『重要度：高』だな。あとの2つは『重要度：低』ということになるな」
出来杉：「分かりました。では、3番だけであれば何とかできる可能性はあるので、スケジュールを検討してみます。あとの2つは稼動後できるだけ早い時期に対応するということで、いつ対応するか別途検討しましょう」
顧客：「そうしよう」
出来杉：「それと対応する方向の3番については、仕様変更手順に基づき、ステアリングコミッティ（プロジェクト運営委員会）での承認が必要になります。仕様変更依頼書を作成しますので必要事項に記入をお願いします」
顧客：「分かった。ありがとう。よろしく頼むよ」

　このケースで重要なポイントは、追加要件に対応することが難しい場合によく行われている「優先順位を付けて対応を考える」ことにある。矢見雲マネージャの例では、個別の要件ごとに判断しているが、このような場合、各要件に必要とされる理由や背景に基づいて判断することになる。しかし、これだとどうしてもあれも重要、これも重要となってしまう、あるいは顧客とこちらで重要度が一致しないということに陥りがちではないだろうか。

　重要なのは、どういう基準で優先順位を付けるかについて合意することである。顧客と開発側の双方が容易に判断できるプロジェクト全体を通しての判断基準をておくことにより、お互いに納得のいく意思決定が迅速にできる。

■今回のまとめ

・スコープマネジメントとは、プロジェクトの目標を達成するために必要な成果物とタスクを、プロジェクト期間を通じて定義していき、その内容をやり遂げることを保証すること。
・スコープマネジメントは、プロジェクトの成功／失敗に大きく影響を及ぼすこと。
・スコープを決定する際は、プロジェクトの関係者が誰であるかをしっかり押さえて、関係者「全員」の合意を得ること。
・定義したスコープは、顧客／開発側双方で確認できるよう「可視化」しておき合意を得ること。
・スコープの変更を検討する際に、要件の優先順位を検討する場合は、優先順位付けの判断基準を明確にすること。