新卒2年目でPMを任された話 ― プレイヤー脳のまま突っ走って学んだこと
この記事の目次
本記事は【Advent Calendar 2025】の15日目の記事です。
はじめに
ITディベロップ第2統括部ITディベロップ2部開発1課のH.Yです。
私は新卒2年目のエンジニアとして、少人数の開発チームを中心に、AIチームやインフラなど複数部門と連携するプロジェクトでPM（プロジェクトマネージャー）を任されました。
厳密には、最初は「PL（プロジェクトリーダー）をやりたい」と課長に相談し、了承をもらっていました。ところが、開発を進めるために必要なことをどんどん進めていたら、気づけばPMの役割を担っていました。
実際、統括PMからも「タスクをどんどん巻き取ってほしい」という意図があり、そのままPMとして動くことになった、という流れです。
初めての経験でしたが、「若手だからサポートしてもらえるだろうし、せっかくだから色々挑戦しよう」という気持ちで臨んでいたため、不安のようなネガティブな感情は特にありませんでした。
その分、プレイヤー脳のまま突っ走り、結果として多くの失敗を経験しました。
この記事では、その失敗と学びをまとめています。
同じく若手でPMを始めた人やPMをやりたい人の参考になれば幸いです。
プロジェクト体制
- PO：要件定義、受け入れ基準の策定、仕様変更の意思決定
- 統括PM：全体の進行管理
- PM（私）：進捗管理、調整、スケジュール策定
開発チーム（5名）
- Yさん：業務委託ベテランエンジニア（FE見積もり担当）
- Tさん：フロントエンド実装担当
- Hさん：フロントエンド実装担当
- Dさん：バックエンド実装担当
- Pさん：バックエンド実装＋小タスク担当
他部署連携
- AIチーム：DB作成、AI機能用のデータ整備、外部API作成
- インフラチーム：デプロイ手順作成、インフラ構成変更対応
- デザイナー：仕様変更に伴うデザイン修正
失敗談と学び
1. 情報共有は“全部”ではなく“行動可能な形”で
状況
ステークホルダーとの方針変更や重要なやり取りがSlackで発生した際、私はメンバー全員をメンションしてリンクを貼り、「これの把握お願いします」と連絡していました。
しかし、そのような連絡は膨大になり、結果として把握漏れが生じました。
原因
- PMとメンバーが把握する情報の性質が異なる
- PM：浅く広く把握
- メンバー：狭く深く把握
- 人には処理できる情報量に限界があるため、メンバーにPMと同じ情報量の把握を期待するのは間違い
- メンバー目線では「把握してください」と言われても、何をすればいいのか分からず、行動に結びつかない
対応
- まだメンバーに対応してもらわない情報は共有しない
- PMの仕事は「メンバーが動ける状態に情報を整理すること」
- 現状・課題・完了条件・PMが考える手段・備考を整理し、Issueに落とし込む
学び
- メンバーが動けるように情報を変換するのがPMの仕事
- PMが処理できる情報の深さに限度があるように、メンバーが処理できる情報の広さにも限度がある
2. スケジュール認識ズレで焦った話
状況
Yさんと進捗確認をした際、期限の認識が大きくズレていることが判明。
- 私の想定：期限は10月14日
- Yさんの認識：期限はその2週間後
さらに、Yさんから「そのスケジュールではかなり無理がある」と指摘され、焦りました。
原因
- 統括PMが提示したスケジュールは「理想値」だった
- 私はそれを「絶対値」と誤解し、Slackで共有したが通知過多で見落とされていた
- 認識合わせを全員で行う仕組みがなかった
- プロジェクト理解が浅く、ガントチャートを作れる状態ではなかったため、「とりあえず進めれば見通しがつく」というプレイヤー的発想で動いていた
対応
- Yさんと統括PMを交えて緊急ミーティングを実施。結果、スケジュールは調整可能であることが分かり、事なきを得ました。
学び
- ガントチャートを作るべきという理解はあったが、プロジェクト初期は情報不足で作れないこともある
- ガントチャートを作る能力は、プロジェクトの性質をもとにリスク要因を見抜く力に依存する
- 「とりあえず進める」だけでは不確実性が増すため、進めながらも認識合わせの仕組みを早期に作る
- 重要な認識合わせはSlackだけに頼らず、確実に確認できる仕組みを用意する
3. 要件の裏にある課題を理解することの重要性
状況
既存システムにない新しい機能の用途を勘違いし、POの想定とは異なる仕様で実装してしまったため、手戻りが生じました。
原因
- POが定義した受け入れ基準に仕様が記載されていなかった
- 要件は理解したが、事業部の業務フロー上「なぜ必要なのか」を理解しないまま進めた
対応
- 「本当にその機能必要なの？」「より適切な課題解決手段はないのか？」と疑う意識を持つこと
学び
- 言われたからやるのではなく、自分の言葉で「なぜやるか」を説明できる程度に理解しないと手戻りが生じる可能性がある
4. PJ完了の定義を明確にすることの重要性
状況
プロジェクト序盤にPOに受け入れ基準を定義してもらい、仕様変更のたびに合意を取りながら更新していました。
しかし終盤ではPJ完了の定義が曖昧になり、関係者間で「何をもってプロジェクト終了なのか」が不明確になり、メンバーを不安にさせてしまいました。
原因
- 仕様変更が高頻度で発生し、受け入れ基準更新の優先度が下がった
- 「受け入れ基準を満たすものを作る」という合意があったため、基準が増えるほど負担が増える心理的ハードルがあった
対応
- 現状をPOに報告し、「受け入れ基準を最新化するのでレビューしてほしい」と依頼
- 合意形成を再度取り直し、受け入れ基準を最新化してプロジェクト完了条件を明確化
学び
- PJ完了の定義は、関係者全員が同じ認識を持てるように仕組み化する
PMになりたい人へ
プレイヤーの時もPMの時も、自主性・課題解決能力・目的意識といった能力はとても重要です。
ただし、PMになると、それらの能力を活かす方法が大きく変わります。
プレイヤーは「自分で成果を出す」ことに集中しますが、PMは「チームが成果を出せる状態を作る」ことが役割です。
PMとして働くのは簡単ではありません。調整や意思決定、リスク管理など、プレイヤー時代には経験しなかった難しさがあります。
しかし、その分、刺激が多く、学びも大きい仕事です。
この記事で紹介した私の失敗は、すべて成長の糧になりました。
もしあなたがPMに興味を持っているなら、ぜひ挑戦してみてください。
※本記事は2025年12月時点の情報です。
