スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

PMP受験記録(その7:PMBOKについて思うこと)

●PDCAサイクルのマッピング

PMBOKのプロセス群は、
・立上げ
・計画
・実行
・監視コントロール
・終結
の5つにまとめられている。

しかし、この中の実行というプロセス群が混乱を招く。
通常、仕事でPDCAサイクルを行う場合、Doは、実際の成果物を生成するプロセスである。
PMBOKでは、成果物を生成するプロセス、例えばソフト開発ではソースコードを書くなど、は、成果物指向プロセスとして、プロジェクトマネジメント・プロセスとは別に扱われ、PMBOKではプロジェクト・マネジメント・プロセスのみを扱う。
プロジェクト・マネジメント・プロセスは、プロジェクト・マネジメント・チームが行い、成果物指向プロセスは、プロジェクト・チーム・メンバーが行い、両者はプロジェクトの期間中重なり合いながら進んで行く。
成果物指向プロセスは、個々の業務に固有なので、PMBOKで扱うことはできない。

とすると、Doは、成果物指向プロセスに当たるので、PMBOKのプロセス群ではないのか、というと、その実行を指揮・監督する「プロジェクト実行の指揮・マネジメント」というプロセスが担当する。ただしこのプロセスは、実際のソースコードを作成するなどの作業を行うのではなく、あくまでもチーム・メンバーに対して指示を出すことである。このアウトプットに要素成果物があるが、指示した結果、アウトプットされたと考えると納得が行く。

ところが、実行プロセス群には、それ以外にも、
・品質保証
・プロジェクト・チーム編成
・プロジェクト・チーム育成
・納入者回答依頼
・納入者選定
・情報配布

というプロセスが含まれている。これは納得ができない。
「実行」という言葉からすれば、これらも実行である。しかし、それを言ったら、計画も監視も終結もすべて「実行」である。

品質保証は、作業に対する監査を行うことなので、本来、監視・コントロールに入れるべきだ。(一方の品質管理は、成果物に対する検査である)。

情報配布も、監視・コントロールの一種である。もし、これが実行なら、なぜ「実績報告」が実行に入らないのだろうか。

プロジェクト・チーム編成や納入者回答依頼、納入者選定は、計画プロセス群、プロジェクト・チーム育成は監視・コントロール群に入れるのが妥当だと思う。

しばしば、「実行」という意味で混乱があり、終結プロセスは手順を出力するだけで実施は実行プロセスというへんてこりんな形になっている。

実行は、「計画書で定義された作業を実施する」とあるが、計画書には、計画書作成自体もあれば、監視・コントロールの手順についても記されている。

実行に対して計画はメタレベルにある。成果物指向プロセスとプロジェクトマネジメントプロセスもメタレベル関係にある。その部分を並列で扱うと、混乱を招く。計画書を作るのも実行のうち。計画書を作るための計画もある。さらにその計画書を作る計画もある。メタレベルは続く。
あることに対するメタレベルがあったとしても、次にはそれ自体が対象となる。実行に対して、計画は、その実行の範疇外となるが、計画もまた別のレベルから見ると、実行対象となる。計画を計画することを計画する、なんてやっていくとキリがなさそうだが、どこかで計画自体の計画は必要なくなる。

大きなプロジェクトだと、計画書を作るのも一つのプロジェクトだ。そうなると、計画プロセスを実行するチームの編成も必要になる。

ソフトウエアを作成する場合、設計書は、WBSであり、計画書である。テスト設計書はスコープ検証のためのWBSである。しかし、設計書は計画プロセスの中の成果物ではなく、実行プロセスの成果物である。

では、プロマネは、設計書作成に参加するのだろうか。プロマネは打ち合わせでは何を話すか? ある企業では単なる司会進行役で、少しでも中身の話になれば担当者が話をする形をとっていた。PMは理解できない話に長時間付き合う。PMは技術的な話に深く首を突っ込む必要があるだろうか。金・時間・人と結果のみを気にするのは、経営陣である。
この辺は、そこは個々のプロジェクトで違うから突っ込めないのだが、その境界というか接点の部分を明確にする必要があるのではないかと思う。


●そのほか
そのほか、いくつかの疑問があった。研修のときに聞いて解決したものもあったが、PMBOKではこうなっていると回答するしかないものもあった。

・プロセスの中にサブプロセスを含んでいるものもある。タイム・マネジメントのところは、かなり細かくしている一方、調達のところは、いくつかのプロセスをまとめてしまっている。そうするとプロセスの役割、インプット・アウトプットが不明確になってしまう。

・ベースラインは変更せずに、スケジュールだけ変更するのはよい?というか現実にあるが、プロジェクト・スケジュールの更新版がない。

・契約管理・終結は、調達についてのみか。顧客との契約はどこで処理する?

・スコープ検証と終結の関係は?通常のプロジェクトではスコープ検証で顧客の受入を持って、プロジェクトが終了プロセスに入れるはずである。だからスコープ検証は終結に持って来るべきでは。この辺の微妙な位置関係を表現できない。

・却下済み変更要求があるのに、却下済み是正・予防・欠陥修正はない?

・主語が欠けている。誰が行なうのか。スコープ検証は、顧客がやる受入試験?その前に内部でやる検証?顧客から受入のサインを貰うことだけ?

・ツールと技法の中にインプット・アウトプットにすべきものがある。アウトプットに計画書の中に含めるべきものもある。

・なぜスケジュール・コントロールには作業パフォーマンス情報がインプットされないのか。

・実績報告と各コントロール どっちが先か。

・ステークホルダーマネジメントでも変更管理をする? アウトプットに承認済み変更要求・是正処置がある。

・スケジュール計画プロセス、コスト計画プロセスがない。

・スコープ検証と品質管理の違い
スコープ検証も要求事項への適合をチェックするのでは。しなければ納品できないのでは?

細かいところは他にもいろいろあるが、こういうことに明確な理由があるのだろうか。単なる欠落であれば、ぜひともきちんとPMBOKに含めてほしい。

関連記事
スポンサーサイト

コメント

非公開コメント

プロフィール

dayan

Author:dayan
小職は、SE(システムエンジニア)を専門としておりますが、技術的な情報を中心に、それ以外に経済関連の日記、たわいもない日記も載せていきます。
[公式HPもよろしく!]

天気予報

-天気予報コム- -FC2-
リンク
ブロとも申請フォーム

この人とブロともになる

カテゴリー
最近の記事
ブログ内検索
最近のコメント
最近のトラックバック
RSSフィード
月別アーカイブ


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。