Web教材一覧法規・基準

プロジェクトマネジメントとPMBOK

学習のポイント

情報システムはプロジェクトチームで開発します。そのとき、プロジェクトの運営が不適切ですと、チームメンバーの活動がバラバラになって無駄が生じますので、納期に遅れたり、コストが増大したり、期待した機能が不十分になったりします。
 プロジェクトを経験と勘で運営する時代ではありません。体系的な知識が必要になります。それをPMBOK(The guide to the Project Management Body of Knowledge:プロジェクトマネジメントの基礎知識体系)を中心にして学習します。しかし、必要となる知識は膨大ですので、ここでは知識体系の概要を理解するだけにします。

キーワード

プロジェクト、プロジェクトマネジメント、PMBOK、知識エリア、プロセス、P2M、ISO 10006


プロジェクトの基礎知識

プロジェクトの定義

プロジェクトは、有期性と独自性を持つ業務であり、日常的に繰り返し行われる業務と区別されます。

有期性
開始と完了が明確になっていることがプロジェクトの特徴です。継続的な業務はプロジェクトとはいいません。
独自性
開始と完了があることは、そのことは1回しか行われないということであり、その遂行の仕方や得られる成果物は独自のものになります。定例的に繰り返し行われる業務はプロジェクトではありません。

たとえば、情報システムの開発やダムの建設などは、それらの検討を開始する時期と、情報システムやダムが完了する時機が明確ですし、出来上がったものも他とは異なるものですし、似たような業務であっても携わる人も違うし環境も違うので独自性があります。それでこれらはプロジェクトであるといえます。
 それに対して、営業活動での顧客訪問や取引情報の入力などは、新規の顧客や新製品の取扱いなど新規性はあっても、日常的に繰返し継続して行う性格のものですから、プロジェクトとはいいません。

プロジェクトチームとプロジェクトマネジャー

特定のプロジェクトを実行するには、関係部門から適任者を選抜してチームを編成します(専任者だけでなく兼任者もいます)。そのチームをプロジェクトチームといい、そのリーダーをプロジェクトマネジャーといいます。プロジェクトチームはプロジェクトが完了した時点で解散する臨時的な組織です。

プロジェクトマネジャーは、現場実働部隊の責任者の立場なのが通常です。
 情報システム開発プロジェクトを例にすれば、ユーザ企業ならば、所期の目的を実現するには、業務改革や顧客折衝など情報システム以外の活動が需要であり、それを含んだ全体の責任は該当部門の部長クラス(システムオーナーという)になり、プロジェクトマネジャーの責任は情報システムに限定したものになります。
 ベンダ企業では、ユーザ企業への責任者は経営者や上位管理者であり、プロジェクトマネジャーの責任は、与えられた権限内に限定されます。

プロジェクトマネジメント

マネジメントは管理と訳されますが、コントロールの意味での管理よりも広い概念です。
 プロジェクト管理は、以前から行われていましたし、それを支援する多様な技法も普及していました。しかし、これまでのプロジェクト管理は、とかくQCTあるいはTQCを管理することに限定されていました。
  Q(Quality、品質):期待された機能を実現する成果物
  C(Cost、コスト):予算。人件費なども含む
  T(Time、納期)
 現在でも、プロジェクトマネージャの任務は、与えられた予算や人(C)と期限(T)の制約のもとで、期待される機能(Q)の成果物-情報システムなど-を実現させることにあります。

最近のプロジェクトマネジメントでは、QCTを実現するためには、組織、コミュニケーション、リスク、調達などの知識(知識エリア)が重要であり、それを活用して、全体最適の観点からバランスよくマネジメントしようという考えかたへと発展してきました。
 現場実働部隊の運営では、チームメンバ全員がプロジェクトの目的・目標を共有化して、高い動機づけをもつことが重要です。また、プロジェクト期間中には、予期しないトラブルが発生します。それでリスクマネジメントが重要になります。これらもプロジェクトマネジャーの主要な任務だといえます。

プロジェクトマネジメントシステム

そして、プロジェクトマネジメントを全社的な観点から、PDCA(計画-実行-チェック-是正)サイクルを適切に継続的に運営することにより、プロジェクトマネジメントの成熟度を向上させることが重要だと認識されるようになりました。それをプロジェクトマネジメントシステムといいます。
 後述のPMBOKは、プロジェクトマネジメントシステムを導入し運営するためのガイドブックだといえます。

PMO(Project Management Office、プロジェクト支援部門)

このような観点から、PMOを設置する企業が増加してきました。PMOとは、組織におけるプロジェクトマネジメントを統括・管理することを専門として設置された部門のことです。
 個々のプロジェクトのマネジメント業務の支援、プロジェクトマネジャーのサポート、プロジェクト間での要員の調整や知識の共有化などを行います。
 PMOは専門家集団ですが、求められるのは特定のプロジェクトに特化した能力ではなく、プロジェクトマネジメントの知識・経験です。それで、臨時的な組織ではなく、恒久的な部門になります。

WBS(Work Breakdown Structure)

プロジェクトは多数の作業から成り立っています。プロジェクトチームが実行すべき作業を、上位の階層から下位の階層へ段階的に分解し、コスト見積りとスケジュール作成を行えるレベルまでに細分化します。そして、その作業での必要な情報と成果物、それに必要な技術や作業量などを明確にします。
 このようにして、複雑な作業を単純な作業にブレークダウンした体系図、あるいは、それにより管理する方法をWBSといいます。適切なWBSを行うことがプロジェクト運営の基礎になります。


PMBOK

PMBOK(A Guide to the Project Management Body of Knowledge)は、PMI(Project Management Institute)が、1996年に策定したもので、プロジェクトマネジメントに関して、一般的に優れた業務慣行として認められている知識を体系化したものです。その後逐次改訂されており、事実上の標準として世界中で広く受け入れられています。
 日本では、PMI東京支部がPMBOKの普及やPMP(プロジェクトマネジャー)資格認定などを行っています。

PMBOKの体系

PMBOKの体系は、プロジェクトマネジメントを適切に行うための知識を体系化した知識エリアと、プロジェクトの開始から完了までの各段階をPDCAに基づいたプロセスの組合せになっています。

知識エリアの体系
(拡大図) (プロセス構成詳細図)

(お詫び)2015年現在のPMBOKは第5版ですが、これらの図表は第4版のままになっています。

知識エリア

PMBOKは「プロジェクトマネジメント」に必要な知識の「体系」を示したものです。必要となる知識を網羅して体系化することが目的であり、知識そのもの(技法など)の解説を目的としていません。「ツールと技法」では、話題になっているEVM(アーンドバリューマネジメント)などについては、やや詳細な解説がありますが、全般的には、単に名称を列挙するか数行の定義を記述しているだけです。
 また、知識というと、EVMやPERTなどの技法の知識だと思われがちですが、それは、プロジェクトマネジメントを成功させるための一部分にすぎません。もっと広い観点で「知識」をとらえることが必要です。

知識エリアとして、次の10エリアをあげています。このうち、タイムマネジメント、コストマネジメント、品質マネジメントの3分野がプロジェクトの結果に直接関係する分野で、古典的なQCTの分野です。
 人的資源マネジメント 、コミュニケーションマネジメント、リスクマネジメント、調達マネジメント、ステークホルダーマネジメントは、そのQCTを実現するために、プロジェクトを円滑に運営するための分野です。そして、統合マネジメントとスコープマネジメントは、それらの分野を統合したものだといえます。

統合マネジメント
プロジェクトにおける多種多様な要素を整合性のある実行をするためのもので、以降の各エリアを統合する位置づけになっています。
スコープマネジメント
スコープとは「範囲」のことです。スコープマネジメントとは「プロジェクトの目標である最終成果物を作成するために必要な作業が過不足なく確実に遂行されることを保証する」ために、WBSを設定(スコープ定義)して、PDCAサイクルにより常に最新の状態に保つことが必要ですし、関連法規や顧客要求事項の変更があるとスコープの変更が必要になります(変更管理)。
タイムマネジメント
納期までにプロジェクトを完成させるための管理です。作業の定義、順序、所要時間見積り、スケジュールの作成と進捗管理をするための分野です。個々のタスクの成果物が予定された期日(マイルストーン)までに達成したことを確認し、遅れが発生したときには対処しなければなりません。
スケジュールが遅延した場合の開発スコープを保ったまま、スケジュールを短縮するための技法として、次の二つが示されています。
  • クラッシング(Crashing)
    クリティカルパス上にあるタスクに対して人員や費用を追加投入することにより、スケジュールを短縮させる方法です。
  • ファスト・トラッキング(Fast Tracking)
    先行タスクが完了する前に後続タスクを進めることで、スケジュールを短縮させる方法です。製造業における< href="../kj3-seizogyo-yougo/index.html#ce" target="_blank">コンカレントエンジニアリングに似た概念です。
コストマネジメント
計画された予算内でプロジェクトを完成させるための管理です。資源計画、コスト積算、予算作成、コスト管理があります。
当初予算の決定には、システム化計画による総開発予算と,各作業を積み上げた見積りを総合的に調整する必要があります。類似プロジェクトの実績も参考にします。
そのとき開発に関係する利用部門の人件費やシステム開発以外の業務改革などにかかる「見えない費用」も算入する必要があります。そして、実績の差異を監視し,必要に応じて計画変更を行う必要があります。特に進捗の遅れはコストの増大を招きます。
品質マネジメント
成果物が期待された機能・性能を過不足なく持つことを実現させるための管理です。
「品質」は「コスト」や「納期」と比較して不明確なことが多く、品質を維持するために必要な管理手段やテストの期間・費用などへの制約が厳しくなりがちですが、手抜きをすると、本番移行後に大きなトラブルが発生するリスクがあります。逆に、品質にこだわりすぎて、過剰なコストや時間をかけるのも不適切です。それには、関係者によるレビューの実施が必要です。
情報システム開発で問題なのは、当初の要件が必ずしも明確でなく変更が多いことです。これは納期やコストに大きな影響を与えます。

納期、コスト、品質は以前からプロジェクトで重視されていた事項ですが、モダンプロジェクトマネジメントでは、それらを保証するために以降の事項が重要だとしています。

人的資源マネジメント
プロジェクトはチーム(組織)で遂行します。その体制を作り、役割分担、責任と権限、要員の確保・育成などを行うためのをする分野です。
コミュニケーションマネジメント
チームがバラバラな行動をしたのでは困ります。また、ステークホルダーにタイムリーに報告する必要があります。どのような情報をいつどのように伝達するかの計画を作り、情報を生成、収集、配布、保管、廃棄するプロセスををする分野です。
リスクマネジメント
開発要員が病気になったとか、思わぬ障害が発生したなど、プロジェクトではリスク対策が必要です。リスクの特定、定量化、対応策の策定などのリスク管理をする分野です。
調達マネジメント
ハードウェアやソフトウェア、情報システムの外部委託など、多くの調達があります。調達計画、契約、調達などの管理をする分野です。
ステークホルダーマネジメント
ステークホルダーとは利害関係者です。社内利用者、顧客、株主、社会、行政官庁など広い分野にわたります。ステークホルダーと良好な関係を築くことが、プロジェクトを成功させる重要な要因です。場合によってはプロジェクトに反対のステークホルダーもいますが、それを協力者に変えることが必要です。コミュニケーションマネジメントから発展した分野です。第5版(2012年)から追加されました。

リスクの分類

リスク対処の分類では、「回避」や「損失制御」などのリスク・コントロール、「保険」「受容」などのリスク・ファイナンスに区分するのが通常です(→参照:「リスク・コントロールとリスク・ファイナンス」)が、PMBOKでは、マイナス(脅威)のリスクだけでなくプラス(好機)のリスクも加えて次のように分類し、それぞれの対応戦略を示しています。

     ┌────┬────┐
     │ 脅威 │ 好機 │
     ┝━━━━┿━━━━┥
     │ 回避 │ 活用 │
     ├────┼────┤
     │ 転嫁 │ 共有 │
     ├────┼────┤
     │ 軽減 │ 強化 │
     ├────┼────┤
     │ 受容 │ 受容 │脅威/好機の両方にある
     └────┴────┘

脅威への戦略
  • 回避:脅威を完全に取り除くために、プロジェクトマネジメント計画を変更すること。プロジェクトの中止、納期延長、範囲の縮小などです。
  • 転嫁:脅威による影響を、対応責任も合わせて、第三者に移転すること。保険や保証契約などです。
  • 軽減:リスクの大きさ(発生確率×影響度)を受容範囲にまで低減させること。能力の高い発注先の選定、テストの重視などです。
  • 受容:リスクを受け入れることを容認すること。災難だと割り切ること、QCTにリスク対応の余裕をもたせることなどです。
好機への戦略
  • 活用:好機が確実に到来するようにすること。能力の高いチーム人選などによる期待以上の品質。コスト低下、納期短縮などです。
  • 共有:好機をとらえることのできる組織に、好機を実行する権限を割り当てること。ジョイントベンチャや社内ベンチャ(プロジェクトが成功したら、その経営を任せる)などです。
  • 強化:好機の発生確率やプラスの影響を増加させること。チャンス時での資源の追加投入、シナジー効果を狙った範囲拡大などです。
  • 受容:積極的な利益追求はしないが、好機実現時には逸することなく利益享受をすること。ハードウェアの価格低下、新技術の出現に即応することなどです。

プロセス群

それぞれの知識エリアで必要となる「結果をもたらす連続したアクション」をプロセスといいます。
 各プロセスを、プロジェクトの立ち上げから終結にいたる時間軸でグループ化したものをプロセス群といいます。プロジェクトの進行にあわせて、必要となるプロセスを示すことにより、どの局面で、プロセスを実施すればよいかがわかります。

各プロセスでは、そのプロセスを行うために、どのような情報を用いて(インプット)、どのような結果を得るのか(アウトプット)、インプットからアウトプットを得るのに役に立つツールや技法にはどのようなものがあるか(ツールと技法)を示しています。

プロセスは、次の5つのプロセス群にまとめられます。立ち上げのプロセスと終結のプロセスは、プロジェクトが有期性であることから重要です。計画・遂行・コントロールのプロセスは、PDCAサイクルになっています。

立ち上げプロセス群
プロジェクト立上げ時にプロジェクト憲章を定めます。プロジェクトに関する基本方針を記述した正式文書であり、これによりプロジェクトが正式に発足します。
・プロジェクトの目的を明確にし,正式に認可する。
・プロジェクトマネジャーの任命(体制はプロジェクトマネジャーの権限)
・プロジェクトマネジャーに組織の資源を使用する権限を与える。
などが示されています。
計画のプロセス群
プロジェクトを行うための計画を立案して、それを維持します。
実行のプロセス群
実際にプロジェクトの業務を行い成果物を作成します。
監視コントロールプロセス群
プロジェクトの目標を達成するのを保証するために、プロジェクトの進捗をモニタリングして、必要に応じて対策を講じます。
終結プロセス群
プロジェクトまたはタスクの成果物の確認や報告などの完了手続きを行います。

プロジェクト憲章

PMBOKでは、プロジェクト憲章の作成を重視しています。プロジェクト立上げプロセスにおいて、経営者が(あるいは先立って指名されたプロジェクトマネージャが原案を作成し、経営者の承認を得て)プロジェクト憲章を策定し、関係者に周知するものです。次のような事項を明確にしたものです。

  ・該当プロジェクトの背景と目的
  ・プロジェクトへの期待成果
  ・プロジェクトの期間、予算
  ・プロジェクトのメンバーと組織構成、権限
  ・プロジェクト実施におけるルール

プロジェクト憲章は、プロジェクト関係者が守るべき基本原則です。期間や予算を具体的に示すのは良いことですが、プロジェクトにはリスクがあります。リスクへの柔軟な対応ができることも考慮する必要があります。

プロジェクト全体に関して、プロジェクト憲章をより具体的に記述したのがプロジェクト・スコープ記述書暫定版です。プロジェクト憲章が法律だとすれば、これは政令や通達に相当します。
 プロジェクト立ち上げプロセス群の段階では,まだ正式版が作れるほど検討が進んでいないので、「暫定版」を作成して、プロジェクト憲章とセットにして、プロジェクトを立ち上げます。そして、計画プロセス群の活動中に「正式版」に確定します。


その他のプロジェクトマネジメント基準

ISO 10006(プロジェクトにおける品質マネジメントの指針)

ISO 10006は、PMBOKをベースにした国際規格です。1997年に策定され、2003年に改訂されまっした。JIS Q 10006 にもなっています。
 プロジェクト管理における品質をプロジェクト・プロセスの品質という観点でとらえています。

ISO 21500(プロジェクトマネジメントの手引き)

PMBOKの第4版をベースとした国際規格です。2012年に策定されました。ここで知識エリアに「ステークホルダーマネジメント」が加えられ、PMBOKも同年にそれに合わせた第5版になりました。両者の間には若干の相違があるものの、全体的には似た内容になっています。ISO 10006との関係は、私は知りません。これに置き換わるのかもしれません。

P2M(プログラム&プロジェクトマネジメント)

プロジェクトと似た用語にプログラムがあります。プログラムとは複数のプロジェクトが互いに関連して並行して行われる場合、その全体を指す概念です(それに対して、ある部門が独立したプロジェクトを複数抱えていることを、マルチプロジェクトといいます)。
 経済産業省の指導のもと、エンジニアリング振興協会は、日本版プロジェクトマネジメントとして、P2M(Project & Program Management)の知識体系、「プログラム&プロジェクト標準ガイドブック」を策定しました。PMBOKをベースにしていますが、全体使命としてのプログラムを意識していること、拡張性を重視していることなどの特徴があります。これにも資格制度があり、プロジェクトマネジメント資格認定センターが担当しています。

さらに上位の概念にポートフォリオマネジメントがあります。これは、複数のプロジェクトやプログラムの全体をまとめたものをポートフォリオといい、経営資源の配分や資産の運用を全社的な観点からマネジメントする技法です。


理解度チェック: 正誤問題記述問題
過去問題