「PLになったけど、正直つらい」「自分はPLに向いていないのでは？」――そう感じているのは、あなただけではありません。
筆者はSIerでエンジニア10年、PL3年目の「平凡PL」です。PLになって一番しんどかったのは、技術の問題ではなく顧客・ユーザーとの調整と説明でした。この記事では、PLがつらくなる理由と、向き・不向きの見極め方、そして「つらい」を軽くする具体策をまとめます。
PLがつらいと感じる5つの理由
1. 「作る」から「説明して合意をつくる」に仕事が変わる
メンバー時代は、正しく設計して正しく作れば評価されました。PLになると、仕様変更の影響説明、遅延の報告、ユーザー部門間の意見調整など、人に説明して納得してもらう仕事が中心になります。ここで戸惑う人が一番多いと感じます。
2. 板挟みになる
顧客からは「早く・安く・もっと機能を」、PMや上司からは「予算と期限は守れ」、メンバーからは「その仕様変更は無理です」。PLはこの三方向の要求がぶつかる場所に立っています。
3. 責任は重いのに、決定権は限られる
スケジュールや品質の責任はPLに来る一方で、予算や体制を変える権限はPM側にあることが多く、「自分ではどうにもできないことで責められる」状況が起きがちです。
4. 自分の作業時間がなくなる
会議・調整・レビューで日中が埋まり、自分の作業は夜に回る。技術が好きでエンジニアになった人ほど、ここでストレスを感じやすいです。
5. 成果が見えにくい
トラブルを未然に防いでも「何も起きなかった」だけなので、評価されにくい。PLの仕事は、うまくいくほど目立たない仕事でもあります。
PLに向いている人・向いていない人
| 向いている傾向 | 向いていない傾向 |
|---|---|
| 相手の言いたいことを整理するのが苦にならない | 自分の手で作ることに一番やりがいを感じる |
| 多少曖昧な状況でも「とりあえず決めて進める」ができる | 答えが決まらない状況が強いストレスになる |
| チームで成果を出すことにやりがいを感じる | 自分の技術力で評価されたい |
| トラブル時に淡々と事実を集められる | 人に悪いニュースを伝えるのが極端に苦手 |
ただし、これは「今の時点での傾向」にすぎません。筆者も最初から調整が得意だったわけではなく、場数を踏んで少しずつ慣れていきました。向いていない＝できない、ではありません。
PLの「つらい」を軽くする具体策
- 説明は「結論→理由→選択肢」の順にする：顧客への説明は、背景から話すより結論から。「A案なら納期どおり、B案なら2週間遅れ」と選択肢で示すと合意が早くなります。
- 悪い報告ほど早く出す：遅延やトラブルは、小さいうちに共有したほうが結果的に楽です。隠すほど説明コストが膨らみます。
- 決められないことはPMに上げる：予算や体制の問題は、PLが抱え込まずPMにエスカレーションする。それはPMの役割です（PLとPMの違い）。
- 議事録で「決まったこと」を残す：言った・言わないの揉め事を減らすだけで、調整の負担はかなり下がります。
- 自分の作業を減らす：PLが実装まで抱えると必ず詰まります。任せられる作業はメンバーに渡しましょう。
それでもつらいなら：選択肢は社内だけではない
工夫してもつらさが続くなら、それは個人の問題ではなく環境の問題かもしれません。
| 選択肢 | こんな人に |
|---|---|
| 社内で役割を変える（技術寄りのポジションへ） | 調整より設計・開発に集中したい |
| PMを目指す | 全体を見て仕組みをつくる方が合っている |
| 副業で社外の経験を積む | いきなり環境を変えるのは不安 |
| 転職で環境を変える | 体制や顧客との関係性そのものに無理がある |
PL経験は、社外でも評価されやすい経験です。いきなり転職を決める必要はありませんが、「自分の経験が外でどう評価されるか」を知っておくだけでも、気持ちはかなり楽になります。
まとめ
- PLがつらい一番の理由は、仕事が「作る」から「説明して合意をつくる」に変わること
- 向き不向きはあるが、説明の型や早めの報告でかなり楽になる
- それでもつらいなら、役割変更・副業・転職など社外も含めて選択肢を持っておく
執筆：平凡PL（SIer勤務・エンジニア歴10年／PL歴3年）
コメントを残す