【実録】エンジニア1年半でPjM見習いに転生！激闘の2ヶ月と「チームを巻き込む」3つの戦術なハナシ

これはNE Advent Calendar 2025の18日目の記事です！

はじめに

こんにちは！マツケンです！

普段はエンジニアとしてコードを書いていますが、この夏、とあるきっかけで 「見習いPjM（プロジェクトマネージャー）」 として転生し、激動の2ヶ月を駆け抜けました。

結論から言うと、「トリセツ」通りにはいかないことだらけでした。

今回は、エンジニア歴1年半の僕が、PjMとしてプロジェクトを回す中でぶち当たった壁と、そこから学んだ 「チーム開発を前に進めるための3つの戦術」、そして叩き出した定量的な成果について、汗と涙の記録をシェアしたいと思います。

これからPjMに挑戦したい人、あるいは後輩に「ちょっと進行やってみない？」と振ってみたい先輩方の参考になれば幸いです。

※注：この記事における「PjM」の定義：本記事では、職種としてのプロジェクトマネージャーではなく、「プロジェクト全体の工程を管理し、完遂までチームを引っ張る役割（ロール）」 として定義しています。

なぜPjMをやることになったの？

ことの発端は、僕が掲げていた3年後のビジョンにあります。

「私が“いなければ”このチームは生まれなかった」と語られる、最高のチームを築く

デカいこと言ってますね。でも本気です。
このビジョンを達成するために、今年の上半期は以下のような目標を設定していました。

1. リーダーの土台づくり： チームを頼り、意思決定に貢献する
2. 技術的な自力向上： 根本解決による生産性向上
3. 自己開示： ビジョンを率直に語れるようになる

そんな折、所属しているチーム内で 「PjMの視点を持ってほしい」 というニーズと、僕の 「プロジェクトを引っ張る経験を積みたい！」 という想いがガッチリ噛み合いました。

さらに、来年には多くの新人エンジニアが入ってくる予定。「今のうちに全体を見る力をつけなければ！」という危機感もあり、8月からの機能開発案件（某ECカートシステムの機能改修など）で見習いPjMとして走ることになりました。

【8月】 「理想のリーダー」を演じようとして自滅した話

最初の1ヶ月。正直に言います。めちゃくちゃしんどかったです。

前プロジェクトのバッファの時間を使ってMiroにスケジュールを引き、プロトタイプも作成し、準備万端で挑んだはずでした。
「まあ先輩も『3日で終わる』とか言ってたし、余裕っしょ！」とか思ってました。

しかし、蓋を開けてみると…

• 見積もりの甘さ： 既存仕様との折り合いをつけるのが想像以上に大変で、タスクが膨らむ膨らむ。
• PjMになりきれない： 実装者として大きめのタスクを自分で持ってしまい、PjMの頭に切り替えられないままMTGに参加してしまう。
• タスクの粒度がバラバラ： チームへの共有も曖昧で、誰が何をやっているかが見えにくい状態に。

結果、チームからは 「もうマツケンはいま（実装で手一杯に）こうなっちゃってるから」 と宣告される始末。

実際に"こうなっちゃってた"とき

チームメンバーは優秀な人ばかりなのに、僕が勝手に一人で抱え込み、勝手にキャパオーバーになっていただけでした。

最終的に、メンバーに無理をお願いして、かなりのイレギュラーを出しながらなんとか納期には間に合わせました。でも、疲弊したメンバーの姿を見て、「やりきれない思い」が残りました。

自分の実力不足を痛感しました。「一人で抱え込んではダメだ」 と、骨の髄まで理解した8月でした。

【9月】 「弱さ」を認めてチームを頼る。巻き込み型の進行術

8月の反省を生かし、9月からはやり方をガラッと変えました。
意識したのは 「とにかく周りを巻き込む」 こと。具体的に行った3つの改善策を紹介します。

改善1：とにかく巻き込む（「弱さ」の開示と合意形成）

8月は「自分でなんとかしなきゃ」と抱え込んでいましたが、9月は 「自分は弱い」と認め、最初からチームメンバーを頼る ことにしました。これは単に甘えるのではなく、「手戻りを防ぐための合意形成」を前倒しにする戦略です。

• 影響範囲の洗い出し： 設計段階から先輩エンジニアを巻き込み、影響のあるファイルをMiroですべて書き出しました。

実際に作った影響範囲のマップ

• 方針の合意： 書き出した情報を元に、他のメンバーとも設計方針を固めました。
• 要件の断捨離： 企画チームとも密に連携。「本当にその機能は必要か？」「既存の仕組みで代用できないか？」を話し合い、削れる工数は徹底的に削りました。

結果、既存クラスを流用できることがわかり、1から設計するよりも大幅な工数削減に繋がりました。
タスク分配もうまくいき、複雑なロジックはメンバーに任せ、自分は 「PjMとしての動き（調査、単純な設定ファイルの修正など）」に集中することができました。

改善2：見える化、とにかく見える化（迷子を生まない「共通地図」づくり）

「あれ？ 今どうなってるんだっけ？」をなくすために、情報の同期を徹底し、チーム全員が指差し確認できる「共通の地図」 を作りました。

• MiroとAsanaの同期： 全体スケジュールの「Miro」と、タスク管理の「Asana」。この2つが乖離しないよう、定期的にチェックしてメンテナンスを行いました。

実際に使っていたmiroとasana。実装を進めて行く中で出る課題や気づきなどを元に、毎週同期させていた。課題感の確認だけでなく終わらせていったタスクが積み上げられて行くところが可視化される部分もよかった。

• ボトルネックの掃除： 「残りのタスクでボトルネックになっているものはないか」を常に監視し、チームが迷わないように先回りして掃除しました。

これらをサボるとリーダーにお尻を叩かれるので必死でしたが（笑）、おかげで「今はどこのフェーズにいるのか」「次は誰が何をすればいいか」がチーム全体でクリアになり、メンバーの自走を促すことができました。

改善3：小さく、とにかく小さく（レビュー参加のハードルを下げる）

8月の「巨大PRでレビュー地獄」の反省から、PRをとにかく細かく分ける作戦に出ました。
これはフロー効率を上げるだけでなく、「レビューのハードルを下げて、チームメンバーを巻き込みやすくする」 ための重要な戦術です。

• 意味のある最小単位： ファイルごと、機能ごとなど、とにかく細かくPRを作成。

• ユーザー影響のない差分は先にマージ： 「リファクタリング」や「DB定義の先行リリース」など、ユーザーに影響のない差分は先にガンガン出してサイクルを回しました。

これにより、「今このファイルの話をしてるんだな」というのが実装者・レビュアー共に分かりやすくなり、フロー効率が爆上がりしました。巨大なPRは誰も見たくありませんが、小さいPRならサクッと見てくれます。
終わったものから脳のリソース（メモリ）を解放できるので、精神的にもかなり楽になりました。

【成果】 数字で見る劇的な変化

これらの改善策を講じた結果、8月から10月にかけてチームの開発生産性は劇的に向上しました。
ただの肌感ではありません。数字にはっきりと表れています。

指標	8月（改善前）	10月（改善後）	変化率
1PRのコード行数 (中央値)	242行	73行	約1/3に減少
1PRのリードタイム (中央値)	3.95日	1.84日	約1/2に短縮

PRを小さくし、チームで回すフローを作ったことで、ここまで数字が変わりました。 具体的に何がこの数字（時間短縮）に効いたのかを分析すると、以下の3点が挙げられます。

1. レビュアーの認知負荷が下がった： 「70行」なら隙間時間で即レビューできますが、「240行」だと「後で腰を据えて見よう」と後回しにされがちでした。ここが解消されたのが最大の要因です。
2. 手戻りコストの最小化： 小さい単位で合意が取れているため、大きな認識齟齬による「全部やり直し」がなくなりました。
3. 待ち時間の削減： 「共通地図」で次やるべきことが明確だったため、「レビュー待ちの間に別のタスクを進める」という並列稼働がスムーズになりました。
   さらに、10月末にリリースした「某ECカートシステムのアップデート対応」では、リリース後1週間、既存機能への影響も含めてバグ報告ゼロという安定稼働を実現できました。

PjMをやってみて変わったこと

この激闘の2ヶ月を経て、僕の中で何かが確実に変わりました。
組織から期待される役割に対して以下のような成長実感がありました。

1. 視野が広がった（要件理解力・設計力）：
   これまでは「自分のタスク」しか見えていませんでしたが、「全体で見た時にこのタスクが来週のボトルネックになるか？」「誰のヘルプに入るべきか？」という視点が持てるようになりました。
2. 伝える力・協働性の向上：
   チーム内外との折衝やMTGのファシリテーションを任せてもらったことで、必要な情報を必要な粒度で伝える力が伸びたと感じています。
3. 信頼の獲得：
   何より嬉しかったのは、リーダーから 「安心して見ていられる」 という全幅の信頼をいただけたことです。

正直、PJMをやっていなかった数ヶ月前より圧倒的に負荷がかかっています。自分の足りないところがモロに露呈します。
でも、毎週いいフィードバックをもらえて、日々が充実しています。ビビりすぎずに飛び込んでみて、やりきってよかったなと思っています。

まとめ：僕は誰かのバンパーになりたい

エンジニア2年目でプロジェクト進行を任されるのは、かなり大変なチャレンジでした。
でも、僕がギリギリ炎上せずに走れたのは、周りのメンバーが「バンパー」のように、僕が道を踏み外しそうになるたびに受け止め、軌道修正してくれたからです。

イレギュラーが起きた時も受け止めてくれたチーム、組織、会社に感謝です。

いつか僕も、後輩たちがチャレンジする時に、安心してぶつかっていけるような「バンパー」になりたいなと思います。

PjM、大変だけど楽しいです。
これからチャレンジする人、「どんとこい」 の精神でいきましょう！