レッスン3：責任と権限のギャップを設計で埋める

このレッスンで学ぶこと

責任と権限のギャップ（Responsibility-Authority Gap）の構造を理解する
プロジェクト憲章によって権限を明文化する8つの要素を学ぶ
スポンサーから引き出すべき5つの具体的な権限を把握する
RACIをタスク・成果物レベルで設計する方法と、「言質を文書に残す」作法を身につける

前回のレッスンでは、マトリクス組織の構造と、その強度によってプロジェクトリーダーの権限の重さが変わることを学びました。今回は、権限が足りない構造そのものを嘆くのではなく、憲章という仕組みによって権限を設計的に補う方法を扱います。中核メッセージの2つ目「権限は『もらう』ものではなく『設計する』もの」を、具体的な手順に落とし込むレッスンです。

責任と権限のギャップとは何か

組織で仕事をするとき、本来は「与えられた責任の大きさ」と「持っている権限の大きさ」は釣り合っているべきです。責任だけが重く、権限が伴わない状態を「責任と権限のギャップ（Responsibility-Authority Gap）」と呼びます。

プロジェクトリーダーは、このギャップの中でもとりわけ大きな不均衡を抱える立場です。成果物の品質、納期、予算については重い説明責任を負う一方で、レッスン1で確認した通り、メンバーへの人事権はほとんど持ちません。この不均衡を放置したまま走り出すと、うまくいかなかったときに「権限もないのに責任だけ負わされた」という不満が募り、うまくいったとしても次の機会に同じ不均衡が繰り返されます。

💡 ポイント ギャップそのものをゼロにすることは、プロジェクトリーダーという役割の性質上、現実的ではありません。本レッスンの目的は、ギャップを完全に消すことではなく、致命的な支障が出ない範囲まで、意図的に縮める設計を行うことです。

ギャップを放置した場合に何が起きるかを、具体的な場面で考えてみます。あるプロジェクトリーダーが、口頭の説明だけでプロジェクトを立ち上げ、権限の範囲を特に確認しないまま数か月が経過しました。途中で仕様変更の要望が現場から上がり、プロジェクトリーダーは「これくらいなら自分の判断で進めてよいだろう」と考えて対応しましたが、後になってスポンサーから「そのような変更は事前に相談してほしかった」と指摘されました。プロジェクトリーダーからすれば「どこまでが自分の判断でよいのか、誰からも明確に示されていなかった」というのが実感でしたが、スポンサーからすれば「相談もなく進められた」という不満が残りました。

このような行き違いは、どちらか一方が悪いというより、権限の範囲が最初から言語化されていなかったことが根本の原因です。次の項から扱うプロジェクト憲章は、まさにこの行き違いを未然に防ぐための仕組みです。

プロジェクト憲章による権限移譲の明文化

ギャップを縮める最も有効な手段が、プロジェクトの立ち上げ時にスポンサーと合意する「プロジェクト憲章」です。プロジェクト憲章とは、プロジェクトの目的・体制・権限をあらかじめ文書化し、関係者の合意を得ておく文書を指します。

プロジェクト憲章を作る目的は、単なる形式的な手続きではありません。口約束のまま走り出したプロジェクトは、途中で「言った・言わない」の争いが起き、プロジェクトリーダーが不利な立場に置かれがちです。憲章という文書の形で残しておくことで、後になって権限の範囲を確認し合える拠り所ができます。

プロジェクト憲章に盛り込むべき要素は、次の8つです。

1つ目はプロジェクトの目的と達成すべき成果。2つ目は成功の判断基準。3つ目はスコープ（取り組む範囲と取り組まない範囲）。4つ目は体制図とメンバーの所属・稼働率。5つ目はプロジェクトリーダーに委譲される権限の一覧。6つ目は予算の枠と執行の承認ルート。7つ目はスケジュールの主要な区切り。8つ目はエスカレーション先と対応の目安期間です。

実際の記載イメージを、簡略化した例で示します。ある業務システム刷新プロジェクトの憲章の一部を抜粋すると、次のようになります。

項目	記載例
目的と成果	老朽化した受注管理システムを刷新し、入力作業の所要時間を半減させる
成功の判断基準	新システムへの移行完了、主要業務での入力時間の半減を検証データで確認する
委譲される権限	10万円までの外部発注をプロジェクトリーダーの判断で執行可能。要員の交代提案権を持つ
エスカレーション先	重大な仕様変更・予算超過はスポンサー（営業本部長）に48時間以内に報告する

このように、抽象的な「権限を持つ」という言葉ではなく、金額や時間といった具体的な数字で線引きしておくことが、後々の解釈のずれを防ぎます。「権限がある」「ない」という二択ではなく、「どこまでなら」「どのくらいの時間内なら」という程度の問題として書き込むことが、憲章を実務で使えるものにする鍵になります。

📝 補足 このうち5つ目「委譲される権限の一覧」が、本レッスンの主題です。目的やスコープは多くの現場ですでに整理されていますが、権限の一覧まで明文化しているプロジェクトは意外に少ないのが実情です。ここを丁寧に詰めることが、後続のレッスンで扱う交渉や動機づけの土台になります。

スポンサーから引き出すべき5つの権限

プロジェクト憲章を作る際、プロジェクトリーダーがスポンサーとの合意で特に引き出すべき権限は、次の5つです。

1つ目は要員の指名への関与権です。誰をプロジェクトに参加させるかという人選の場面で、プロジェクトリーダーの意見を聞いてもらう権利です。最終決定権まで求めなくても、意見を述べる場を確保することが重要です。具体的には、プロジェクトの立ち上げ時にスポンサーへ次のように依頼します。「今回のプロジェクトでは、各部門からメンバーを推薦していただく前に、業務内容と必要なスキルを私からもお伝えする機会をいただけないでしょうか。最終的な人選は各部門にお任せしますが、事前に希望を伝えられる場を持ちたいと考えています」。決定権そのものを求めるのではなく、意見を述べる機会を求める形にすると、スポンサーも合意しやすくなります。

2つ目は優先順位の決定に関する後ろ盾です。メンバーがプロジェクトの仕事とライン業務のどちらを優先すべきか迷ったとき、スポンサーが「このプロジェクトは優先度が高い」と明言してくれる合意です。合意を取り付ける際は、抽象的な「優先してください」ではなく、実際に想定される場面を挙げて確認します。「メンバーの原隊の業務とプロジェクトの締め切りが重なった場合、どちらを優先すべきか、あらかじめ方針を示していただけますか」とスポンサーに尋ね、「今期の重点施策なので、基本的にはプロジェクトを優先してよい」といった具体的な回答を引き出しておくと、実際に板挟みが起きたときの拠り所になります。

3つ目は予算執行の権限です。一定額までの支出について、都度の承認を待たずにプロジェクトリーダーの判断で執行できる範囲を定めます。例えば「10万円までの支出はプロジェクトリーダーの判断で執行し、事後報告のみとする」といった具体的な金額を憲章に明記しておくと、日々の細かな支出のたびにスポンサーの承認を仰ぐ手間がなくなります。

4つ目は仕様変更の承認権です。プロジェクトの途中で要求内容が変わることは珍しくありません。どの程度の変更ならプロジェクトリーダーの判断で受け入れてよいか、どこからスポンサーの承認が必要かをあらかじめ線引きします。

5つ目はエスカレーション先の確約です。プロジェクトリーダーの手に負えない問題が起きたとき、誰に、どのように相談すればよいかをあらかじめ決めておきます。エスカレーションの詳しい設計はレッスン7で扱います。

⚠️ 注意 これら5つを一度に、しかも完全な形で得られることは多くありません。現実には、スポンサーとの対話を重ねながら、優先度の高いものから段階的に合意を取り付けていく進め方になります。すべてが揃うまで動けないと考えるのではなく、得られた範囲で走り出しつつ、機会を見て追加の合意を取りにいく柔軟さが必要です。

RACIをタスク・成果物レベルで設計する

権限の明文化をさらに実務レベルに落とし込む道具が「RACI」です。RACIは、誰が実行責任者（Responsible）か、誰が説明責任者（Accountable）か、誰に事前相談すべきか（Consulted）、誰に事後報告すべきか（Informed）を整理する枠組みです。

会議の場での決定権を整理するためにRACIを使う場面もありますが、本レッスンで扱うのは、それとは異なる粒度です。個々のタスクや成果物の単位でRACIを設計します。例えば「要件定義書の作成」というタスクであれば、実行責任者は担当メンバー、説明責任者はプロジェクトリーダー、事前相談先は関連部門の担当者、事後報告先はスポンサーとステアリングコミッティ、というように、成果物ごとに役割を書き出します。

実際の一覧表にすると、次のようなイメージになります。

タスク・成果物	R(実行責任者)	A(説明責任者)	C(事前相談)	I(事後報告)
要件定義書の作成	担当メンバー	プロジェクトリーダー	関連部門の担当者	スポンサー・ステアリングコミッティ
外部ベンダーの選定	調達担当メンバー	プロジェクトリーダー	法務・購買部門	スポンサー
テスト計画の承認	プロジェクトリーダー	スポンサー	品質保証部門の担当者	ステアリングコミッティ

この一覧を見れば、「要件定義書の内容に問題があったとき、最終的に説明を求められるのは誰か」「外部ベンダーの選定で事前に相談すべき部門はどこか」が一目でわかります。表を作る過程そのものが、曖昧なまま進みがちな役割分担を洗い出す機会にもなります。

📖 もっと詳しく 会議における発言権や決定権のレベルでRACIを使う設計は、会議運営や意思決定プロセスを扱う別の実践的な資料で詳しく学べます。本コースでは、プロジェクトの個々のタスク・成果物という、より細かい単位での使い方に絞って扱っています。

タスク・成果物レベルでRACIを整理しておくメリットは2つあります。1つ目は、誰が最終的に責任を持つかが曖昧なまま進むことを防げる点です。2つ目は、メンバーへの依頼をする際に「あなたはこのタスクの実行責任者です」と明確に伝えられるため、責任の所在をめぐる後からのすれ違いを減らせる点です。

決裁権限の事前確認

プロジェクトの途中で「これは誰が決めてよいのか」が分からず、判断が止まってしまう場面は少なくありません。これを防ぐために、プロジェクトの立ち上げ段階で、想定される主要な意思決定について、誰が決裁できるかを事前に確認しておきます。

具体的には、スコープの軽微な変更、外部への発注、成果物の受け入れ判断、スケジュールの調整といった項目ごとに、決裁権者を一覧にしておきます。これをプロジェクト憲章の一部として文書化しておけば、途中で判断が止まる場面を大きく減らせます。

陥りやすい失敗パターンは、決裁権者の一覧を作らないまま走り出し、想定外の判断が必要になった瞬間に手が止まることです。ある業務改革プロジェクトでは、途中で予定外のシステム改修が必要になり、誰が発注を承認できるのか分からないまま2週間が経過し、スケジュールに遅れが生じました。決裁権者の一覧は、すべての場面を網羅できなくても、主要な項目だけでも事前に整理しておくことで、こうした停滞を大きく減らせます。

「言質を文書に残す」作法

権限の合意は、口頭のやり取りだけで終わらせず、必ず文書として残すことが重要です。これを本コースでは「言質を文書に残す」作法と呼びます。

具体的な方法は難しいものではありません。スポンサーとの打ち合わせで権限について合意した内容を、その場か直後にメールやチャットの記録として送り、「先ほどの打ち合わせでの合意事項は以下の通りと理解しています」という形で確認を取ります。相手からの返信や反応があれば、それが合意の記録になります。

実際の文面は、堅苦しいものである必要はありません。例えば、次のような短いメールで十分です。

「〇〇部長、本日はお時間をいただきありがとうございました。打ち合わせでの確認事項を以下にまとめます。1、10万円までの支出はプロジェクトリーダーの判断で執行してよい。2、要員の交代が必要な場合は、事前に部長へ相談する。3、重大な仕様変更は48時間以内に部長へ報告する。認識に相違があればご指摘ください」

このように、箇条書きで短く要点をまとめるだけで、後から見返したときに何を合意したかが一目でわかる記録になります。相手からの返信が「認識の通りです」の一言であっても、それが後々の重要な拠り所になります。

🔰 初学者の方へ 「わざわざ文書にするのは、相手を疑っているようで気が引ける」と感じる方もいるかもしれません。しかし、これは相手への不信の表明ではなく、双方の記憶違いを防ぐための実務上の作法です。多くのスポンサーは、むしろ丁寧に確認を取ってくれるプロジェクトリーダーを信頼できると感じます。

言質を文書に残す習慣は、プロジェクトが順調なときにはあまり意識されませんが、途中でトラブルが起きたときに大きな違いを生みます。「あの時こう合意したはずです」と提示できる記録があるかどうかが、プロジェクトリーダーの立場を守る最後の砦になります。

まとめ

このレッスンでは、以下のことを学びました。

責任と権限のギャップは、プロジェクトリーダーという役割に構造的に伴うもので、完全にゼロにはできないが縮めることはできる
プロジェクト憲章に権限移譲を明文化することで、後からの「言った・言わない」を防ぎ、権限を設計的に補える
スポンサーから引き出すべき5つの権限は、要員の指名・優先順位の決定・予算執行・仕様変更の承認・エスカレーション先の確約である
RACIをタスク・成果物レベルで設計することで、責任の所在を明確にできる
決裁権限を事前に確認し、合意内容は必ず文書に残すことで、途中の判断停止やトラブルを防げる

次のレッスンでは、こうして設計した権限を土台にしながらも、それだけでは動かない相手をどう動かすか、権限に頼らない「影響力」の技術を扱います。人は貸し借りで動くという中核メッセージを、具体的な交換の枠組みとして学びます。

確認クイズ

このレッスンの理解度をチェックしましょう。