プロジェクトマネージャーがいないと、進まない？
「プロジェクトマネージャーがいなくて困っています」
「うちのプロジェクト、誰が進めるの？ってなってて」
──最近、そんな話をよく耳にします。
かといって、理想のプロジェクトマネージャーなんて、簡単には見つかりません。
見つかったとしても、プロジェクトの“全部”を任せられる人材なんて、どこにもいない。
だから、現場ではいまだに、属人的な負担を誰かが背負いながら、なんとか進めるしかない状態が続いています。
でも、本当にそうでしょうか？
そもそもプロジェクトマネージャーって、「いないと進まない前提の存在」でなければならないのでしょうか。
ビジネスサイドのあなたがもし、
「プロジェクトマネージャーが必要なんだけど、なかなか人がいなくて」
そう感じているとしたら、それは人の問題ではなく、構造の問題かもしれません。
本記事では、「プロジェクトマネージャーがいなくても進む組織はつくれるのか？」という問いに向き合いながら、
これからの事業やプロジェクト推進の“現実的でクリエイティブな選択肢”を探っていきます。
大げさな理想論ではありません。
そして、「みんなで頑張ろう」という根性論でもありません。
“推進力”は、役職ではなく構造からつくれる。
そう言い切れる理由を、順を追ってお伝えしていきます。
なぜプロジェクトマネージャーに頼りすぎてしまうのか？
実は15年前、私が最初に所属した会社でも、プロジェクトマネージャーになりたいという人は、ほとんどいませんでした。
その理由はとてもシンプルです。
当時の若手にとって、プロジェクトマネージャーは「苦しそうな役割」にしか見えなかったからです。
上司たちは毎日、進捗の確認に追われ、資料をまとめ、トラブルがあれば矢面に立ち、関係者の板挟みになって謝り続けていました。
その姿を見て、みんな口を揃えてこう言うんです。
「ぜったい、ああなりたくないよね」
そして驚くべきことに、それから15年経った今も、この状況はあまり変わっていません。
私が以前いたのは、いわゆる“プライムベンダー”と呼ばれる立場のIT企業でした。
そこでのプロジェクトマネージャーの仕事は、システム関連業務は当然ありますが、発注元のユーザー企業の中に深く入り込んで、社内の派閥調整や、部門間の衝突の仲裁まで行うものでした。
もうそこに「ITの知見」なんて、ほとんど関係ありません。
むしろ、社内で処理しきれなくなった“人間の問題”を、社外の第三者が“外圧として”解決しに行くというレベルでした。
もはやそれは、コンサルタントのような立ち位置ですらある。でも、専門性があるわけではない。単に「誰かがやらなきゃ進まないから」という理由で、プロジェクトマネージャーが請け負ってしまう。
この役割を間近で見ていた若手たちが、「ああはなりたくない」と思うのも無理はありません。
人間関係のいざこざを処理する係（のように見えてしまう）。
プロジェクトマネージャーという仕事自体が悪いわけではありません。
チームにとっては欠かせない役割であり、価値ある仕事です。
それなのに、なぜこんなにも“なり手”がいないのでしょうか？
考えられる理由は以下です。
- 責任は重いのに、裁量や評価がついてこない
- 実行権限がないのに、調整だけ任される
- プロジェクトマネージャーに頼るようにつくられてしまっている組織の仕組み
責任は重いのに、裁量や評価がついてこない
プロジェクトの失敗は真っ先にプロジェクトマネージャーの責任になりがちですが、成功したときはチームの成果として吸収されてしまう。
プロジェクトが遅れたり、トラブルが起きたりすれば、「なぜ防げなかったのか？」「もっと早く言ってくれればよかったのに」と、真っ先にプロジェクトマネージャーが問われます。一方で、プロジェクトが予定通りに進んだとしても、それは“トラブルがなかったこと”としてスルーされてしまう。わざわざ「今回、進行がうまくいったね。あなたのおかげです」とフィードバックされることは、まずありません。
うまくいっても評価されにくく、失敗すれば全責任を問われるという、不公平な構造になってしまっているのです。
正直、“報われにくい仕事”という印象が強いのは否めません。
実行権限がないのに、調整だけ任される
開発メンバーを直接動かす権限があるわけでもなく、予算やリソースを自由に使えるわけでもない。
それでも「スケジュール通りに進めてください」と言われる。
自分では動かせないコマで勝負し続ける将棋のようなものです。
プロジェクトマネージャーに頼るようにつくられてしまっている組織の仕組み
たとえば、ビジネスサイドは目的を語る。技術サイドは技術で答える。
でもその間をつなぐ人がいない。すると、「調整役」や「翻訳役」が必要になります。
この“間に挟まる役”を、プロジェクトマネージャーが引き受ける。
- 情報がプロジェクトマネージャーを通さないと流れない
- 意思決定がプロジェクトマネージャーに集中する
- プロジェクトの成否までその人次第になってしまう
結果的に、“進め役がいないと止まる”構造が、無自覚のうちにできあがってしまうのです。
「任せる」ことと「放り投げる」ことの違い
よくあるのが、企画フェーズを担ったビジネス側の人が、プロジェクトの“推進”まで任されることを避けるケースです。
これは必ずしも無責任というわけではありません。
むしろ、「自分には実行のスキルがないから、そこは任せたほうがいい」と、実務フェーズに適した人材に委ねるという判断であることが多い。
ただ問題なのは、その“預け方”が抽象的で丸投げに近いこと。
「任せた」といっても、進め方も判断基準も共有されていない。
気づけば、“うまくいかなかったらプロジェクトマネージャーの責任”、いやいや、ビジネス側の依頼の問題、という不毛な空気ができあがってしまう。
つまりこれは、役割の分担があいまいなまま進んでしまったことによる“すれ違い”の問題なのです。
ここで、前提を考え直してみたい。
「プロジェクトマネージャーが必要な構造」自体が、前提として正しいか？
プロジェクトマネージャーに依存する構造そのものが、問題なのでは？
このあと、そんな可能性について掘り下げていきます。
IT業界以外でも、似たような“進め役”はいるが評価されていない
プロジェクトマネージャーという職種名は、たしかにIT業界でよく聞く言葉です。
でも、プロジェクトを“進める人”という意味での役割なら、他の業界にも当たり前のように存在しています。
製造業であれば「生産技術の立ち上げリーダー」や「工場導入プロジェクトの調整担当」。
建設業であれば、工期・安全・コストの三点を見ながら現場を回す「施工管理者」。
教育の現場では、新しいカリキュラムや研修を“現場で実装する”ために調整する人。
医療・福祉の分野でも、施設の立ち上げやシステム導入時に、ステークホルダーを横断して動かす人などが必ずいます。
これらの役割は業界によって呼び方が違うだけで、担っていることは、IT業界で言う“プロジェクトマネージャー”と本質的に変わりません。
関係者を巻き込み、スケジュールを調整し、現場の動きを止めずに前に進めていく──
業界や業務範囲の違いはあっても、“プロジェクトを進める人”という点では共通しています。
こうした役割を担える人材は、どの業界でも足りていません。
また、成果が数字で見えにくい、評価が曖昧になりやすい、属人化しやすいという構造まで、驚くほど似ています。
実際には、これらの人たちがいなければ、現場での“動き”が起きない。
全員が「自分の持ち場だけ」で完結しようとすると、絶対に橋渡しする誰かが必要になります。
それでも評価されにくいのは、
- 「成功すると何もなかったように見える」
- 「誰でもできるように“見える”」
- 「成果が定量化しづらく、語られにくい」
といった、“プロジェクトを進める仕事”特有の見えづらさがあるからです。
つまり、「プロジェクトを動かす人」が不足しているのは、IT業界だけの問題ではないということ。
むしろ、多くの業界で「推進役は必要。でも育ってないし、評価もされない」──
そんな共通の課題に直面しているのが現実ではないでしょうか。
プロジェクトが動く組織に共通する“当たり前の条件”とは？
話を戻します。「そもそも、プロジェクトマネージャーがいないと進まない構造自体が問題なのでは？」という話でした。
属人的な調整に頼らず、関係者全員が判断・行動できる状態を作る
どんな業界でも、プロジェクトがうまく回っている組織には以下のような共通項があります。
関係者全員が「何を達成すべきか」を具体的に理解している
「達成すべき状態」が共通認識になっているか？これはすべての土台です。
「◯◯までに◯◯が◯◯できた状態を実現することで」が全員に明示されている状態。
収益などのビジネス目標や利用率などのプロダクト目標でもよいです。価値提供や問題解決どちらでも良いですが、目標が達成されることでターゲットの期待状態が実現できる。これが、関係者に伝わっていないことには始まりません。
業界を問わず、“チームが目指すゴールを粒度まで合わせて握っているかどうか”という話です。
各自が「自分たちにとってのベネフィット」を理解している
人は“自分に関係ある”と思えないプロジェクトには関与しづらくなります。自分事として考えられないものです。
「これは会社の方針だから」と言われるより、「この成果が出れば、あなたの部署の業務が○○時間減ります」と言われたほうが動きやすい。
プロジェクト全体の目的と、個々人の業務や成果とがきちんとつながっていること。
この接続が曖昧だと、協力は表面的なものになります。
お互いの役割・業務範囲・関与範囲が整理されている
「誰が、何を、どこまで考えるのか、なにを考えなくてよいのか」
これが共有されていないと、決まるべきことが決まらず、ポテンヒットとなったり、別な人が同じ作業をしてしまったり、相談事項がすべてプロジェクトマネージャー、もしくは起案者に流れ込みます。
分かりやすいのは、「成果物」単位でだれが担当するか考えるとよいでしょう。その成果物の「インプット」やその成果物を元にした「アウトプット」はだれが作るのか、そもそも成果物の要否の認識合わせを関係者でしておくことが重要です。細かい成果物は関係者間で問題ありません。自身と近しい職種間でさえ、この役割や範囲をお互いに勘違いしているものなので、一度、関係者間で集まって整理してみてください。認識合っている方が少ないのです。
会話の粒度が揃っていて、「言葉」の定義の認識が合っている
基本的には、「プロジェクトに関するビジネス用語」で話すのが基本です。「ビジネス用語」は関係者全員が把握しているものだからです。
お互いそう思っていますが、現実は違います。
意外と通常業務も含めて各自で伝わる造語が作られています。その「造語」がどのような定義なのか確認しておくべきです。
この問題を解決するために、会社における「言葉の用語集」を検討したことがありますが、これを運用することは非常に難しいです。全社で取り組みを促す必要があるため、用語集の更新がされているのか監視できないし、そのための時間も馬鹿になりません。
おすすめなのは、プロジェクト毎にプロジェクトに関する用語集を用意することです。
はい、面倒です。面倒ですが、認識齟齬を解消する効果は絶大です。重要な用語や勘違いしやすい用語に注力した一覧でよいです。これでクリティカルなミスは防げます。
特定の関係者間で議論する詳細な会話では「専門用語」が出てくるのは当たり前なので問題ありません。
スコープ・優先順位・判断基準が定義されている
プロジェクトを進めるうえで最も重要なのは、「何をやるか」よりも「何をやらないか」が関係者と共に合意されていることです。
これが曖昧なままだと、どんな進行役がいてもプロジェクトはブレます。
さらに重要なのが、「やる／やらない」の判断基準そのものが定義されているかどうかです。
- 「この変更はスケジュールを大幅に超過する」
- 「これはユーザー価値に直結しない」
- 「この実装は技術的リスクが高すぎる」
こうした判断は、プロジェクトに精通している人と、実現可否を持つ関係者とで事前にすり合わせておくべきものです。
ここではプロジェクトマネージャーは機能しません。いなくてもできることです。
判断ができない原因は「見積もりのズレ」にあることが多い
判断の場面でよく起こるのが、要望に対して見積もる側から「その要望は見積もれません」と返されるケースです。
この原因の多くは、「見積もりとは幅を持つもの」であるという認識と、どの程度の精度（レベル感）を求めているのかが、要望側と見積もる側で合っていないことにあります。
見積もりとは“予測”であり、幅があって当然
たとえば、営業の契約目標で「今月は10件達成」と言い切ることは稀です。実際には、「この進捗なら今月は8〜12件の見込み」と表現するのが自然です。これが「見積もりの幅」です。
どの程度の幅を許容するかは、プロジェクトの性質やステークホルダーの期待によって異なります。
「3日以内の誤差で済む見積もりが必要なのか」「1ヶ月程度の見込みでよいのか」。
このような見積もりの“レベル感”についての期待値も、関係者間で事前に共有されていなければなりません。
このような「当たり前」が揃っていれば、極端に言えば誰が推進してもプロジェクトは進みます。
個々のファシリテーション能力や調整力も重要ですが、それらが機能するためには、まず“当たり前の条件”が整えるとが前提です。
🧩 補足：報告や会議設計は、職種ではなく“ビジネススキル”の問題
プロジェクトマネージャーにありがちな仕事として、「報告の取りまとめ」や「会議体の設計・進行」が挙げられます。
週次の定例会で、何を話すかも決めずに「とりあえず順番に進捗を報告しましょう」──
これが“普通”になっている現場は少なくありません。
はっきり言いますが、報告や会議設計はプロジェクトマネージャーのスキルの問題ではありません。ビジネスパーソンとしての基礎力の問題です。
会議を開くなら、「その時間のあと、何がどう変わっているべきか？」を想定すべき
- この会議で何を決めたいのか？
- 参加者はどんな前提情報を持って臨むべきか？
- この会議のあと、誰が何を判断し、何を進めるのか？
これらが設計されていなければ、その会議はただの時間泥棒です。会議後に「で、どうなったんだっけ？」となるようなものは、開く価値がありません。
報告も同じ。“何を伝えて、どう判断してもらうか”が設計されていなければ意味がない
報告とは、「何が起きていて」「何が問題で」「どんな判断が必要か」を相手に渡す。
「状況を共有して終わり」のような報告は、報告の“体裁”をしているだけで、中身がないと言わざるを得ません。
報告だけが目的なら、会議である必要はまったくない
情報を共有するだけなら、テキストで事足ります。
相手がいつでも読めて、確認できて、必要なタイミングで掘り下げられるからです。
それなのに、なぜ会議という形をとるのか？
その理由が「自分がその場で把握できていないと不安だから」であれば、それは“報告”の名を借りた自己都合の押し付けです。
不毛な会議はコスト。会議にするということは“相手の時間を奪っている”という自覚が必要
- 会議は安易に開くものではない
- 会議のたびに、数人〜十数人の作業時間と集中力が削られている
- それでも「定例だからやる」のなら、それは思考停止
会議や報告の設計ができないなら、それは“役職以前”の問題である
これまで何度も見てきました。
定例会という名前の、“毎週の作業報告読み上げ会”。
出席者全員が、頭では「これは無駄だ」と思っていながら、
誰もなおそうとしない。なぜなら、設定した人がそれでいいと思っているから、理解してないから、役職者だから、etc.
はっきり言います。
会議や報告の設計ができないのに、プロジェクトを率いたり、誰かの時間を管理する立場に立つべきではありません。
会議設計や報告設計は、「ビジネススキル」です
意思決定、情報共有、説明会、状況整理、問題解決など。
こうした目的に応じて、「どんな準備をし」「どんな内容で」「どんな期待値で」臨むべきかを考える力──
これは、職種に関係なく、誰もが持つべきスキルであり、持たずに“場だけ設ける”人は、むしろ自分の未熟さを公然とアピールしているようなものです。
「なぜこの会議をやっているのか？」が即答できない人に、会議体を設定する資格はありません。
それでも、なぜプロジェクトマネージャーに負荷が集中してしまうのか？
ここまでで、「本来、プロジェクトは「当たり前の条件で動くべき」ということは見えてきたと思います。
スコープ、優先順位、判断基準──これらが事前に整理され、関係者で握れていれば、進行役に過剰な負荷がかかることはないはずです。
それでも、現実の現場ではプロジェクトマネージャーや推進担当に、あらゆる判断、調整、報告、説明が“集まってきてしまう”構造が温存されています。
なぜか？
1. 「一次判断候補を代わりにやってくれる人」という誤った認識
プロジェクトマネージャーの役割が、「全体を見て調整し、判断する人」と捉えられてしまうと、関係者はつい「じゃあ、◯◯さんに聞いてからにしよう」となってしまいます。決まらないことが増えるたびに、「最終的にはPMが決めるべきでしょ」と丸投げされてしまう。
本来、「何をどこまで誰が判断するか」は関係者全員で決めておくべきことです。
決められていないから、判断が流れ込み、結果的にPMが“なんでも屋”になるのです。
2. 他のメンバーが“考える責任”を放棄している
「こうしたいけど、判断は任せるんで、PM側で考えてください」
──一見、協力的に見えるこの言葉。
でも実際は、考える責任を相手に丸投げしているだけです。
「こういう背景で、この観点で進めたいと思っています。どうでしょうか？」
このように“素材”を持ち込んでくれるならまだしも、
「ノープラン・ノー材料」で投げられる判断要求は、ただの負荷転嫁です。
というか、もうこれも、交渉や相談のビジネススキルの問題ですね。
プロジェクトマネージャーは、答えを知っているわけではありません。
答えを一緒に考えるために、関係者それぞれが考えた上で会話をするのが、本来の形です。
（プロジェクトとか、もう関係ないですね）
3. 役割と責任の“曖昧さ”が放置されている
「その作業、PMがやることだよね？」
「いや、そこは営業じゃないと判断できないでしょ」
「仕様確認、結局どこがまとめるの？」
こうした会話が現場で頻発しているとしたら、それは役割分担が曖昧なまま走り出していたサインです。
誰がどの判断をするのか、誰が何に責任を持つのか。
これが最初に決められていないと、都合のいいときだけ「PMに投げる文化」が生まれてしまいます。
4. 「PMが背負って当然」という空気が文化になっている
「全部PMが見てくれてるから大丈夫でしょ」
「とりあえず、PMに連絡しておけばOK」
──こうした発言が“善意”で交わされることすらあります。
でも、それってPMがどれだけの判断と情報を抱えているか想像できていない証拠です。
プロジェクトマネージャーは、“リスクと期待が集中する真空地帯”を無限に埋める人ではありません。
「全部背負って当然」な空気は、無意識のチーム依存そのものです。
5. 「それ、誰が考えるの？」がいつまでも放置される
最も根深いのはこれです。
「なんでPMがこんなに大変そうなんだろう」と誰も思っていない。
あるいは、「あの人はできる人だから回ってる」と勘違いしている。
でも実際は、あらゆる認識ズレ、意思決定のための情報格差の「空白」をPMが裏側で埋めて考えてるだけなんです。
- 誰が考えるべきか決まっていない
- 誰が意思決定者かも定義されていない
- 情報の流れも非構造的で、PMだけが全体像を把握している
それを「優秀なPM」と評価してしまった瞬間に、その“歪み構造”が組織に固定されてしまいます。
「誰かが全部やってくれる構造」ではなく、「自分たちの空白を誰かに押しつけていないか」を問い直す
プロジェクトマネージャーに負荷が集中するのは、スキルのせいではありません。
“仕組みの空白”を、誰も見ようとしない組織文化と、考えることを手放した関係者たちの姿勢こそが原因です。
プロジェクトは、誰か1人が背負うものではありません。
それぞれが自分の役割と判断責任を持ち寄るから、はじめて進みます。
“プロジェクトマネージャー”という職種がいらなくなる未来へ
「プロジェクトマネージャー」という職種は、必要ありません。「進行管理」や「調整」だけを専門にやる人がいなくても、チーム全体が“設計された構造”の中で、自律的に前に進めるようになることこそが理想なのです。
職種に頼らず、機能が分散された状態が“強い組織”である
プロジェクトマネージャーに限らず、役割とは本来、特定の人に集中させるものではありません。
- 目的を言語化する人
- 判断軸を定義する人
- 会話の粒度をそろえる人
- 空白に気づき、整理する人
- 誰かの思考を引き出す人
これらが「一人の優秀なプロジェクトマネージャー」に押し付けられる構造こそが、これまでの問題でした。
今後は、こうした役割がチーム内で自然に分散し、補い合うことが前提になっていくはずです。
プロジェクトマネージャーがやってきた“役割”は、これからも必要です。ただ、それが職種として固定されている必要はありません。
- 企画フェーズで構造設計を担うビジネスサイド
- 開発の進行と判断軸を整理するテックリード
- 会話のファシリテーションをするUI/UXデザイナー
こうした多様な職能の人たちが、一部のPM的役割を“持ち寄る”ような状態こそが理想です。
本当に目指すべきは、「プロジェクトマネージャーがいなくても進むチーム」
- スコープと優先順位が明示されていて
- 判断基準が揃っていて
- 情報共有の設計が整っていて
- 役割分担と責任範囲がクリアになっていて
- 誰か一人にすべてが集中していない
そんなチームができれば、プロジェクトマネージャーはもう“苦しむ係”ではなくなります。
その状態を最初に整えるファシリテーターとして関与し、あとは自然にチームに溶けていく──
それが、これからのプロジェクト推進のあり方、そうあるべきだと思います。