カテゴリー: 現場の話

生成AIを開発現場で使うのは、もう珍しいことではなくなりました。一方で、SIerの現場では「セキュリティ的に使っていいのか」「品質は大丈夫か」と、導入に慎重なところも多いはずです。

この記事では、PLの立場から「生成AIをどこで使うと効果があり、どこに注意すべきか」を整理します。

データで見る：開発者のAI利用は「使うけど信用しきれない」

Stack Overflowが2025年に実施した開発者調査（177か国・4.9万人以上が回答）では、次のような結果が出ています。

• 開発でAIツールを使っている、または使う予定の開発者は84%（2024年は76%）
• AIの出力の正確さを信用していない開発者は46%（2024年は31%）
• 不満の上位は「AIが生成したコードのデバッグに時間がかかる」（45%）

つまり、利用は広がっているものの、「そのまま信じて使える」段階ではないというのが現場の実感です。PLとしては、この前提でルールを考える必要があります。

PL業務で生成AIが効きやすい場面

業務	使い方の例	効果
議事録・報告書	会議メモから議事録のたたき台を作る	作成時間の短縮
顧客への説明資料	技術的な内容を、非エンジニア向けの言葉に言い換える	説明の分かりやすさ向上
要件の整理	ヒアリング内容から要件の抜け漏れ候補を洗い出す	確認漏れの防止
見積り・WBS	作業分解のたたき台を作る	計画づくりの初速アップ
テスト観点	仕様からテスト観点の候補を出す	観点漏れの防止
レビュー	コードや設計書の気になる点を事前に洗い出す	レビュー負荷の軽減

筆者がPLとして一番時間を使うのは顧客・ユーザーとの調整と説明なので、説明資料の言い換えや議事録のたたき台は特に相性がいいと感じる領域です。

導入時に注意すべきこと

1. 顧客情報・機密情報の扱い

SIerでは顧客の情報を扱うため、最も注意が必要です。入力データが学習に使われない設定や法人向けプランになっているか、会社や顧客との契約で外部サービスの利用が認められているかを必ず確認しましょう。

2. 出力のレビュー責任

AIの出力は「たたき台」と位置づけ、最終的な確認は人が行うルールにします。上の調査でも、AIが作ったコードのデバッグに時間がかかるという声が多く、レビューを省けば手戻りが増えます。

3. チーム内のルール統一

人によって使い方がバラバラだと、品質のばらつきや情報漏えいのリスクにつながります。「使っていい業務・使ってはいけない情報・レビューの方法」を簡単なルールにまとめておくと安心です。

生成AI時代に、PLの価値はどう変わる？

資料作成や作業分解のたたき台はAIが作れるようになっても、顧客と合意をつくることや、AIの出力を見て「これで進めて大丈夫か」を判断することは、引き続き人の仕事です。

むしろ、AIで作業時間が減るぶん、調整・判断・リスクの先読みといった「PLにしかできない仕事」の比重が大きくなっていくと考えています。生成AIの活用経験は、今後の転職や副業でもアピールしやすいポイントになるはずです（エンジニアが年収を上げる方法）。

まとめ

• 開発者の84%がAIを使う（予定含む）一方、46%は正確さを信用していない
• PL業務では議事録・説明資料・要件整理・テスト観点で効きやすい
• 機密情報の扱い、レビュー責任、チームのルール統一が導入の前提
• AI時代こそ、合意形成と判断というPLの価値が大きくなる

参考：Stack Overflow 2025 Developer Survey（プレスリリース） ／ 2025 Stack Overflow Developer Survey：AI

執筆：平凡PL（SIer勤務・エンジニア歴10年／PL歴3年）

「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年）

「PLとPMって、結局なにが違うの？」――SIerで働いていると、一度は聞かれる（あるいは自分でも迷う）質問です。

教科書的な定義はネットにたくさんありますが、この記事ではSIerでエンジニア10年・PL3年目の筆者（平凡PL）が、現場の実感ベースで違いを整理します。これからPLを任される人、PMを目指すか迷っている人の判断材料になればうれしいです。

結論：PLは「案件を前に進める人」、PMは「前に進められる環境をつくる人」

筆者の実感を一言でまとめると、こうなります。

PLは案件の推進と調整。PMは管理作業と、メンバーが案件を進めやすいような制度・環境づくり。

PLは「このプロジェクトを、この期限で、この品質で終わらせる」ために、現場の最前線で手と口を動かす役割です。一方PMは、予算・体制・契約・リスクといったプロジェクトの土台を整え、PLやメンバーが迷わず動ける状態をつくる役割です。

PLとPMの違いを表で比較

項目	PL（プロジェクトリーダー）	PM（プロジェクトマネージャー）
主なミッション	案件の推進・現場の調整	プロジェクト全体の成功責任・環境づくり
見ている範囲	担当チーム・担当工程	プロジェクト全体（予算・体制・契約含む）
主な相手	メンバー、顧客の担当者・ユーザー	顧客の責任者、社内の上長・他部署
代表的な仕事	タスク分解、進捗確認、仕様調整、レビュー、課題対応	計画策定、予算・要員管理、リスク管理、体制・ルールづくり
技術との距離	近い（設計・レビューに入ることも多い）	遠め（技術判断はPLに任せることが多い）
評価されやすい点	期限どおりに品質高く終わらせる	赤字・炎上を防ぎ、チームが回る仕組みをつくる

※会社やプロジェクト規模によって線引きは変わります。小規模案件ではPMがPLを兼ねたり、逆にPLがPM業務の一部を担ったりすることも珍しくありません。

PLの仕事：現場で一番大変なのは「調整と説明」

PLの仕事というと進捗管理を思い浮かべがちですが、筆者がPLになって一番大変だったのは顧客・ユーザーとの調整と説明です。

• 仕様変更の要望が来たとき、影響範囲とスケジュールへのインパクトを説明して落としどころを探る
• ユーザー部門ごとに言っていることが違うとき、論点を整理して合意を取りにいく
• 遅延やトラブルが起きたとき、原因と対策を「相手が納得できる言葉」で説明する

メンバー時代は「正しく作る」ことが仕事の中心でしたが、PLになると「正しく伝えて、合意をつくる」ことの比重が一気に上がります。技術力があるのにPLでつまずく人が多いのは、この切り替えが想像以上に難しいからだと感じています。

PLに求められるスキル

• 説明力・調整力：技術的な話を、顧客やユーザーの言葉に翻訳する力
• タスク分解と見積り：曖昧な要求を作業に落とし、現実的な計画にする力
• 技術的な判断力：設計やレビューで「これで進めて大丈夫か」を決める力
• 課題の早期発見：小さな違和感を放置せず、炎上前に手を打つ力

PMの仕事：メンバーが動きやすい「仕組み」をつくる

PMは、PLよりも一段引いた位置からプロジェクト全体を見ます。予算・要員・契約・リスクの管理に加えて、筆者が重要だと感じるのは「メンバーが案件を進めやすい制度や環境をつくる」役割です。

• 会議体や報告ルールを決めて、情報がきちんと上がってくる仕組みにする
• 体制や役割分担を整えて、特定の人に負荷が集中しないようにする
• 顧客の責任者と握るべきこと（スコープ、優先順位、判断者）を先に固めておく

PLが「目の前の案件を前に進める人」だとすれば、PMは「PLが前に進めやすい道を整備する人」です。PMの仕事がうまくいっていると、現場は驚くほどスムーズに回ります。

PLからPMへ：キャリアとしてどう考える？

SIerでは「メンバー → PL → PM」と段階を踏むのが一般的なキャリアパスです。ただし、PMに進むことだけが正解ではありません。

方向性	向いている人
PMへ進む	全体を俯瞰するのが好き、予算や体制づくりにやりがいを感じる
PLを極める	現場で案件を動かすのが好き、技術から離れすぎたくない
技術スペシャリストへ	調整よりも設計・技術判断に集中したい
社外に出る（転職・副業・独立）	PL経験を別の環境で活かしたい、収入や働き方を変えたい

PL経験は、社外でも評価されやすい経験です。「顧客調整をしながら案件を推進した」経験は、Web系企業や事業会社、フリーランス案件でも求められることが多いからです。このあたりの選択肢については、別の記事でくわしく整理していきます。

まとめ

• PLは案件の推進と調整、PMは管理と、メンバーが動きやすい環境づくり
• PLの一番の壁は「作る」から「説明して合意をつくる」への切り替え
• PLの次はPMだけではない。自分が何にやりがいを感じるかでキャリアを選べばいい

「PLになったけどつらい」「このままPMを目指すべきか迷う」という人は、まず自分がどの仕事にやりがいを感じているかを書き出してみるのがおすすめです。

執筆：平凡PL（SIer勤務・エンジニア歴10年／PL歴3年）