PMBOK 式・スコープを確立するまでの方法について！
七色メガネはじめに
こんにち WAON ! 株式会社 Belong で Engineering Manager をしている七色メガネです。
蚊も死に絶える初夏の候、皆々様におかれましてはお変わりなくお過ごしでしょうか。私は変わりました。(?)
先日 PMBOK を学んで PMP 資格をとってきました。 ので今回は、 PMBOK におけるスコープ管理の方法を、中でもプロジェクト初期におけるスコープ確立までの流れについて、簡単にではありますが紹介できればと思います。よろしければお付き合いください。
PMBOK におけるプロジェクトマネジメントの全容
まずはじめに、PMBOK 6 版で解説されるプロジェクトマネジメントの全容をさらっと確認してみましょう。
※ 画像引用: https://www.linpress.co.jp/blog/c35
PMBOK では必要な作業を 10 の知識エリアと 5 つのプロセス群に分け、合計 49 のプロセスとして内容を整理しています。でかいですねえ。
「スコープ」という概念は、この中で 1 つの知識エリアを形成していることからも分かる通り、プロジェクトマネジメントにおいてとても重要なものです。
また PMBOK のスコープエリアには全てのプロセスがあるわけではなく、「計画」と「監視・コントロール」のみがあることがわかります。
これは
- 「最初にやるべきことを合意して、」
- 「継続的にスコープの追加や逸脱を監視・コントロールし、」
- 「プロジェクトの途中、及び最後に、成果物がスコープに適合しているかを確認する」
ぐらいの意味です。今回の記事では、特に計画プロセスまでにフォーカスして内容を見ていきたいと思います。
スコープとは何か
▼ 2 つのスコープ
それぞれの工程にフォーカスする前に、言葉の意味を確認しておきましょう。PMBOK における「スコープ」の定義は 2 つあります。
- プロジェクトスコープ ... 規定された特性や機能を持つ、プロダクト、サービス、所産などを生み出すために実行しなければならない作業
- プロダクトスコープ ... プロダクト、サービス、所産に特有の特性や機能
お餅を作るとして、「もちもちでなければいけない」「焼くことができなければいけない」「長方形でなければいけない」など成果物たるお餅そのものに求める要素を規定するのが「プロダクトスコープ」ですね。
対してプロジェクトスコープは、そんなお餅を作るために必要な過程のことです。 お餅を作るためには杵と臼が必要なので買わなければいけないし、人も集めなければいけないし、出来立てのお餅を輸送する手段も確保しなければいけません。 それらを整理して、必要な作業としてまとめたものがこの 2 つめのスコープ、プロジェクトスコープです。
どちらが重要というものではなくどちらも重要なタイプのあれです。 プロジェクトが進行する際には、これらを文書化して共有し、ステークホルダーの合意を得ておくことが PMBOK では推奨されています。
▼ スコープクリープ
スコープ？ そんなものは要らねえ! 俺は感覚派だ！というワイルドの民もいることと思います。否定はしません。
ただこれらのスコープを明らかにしないで進行したプロジェクトがどうなるかは、それほど想像に難くないのではないかなと思っています。
例えば、
- 計画外の作業を頼まれたが簡単なものだったので引き受けた
- → 作業依頼が常習化して週に 10 本飛んでくるようになり、本来やるべきことができなくなった
- 時間が余ったので合意していない作業を行った
- → 期待値から外れ、評価できないものが出来上がった
- 発注者・受注者間でシステムのテストを行うことが合意されていたが成果物を定義していなかった
- → 受注者はテスト結果のエビデンスや Doc を作成せずに納品し、発注者が契約違反だと抗議した
などです。こういった「合意していない内容」を行ってしまうことを、「スコープクリープ」と呼びます。悲しみの種ですね。なるべく避けましょう。
▼ アジャイルとスコープ
俺は流動性の申し子! スコープは変転する！ というアジャイルの民もいることと思います。否定はしません。
ただ一応書いておくと、アジャイルにおいてもスコープの概念は当然あります。
Scrum における Sprint を例に出すと、Scrum チームは Sprint Planning イベントを通して次回の Sprint における着手内容を決定します。これがスコープになります。
Sprint が始まった後は、この決定されたスコープは Sprint が終了するまで基本的に変更されません。つまりスコープクリープは許容しません。( 緊急の Incident などは別でしょうが )
別の側面でも見てみましょう。
ウォータフォールでのデメリットを打ち消して開発を行いたいということでアジャイル手法が選択されることが多いですが、克服したい問題として「スコープの不確実性」が選ばれた場合には、俗にいう「反復型」の開発方法が選択されることが多いです。
( 別の観点としては「デリバリー速度」などがあり、これに価値を見出すのであれば漸進型の手法をとることになります )
※ 画像引用: https://ssaits.jp/promapedia/method/iterative-incremental.html
この場合であっても、スコープは議論やフィードバックを受けて改善・更新されるのであって、不定のまま放置されているわけではありません。走る方向を一度決めて、合意し、走り出し、途中で振り返り、方向を修正します。
のでこの場合においてもスコープは存在し、ちゃんと注意しなければあらぬ方向に進むようなスコープクリープは起こり得ると言える、と私は考えています。
スコープ確立までの流れ
前置きが長くなりました。では PMBOK におけるスコープ確立の方法について読み解いていきましょう。 大きな流れとして、以下のようなステップを踏みます。
- プロジェクトの目的・背景を抑える
- ステークホルダーを知る
- 要求事項を洗い出す
- スコープを決める
- WBS を作る
▼ 前準備 I: プロジェクト憲章の作成あるいは確認
いきなりスコープの知識エリア外の話で申し訳ないのですがここは外せないので触れます。
プロジェクト憲章とは、プロジェクトの存在を認可し、プロジェクトの必要性を説明し、プロジェクトマネージャーに各種権限を付与するものです。
具体的に記載内容の決まりはないのですが、主に以下のような内容が記述されます。
- プロジェクトの目的
- プロジェクトの達成基準（測定可能な成功基準）
- プロジェクト概要、作業範囲
- 前提条件・制約要件
- ハイレベル要求事項
- 予算
- リスク
つまりここでは、プロジェクトがそもそもなぜ立ち上がったのか・何が目的なのか、などスコープの核とも言うべき本質が解説されます。 以降整理するスコープはこの憲章の内容から外れないよう常に意識する必要があります。
小規模なプロジェクトやアジャイルプロジェクトではプロジェクト憲章という名前の資料は存在しないかもしれません。
しかしやりたいことの概要もビジネス背景も予算もリソースも明らかにせずに始めるプロジェクトは無い ( と信じています ) ので、何かしら類似の資料があるはずです。探しましょう。
もし存在しない場合、プロジェクトの途中で「こんなプロジェクトは承認していないぞ！」とプロジェクトが中止になる可能性があります。その場合は自分で作成し、偉い人の承認をもらうところから始めましょう。
余談ですがこれは企画書に該当するので、どうしても期間感やスケジュールに関する見積もりが付随することと思います。やることが決まっていないのに、です。
そんな状況で行う見積もりなんてものは、絶対に正確になり得ません。見積もり技術云々以前に、何をするのか分からないんですから。
こんな見積もりの不安定さを表す概念として、「不確実性のコーン」という考え方があります。
※ 画像引用: https://ssaits.jp/promapedia/concepts/cone-of-uncertainty.html
初期時点での見積もりは 100+α % でずれ得る、ということを示す図ですね。予算がこの時点で決まるのなら、必要な分のバッファを取るというのは生存戦略として重要です。
▼ 前準備 II: ステークホルダーの特定
もう 1 つだけスコープの知識エリア外のプロセスに触れます。ステークホルダーの特定です。
これから行われようとしているプロジェクトにはステークホルダー ( 利害関係者 ) がいます。ここではプロジェクトの成功によって利益を享受する、ポジティブなステークホルダーだけを考えます。
恐らく、プロジェクトと関係を持つ人は多く存在します。そしてそれぞれの人が少しずつ異なる要望を持っています。
ここで意識しなければいけないのは、見落としてはいけない/聞かなくてはいけない意見を見落とさないことです。
以下のメンバーがステークホルダーとしてプロジェクトに関心と要望を持っているとします。
- システムを利用することになる部門のリーダー兼プロジェクトスポンサー
- システムを利用することになる User
- 自分の上司
全員の意見を聞いて実現できたら一番良いですが、そうできないことが多いのは説明不要だと思います。 その場合ステークホルダーの意見に優先度をつけることになりますが、今回で言えば #1 > #2 >>> #3 になるかと思います。 前方のステークホルダーの意見を聞かなかったり無視した場合、求めているシステムを実現できない・作ったシステムが使われない・プロジェクトが検収されない、などの自体に繋がり得ますね。 従って常に寄り添って意見を聞く必要があります。
またステークホルダーは常に流動します。初期時点で上記の #1 ~ #3 だったとしても、例えばプロジェクトの途中で CTO が入れ替わったとして、以降全てのシステムのアーキテクチャは CTO が確認・承認することになったとします。すると当然、キーステークホルダーとして #4 CTO が登録されることになります。
これに気づかないとどうなるか。無視できない意見がプロジェクトの途中意図しないタイミングで追加され、スコープが乱れます。
ということで、スコープ管理の前提としてステークホルダーを特定しその内容を更新し続けることは必須になります。意識しましょう。
ちなみにステークホルダー管理の手法は PMBOK のなかでいくつか紹介されていますが、そのうちの 1 つに「権力と関心のグリッド」というものがあります。 画像だけ貼っておくので、興味があれば調べてみてください。
※ 画像引用: https://ssaits.jp/promapedia/method/power-interest-grid.html
(1) 要求事項の収集
では本題に入りましょう。まずは要求事項の収集です。
要求事項とはプロジェクトと成果物に対する要求になります。プロジェクト憲章に記載されていたことや、もう少し具体的な要求などをまとめていきます。
この時点では要求事項の絞り込みや削減はしません。列記するだけです。ただ優先度だけはつけておきます。
固定のテンプレートはありませんが、PMBOK では概ね以下のようなカテゴリを設けた「要求事項文書」としてアウトプットされることが推奨されています。
- ビジネス要求事項
- ステークホルダー要求事項
- 機能要求事項
- 非機能要求事項
- プロジェクト要求事項
- 品質要求事項
この要求事項文書の使われ方はビジネス環境によって変わってくると思います。
初期の要求整理時点で解像度高く要求を整理できているのであればこの文書の価値はプロジェクト終盤まで高いでしょうし、初期時点では何をやるか決めきれていないというような環境であればこの後に整理するスコープ記述書の方が重要度が高くなってくることと思います。
個人的には、要求にも叶えられるもの・叶えられないものがあり、叶えられないものはスコープには入れないので、最後まで参照したいのは要求事項文書ではなくスコープ記述書だと考えています。
が、ケースバイケースですね。
(2) スコープの定義
要求事項が整理できたら、スコープを確定させます。このプロセスのアウトプットが、「スコープ記述書」と呼ばれるものです。
プロジェクト憲章における内容がハイレベルな要求概要、要求事項文書における内容が優先度付けされた要求の一覧だったのに対し、スコープ記述書では最終的にプロジェクトが実施・実現する内容を具体的に記載したものになります。
こちらもテンプレートはありませんが、以下のような推奨項目があります。
- プロダクト・スコープ記述書
- 受け入れ基準
- プロジェクト成果物
- プロジェクトの除外事項
プロダクトスコープとはプロダクトが持たなければいけないサービスや特性に関する記述でした。 プロジェクト開始時点から 100% の精度で記載できるわけもないので、プロジェクトの進行に合わせて徐々に解像度を上げていく「段階的詳細化」という概念が PMBOK では推奨されています。
受け入れ基準、成果物、除外事項は読んで字の如くですが、重要な項目です。
「在庫管理システムを作る」というプロジェクトがあったとして、このプロジェクトの終了条件はなんでしょうか？ システムが完成すること？ システムが引き渡されること？ システムが利用開始されること？ もしこの基準が「受け入れ基準」「成果物」として明確にスコープとして定義されていたら、受注者も発注者も迷うことがありませんね。
また「やらないこと」の宣言も重要です。おそらく要求事項文書には要求が山のように記載されているはずですが、コストやスケジュールの観点で諦めざるを得ないものもあるはずです。そういったものを今回のスコープに入れないという決定は、口頭などでふわっと合意するだけでなく、このスコープ記述書における除外事項として明記しておけば間違いがありません。 プロジェクトの後半になって「あれもやってって言ったじゃないですか！」という指摘を受けた時、「確かにそれは要求事項としていただいていました。しかしスケジュールの観点から実現が困難であり、スコープ記述書の除外事項にその旨を明記させていただき、合意もいただいていました」という回避ができるようになります。
※ 一応書いておくと、スコープに書いていないこと以外をやるべきはない、ということ言いたいわけではありません。物事の優先度は時間や状況によって変わります。やるべきことも変わるでしょう。 しかしそういった事態に直面したら、スコープの方を見直すべきです。スコープを変えずに追加や変更をあれこれ加えることは前述のスコープクリープであり、それを見越していないコストやスケジュールとの不調和が起き、結果プロジェクトの失敗に繋がってしまうのです。
(3) WBS の作成
PMBOK ではスコープ記述書のの内容をベースにして WBS を作成することが推奨されます。 ここでの WBS とは必要な作業がワークパッケージとして要素分解されたものをさしており、必ずしもスケジュール要素を含みません。スケジュールの設定は WBS を input として別に行われます。 ( 別に WBS にスケジュールを含んだ形で一緒に作っても良いと思います. )
作成されているスコープ記述書は初期状態で完璧ではありません。「もちもちのお餅」を作るつもりだったが、それには「もちもちの餅米」が必要が分かり、それが市場にはなかったために「餅米を生産する」という作業を追加で行うか、あるいは「もちもち感を諦める」という選択を取る必要がある、みたいなこともあるかもしれません。
そういった意味で、WBS の作成によりスコープは更に解像度を高めます。
このように「最初から完璧なものは作れないので、徐々に解像度を上げていく」ということを指して、「段階的詳細化」という概念が PMBOK では提唱されます。
※ 画像引用: https://products.sint.co.jp/obpm/blog/serial-umeda07
ちなみに PMBOK では、各プロセスの作業順序が時系列的なものとは考えていません。 立ち上げ → 計画 → 実行 ... のような大きな流れはあるものの、スコープの定義が含まれている計画エリアの中などについては、むしろスコープ・スケジュール・コストなど各プロセスは並行に行われるべきだと考えます。 スコープが分からないとスケジュールが組めないのもわかりますが、スケジュールをある程度決めないとスコープも決められないですしね。
マネジメントを学ぶものからすると行うべき綺麗な一本道が示されて欲しいものですが、現実問題そうはならないんですね。適宜、並行して必要な作業を行っていきましょう。
※ 画像引用: https://ssaits.jp/promapedia/concepts/5-process-groups.html
まとめ
まとめるとスコープの確立に必要な作業は以下のようなものになります。
- プロジェクトの目的・背景を抑える ( スコープの核を知る )
- ステークホルダーを知る ( スコープに影響を与える人を知る )
- 要求事項を洗い出す ( やりたいことを一覧化し、優先順位を整理する )
- スコープを決める ( やること・やらないこと・やり方・作るもの などを明文化し、合意する )
- WBS を作る ( やることの解像度を上げていく )
ここまでやってもまだまだスタート地点ですが、しかしこのステップを踏むのと踏まないのとでは、プロジェクトの進めやすさやスコープクリープの発生率などが大きく異なるのではないかなと思います。 プロジェクトに限らず何か新しいことを始めることがあれば、少し思い出してもらえたら嬉しいです。
終わりに
ということで今回は PMBOK に則ったスコープの確立の仕方についての記事でした。 今回触れていないこととして「スコープマネジメントの計画」や「統合変更管理 (スコープの変更管理)」などについての解説も PMBOK には記載があるので、もし興味があればそちらも調べてみてもらえればと思います。
弊社 Belong では一緒にサービスを育てる仲間を募集しています。
もし弊社に興味を持っていただける方がいらっしゃったら、 エンジニアリングチーム紹介ページ をご覧いただければと思います。
では今回はここまで。サヨウナラ！