· HARUBOUYA · pm · 13 min read

プロジェクトマネージャーは、結局何をすべきなのか

PMの仕事は進捗を聞いて回ることではありません。決めること、作るもの、週次の型、うまくいかないときの動き方を整理します。

プロジェクトの進捗を共有している会議の様子のイラスト

「PMは何をする人か」と聞かれると、答えが人によって違います。進捗管理、調整役、板挟み、といったイメージがあります。どれも一部ではありますが、中心ではありません。

PMの仕事は2つに集約できます。決めることと、他の人が決められる状態を作ることです。ここから外れる作業は、やらなくてよいか、他の人がやったほうがよいです。

1. PMの中心にある仕事

決める

プロジェクトでは、毎日のように判断が求められます。

  • どこまでを今回やり、どこから次回に回すか
  • 2つの案のどちらを採るか
  • 遅れたとき、何を削るか

決めないことが、最も大きな遅延を生みます。 決まらないまま作業が進むと、あとで作り直しになります。

決められない場合は、いつ、誰が、何をもって決めるかを決めます。これも判断の一つです。

決められる状態を作る

自分で決められないことのほうが多いです。その場合にやることは、判断できる材料を揃えて、決める人の前に出すことです。

揃えるもの内容
選択肢2〜3案。1案だけでは判断になりません
影響費用、期間、リスクへの影響
推奨PMとしてはどれを推すか、理由
期限いつまでに決める必要があるか

「どうしましょう」と聞かないでください。 「A案を推します。理由は納期です。Bにする場合は2週間延びます。今週中に判断が必要です」と出します。

2. PMが作るもの

道具は多くありません。この6つで足ります。

作るもの役割更新頻度
体制図・役割分担誰が何を決めるか開始時、変更時
スコープ定義やること・やらないこと開始時、変更時
スケジュール工程と期日、依存関係週次
課題管理表起きている問題と担当随時
リスク一覧起きていないが起きうること隔週
決定ログ何を、いつ、誰が決めたか決めたとき

やらないことを書く

スコープ定義で重要なのは、**「やること」より「やらないこと」**のほうです。

やること   : 受注データの取り込み、日次更新、管理画面での閲覧
やらないこと: 在庫データの取り込み(次フェーズ)
             リアルタイム更新(日次で合意)
             既存システムの改修

やらないことが書かれていないと、「当然やってくれると思っていた」が終盤に出ます。

決定ログを軽視しない

「あの件、どうなりましたっけ」が最も時間を奪います。 決めたことを1行ずつ残します。

2026-07-02 更新頻度は日次(6時)とする。決定:発注元 / 理由:即時連携は費用対効果が合わないため
2026-07-09 対象期間は過去2年分。決定:発注元 / 理由:それ以前は元データの品質が不明なため

この1行があるだけで、蒸し返しが減ります。担当が代わったときにも効きます。

3. 週次の型

毎週やることを固定します。これが回っていれば、プロジェクトはだいたい持ちます。

やること内容
進捗の確認予定と実績の差。「何%」ではなく「何が終わったか」
課題の棚卸し新規の追加、解決済みの消し込み、放置されているものの再割り当て
来週の確認誰が何をやるか、止まりそうな箇所
決定事項の記録その場で決まったことを書きます
リスクの確認隔週でよいです

進捗を「%」で聞かないでください。 90%のまま2週間動かないことが起きます。「何が終わって、何が残っているか」で聞きます。

会議で聞くこと

聞くこと引き出したいこと
終わったものは何か事実
止まっているものはあるか課題
誰かの返事を待っていないか依存による停滞
想定と違ったことはあるか早期のリスク

「順調です」で終わらせません。 止まっている作業は、たいてい他人の返事を待っています。そこを外すのがPMの仕事です。

4. やらなくてよいこと

やりがちなことなぜ避けるか
実装の細部に口を出します担当者のほうが詳しいです。判断の質が下がります
全部自分で確認します自分がボトルネックになります
進捗を毎日聞いて回ります作業時間を削り、信頼も減ります
議事録を清書します決定と宿題だけでよいです
全員を全会議に呼びます関係ない人の時間を奪います
悪い情報を止めます遅れるほど選択肢が減ります

悪い知らせは早く上げます。 遅れを隠して挽回を試みると、判断の機会を失います。「今のままだと2週間遅れる。対策は3つある」と早い段階で出すほうが、結果的に信頼されます。

5. うまくいっていないときの動き方

遅れている

まず原因を1つに特定します。人手か、仕様か、待ちかを確かめます。

原因打ち手
人手が足りません範囲を削ります。人を増やしても、終盤では効かないことが多いです
仕様が決まりません決める会議を設定します。決まらないなら仮決めして進みます
他者の返事待ち期限を切って依頼し直します。上位者に上げます
想定より難しいです方式を変えるか、範囲を削ります

「頑張る」で解決しません。 削るか、伸ばすか、増やすかのいずれかです。

要望が増えてきた

途中の追加要望は必ず出ます。断るのではなく、扱いを決めます。

  1. 要望を一覧に記録します(却下しない)
  2. 影響を見積もる(期間、費用)
  3. 今回やるか、次回に回すかを決める人に出します
  4. 決まったことを決定ログに書きます

「入れます」と即答しません。 影響を出してから決めます。この手順があると、追加要望が悪いものではなくなります。

関係者の意見が割れている

  • 何が対立しているのかを言葉にします。 目的か、手段か、優先順位か
  • 目的が一致していれば、手段は決められます
  • 目的が割れているなら、上位者に判断を求めます

6. よくある失敗

失敗起きること
やらないことを書きません終盤で範囲が膨らみます
決定を記録しません同じ議論を繰り返します
進捗を%で管理します終盤まで遅れが見えません
課題に担当と期限がありません誰も動きません
悪い情報を遅らせます打てる手がなくなります
全部自分でやりますPMが止まると全部止まります
会議が報告だけ決める場になっていません

7. 最初の1週間でやること

引き継いだ、または新しく始めたときの順番は次のとおりです。

  1. 目的を確認します。何が達成されれば成功か、1行で書きます
  2. 決める人を特定します。予算、仕様、リリース可否のそれぞれ
  3. やらないことを書き出し、合意します
  4. 課題管理表を作ります。担当と期限の欄を必ず置きます
  5. 週次の場を設定します。曜日と時間を固定します
  6. 決定ログを開始します

1と2を飛ばさないでください。 目的が曖昧なまま、決める人が分からないまま進むと、終盤で必ず止まります。

まとめ

  • PMの仕事は決めることと他の人が決められる状態を作ること
  • 判断を仰ぐときは、選択肢・影響・推奨・期限を揃えて出します
  • 作るものは6つです。やらないことと決定ログを軽視しません
  • 進捗は「%」ではなく「何が終わったか」で聞きます
  • 止まっている作業は、たいてい誰かの返事待ち
  • 遅れたら、削る・伸ばす・増やすのいずれかを選びます
  • 悪い知らせは早く上げます

調整役に見える仕事ですが、実際は判断の仕事です。決めないことが、いちばん高くつきます。

Share:

参考になったら、いいねを押してください。

コメント

    お名前とコメントは、確認後にこのページで公開されます。メールアドレスや電話番号などは書かないでください。

    Back to Blog

    Related Posts

    View All Posts »
    なぜエンジニアに話が伝わらないのか

    なぜエンジニアに話が伝わらないのか

    伝わらないのは相手のせいではなく、伝え方の型が違うためです。依頼の書き方、避けたい言葉、質問への答え方を整理します。

    前任者がいないシステムを引き継ぐ手順

    前任者がいないシステムを引き継ぐ手順

    資料がなく、聞ける人もいない状態で引き継ぐ場合の進め方です。まず動いているものを数え、止まったら困る順に並べます。調査から運用に乗せるまでの進め方を書きます。

    ベンダーに頼む前に、自分で決めておくこと

    ベンダーに頼む前に、自分で決めておくこと

    見積もりが会社によって何倍も違います。原因はベンダーではなく、渡した情報の粒度にあります。頼む側が先に決めておく6項目と、その書き方をまとめます。