「次の案件、PMお願いします」
そう言われた瞬間、「あ、やばいかも」と感じた人も多いのではないでしょうか。
- PMって結局、何をすればいいんだっけ
- 進捗管理をちゃんとしていれば大丈夫？
- ベンダーが主導してくれる前提で進めていいの？
明確な説明も、引き継ぎもないまま、とりあえずプロジェクトが始まってしまう。そして、誰も「PMのやり方」を教えてくれない・・・。そんな状態でPMを任されるケースは、現場では決して珍しくありません。
多くの人は、プロジェクトがうまくいかないと「自分のスキルが足りないからだ」と考えがちです。でも、実際は違います。
原因の多くは「人」ではなく「仕組み」です。
特に事業側PMの場合、
- ベンダーが何とかしてくれるはず
- 自分は管理だけしていればいい
という前提のまま進めると、プロジェクトはほぼ炎上していきます。
最初のうちは、進んでいるように見える。会議もしている。資料も揃っている。なのに、「決めるべきことが、誰にも決められていない」というような状態に陥っていく。そして、最後は馬力でなんとかせざるを得ない。
本記事では、「意思決定」という観点から、事業側PMが担うべきプロジェクト管理の全体像を整理します。
この記事でわかること
- なぜPMが必要なのか
- PMの役割とは何か
- PMが管理すべきこと、やってはいけないこと
では、まずは「PMの役割とは何か」から見ていきましょう。
※本記事では「事業会社におけるPM」を前提に解説します。ベンダー側PMとは、求められる役割が少し異なるためです。
PMの役割：「管理する人」ではない本当の仕事
まず最初に、PM（プロジェクトマネージャー）の役割から整理します。
事業会社で「PMやってー」と言われても、「で、具体的に何をやればいいのか」まで説明してくれる人は、ほとんどいません。（というか、説明できる人自体が少ない）
その結果、
- 進捗を追う
- 会議を回す
- ベンダーとやり取りする
といった“それっぽい作業”をしながら、なんとなくPMをやっている状態になりがちです。
では、そもそもPMとは何者なのでしょうか。
PMの役割を一言で言うと「意思決定者」
PMの役割とはこうです。
QCD（品質・コスト・納期）を守るために、意思決定を継続的に行う人
「え？PMってプロジェクト管理をする人じゃないの？」
そう思った方も多いかもしれません。確かに、プロジェクト管理もPMの仕事の一部です。ただし、それは本質ではありません。
PMの重要な役割は、管理することそのものではなく、判断が必要な場面で決めることにあります。
なぜ「管理」だけではPMの役割を果たせないのか
プロジェクトを進めていると、必ず次のような問いに直面します。
- 予定より遅れそうだが、スコープを削るか、納期をずらすか
- 品質を優先するか、コストを抑えるか
- 今決めるべきか、もう少し情報を集めるか
これらは、「正解」がある問題ではありません。すべて、トレードオフの選択です。
そして、この選択は、事業としてのQCD（品質・コスト・納期）を理解していないとできません。
だからPMは、進捗を管理するだけの人でもなく、ベンダーの報告を聞くだけの人でもなく、「決める責任を引き受ける存在」になります。
「それでもPMって、そこまで必要？」
ここで、こう思った方もいるかもしれません。
事業会社としてはベンダーに発注しているし、
そこまで重たい役割のPMって本当に必要なの？
形だけPMを置いておけばよくない？
この疑問は、とても自然ですし、実際は多くのプロジェクトで形だけのPMが置かれています。では、なぜそれでもPMという役割が必要なのか。
次の章では、その理由をもう少し構造的に見ていきます。
PMの必要性：プロジェクトは「決め続けないと前に進まない」
では、なぜPMという役割が必要なのでしょうか。
言い換えると、なぜ QCDを守るための「意思決定」を継続的に行う役割 がプロジェクトには欠かせないのでしょうか。
結論は、とてもシンプルです。
プロジェクトは、計画通りに進まないから
そして、計画からズレるたびに、必ず何らかの意思決定が必要になるからです。
プロジェクトは「不確実性」を前提にしている
少しイメージしやすくするために、まず「プロジェクトとは何か」から整理します。プロジェクトには、次のような特徴があります。
- 有期性：必ず終わりがある
- 独自性：基本的に、初めてやること
つまり、プロジェクトで扱う仕事は原則として「経験のないこと」 です。そのため、どんなに丁寧に計画を立てても、次のような理由から必ず計画はズレていきます。
- 要件の認識ズレ
- 技術的な制約
- 組織や人の事情
ここで重要なのは、ズレること自体は問題ではないという点です。
本当に危険なのは、ズレが発生したときに誰も決めない状態になることです。判断が先送りされ、影響範囲が広がり、気づいたときには手遅れになる。
この状態が、プロジェクトにとって最も致命的です。
なぜPMでなければ「決められない」のか
では、その意思決定を誰がやるべきなのでしょうか。
ベンダーやプロジェクトメンバーが決めればいいのでは、と思うかもしれません。しかし、意思決定には 判断の基準 が必要です。
プロジェクトにおける判断基準は、QCD（品質・コスト・納期） です。そして、そのQCDに対して最終的な責任を持っているのがPMです。
PM以外の立場では、
- その機能は事業として本当に必要か
- どこまで品質を担保すべきか
- 追加コストを払う価値があるか
といった、複数の観点を同時に満たす判断がどうしても難しくなります。（正直、PMでも簡単ではありません）
だからこそ、不確実性の塊であるプロジェクトにおいて、QCDという複数の軸を踏まえながら意思決定を繰り返す役割として、PMという存在が必要になるのです。
PMがやることの全体像
次に、プロジェクトを通してPMがやることの全体像を整理します。
「プロジェクトマネジメント」と聞くと、細かい管理やタスクの話をイメージしがちですが、いきなりそこに入ると全体を見失います。まずは、もう一段抽象度を上げて PMの仕事を構造として捉える ことが大切です。
PMの仕事はシンプルに言うと、計画 → 可視化 → 意思決定というサイクルを、プロジェクト期間中ずっと回し続けることです。
PMはベンダー管理係でも、企画と開発の単なるパイプ役でもありません。プロジェクトの安定性を保つために、このサイクルを止めずに回し続ける人。それがPMです。
では、それぞれ何を意味しているのかを見ていきましょう。
計画：不確実性を管理対象へ
繰り返しになりますが、プロジェクトは不確実性の塊です。だからこそ、PMの最初の仕事は「計画を立てること」になります。
ここでいう計画とは、完璧な未来予測をすることではありません。不確実なものを不確実なまま洗い出し、基準を作ることが目的です。基準がなければ、ズレているのかどうかすら判断できません。
例えば、計画がないまま進むと、
- 今、遅れているのかどうかわからない（常にオンスケに見える）
- 品質が高いのか低いのか判断できない
- コストが適正かどうか見えない
といった状態になります。
これでは、問題が顕在化したときにはすでに手遅れです。だからPMの初手は、必ず「計画を作ること」になります。
プロジェクト計画の作り方はこちらの記事でも解説しています。
可視化：判断できる状態を作る
次にPMがやるのが可視化です。プロジェクトで扱う情報を、判断できる形で見える状態に保ち続けます。
可視化の対象は、進捗やタスクだけではありません。成果物、課題、前提条件など、判断に影響する情報すべてが対象です。そして重要なのは、「一度見えるようにすること」ではなく、常に最新の状態を維持することです。
なぜ可視化が必要かというと、計画とのズレを早期に検知するためです。
プロジェクトは必ずズレます。だからこそ、そのズレが小さいうちに気づき、小さな判断・小さな修正で済ませる必要があります。そのための土台が、可視化です。
意思決定：決め続ける
最後が意思決定です。PMの仕事の中で、最も重く、そして最も本質的な役割です。
プロジェクトでは、問題が起きるたびに判断を迫られます。例えば、「この要件を実現すると1ヶ月遅れるが、現場にとっては必要不可欠。どうするか」といった場面です。
こうした状況で、何らかの結論を出し続けることがPMの仕事になります。
ただし、PMが独断で何でも決めればいいわけではありません。重要なのは、意思決定のプロセスを残すことです。
- 何が問題だったのか
- どんな選択肢があったのか
- 何を根拠に判断したのか
- どのように合意したのか
意思決定の結果、何かを犠牲にすることは珍しくありません（例えば、品質の代わりにコストを払うなど）。だからこそ、「なぜその判断をしたのか」を残しておくことが、後から意思決定の妥当性を守ることにつながります。これを怠ると、後から必ず“ちゃぶ台返し”が起きます。
PMとは、計画し、見える状態を保ち、決め続ける人です。この3つを回し続けることが、PMの仕事の全体像です。
事業側PMがプロジェクト管理でやること
ここからは、いわゆるプロジェクト管理の話です。PMとして、どのような観点で管理を行えばよいのかを整理していきます。
プロジェクト管理と聞くと、管理項目をいくらでも思いつくかもしれません。ただし、事業会社のPMがそれらすべてを同じ粒度で管理すべきかというと、そうではありません。多くの場合、開発はベンダーに委託しており、そこにはベンダー側のPMやPLが存在します。彼らと同じ観点・同じ深さで管理をしても、役割が重複するだけです。
事業会社のPMとして重要なのは、次の５つです。
- 進捗管理
- 課題管理
- 情報管理
- リスク管理
- 品質管理
それでは、順に見ていきましょう。
進捗管理：遅れに「いち早く気づく」ための管理
PMといえば進捗管理、というイメージを持つ人は多いと思います。ただし、進捗管理の目的を誤ると、一気に形骸化します。
進捗管理の目的は、オンスケを守ることではありません。スケジュールの遅延に、いち早く対処できる状態を作ることです。プロジェクトは必ず計画通りにいきません。だから重要なのは、遅れをなくすことではなく、遅れを早く察知することです。
進捗管理の目的
スケジュールの遅延に、いち早く対処できる状態を作ること
進捗管理でPMがやることは、大きく次の3つです。
- 進捗の可視化
- 定例でのチェック
- リスケジュール
まず、進捗を可視化します。ExcelのWBSでも構いませんが、可能であれば Jira や Backlog など、関係者がいつでも進捗を確認できるツールを使うのがおすすめです。
次に、定例MTGで必ず進捗を確認します。アジェンダを固定し、「進捗確認 → 課題確認」という流れを毎回繰り返すことで、進捗の棚卸しを習慣化します。
そして最も重要なのが、リスケを恐れないことです。遅延が顕在化、もしくはその兆候が見えた時点で、臆せずリスケします。計画を守ることに固執するのではなく、状況に合わせて計画を更新し続けることこそがPMの仕事です。
課題管理:「重要な判断」を見逃さないための管理
次は課題管理です。ここで強調したいのは、課題管理の目的は、課題をゼロにすることではないという点です。
課題管理の目的は、QCDに影響する重要な課題に、いち早く対処できる状態を作ることです。プロジェクトでは多くの課題が発生しますが、そのすべてが同じ重さではありません。重要なものと、単なる困りごとが混在します。
課題管理の目的
QCDに影響する重要な課題に、いち早く対処できる状態を作ること
課題管理でPMがやることは、次の4つです。
- 課題の可視化
- 定例でのチェック
- やる／やらないの判断
- タスク化
まず、課題を可視化します。課題が属人化すると、存在に気づくことすらできません。進捗管理と同様、Jira や Backlog などを使って、課題を一元管理するのがおすすめです。
可視化された課題は、定例MTGで必ず棚卸しします。新規の課題が出てきた場合は、「対応するか・しないか」をその場で判断します。対応すると決めた場合は、必ずタスク化し、誰がいつまでに何をやるのかを明確にします。ここまで落とし込んで初めて、課題は前に進みます。
情報管理：関係者の「前提」を揃えるための管理
次は情報管理です。あまり意識されにくいですが、関係者が多いプロジェクトでは非常に重要な管理です。
情報管理の目的は、関係者の知識量・前提認識を揃えることです。プロジェクトが進むにつれ、ドキュメントが増殖し、どれが最新かわからなくなったり、コミュニケーションが複数のチャネルに分散したりしがちです。
情報管理の目的
関係者の知識量・前提認識を揃えること
これを防ぐために、PMはまず「場」を作ります。最低限、次の2つは必ず決めます。
- ドキュメントの保管場所
- コミュニケーションの場所
ドキュメントの保管場所は、できるだけ一箇所に集約し、全員がアクセスでき、共同編集とバージョン管理ができることが重要です。場を作ったら、そこに情報を集め、ルールを決め、使われ続ける状態を維持します。
また、情報管理はメンテナンスが命です。フェーズの区切りなどで不要な資料を整理し、「今見るべき情報」が埋もれないように定期的に掃除をします。
リスク管理：「起きたら困ること」に先回りする管理
次はリスク管理です。プロジェクトは不確実性の塊であり、予期せぬことが必ず起こります。だからこそ、起きる前提で備えておきます。
リスク管理の目的は、「起きたら困ること」に事前に備えることです。多くのリスクは、プロジェクト計画時点で洗い出されているはずです。重要なのは、それを放置せず、定期的に見直しながら運用することです。
リスク管理の目的
「起きたら困ること」に事前に備えること
リスクへの対応には、次のような型があります。
- リスク回避：進め方自体を変えてリスクをなくす
- リスク低減：発生確率や影響度を下げる
- リスク受容：一定のリスクを許容した上で進める
- リスク転嫁：契約や役割分担で他に移す
リスク管理は、「起きたらどうするか」を考えるだけではありません。そもそも起きないようにする、起きても致命的にならないようにすることも含めた管理です。
品質管理:事業として成立する品質を守る
最後は品質管理です。品質管理の目的は、プロジェクトで定めた品質を守ることです。
品質管理の目的
プロジェクトで定めた品質を守ること
まず、どのレベルの品質を満たせばよいのかを明確にします。多くの場合、これは要件定義書が品質基準になります。次に、その品質を確認するためのテスト計画を立てます。誰が、どの観点で、どの成果物を確認するのかを決め、チェックが漏れない仕組みを作ります。
さらに、設計書や中間成果物などに対するレビュープロセスもPMが設計します。どこまでレビューするかは、品質と工数のバランスを見ながらPMが判断します。
こうして、人に依存せず、仕組みとして品質を担保するのが品質管理です。
おわりに
これまで、PMという役割が「企画職の片手間」で任されている現場を、何度も見てきました。
ですが、PMは本来、片手間でできる仕事ではありません。幅広い知識と経験が求められる、専門性の高い仕事です。
本記事で整理してきた通り、PMは単なる管理者ではありません。事業としてのQCDを守るために、意思決定を引き受ける存在です。そしてその意思決定は、一度きりではありません。プロジェクトの期間中、何度も、何度も、判断を迫られます。
だからこそ、「やらされ仕事」のPMでは、この役割は務まりません。プロジェクトに対して自分なりの意思を持たなければ、誰かの言いなりになるだけで、自信を持って決め続けることはできないからです。
PMとしてやるべきことは、すでに体系化されています。便利なツールも、ノウハウも、世の中には十分にあります。それでも最後に問われるのは、このプロジェクトを成功させたいと、本気で思っているかどうか。
PMとは、不確実性の中で、決めることから逃げない仕事です。だからこそ、プロジェクトに対する強い意志を持てるかどうかが、良いPMとそうでないPMを分けるのではないかと、私は思っています。
おまけ：プロジェクト管理のアンチパターン
プロジェクトがうまくいかない原因の多くは、スキル不足ではありません。管理の前提や、構造の間違いです。ここでは、これまでの実務で何度も見てきた「やりがちな失敗パターン」をまとめます。
同じ轍を踏まないためのチェックリストとして読んでみてください。
PMがタスクを持ちすぎる
一見すると、責任感が強く、よく動いているPMに見えるパターンです。
- 自分で資料を作る
- 調整も全部引き受ける
- 細かい作業まで抱え込む
しかし、PMが忙しすぎるプロジェクトは、ほぼ確実に失敗します。
PMは、タスクをこなす人ではありません。人を動かし、判断し、次の一手を考える人です。
不測の事態が起きたときに動けるよう、PMは意識的に余白を持つ必要があります。
極端に言えば、**PMは「少し暇」なくらいがちょうどいい。**人にタスクを振れないPMは、まだPMとして成熟していない状態だと言えます。
PMが伝書鳩（ディスパッチャー）になっている
ベンダーと企画の間に立ち、 情報を右から左へ流すだけの存在になっているパターンです。
- ベンダーからの質問には「企画に確認しますね」
- 企画からの質問には「ベンダーに確認しますね」
一見すると、 調整役として機能しているように見えます。しかし実態は自分では何も判断せず、意思決定をすべて先送りしている状態です。
この状態になると、
- 判断が常にワンテンポ遅れる
- 情報が文脈を失ったまま伝わる
- 「誰が決めるのか」が不明確になる
といった問題が連鎖的に起こります。
PMの役割は、情報を運ぶことではありません。必要な情報を整理し、自分の判断として意思決定することです。伝書鳩になった瞬間、PMは「管理者」ではなく、単なるディスパッチャーになります。
そしてそのプロジェクトでは、決める人が、どこにもいなくなるのです。
プロジェクト計画がないままスタートする
計画を作らないまま、いきなり要件定義やソリューションの議論に入るパターンです。
ひどい場合は、PMという役割すら明確になっておらず、「やりたいこと」だけが延々と議論されているケースもあります。やりたいことがまとまって「これを開発したい」と言われても、計画がなければプロジェクトは動きません。
計画とは、未来を正確に予測するためのものではありません。不確実性を前提に、どこで何を決めるかを決めておくことです。
これがないまま始めると、判断が後手に回り、必ず混乱します。
型がなく、場当たり的な管理になる
プロジェクトは「初めてのこと」を扱います。ただし、それはすべてを場当たり的にやっていいという意味ではありません。
特に、
- プロジェクト管理の進め方
- 成果物のフォーマット
- レビューの観点
こうしたものは、過去のナレッジを使って十分に定型化できます。型がないまま進めると、管理は属人化し、再現性がなくなります。
最終的には、PMがいないと一切前に進まないプロジェクトになり、PMが抜けた瞬間にプロジェクトが止まる、という事態を招きます。
PMが何も決めない（最も致命的）
PMはいるが、実質的には何も決めないパターンです。
- 「私はこう思います」
- 「こうしたらいいんじゃないですか？」
と意見は言うものの、意思決定は常に誰かに委ねる。
この状態では、プロジェクトは確実に停滞します。プロジェクトは不確実性の塊であり、それゆえ、無数の意思決定が必要になります。
決めないPMは、PMではありません。
意思決定が行われないこと自体が、プロジェクトにとって最大のリスクです。