PMBOK 7th 標準2章【後編】：2章はどうやら、超ザックリしたフレームワークの説明であるらしい。

今日も、標準の2章の続きです。2.3章から始めます。
昨日の先頭で、この章に書かれていることは「プロジェクトの機能」（project functions）って書いたんですけど、今日よく2.3章を読んだら、機能じゃなくて役割なんですね。。。大変失礼いたしました。

前回と今回で、どこの話をしてるのか？を少しまとめてみました（ひょっとして、読み違いがあるかもしれないですが）。緑が前回、オレンジが今回です。
どうやら、2章でこのフレームワークの説明をして、3章でこれを管理する行動原則を示そうとしている、ようです。標準部分は、3章で終わりです。

2.3　プロジェクトに関連する役割

プロジェクトは、プロジェクトを効果的かつ効率的に運営するために必要な、さまざまな役割[functions]で推進されます。この役割は、ある一人の人や、グループや、定義された役割の組み合わせで構成されます。
（PMとか、PMOとか、なんとか統括とか、そういうやつのことかな。）

プロジェクトの共同作業が「適切に連携」[coordinate]するよう努力することは、プロジェクトが成功するために非常に重要です。
※ coordinate：to organize an activity so that the people involved in it work well together and achieve a good result

この作業連携は、文脈により異なるタイプが適合します。あるプロジェクトは、チームメンバーが自己組織化するような、分権的な作業連携が上手く行きます（アジャイルはこのタイプに相当する）。またあるプロジェクトでは、プロジェクトマネージャーかそれに類する人のリーダーシップとガイダンスによる、中央集権的なタイプが上手く行きます（ヒエラルキー型、従来のプロジェクト組織）。中央集権型の作業連携だったとしても、その一部が自己組織化されているということも、あり得ます。

どのような連携でれ、プロジェクトチームとステークホルダーの間を支援的なリーダーシップモデルで適切に関与することは、成果の成功を下支えします。
納品物や業界や組織やその他の要因により、別の役割がプロジェクトを支援するかもしれません。2.3.1～2.2.8章に、よくある例を示します（これがすべてではありません）。

2.3.1～2.3.8：役割例

↓これらは例とのことなので、詳しく和訳して残すのはやめます。

2.3.1　監視と調整の提供[provide oversight and coordination]
2.3.2　目標とフィードバックの提供[present objectives and feedback]
2.3.3　ファシリテーションとサポート
2.3.4　仕事と洞察の貢献[perform work and contribute insight]
2.3.5　専門知識を適用[apply expertize]
2.3.6　ビジネスの方向性と洞察を提供[provide business direction and insight]
2.3.7　リソースと方向性を提供[provide resources and direction ]
2.3.8　ガバナンスの維持[maintain governance]

（2.3.1と2.3.2はPMやPMOという感じ。2.3.3はスクラムマスターか。2.3.4～2.3.5は開発チームやコンサルと思われ、2.3.6はプロダクトオーナー、2.3.7はもっと組織（ライン）的な話っぽい。メンターとかもここに入りそう。
2.3.8は、社内PMOみたいな感じかな。よくフェーズ完了の監査を社内PMOがやったりしますが、そういうのが当てはまりそう。

なんか、まわりくどい（笑）。
とにかく、組織やプロジェクトによって必要な役割は異なり、何をどう組み合わせてプロジェクトを成功に導くのか？は、都度違うよ、ということのようです。）

2.4　プロジェクトの環境

前述の通り、プロジェクトには内部環境や外部環境があって、それらが様々な深度で影響を与えます。影響はプロジェクトの特性やステークホルダーや開発チームに対し、喜ばしいもの/そうでないもの/中立のインパクトを生じます。

2.4.1　内部環境

ここも例が出てます。例を見ると判りやすいと思うので、ざっと挙げておきます。
・プロセス資産
・ガバナンス資産
・データ資産
・ナレッジ資産
・セキュリティと安全性
・組織の文化、構造、ガバナンス
・施設やリソースの地理的貢献
・インフラ
・リソースの可用性
・従業員の能力

2.4.2　外部環境

こちらも例示です。
・市場の動向
・社会的・文化的な影響と課題
・規制環境
・商業データベース
・学術調査
・業界の標準
・財務上の考慮事項
・物理的環境

（こういう環境的なものには、リスクが潜在することがあるのでよく注意せよと、先輩から習ったのを思い出します。）

2.5　プロダクト管理の考慮

ポートフォリオ、プログラム、プロジェクト、プロダクトの統制は、より密接に連携されています。プロジェクト管理以外は本標準の範囲外ですが、これらの連携はプロダクトを生成するプロジェクトにおいて、有用な文脈を提供します。

（プロダクトマネージャーというのは、PMとはまた全然別の役割ですよね。プロダクトオーナーとも違うし。
私はあまりエンプラ以外を知らないので、プロダクトのライフサイクルに関してはあまり関連がないのです。いったん「ここにプロダクトライフサイクルの話があったよ。」にとどめます。必要性やご要望が出てきたら、あとで書くかもです。）

最後に

さて、なんとか2章が終わりました（だいぶ端折りましたが。）。
プロジェクトと、それを取り巻くコンポーネントや環境などのフレームワークが提示された、ようです。
第6版のプロジェクトマネジメント標準では、プロジェクトの立ち上げ→計画→実行→監視→終結、というプロセスを説明していたのですが、そういうプロセスの説明は一切！なくなっています。（第6版を見ろ、ということなのだろうか。。）

その代わりに、なんでもぶっ込めるザックリしたフレームワークになってるわけですが、まぁこれは本標準のメインではなく、3章のPrinciplesが本題なのです！楽しみです。

あとちょっと気になったのが、開発組織の話をするときに[organization]でなく[coordinate]を使ってる、ということです。開発形態によらない記載にしてるなと思いました。

次回以降は3章を読むのですが、12つのPrinciplesを分けて書くか？いくつかをまとめて投下するか？検討中です。それぞれのボリュームはそんなの大きくないので、いくつかをまとめる方に傾いています。

今回もお読みいただき、ありがとうございました。