第5章:プロジェクトスコープマネジメント
ここでは、プロジェクトスコープマネジメントをまとめます。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
keywords
- スコープマネジメントとは何か?
- プロジェクト選定手法
- プロジェクトの立ち上げ
- プロジェクト憲章
- 制約条件・前提条件
- スコープ記述書
- スコープマネジメント計画書
- 成果物によるプロジェクトマネジメント
- デルファイ法
- WBS
- 要素分解
- スコープ検証
- WBS辞書
スコープマネジメントとは何か?(p.51)
PMBOKは直訳→正確だがわかり辛いので、解説する。
- プロジェクトの全フェーズ(立ち上げ/計画/実行/コントロール/終結)のそれぞれにおいて、必要な作業をスコープという。スコープマネジメントとは、プロジェクトの全フェーズで必要な作業をマネジメントすること
- 「スコープ」を「マネジメント」するということは、上記の作業のうち、ムダな作業を発生させないようにすること
- ただし、足りない部分を発生させてはいけない。プロジェクトを成功裏におさめるために、必要な作業を過不足のないように、また抜けがないようにすること
- 何に対して過不足、抜けがないかというと、プロジェクト憲章に対して。プロジェクト憲章は抽象的な書き方をしているかもしれんが、ここに書いていないことはプロジェクトに不要なこと。つまり、プロジェクトに必要な作業はプロジェクト憲章に書いてあるべきともいえる
- そのために、「その仕事が過不足なくホントーに終わっているのか?」「抜け落ちている作業はないか?」を定期的にチェックする必要がある
プロジェクト選定手法(p.54)
PMBOKの訳があまりにアレなので、原語を記す。こっちの方が分かりやすいと思う。
1. Benefit measurement methods
2. Constrained optimization methods
1.は、複数の案のそれぞれの利点(benefit)を得点方式で測る(measure)やりかた。複数案を比較する際に有効のため、比較研究アプローチとも呼ばれる。以下の例があるが、覚える必要はなく、「ふーん」ぐらいでよい。
- 比較研究法
- 得点モデル
- 利益分担法
- 経済評価モデル
2.は数学的に厳密に計出するやりかた。なんらかの数式を当てはめるため、数学的アプローチとも呼ばれる。リアルを無理くりあてはめようとするため、さまざまな前提・制約条件が課される(constrained)だろうし、モデルにあわせて最適化された(optimization)インプットをするだろうし。以下の例があるが、覚える必要はなく、1.との違いだけを押さえておけばよい。
- 線形計画法
- 非線形計画法
- 動的計画法
- 整数計画法
- 多重目標計画法
さて、ここで訳語を紹介します。自分の説明もアレだけど、この訳もアレだと思うぞ。
1. Benefit measurement methods→利益測定法
2. Constrained optimization methods→制約条件最適化モデル法
ポイントは「○○計画法」とついてたら「制約条件最適化モデル法」のこと。
プロジェクトの立ち上げ(p.52)
プロジェクトの立ち上げ時にすることは以下の通り。
- プロジェクト選定基準に従い、プロジェクトを選び取る
- 母体組織の戦略計画を確認する
- 過去の情報を収集する
- プロジェクトの成果物を洗い出す(成果物記述書)
- ざっくりとした見積もり(時間・スコープ)
- 制約条件や前提条件を洗い出す
- どんな人的資源(スキル、数)が必要か洗い出す
- プロジェクト憲章を確定する
- ステークホルダーの要望/ゴールをヒアリングする
- プロジェクトのポリシーやコンプライアンス(遵守するべきこと)を確認する
- プロジェクトの成果を測るための基準を決める
- プロジェクト憲章に従い、プロジェクトを正式に認定してもらう
- プロジェクトマネージャを選定・任命する
立ち上げ段階で必ずしもプロジェクトマネージャが選定されているわけでないことは、言わずもがな…だけど、リアルでは違うよね… PMBOK書いたヒトもそれは分かっているみたいで、「プロジェクト・マネージャはプロジェクトの初期段階のできるだけ早い時期に選定し、任命すべきである」なんて書いてある(p.55)。
プロジェクト憲章
プロジェクト憲章とは何か? プロジェクト憲章に必要なものを選べ… プロジェクト憲章のおかげでプロジェクトマネージャはどんなメリットがあるのか… という問題が出る。で、たいていの人は間違えるそうな。だって、プロジェクト憲章なんて見たこともないからな(w(ひょっとすると私だけなのかもしれんが)
プロジェクト憲章とは、
- プロジェクトの定義(何をプロジェクトとするのか)
- プロジェクトマネージャの権限の定義(プロジェクトマネージャが予算/スケジュール/スタッフを使えるように権限を与えるのは誰か)
- プロジェクトの成果は何か(そのプロジェクトが"成功した"ことを測るための成果は何か)
- ビジネスニーズ(どうしてそのプロジェクトが必要なのか)
- 成果物の定義(どんな成果物を求めているのか)
例
───────────────────────────
プロジェクト憲章
───────────────────────────
1.プロジェクト名/プロジェクトの定義
このプロジェクトの名称は会計システム更改のための予備調査プロジェクト。10年来使い続けてきた社内レガシーシステム(会計システム)を、クライアントサーバ方式を用いて更改する。このプロジェクトでは、以下の事項を調査・検証を行う。
- 適用できる技術
- 時間・コスト見積もり
- 更改する範囲の見積もり
- プラットフォームの選択
2.プロジェクトマネージャ/プロジェクトマネージャの権限
プロジェクトマネージャは相沢祐一次長としチームメンバーの選択およびプロジェクト予算の最終決裁権を持つ。
3.プロジェクトの成果
着手より7週間以内に、投資対効果が最も高いプラットフォームが提示され、実現性が最も高い技術が洗い出されていること。また、予備調査の後、更改プロジェクトの実行にあたり必要な時間/コスト/スコープの見積もりがなされていること
4.ビジネスニーズ
現行システムの運転費用および保守費用は、あわせて年間1200万円費やされている。新技術の適用によりこれを削減したい
5.プロジェクトの成果物
- 採用プラットフォーム案(最低限Linux/Windowsの両案併記)およびその投資対効果のレポート
- 適用技術、使用言語、通信方式、開発方式のレポート
- 時間/コスト/スコープの見積もり
- 分析レベルのユースケース
上記内容で了承
署名:取締役 水瀬秋子
───────────────────────────
少なくとも私には、PMP勉強を始めるまでは、こんなもの見たことも聞いたこともありませんでしたな(私の不勉強なだけなのかもしれないが…)。この存在を知ったとき「どうしてそんなものが必要なのだろう?」と考えたものよ。
プロジェクト憲章のメリットは、PMBOKではこう語られている… (リアルではどうか不明)
- プロジェクトマネージャに権威を与える。プロジェクト憲章のおかげで、使えるリソースが明示され、チームメンバーの理解と協力を得ることができる
- 正式・公式に「プロジェクト」の存在を知らしめる効果がある
- プロジェクトのゴール・目的をハッキリさせる
「正式にプロジェクトを確定する」…これは確かにその通り。なんだか知らないうちに人が寄せられてきて、なんだかよく分からないがコレをヤレ!と命令されて、なんだか知らないうちに死の行進が始まっていた… なんてことよくあるし。少なくともどんなプロジェクトにかかわっているのかを知らしめるためには、必要だね。
「プロジェクトの目的を確定する」…これも激しく同意。「いったい何を目的としてこのプロジェクトを進めているのだろう?」という疑問、抱いたことありませんか? やるべきことは多々あるし、時間に追いまくられているのだが、そうやっているのは「何のためか?」を知らされないまま、毎日を毎週をこなしていませんか?
プロジェクト憲章で試験に出そうなところは、
- プロジェクトマネージャの上司が誰かがハッキリする
- 立ち上げプロセスで作成される
- プロジェクトマネージャが作成するのではない
- プロジェクトのおおまかな方向を示すものであり、プロジェクトが転ばない限り変更されることはまずない。変更の際は当然、署名した人の同意を必要とする
- プロジェクト憲章は、スコープマネジメントの立ち上げプロセスのアウトプット
制約条件・前提条件(p.55)
プロジェクトマネジメントでできることに対する制約条件のこと。例えば、スコープ、要員、予算、スケジュールなどがある。契約に基づいたプロジェクトである場合、「契約」そのものが制約条件となる
スコープ記述書(p.56)
スコープ計画のアウトプット。ステークホルダー間で、「プロジェクトの範囲はこれだ」というものを共通認識できるようにまとめたもの。例えば、プロジェクトの目標。つまり、そのプロジェクトが成功したかどうかを判定するための基準のこと。コスト○%削減とか、顧客満足度指数○ポイントアップとか。あるいは、プロジェクトの成果物。そのプロジェクトで作り上げた製品やサービスなど
スコープマネジメント計画書(p.56)
PMBOKの説明が酷い。読むと余計に分からなくなるので次の説明で理解してほしい。スコープマネジメント計画書には、以下の2つのことを記述する
- スコープをどのように管理するのか(記録方法など)
- スコープの変更をどのように管理するのか(変更の手続き、変更履歴の管理、ステークホルダーへの変更の通達)
成果物によるプロジェクトマネジメント
Manegement by Objectives(MBO)のこと。プロジェクト成果物によるプロジェクトマネジメントのことだが、カンタンにいうと、具体的に得られる成果物が、事前に計画したものとズレがないかチェックすること。
そのプロジェクトが上手くいっているかいないかは、進捗度合いやレポートでは測りづらいものがある。しかし、実際に得られる成果物(製品の試作品やプロトタイプされ実際に動くコード)ならとても具体的。その具体的なモノが、計画で見積もったモノとずれていないか定期的にチェックし、ズレがありそうなら是正措置をとる、ということ
デルファイ法(p.132)
専門家から意見を得る方法。スコープ、見積もり、リスクで用いる。PMBOKはリスクマネジメントで出てくるが、リスクに限定せず使える。自分の経験上、スコープ>見積もり>リスクの順に使える(だって何しなきゃいけないのかを見落としたら目も当てられないからね)。
デルファイ法のルールとして「意見を求める人どうしは、お互いに匿名性を保つこと」というのがある。人は権威に流されやすい。この方法は余計なバイアスを排除し、意見同士が相互に影響し合うのを回避することを目的とする。
だからといって、意見を聞きっぱなしで終わってはダメ。意見のコンセンサスを得るように努力すること
WBS(p.59-61)
Work Breakdown Structure のこと。PMBOKのキモであり、見積もり、リスク、要員計画、ネットワークダイアグラムへ派生する元ネタでもある。最も間違えやすいところでもある(かくいう私も練習問題ではさんざんだった…)
WBSとは、
- プロジェクトスコープを分割していったもの
- 階層型構造をもつ
- 下位層を上位層が統合する(下の層ができて上の層が完了したといえる)
- 分割していって、最終的には、理解しやすく実現可能で扱いやすいタスクレベルまでたどり着く(リアルではそーはいかんだろうが)
- いわゆる「組織体制図」に見た目は似たところがあるが、人ではなく仕事を割っているところが偉い違う
- チームメンバーによって作成される
- そのプロジェクトで行う全ての仕事が書かれている。モレヌケ省略があるようならそれはWBSとは言わない
- 作業そのものよりも成果物を目標としたタスクに割られている(○○をする、ではなく、○○をすることで△△を作り出す)
- 過去のプロジェクトから拝借可能
WBSの最上位にはプロジェクト名そのものが入る。最初の階層には、例えばソフトウェア開発であれば、「要因分析」「設計」「コーディング」「テスト」「移行」…などが入る。最終的には実現可能なタスクレベルにまで分割され、一つのタスクはだいたい数時間から数十時間で終わるレベルの作業にまで分割される
WBSはスコープ定義のアウトプットであるが、これが次のどのインプットになっているのかに注目
- WBSは、タイムマネジメントの6.1アクティビティ定義のインプットとなっている。このプロセスを経てWBSはリファインされ更新版が作成される。同時にアクティビティリストが作成される。WBSはプロジェクトに必要な全てのタスクを階層的、体系的に構成している一方で、アクティビティリストはプロジェクトに必要な全てのタスクを順序性、相関関係を保って構成される(6.2アクティビティリスト順序設定)
- WBSは、コストマネジメントの7.1資源計画プロセスのインプットとなっている。どんな資源を必要とするかは、どんな仕事をしなきゃいけないかに拠るからね
- WBSは、コストマネジメントの7.2コスト見積もりプロセスのインプットとなっている。あたりまえだが、いくらかかるかは、どんな仕事をしなきゃいけないかに拠るから
- WBSは、コストマネジメントの7.3コストの予算化プロセスのインプットとなっている。7.1~7.3はコストマネジメントの計画プロセス。要はコストマネジメントの計画段階の全てのインプットにWBSを要するということ
- WBSは、人的資源マネジメントでも必要とする。どこにも"WBS"の文字列がないって? そだね。でも9.1組織計画プロセスのインプット「要員に対する要求事項」を読んでくれ(p.109)。要員に対する要求事項は、7.1資源計画プロセスのアウトプット「資源に対する要求事項」の一部分を成しているんだ。こんなカンジ:WBS→7.1→9.1のフローで資源、人的資源がリファインされる
- WBSは、リスクマネジメントの11.1リスクマネジメント計画プロセスのインプットとなっている。私見だが、ここにWBSを持ってくるのは間違いだと思う。本来ならば11.2リスク識別のインプットとして入れるべきなんだろうが、PMBOKでは11.1マネジメント計画プロセスなんだって。「そのタスクを実行するにあたって予見されるリスクは何だろうか?」と考えるべきなのに… やっぱり現場と離れてるな…
すこし先走ってしまったが、WBSがいかに重要かは理解できたと思う。つまり、WBSがヘボかったら、タイム、コスト、人的資源、リスクの計画プロセスのインプットからしてモレヌケがあるということ。もっと怖いのはモレヌケがあることに気づかない、ということ。そりゃそうだよな。タイムマネジメントを想定してみてくれ。「そのタスクがある」ことが情報として渡されなければ、当然「そのタスクにかかる時間見積り」はなされないだろうし…
ありがちなのは環境まわりかな。「linuxでなんか作れ!」と言われても、言われたほうがマカーだったりwinだったりしたら、その環境を構築する作業があるはず(習熟トレーニングも含めるとさらに)。で、気づくんだよな、プロジェクトが回りはじめてから(もう遅いって)
WBSはプロジェクトの根幹を成すといっても過言ではない。WBSに書いていないことは「そのタスクはプロジェクトではない」と言い切ってもいいぐらい(リアルでは偉い違うかもしれないが…)
WBSにモレヌケがある==プロジェクトそのものにモレヌケがある
実行プロセスでの話。WBSではタスクが階層的にグラフィカルに見えるため、そのタスクを実行するメンバーは、全体のどこを担っているのかがすぐ分かる。つまり、自分が携わっている成果物が全体のどこに位置するのか、指さしができるということ。
こんな経験ありませんか?(私はちょっちゅう)→「いま作っているツール、これどこで使うんだろ?」「このドキュメント、言われたから作るけれど、ここまで詳細化するべきものかぁ? どこで使うんだろ?」…もちろんWBSさえあればこんな思いはなくなるとは言わない。ただ、WBSを作る過程で「全体から見たときのそのタスクに求められるもの」が明らかになるのは事実。実際に、やってみると変わりますぞ(→まず自分のプロジェクトから)
要素分解(p.58)
PMBOKでいっぱい書いてあるが、「へぇ」レベル。試験の役にも立ちそうにないし、リアルではさらに使えないし… 要は、要素分解とは、扱いやすいレベルにまで分解すること
- 何を分解するかって? それは、成果物や仕事(work)を分解すること。試験工程なら、試験リスト作成、試験リスト実施、試験結果検証に分解すること
- どのレベルにまで分解するかって? それは、作業時間が把握できるレベルにまで分解すること。デザインパターンなら、singleton や factory method を使うんだよなーというレベルまで。システムインテグレーションテストなら、注文パターンの種類×試験リスト項目概数まで
- で、誰にとって扱いやすいかというと、これを読んでいるあなた。即ちプロジェクトマネージャにとって扱いやすいことが重要。よい例がある→むかし大先輩に教えられた大切なこと。それは「あなたができないような仕事を他人に任せてはいけない」。その頃自分はプログラマだったんだけど、自分が理解できない方式、説明できない概念を振り回していたっけ… それを諭すつもりで言ったんだと思う。自分が説明できないような仕事を扱ってはいけない。賢(さか)しらはキケンだ。他人に任せるときには「自分でもできるのだが、それをやる時間/マンパワーが足りないから、貴方にお願いします」というつもりでやらないと、思わぬ行き違いが出てくるよ、ということ。チョト脱線したけれど、要素分解の極意はコレ。プロマネが把握/説明/理解できないレベルの仕事単位に切ってあるのなら、きっとロストするだろうね、そのプロジェクト
スコープ検証(p.61-62)
「ステークホルダーに対し、スコープを公式に受け入れてもらうこと」…がその定義だが、具体的に書いたほうがわかりよいだろう。スコープ検証とは、
- インスペクションレビュー
- 製品レビュー
- ウォークスルー(*)
- できあがったもの(成果物、要素成果物)が受け入れられるかどうか、チェックする/チェックしてもらうこと
- んで、ちゃんとOKの意味のサインしてもらうこと
*この言葉、皆様、いろいろな意味で使っているケド、ちゃんと分かってるのだろうかとココで言ってみるテスト。ま、ヨコモジを使うとかっちょええし、できる人みたいなフリもできるしね(w → walk-through:セリフに動きをひと通り合わせてみるリハーサル、立ち稽古のこと。転じて「一連の流れを通しでテストすること、チェックすること」
重要:スコープ検証と品質管理との違いは、以下の通り
- スコープ検証とは、作業結果が受け入れられるかどうかチェックすること
- 品質管理(p.102)とは、作業結果が何らかの基準に照らし合わせて正しいかどうかチェックすること
みんなもあるよね? 「品質的に問題アリかもしれないが、納期は今日だ!仕方ない…」なんて悲しい話
WBS辞書(p.61)
試験でもリアルでも重要なのに、なぜかPMBOKでは3行しか書いてない不思議。WBS辞書はチームメンバーの協力により作成されるもので、どんな作業がいつ成されるのかが記述してある。タスク記述書(task description)とも呼ばれる。こんなカンジ
例
───────────────────────────
WBS辞書(タスク記述書)
───────────────────────────
プロジェクト名:会計システム更改のための予備調査プロジェクト
- タスク内容:システム方式案による性能の検証
- 成果物:方式案ごとの性能レポート
- 受け入れ基準:50キロバイト程度のhtml文をCORBA/IIOP,RMI,httpトンネリング,ftpで通信した結果の処理速度が、システム方式案毎に計出されていること
- 必要な人員:上記の通信方式の環境を構築できる人
- 必要な資材:上記の通信方式に必要なハードウェア/ソフトウェア
- 期間:環境構築も含めて6日
- コスト:社内の資材で対応可能
- 期限:2004/4/14まで
- 依存するタスク:タスクNo.8より前に完了。タスクNo.1より後でなければこのタスクを開始することはできない
承認者:相沢祐一(2004/4/3)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PMP試験対策の目次に戻る
--

| 固定リンク
コメント
ウォークスルーって単に読み合わせのことじゃないでしょうか?
投稿: | 2005.03.09 13:30
読み合わせ… 言われてみれば確かにそうかもー
ご指摘ありがとうございます。
あらためて考えてみると、「業務フローの一連の流れを念頭において、各々の機能を通しで検証すること」だと思います。
投稿: Dain | 2005.03.11 00:07