レッスン1：プロジェクトリーダーという職種——ラインの縦軸と横軸

このレッスンで学ぶこと

プロジェクトを定常業務と区別する2つの要件（有期性・独自性）を理解する
PL・PM・PMO・スポンサー・ステアリングコミッティという登場人物の役割を整理する
プロジェクトリーダーに公式の人事権がないのは欠陥ではなく構造的な常態であることを理解する
権限を支える3つの土台（公式権限・専門性・関係性）と、本コースが向き合う中核メッセージ6個を把握する

プロジェクトとは何か——有期性と独自性

会社の仕事には、大きく分けて2種類あります。毎日・毎月・毎年繰り返される定常業務と、始まりと終わりが決まっている一回限りの取り組みです。後者を指す言葉が「プロジェクト」です。

プロジェクトには2つの要件があります。1つ目は有期性です。プロジェクトには必ず始まりと終わりがあります。「基幹システムを刷新する」「新製品を市場投入する」「複数部門をまたぐ業務改革を実行する」といった取り組みは、目的を達成した時点、あるいは中止が決まった時点で終わります。定常業務のように「来年も同じ体制で続く」ことを前提にしません。

2つ目は独自性です。プロジェクトは、これまでにない成果物や状態を生み出す取り組みです。毎月の月次決算や、毎日の受発注処理は、手順が確立された繰り返し作業であり、独自性を持ちません。一方、プロジェクトは毎回条件が違い、前例をそのまま当てはめられません。

💡 ポイント 有期性と独自性の2つがそろって初めて「プロジェクト」と呼べます。期間が決まっていても、毎年恒例の定型イベント運営のように内容が定型化されていれば、それは定常業務に近い性質を持ちます。逆に、独自性の高い取り組みでも、終わりのない継続的な活動であれば、プロジェクトではなく新規事業や新設部門の運営に近いものです。

この2つの要件は、プロジェクトリーダーという役割の性質そのものを決めます。有期性があるため、プロジェクトリーダーは「時限組織」を率いる立場になります。独自性があるため、過去の手順をそのまま踏襲できず、都度、体制と進め方を設計し直す必要があります。この2点が、通常のライン管理職とは異なる難しさを生み出す出発点です。

具体的な場面で考えてみます。ある企業で「基幹システムを刷新する」プロジェクトが立ち上がり、半年後のカットオーバー（切り替え）を目指して進んでいました。ところが、途中から「刷新後の運用改善も同じチームで続けてほしい」という声が現場から上がり、プロジェクトの終了時期が徐々に曖昧になっていきました。

このとき起きているのは、有期性の要件が崩れる典型的な失敗パターンです。運用改善は本来、終わりのない定常業務であり、プロジェクトチームがそのまま担い続けると、いつまで経っても時限組織が解散されず、メンバーは原隊に戻れないまま宙に浮いた状態が続きます。プロジェクトリーダーは、立ち上げの段階で「何が終わったらこのプロジェクトは終わりなのか」を明確にし、範囲外の依頼が来たときには、それが新しいプロジェクトなのか、定常業務への移管なのかを見極める役割を担います。

⚠️ 注意 「せっかく積み上げたノウハウがもったいないから」という理由で、プロジェクトの終わりを曖昧にしたまま活動を延ばしてしまう場面は少なくありません。しかし、終わりを決めないプロジェクトは、有期性を失った時点で本コースが扱う「時限組織のリーダー」という前提そのものが崩れます。延長する場合も、いつまで、何を目的に延ばすのかを、スポンサーとあらためて合意し直すことが重要です。

登場人物を整理する——PL・PM・PMO・スポンサー・ステアリングコミッティ

プロジェクトには、通常のライン組織にはない独自の登場人物がいます。本コースを通じて繰り返し登場するため、最初に整理しておきます。

プロジェクトリーダー（PL）は、プロジェクトの現場を率いて成果を出す責任者です。組織によっては「プロジェクトマネジャー（PM）」という肩書きで同じ役割を指すこともあり、呼び方は企業文化によって揺れます。本コースでは、現場を率いる立場を一貫して「プロジェクトリーダー（PL）」と呼び、PMという表記が出てきた場合も同じ機能を指すものとして扱います。

スポンサーは、プロジェクトの実施を承認し、必要な資源や権限の後ろ盾となる経営層または上級管理職です。プロジェクトの成否に対する最終的な説明責任を持ち、PLに権限を委ねる側の立場です。

PMO(プロジェクト・マネジメント・オフィス)は、複数のプロジェクトを横断的に支援・統制する社内組織です。PMOの機能や関わり方はレッスン7で詳しく扱います。ここでは「複数のプロジェクトを横串で見る立場がある」とだけ押さえてください。

ステアリングコミッティは、プロジェクトの重要な意思決定を行う会議体です。関係部門の責任者やスポンサーが参加し、進捗確認や重要な方向づけを行います。

これらの登場人物とPLの関係を図で整理します。

flowchart TD
  Sponsor[スポンサー]
  Steering[ステアリングコミッティ]
  PL[プロジェクトリーダー]
  PMO[PMO]
  Members[借りてきたメンバー]
  Line[各部門のラインマネジャー]

  Sponsor -->|権限の委譲・後ろ盾| PL
  Sponsor -->|議長・参加| Steering
  Steering -->|重要決定・方向づけ| PL
  PL -->|報告・支援要請| PMO
  PMO -->|標準・支援・監督| PL
  Line -->|要員を貸し出す| Members
  Members -->|プロジェクトで稼働| PL
  PL -->|進捗・成果を還元| Line

図1：プロジェクトリーダーは、上にスポンサーとステアリングコミッティ、横にPMO、そして各部門のラインマネジャーから借りたメンバーという、複数方向の関係の中心に立ちます。

実務では、この関係性は日々の動き方にも表れます。プロジェクトリーダーは、週に1度はスポンサーへの簡単な状況共有を行い、月に1度はステアリングコミッティで主要な意思決定を仰ぎ、PMOへは定型フォーマットで進捗を報告する、というリズムを持つことが一般的です。登場人物が多いからといって、毎日全員とやり取りする必要はありません。誰に、どのくらいの頻度で、何を伝えるかを設計することが、複数方向の関係を機能させる出発点になります。この設計の具体的な進め方は、レッスン3(プロジェクト憲章)とレッスン7(PMOとの連携)で詳しく扱います。

権限がないのは欠陥ではなく常態

多くのプロジェクトリーダーが最初につまずくのは、「自分にはメンバーへの人事権がない」という現実です。評価もできない、異動も命じられない、昇給や昇格にも関与できない。それでいて、成果には責任を負う。この状態を「自分の立場が中途半端だからだ」「経験が足りないからだ」と受け止めてしまう方が少なくありません。

けれども、この状態は個人の力不足ではなく、プロジェクトという仕組みそのものが持つ構造的な特徴です。理由は3つあります。

第1に、プロジェクトのメンバーは、多くの場合、各部門のラインマネジャーの部下のままプロジェクトに参加します。人事権はそのラインマネジャーが持ち続け、プロジェクトリーダーには渡りません。第2に、プロジェクトは有期性を持つため、プロジェクトが終わればメンバーは元の部署（原隊）に戻ります。一時的な集団に恒久的な人事権を設定する仕組みは、そもそも用意されていません。第3に、多くの企業組織は、指揮命令系統をライン（機能軸）に一本化する設計を基本にしています。プロジェクトという横断的な仕組みは、その基本設計の上に後から重ねられた仕組みであり、権限の後付けが常に発生します。

⚠️ 注意 「権限がない」という前提を受け入れられないまま走り出すと、権限があることを期待して依頼をし、断られるたびに消耗します。本コースの出発点は、権限がないことを嘆く段階から抜け出し、権限がない前提でどう成果を出すかを設計する段階に進むことです。

権限なきリーダーシップが常態であるという認識は、悲観的な話ではありません。むしろ「権限がある前提の技術を身につけても使えない」ことがはっきりする分、必要な技術に集中して取り組めるという利点があります。本コースが扱うのは、まさにその技術です。

具体的な場面で考えてみます。あるプロジェクトリーダーが、開発部門から借りているメンバーに「今週中に仕様書のレビューを終えてほしい」と依頼したとします。メンバーは「わかりました」と答えたものの、週末になっても仕様書は戻ってきません。理由を尋ねると、「すみません、部の緊急案件が入ってしまって」という返事が返ってきます。

このとき、プロジェクトリーダーが「自分の頼み方が悪かったのだろうか」「もっと強く言うべきだったのだろうか」と自分を責めてしまうことがあります。しかし、これまで整理してきた通り、メンバーにとって評価権を握っているのは原隊の上司です。緊急案件を優先するのは、メンバーにとって合理的な行動であり、プロジェクトリーダーの頼み方の巧拙とは別の話です。

この場面で有効なのは、メンバー個人を責めるのではなく、優先度そのものをスポンサーや原隊の上司と調整する動きに切り替えることです。「頼み方を工夫すれば解決する問題」と「構造そのものを調整しないと解決しない問題」を区別する視点を持つことが、権限なきリーダーシップの出発点になります。具体的な調整の技術は、レッスン3以降で扱います。

権限を支える3つの土台——公式権限・専門性・関係性

人が誰かの言うことに従うとき、その背景には権限の土台があります。土台は大きく3つに分けられます。

1つ目は公式権限です。組織図や職位規程によって与えられた、指示・評価・処遇に関する正式な権限です。ライン管理職はこの土台を持ちますが、プロジェクトリーダーはほとんどの場合、これを持ちません。

2つ目は専門性です。特定の分野に関する深い知識や経験があると、その分野については周囲が自然と意見を求め、判断を尊重するようになります。プロジェクトリーダーが特定領域の専門家として選ばれている場合、この土台はある程度使えます。

3つ目は関係性です。信頼、人望、過去の協力関係の積み重ねによって生まれる、周囲が自発的に協力したくなる土台です。公式権限を持たないプロジェクトリーダーにとって、専門性とあわせて最も頼りになる土台がこれです。

3つの土台をあらためて整理すると、次のようになります。

土台	何によって生まれるか	プロジェクトリーダーにとっての度合い
公式権限	組織図・職位規程による正式な権限	ほとんどの場合持たない
専門性	深い知識・経験の蓄積	選ばれた経緯によっては一定程度使える
関係性	信頼・人望・協力関係の積み重ね	意図的に強化できる中心的な土台

📝 補足 3つの土台は独立していますが、組み合わせて使うことができます。特定分野の専門性が高く、なおかつ普段から丁寧に信頼関係を築いているプロジェクトリーダーは、公式権限がなくても十分にメンバーを動かせます。本コースのレッスン4以降で扱う「権限なき影響力」は、専門性と関係性という2つの土台を意図的に強化し、活用する技術です。

陥りやすい失敗パターンは、公式権限がないことに気づかないまま、ライン管理職と同じ口調で指示を出してしまうことです。「明日までにやってください」という言い方は、公式権限を持つ上司が使えば自然に響きますが、公式権限を持たないプロジェクトリーダーが同じ言い方をすると、メンバーの心の中で「なぜこの人にそこまで言われなければならないのか」という違和感が生まれます。専門性や関係性という別の土台に立った言葉遣いに変えるだけで、同じ依頼でも受け止められ方が変わります。この言葉遣いの具体的な技術は、レッスン4で詳しく扱います。

プロジェクトリーダーが抱える5つの悩み

プロジェクトリーダーに任命された方の多くが、共通して次の5つの悩みを抱えます。それぞれの悩みは、本コースの後半のレッスンで具体的に扱います。

1つ目は、指示を出しても優先度を下げられてしまうという悩みです。「今週中にお願いします」と伝えても、メンバーの手元では原隊の業務が優先され、気づけば締め切りを過ぎている、という経験を持つプロジェクトリーダーは少なくありません。メンバーは原隊の上司からも別の業務を与えられており、評価に直結しない依頼を後回しにするのは、メンバーにとって自然な判断です。

2つ目は、予算や体制の決定権が曖昧で、決めるべき人が見えないという悩みです。追加の外部委託が必要になったとき、誰の承認を得ればよいのかが分からず、確認だけで数日を費やしてしまうといった場面がこれにあたります。決裁権者が明確でないプロジェクトほど、些細な判断のたびに立ち止まる時間が積み重なります。

3つ目は、評価も昇進も左右できない相手をどう動機づけるか分からないという悩みです。「頑張ってもプロジェクトリーダーには何も返してもらえない」とメンバーに思われてしまうと、依頼への協力の質が徐々に下がっていきます。何を渡せば動機づけになるのかが見えないまま、頼み込むことだけが続いてしまうケースです。

4つ目は、複数の部門から人を借りるとき、どこにどう頼めばよいか分からないという悩みです。ある部門には強く頼めても、別の部門には遠慮してしまい、結果として声を掛けやすい部門だけに負担が偏った体制になることがあります。

5つ目は、プロジェクトが終わったあと、成果をどう扱えばよいか、メンバーをどう送り出せばよいかが分からないという悩みです。成果物を渡した時点で「終わった」と考えてしまい、メンバーへの感謝や原隊への引き継ぎが疎かになるケースが典型です。

これら5つの悩みは、それぞれレッスン3(責任と権限のギャップ)、レッスン5(複数部門との交渉とリソース獲得)、レッスン6(動機づけ)、レッスン5(同時交渉の順序)、レッスン8(終結マネジメント)で正面から扱います。

本コースの立ち位置

本コースはプロジェクトリーダーを、ラインの人事権を持たないまま、他部署から借りてきたメンバーで成果を出す時限組織のリーダーの視点で扱います。はじめて部下を持つ方に向けたマネジメントの型はマネジメント関連の入門コース、課長として複数チームを束ねる実務は中間管理職向けの実践コース、WBS・スケジュール管理・工程表といったプロジェクト管理のツールは全社員向けの入門コース、1on1とフィードバックの技法は1on1関連の実践コースを参照してください。

本コースは、これらとは別の軸に位置づけられます。ライン管理職が「縦の階層」を上っていく道筋だとすれば、プロジェクトリーダーは「横の軸」を渡り歩く道筋です。新任マネジャーやミドルマネジャーの次に来る階層ではなく、それらと並走する別の職種として捉えてください。

🔰 初学者の方へ 「自分はまだライン管理職になったことがないのに、プロジェクトリーダーが務まるだろうか」と不安に感じる方もいるかもしれません。実際には、ライン管理職の経験がなくてもプロジェクトリーダーを担う方は多く、むしろ本コースが扱う「権限なき影響力」の技術は、将来ライン管理職になったときにも役立つ土台になります。

中核メッセージ

本コースは、8つのレッスンを通じて、次の6つの中核メッセージを繰り返し扱います。

プロジェクトリーダーに権限がないのは欠陥ではなく常態——前提を変える
権限は「もらう」ものではなく「設計する」もの——憲章で明文化する
人は貸し借りで動く——相手にとっての通貨を見つける
評価権がなくても動機づけはできる——原隊への還元が最大の報酬
PMOは監視者ではなく味方にできる——報告の設計で関係が変わる
終わらせ方がリーダーの評価を決める——解散は次のアサインの入口

これら6つは、レッスンが進むごとに1つずつ具体的な技術として展開されます。まずは、このレッスンで扱った「権限がないのは常態である」という前提を、次のレッスン以降の土台として持ち帰ってください。

まとめ

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

プロジェクトは有期性と独自性の2つの要件を満たす取り組みで、定常業務とは性質が異なる
PL・スポンサー・PMO・ステアリングコミッティという登場人物が、複数方向からプロジェクトリーダーと関わる
プロジェクトリーダーに公式の人事権がないのは、個人の力不足ではなく組織設計上の構造的な常態である
権限を支える土台には公式権限・専門性・関係性の3つがあり、プロジェクトリーダーは専門性と関係性を中心に据える
プロジェクトリーダーが抱える5つの典型的な悩みは、後続のレッスンで具体的に扱う
本コースは6つの中核メッセージを軸に、権限なきリーダーシップの技術を8レッスンで段階的に学ぶ

次のレッスンでは、プロジェクトリーダーが日々向き合う「マトリクス組織」という構造そのものを詳しく読み解きます。機能軸とプロジェクト軸が交差する組織で、なぜ「二人のボス」問題が起きるのか、そして自分のプロジェクトがどの強度のマトリクスに置かれているのかを診断する視点を身につけます。

確認クイズ

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