プロジェクト・ガバナンス：チームの進行を妨げない実践的なフレームワーク

『スーパーマリオ』をプレイしたことがある人なら、あの瞬間をご存じでしょう。タイマーが残り少なくなり、同じジャンプを2回も失敗してしまい、もう一度挑戦するか、別のルートを探すかを決めなければならない場面です。決断を下し、その結果を受け入れるのです。

プロジェクトでは、同様の状況に直面することがあります。仕事が遅れた場合、納期を延期したり、追加の人員を雇ったり、範囲を縮小したりといった選択肢があります。しかし、こうした選択は他者の予算やコミットメントに影響を及ぼします。したがって、こうした決定を下すには、実行するための権限も必要です。どの変更を自ら承認でき、どの変更には他者の承認が必要かを把握しておく必要があります。

プロジェクト・ガバナンスのフレームワークは、作業開始前にこうしたルールを定めます。ここでは、チームが変更や承認にどのように対応しているかを実際の例を交えながら、その構築方法をご紹介します。

プロジェクト・ガバナンスとは？

プロジェクトガバナンスとは、承認から完了に至るまで、プロジェクトを組織の目標に沿ったものとして維持するための、役割、意思決定権、および管理措置からなる枠組みのことです。

PMIは、ガバナンスを、プロジェクトのライフサイクル全体にわたり、組織のガバナンスモデルと整合する監督機能として定義しています。簡単に言えば、ガバナンスは方向性と意思決定のルールを設定するものです。プロジェクト管理は、そのルールに基づいた日々の計画立案と実行を担当します。

また、このフレームワークでは、コスト、リスク、期待される便益が変化した際に、プロジェクトへの資金提供を継続する価値が依然としてあるかどうかを誰が検討するかも定義されています。スポンサーは、プロジェクトの期待される便益、コスト、投資の理由を記録したビジネスケースを用いて、条件の変化に伴いプロジェクトを継続することが妥当かどうかを評価します。

許容度に基づくプロジェクトガバナンスはどのように機能するのでしょうか？

許容範囲に基づくガバナンスにより、合意されたリミットの範囲内で仕事やタイムラインを管理する余地が生まれます。合意されたリミットを超える見込みがある場合は、指定された承認担当者にその旨を報告してください。

これらのリミットは特定のプランに適用されます。プロジェクト全体、各フェーズ、および個々の作業パッケージごとに、それぞれ異なるリミットが設定されている場合があります。全体的な予算や納期を守っているからといって、そのフェーズのリミットを超える権限が与えられるわけではありません。

PRINCE2では、このアプローチを 「例外管理（ manage by exception）」と呼んでいます 。ウェブサイトのリニューアルにおいて、これがどのように機能するかを以下に示します：

残りの仕事を並行して進めれば、リリース予定日は守れるかもしれませんが、テストには依然として割り当てられた4週間以上の時間がかかってしまいます。つまり、テストプランを変更するには、依然として運営委員会の承認が必要となります。委員会が修正されたプランとリミットを承認したら、その範囲内で日々の仕事を管理します。

プロジェクト・ガバナンスとプロジェクト管理：その違いとは？

プロジェクトマネージャーとスポンサーは、同じ変更事項を見ていても、それぞれ異なる問題点を指摘することがあります。

マネージャーにとって、引き渡しの遅延は、仕事を完了させるための新たな方法を見つけなければならないことを意味します。スポンサーにとっては、リリース時期の遅れがビジネス上のコストに見合うかどうかを判断しなければならないことを意味するかもしれません。両者とも結果に利害関係がありますが、下す判断は異なります。

複数のプロジェクトにまたがって、プロジェクト管理オフィス（PMO）が共有のレポート作成および承認基準を設定する場合があります。しかし、それによってPMOが資金調達や範囲に関するあらゆる決定権を持つわけではありません。PMOガバナンスフレームワークに関する当社のガイドでは、PMOのより広範な役割について解説しています。

プロジェクト・ガバナンス・フレームワークの構成要素とは？

ハロルド・カーズナーの著書『プロジェクト管理2.0』で述べられているように、プロジェクトガバナンスは組織構造、人材、情報という3つの柱に基づいています。組織構造は報告系統や承認ルートを規定し、人材は役割と意思決定権を担い、情報は意思決定に必要な根拠を提供します。

これらの柱を実践に移すために、PMIのカンファレンス論文では、状況に応じて適応できる8つのガバナンス要素が提案されています。以下のチェックリストは、各要素が何をカバーしているか、および維持すべき記録やプロセスを示しています。

承認に関しては、記録内容が単に仕事の割り当てにとどまっていないか確認してください。RACIマトリックスは成果物に対する責任者を示すことはできますが、追加経費や納期延長を承認できる人物を必ずしも特定するものではありません。その権限を「意思決定権限」として記録し、変更管理プロセスを用いて、申請が承認者にどのように届くかを定義してください。

また、リスクと問題を区別する必要があります。リスクは「発生する可能性があるもの」であり、問題は「すでに存在しているもの」です。サプライヤーによる納期の遅延の可能性はリスクです。納期の遅れは、対応が必要な問題です。これらをリスク登録簿のテンプレートや問題ログで追跡するか、カテゴリや所有者を個別に管理できるRAIDログを活用しましょう。

プロジェクト・ガバナンスの責任者は誰か？

通常、プロジェクトスポンサーはビジネスケースの責任者であり、プロジェクトの価値について最終的な説明責任を負います。プロジェクトマネージャーは合意されたリミット内で成果を納め、必要に応じて運営委員会やPMOが監督を行います。

必要な役割は、プロジェクトの複雑さやリスクによって異なります。小規模なプロジェクトであれば、スポンサーとプロジェクトマネージャーだけで十分な場合もあります。複数の部門にまたがる仕事では、優先度の競合を解決し、大きな変更を審査するために、運営委員会が必要になることもあります。

運営委員会に要請を送る前に、その委員会が変更を承認できるのか、それとも単に推奨するだけなのかを確認してください。例えば、データ品質の問題を解決するために3万ドルの追加予算が必要だと仮定した場合、委員会はその追加予算を支持するかもしれませんが、最終的な支出決定権はCFOにあります。その場合、資金をコミットする前に、やはりCFOの承認を得る必要があります。

プロジェクト憲章やガバナンスプランに、これらの境界線を明記し、未解決の意見の相違について最終決定を下す場所も明記してください。緊急の要請については、その決定権限がデリゲート済みで、承認権限も持つバックアップ承認者を指名してください。

6つのステップでプロジェクトガバナンスのフレームワークを構築する方法

まずプロジェクト憲章と承認済みのプランから始め、以下のステップに従って、実施段階で遵守すべきルールを定義しましょう。

ステップ1：承認が必要となる可能性のある決定事項を特定する

プロジェクトの資金調達、範囲、成果物の提供、または期待される便益に影響を与える可能性のある決定事項をリストアップしてください。次のフェーズを開始する許可など、計画された承認事項や、ビジネスケースの変更時に継続するかどうかといった、変更によって引き起こされる決定事項も含めます。

各決定について、以下の点を記録してください：

日常的なタスクの選択は、その仕事を管理している担当者に任せてください。

ステップ2：コスト、スケジュール、スコープ、リスクの許容範囲を設定する

許容範囲とは、既存の権限の範囲内で、結果が承認されたプランからどの程度逸脱してよいかを定義するものです。仕事を開始する前に、スポンサーや統括機関とこれらのリミットについて合意しておきましょう。

あなたのプロジェクトの承認済み予算は420,000ドルです。スポンサーはコスト許容範囲を5％に設定し、21,000ドルの追加支出を承認したため、支出リミットは441,000ドルとなりました。440,000ドルという予測額は、承認されたリミットの範囲内です。予測額が448,000ドルに上昇した場合は、追加支出を行う前にスポンサーの承認を得てください。

その他のリミットについても、同様に明確に定義してください：

各許容範囲を、それが対象とするプランと結びつけましょう。リスク管理プランは、リスクの閾値を設定するのに役立ちます。プロジェクトによっては、品質、便益、または持続可能性について、明確なリミットを設ける必要がある場合もあります。

ステップ3：特定の担当者に意思決定権を付与する

意思決定リストに戻り、各アイテムについて承認者を指定してください。次に、提案書を作成する担当者と、意見が必要な担当者を特定してください。

以下の責任を明確に区分してください：

委員会での決定については、合意形成の過程と、その結果を誰が記録するかを文書化してください。また、権限を持つバックアップを指名し、そのバックアップがいつ介入できるかについて明確なルールを定めてください。

ステップ4：エスカレーションの経路と対応時間を定義する

エスカレーションの際は、承認者が判断を下せるよう十分な情報を提供する必要があります。以下の項目を網羅した簡潔な例外レポートを使用してください：

対応期限は、実際にアクションを起こす必要がある時期に合わせて設定しましょう。例えば、サプライヤーが金曜日に回答を必要としている場合、木曜日までに承認を求めることで、決定内容を実行するための時間を確保できます。

さらに、期限に間に合わなかった場合の対応も決めておきましょう。次の担当者を指定し、影響を受ける仕事を一時停止する必要があるかどうかも明記してください。これらのエスカレーションマトリックステンプレートは、プロジェクトの承認プロセスに合わせて調整できる基本レイアウトを提供します。

ステップ5：保留中の決定事項を簡単に見つけられるようにする

承認担当者が、自身の対応を待つリクエストを共有して把握できる仕組みを整えましょう。各エントリーには、決定が必要な事項、担当責任者、および期限を明記してください。例外事項については、予測値とリスクにさらされるリミットも記載します。リクエストには裏付けとなる資料がリンクされており、承認担当者が見積もり、影響、および選択肢を確認できるようにしてください。

これらのプロジェクトダッシュボードの例に見られるようなリアルタイムのビューは、条件の変化に応じてリクエストを追跡するのに役立ちます。定期的なステータス報告ではマイルストーンや進捗状況を報告できますが、タスクの更新情報の中に承認リクエストが埋もれてしまわないように注意してください。

ステップ6：決定事項を記録し、フレームワークを見直す

決定がなされた時点で、承認者、日付、検討された選択肢、根拠、およびフォローアップ措置を含め、各決定内容を記録してください。

承認に伴い、予算、スケジュール、またはスコープのベースラインの更新が必要になる場合があります。変更管理を通じてそれらの変更を行い、改訂された記録を決定ログにリンクさせ、影響を受けるすべての関係者に、今後どのプランに基づいて仕事を進めるかを伝えてください。

各フェーズのレビューにおいて、そのフレームワークがタイムリーな意思決定に役立ったかどうかを評価してください：

その回答をもとに、フレームワークへの変更案を提案してください。許容範囲や意思決定権限の改定についても承認が必要です。合意が得られたら、次のフェーズが始まる前に、コミュニケーションプランを通じて共有してください。

あなたのプロジェクトには、どの程度のガバナンスが必要でしょうか？

この6つのステップはあらゆるプロジェクトに適用できますが、監督のレベルは、そのプロジェクトのコスト、リスク、依存関係、および誤った決定がもたらす結果に見合ったものでなければなりません。PRINCE2では、これを「プロジェクトに合わせて調整する（tailor to suit the project）」と呼んでいます。

例えば、1つのチームによるパイロットプロジェクトであれば、スポンサーと明確な承認ルートさえあれば十分かもしれません。しかし、支払いデータの取り扱いが始まるようになれば、チームのサイズが変わっていなくても、正式なセキュリティレビューが必要になる可能性があります。

以下の表は、セットアップを決定する際の出発点となります。サイズについては、チームの人数やプロジェクト期間に基づく固定的なルールではなく、あくまで例として捉えてください。

意思決定者が行動するために十分な情報と権限を得られる、最もシンプルなセットアップを目指しましょう。その選択内容をプロジェクト憲章に明記し、スコープやリスクに変化があった場合は見直してください。

プロジェクト・ガバナンスの実践：マンチェスター大学のCRM導入事例

マンチェスター大学のグラフェン・エンジニアリング・イノベーション・センターでは、問い合わせの追跡や顧客のオンボーディング管理を行うためのCRMが必要でした。CEOがプロジェクトを立ち上げ、事業開発担当ディレクターがプロジェクト委員会を率い、プロジェクトマネージャーのネイサン・ラムが実施を管理しました。

チームは、ソフトウェアのコスト上限をユーザー1人あたり月額20ポンドと設定し、最大50人のユーザーに対するサポートを必要としていました。公開されたケーススタディでは、承認プロセスやフェーズごとのレビューが仕事にどのような影響を与えたかが説明されています：

監督に確固たる根拠が必要な場合：クロスレール

クロスレイルの事例からは、別のガバナンス上の問題が浮き彫りになっています。すなわち、リーダーたちは形式的な監督権限は持っていたものの、現実的な実行プランが欠けていたのです。

英国国家監査院（NAO）の2019年の報告書によると：

NAOは、追加費用の原因として、過密なスケジュール、契約上の取り決め、そして現実的なプランの欠如を指摘しました。その結論は明快でした。クロスレイルは「当初のスケジュール通りにプロジェクトを完了できるという非現実的な見解に固執していた」のです。

アジャイルチームにおいて、プロジェクトガバナンスはどのように機能するのでしょうか？

アジャイルチームには、学びながら優先度を調整する余地が必要です。ガバナンスは、チームがそうした選択を行える範囲として、目標、資金、承認のリミットを定義します。

スクラムでは、プロダクトオーナーがプロダクトバックログの優先順位を決定し、開発者は各スプリントで選択された仕事をどのように成果物として提供するかをプランします。スプリントレビューでは、スクラムチームとステークホルダーが成果物を検証し、今後のやることについて話し合います。

こうした議論を通じて、変化するビジネスニーズやプロダクト目標に対するリスクが明らかになることがあります。ただし、スプリントレビューは、追加資金の承認やチームの権限を超える変更の承認に代わるものではありません。

例えば、ユーザーからのフィードバックにより、アプリの決済プロセスが分かりにくいことが判明したとします。プロダクトオーナーは、決済プロセスの改善をバックログの上位に繰り上げることができます。その変更により追加の資金が必要になったり、合意されたリミットを過ぎたりする可能性がある場合は、チームはプロジェクトのガバナンスプロセスを通じて承認を得る必要があります。

プロジェクトガバナンスにおけるよくある間違いとその解決策

承認を得たからといって、必ずしも実行が順調に進むとは限りません。審査担当者は、根拠の不備を見落としたり、ユーザーからの懸念を軽視したり、あるいは見過ごされがちな条件付きで仕事を承認したりする可能性があります。

フレームワークを実践する際には、以下の5つの間違いに注意してください：

ClickUpでプロジェクトガバナンスを運用する方法

予測値が合意されたリミットを超えた場合、スポンサーには単なる警告以上の情報が必要です。予想される影響、選択肢、そして意思決定の期限が求められます。ClickUpを使えば、その依頼を、裏付けとなる証拠や影響を受けるプロジェクトの仕事と併せて管理することができます。

承認ルールを仕事に密着させる

まずは「ClickUp ガバナンスプランテンプレート」から始めましょう。このテンプレートには、「役割と責任」ビューと、承認プロセスに合わせて調整可能な「決定権限」カスタムフィールドが含まれています。

無料テンプレートを入手する

ClickUp Docsを使用して、許容範囲、エスカレーション手順、対応時間を文書化しましょう。プランを承認タスクにリンクさせることで、レビュー担当者は各リクエストの背景にあるルールを確認できるようになります。

例外を承認依頼に変える

それを踏まえて、例外事案に対するワークフローを設定できます。ステップ2の例を応用してみましょう。そこでは、プロジェクトマネージャーが最大441,000ドルの支出を承認できることになっています。

スポンサーに対し、未決定事項の状況を把握できるようにする

継続的な監視には、ClickUpのダッシュボードを活用して情報を一元的に表示できます。「計算」カードを使用して予測コストを表示し、「タスクリスト」カードで承認待ちのタスクをフィルタリングして表示します。所有者、期限、関連するカスタムフィールドも表示することで、スポンサーは各リクエストを開いて詳細を確認できるようになります。

承認された変更が成果物の納期に影響を与える場合、プロジェクトマネージャーは、決定の根拠を損なうことなく、関連するタスクや期日を更新することができます。

小規模なプロジェクトであれば、ガバナンスプランと共有の承認リストだけで十分かもしれません。リクエスト数が増えるにつれて、自動化機能やダッシュボードを追加していきましょう。

ClickUpの料金体系

ClickUpユーザーの声は？

サヴィルズでは、地域ITチームがアジアの14地域にわたるソフトウェアの導入、インフラプロジェクト、およびベンダーからの納品を統括しています。

以前： プロジェクト管理者は各国から進捗情報を収集し、約20件のPowerPointプレゼンテーションをまとめて月次CIOレポートを作成していました。経営陣は、そのレポート作成サイクルを通じて全体像を把握していました。

ClickUpを活用すれば： 共有されたプロジェクト記録は、リアルタイムのCIOダッシュボードに直接反映されます。経営陣は、どのプロジェクトの進捗が良好か、どのプロジェクトに注力すべきかを把握できる一方で、チームはリクエスト、変更、問題に関する同一の記録に基づいて仕事を進めることができます。

その結果： 10名のプロジェクトチームは、タスクに関する議論の中でベンダーからの質問や引き継ぎを処理することで、毎月50時間以上を節約しています。プロジェクトマネージャーは、異なるタイムゾーン間の調整やレポート作成に費やす時間を削減でき、経営陣はポートフォリオの最新状況を把握できるようになりました。

どの程度のガバナンスを導入すべきか？

1つのチームで構成され、意思決定者が明確な、小規模でリスクの低いプロジェクトであれば、基本的な憲章、承認リミット、および意思決定ログがあれば十分かもしれません。別途の運営委員会や詳細なガバナンスプランは必要ありません。

意思決定が部門をまたぐ場合、多額の支出を伴う場合、規制上の義務に影響を与える場合、あるいは多額のコストを伴う遅延を引き起こす可能性がある場合は、より正式なプロジェクト・ガバナンスの枠組みを活用してください。仕事開始前に、承認者を明確にし、エスカレーションの閾値を設定し、レビューのタイミングについて合意しておきましょう。

ClickUp を使えば、承認依頼、裏付けとなる証拠、記録された決定事項をプロジェクトと併せて管理できるため、チームは何が、なぜ承認されたのかを遡って確認できます。

プロジェクト・ガバナンスに関するよくある質問

プロジェクト・ガバナンスとプロジェクト・アシュアランスにはどのような違いがあるのでしょうか？

プロジェクト・ガバナンスは、誰が意思決定を行い、その意思決定者にどのような権限があるかを定義します。プロジェクト・アシュアランスは、プラン、報告書、および統制が、それらの意思決定者に信頼できる情報を提供しているかどうかを検証します。例えば、ステアリング委員会が決定を下す前に、独立したアシュアランス・レビューを通じて、プロジェクトが開始できる状態にあるかどうかを評価する場合があります。

プロジェクトガバナンスが効果的であるかどうかを、どのように測定すればよいでしょうか？

承認決定にかかる時間、決定の期限が守られない頻度、および段階レビューで合意されたアクションが期限通りに完了しているかどうかを追跡します。また、必要な承認を得ずに変更が実施される頻度を確認することもできます。プロジェクトの各フェーズにおけるこれらの傾向を分析し、ガバナンスがチームによるタイムリーかつ情報に基づいた意思決定を支援できているかどうかを検証しましょう。

プロジェクトの途中でスポンサーが離脱した場合、どうなるのでしょうか？

組織は、暫定または後任のスポンサーを任命し、その意思決定権限を確認する必要があります。その後、プロジェクトマネージャーは、ビジネスケース、現在のリスク、保留中の承認事項、および資金調達の確約について、そのスポンサーに説明を行います。権限が正式に移譲されるまでは、チームは他の幹部が同じ決定を承認できると想定すべきではありません。

外部ベンダーとの連携において、プロジェクトガバナンスはどのように機能するのでしょうか？

外部ベンダーは、契約の範囲内でリスクの報告、変更の提案、仕事の管理を行うことができます。ただし、合意済みの費用、範囲、または納期に関する変更については、契約に定められた変更管理プロセスおよび組織の承認ルールに従わなければなりません。ベンダーによる仕事開始前に、成果物の受入、契約変更の承認、および紛争の解決を行う権限を持つ者を明確に定義しておきましょう。

プロジェクトのマイルストーンとフェーズゲートの違いは何ですか？

マイルストーンとは、ユーザーテストの完了など、重要なイベントや完了した成果物を指します。ステージゲートとは、権限を持つステークホルダーが証拠を精査し、プロジェクトを継続できるかどうかを決定する判断ポイントです。マイルストーンに到達したからといって、自動的に次のフェーズが承認されるわけではありません。