PMBOK第7版：原理・原則の超ざっくり解説②
本記事の概要
本記事は、世に溢れるプロジェクトマネジメント手法の中でも、PMBOK第7版の概要を簡単に紹介します。
日々のプロジェクトでトラブルに疲れ果て、プロジェクトマネジメントに課題を感じていませんか・・・？
過去にPMBOKやPMPの勉強をしたけど、机上の空論すぎて "役に立たない" と思っていませんか・・・？
実は、私は過去にPMBOKに触れて、すぐに切り捨てました。
ウォーターフォール、WBS、変更管理プロセス・・・ありとあらゆるものを "管理" させられる教科書は、現場で役立つとは思えませんでした。
しかし、実は2021年以降、根本的に考え方が変わりました。
現在のPMBOK第7版は、実践的で役に立つ内容になっています。
本記事は、多くの読者にPMBOK第7版を伝えるべく、短時間で要点を掴めるよう超ざっくり解説をしていきます。
PMBOKの第7版は、具体的な手法やプロセス、手続きを定義したものではなく、プロジェクトマネジメントの「原理・原則」が重要視され、あらゆるプロジェクトに適用できる内容に生まれ変わりました。
本記事では、「原理・原則」の12個の中で、後半の6個について、簡単に説明をしていきます。5分で読める、決して難しくない内容ですので、ぜひ読んでみてください。
また、1つ前の記事で前半の6個を解説しています。
この記事で学べること
PMBOK第7版の原理・原則について、10分で概要を学ぶことができる。
筆者の体験を基に、現実のプロジェクトに反映するポイントを理解することができる。こちらの記事では、前提知識となるPMBOK第7版の概要を簡単に紹介します。
7.テーラリング
テーラリングは、元々はお洋服の"テーラー" （個人の体や特徴に応じて服を仕立てる職人さん）という意味の言葉が、PMBOKで用いられています。
つまり、全く同じプロジェクトは存在せず、背景や目的、価値、ステークホルダーなどの様々な条件を基に、
プロジェクトマネジメントのスタイルを柔軟に調整する
ことが求められています。
PMBOKを知っている方は、少し違和感のある内容かもしれません。
というのも、PMBOKの第6版までは、ハウツーを示しており、スコープ、スケジュール、コスト、品質、リスク、コミュニケーション、リソースの調達等の観点で、文字通り"管理"することを求めていました。
プロジェクトマネジメントと言えば未だに、下記のような管理手法を思い浮かべる方が多くいらっしゃるのではないでしょうか。
・ WBS
・ マスタースケジュール
・ 課題管理表
・ リスク管理簿
・ ステークホルダー管理簿
・ 変更管理プロセス
・ 品質管理プロセス
・・・などなど。
PMPの勉強をしたことのある方であれば、プロジェクト憲章、プロジェクトマネジメント計画書、スコープマネジメント計画書・・・全て書き並べはしませんが、延々と管理のためのドキュメント類が並んでいきます。
PMBOKの第7版においては、管理のために使用すべきツールやプロセス、それを用いたアウトプットが定められているのではなく、
プロジェクトの状況に応じて、柔軟に様々な手法を使い分ける(テーラリングする)
ことを原理・原則としています。
例の1つですが、必ずしもWBSを作る必要は無くなりました。
なお、決して第6版の方法論を否定するものではなく、第7版においても、方法論の1つの参考として位置付けられています。テーラリングの結果として必要であれば、使うことのできるツールの1つなのです。
8.品質
プロジェクトの中に品質の観点を組み込むことが求められています。
成果物の中に、品質を評価する指標、つまり、何を持って品質が高い/低いと言えるのかを定め、プロジェクトの活動の中で定期的に品質を評価するよう、プロセスとして組み込むことが求められています。
とはいえ、私の経験上、
必ずしも品質を評価する指標が明確に定義できない場合も多々存在する
と考えています。
例えば、成果物が "XXシステムの要件定義書" の場合に、どのような指標が適切でしょうか。
要件の網羅性・・・？
要件のヒアリングの回数・・・？
それよりも現実的なことは、お客様のステークホルダーによるレビューを受け、OK/NGの判断や、修正点があれば更新する、といった活動ではないでしょうか。
時として品質は、必ずしも指標は定義できず、定性的で曖昧なプロセスになる得る
ということを念頭に置かなければなりません。
この場合は、
品質を確認する活動を早期に実施し、全体像を見ながら段階的に改善していく
といったアプローチが考えられます。
また、システム開発においては、従来のウォーターフォール型における品質管理手法として、「テスト密度(発生率)」「バグ密度(発生率)」「レビュー指摘密度(発生率)」などが使われてきました。
しかし、昨今のアジャイル開発においては、ペアプログラミングによるコードレビューやテスト駆動開発のような開発段階での対応、動くアプリケーションを用いた仕様確認レビュー、バーンダウンチャートなどによるチームの生産性の確認など、様々な観点で品質を評価し、改善するための手法が出てきています。
状況に応じて様々な手法が考えられますが、いずれにせよ、品質の観点に関連する活動を組み込む必要があるということです。
9.複雑さ
複雑さの解説に入るにあたり、大前提を理解する必要があります。
それは、「完璧な計画は困難であり、必ずしも計画通りにプロジェクトは進まない」ということです。
このテーマは、PMBOK としては、
複雑性の舵取りをすること
を求めていますが、具体論に落とし込むと、なかなか難しいテーマです。
現代のプロジェクトは、手順書通りに作れば完成できる、"プラモデル" のようなものとは異なり、"やってみないと分からない" ような不確かさや曖昧さ、外的要因がプロジェクトに影響し変更を余儀なくされるなど、様々な困難が存在します。
このような事象に対して、プロジェクトマネージャーの知識や経験に基づき対処していくのです。
この点は、より具体的な実例紹介の中で、どのように複雑な問題が発生し、対応したのかを補足するにします。
10.リスク
プロジェクトに影響を与える不確定な事象を継続的に評価し、時として対応を行います。
抽象的な表現では解釈が難しいので、具体例を示します。
一部のメンバーが他のプロジェクトと掛け持ちしているが、他のプロジェクトはトラブルが続いている。
トラブルが悪化することで、本プロジェクトへの参画が限定的となり、作業に必要なスキルおよび要員リソースが不足するリスクがある。
これは一例に過ぎませんが、イメージが湧くでしょうか。
なお、PMBOKの"リスク"とは、必ずしもネガティブな要素ではなく、ポジティブでプラスのリスクについても触れられていますが、プロジェクトマネジメントにおいて、現実的に焦点を当て考えるべきは、明らかにネガティブなリスクでしょう。
プロジェクトマネージャーが求められている行動として、
リスクを能動的に特定し、リスク低減に向けた取り組み (先の事例であれば、念のため代替要員を探す、トラブルプロジェクト側のPMと会話し関与度合いを維持・調整する、など) を求めています。
また、万が一、リスクが発現した場合には、
影響が許容できるレベルにコントロールする (先の事例であれば、代替要員の増員や交代、スケジュール調整による一部タスクの後ろ倒し、など)
といった対応をする必要があります。
11.適応力と回復力
プロジェクトの変化に適応する観点と、失敗やトラブルから回復する２つの観点が述べられています。
プロジェクトを進めていくと、成果"物"の内容の増減、優先順位が変更、チームメンバーの交代がなど、様々な変化に遭遇します。
また、トラブルや、リスクが発現したのであれば、その影響を緩和し、そこから立て直しを行わなければなりません。
PMBOK第6版に慣れている方向けに、"計画変更" や "リスク管理" といったキーワードを思い浮かべると、イメージがつくでしょうか。
第7版の内容は、成果"物" よりも成果（価値）に焦点を当て、より良い対応方針や解決策を探し、柔軟に計画を変更しプロジェクトを進めていくことが多いように感じます。
12.変革・チェンジ
プロジェクトの成果を出すために、チームを変革する(できるようにする)ことが求められています。
変革とは、新しいアプローチ、技術、プロセスなど、様々なものが考えられます。
今までと異なる状態に変化するのですが、必ずしも全てのステークホルダーが変化に納得して、受け入れてくれるわけではありません。
各ステークホルダーへの影響を踏まえ、積極的に説明や対話を行い、時には議論し、納得して変革を進めることが必要になってきます。
後半のまとめ
本記事では、PMBOK の第7版における12の原理・原則のうち、後半の6個を紹介しました。
「11.適応力と回復力、12.変革・チェンジ」については、内容が薄く見えますが、プロジェクトの実例の中で触れていく (むしろ、メインディッシュとも言える) ので、こちらのマガジンをお楽しみください。
また、冒頭にも記載しましたが、やはり原理・原則だけ紹介されたとしても、具体的なプロジェクトへの落とし込みや、方法論については、悩まれると思います。
私自身も、「私こそがPMBOK の第7版のマスターだ！！」などど言うつもりは毛頭なく、悩む展開も多々ありました。
あの時、こうしたら、どうなったかな？
・・・という妄想もよくあります。
次回以降の事例のお話は、あくまで私のやり方に過ぎませんが、少しでもプロジェクトマネージャーの皆様の参加になればと思います。
いいなと思ったら応援しよう！
