Web教材一覧法規・基準

プロジェクトマネジメント
PMBOK(第6版)と JIS Q 21500:2018

留意事項

PMBOKは、プロジェクトマネジメントを進めるために必要な知識を体系化したものです。ISO 21500シリーズは、PMBOKを国際規格化したものであり、それをJIS化したのがJIS Q 21500です。すなわち、PMBOKとJIS Q 21500は、ほぼ同じ内容になっています。JIS Q 21500は、ルールや技法の説明は含まれていません。

           ISO      JIS    PMBOK
最新版(2020年現在)ISO 21502:2020   策定中     第7版(2021)
本章での参照版   ISO 21500:2012 JIS Q 21500:2018  第6版(2017)

最新版は旧版と比較して大幅に改訂されました。ここでは、過去の試験問題に対応するため、あえて旧版に準拠しています。

キーワード

プロジェクト、有期性、独自性、プロジェクトマネジメント、プロジェクトマネジメントシステム、プロジェクトガバナンス、プロジェクトスポンサ、プロジェクト運営委員会、プロジェクトマネジャー、プロジェクトチーム、PMO(プロジェクト管理部門)、プロジェクトマネジメントチーム、PMBOK、JIS Q 21500、知識エリア(対象群)、統合マネジメント、スコープマネジメント、スケジュールマネジメント(タイムマネジメント)、コストマネジメント、品質マネジメント、資源マネジメント(人的資源マネジメント)、調達マネジメント、ステークホルダーマネジメント、プロセス群、立ち上げプロセス群、計画のプロセス群、実行のプロセス群、監視コントロールプロセス群(管理のプロセス群)、終結プロセス群、プロセス、プロジェクト憲章、リスク、非事象リスク、WBS、WBS辞書、ワークパッケージ、プログラムマネジメント、


プロジェクトの基礎知識

プロジェクトの定義

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

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

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

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

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

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

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

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

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


プロジェクト体制

プロジェクトガバナンス

プロジェクト活動を経営の観点から指揮し,管理することです。プロジェクトスポンサまたはプロジェクト運営委員会が担当します。

プロジェクトスポンサ

経営の観点から該当プロジェクトを運営すること、すなわちプロジェクトガバナンスを担当する人です。プロジェクトの影響度により、経営者、部門担当役員、対象業務部長などが担当し、プロジェクトの最高責任者です。
 主な任務は次の通りです。

プロジェクト運営委員会

プロジェクトが複数の組織に影響を与える場合、それらの組織の代表者をメンバとし、プロジェクトスポンサを委員長とする委員会を設置することがあります。全体の戦略的方向性に関する指針を提示し、それを組織の大部分に広めるのを支援する任務をもちます。

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

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

プロジェクトマネジャーは、プロジェクトの要求事項を満たすために、知識、スキル、ツールと技法をプロジェクトへ適用する任務をもち、チームメンバを指揮します。
 情報システム開発プロジェクトを例にすれば、ユーザ企業側でのプロジェクトチームとベンダ企業側でのプロジェクトチームが存在します。通常は請負契約ですので、それらは別個のチームになり、互いのプロジェクトリーダを介して協力体制をとります。
 ユーザ企業ならば、所期の目的を実現するには、業務改革や顧客折衝など情報システム以外の活動がであり、それを含んだ全体の責任は当該部門の部長クラス(システムオーナーという)が行い、プロジェクトマネジャーは、当該部門の部長あるいは情報システム部長から任命された者になります。
 ベンダ企業では、一般にプロジェクトマネジャーという職種があり、対象システムやユーザ企業の業種への知識スキルをもつ者が任命されます。

PMO(Project Management Office、プロジェクト管理部門)

PMOは、プロジェクト組織ではなく継続性を持つ部門です。「管轄する複数のプロジェクトを一元的にマネジメントし、調整を行うことに種々の責任を有する組織の一部門あるいはそのグループ」であり、プロジェクトの関連するガバナンス・プロセスを標準化し、資源、方法論、ツール及び技法の共有を促進するのが任務で、プロジェクトマネジメントへの支援から、プロジェクトを直接マネジメントするまで広範囲にわたります。
 ・方法論やベストプラクティス、標準の特定と開発
 ・プロジェクトの監査
 ・文書の作成とマネジメント
 ・プロジェクト間のコミュニケーションと調整

プロジェクトマネジャーとPMOの違い

プロジェクトマネジメントチーム

大規模、複雑なプロジェクトでは、プロジェクト内部にPMOのような組織を設置することもあります。それをプロジェクトマネジメントチームといいます。プロジェクトマネージャの任務は複雑で、1人のマネージャでは達成が困難な場合があります。
 新規技術の調査、特定のステークホルダとの折衝、文書の整備など、プロジェクトマネージャの周辺業務を支援して当該プロジェクトを成功させることが任務です。


プロジェクトマネジメントの体系

PMBOKガイド

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

2017年のPMBOKガイド(第6版)では、アジャイル開発(PMBOKガイドでは「適応型の開発ライフサイクル」と分類)への対応が重視されました。10の知識エリアごとにアジャイル開発を適用する場合の進め方や考慮点を盛り込み、付録として「アジャイル実務ガイド」がセットされました。

JIS Q 21500

正式名称は「JIS Q 21500:2018 プロジェクトマネジメントの手引」、原規格は「ISO 21500:2012 Guidance on project management」です。すなわちガイドブックであり、PMBOK「ガイド」と同じ意味合いです。PMBOKを規格にしたものですが、「知識」を目的としていないので、実践を支援する方法論やツールに関する記述はありません。

  

知識エリア(対象群)、プロセス群、プロセス

PMBOKの体系は、プロジェクトマネジメントを適切に行うための知識を体系化した知識エリアと、プロジェクトの開始から完了までの各段階をPDCAに基づいたプロセス群の組合せになっています。その組合せにプロセスがあり、何を行うべきか、その方法を示しています。
 JIS Q 21500 では「知識エリア」を「対象群」としています。
参照:プロセス一覧表

知識エリア

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

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

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

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

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

リスクマネジメント

JIS Q 21500でもリスク分析の規定がありますが、PMBOKではより具体的な手順が示されています。

リスクの定義

リスクマネジメントの手順


プロセス

プロセスのタイプ

プロジェクトを動かしていくためのプロセスには以下の3つがあり、それぞれが相互に関与しています。

プロセス群

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

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

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

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

プロセスの例:統合マネジメント

PMBOKでは、各知識エリアのマネジメントを遂行するのに、これらのプロセス群で何を行うか、成果物は何かの観点から(下位の)プロセスを示しています。

統合マネジメントを例に知識エリアとプロセス群の関係を示します。

PMBOKでは、各プロセスの実施に関する「ツールと技法」を列挙し、その簡単な説明と適用での留意事項を示しています。これがPMBOKの大半を占めていますが、中途半端になるので、ここでは割愛しました。


重要用語

プロジェクト憲章(プロジェクトチャーター)

プロジェクト立上げプロセスにおいて、経営者が(あるいは先立って指名されたプロジェクトマネージャが原案を作成し、経営者の承認を得て)プロジェクト憲章を策定し、関係者に周知するものです。ステークホルダ(利害関係者)に対してプロジェクトの存在を正式に認可してもらうことを目的としたものでもあります。

プロジェクトに関する基本事項を文書化したもので、次のような項目からなっています。
  ・プロジェクトの目的または妥当性
  ・プロジェクトの目標及び成功基準
  ・要求事項概要
  ・プロジェクト記述概要(プロジェクトの方針)
  ・リスクの概略
  ・要約マイルストーン、スケジュール
  ・要約予算(概要見積り)
  ・プロジェクト承認要件(実施承認の判断基準や担当者)
  ・プロジェクトマネージャ(責任と権限)
  ・プロジェクト・スポンサー(プロジェクトの最終責任者)

プロジェクトの立上げプロセスにおいて作成され、承認されたらプロジェクトが発足し、プロジェクトマネジャーが任命されます。

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

リスクの分類

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

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

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

非事象リスク

PMBOKガイド第6版では、リスクの分類として、次の体系も示しています。

リスク
 ├─事象リスク(事象に基づくリスク)
 │      設計完了後の顧客からの仕様変更要求や開発関係企業の倒産など
 └─非事象リスク(具体的な事象以外でのリスク)
    ├─変動リスク(計画時の各種パラメタ予測値からの乖離)
    │   生産性が予想外に低い、テストでのエラー件数が予想外に多いなど
    └─曖昧さリスク(計画時に十分に把握できなかったリスク)
        要求事項の不完全理解、法的規制、新技術の不確実性、プロジェクトの複雑性など

プロジェクトの細分化

WBS(Work Breakdown Structure)

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

ワークパッケージ

WBSは、上位ー下位へと階層的に表示されますが、その最下位レベルの要素のことです。ワークパッケージが進捗コントロールの最小基本単位になります。プロジェクトの規模と目的により粒度はさまざまです。
 ワークパッケージは、必要に応じていくつかのアクティビティ(具体的な作業)に分解され、責任担当者や実施組織などのリソースが割り当てられます。

WBS辞書

個々のWBS要素に関する作業の内容と意味を明確に定義したものです。
  ・WBSの位置:上位WBS要素、先行・後続WBS要素
  ・関係者:作業担当者、実施責任者、管理責任者、承認者
  ・作業:開始・完了予定、実施に必要な成果物・リソース、完了条件、成果物(仕様)
  ・予想リスク、コスト等
などの内容を常に最新状態に保持したものです。多くのプロセスにおいて参照、更新されます。

OBS(Organization Breakdown Structure)

WBSがプロジェクトの作業と成果物により階層化したのに対して、OBSはプロジェクト組織を階層的に図式化したものです。ワークパッケージに組織/人員を割り振り、責任や指揮の系統に従って配置するとOBSになります。
 ワークパッケージとOBSをマトリクスの表にすることにより、作業と責任者の対応が明確になります。


その他の関連基準

プログラムマネジメント

プロジェクトと似た用語にプログラムがあります。プログラムとは複数のプロジェクトが互いに関連して並行して行われる場合、その全体を指す概念です。
 プログラムマネジメントとは、「プログラムの戦略目標と成果価値を達成するために、調和を保ちつつ一元的にプログラムをマネジメントすること」と定義されています。戦略目標に整合させるよう、関連する複数プロジェクトに影響する制約条件およびコンフリクトを解消することだといえます。

プログラムは目的達成を対象にし、プロジェクトはそのための目標(手段)の実現を対象にします。
 目的とは、実現したいことです。システム開発でいえば、新サービスを提供する、生産性を向上させるなどのことです。
 その目的を達成するには、多様な目標があります。システム開発だけでなく、組織体制や業務の変更、顧客や関係先との調整が必要ですし、直接関係する基幹系システムだけでなく、その効果を高めるための付帯的なシステムも必要でしょう。

(これに対して、ある部門が独立したプロジェクトを複数抱えていることを、マルチプロジェクトといいます)。

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

 経済産業省の指導のもと、エンジニアリング振興協会は、日本版プロジェクトマネジメントとして、P2M(Project & Program Management)の知識体系、「プログラム&プロジェクト標準ガイドブック」を策定しました。PMBOKをベースにしていますが、全体使命としてのプログラムを意識していること、拡張性を重視していることなどの特徴があります。これにも資格制度があり、プロジェクトマネジメント資格認定センターが担当しています。

プロジェクトポートフォリオ

ポートフォリオとは、「戦略的なビジネス目標を達成するための仕事を効果的にマネジメントすることを目的にグループとしてまとめられた、プロジェクト、プログラム、および関連業務の集合である」と定義されています。
 ポートフォリオマネジメントとは「1つ以上のポートフォリオを一元化してマネジメントすること」です。戦略目標を達成するために、プログラム及びプロジェクトの最適な組み合わせを選択して、構成要素の優先順位を決定し、必要な資源を提供することです。

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

プロジェクトマネジメントそのものの手引書ではなく、プロジェクトマネジメントのプロセスにおける品質に関する規格でしたが、2019年にJIS Q 21500 の策定により廃止になりました。


JIS Q 21500:2018、PMBOK(第6版)プロセス一覧

-対象群-プロセス群(JIS Q 21500:2018)PMBOK(6版)
(知識エリア) - 立ち上げ - --- 計画 --- --- 実行 --- 管理(監視コントロール) -- 終結 -- ~~ ツールと技法 ~~
統合 4.3.2 プロジェクト憲章の作成
←プロジェクト作業規定書、契約、ビジネスケース又は以前のフェーズの文書
→プロジェクト憲章
4.3.3 プロジェクト全体計画の作成
←プロジェクト憲章、補足計画、以前のプロジェクトから得た教訓、ビジネスケース、承認された変更
→プロジェクト計画、プロジェクトマネジメント計画
4.3.4 プロジェクト作業の指揮
←プロジェクト計画、承認された変更
→進捗データ、懸案事項ログ、得た教訓
4.3.5 プロジェクト作業の管理
←プロジェクト計画、進捗データ、品質管理測定値、リスク登録簿、懸案事項ログ
→変更要求、進捗報告書、プロジェクト完了報告書


4.3.6 変更の管理
←プロジェクト計画、変更要求
→承認された変更、変更登録簿
4.3.7 プロジェクトフェーズ又はプロジェクトの終結
←進捗報告書、契約文書、プロジェクト完了報告
→完了した調達、プロジェクト又はフェーズの終結報告書、解放された資源


4.3.8 得た教訓の収集
←プロジェクト計画、進捗報告書、承認された変更、得た教訓、懸案事項ログ、リスク登録簿
→得た教訓文書
ベースライン
CCB(変更管理委員会)
ステークホルダ 4.3.9 ステークホルダの特定
←プロジェクト憲章、プロジェクトの組織図
→ステークホルダ登録簿
4.3.10 ステークホルダのマネジメント
←ステークホルダ登録簿、プロジェクト計画
→変更要求
スコープ 4.3.11 スコープの定義
←プロジェクト憲章、承認された変更
→スコープ規定書、要求事項


4.3.12 WBSの作成
←プロジェクト計画、要求事項、承認された変更
→WBS、WBS辞書


4.3.13 活動の定義
←WBS、WBS辞書、プロジェクト計画、承認された変更
→活動リスト
4.3.14 スコープの管理
←進捗データ、スコープ規定書、WBS、活動リスト
→変更要求
ワークパッケージ
プロジェクトスコープのクリープ
資源 4.3.15 プロジェクトチームの編成
←資源要求事項、プロジェクトの組織図、資源の利用可能性、プロジェクト計画、役割規定書
→スタッフ配置、スタッフ契約
4.3.16 資源の見積り
←活動リスト、プロジェクト計画、承認された変更
→資源要求事項、資源計画


4.3.17 プロジェクト組織の定義
←プロジェクト計画、WBS、資源要求事項、ステークホルダ登録簿、承認された変更
→役割規定書、プロジェクトの組織図
4.3.18 プロジェクトチームの開発
←スタッフ配置、資源の利用可能性、資源計画、役割規定書
→チームのパフォーマンス、チーム評価
4.3.19 資源の管理
←プロジェクト計画、スタッフ配置、資源の利用可能性、進捗データ、資源要求事項
→変更要求、是正処置


4.3.20 プロジェクトチームのマネジメント
←プロジェクト計画、プロジェクトの組織図、役割規定書、進捗データ
→スタッフのパフォーマンス、スタッフ評価、変更要求、是正処置
RAM(責任分担マトリックス)
OBS(組織ブレークダウンストラクチャ)
時間
(スケジュール)
4.3.21 活動の順序付け
←活動リスト、承認された変更
→活動順序


4.3.22 活動期間の見積り
←活動リスト、資源要求事項、履歴データ、工業標準、承認された変更
→活動所用期間見積り


4.3.23 スケジュールの作成
←活動順序、活動所用期間見積り、スケジュールの制約、リスク登録簿、承認された変更
→スケジュール
4.3.24 スケジュールの管理
←スケジュール、進捗データ、プロジェクト計画
→変更要求、是正処置
類推見積り、パラメトリック見積り、三点見積り、ボトムアップ見積り
スケジュールネットワーク分析、アローダイアグラム
PERT、CPM(クリティカルパス法)
PDM(プレシデンスダイアグラム法)、ラグ、リード
ガントチャート、マイルストーン
クラッシング、ファストトラッキング
EVM
大日程計画表、マスタスケジュール
中日程計画表、工程別作業計画
小日程計画表、週間作業計画
進捗報告
コスト 4.3.25 コストの見積り
←WBS、活動リスト、プロジェクト計画、承認された変更
→コストの見積り


4.3.26 予算の作成
←WBS、コストの見積り、スケジュール、プロジェクト計画、承認された変更
→予算
4.3.27 コストの管理
←進捗データ、プロジェクト計画、予算
→実コスト、予想コスト、変更要求、是正処置
類推見積り、パラメトリック見積り、三点見積り
ボトムアップ見積り
LOC法
COCOMO、COCOMOⅡ
ファンクションポイント法
EVM
コストベースライン
リスク 4.3.28 リスクの特定
←プロジェクト計画
→リスク登録簿


4.3.29 リスクの評価
←リスク登録簿、プロジェクト計画
→優先順位付けされたリスク
4.3.30 リスクへの対応
←リスク登録簿、プロジェクト計画
→リスク応答、変更要求
4.3.31 リスクの管理
←リスク登録簿、進捗データ、プロジェクト計画、リスク応答
→変更要求、是正処置
リスクの定性的分析技法
リスクの定量的分析技法
品質 4.3.32 品質の計画
←プロジェクト計画、品質要求事項、品質方針、承認された変更
→品質計画
4.3.33 品質保証の遂行
←品質計画
→変更要求
4.3.34 品質管理の遂行
←進捗データ、成果物、品質計画
→品質管理測定値、検証した成果物、検査報告書、変更要求、是正処置
データ表現技法
調達 4.3.35 調達の計画
←プロジェクト計画、組織内の処理能力及び力量、既存の契約、資源要求事項、リスク登録簿
→調達計画、推奨供給者リスト、内製又は購買を決定するリスト
4.3.36 供給者の選定
←調達計画、推奨供給者リスト、供給者による応札の文書、内製又は購買を決定するリスト
→情報提供,提案,入札,応札又は見積りに関する依頼書、契約書又は注文書、選定された供給者リスト
4.3.37 調達の運営管理
←契約書又は注文書、プロジェクト計画、承認された変更、検査報告書
→変更要求、是正処置
調達戦略
契約タイプの選択
コミュニケーション 4.3.38 コミュニケーションの計画
←プロジェクト計画、ステークホルダ登録簿、役割規定書、承認された変更
→コミュニケーション計画
4.3.39 情報の配布
←コミュニケーション計画、進捗報告書、予定外の要求
→配布情報
4.3.40 コミュニケーションのマネジメント
←コミュニケーション計画、配布情報
→正確でタイムリな情報、是正処置
双方向コミュニケーション
プッシュ型コミュニケーション、プル型コミュニケーション
電子メール、ボイスメール
テレビ会議
コミュニケーションチャネル