PMBOK 7th:標準3章:③ステークホルダーは従来通り、②チームと④価値は、やっぱりアジャイルに傾斜。

今日はPrinciplesの2「チーム」から始めます。概ね、一つの原則が3ページ程度。一度に2つ～3つくらいずつ読んでいこうかと思っています。
→そう思って3つ頑張ったら、すごく時間がかかってしまった。。

3番目のステークホルダーについては、書いてあることが旧版のステークホルダー・マネジメントの内容なので、詳細な訳は飛ばしています。
②チームと④価値については、アジャイルの思想の方に傾いてると思いました。

PMBOK第6版には、9.4章に「チームの育成」というプロセスがあって、従業員の士気高揚や離職率の低下が利点とあります。ツールと技法に「交渉」や「褒賞と表彰」があったりする。そういう「いかにもヒエラルキー型組織向け」ではなく、もっと多様で自己組織化されたものを目指してる感じです。

一方、価値[Value]については、ビジネスにしっかりと焦点をあて、変化をとらえてプロジェクトも変化していかなければならない、と書かれています。これまでの第6版では、ビジネスに関しては1.2.6.1章でちょろっと書かれてるだけなので、扱いが変わってる感じです。

3.2　チーム

プロジェクトチームの協働環境を作れ。

プロジェクトの協働環境[collaborative project team environment]の作成には、チームの合意や組織構成やプロセスなど、複数の要因の貢献を含みます。これらの要因は、チームメンバーが共に働き相乗効果をもたらす文化をサポートします。

・チーム合意[Team agreements]
チーム合意は、一連の行動パラメータと、プロジェクトチームにより作られた作業規範を表現します。チーム合意はプロジェクトの最初に作成され、プロジェクトチームが一緒にに働く時間とともに進化し、共にうまく働き続けるために必要な規範とふるまいを特定します。

・組織構造[Organization structure]
（要約すると、「その時々で構造は選択され、アレンジされるよ」ということらしい。一般的な話なので、詳しく訳しません。）

・プロセス
プロジェクトチームは、タスクや与えられた仕事を完遂するためのプロセスを定義します。例えばプロジェクトチームは、作業分解にWBSやバックログやタスクボードを使用できます。

プロジェクトチームは、組織の文化や環境に影響されます。これらの影響の中で、チームは自分たちの文化を作っていきます。チームはプロジェクトの目的を完遂するために最良になるよう、組織構造を合わせる[tailor]ことができます。

役割と責任の透明性は、チームの文化を改良することができます。プロジェクトチーム内で、特定のタスクについてメンバー自らが選択したり、指名されたりします、そこには、タスクに関係する権限[authority]と実行責任[Responsibility]と説明責任[Accountability]が存在します。
ある特定の作業に対し、誰に実行・説明責任があろうとしても、協働するプロジェクトチームはプロジェクトの成果物に対し、協働所有権を有します。（要するに、「自分の責任じゃないから知らない」って言わないってこと）

多様なプロジェクトチームは、お互いに異なる見方を持ち寄ることにより、プロジェクト環境を豊かにします。（ダイバーシティの話が入ります、略）

プロジェクトチームの協働環境の別の側面は、実践標準や倫理コードや、プロフェッショナルが組織やプロジェクトチームで働くためのガイドラインの組み込みです。プロジェクトチームは、どのようにこれらのガイドが、チームの規律との間の衝突を避けることができるか、考慮します。

プロジェクトチームの協働環境は、情報と知識の自由な交換をはぐくみます。これはまた、プロジェクト開発中の共有学習とメンバーの成長を増やします。プロジェクトチームの協働環境はすべての人が、組織が要求する成果に対し最善の努力で貢献することを可能にします。
そして組織は、その基本的な価値や原則や文化を尊敬し強化する成果物から、恩恵を受けるでしょう。

3.3　ステークホルダー

ステークホルダーとの効果的な関与

（先頭に、ステークホルダーの定義と、ステークホルダーがどんな影響を与えるか？という例が書かれています。あとは、ステークホルダーとどう関わっていくか？など、ステークホルダー管理の話が要約されて書かれていると思いました【プロセスとしての記載ではなく、平文の記載という意味です】。この辺は第6版以前のPMBOKをご覧ください。そのため、本章は省略します。）

3.4　価値

価値に焦点を当てる

価値（顧客やエンドユーザの視点からの成果を含む）は、究極の成功の指標であり、プロジェクトの道しるべです。プロジェクトの価値は、スポンサーや受益組織に対する財務的な貢献として表現されるかもしれません。価値はまた、社会や顧客がプロジェクトの結果から享受するメリットが達成されたかどうかの尺度かもしれません。プロジェクトがプログラムの構成の一部であるとき、プロジェクトのプログラムへの貢献も、価値と言えます。

多くのプロジェクトは、ビジネスケースに基づいて開始されています。プロジェクトは、契約や作業明細書やその他のドキュメントにより、プロセスやプロダクトやサービスを開発したり変更する必要性が確認されてるために、開始されるかもしれません。すべての場合で、プロジェクトの意図は、価値あるソリューションで要求に対応し、望んだ成果を提供することです。

ビジネスケースには、戦略的提携やリスクアセスメントや、経済的フィジビリティスタディーや投資のリターンなどの情報を含みます（何言ってんだ？）。ビジネスケースは、プロジェクトの定性的および定量的な価値の貢献を明言するかもしれません。ビジネスケースには少なくとも、これらの要素を含みます；

・ビジネスの要求
ビジネスはプロジェクトに、なぜプロジェクトを遂行するのかに対する論理的根拠を提供します。その根拠は、ビジネス要求の初期資料やプロジェクト憲章などのドキュメントに記載されます。ドキュメントは、ビジネスのゴールと目的を提供します。ビジネス要求は、実行組織や顧客の組織、組織のパートナーシップを意図しているかもしれません。ビジネス要求の明示はプロジェクトチームが、将来のビジネス上の状態の変化を理解し、プロジェクト成果の価値が増減する機会を特定するのに役立ちます。

・プロジェクトの正当性
プロジェクトの正当性は、ビジネス要求に関係します。なぜそのビジネスが投資に値し、なぜこの時点で対処すべきなのかを説明します。プロジェクトの正当性には、費用便益分析と仮説を伴います。

・ビジネス戦略
ビジネス戦略はプロジェクト実施の理由で、すべての要求は価値の達成に対する戦略に結びついています。

（要するに、プロジェクトってのは価値という成果を出す営みなんだけど、価値のベースとしてビジネスがあるので、ビジネスの戦略や要求を理解してないと、正しい価値を生むことができないよ、ということのようだ。

なので、クリアに書かれないといけないし、プロジェクトの遂行中にUpdateされなければならない。ビジネス状況は常に変化するから。最初にこう決めたんだから変えない！ってすると、失敗するよね。）

プロジェクトチームは継続的に、プロジェクトの進行と望ましい成果やベースラインやビジネスケースに対する方向性を評価します。代わりに、ビジネスケースは、プロジェクトチームやステークホルダーに特定された好機をとらえ問題を最小化するよう、アップデートされます。もしプロジェクトやステークホルダーが、もうこれ以上はビジネス要求が達成されないとか、残念ながら期待される価値が提供できないと判断したときは、プロジェクトの中止が選択されるかもしれません。（←私は30年で一度も見たことないけど！！）

価値[value]とは社会的・絶対的な価値があり[worth]、重要で、有用な何かです。価値は主観的で、同じコンセプトでも違う組織・違う人にとっては違う価値であり得ます。何を利益と考えるかは、組織の短期・長期の財務的利益に対する、または非財務要素に対する戦略により、変化します。
すべてのプロジェクトはステークホルダーの幅があるので、各ステークホルダーのグループによって作り出された異なる価値は、顧客の視点で重要度を決め、全体でバランスを取らなければなりません。

プロジェクトの文脈では、顧客や組織やステークホルダーに対する価値を最大化するための、異なる型が存在します。ここには、要求される機能性と品質レベルを低リスクで、できるだけ少ない資源を使い無駄を避ける手法を含みます（要するに、小さく作るアジャイル的な手法）。
特に適応型プロジェクトでは、決まったスコープを持たず、プロジェクトチームが顧客と一緒にどのフィーチャーが投資に値するか、成果物に追加する価値があるか、決定することができます（要するにアジャイル・スクラム）。

プロジェクトの価値実現をサポートするために、プロジェクトチームは焦点を成果物から意図した成果に移さねばなりません。これによりプロジェクトは、ただ特定の成果物を作るのではなく、プロジェクトのビジョンや目的のために実施することが可能になります。

例えば顧客は特定のソフトウェア・ソリューションが欲しいかもしれない。なぜならそのソリューションが高い生産性でビジネス要求を満たすと考えたから。そのソフトウェアはプロジェクトの成果ですが、ソフトウェアそれ自体は意図した生産性を実現しません。このケースでは、ソフトウェアの使用により生産性を向上させるよう、ソフトウェアのトレーニングとコーチングを成果物として足す必要があります。もしプロジェクトの成果物が生産性をあげることに失敗すれば、顧客はプロジェクトが失敗したと感じるでしょう。

このように、プロジェクトチームとステークホルダーは、成果物と成果物から得られる結果の両方を理解します。

プロジェクトによる価値の貢献は、短期・長期で測定され得ます。なぜなら、価値の貢献は貢献そのものと運用活動が混在し、切り離すことができないからです。プロジェクトがプログラムの構成要素だった場合、プログラムレベルでの評価が必要です。

価値の評価は、プロジェクトの成果物のライフサイクル全体で実施すべきです。価値は時間と共に実現されますが、効果的なプロセスにより、早期の利益実現が可能になります。効果的で効率的な実装により、プロジェクトチームはデモを行ったり、優先度をつけたデリバリや、よりよい顧客サービスや、改善された作業環境などの成果を成し遂げます。プロジェクトの成果物の使用に責任を持つ組織リーダーと働くことで、プロジェクトリーダーは成果物が計画した成果を実現すると確信できるのです。（この部分もアジャイル。）

最後に：読んでいて思ったこと。

・バリューについて：プロジェクトの目的
私がPMになりたての頃、いわゆるエンプラ系のSIerにいたんですけど、プロジェクト計画書の冒頭って書くのがすごーく、難しかったです。なぜこのプロジェクトをやるのか？って、そりゃ会社に言われたから、だったから。
プロジェクトの目的は、会社の利益としてQCDを達成することだと思っていました。。

・バリューについて：時間の経過と価値の変動
以前ある市場製品のPMO設立のお手伝いをしてたんですが、ある機種の開発（WF）に1年かかるのですね。で、開発期間中に他社が新機能を出してきたから、それをすぐ組み込め、という。いやそれWFでは無理ですよねと。その追加対応でソフトの開発が遅れるので、ソフトは悪者になっていたのです。そういう開発は、もう無理という話なのかなと思って読みました。

あと印象に残ったのは、「プロジェクトの成果が、即成功ではない場合があるよ」ですかね。確かに、ただ要求仕様に沿ったソフトだけ与えても、使いこなせなくて「言ってたことと違う！」ってのは、時々聞く話です。

さて、次回は「システム思考[System Thinking]」と「リーダーシップ」の二つで区切ろうかと思います。システム思考と聞くと、故ワインバーグ氏を思い出します。そして、訳すの難しそう。。。

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