PMBOK特集 第一部 デスマーチとPMBOK −なぜ、いまプロジェクト管理か 中山 幹敏 今や日本においても、プロジェクトを管理する手法として一般的な認知を受けているのは、PMBOK（ピン ボック）である。PMBOK は Project Management Body Of Knowledge のそれぞれ頭文字をとった略称で、日 本語での名称を「プロジェクトマネジメント知識体系」という。PMBOK を提唱しているのは米国のプロジェ クトマネジメント協会（Project Management Institute, PMI）で、同協会は『PMBOK ガイド 第 3 版』を発 行するとともに、それに基づく認定資格である PMP（プロジェクトマネジメント・プロフェッショナル）試 験を実施している。この特集では、第一部においてソフトウェア開発で見られる「デスマーチ」プロジェク トの分析を通して PMBOK の必要性を検討し、第二部では開発業務に適用する観点からみた PMBOK の特長に ついて解説する。 デスマーチとは 「デスマーチ（死の行進）」−この穏やかならぬ 言葉が、ソフトウェア開発に携わる人々の間で使 われることがしばしばある。プロジェクトはさま ざまな要因が絡み合ってデスマーチに陥ることが ある。そうなると、プロジェクトは、死の行進の ように、終わりの見えないなか、ひたすら前進し なければならなくなる。メンバーの深夜残業、徹夜、 週末出勤が続き、それでも納期を守れそうもない。 クライアントや上司からは理不尽な（あるいは理 不尽と思える）要求や脅しを受ける。やっとの思 いで、なんとかプロジェクトを終わらせても、身 体的・精神的に体を壊すメンバーや退職を決意す る者など、いわば「傷病者」や「戦死者」を生む ことさえある。 「デスマーチ（death march）」という語は、もと もと、第二次世界大戦末、敗色が濃くなったナチス・ ドイツが、強制収容所からの撤退時に、収容者を 歩かせて別の場所に強制移動させたという事件を 指して使われる言葉である。たとえば、1945 年 1 月、ナチスはソ連のポーランド侵攻を受けて、ア 2 ウシュヴィッツにいた六万人を行進させて、50 キ ロ以上離れた収容所に移動させた。その途上で約 一万五千人が死んだ。それ以外のナチの強制収容 所でも同様のことが起きた。またナチスだけでな く、日本軍も、第二次世界大戦中にフィリピンの バターンで戦争捕虜に死の行進をさせた。 忌まわしいデスマーチであるが、この言葉をソ フトウェア開発の悲惨なプロジェクトに使ったの はエドワード・ヨードン（Edward Yourdon）であ る。ヨードンは「コード／ヨードン法」というオ ブジェクト指向分析／設計法を開発した人物とし て有名である。現在では、オブジェクト指向の分 析といえば、UML（統一モデル記述言語）が一般 的に使われるが、「コード／ヨードン法」はそれ以 前の主要な分析／設計法の一つであった。 ヨードンが「デスマーチ」というタイトルの書 籍を執筆したのは 1997 年である。多くの反響が あり、2004 年には「デスマーチ第 2 版」を書い ている。第 2 版の日本語訳は、（第 1 版と同じ）松 原・山浦訳で 2006 年に日経 BP 社から出版されて いる。 その本の中で、ヨードンはデス こ の「 失 敗 す る リ ス ク が 50% マーチ・プロジェクトを次のよう を超える」プロジェクトという定 に定義している。 義の方が包括的である。開発プロ デスマーチ・プロジェクトと は、『プロジェクトのパラメー タ 』 が 正 常 値 を 50% 以 上 超 過したもの（「デスマーチ第 2 版」、p.2） 『プロジェクトのパラメータ』 には、スケジュール、人員、予算、 ジェクトを成功させるには、スケ ジュールや人員や予算などの開発 資源が十分そろっていなければな らないが、根本的には開発資源の 不足がデスマーチ・プロジェクト の原因である。 デスマーチに至る要因と結末 機能などがある。スケジュールや では、何が要因となって開発資源 人員や予算が予想される規模の半 の不足に至り、デスマーチが始まる 分であったり、逆に機能が予想の のだろうか。いくつかの段階で要因 倍以上であったりするなら、プロ となるものを検討してみよう。 ジェクトはデスマーチに陥るとい うのである。確かに無理には限度 があり、納得できる話である。 プロジェクト計画：当初から、無 理な予算とスケジュールでプロ ジェクトが始まる場合がある。受 もちろん、50% 以上超過してい 託でソフトウェア開発を行ってい なくてもデスマーチになるプロジェ る場合、要件が固まらないまま概 クトもある。したがって、ヨードン 算見積りが先行し、いったん出た は次のような定義もしている。 概算見積り額が一人歩きを始める ながらもプロジェクトが進むこと がある。 要件定義：デスマーチに至る大き な要因の一つは、要件定義の段階 でクライアントの仕様があいま いであったり、クライアントが要 件を明確に決めようとしなかった りするなど、要件定義の甘さにあ る。仕様のずれは、後の工程での 仕様変更につながる。特に、テス ト段階で発生する仕様変更は、プ ロジェクトに破壊的な影響を及ぼ すことがある。 設計：設計段階で問題となるのは、 クライアントと開発側の「常識の ずれ」である。クライアントは、 当然ながら開発側にプロとしての 常識を期待して、つまり言わなく てもそれくらいプロなら分かるだ ろうという先入観をもって発言し てくる。設計レビューにクライア ントが参加しない場合は特に、あ 公正かつ客観的にプロジェク と、無理な予算でプロジェクトが トのリスク分析（技術的要因 始まるかもしれない。また、スケ の分析、人員の解析、法的分 ジュールが上層部の「天の声」で 析、政治的要因の分析も含む） 決まったり、関連する予定の影響 をした場合、失敗する確率が を考えるとスケジュールの延期が 製造（実装）・単体テスト：残業 50% を超えるもの（同書、p.4） 難しかったりすると、無謀と思い が常態化している職場では、スケ PMP 試験 とで設計の見直しが生じることが あるが、これもデスマーチの誘因 となる。 ジュールの遅れを取り戻すべく、 製造・単体テストの段階で無理な スケジュールをこなす「精神」や PMP 試験は、プロジェクトマネジメントに関する知識、理解度を測 「文化」がしみついているかもしれ ることを目的として、プロジェクトマネジメント協会（PMI）（本部は ない。しかし、この段階でしっか 米国）が実施する Project Management Professional の認定資格試験で りしたレビューによってプログラ ある。PMP 試験に合格すると、PM の有資格者である PMP として国 ムの品質を確保しないと、テスト 際的に認定され、名刺に PMP であることを記載できるようになる。 工程での後戻りがしばしば発生し、 PMI 東 京 支 部 の サ イ ト（http://www.pmi-tokyo.org/） を み る と、 デスマーチに至ることがある。 2006 年 12 月 現 在 で、 全 世 界 で 221,144 人、 日 本 で 18,009 人 が、 結合テスト・総合テスト：テスト PMP の資格保持者である。PMP 試験に合格するには、PMBOK の知識 は、納期の迫るなか、遅延が許さ と理解が必須である。 れ な い 状 況 で、 そ れ で も 品 質 を しっかり担保するという使命のも 3 とにある。テストの品質を確保す では、開発資源の るには、テスト計画とテスト仕 不足はどのようにデ 様書をしっかりレビューしなけ スマーチによって補 ればならない。すでに述べたよ 完されようとするの うに、テスト段階でデスマーチ だろうか。ヨードン に陥る原因には、ここに至って は「デスマーチ」の 仕様変更や仕様追加があったり、 中で、興味深いネー 製造工程でのプログラムの品質 ミングをした、4 つ が低くてバグが終息しなかった り、テスト計画不足でたいへん のスタイルがあると 論じている。（図 1） 高 カミカゼ型 スパイ大作戦型 自滅型 モーレツ型 満 足 度 低 成功する可能性 高 図 1： デ ス マ ー チ・ プ ロ ジ ェ ク ト の 4 つ の ス タ イ ル （出典：ヨードン「デスマーチ第 2 版」,p.55） なテストのやり直しが続いたり 図 1 に あ る「 満 足 度 」 は ソ フ かい、その使命をやり遂げようと することなどがある。テスト要 トウェアの開発中にメンバーが する。犠牲者が出るかもしれない 員 も プ ロ グ ラ ム の 修 正 要 員 も、 感じる満足度や充足度、「成功す が、成功を信じて前進するような テスト段階での最後のデスマー る 可 能 性 」 は、 デ ス マ ー チ・ プ プロジェクトである。 チで心身ともぼろぼろになる。 ロジェクトが成功する可能性の プロジェクトへの最後の一撃と 高さである。 なるのが、テストである。 ほかにも、事故やけがなどによ る必須メンバーの脱落、あるいは 「モーレツ型プロジェクト」と は、軍隊式のスパルタ・プロジェ 「スパイ大作戦型プロジェク クトである。ヨードンは、この型 ト」とは、デスマーチの中でも成 のプロジェクトの特徴として、次 功する確率の高いプロジェクトで の 3 つをあげている。 「(a) プロジェ 人員追加のためにかえって時間が ある。同名のテレビ番組や映画の クト・マネージャーはプロジェク 取られたり、技術レベルが低下し 主人公のように、不可能と思える トを成功させるつもりである。(b) たりするなど、様々なことが引き ミッション（使命）でも、「卓抜 プロジェクト・マネージャーは会 金になって、開発資源の不足が生 した技術と勤勉さ」（同書、p.56） 社の中で生き残るつもりで、プロ じることがある。 により、チームが結束して立ち向 ジェクトを成功させて利益を得よ トリアージ ヨードンは「デスマーチ第 2 版」の中で、デスマーチを回避する方法として、 「トリアージ」を強調している。 トリアージ（triage）とは、基本的に「負傷した人々を、緊急の医療処置の必要性や効果に基づいて、グルー プ分けするプロセスを言う。トリアージは、戦場、災害地、病院の緊急処置室で、割り当てねばならない医 療資源に限りがあるときに用いられる。」（同書、p.128）American Heritage Dictionary（第 3 版）からの引 用である、この定義から分かるように、トリアージは、緊急時に、限られた資源から最大の効果を得るため に取られる資源分配のシステムである。助かる見込みの高い人にまず医療処置を施すことは、心情的には複 雑であっても、緊急医療の現場では一般的に採用されているシステムだそうだ。 同じことは、デスマーチに陥ったソフトウェア開発プロジェクトにもいえる。現実的には、全機能の実装 をあきらめて必須機能の実装に絞り込んで開発資源を投入したとしても（トリアージ）、クライアントの要 求のほとんどを満たしたソフトウェアをリリースできることが多い。その後に、追加機能のリリースを段階 的に計画できる。もし全機能を予定の期日までにという戦略を取るなら、デスマーチのまま、品質の低いプ ログラムで混乱にいっそう拍車がかかり、自滅することにもなりかねない。 デスマーチから抜け出るには、政治力を使って、トリアージ戦略で交渉することを忘れないようにしたい。 4 うとしている。(c) プロジェクト・ できる体制とスケジュールで始め 確かに、デスマーチに陥ったプ マネージャーは、プロジェクトの る必要がある。たとえ完璧な体制 ロ ジ ェ ク ト を 見 て い る と、 プ ロ 成功のためならメンバーの健康や やスケジュールを組めなくても、 ジェクト管理があまりなされてい 幸せを犠牲にする（実際には、そ 少なくともリスクを認識し、リス なかったり、あるいはプロジェク うしたいと考えている）。」（同書、 クの解消に向けて継続的に対処し ト管理どころではなくなって、混 p.57）デスマーチになったとき、 ていく姿勢が重要である。 乱のなかプロジェクトが進行した こういうタイプの PM のもとで働 くと、心身とも衰弱してしまうの はよく理解できる。しかも、この 伝統は軍隊と同じように受け継が プロジェクトの計画時に、「仕 様」、「スケジュール」、「コスト」、 「品質」、「体制」、「コミュニケー りしていることがある。 それでも、デスマーチを回避す るか、あるいはデスマーチの程度 ション方法」、「リスク」、「外注」 を軽減するには、しっかりとした な ど を、 管 理 項 目 と し て 明 確 に 「プロジェクト管理」が必要とい 「自滅型プロジェクト」は、最 し、これらの項目を分析しておく うのはいくら強調してもしすぎる 悪のプロジェクトである。だれも なら、状況の変化を追跡して適切 ことのない点である。それゆえに、 が失敗すると思いながらも、プロ なアクションを迅速に取れるよう PMBOK なのである。 ジェクトから抜け出すこともでき になる。まさに「始めが肝心」で ずに、みなが破局に向かう。この ある。 れるものである。 型のプロジェクトには加わりたく ないものである。 また「計画倒れ」という言葉も あるように、計画がいかに立派で 「カミカゼ型プロジェクト」も も、その後の実施状況が芳しくな 失敗する点では、 「自滅型プロジェ いなら、当然のことながら、デス クト」と同じであるが、メンバー マーチに至ってしまう。計画の実 のモチベーションやモラールが違 施状況や進捗を「管理」し、新た う。メンバーはプロジェクトが失 なリスクを見極め、現実的なスケ 敗したとしても、プロジェクトに ジュールになるよう継続的に改善 参加できたことを誇りに思い、何 を加えていく必要がある。しかも かをつかむことができたと感じて PM は、メンバーのモラールを高 いる。そういうプロジェクトも確 めながら、プロジェクトを管理し かにあるかもしれない。 ていかなければならない。 プロジェクト管理の重要性 ヨードンの示唆に富む書物を読 みながらデスマーチ・プロジェク トを考察してみると、「計画」と 「管理」、PM の「交渉力（政治力）」 の重要性が浮かび上がってくる。 さらに PM には、管理能力だけ でなく、デスマーチを回避する「政 治的」スキルつまり「交渉力」が 求められる。PM は、利害関係者 との折衝を通して、現実的な納期 PMBOK 導入の目的 しかし、PMBOK を使った、あ るいは参考にしたプロジェクト 管 理 を 行 う う え で、 忘 れ て な ら ないのは PMBOK を導入する目的 で あ る。PMBOK の 導 入 目 的 は、 PMBOK を 使 う こ と 自 体 に あ る のではない。むしろその目的は、 PBMOK を使うことによって、デ スマーチを回避し、納期・コスト・ 品質・顧客満足のすべての面でプ ロジェクトを「成功」させること にある。その点を忘れないように して、導入目的からそれないなら、 PMBOK を柔軟に生かすことがで きるだろう。 【参考文献】 ・エドワード・ヨードン著、 『デスマー や人員や予算を確保していかなけ チ 第 2 版』 （松原友夫・山浦恒央訳） 、 ればならないが、そうした交渉を 日経 BP 社、2006 デスマーチを避ける鍵は、まず 有利に進めるには、プロジェクト プロジェクトの計画時にある。も に関する客観的なデータで理論武 ちろん、計画段階で破綻が見えて 装することが必要不可欠である。 いるプロジェクトを別にして、プ そのためにも、プロジェクトの管 ロジェクトは、デスマーチを回避 理が重要になってくる。 ・梅田弘之著、 『実践！ プロジェクト 管理入門［増補改訂版］ 』 、翔泳社、 2006 ・久手樫憲之著、 『IT エンジニアのた めの PMBOK2004 がわかる本』 、翔 泳社、2005 年 5 PMBOK特集 第二部 PMBOK入門 吉田 稔 PMBOK とは 本特集の第一部では、システム 開発における「デスマーチ」を回 避するために、プロジェクトの計 画や実行管理の重要性を論じた。 第二部では、プロジェクトを計画 したり実行管理したりするための 知識体系である PMBOK を解説す る。 第 一 部 で 述 べ た と お り PMBOK と い う 名 称 は、Project Management Body Of Knowledge のそれぞれ頭文字をとった略称の ことである。「プロジェクトマネ ジメント知識体系」という訳語が 当てられるが、日本でも PMBOK （ピンボック）と呼ぶことが多い。 PMBOK と PMBOK ガ イ ド の 違 いだが、抽象的な概念としてのプ ロジェクトマネジメントの知識体 系を PMBOK と呼び、その具体的 な指針をまとめたものを PMBOK ガイドと呼ぶ。一般に PMBOK ガ イ ド の こ と を 指 し て「PMBOK」 と 呼 ぶ こ と が 多 い。 本 稿 で も PMBOK ガ イ ド の こ と を PMBOK と呼ぶことにする。 解説する。これから PMBOK を学 習しようと考えている読者の一助 にしていただきたい。 時間軸に沿って体系化する 「プロセス群」と「プロセス」 プロジェクトをマネジメントす るにあたり、特定の成果を生み出 す一連の活動のことを、PMBOK は、44 のプロセスを定義してい おりでないところがある。そのた る。 さ ら に PMBOK で は、44 の め、知りたい内容が各所に散在し プロセスを 5 つのプロセス群に分 ていて概要をつかみにくいことが 類している。 ある。 発のプロジェクトに特化した知識 に効果的であると認められた知 体系ではない。超高層ビルの建設 識・スキルを体系化したもののこ プロジェクトや金融商品の開発プ とである。 ロジェクトや音楽イベントの企画 Institute, PMI） で あ る。PMI は、 ム開発に適用する上でのヒントを は、プロジェクトの実行順序と は、プロジェクトを成功させるの メ ン ト 協 会（Project Management する。さらに、PMBOK をシステ ではプロセスと呼ぶ。PMBOK で さらに PMBOK は、システム開 は、 米 国 の プ ロ ジ ェ ク ト マ ネ ジ 以下に、PMBOK の概要を解説 ところで PMBOK の解説の順序 その名称が示すとおり PMBOK と PMBOK を 提 唱 し て い る の 6 ガイド 第 3 版』である。 PMBOK を 概 観 す る た め に、5 つのプロセス群から取り上げるこ とにしよう。 監視コントロール・プロセス群 プロジェクトなど、あらゆる業界 のプロジェクトマネジメントに適 用できるように策定されている。 そのためシステム開発者にとっ 立上げ プロセス群 計画 プロセス群 実行 プロセス群 終結 プロセス群 図 2-1 PMBOK のプロセス群 プロジェクトマネジメントの知識 て、PMBOK は解説が一般的すぎ 体系のガイドラインを発行して て、開発業務へどのように適用し 5 つのプロセス群とは、44 のプ いる。ガイドラインの最新版は、 たらよいのか、分かりにくいこと ロセスを以下のように分類したも 2004 年 に 発 行 さ れ た『PMBOK がある。 のである。 □立上げプロセス群 れている。 ジェクトを進める。最後に終結プ るプロセスの集合。 □監視コントロール・プロセス群 て、 プ ロ ジ ェ ク ト を ク ロ ー ズ す □計画プロセス群 との差異を識別するために進捗を プロジェクトを定義し、認可す プロジェクトマネジメント計画 プロジェクトの目標を定め、目 標を達成するための一連の活動を 計画するプロセスの集合。 監視し、差異がある場合に是正処 置を実施するプロセスの集合。監 視と是正処置によって、他のプロ セス群へフィードバックが生じる □実行プロセス群 プロジェクトマネジメント計画 ので、図 2-1 において監視コント を実行するために、人や他の資源 ロール・プロセス群と他のプロセ を統合するプロセスの集合。実行 ス群は、双方向の矢印で結ばれて 途中で生じた変更によって、実行 いる。 プロセス群から計画プロセス群へ □終結プロセス群 フィードバックが生じるので、図 2-1 では実行プロセス群と計画プ ロセス群は、双方向の矢印で結ば プロジェクトの成果物を正式に 受け入れ、プロジェクトを公式に 終了するプロセスの集合。 監視コントロール・プロセス群 セ ス 群 は、 プ スコープ検証、スコープ・コントロール、スケジュール・コントロール、 コスト・コントロール、品質管理、プロジェクト・チームのマネジメント、 実績報告、ステークホルダー・マネジメント、リスクの監視コントロール、 契約管理、プロジェクト作業の監視コントロール、統合変更管理 ロセスを時 間の座標軸に 沿って分類し たものと言い プロジェクト 憲章作成 プロジェクト・ スコープ記述 書暫定版作成 計画 プロセス群 プロジェクト マネジメント 計画書作成 スコープ計画 スコープ定義 WBS作成 アクティビティ 定義 アクティビティ 順序設定 アクティビティ 資源見積り アクティビティ 所要機関見積り スケジュール作成 コスト見積り コストの予算化 品質計画 人的資源計画 コミュニケー ション計画 リスク・ マネジメント計画 リスク識別 定性的リスク分析 定量的リスク分析 リスク対応計画 購入・取得計画 契約計画 実行 プロセス群 プロジェクト 実行の指揮・ マネジメント 品質保証 プロジェクト・ チーム編成 プロジェクト・ チーム育成 情報配布 納入者回答 依頼 納入者選定 終結 プロセス群 プロジェクト 終結 契約終結 る。監視プロセス群の各プロセス は、プロジェクトの立ち上げから 終結までを監視するために実施す る。 前 述 の と お り PMBOK で は、5 つのプロセス群の下に 44 のプロ セスを定義している。図 2-2 に、 44 のプロセスがどのように 5 つ に分類されているかを示す。 PMBOK 初 心 者 が 図 2-2 を は じ 5 つのプロ 立上げ プロセス群 ロジェクトの各プロセスを実施し 換えてもよ い。 す な わ めて見たら、たくさんのプロセス があることに圧倒されるかもしれ ない。しかし以下に述べる学習の コツをつかめば、心配無用である。 まず、読者が参加したことがあ るプロジェクトの、立ち上げから 終結までを思い起こしていただ きたい。規模の大きいプロジェク トや、評価の高いプロジェクトマ ネージャが取り仕切ったプロジェ クトであれば、なお良い。 ち、 立 ち 上 げ 次 に 図 2-2 を 詳 細 に 見 て、 読 プロセス群の 者が参加したプロジェクトをマネ 各プロセスを ジメントするために、どんなプロ 実 施 し て、 プ セスが実施されたか、どんなプロ ロジェクト開 セスを実施すれば良かったのか 始を承認す を 考 え て 欲 し い。 こ う し た 仕 方 る。 次 に 計 画 で 44 のプロセスを眺めてみると、 プロセス群の PMBOK ではプロジェクトをマネ 各プロセスを ジメントするためのプロセスが、 実 施 し て、 計 時間の座標軸に沿って過不足なく 画を詳細に練 整理されていることが理解できる る。 実 行 プ ロ だろう。 セス群の各プ ロセスを実施 図 2-2 PMBOK の し て、 計 画 プロセス とおりにプロ マネジメント対象ごとに体系 化する -9 つの「知識エリア」 旧来から言われていることだ 7 が、成功プロジェクトとは、コス トを予算の範囲内に収めたり、成 果物の品質を顧客が満足するまで 高めたり、納期とおりに成果物を 完成させたりしたプロジェクトの ことである。したがってプロジェ クトマネジメントの対象分野とし て、コストや品質やスケジュール の３つは特に重要である。 さらにこの３つの分野を適切に マネジメントするためには、人的 資源をマネジメントして必要なス キルをもった要員を必要な数だけ 投入したり、リスクをマネジメン トして不測の事態が出現しても致 命的な打撃を受けないようにした りするなど、もっと広範囲の分野 をマネジメントの対象にする必要 がある。 PMBOK では、マネジメントの 対象として 9 つの分野を識別して い る。 そ し て 44 の プ ロ セ ス は、 これら 9 つのマネジメント対象に 再分類されている。PMBOK では、 9 つの対象のことことを知識エリ アと呼んでいる。 つまり PMBOK では、5 つのプ ロセス群によって時間の座標軸に 沿ってプロジェクトマネジメント の知識を体系化するだけでなく、 9 つの知識エリアによってマネジ メント対象の座標軸に沿ってもプ ロジェクトマネジメントの知識を 体系している。 以下に 9 つの知識エリアを列挙 する。 ①プロジェクト統合マネジメント ②プロジェクト・スコープ・マネ ジメント 8 ③プロジェクト・タイム・マネジ プロジェクト作業の 監視コントロール 統合変更管理 メント 監視コントロール・プロセス群 ④プロジェクト・コスト・マネジ メント ⑤プロジェクト品質マネジメント ⑥プロジェクト人的資源マネジメ ント ⑦ プ ロ ジ ェ ク ト・ コ ミ ュ ニ ケ ー ション・マネジメント ⑧プロジェクト・リスク・マネジ メント ⑨プロジェクト調達マネジメント 以下に９つの知識エリアを解説 する。 ①プロジェクト統合マネジ メント プロジェクトを成功させるため には、コストと品質と納期の目標 を期待とおりに達成することが必 要 で あ る。 し か し そ の 三 者 は ト レードオフの関係にある。たとえ ば、たくさん人をかければ納期を 守れるが、予算オーバーになって コスト面で失敗プロジェクトにな る。設計や製造にじっくり日数を かければ顧客満足度の高い成果物 を納品できるが、納期を守れなく なってやはりスケジュール面で失 敗プロジェクトになる。 立上げ プロセス群 計画 プロセス群 実行 プロセス群 終結 プロセス群 プロジェクト 憲章作成 プロジェクト・ スコープ記述書 暫定版作成 プロジェクト マネジメント 計画書作成 プロジェクト 実行の指揮・ マネジメント プロジェクト 終結 図 2-3 プロジェクト統合マネジメ ントに含まれるプロセス ②プロジェクト・スコープ・マ ネジメント プロジェクトで、何をするのか、 何をしないのか、という作業範囲 のことを、プロジェクト・スコー プ（以下、スコープと略す）と呼ぶ。 スコープがあいまいなままスター トしたシステム開発プロジェクト は、やがて顧客との大きなトラブ ルに発展することが多い。また、 プロジェクトの途中でスコープを 変更する必要が生じた場合でも、 変更を承認したり変更を反映した りするための仕組みが機能してい ないと、コスト面やスケジュール 面で泥沼状態になることが多い。 スコープを定義したり検証した りコントロールしたりするプロセ スは、プロジェクト・スコープ・ マネジメントの知識エリアに分類 される。 スコープ検証 スコープ・ コントロール すべてのマネジメント対象分野 をバランスよくマネジメントする 監視コントロール・プロセス群 ことが必要だが、そのためのプロ セスをまとめた知識エリアが、プ ロジェクト統合マネジメントであ る。図 2-3 に、44 のプロセスの中、 どのプロセスがプロジェクト統合 マネジメントの知識エリアに分類 されるのかを示した。 立上げ プロセス群 計画 プロセス群 実行 プロセス群 終結 プロセス群 スコープ計画 スコープ定義 WBS作成 図 2-4 プ ロ ジ ェ ク ト・ ス コ ー プ・ マネジメントに含まれるプロセス ③ プ ロ ジ ェ ク ト・ タ イ ム・ マネジメント を完了させるためのプロセスは、 プロジェクトの成否を評価する ントの知識エリアに分類される 特に重要な条件の一つは、納期を プロジェクト・コスト・マネジメ （図 2-6）。 監視コントロール・プロセス群 るスケジュールを立てて、それに ⑤プロジェクト品質マネジ メント 従ってゆくためのプロセスは、プ 納期・コストに加えて、プロジェ ロジェクト・タイム・マネジメン クトの成否を判断するもう一つの トの知識エリアに分類される。 重要な条件は品質である。ソフト 守 れ た こ と で あ る。 納 期 を 守 れ スケジュール・ コントロール 程で発見することによって達成さ の計画・設計・製造の各工程で作 りこむものである。各工程でどの ように品質を作りこんでゆけるか 立上げ プロセス群 計画 プロセス群 実行 プロセス群 終結 プロセス群 をマネジメントするプロセスは、 プロジェクト品質マネジメントと アクティビティ定義 アクティビティ順序設定 アクティビティ資源見積り アクティビティ所要期間見積り スケジュール作成 立上げ プロセス群 計画 プロセス群 人的資源計画 ウェアの品質は、バグをテスト工 れるものではなく、システム開発 監視コントロール・プロセス群 プロジェクト・チーム のマネジメント いう知識エリアに分類される。 実行 プロセス群 終結 プロセス群 プロジェクト・チーム編成 プロジェクト・チーム育成 図 2-8 プロジェクト人的資源マネ ジメントに含まれるプロセス ⑦プロジェクト・コミュニケー ション・マネジメント プロジェクトと利害関係にある 人や組織のことを、ステークホル ダーと呼ぶ。たとえば顧客やプロ ジェクトメンバーがそうである。 ステークホルダーと良いコミュニ 品質管理 図 2-5 プロジェクト・タイム・マ ネジメントに含まれるプロセス ジェクトの成否に大きな影響を及 監視コントロール・プロセス群 ④ プ ロ ジ ェ ク ト・ コ ス ト・ マネジメント 供するのかをマネジメントするプ 立上げ プロセス群 計画 プロセス群 実行 プロセス群 終結 プロセス群 算とおりに終わったかどうかであ る。予算を立て、予算の消化状況 ぼす。ステークホルダーに、どの ような情報をどのタイミングで提 プロジェクトの成否を評価す る、納期以外の重要な条件は、予 ケ ー シ ョ ン を 図 る こ と は、 プ ロ 品質計画 品質保証 ロセスは、プロジェクト・コミュ ニケーション・マネジメントとい う知識エリアに分類される。 を監視し、予算内にプロジェクト コスト・ コントロール 実績報告 ステークホルダー・ マネジメント 図 2-7 プロジェクト品質マネジメ ントに含まれるプロセス ⑥プロジェクト人的資源マネジ メント 監視コントロール・プロセス群 監視コントロール・プロセス群 限られた予算・日数の中で期待 された品質を達成するためには、 必要なときに必要なスキルを持っ 立上げ プロセス群 計画 プロセス群 実行 プロセス群 終結 プロセス群 コスト見積もり コストの予算化 図 2-6 プ ロ ジ ェ ク ト・ コ ス ト・ マネジメントに含まれるプロセス た要員を、必要な数だけ投入する 必要がある。それを実践するため のプロセスは、プロジェクト人的 資源マネジメントの知識エリアに 分類されている。 立上げ プロセス群 計画 プロセス群 実行 プロセス群 コミュニケーション 計画 終結 プロセス群 情報配布 図 2-9 プ ロ ジ ェ ク ト・ コ ミ ュ ニ ケーション・マネジメントに含まれる プロセス 9 ⑧プロジェクト・リスク・マネ ジメント プロジェクトに、プラスまたは マイナスの影響を与える不確実要 素のことを、リスクと呼ぶ。事前 にリスクを想定・評価して対応す るプロセスは、プロジェクト・リ スク・マネジメントの知識エリア に分類される。 監視コントロール・プロセス群 計画 プロセス群 実行 プロセス群 終結 プロセス群 リスク・マネジメント計画 リスク識別 定性的リスク分析 定量的リスク分析 リスク対応計画 図 2-10 プロジェクト・リスク・ マネジメントに含まれるプロセス ⑨プロジェクト調達マネジ メント プロジェクト・チーム・メンバー だけでは、中間成果物や最終成果 物を作成できない場合、パッケー ジソフトを調達したり、開発工程 監視コントロール・プロセス群 計画 プロセス群 購入・取得計画 契約計画 実行 プロセス群 納入者回答依頼 納入者選定 終結 プロセス群 契約終結 図 2-11 プロジェクト調達マネジ メント 10 る。このような、プロジェクト・ ると、初期の計画フェーズの時点 チームの外から製品やサービスを ではスケジュールを詳細まで詰め 調達するためのプロセスは、プロ きれないことがある。その場合、 ジェクト調達マネジメントの知識 開発フェーズが進むごとに計画を エリアに分類される。 詳細化してゆく。また、特定の開 PMBOK をシステム開発に適用 する 発ベンダーにロックされることを 嫌う顧客の場合、開発フェーズ単 位で入札を行ない、ベンダー選定 を繰り返すことがある。その場合、 に策定されたものなので、システ ベンダーは、開発プロジェクトの ム開発者が業務に適用する場合、 一フェーズの中だけで、プロジェ PMBOK をカスタマイズする必要 クトの立ち上げから終結まで実施 がある。 する。 PMBOK をカスタマイズするポ PMBOK で は、 フ ェ ー ズ の 下 イントの一つは、システム開発の 位 概 念 と し て、 各 フ ェ ー ズ の 中 工程の流れを、PMBOK のプロセ で 5 つのプロセス群のサイクル ス群 / プロセスへどのようにはめ が回るケースも想定している（図 込むかである。これをウォーター 2-12）。大規模プロジェクトや開 フォールの開発モデルを例にして 発フェーズ単位で受注するプロ 考えよう。ご存知のとおりウォー ジェクトの場合、フェーズ単位で ターフォールモデルとは、要件定 も PMBOK を適用できる。 義、設計、製造、テストなどの各 工程が順番に実施される開発モデ ルのことである。 PMBOK では、プロジェクトの 下位概念として、フェーズという 概念がある。要するに、特定の中 間成果物を完成・承認する工程を フェーズと呼び、プロジェクトを 契約管理 立上げ プロセス群 プロジェクトの規模が大きくな PMBOK は、あらゆる業種向け リスクの監視 コントロール 立上げ プロセス群 の一部を外注したりすることにな PMBOK をシステム開発業務に カスタマイズする際の別のポイン トは、PMBOK で紹介されている ツールや技法を取捨選択すること である。 紙面の都合で詳述しなかった が、PMBOK では、個々のプロセ スの詳細説明において、そのプロ フェーズに分割して、プロジェク セスを実施する上で有効と一般的 トの運営や管理を容易にする、と に認められている、ツールや技法 い う 考 え で あ る。PMBOK で は、 を列挙している。すべてのツール これらのフェーズが連なることに や技法を無理に導入しようとする より、プロジェクト・ライフサイ のではなく、プロジェクトの規模 クルが構成されると考える。そこ やシステム開発固有の特性を考慮 で、PMBOK におけるフェーズの して、取捨選択する必要がある。 概念の階層に、ウォーターフォー ただし、まだ使用したことにない ルモデルの開発工程をはめ込むこ ツールや技法でも、効果がありそ とができる（図 2-12）。 うなものは、積極的に導入を検討 するとよい。 いるものが少なくない。たとえば 自動車業界は、新車開発プロジェ た と え ば PMBOK は、 コ ス ト クトの経験を数十年にもわたって 管 理 の 技 法 と し て EVM（Earned 積み上げてきている。建築業界の Value Management） を 紹 介 し て プロジェクトの経験は、人類の建 い る。EVM と は、 金 額 ベ ー ス で 築の歴史と同じだから、数千年の 進捗管理を行なうことによって、 キャリアがある。一方、システム 成果物の進捗の予定・実績を管理 開発業界は、まだ若い業界である す る だ け で な く、 予 算 消 化 の 予 ため、システムの開発プロセスが 定・実績も管理する管理手法であ 未熟であると繰り返し指摘されて る。すでに EVM は、システム開 きた。 発の現場で普及が進んでいる技法 だが、本稿の読者が未導入ならば、 PMBOK は、建築業界など様々 な業界におけるプロジェクトマネ 検討することを勧めたい。 ジメントのノウハウを体系化し PMBOK 導入のメリット たものである。システム開発者が システム開発プロジェクトに PMBOK を学べば、プロジェクト PMBOK を導入することには、メリッ マネジメントの先達たちから教え トがいくつもある。その一つは、他 を受けることになるのである。 業界の成熟したプロジェクト手法を PMBOK を導入する別のメリッ お手本にできることである。 トは、システム開発の受発注者の 双方がプロジェクトマネジメント 他業界の中には、プロジェクト を語る上で、共通の用語集を持て マネジメントの長い歴史を持って ることである。 PMBOK の認知は内外で進んで おり、プロジェクトマネジメント の 知 識 体 系 と し て は、 デ フ ァ ク トスタンダードの地位を占めてい る。今後もさらに多くの企業・団 体が、PMBOK に準拠したプロジェ クトマネジメント標準を採用する ことが予想される。 システム開発の受発注者の双方 が PMBOK に準拠した開発標準を 有している場合、共通の用語とし て PMBOK の用語を使用できるの で、プロジェクトマネジメント関 係のコミュニケーションをスムー スに行なえる。 【参考文献】 ・広兼 修著、『プロジェクトマネジ メント標準 PMBOK 入門』、オー ム社、平成 17 年 監視・コントロール 立上げ 計画 実行 終結 フェーズの 概念の階層 ウォーターフォール モデルの開発工程 プロジェクト・ライフサイクル 立上げ フェーズ 計画 フェーズ 要件定義 フェーズ 設計 フェーズ 製造 フェーズ テスト フェーズ 終結 フェーズ フェーズ単位 で５つのプロ セス群のサイ クルを回す 図 2-12 PMBOK のフェーズの概念とウォーターフォールモデルの開発工程 11
© Copyright 2024 Paperzz
