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