PMBOK 概要編〜PMの分類体系
ーCAP1.2ー
PMの知識体系
PMの知識体系〜大きくセグメントして３つある
９つの知識分類エリア
アウトプット
スコープ
９つの知識分類エリア
・プロジェクト統合マネージメント（PIntegrationM）
全体を促えるための作業エリア。他の知識分類セグメントを集約し、統合するセグメント。プロジェクト全体を俯瞰できる全体の最適化を測る部分。
・プロジェクトスコープマネージメント（PScorpM）
スコープは作業範囲という意味で、どこまで対応させるか、どこまで作業するかを指している。
・プロジェクトタイムマネージメント（PTimeM）
スコープの期日算出で俯瞰できるスケジュール作成とその管理するエリア
・プロジェクトコストマネージメント（PCostM）
プロジェクト予算に似合う見積もり作成とコストの算出するエリア
・プロジェクト品質マネージメント（PQualityM）
成果物の完成度を設定し、それを達成するための手段を計画するエリア。品質は時間と予算、スコープで決まる。
・プロジェクト人的マネージメント（PHumanM）
プロジェクトチームの設立と体制などを決めるエリア。
・プロジェクトコミュニケーションマネージメント（PCommunicationM）
チームないのコンセンサス（合意や決定等）やシェアー（共有等）を決めるエリア。
・プロジェクトリスクマネージメント（PRiskM）
作業を進める際にどのようなリスクがあるのかを想定範囲で洗い出し、その対応を考えるエリア
・プロジェクト調達マネージメント（PProcurement M）
外部業者の発注や契約に関わるエリア
知識エリアでの重要サイクル
インプット→ツールと技法→アウトプット
取得方法→処理方法→成果物のこと。
インプット：情報を収集すること。
例）ステークホルダー・組織分析・プロジェクト概要ノイズ制約条件
ツールと技法：インプット情報を処理するテンプレートや判断を下す方法・ノウハウ
アウトプット：ツール技法を用いて、企画書、見積書、ログ管理、動作検証テスト報告書、議事録等のドキュメント類
アウトプット：ここでは仕事や作業の結果を形として残したもの。日本のビジネスシーンではアウトプットで作業結果を形として残す文化はあまり意識されていなかった。というより、案件に関わるメンバーに変化がなかったり、成果物が毎回大きなちがいがなかったが、前回でもプロジェクトは有機的かつ独自性にとんでおり、毎回成果物が変わってしまう。
作業範囲を決めるスコープ
プロジェクトスコープマネージメントは
その後のPMを決める一つの指針になる
スコープ：直訳は範囲。プロジェクトにおいては、作業範囲を指す。スコープは「成果物スコープ」と「プロジェクトスコープ」に分けることができる。
成果物スコープ：発注者側に納品するすべてのもの。具体的にはプログラムソースやimgデザインデータ、ドキュメントテキスト、時には物理的デバイスも含む。
プロジェクトスコープ：成果物までの必要な作業。例えば、ミーティング回数やソリューションコンサル業務など目に見えない必要な作業。
スコープマネージメントの重要性として、双方間（制作会社とクライアント）の作業範囲の共通認識である。ここが疎かな場合、トラブル（スコープクリープ）が発生し、その他のマネージメントに影響が出たり、再度すり合わせ、成果物の相違などさまざまなクリープが発生する。
９つの知識エリア・スコープ・アウトプットのバランス
PMBOKはデファクトスタンダードになりつつあるが・・・
網羅性：９つの知識エリアを網羅する必要があるということ。網羅して初めてプロジェクトの方向性や成果物が見えてくるため。最初はクライアントすら成果物が想像できていない状況。また、その成果物がどのような影響を与えるかが見えていないもの。その状況下の中、成果物の責任を負うためディレクションは先を見据え、各メンバーを指揮しなければならない。ディレクターが曖昧であればあるほど、メンバーのモチベーションの維持や身勝手な暴走を止めることが困難。論理的に納得させるためには網羅性は重要と考えるべきである。
柔軟性：マージンを持っておくこととも言えるが、ここでは「手を抜くところは手を抜く」「状況に応じた変更」が必要になる。プロジェクトには独自性が含まれ、予期しない出来事があるのは当然で、そのリスクを柔軟に対応するためには完璧に仕上げたところで、変更があるのは目に見えている。そのため、網羅性も必要だが、柔軟に変更を加えゴールに導く必要も当然担う。
PMBOKはフレームワーク（体系）でありバイブルではないことを押さえておく必要がある。
余談＿バイブルとは
バイブルは３つの意味がある。「聖書」「その分野でもっとも重要な書物」「自分の考えなどに影響を及ぼした重要なもの」の３つ。PMBOKは決して、パーパスやモラル等の普遍的なものではないこと、時にはPMBOKフレームワークから脱することはあり得ると認識しておく。それがプロジェクトであるという認識でいることが必要である。