初めてPMをやる人が失敗する、スコープ管理を上手にやるコツ

お疲れ様です、ゆーろー@常駐しないPMOです。

わたしがプロコンサルとして参加しているiPM naviのコラムをご紹介します。

👍 このコラムは

むずかしさ　：
★★☆☆☆（PM初級者向け）

ボリューム　：
★★★☆☆(5分-8分で読める)

気付き学び　：
★★★★★(スコープ方針・基準)

お役立ち　　：
★★★★★(スコープ管理)

仕事の実用性：
★★★★☆（今すぐ使える）

---

writing by MASA
*このコラムはiPM naviで配信しています。

あなたが新人PMだとして、プロジェクト管理・プロジェクトマネジメントと聞いて、やらなければならない「管理」項目について皆さんはどんな管理を思い浮かべるでしょうか。

大概の人はまず計画したタスクの進捗管理と答えると思います。

設計や開発、テストなどの予実管理ですね。 もちろんこれは正解です。

他にも課題管理と言う人もいるかもしれません。

では、重要な管理項目は何か？と問われた時に、何って答えるでしょうか？

もちろん❗️

人によって考え方はそれぞれです。 私なら『スコープ管理』と答えます。

---

こんにちは、MASAです。

スコープ管理は、今まで設計や開発を担当してきた人で、これから初めてPM担当する、もしくはプロジェクトマネジメントをこれから勉強する人にとっては、あまり馴染みのないものかもしれません。

初めてPMをやる人が失敗する、多くの敗因は『スコープ管理』を知らないことです。

プロジェクトの管理項目で、重要なのはスコープ管理であり、スコープ管理がきちんと出来ればプロジェクトは成功に近づいていきます。

スコープ管理とは一言で言えば「プロジェクトで何を作るか」「プロジェクトで何をアウトプットするか」、すなわち作業範囲を管理するということです。 もう少し具体的に言うと、システム開発プロジェクトであれば、ユーザーのどの要望を取り込むか、その要望に紐づくどのシステム機能（非機能もですが）を構築するかを管理しコントロールすることです。

狭義では、ユーザーの要件や、それら要件に基づくシステムに求められる機能をリスト化するなどして、プロジェクトの対象範囲に含める・含めないを選別し、管理することです。

主に上流工程での管理作業とイメージされるかもしれません。

広義には、いったん確定した要件や機能に、構築やテストなどの下流工程において発生する諸々の変更要望や、不具合の改修要否を、ユーザーと調整し管理して行くことも含まれます。

なぜスコープ管理が重要なのか？

なぜスコープ管理が重要なのでしょうか？

それは、スコープというものはプロジェクトのあらゆる管理項目の上位にあるものだからです。

大抵のプロジェクトで、当たり前に管理する作業タスクやその進捗、課題、変更要望、リスクなどは、全てスコープに紐づいているからです。

絶対に失敗しないプロジェクトは「何も作らないプロジェクト」

ところで、あなたは絶対に失敗しないプロジェクトはどんなプロジェクトだと思いますか？

人によって様々な考えはあると思いますが、一つ言えることは、極端な例ですが、「何もしないプロジェクトは絶対に失敗しない」ということです。

もちろん！

そんなプロジェクトは、ユーザーの満足は全く得られないので成功とはいえないでしょうが・・・こと「失敗しない」という観点でいけば何も作らなければ失敗もありえないわけです。

前述したとおり、タスクはすべて元をたどればスコープに紐づいているので、スコープが多くなれば、それに紐づくタスクが増え、タスクが増えればミス（不具合）が増え、変更要望も増え・・・というロジックです。

それならば、大もとであるスコープが適正でなければ、プロジェクトの成功確率は加速度的に減ってしまうということです。

若手PMが陥りがちなスコープの罠

そんな失敗なんてそうそうしないでしょう、と思うかもしれないません❗️

そこで、よくありがちな例をあげてみます。 設計や開発で腕を鳴らした若手PMの人の場合、ハマりがちなのが、ユーザーから出される要件や機能に対して、自分で作業することを前提にスコープを取り込みすぎてしまうということです。

腕に自信があるがゆえに、多少キャパシティに対してオーバー気味の要望が出てきても、なんとかこなせるだろうとスコープに取り込んでしまいがちです。

小規模なプロジェクトだったら、それでも最後の最後でPMが最終的にPM自身で作業をやって、何とかなるかもしれません。

しかし、大きなプロジェクトでは話は別です。 チームというのは、メンバーのパフォーマンスがバラバラです。

ユーザーのフロントに立っていないメンバーは、要求を正しく理解するためのオーバーヘッドもかかってきます。

また、これは開発を担当する企業側のPM・ユーザ企業側のPMに共通して言えることですが、PMがやる気満々ではあるものの経験不足だったり、若手の場合、ユーザーの要望を叶えることで評価を上げたい！！というマインドが働くことで、過剰なスコープを盛り込みがちです。

さらに、ユーザ企業側PMが若手の場合❗️

要望を出してくる現場ユーザーよりも、職位が低い・現場業務に疎いことにより、周囲から高評価をもらいたいことから、スコープを取り込みすぎたりします。 これらのような状況の場合、要注意です。

スコープ管理の考え方と計画を共有しましょう

プロジェクトも終盤になってくると、追加の要望や変更要求、次々と発生する不具合や課題への対応など、やることがたくさん発生します。

現場は、押せ押せムード（地獄絵図になってる場合も）になってきます。

あなたも経験がると思います。 ただでさえ忙しいのに、重要度の低そうなスコープのためのタスクが追加で入ってくると開発現場の士気も下がってしまいます。

また、スコープに関する考え方やプロジェクトへの取り込み判断の基準がないと、ユーザー部門との調整に、都度議論 になってしまい時間が掛かってしまいます。

そして、本来べきタスクにどんどん影響していきます。

もっと言うと、それらに関わるマネジメント要員（PMOメンバ）の作業工数も大量に掛かってくるのです。

資料作成のために、会議前の日に毎週徹夜なんてことにもなりかねません。 このような馬鹿げたことばかりになります。

こんな状況を招かないために、スコープ管理計画を立てて、開発対象のスコープや要件変更の管理のルールを作って、きちんと顧客と合意しておく必要があります。

｜スコープの方針、基準
スコープに取り込むか否かの大方針や基準を明示しておきましょう。

そして、予めユーザーと合意しておくことでプロジェクト開始後にスコープ検討や変更の検討の際に、議論の時間を減らすことができます。

やむを得ず、基準外のスコープを取り込みたいという要望になった場合は、スケジュールの延長やコストの追加等のユーザー調整がやりやすくなります。

｜スコープ管理の会議体やワークフロー、ツールなど
予め、必要な会議体や変更にかかる体制、役割分担、ワークフローを定義しておきましょう。

そうすることで、スコープ管理に掛かる人的コストの間違いを提言する効果が見込めます。

最後に

今回は、スコープ管理について解説しました。

スコープ管理を制するPMは、プロジェクトを制すると言っても過言ではありません。

スコープ管理を成功させるのは、事前にスコープの考え方と計画の共有が大事であると認識していただけましたか？

・スコープの方針、基準

・スコープ管理の会議体やワークフロー、ツールなど

これらは、プロジェクト計画段階で検討しておき、予め関係者、特にユーザーときちん合意をしておいてください。

---

★★★　45秒で分かるiPM navi　★★

無料メンバーの登録（こちら）

iPM naviの活用方法（こちら）

★★★　ぜひ、お立ち寄りください　★★

最後まで読んでいただき有難う御座いました。