番外編 PMBOK®7thの先へ プロジェクト・デザインでプロジェクトの発意・形成と実行をつなぐ
8月1日にPMBOKの第7版（以下PMBOK®7thと記す）が発行されました。
私はTGS多摩大学大学院でPMの講義を担当している手前もあり予約購入しましたが、一気に読み進めることのできる程面白い本ではないので、一日2時間程の時間を当てて何とか読了しました。
既にnoteにも優れた紹介記事が投稿されていますが、このnoteは少し観点を変えて、PMを担う方々のより有効性の高い実践のために、PMBOKを補う下図の提案をしたいと思います。
下記目次の順序で記述します。
先ず、PMBOK®6thからPMBOK®7thへ何が変わったか、要点を記述します。
次に、私がPMBOK®6thに感じていた違和感とこれらがPMBOK®7thでどの程度解消されたか、を整理します。
最後に、以前として残る違和感を解決するための提案を提示します。
このnoteは、多摩大学大学院の講義で使用してきた教材を下敷きに、その大幅改定のためのドラフトを、クリエイティブコモンズ［©中分毅 (Licensed under CC BY-NC-ND 4.0)］として公開するものです。
今月は、コスト・マネジメントを取り上げる予定でしたが、PMBOK®7thが8月1日に公開されましたので、番外編としてこれについて思うところを記しました。
目次
1. PMBOK®6thからPMBOK®7thへ何が変わったか
PMBOK®6thからPMBOK®7thへ何が変わったかについては、発行前から米国では多くの記事が書かれていました。それらも参照し、2以降の議論の前提として、何が変わったかを大急ぎで見ておくことにしましょう。
両者を比較して下図に示しました。（見難い方はクリックして元のスライドを見てください）
■PMBOK®6thの特徴と構成
PMBOK®6thは、予測型アプローチを基軸に据えています。予測型アプローチはpredictive approachの直訳です。プロジェクトの出発で見通しが立ち、完了までの計画を策定してこれを実行するというアプローチで、Waterfallと同義です。predictiveは事前確定的と訳す方が適当かとも思います。適応型アプローチadaptive approach（agileはこれに該当します）を無視している訳ではなく、その場合の留意点を補足し、更にAgile Approachに関するガイドブックは別冊で発行されています。
構成は次の様になっており、予測型アプローチのプロセスを基礎に置いた構成となっています。
①知識体系は、「5つのプロセス X 10の知識エリア」のマトリックスで整理されています。
②5つのプロセスとは、立上げ、計画、実行、監視・コントロール、終結です。
③10個の知識エリアは、統合、スコープ、スケジュール、コスト、品質、資源、コミュニケーション、リスク、調達、ステイクホルダーで、10のエリアに関して、計49の手順／処理に関する知識が整理されています。
■PMBOK®7thの特徴と構成
PMBOK®7thは、予測型から適応型までの全方位に対応することを基本としています。このため、全体の構成にも抜本的な変更が加えられました。
① プロセスを重視した5つのプロセスから、原理重視に基づく構成に変更されており12の原理が提示されています。12の原理の内容は上の図に示していますが、行動を導く基本原理であると位置付けられています。
② 10の知識エリアに換えて、8のパフォーマンス・ドメインが新設されています。このドメインは、プロジェクトが求められる成果を提供できるか否かを左右する重要な領域として設定されています。具体的な内容は上の図を参照して下さい。
③ この結果、PMBOK®6thの様な「プロセスX知識領域」というマトリックス型の構成は踏襲されていません。
PMBOK®6thは756ページという分厚い本でしたが、PMBOK®7thは、12の原理を記述したThe standard for project management67ページと従来のPMBOK®Guideの274ページの合計341ページと半分以下に圧縮されています。
■全体的な比較
下のスライドは、「Everything you need to know about the PMBOK Guide 7th edition」という米国のブログから引用したものですが、両者の相違点がコンパクトにまとめられていますので、一部改変して和訳を付しました。
https://yassinetounsi.com/everything-you-need-to-know-about-the-pmbok-guide-7th-edition/
このスライドにも示されていますが、私個人としては、以下の様に捉えています。
今回の最大の改訂は、Predictive/Waterfall基軸からAdaptive/Agileまでの全方位対応への変更で、それに伴って、Predictiveをベースとするプロセスに焦点を当てたPMBOK®6thの記述レベルよりも、一段メタレベルの記述を採用した。
従って、3で述べる様に、PMBOK®6thに対して感じた疑問・違和感を解消する方向性は示されたものの、プロジェクト・マネージャーが実務で活用できる具体的なレベルの実践知は提示されなかった、と感じています。
2. 消えない違和感とその原因
私が初めてPMBOKを読んだのは2000年です。建設領域におけるPMともいえるCM（Construction Management）の普及のために設立された日本CM協会の創成期に、CMの知識体系を検討する上でのお手本として、米国事情に詳しいメンバーの手ほどきで読むことになりました。この時には「プロセスX領域」のマトリックスで知識を整序するPMBOKの方法論に大変触発された覚えがあります。
次に読んだのは2015年で、TGS多摩大学大学院でPMの講義を担当することになったらからです。PMPを取得した勤め先の後輩からPMBOK®5thを送ってもらい、程なく発行されたPMBOK®6thと併せて四苦八苦して読了しました。分厚いこともあってPMBOKそのものやPMBOK解説書を講義のテキストとして用いることは難しいと考え、独自に講義用のテキストを作成してきました。
その時に感じた疑問や違和感（不満と言うべきかもしれません）は、下図に示すように二つに大別されます。
① PMBOKの設定するプロジェクト・マネジメントの領域内での違和感
② PMBOKがプロジェクト・マネジメントの領域を限定することに対する違和感
以下では、PMBOK®6thに対する違和感について説明し、続いてPMBOK®7thでこの違和感がどの程度解消されたかを述べたいと思います。続く3では、この違和感の解消策の一つがプロジェクト・デザインである、との提案をします。
2.1. PMBOK®6thに対するプロジェクト・マネジメントの領域内での違和感
プロジェクト・マネージャーにとって切実な状況に対応する指針が読みとれないのではないか、と思われる点が大きく5点があります。
① プロジェクトの目的・目標が抽象的（具体性がない）、曖昧（解釈が複数）、現実性がない、矛盾がある場合にどう行動するのか？
・ PMBOK®6thではプロジェクトの目的・目標は所与であって、これらは前プロジェクト段階業務（Pre-Project Work）のBusiness CaseやBenefits Management Planなどで検討・設定されます。これに基づいて目的、目標、成功指標、主要な要求事項と成果物などを記載したプロジェクト憲章Project Charterが作成され、プロジェクト・マネジメント計画策定へのインプットとなります。
・PM実務を担う方（つまりプロジェクト・マネージャー）は、プロジェクト・オーナーから提示された、目的・目標が、抽象的で具体的なイメージがない、曖昧で人によって解釈が異なっている、矛盾があって実現することが困難である等々の問題を実感することが多々あるものと思います。
・しかし、役員会の決定事項である、顧客の要望である、という理由で、目的や目標が吟味されることなくプロジェクトに突入する場合も多い筈です。
・この出発点での躓きへの対処法が示されてないと私は感じます。これを違和感の第一点目に上げたいと思います。
② 出発時点ではすべてを見通すことはできない時にどう行動するべきなのか？
・目的や目標が曖昧な場合には言うに及びませんが、仮に目的・目標が明確であったとしても、出発時点でプロジェクトの終着点までの業務展開を詳細に見通すことが出来るプロジェクトは、そう多くはないと思われます。
・この様な場合に、プロジェクトの当初で詳細なWBSやPERTを創り上げ、これに基づいてEVMでプロジェクトを管理していくことは、無駄であるばかりか余分な労力を発生させ、ティーム・メンバーの士気を挫くという点で機会損失の発生であるとさえ感じます。
・PMBOK®6thでは、事前確定的（Predictive）でない場合のプロジェクト・ライフサイクルについても触れられていますが、事前確定的（Predictive）でない場合は副次的であり、他のコストや品質などのマネジメント領域で不確定性にどう対処するのかが明確に示されている訳ではありません。
③ 各マネジメント領域における固有の課題とは何か？
・PMBOK®6thでは、コスト、品質、コミュニケーション等10のマネジメント領域やその下位領域に関する記述が、Inputs→Tools & Techniques→Outputsと言う統一したスタイルで記述されています。
・プロジェクト・マネジメントに関する膨大な知識領域を体系的に記述する上で、スタイルを揃えないと書き手も読み手も収拾がつかないということは理解するのですが、何を入力し何を出力するのかという手続き的な記述が中心となっており、読み通すのに大変な忍耐力が要求されます。
・加えて、PMBOK®6thでは、プロジェクト・マネージャーが直面するその領域固有の課題とそれへの対応方法が明示されている訳ではなく、読者は苦労して読んだ割には報われないと感じるのではないでしょうか。
④ プロジェクトは人間によって担われる、では人間的側面への対応は？
PMBOKが技術主義に偏向しているとの批判は数多く寄せられていたと思うのですが、私は大きく2点の問題があると思います。
・一点目は、プロジェクト・ティーム・メンバーの動機付けを如何に維持・発展させるかという点です。これはプロジェクト・マネージャーの根幹的な役割の一つだと思うのですが、PMBOK®5thのINDEXには“Motivation”を見出すことはできません。
・ 二点目は、プロジェクト・マネージャーの力能Competencyやリーダーシップです。技術主義が強ければ、プロジェクト・マネージャーに求められるものは技術的知識を如何に適切に活用するかに限定され、リーダーシップや全体的な力能を問う必要はないことになります。PMBOK®5thのINDEXでCompetencyの該当ページを見ると書かれているのはメンバーの技術能力であって、Leadershipについてもプロジェクト・マネージャーのInterpersonal Skillsの一つとして記述されているに過ぎません。
PMBOK®6thでは3.4.4Leadership Skillsにおいて、人間的側面の重視（A common denominator in all project is people, P60）、プロジェクト・マネージャーはリーダーシップとマネジメント能力の両者を兼ね備えている必要があること（Project managers need to employ both leadership and management. P64）が記述され、改善が見られますが、付随的な位置付けに留まっている様に思われます。
⑤ プロジェクト・オーナーの中にはしばしば見解の不一致が存在するが、それにどう対処すればよいか？
・唯一無二の意思決定者が全てを決するという独裁的なプロジェクト・オーナーは少ない訳で、オーナー組織や役員層の中で見解の不一致があり、これに振り回されるという経験をした方も多い事でしょう。同じ組織内であっても部署や階層が違えば保有しているフレーム（関心事やものの見方）が異なる訳で、複数組織の共同プロジェクトとなるとこの点は際立ったものになると思われます。
・この問題が解決されないと、予算はどんどん消化されていくが仕事の手戻りは多く、ティーム・メンバーの士気も下がっていくことになります。
・手続き論的なステイクホルダー・マネジメントやコミュニケーション・マネジメントのみで、この問題への対処方針を見出すことは困難と思われます。
2.2. PMBOK®6thがプロジェクト・マネジメントの領域を限定することに対する違和感
これについては、大きく2点あげたいと思います。
① プロジェクトの目的・目標は所与なので、プロジェクト・マネージャーの役割は受領し、理解することに限定されているのではないか？
この項目は、2.1の①「プロジェクトの目的・目標が抽象的、曖昧、現実性がない、矛盾がある場合にどうするか触れていません」とも密接に関係する事柄で、さらに3点指摘したいと思います。
・先ず、PMBOKでの区分によるプロジェクトの立上げ（initiating）において、プロジェクト・マネージャーは提示されたプロジェクトの目的や目標を理解するという受動的な立場に留まっていますが、それらを吟味し、必要があればプロジェクト・オーナーに再考を求めたり、オーナーと協働して明晰にする作業をしたりすることが可能なステップを組込むべきだと考えます。
・次に、より本質的な点として、プロジェクトを発意し形成する過程にプロジェクト・マネージャーが全く関与しないWhat（プロジェクトの発意・形成）とHow（プロジェクトの実行）の整然とした区分が有効なのか、を挙げたいと思います。そもそも多くのプロジェクトでは、プロジェクトを発意した主体がそのまま実行を担うという場合も多い筈で、この様に截然と区分して論じることに疑問を感じざるを得ません。
・最後に付け加えたいのは、共創が重要視される時代にあって、ある程度プロジェクを進めて行く中で相互理解が深まり目的や目標が豊かになり具体化されていくプロジェクトも増加し、その重要性も高まっていくことです。
なお、私が、PMBOKを独断的に解釈した上で批判している、と思われる方がおられても当然かと思いますが、そうでないことは、後出3.2や3.3をお読み頂ければ納得がいくと思います。
② プロジェクトの成果に対するオペレーションからのフィードバックを受けるループはどこにあるのか？組織の成熟度の問題なのだろうか？
・「オペレーションの観点が反映されなかった」は、プロジェクト失敗の原因の上位にランクされることが多い要因の一つです。
・一般に、開発に従事している組織や個人は、ある開発が終ると次の開発に早く取り組みたいという動機を有していたり圧力にさらされたりしている場合が多いので、オペレーションの情況を把握することが中々実現しないのが現実で、これが上記の失敗に拍車をかける一因ともなっていると推測されます。
・PMBOK®6thではプロジェクトの引き渡し（Handover）をもってプロジェクトは終結（Closing）します。そもそも期間限定の組織であることもあり、プロジェクトの成果が供用されてからの知見を、プロジェクト・マネージャーやプロジェクト・ティームにフィードバックするループは、プロジェクト・マネジメントには含まれないことになります。
2.3. PMBOK®7thでこの違和感はどこまで解消されたか？
では、PMBOK®7thでこの違和感はどこまで解消されたかのでしょうか？それを見て行きたいと思います。
両者の関係をマトリックスに整理しました。縦にPMBOK®7thプロジェクト・マネジメントの12原理、横にはPMBOK®6thに対して私が感じていた違和感を配しています。違和感の解消に貢献すると思うところに〇を、条件付きの場合には△を付しました。
個人の印象的な評価では拙いので、判断の根拠として〇△には該当するPMBOK®7thの文章を抜き出して仮訳と判断理由を付しました。大きくは誤っていない心算ですが、こう解釈すべきでないか、そうではないのではないか、というご意見があれば是非お聞かせください。
■解消の方向にありますが、実践知としては補うべき点が沢山あります
先ず結論から述べることにします。
1. 領域を限定することに対する違和感は残念ながら殆ど解消されていません。これは今回の改訂においてプロジェクト・マネジメントの対象領域の見直しがなされている訳ではないので、当然の帰結と言えるでしょう。
2. 従って、PMBOKがプロジェクトの対象として設定している範囲外の事がらについては、別途実践知を整理・構築することが必要です。
3. PMBOKのプロジェクト・マネジメントの領域内での違和感については、ほぼすべてについてその解消につながる記述を見出すことが出来ます。
4. 記述の抽象度が高いので、プロジェクトに携わるプロジェクト・オーナー、プロジェクト・マネージャー、ティーム・メンバーが認識として持つことは重要ですが、これを実践するためには相応の実践知を整備・補完する必要があると考えます（いわば憲法の様なもので、個別法や令・規則が必要です）。
5. PMBOK®6thの10の知識領域の各領域におけるマネジメント上の固有の事項を扱った記述がないという事態に変化はありません。PMBOK®7thが10の知識領域を捨て去っている訳でも踏襲している訳でもないので、当然の帰結と言えるでしょう。
6. しかし、10の知識領域は、例えばコストの様にPredictiveであろうとAdaptiveであろうと重要なマネジメント領域で構成されているので、この領域での実践知の進歩を反映した構成になっていないことは、大変残念に思います。
■違和感とPMBOK®7th の10原理を照らし合わせる
上記結論の判断根拠を示します。下記の文章の番号は、マトリックスの番号に対応していて、マトリックスで提示した〇△の判断根拠を示したものです。（見難い方はクリックして元のスライドを見てください）
英文は、PMBOK®7thからの引用で、ページと仮訳を付しました。
1. 下記の運営を実現しようとすれば、目的・目標が問題点を孕む場合、それに遡及して検討を行うべきである、と言うことになるので、違和感を解消する方向です。
Operating in alignment with the organization, its objectives, strategy, vision, mission, and sustainment of its long-term value/組織、組織の目的、戦略、ビジョン、ミッションおよび長期的価値の維持に沿ったプロジェクトの運営（StandardP25）
2. 下記が実現するためには、プロジェクト・メンバーの動機付けも重視されるし、プロジェクト・マネージャーのリーダーシップも重要になる筈で、人間的側面の重視につながります。
Commitment to and respectful engagement of project team members, including their compensation, access to opportunity and fair treatment/プロジェクト・ティーム・メンバーはプロジェクトへの関与に際して尊重され公正に処遇される（StandardP25）
3. 下記の考え方からは、プロジェクト・オーナーの内部で意見の不一致がある場合には、相互理解を経て共通目的へと到達するための行動をとることが求められることになると思われます。
In the project management context, this duty often requires stewards to challenge team members, peers, and other stakeholders to consider their words and actions; and to be empathetic, self-reflective, and open to feedback./誠実性という文脈では、プロジェクト・マネージャーには、ティーム・メンバーや同僚、その他のステイクホルダーに対して、自分の言葉や行動を考えるように促し、共感し、自分を省みて、フィードバックを受け入れる様に仕向けることが求められます。（StandardP26）
4. 協働するティーム環境を醸成する上で、メンバーの動機付けやプロジェクト・マネージャーのリーダーシップが重要なことは自明と言え、人間的側面の重視につながります。
5. 下記に基づいて、ユーザーやオペレータ―をティームに取り込むことによって、運営の視点をより明確に取り入れることが可能となりますが、供用後のフィードバックではないので△としました。
A diverse project team can enrich the project environment…can be comprised of internal organizational staff…./ティーム・メンバーの多様性がプロジェクト環境を豊かにする…例えば組織内部のスタッフなど。（StandardP30）
6. 下記は、オーナー内部の不一致の解消そのものに言及しています。
Communication is a key part of engagement; however, engagement delves deeper to include awareness of the ideas of others, assimilation of other perspectives, and collective shaping of a shared solution. /コミュニケーションは関与の重要な要素ですが、関与はさらに深く、他者の考えを認識し、他者の視点を吸収し、共有された解決策を集団で形成することを含みます。（StandardP33）
7. 下記からすれば、プロジェクト実施側に提供された戦略や便益などの情報が不十分であったり整合しなかったりする場合には、オーナー側には再考が求められることになります。
Together, the business need, project justification, and business strategy, in addition to benefits and possible agreements, provide the project team with information that allows them to make informed decisions to meet or exceed the intended business value. /ビジネス上の要望、プロジェクトの正当性、ビジネス戦略に加え、便益や考えられる合意事項などをまとめて、プロジェクト・ティームに情報提供することで、意図したビジネス価値を満たす、あるいはそれ以上の決定を下すことができます。（StandardP35）
8. プロジェクトの望まれる成果そのものがプロジェクトを通じて発展していく訳ですから、出発時点で不確定性をもっていることが当然となります。
Desired outcomes should be clearly described, iteratively assessed, and updated throughout the project. /プロジェクトの望まれる成果は、プロジェクト全期間を通して明確され、反復的に評価され、更新されるべきである。（StandardP35）
9. 大きな変化が起こることを前提とすべきであるとしているので、出発時点で詳細な業務計画を策定することは意味がない、との結論となります。
With systems thinking, including constant attention to internal and external conditions, the project team can navigate a wide spectrum of changes and impacts to keep the project in agreement with the relevant stakeholders. /内部および外部の状況に常に注意を払うことを含めたシステム思考により、プロジェクト・ティームは、広い範囲に及ぶ変化や影響に上手く対応し、関連するステイクホルダーとの合意を維持することができます。（StandardP38）
10. プロジェクト・マネージャーにはリーダーシップが要求されることが、付随的な条件ではなく、根本的な条件として明示されています。
Authority alone is insufficient. It takes leadership to motivate a group toward a common goal, influence them to align their individual interests in favor of collective effort, and achieve success as a project team rather than as individuals ./権限だけでは不十分です。共通目標に向かって集団を動機づけ、個人の利益を一致させて集団的な努力をするように促し、個人ではなくプロジェクト・ティームとして成功を収めるには、リーダーシップが必要です。（StandardP41）
11. アプローチを事前確定させるのではなく、プロジェクトの進捗に伴う追加情報によってその都度検討することを推奨しています。
Tailoring the approach is iterative, and therefore is a continuous process throughout the project. /アプローチをあつらえることは反復的に行われるため、プロジェクトを通じて継続的に行われます。
12. PMBOK®6thの10のマネジメント領域の中で、Qualityのみが12の原理の一つとして取り上げられました。品質の概念が、プロジェクトの成果だけではなくプロセスにも拡張されたのが特徴ですが、成果の品質をマネジメントする上での固有の事項に焦点が当てられている訳ではないので、△としました。
Project quality entails ensuring project processes are appropriate and as effective as possible. /プロジェクト品質とは、プロジェクトのプロセスが適切であり、可能な限り効果的であることを意味します。（StandardP47）
13. 複雑性をもたらす要因の一つとして曖昧性が取り上げられています。曖昧性は、多義的つまり人によって解釈が異なる状況を意味しており、プロジェクトの出発時点で、目的や目標が帯びている曖昧性を明確にすることが重要となります。
Ambiguity is a state of being unclear, of not knowing what to expect or how to comprehend a situation. /曖昧性とは、何を期待していいのか、どう理解していいのか分からない状態のことです。（StandardP51）
14. プロジェクトに携わった人の当然の実感だと思うのですが、プロジェクトの当初に成果物を事前確定することが適切であるとは限らず、プロジェクトの進行に伴って成果の内実が豊かとなり、課題解決につながることを述べています。
A project rarely performs exactly as initially planned.… Envisioning outcomes rather than deliverables can enable solutions, harnessing a better result than the one originally planned. /プロジェクトが当初の計画通りに進行することは殆どありません。…成果物ではなく、成果物がもたらす成果を構想することで、当初の計画よりも良い結果を得ることができ、解決につながります。（StandardP56）
15. プロジェクト・オーナー内部での不一致の原因の一つが、プロジェクトがもたらす変化に対する評価の違いにある場合が多いと思われますが、この場合自覚的にChange managementを行うことが有効になります。
Stakeholder engagement and motivational approaches assist in change adoption. /ステイクホルダーを関与させることや動機付けを重視するアプローチは、変化への抵抗を抑え変化が受け入れられることにつながります。（StandardP58）
3. PMBOK®7thの先へ
2では違和感を個々に検討して、プロジェクト・マネジメントの実践知としての有効性を高めるためには、次の3点が必要ではないか、と提案しました。
① PBBOKがプロジェクトの対象として設定している範囲外の事がらについては、別途実践知を整理・構築することが必要です。
② 記述の抽象度が高いので、プロジェクトに携わるプロジェクト・オーナー、プロジェクト・マネージャー、ティーム・メンバーが認識として持つことは重要ですが、これを実践するためには相応の実践知を整備・補完する必要があると考えます（いわば憲法の様なもので、個別法や令・規則が必要です）。
③ PMBOK®6thの10の知識領域は、例えばコストの様にPredictiveであろうとAdaptiveであろうと最重要のマネジメント対象で構成されているのであり、この領域での実践知の進歩を反映した構成になっていないことは、大変残念に思います。
初読から4週間の経過の中で違和感を反芻しているうちに、以下の思いが強くなりました。
PMBOK®7thの志向性とした採用された「価値に焦点を当てる」と、プロジェクト・マネジメントの対象領域を限定することの間には矛盾があるのではないだろうか？
つまり、
・プロジェクト・マネージャーが目的や目標の設定に関わったりそれらを吟味してプロジェクト・オーナーにフィードバックしたりする機会がないまま、
・目的・目標を所与として要求事項の抽出からプロジェクトを開始して、価値の創出に焦点を当てる
のでは、プロジェクトを通じての価値創出が十分にできない場合があり、これがPMBOKに対して感じる違和感の最大の要因ではないかと思うに至った訳です。
そこで、ここでは①（プロジェクト・マネジメントの領域限定）の解決策として、以下を提案したいと思います。
・プロジェクト・デザインでプロジェクトの発意・形成と実行をつなぎます
・プロジェクト・マネジメントの領域は、「プロジェクト・デザイン＋従来の領域」で構成されます
なお、②③については、TGSのテキスト改訂のためにドラフト「変革の時代の組織リテラシー」の中で展開中ですので、関心のある方はそちらを参照して下さい。
3.1. プロジェクトの目的は所与でない
このテーマについては、既に「変革の時代の組織リテラシー」で以下のスライドを提示しているところです。
このnoteでは、接点の相互浸透をプロジェクト・デザインとして捉え直し、もう少し中身に踏み込んだ体系的なアプローチを提案したいと思います。
3.2. プロジェクト・デザインに関するILOの提案 RBM：RESULTS-BASED MANAGEMENT
プロジェクト・デザインという言葉は、余り日本では普及していないようですが、海外では国連などの国際機関が海外援助プロジェクトを企画し実行する際の基本原理として1990年代に提唱されたRBM：RESULTS-BASED MANAGEMENTに淵源がある様に思われます。
因みに、RBMは次のように定義されています。
RBM is a management strategy by which all actors, contributing directly or indirectly to achieving a set of results, ensure that their processes, products and services contribute to the achievement of desired results (outputs, outcomes and higher level goals or impact).
RBMとは、ある結果の達成に直接または間接的に貢献するすべてのアクターが、そのプロセス、製品、サービスが望ましい結果（アウトプット、アウトカム、より高いレベルの目標またはインパクト）の達成に貢献することを確実にするためのマネジメント戦略です。
https://unsdg.un.org/sites/default/files/UNDG-RBM-Handbook-2012.pdf
ここでは、国際機関の一つであるILOが発行しているProject Design Manualを参照することにします。https://www.ilo.org/global/topics/cooperatives/publications/WCMS_159819/lang--en/index.htm
■ILOが提案するプロジェクト・デザインのステップ
下図は、同書からプロジェクト・デザインのステップを説明した図の引用ですが、その4ステップを訳出して、図の左に書き加えました。
（見難い方はクリックして元のスライドを見てください）
①プロジェクトの同定（Identification）
どの様なプロジェクトを行うべきかを明確にするプロジェクトの同定が最初のステップです。そこでは、関連するステイクホルダーを洗い出し関心事や計画上の考慮事項を分析し、問題分析を経て、問題を解決するための目標分析へと進みます。
そして代替案を検討し、望ましい案を選択します。
② プロジェクトの形成（Formation: the logical framework）
次にロジカル・フレームワークを用いて、中期・短期の目標、成果、成果を獲得するための行動を明らかにするとともに、置かれた仮定の分析や進捗指標の設定を行います。
③ プロジェクト実行計画策定（Implementation Planning）
ロジカル・フレームに基づいて、業務分割構成、業務分担、スケジュール、予算からなるプロジェクト実行計画を策定します。
④ モニタリング・評価計画策定（Planning Monitoring and Evaluation）
プロジェクトの進捗をチェックし評価するためのM&E計画を策定します。
■PMBOKのプロジェクト・ライフサイクルと比較する
PMBOKのプロジェクト・ライフサイクルでは、①②は前プロジェクト業務（Pre-project work）となり、プロジェクトは③から始まることになるので、プロジェクト・デザインは前プロジェクト業務とプロジェクトの初期段階をカバーすることになります。下図で確認して下さい。
（見難い方はクリックして元のスライドを見てください）
■適応型（Adaptive）では違うのではないか？
上図はPMBOK®6thなので事前確定型（Predictive）のライフサイクルではないか、と疑問を持たれる方もおられると思います。そこで、PMBOK®7thの適応型についても念のために見ておくことにします。
下図は、適応型のプロジェクト・ライフサイクルをPMBOK®7thから引用したものです。
ここでテーマとしているプロジェクト・デザインは、下図で言えば「プロジェクトの定義と成果ビジョンの策定Define Project and Product Vison」が主で、一部がイテレーションの後のバックログの優先順位の見直し当たると言えます。問題は、プロジェクトの定義と成果ビジョンの策定にプロジェクト・マネージャーが参加するかどうかですが、以下のPMBOK®7thの引用から、プロジェクトは要求事項の抽出・設定から始まる様に思われます。
適応型が適しているのは要求事項が基本的なレベルで不確定で流動的で,プロジェクトを通じて変更が見込まれる場合（requirements are subject to a high level of uncertainty and volatility and are likely to change throughout the project Section2 P38）
プロジェクトの開始時点では明確なビジョンが設定され、当初設定された要求事項が、ユーザーのフィードバックによって洗練、詳細化、修正、置換される（A clear vison is established at the start of the project, and the initial known requirements are refined, detailed, changed, or replaced in accordance with user feedback Section2 P38）
3.3. プロジェクト前段に関するPMIレポートThe Front End
今度は、PMIが2019年に発行したプロジェクト前段（The Front End）に関する委託研究レポートを見ることにしましょう。Front Endとはあまり聞かない言葉ですが、Front前半部分の端部Endと言うことで、取敢えず前段と訳すことにしました。
このレポートは、PMIが英国とノルウェーの大学教授に委託し、2006年から2017年の間に20の学術雑誌に発表されたプロジェクトの前段に関する検討を含む研究論文を系統的にレビューした成果です。
https://discovery.ucl.ac.uk/id/eprint/10093094/1/112112_A%20Systematic%20Literature%20Review_2P_TT_KS%20-%20AE.pdf
■プロジェクトの前段（The Front End）とは
では、プロジェクトの前段（The Front End）とは何でしょうか？
これはプロジェクトをどの様に定義するかで変わってくる訳ですが、このレポートでは行動を担う組織と関係付けて下図の様に設定しています。PMIの白書ですので、PMIもこの区分に同意しているものと思われます。
① プロジェクト前段（The Front End）はプロジェクトを発意して形成する段階で、通常プロジェクトの実行を決定しプロジェクトの資金を提供する企業、政府などの恒久的組織によって担われます。
② これに続くのがプロジェクトの実行（The Project）で、プロジェクトを実行する期間限定組織つまりプロジェクト・ティームによって担われます。PMBOKのプロジェクト・マネジメントが対象としている部分です。
③ プロジェクトの成果が恒久的組織によって活用される通常業務（Business as Usual）がこれに続くことになります。
■プロジェクトの前段（The Front End）では何が行われるのか？
では、プロジェクトの前段では何が行われるのでしょうか？同レポートは、下図に引用した様に4つの範疇にまとめています。
① プロジェクトの目的を打立てる
ニーズ、問題、ステイクホルダーの分析を行った上で、組織戦略におけるプロジェクトの位置付けを明らかにし、プロジェクトの成功評価指標を設定します。
② コンセプトに基づき代替案を選択する
脅威と機会を分析した上でプロジェクトのコンセプトを定め、これを実現するためのプロジェクト代替案を比較評価します。
③ 選択された案を様々な角度で検討する
選択された代替案を対象に、費用便益分析、技術アセスメント、環境アセスメント、リスク分析など様々な分析を行います。基本的なプロジェクト実施方式もここで設定します。
④ プロジェクトの実行を準備する
プロジェクトの実施に向けて、ファイナンス、契約や調達方式、プロジェクト実行にけるガバナンスを検討し、プロジェクトで行う業務の範囲、予算、実施期間など実行計画の根幹事項を定めます。
表現や括り方、実行計画をどこまで詳細に詰めるかなどの相違はあるものの、ここでいうプロジェクト前段（The Front End）は、ILOのプロジェクト・デザインとほぼ重なるものです。
（見難い方はクリックして元のスライドを見てください）
3.4. プロジェクト・デザインの提案
プロジェクト・デザインの先行提案やプロジェクト前段に関する分析も考慮し、プロジェクト・デザインとして下図を提案したいと思います。
（見難い方はクリックして元のスライドを見てください）
① プロジェクト・デザインはプロジェクトの発意とプロジェクトの実施を繋ぐ役割を果たします。
②プロジェクト・マネージャーはプロジェクト・デザインから参加し、主導的な役割を果たします。
プロジェクト・デザインは以下の手順で進みます。
③ 先ず、発意を受けてプロジェクト形成を行います。
このため、以下の問いに答える必要があります。
・対象とするステイクホルダーは誰か？どの様な関心事や問題を有しているか？
・ステイクホルダーの直面する問題を解決するためにはどの様な課題の解決が求められるか？
・ステイクホルダーの多面的な関心事や課題解決を組合せてプロジェクト化するために、どの様な目的を創案・形成すれば良いか？
・目的を実現するプロジェクトのコンセプトとしてどの様な代替案があるか？
・費用や収入などから見た実行可能性や、考えられるリスクは？
④実行案を選択し、実行体制を検討の上、プロジェクトの目論見書を作成します。
これに基づき、プロジェクトを実施するかどうか、の意思決定が行われます。
④ 実施が決定されると、目論見を実行へと具体化するため、プロジェクトの目標・要求・制約をつめていきます。
プロジェクト・ブリーフの作成です。
重要なことは、ブリーフ作成によってプロジェクトを実施する動機が再確認され掘り下げること、目標の設定や要求の分析を通じてプロジェクトの成果やプロジェクトがもたらす価値に対するイメージが具体化され、プロジェクト・メンバーによって共有されることです。
仕事上の友人や研究上の友人から、PMBOK®7thについてコメントを出すべきだと言われ、現在改訂中のTGSテキストの最後でまとめようと思っていたプロジェクトの初動期マネジメントの一部を先取りしてアップすることにしました。
ここで提案していることを実例として提示しないと机上の空論となってしまいますので、別途作成しようと思っています。
また、PMBOK®6thの10の知識領域は、コミュニケーション・マネジメントやステイクホルダー・マネジメントの様に、それ自体を取り上げて何がマネジメントの焦点となるのか？を検討すべき領域があると思っています。
目標・要求のマネジメント、品質マネジメントについては既に取り上げてきましたが、今後次の領域を扱っていきたいと思っています。
・コスト・マネジメント
・モティベーション・マネジメント、チェンジ・マネジメント
・プロジェクト・マネージャーに求められるリーダーシップ
・コミュニケーション・マネジメント
・ステイクホルダー・マネジメント
・初動期のマネジメント
この記事が気に入ったらサポートをしてみませんか？