うーむ、長いタイトルだな（笑）。そもそも、「プロジェクト・インテグレーション・マネジメント」という用語自体が長い。カタカナで23文字もある。PMBOK Guideの邦訳版のように「プロジェクト統合マネジメント」としても、14文字だ。しかしこれ、”PIM"とかって3文字略語にしても通じないだろうし、致し方ないだろうな。 前回の記事にも書いたが（「プロジェクト・インテグレーション・マネジメントと『鉄の三角形』」https://brevis.exblog.jp/27102305/）、現在のPMBOK Guideには、PMに必要な10のマネジメント知識エリアが列挙されている（初期の頃は9個だった）。そしてその中核となるのが、「プロジェクト・インテグレーション・マネジメント」（ああ長い^^;）である。それは、他の9個の領域のマネジメントを統合する。そして、他の9個の領域には、とくに順序はなく、対等だということになっている・・PMPの試験対策的には。 しかし、もちろんそんな事は嘘である。９つの領域：スコープ・スケジュール・コスト・品質・人的資源・コミュニケーション・リスク・調達・ステークホルダーエンゲージメント、の間には、実務上、明確な軽重があり、そして順序に関する依存関係がある。なぜそういうことをPMBOK Guideがはっきり書かないのか、わたしにはよく分からない。だが、9個のマネジメント領域の間をどう調整していくかこそ、「インテグレーション・マネジメント」の一番大事な機能である。こうしたことを知らないと、プロマネの実務上、明らかに不便だ。だから、ここにそれを記しておこうと思う。 まず、プロジェクトを取り巻く様々な制約条件の内、もっとも広く存在し、そして強くしばられるものは、「スコープ」（役務範囲）と、「予算」と、「納期」の三つである。そこで、これを『鉄の三角形』と呼ぶことは、前回も書いた。言いかえるなら、プロジェクト遂行において、プロマネがつねに意識の上位においておかなければならないのは、スコープ・スケジュール・コストの3つである。そして、だからこそ、PMBOK Guideはごく初期の版の頃から、この3領域が最初の方におかれてきたのだ。 もちろん、プロジェクトにはいろいろな種類があるし、個性や取り巻く状況も様々だ。だから、納期制約のないプロジェクトもあるし、予算を気にしなくてもいいプロジェクトだって（うらやましい限りだが）希には存在する。逆に人的資源（つまり配員）の制約が一番きついとかいうケースだって、あるだろう。ただ、もっとも多くの場合、上記の3つが主要な制約条件なのである。 ちなみに、受注型プロジェクトと違い、自発型プロジェクトの場合は、スコープ制約よりも品質（ないしプロダクトの性能）制約の方が優先される場合も多い。とくに新製品開発などではそうだろう。また、納期制約や予算枠も、受注型より弱い場合がある。でも、通常は「スコープ・コスト・スケジュール」または「品質・コスト・スケジュール」が、プロマネにとって主要な関心事項なのである。 （なお、品質とスコープの間には相補的関係があるのだが、この話をしていると長くなるので、別に書くことにする） そもそも、上に掲げた９つの要素のうち、プロジェクトの目標や制約になり得るのは、スコープ、コスト、スケジュール、品質の４つである。これらは、仕事のパフォーマンス指標と言っていい。人的資源は制約にはなり得るが、それ自体が目標になることはない。逆に、リスクとは基本的に、目標の反対概念であって、あまり歓迎されざる環境的要素である。そして、それ以外の、コミュニケーション、調達、ステークホルダーエンゲージメントなどは、目的と言うよりは手段に関することである。 ということで、上に掲げた9つの領域は、 (1) 主要な領域： スコープ、コスト、スケジュール (2) それに準じる注意領域： 人的資源、品質、リスク (3) 上記を支える補助的領域： コミュニケーション、調達、ステークホルダーエンゲージメント という風に層別することができる。 これらは、互いにいろいろな形で関係し合っている。それを認識し、うまく調整・統合するのがインテグレーション・マネジメントだ、という訳である。主要とか補助的とか分類したが、補助的だからといってコミュニケーションとかステークホルダー・エンゲージメントをおろそかにすると、結局は品質やリスクを経由して、大事なお金と納期にはね返ってくる。 とくに、これらの要素間の関係性を意識しなければならないのは、計画作成段階である。プロジェクト・マネジメント計画書の策定において、間違った順序で進めると、とんでもない計画が生まれてしまう。 プロジェクトの計画立案において、まず真っ先に着手しなければならないのは、スコープ定義である。「スコープ」の制約とは、「役務範囲」のことだと、上で書いた。役務範囲とは契約用語だが、とにかく「やらなければいけない責任範囲」を意味する。言いかえると、プロジェクトを構成する必須の作業（Activity）の集合を指す。 といっても、契約書にリストがあって、「これこれのActivityを全部実行せよ」などという形で、制約が与えられることはない。普通、もっと大まかな形で、受発注者の間の責任範囲が指定されるだけだ。では、どうやって「こんな注文を出されたらスコープ外なので追加です」などと主張できるのか？ じつはスコープは2段構造になっている。まず、成果物のスコープ（プロダクト・スコープ）がある。これは、プロジェクトの成果物がどのような特性を持ったもので、およそどのような構成になっているかを示したものだ。契約書に規定されるのは、主にこちらである。たとえばPCのセットが成果物ならば、CPUとボードと筐体とモニタとキーボード、といったモノのスコープが列挙される。 この成果物スコープを、すべて算出するための作業（Activity）を拾い出す。その結果うまれるのがプロジェクト・スコープだ。つまり、プロジェクト・スコープとは、Activityの集合である。通常それは、階層的に構成され管理番号を付番されたWBS（Work Breakdown Structure）の形で表現される。WBSはスコープの表現形で、ベースラインとも呼ばれる。 そしてこのWBSが、その後の計画作業の主要なベースとなる。 まずは、WBSを構成するそれぞれのActivityを、誰が責任を持って遂行するかを考えなければならない。これは、かつて「WBSはプロジェクト組織を規定する」（https://brevis.exblog.jp/19096066/ 2012-10-24）に書いたとおりである。「誰が」といっても、別に個人の名前まで全て決める必要はない。計画段階では、職種と大まかな人数を考えればいい。それがプロジェクト・チームの組織図と役割となる。 そして、Activityに割り当てた人数と、その仕事に必要な作業量、そして一人あたりの生産性から、各activityの所要期間が推算できる。また、各Activityのアウトプットとインプットを明らかにすると、Activity間の依存関係（Aが終わらなければBが開始できない、など）が分かる。それをもとに、プロジェクト全体の中での、Activityのつながり（ロジック・ネットワーク）を作る。そうすると、クリティカル・パスが計算でき、プロジェクトの全体工期も見えてくる。これがスケジュール計画である。 かくして、動員する人数、各Activityの期間、それに付随する工数と、外部費用などをWBSの構造に従って積み上げることによって、プロジェクトの実行予算計画ができる。全体をまとめると、次のようなステップで、プロジェクト計画は立案されるのである。 まあ、より細かく言うと、コスト計画の後でリスク・アセスメントをやって対策を考え、それによってスケジュールやコスト計画の内容に戻って修正するとか、あるいは品質計画や調達計画も必要な場合が多いとか、いろいろある。だが、大筋で言うと、スコープ・組織・スケジュール・コストの4つの柱をおさえなければ、プロジェクトの計画を作ったとは言えない。  逆に言うと、スケジュール計画が見えないまま、コスト推算や予算計画を立てても、意味が無い。また、プロジェクトの組織や人数が決まらぬ段階で、スケジュールは計画できない。そして、組織はWBSがなかったら決まらない。WBSはスコープ定義がなければ作れない。こういう順序でしか、計画立案はできないのだ。 ところが、現在のPMBOK Guideでは、なぜかこうしたプロジェクト計画立案の流れが、明確に書いていない。かわりに、プロジェクト・インテグレーション・マネジメントの章の説明によると、「プロジェクト・マネジメント計画書は、スコープ・スケジュール・コスト・品質・・等の「補助的マネジメント計画」とベースラインを、インプットにせよ、と書いてある。まるで、各領域の計画を独立に別々に作っておいて、最後にバインダーでまとめれば計画書ができあがる、といわんばかりだ。 もちろん、そんなおかしな事はない。こういう書き方になっているのは、「段階的詳細化」にしたがって、プロジェクト・マネジメント計画書を何度か作り直しブラッシュアップするはずだ、という考え方が背景にあるのだ。そして、コスト見積が、WBSのベースラインをインプットとする、といった依存関係も、確証を細かく見ていくと書いてある。だが、全体としては、9つの領域が平等に、並列に、そしてあまりお互いに関係なく成立するような印象を受ける書き方だ。これは、とてもミス・リーディングな説明ではないかと思う。 ちなみに念のため、2000年に発行された、古い「PMBOK Guide 第2版」を見直してみたら、なんのことはない。Project Integration Managementの章に、ちゃんと計画立案の流れ図が描いてあるではないか。  作業の分割の仕方は、わたしの5ステップと多少違って、より詳細だが、大筋としての流れは似ている。というか、実務的にはこういう順序でやるしかないのだ。そして、こういう図がある方が、全体の関係がずっと分かりやすいと思うのだが。 PMBOK Guideがなぜ、こうした図をやめてしまったのか、正確な理由は知らない。ただ、9つの領域を独立に並列に扱ったのでは、プロジェクト・インテグレーション・マネジメントにならない、ということはもっと強調されるべきだと思う。 そして、このことは、むしろプロジェクトを発注する側の責任者に、ちゃんと理解してほしいと思うのだ。発注者が、あとから思いついたようにいろんな注文を出し、スコープを変更しておいて、しかしコストも品質も納期も「元のままでやってくれ」、と言ってくるケースを、しばしば目にしてきた。だが、そんなことはプロジェクト統合の原理から言って、不可能なのだ。プロジェクトの要素は互いに絡み合い、関係し合っているのであって、一つだけを勝手にかえることはできない。そういう基本的なことを、わたしは多くの発注者に理解しておいてほしいと思う。 わたしは機会があって、ときどきPMの教育研修を手伝うこともあるし、また自分が主査を務める研究部会などで他の業界のPMの方々と話すこともある。そうした中でしばしば痛感するのは、多くの受注側のプロマネの苦労が、発注者側のプロジェクトへの無理解に起因しているという事実である。とくにIT分野で、この傾向は強いのではないか。 発注者はもっと、プロジェクトの性質を理解してほしい。何か変更を要求するにしても、せめてリーズナブルな要望の形でだしてもらいたい・・こう感じているプロマネが、いかに多いことか。これは、とても残念なことである。そして、はっきりいってIT業界の損失でもあると思う。 プロジェクトは、9つもの要素が複雑に関係し合った、一種のシステムである。だから、システムズ・アプローチをもって扱わなければならない。こういう理解を、もっと多くのユーザ企業の情シス部門が知ってほしいと願うのである。
by Tomoichi_Sato
| 2018-03-08 23:56
| プロジェクト・マネジメント
|
Comments(0)
|
検索
カテゴリ
著書・姉妹サイト
私のプロフィル My Profile
【著書】 「世界を動かすプロジェクトマネジメントの教科書  」「時間管理術 」(日経文庫)「BOM/部品表入門 (図解でわかる生産の実務) 」「リスク確率に基づくプロジェクト・マネジメントの研究 」【姉妹サイト】 マネジメントのテクノロジーを考える Tweet: tomoichi_sato 以前の記事
最新のコメント
最新のトラックバック
フォロー中のブログ
ブログパーツ
ファン
記事ランキング
ブログジャンル
画像一覧
|
