再エネにおける プロジェクトマネジメント

PMBOK

米国にはProject Management Institute（PMI）という団体があり、日本にもその支部があります。世界最大の プロジェクトマネジメント 団体であり、「 プロジェクトマネジメント 知識体系ガイド」（Project Management Body of Knowledge；PMBOK）なるものが標準書として発行されています。2021年末には第7版が発行され、その標準書も大きく変更、ITや製品開発で使われているAgileという思想を強く取り入れる予定となっています。第6版までは、Waterfall型といわれる旧来の大型プロジェクトを強く意識したものとなっています。

このPMBOKは、 プロジェクトマネジメント のフレームワークであり、プロジェクトに考慮すべき要素がもれなく記載されているので、プロジェクトに携わる人には参考になるかと思います。日本では、こうしたノウハウを暗黙知として個人や組織に蓄積されますが、ハイ・コンテクストな文化である日本において成り立つといえます。一方、ロー・コンテクストな文化の欧米は、こうした知見を徹底的に文書化、標準化して蓄積します。日本人だけではなく、海外の企業と一緒に仕事をする場合は、この視点から文書化していくことが重要だといえます。

ただPMBOKの内容は、フレームワークであるため、これだけ読んでもプロジェクトに直接適用するのが難しいです。そこで、このフレームワークに沿って、グリーンフィールド（プロジェクトの企画から終了まで一から進めるプロジェクト、これに対してM&Aのような事業をブランフィールドと呼んでいます）での再エネ開発事業の進め方を考えていきたいと思います。

プロジェクトマネジメント における段階、手順及び知識体系

プロジェクト期間における各段階

プロジェクト期間（Project Life Cycle）には、各段階/フェーズ（Phase:PS）があり、そのたびに、判断が求められます（Phase Gate:PG）。これを再エネ事業プロジェクトで考えると、図１のようになります。各矢印がフェーズを表し、矢印の先端で判断がなされます。ただ、スクリーニング、つまりプロジェクトの選択自体は プロジェクトマネジメント の前段階の位置づけですので、スクリーニングプロセスは別の記事で記載したいと思います。

また、図１の矢印の中には更に小さい矢印があり、その小さな矢印にもまた判断があることになります。図２は主要契約協議フェーズを分解したものです。一般に判断ポイントは、契約的に拘束される、資金を出資するタイミングといえるかと思います。

更に小さく分解していくには、業務内容（Work Breakdown Structure:WBS）を作成し、各々の工程に中間管理点（Milestone）を設定して工程を管理していくことになります。

プロジェクト管理手順

各フェーズには、実施すべき管理手順（Project Management Process）があり、これを各フェーズで繰り返して、プロジェクトを進めていくことになります。いわゆるPDCAですね。PMBOKにおいては、図３のように５つに分けています。

①事前準備（Initiating）、②計画（Planning）、③実施（Executing）、④監視・制御（Monitoring and Controlling）、⑤終了（Closing）で、後半４つはPDCAですね。実際業務で意識せずにやっていたり、PCDAとして進めていたりするので、改めて言うほどのことではないと感じるかもしれませんが、これを プロジェクトマネジメント として標準化したものがPMBOKです。

プロジェクト管理の知識体系

図１から図３に、プロジェクト期間における各フェーズと管理手順を示しております。まとめますと、下記の通りです。

更にこの管理手順において、１０の知識体系（Knowledge Area）をもとに業務標準を定めていきます。どのフェーズでもこの業務標準を使うわけではありませんが、WBSに基づいて、Work Packageが作成されれば、この業務標準に従って、業務を進めます。業務標準と各手順の関係は図５の通りです。

以上のように、各フェーズ（Project Phase）において、意思決定を行うために（Project Gate）、業務標準（図５）に沿ってプロジェクトを進めていくということになります。

業務標準のうち、記載すべき項目をチェックリスト化したものとして、Rita Mulcahy氏が、Rita’s Process Chartなるものを提案しています。チェック項目は、各Knowledge Areaで共通でする部分と共通しない部分があり、Knowledge Areaによって、記載すべき項目を使い分けるというものです。各業務標準の記載項目と思ってもらえるといいかと思います。

Rita氏は、Project Management Professional（PMP）試験のためのテキストを発行しています。英語版しかありませんし、600ページぐらいありますが、PMPの資格取得には非常に参考になりますし、またPMBOKよりもわかりやすくPMBOKについて解説されているので、おすすめです。

統合管理（Integration Management）

統合管理って何？

プロジェクトマネジメント の知識体系のうち、統合管理（Integration Management）は、プロジェクト全体に関する管理方法ともいえ、プロジェクトマネジャー（”PM”）の主たる業務といえると思います。つまり、チームメンバー、専門家やアドバイザーの出してきた成果を統合して、その知見をプロジェクトに反映させていくというものです。 プロジェクトマネジメント そのものですね。各フェーズ、各手順、各知識体系は相互に関連しており、ある特定分野だけに集中していてはプロジェクトを進めることができません。再エネ事業、例えば水力発電でいえば、水車構造だけ理解していても、発電所を建設することはできません。山を削り、発電所の基礎をつくり、発電所の建屋を作り、水車を組み込み、コンクリートを打って、機器を設置し、完成検査を行い、運用を始めるというように、技術に関してだけでも、土木・電気・機械・建築の知識がなければ、予定工期で工事は終わりません。つまり、全分野を広く理解し、特定の分野では専門性が高く、各専門家の知識を理解し、統合していけるような人材（T字型人材）でなければ、PMはできません。海外では プロジェクトマネジメント 自体が専門分野となっているぐらいです。こうした意味で、各部品（専門部分）を組み立てて製品（プロジェクト）に仕立てるプロセス全体の管理が、この統合管理となります。

統合管理で行う内容は以下の通りとなります（（）内の番号は、Project Management Processの番号）。

• プロジェクト憲章（Project Charter）を作成する（①）
• プロジェクト管理計画を作成する（②）
• プロジェクト業務を監督・管理する（③）
• プロジェクト知見を管理する（③）
• プロジェクト業務を監視・制御する（④）
• 変更の組み込みを行う（④）
• プロジェクトもしくはフェーズを完了する（⑤）

プロジェクト憲章

プロジェクト憲章とは、関係者が共通認識を持つために作成されたプロジェクトの概要書だと実務的には考えればよいかと思います。本来の定義では、Chater、プロジェクトの設立許可書ということになりますが、どの会社でもプロジェクトを実施する際には、何らかの概要書は作成すると思います。それを、必ず作るようにしましょうという趣旨です。

PMBOKでは、一般的な書くべき項目が記載されていますが、プロジェクト管理計画を意識して項目だしをすればいいかと思います。更に、他の企業と協業してプロジェクトを実施する場合、Minutes of Understanding（覚書）やCoorperation Agreement（協業協定書）などの契約書の作成にも役立ちます。

そうした観点から、下記の項目を書くのを推奨します（PMBOKで書かれている言葉となります）。

• プロジェクトの名前と事業内容（project title and Description）
• プロジェクトを実施する背景（Business Case）
• プロジェクトの（具体的な）目標（Measureable Project Objectives）
• プロジェクトマネジャー
• プロジェクトの組織（Resources Pre-assigned）
• プロジェクト関係者リスト
• 成果物（High -Level Product Description/ Key Deliverables）
• 概略予算
• 予定工期及びマイルストーン
• リスク（Overall Project Risk）
• 撤退条件（Project Exit Criteria）
• （権限者による）承認項目（Project Approval Requirements）

プロジェクト管理計画

プロジェクト管理計画（Project Management Plan）というのは、プロジェクトを進めるにあたっての方針や手続きであり、知識体系に沿った視点で計画を立てるというものです。企業レベルでいえば、社内標準約款にあたるものです。ここではプロジェクトごとでも作っておくべきという考え方に基づいたものです。ISOを導入している会社で、建設に関わる企業では、建設工事のプロセスの多くが標準化されており、プロジェクト（建設工事）毎に、管理計画が立案されているものと考えます。

一方、再エネ開発のような電源開発プロジェクトでは、テーラーメイドであるがゆえに、十分な標準化が進んでおらず、プロジェクトごとに進め方が異なるというのはよくあることではないでしょうか。

しかしながら、できるだけ、進め方の手順や意思決定基準などを決めておけば、事象が生じたときにスムースに進むでしょという考え方です。いちいちえらい人に伺いを立てるか、十分な権限を有した人をPMに任命するかのいづれかですね。日本企業の多くが、こうした点をあいまいにしつつプロジェクトを進めるので、意思決定が遅い、プロジェクトを進めるのが遅いといわれる所以かもしれません（権限者の多くは忙しく、いちいち一つ一つの案件を判断することできないです。）。

• プロジェクト工期（Project Life Cycle）：各フェーズを規定します。
• 経営照査（Manamgement Review）：プロジェクトの進捗を経営層や関係者に報告するものです。プロジェクト組織に関係経営層を入れて、定期的にプロジェクトの状況報告がなされるようにする場合もあります。
• 各管理計画（Knowledge Area Management Plan）：各知識体系に沿って作成するより具体的な管理計画です。主なところでいえば、費用管理計画や工程管理計画などです。必ずしも、Knowledge Areaに示されている計画は必要ではなく、各フェーズごとに、その重要さは変わってきます。
• 基準値（Baselines/ Performance Measurement Baselines）：プロジェクトを始めるにあたっての基準値です。これを基に進捗や成果、撤退などを決めていきます。主に必要なものは、事業内容、工程、予算になります。

その他、Development Approach、Requirements Management Plan、Change Management Plan、Change Control System、Configuration Management Plan、Configuration Management Systemなどが反映すべき項目としてPMBOKには挙げられています。

また管理計画とは別に、プロジェクト関連文書（Project Documents）もこの段階で収集しておくことは重要となります。管理計画には記載しなくとも、参照すべき文書や図書などは多数あります。最も参考にすべきは類似プロジェクトの情報であり、失敗事例などはリスク管理に非常に役立ちます。こういった情報を初期の段階で収集しておくことは、プロジェクトの成功のカギになります。

更にプロジェクトの実施中に得られる記録類も、Project Documentsとして蓄積していいきます。つまり、管理計画が主要文書であり、Project Documentsは参照文章・データの位置づけとなります。

プロジェクト業務の監督・管理

難しく書いていますが、いわゆるPMの本来業務である関係者間の調整業務です。プロジェクト管理計画にそって、その計画通りにプロジェクトを進めていくことを指しています。この際に重要なのは、一つの項目ばかりに集中してしまい、全体最適を忘れないようにすることです。

よくPMの時間の9割はコミュニケーションに使うべしとされるのは、この業務をこなすには、ミーティングやツールを使って、関係者間の調整を如何にうまく進めるかがプロジェクト成功のカギになるからです。

例えば、再エネによる発電所はその土地に応じたテーラーメイドな設備を有しており、建設を行う際に地元関係者の理解がなければうまくいきません。土地の収用、苦情の対応、建設や運転のリソース確保など、こう言ったことの調整は、管理計画に沿っているだけではうまく進みません。コミュニケーションを図り、理解を得る努力をしつつ、再度計画に反映していく。つまり、関係者（Stakeholder）から得た要求や情報は、計画書に再度反映していくことは、統合管理の中で行っていくことになります。

プロジェクト知見の管理

プロジェクト実施中に得た知見を蓄積、記録していくこともPMの重要な役割になります。これは次のプロジェクトに利用されるものであり、先ほど挙げましたProject Documentとして使われることになります。

特に失敗から学ぶことは多く、成功よりもむしろ、次のプロジェクトで役立つことが多いですが、チームや会社での信頼構築が欠かせません。

https://renewablenergy-pro.com/2021/01/18/failureimportant/

更に、知見には、分かりやすい知見（Explicit Knowledge）と伝えにくい知見（Tacit Knowledge）があります。

• 分かりやすい知見（Explicit Knowledge）：事実に基づいたものであり、図や文字によって伝えるのが容易な知見。ただし、理解してもらうには説明や文章な場合もある。いわゆる先人からの学び（Lessons to learn）のこと。
• 伝えにくい知見（Tacit Knowledge）：はっきりと述べるのが難しい感情、経験や能力のこと。こうした知見を共有するには、互いに信頼が不可欠。

こうした知見を如何に組織で共有するかがここでの重要課題であり、ここで知見管理（Knowledge Management）や情報管理（Information Management）が出てきます。最近は、様々なコミュニケーション、知識共有、情報共有のソフトが出てきているので、こういったソフトを使って、知見を共有していくかが重要となります。最近私自身は、TeamsやNotionを使って業務を進めることが多くなっています。

プロジェクト業務の監視・制御

プロジェクトを、各計画案通りに進んでいるかどうかを、監視、必要に応じて対応（制御）していきます。ここで重要なのは、例えば予定工期に比べて遅れた場合、休日日数を減らして工事を促進するなど、まずは計画を変えずに対処をする（Corrective Action）です。これに対して、新たな機械を言れるや、予定していた工事をやめるなどは、これには当たらず変更手続き（Change Requests）になるので、その点は注意が必要です。PMBOKでは、この点を強調しており、計画を変更する場合、Change Management Planに従って、Change Requestsを行うように求めています。

建設工事などでは、この手続きをValiation Orderとして定めていることが多く、後々、コントラクターからのクレームの原因であるので、安易な指示は紛争になりかねないので、事前にルールを決め、それに従って、処理を進めることは重要になります。

変更の組み込み

いわゆる計画が決まったのち、実行中において、変更が必要となった場合の手続きです。変更の要求は、前の項で記載しましたが、変更は必ずしも認められるものではなく、変更を詳細に評価したのち、拒否するのか、承認するのかが決定されます。

調達計画に入る建設契約については、この変更手続きが詳細に記載れています。というのも、プロジェクト進行において、最も揉めることが多い部分だからです。クレーム＞紛争＞紛争調整委員会（Dispute Adjudication Board）＞仲裁（Arbitration ）という流れは、できる限り双方の不利益を小さくするための努力です。

変更には2種類あって、一つは管理計画、基準値、方針や手続きなどの変更を伴うもの、二つ目はそうでないものです。建設工事の事例でいけば、Variation orderが予備費の予算の範囲内、かつ権限内であれば、他の承認を求めることなく、変更の実行は可能となります。一方、そうでない場合は、その権限を有する人に承認願いをかけ、承認が下りたのちに実行となります。PMBOKでは、この組織をChange Control Board（CCB）と呼んでいますが、会社であれば、取締役会のことであり、同じような組織はあるかと思います。

プロジェクトもしくはフェーズの完了

公式に成果品を受け入れ、完成証明書の発行を行う手続きとなります。加えて、Lesson to learnや様々な記録を蓄積することもここで行います。

建設工事であれば、このプロセスは完成検査、完成検査書、最終支払い手続き、瑕疵担保期間のスタート、補償の清算など、工事（プロジェクト）を終えるに際して、どのような状態であれば工事完了を認めるのかを詳細に決め、双方異論なく終えれるようにしておく部分となります。

まとめ

ここでは、再エネ事業のプロジェクト工程と プロジェクトマネジメント の概要的な関係について述べました。別の記事において、１０の知識体系に関する記事を述べていきたいと考えています。最後に、表２は、表１のチェックリストのうち、統合計画で記載すべき項目に色付けをしたものです。こうして欧米のプロジェクトでは業務標準が作成されています。