実装だけの人が、PM要素を少しずつ増やすには
金曜夕方、実装は終わったのに前へ進まない
「コードは書けた。でも、これ次に誰が決めるんだっけ…？」
金曜の夕方。機能の実装はだいたい終わった。テストも通った。レビュー依頼も出せそうだ。
なのに、最後の一歩で手が止まる。
仕様の一部がまだ曖昧。画面文言は誰がOKを出すのか分からない。リリース日も「できれば来週」くらいの温度で止まっている。ここで黙ってレビューに出すこともできる。でも、たぶん戻ってくる。いや、かなり戻ってくる😅
こういう時に、「PMが決めてくれればいいのに」と思うことはある。あるよね。実装者としては、実装に集中したい。進行管理まで持つのは重いし、責任だけ増えそうで怖い。
ただ、ここで増やしたいPM要素は、いきなり全体責任を背負うことではない。今の実装が止まりそうな場所を、少しだけ先に見える形にすること だ。
たとえば、レビュー依頼の前にこう書く。
実装は完了しています。残りは、文言の最終判断、公開日の確定、エラー時の通知文面です。
これだけで、空気が変わる。自分がPMになるわけではない。でも、現場は次に何を決めればよいか見える。
PMIの2025年版 Pulse of the Profession は、プロジェクト人材に必要な business acumen、つまり事業や価値の見え方を、単なるトラブル対応から戦略的な価値づくりへ進む力として扱っている。難しく聞こえるけれど、実装者の現場に置き換えるなら、「自分の作業が、相手の判断や成果にどうつながるか」を少し見に行く力だ。
この記事では、「PMになる方法」ではなく、実装者のまま小さく持てるPM要素を整理する。肩書きを変える話ではない。金曜夕方に止まった仕事を、月曜に少し進めやすくする話だ。
PM要素は、肩書きより先に一言で始まる
PM要素という言葉を聞くと、スケジュール管理、議事録、顧客調整、メンバー管理が一気に頭へ並ぶ。重い。全部まとめて来ると、そっと閉じたくなる。
でも、実装者が最初に持つなら、もっと小さい方がいい。仕事を増やすのではなく、止まりそうな場所に一言置く。その一言が、結果的に進行を助ける。
Scrum Guide では、開発者もスプリントの計画、品質、日々の計画調整、プロとしての説明責任を持つと整理されている。つまり、作る人は「言われたものを作るだけ」の存在ではない。もちろん、最終判断者になるという意味ではない。作る人だからこそ、どこで止まりそうか、どこが曖昧かに早く気づける。
まず見るのは、論点が散らばっていないか
金曜夕方の例なら、困っていることは一つに見えて、実は三つに分かれている。
- 仕様として決めること
- 公開日として決めること
- エラー時の対応として決めること
これを「まだいろいろ未確定です」と書くと、相手も動きにくい。どこから手をつければいいか分からないからだ。
一方で、「残りは3点です」と分けると、急に動きやすくなる。文言はプロダクト側、公開日は責任者、エラー通知は運用担当。誰に聞くかも見えてくる。
PM要素の最初の一歩は、答えを出すことではなく、未決事項を分けること だ。これなら、実装者の延長でできる。むしろ実装している人の方が、どこが曖昧かを見つけやすい。
「決める人」を見つけるだけでも前へ進む
次に見るのは、誰が決めるかだ。
現場では、相談相手と決定者が違うことがよくある。毎日やり取りしている担当者は気さくで話しやすい。でも、その人がリリース日を決められるとは限らない。画面文言を見てくれる人と、公開可否を決める人も違うかもしれない。
ここを曖昧にしたまま進めると、レビューで「確認します」が増える。確認します、確認します、確認します。気づいたら一週間が消える。正直、かなりしんどい。
だから、実装者が持つPM要素としては、こう聞くだけで十分なことがある。
この3点は、それぞれ誰に最終確認を取ればよさそうですか？
これは仕切りすぎではない。判断を奪っているわけでもない。止まる前に、確認先を明らかにしているだけだ。
増やすのは仕事量ではなく、止まりにくさ
役割を広げようとすると、つい「もっと持つ」「もっと手伝う」方向へ行きがちだ。議事録も書く。進行も見る。調整も入る。資料も作る。
短期的には喜ばれる。でも、境界がないまま拾い続けると、ただ便利な人になる。便利な人は助かるけれど、評価や単価の根拠に変えるのが難しい。なぜなら、「何を前に進めたのか」が見えにくいからだ。
増やしたいのは仕事量ではない。増やすべきなのは、チームが止まりにくくなる動き だ。
PMIの2024年版 Pulse of the Profession では、変化の多い環境では、組織がチームに柔軟性を持たせ、継続学習へ投資することがプロジェクト成果につながると整理されている。ここでいう柔軟性は、なんでも引き受けることではない。状況に合わせて、進め方を調整できることだ。
完了条件を一段だけはっきりさせる
止まりにくさを作るなら、完了条件を見るのが効く。
「実装完了」と言っても、相手にとっての完了は別かもしれない。コードがマージされること。テスト環境で確認できること。本番に出ること。問い合わせが来た時に説明できること。ここがズレると、こちらは終わったつもりでも、相手はまだ不安なままになる。
だから、レビュー依頼の最後にこう添える。
今回の完了条件は、テスト環境で文言確認が終わり、公開日が決まり、本番反映の担当者が決まるところまで、という認識です。
少し長い。でも、これがあると話が早い。違っていれば、その場で直せる。黙って進めてあとでズレるより、ずっと軽い。
完了条件を決めるのはPMだけの仕事に見えるかもしれない。ただ、実装者も「この状態なら安心して渡せる」を言葉にできる。そこまでが、品質や進行の一部になる。
抱え込む人と、前に出す人は違う
ここで気をつけたいのは、抱え込まないことだ。
PM要素を増やすと聞いて、全部を自分で解決しようとすると危ない。文言も決める。公開日も詰める。運用担当にも根回しする。そこまでやると、いつの間にか自分の作業が増え、責任範囲も曖昧になる。
やることは、全部を背負うことではない。未決事項を分け、確認先を聞き、完了条件を一段はっきりさせる。ここまでで止めていい。
PM要素は、責任を奪うことではなく、責任者が判断しやすい材料を出すこと だ。この線を越えない方が、長く続けやすい。
単価や評価につなげるなら、動きを記録する
小さなPM要素は、やった本人ほど軽く見がちだ。
「ちょっと整理しただけです」
「軽く確認しただけです」
「ついでに書いただけです」
分かる。実装に比べると、成果物として見えにくい。コード行数も増えないし、画面も変わらない。だから、自分でも価値として数え忘れる。
でも、現場を止まりにくくした動きは、ちゃんと記録しておいた方がいい。週報、月次報告、更新面談、単価相談の時に、そのまま材料になる。
「やったこと」ではなく「前に進んだこと」で残す
記録する時は、「会議に参加した」「議事録を書いた」だけだと弱い。作業名で終わるからだ。
代わりに、こう残す。
- 未決だった公開日の判断者を整理し、確認待ちを1日に短縮した
- レビュー前に文言、公開日、運用確認を分け、差し戻し範囲を小さくした
- 完了条件を事前に合わせ、実装後の追加確認を減らした
少し大げさに見えるかもしれない。でも、盛っているわけではない。自分が何を前へ進めたのかを、相手が分かる言葉に変えているだけだ。
IPAの「DX動向2025」は、DXの状況を戦略、技術、人材の3つの視点で見ている。技術だけではなく、人材や進め方も成果に関わる。実装者の役割拡張も同じで、コードだけではなく、判断が進む状態を作ったことまで見えるようにしたい。
やらないことも一緒に書く
もう一つ、役割を広げる時に効くのが「今回はここまでは持たない」を書くことだ。
たとえば、文言の最終判断を自分で抱えない。公開日の決定も自分で決めない。運用担当への周知も、必要なら担当者を確認するところまでにする。冷たく見えるかもしれないけれど、これは線引きだ。
実装者が前に出るほど、相手から見ると「この人に頼めば全部進むかも」と見えやすい。そこで全部を拾うと、次から自然に自分の範囲になる。最初はありがたくても、後でしんどくなるやつだ。
だから、週報やレビュー依頼には、前に出したことと持たないことをセットで残す。
未決事項は整理済み。最終判断はプロダクト側、公開日は責任者、運用周知は担当者確認後に進める。
この一文があると、助ける動きと責任範囲が分かれる。小さくPM要素を持つほど、持たない範囲も言葉にする。 ここまでできると、便利な人ではなく、進行を整える人として見られやすくなる。
最初の一週間で試すなら、この3つでいい
明日から全部変える必要はない。むしろ、いきなり大きく変えると続かない。
最初の一週間で試すなら、次の3つで十分だ。
1つ目。レビュー依頼の前に、「残っている未決事項」を1〜3個に分ける。
2つ目。それぞれについて、「誰が決めるか」を聞く。
3つ目。最後に、「今回の完了条件はここまでで合っているか」を確認する。
これだけで、仕事の見え方は変わる。自分が何を作ったかだけでなく、何を止まりにくくしたかが見える。
金曜夕方の画面に戻るなら、やることは大きくない。レビュー依頼に3行足すだけだ。
実装は完了しています。残りの確認は、文言、公開日、運用時の通知文面です。
それぞれの最終確認先と、今回の完了条件が「テスト環境確認まで」か「本番反映まで」かを合わせたいです。
たったこれだけ。でも、これがあると月曜の会話が変わる。相手も動きやすいし、自分も「どこまで持つべきか」で迷いにくい。
最後に
PM要素を増やすことは、いきなりPMになることではない。進行管理を全部背負うことでもない。
まずは、実装の延長で止まりそうな場所を一つ見つける。未決事項を分ける。決める人を確認する。完了条件を一段はっきりさせる。そこからで十分だ。
役割は、大きな肩書きから始まるとは限らない。金曜夕方に止まった仕事へ、月曜のための3行を足す。その小さな前進力が、次の評価や単価の根拠になっていく。
ここまで読んで、「自分がすでにやっている動きが、役割として数えていいのか分からない」と感じたなら、まずは一度書き出してみてほしい。実装以外に、誰の判断を助けたか。どの手戻りを減らしたか。どの曖昧さを先に見つけたか。
そこが見えると、広げる範囲も、断る範囲も、少し決めやすくなる。まずは自分の仕事の中にある小さな前進力を、一緒に見つけてみませんか？✨
