PdMがコードを書ける時代、エンジニアとの棲み分けをどう決めるか
職種で線を引くと必ずもめます。「本番に出るコードかどうか」で引くと運用できます。そのまま社内で使えるルール文例と、導入時の反発への対処をまとめました。
PdMがPRD（要件定義書）を書いて渡す。これまではそこで役割が終わっていました。今は、そのPRDをもとに自分で動くものを作れます。問題は、それを会社でやろうとしたときです。 どこまでPdMがやり、どこからエンジニアの領域なのか。この記事では、実際に運用できるルールの決め方をまとめます。
まず結論
棲み分けの基準は「職種」ではなく「そのコードが本番に出るかどうか」で引きます。
「PdMはここまで、エンジニアはここから」と職種で線を引くと、必ずもめます。人によって技術力が違うからです。
一方、「本番環境に出るコードかどうか」で引けば、誰がやっても同じ基準になります。 これが実務で回るルールです。
自分とAIでできることが多い
- 自分や友達だけで使うツール
- 学校や会社の中だけで使うツール
- アイデアを試すための試作品
- 利用者が少ない小さなサービス
専門家の知識が重要になる
- 他人の個人情報を預かる
- お金のやりとりをする
- 利用者が一気に増えたとき
- 動かなくなったときの復旧
なぜ職種で線を引くと失敗するのか
よくある決め方と、その問題点を挙げます。
| 決め方 | 何が起きるか |
|---|---|
| 「PdMはコードを書かない」 | 試作もできなくなり、AIを使う利点が消える |
| 「PdMも自由に書いていい」 | 品質基準がバラバラになり、エンジニアが後始末を抱える |
| 「技術力のある人だけ書いていい」 | 誰が該当するのかを毎回もめる。評価の話になってしまう |
どれも運用が続きません。 判断が人に依存するからです。
実際に回る3つの型
現場で採用されている型を3つ挙げます。組織の規模に応じて選んでください。
型1：試作専用の置き場を分ける（少人数向け）
もっとも簡単で、もっとも事故が少ない方法です。
本番のコードとは完全に別の場所に、試作用の置き場を用意します。PdMやデザイナーはそこで自由に作ります。本番側には触れません。
- メリット — 事故が起きようがない。承認プロセスも不要
- デメリット — 試作の成果を本番に持っていくとき、作り直しになる
- 向く組織 — エンジニアが数人の会社、スタートアップ
作り直しは無駄に見えますが、そうではありません。 試作の目的は「必要かどうかを確かめること」なので、確かめ終わった時点で役目を終えています。
型2：本番に出す前に必ずレビューを通す（中規模向け）
PdMも本番のコードを触れますが、エンジニアの確認を通らないと反映されないという形にします。
- メリット — 試作から本番までが地続きになる
- デメリット — レビューする側の負担が増える。ここを軽く見ると破綻する
- 向く組織 — エンジニアが10人以上いて、レビューの文化がある会社
導入するなら、レビュー担当の工数を正式に確保してください。 「空いた時間で見て」では続きません。
型3：触ってよい範囲を機能単位で決める（大規模向け）
「表示まわりは触ってよい、データを扱う部分は触らない」のように、領域で区切ります。
- メリット — 大人数でも運用できる
- デメリット — 区切りの定義とメンテナンスに手間がかかる
- 向く組織 — 部門が分かれている規模の会社
そのまま使えるルール文例
型1を採用する場合の文例です。このままSlackやドキュメントに貼って使えます。
【AIツールを使った試作についてのルール】
■ やってよいこと
・試作用の置き場で、自由に作って構いません
・社内メンバーだけに見せるのは自由です
・作ったものを打ち合わせで共有するのも自由です
■ 必ず守ること
・本番環境には反映しません
・実在の顧客データは使いません（サンプルデータを作って使ってください）
・社外の人には共有しません
・「試作品です」と明示して共有します
■ 本番に持っていきたくなったら
・作り直す前提で、エンジニアに相談してください
・そのとき、次の3つを一緒に渡してください
1. 動く試作品
2. 誰に使ってもらい、どんな反応だったか
3. 自分で気づいている未対応の部分
■ 判断に迷ったら
・他人の個人情報を扱う → 必ず相談
・お金のやりとりが発生する → 必ず相談
・社外の人が触れる → 必ず相談
「必ず守ること」の4項目が要です。 ここさえ守られていれば、試作で事故は起きません。
試作専用の置き場を、具体的にどう用意するか
型1を採用する場合、実際の準備はこれだけです。
- 1
本番とは別の置き場を1つ作る
GitHub なら prototypes という別のリポジトリを1つ。本番のコードとは完全に分けます。
- 2
サンプルデータを用意する
実在の顧客データは使いません。名前や連絡先がダミーのデータを、エンジニアに作ってもらいます。
- 3
無料枠のアカウントを用意する
Supabase（データの保存先）と Vercel（公開先）を、試作専用に別アカウントで作ります。本番と混ざらないようにするためです。
- 4
ルールを1枚のドキュメントにする
後述の文例をそのまま貼れば十分です。
3番目が重要です。 本番と同じアカウントを使うと、操作を間違えたときに本番に影響が出ます。試作専用に分けておけば、何をしても事故になりません。
PdM側に渡す最初の指示
準備ができたら、PdMには次のように伝えます。
試作用の置き場を用意しました。ここでは自由に作って構いません。
・作業する場所: （リポジトリのURL）
・データの保存先: （試作専用のSupabaseプロジェクト）
・公開先: （試作専用のVercelプロジェクト）
・使うデータ: sample-data フォルダのダミーデータを使ってください
本番のアカウントには接続しないでください。
接続情報を求められたら、上に書いたものだけを使ってください。
「本番のアカウントには接続しない」を明記してください。 AIに「データを保存したい」と頼むと、手元にある接続情報を使おうとすることがあります。
誰が何をやるかの整理
役割分担を表にすると、話が早くなります。
| 工程 | PdM | エンジニア |
|---|---|---|
| 何を作るか決める | ◎ | ○ |
| PRDを書く | ◎ | — |
| 試作品を作る | ◎（ここが新しい） | ○ |
| 使ってもらって確かめる | ◎ | — |
| 本番の設計 | — | ◎ |
| 本番の実装 | — | ◎ |
| 安全性の確認 | — | ◎ |
| 運用・障害対応 | — | ◎ |
変わったのは「試作品を作る」の行だけです。 それ以外の分担は、実はほとんど変わっていません。
ここを誤解して「PdMが実装までやる」と考えると、必ず衝突します。
PdMの仕事は、どう変わるのか
棲み分けのルールとは別に、仕事の中身も変わります。ここを整理しておかないと、ルールだけ作っても機能しません。
従来の流れ
要求を聞く → 要件に落とす → PRDを書く → 渡す → 待つ → 出てきたものを確認する
「渡す」と「待つ」の間が、いちばん時間がかかっていました。 そしてここで認識のズレが生まれ、手戻りが発生していました。
これからの流れ
要求を聞く → 要件に落とす → PRDを書く → 自分で試作する → 検証する → 渡す
「自分で試作する」と「検証する」が挟まります。 渡す前に、需要があるかを確かめられるようになりました。
重要度が上がった仕事
| 仕事 | これまで | これから |
|---|---|---|
| 要求を掘る | ○ | ◎ 重要度が上がった |
| PRDを書く | ◎ | ◎ さらに重要 |
| 実装を説明する | ◎ | △ 動くもので伝わる |
| 検証する | △ 実装後にしかできない | ◎ 作る前にできる |
| 優先順位をつける | ◎ | ◎ |
PRDの重要性は、下がるどころか上がりました。 これまでPRDは人が読む文書で、曖昧でも対話で埋められました。今はPRDがそのままAIへの入力になるので、曖昧なPRDからは曖昧なものしか出てきません。
書き方は要求と要件は違う｜PRDの書き方にまとめました。
「作れる」の意味を取り違えない
ここが重要です。PdMが作れるようになったのは、試作品までです。
自分とAIでできることが多い
- 自分や友達だけで使うツール
- 学校や会社の中だけで使うツール
- アイデアを試すための試作品
- 利用者が少ない小さなサービス
専門家の知識が重要になる
- 他人の個人情報を預かる
- お金のやりとりをする
- 利用者が一気に増えたとき
- 動かなくなったときの復旧
「実装までPdMがやる」と考えると、必ず衝突します。 本番のコードは、安全に動かし続ける責任とセットです。試作品にはその責任がありません。別物として扱ってください。
PdMが知っておくべき技術知識
全部を学ぶ必要はありません。判断に必要な範囲だけで十分です。
- データをどういう単位で保存するか（同じ情報が繰り返されるなら表を分ける）
- 誰がどのデータを見られるか（画面で隠すだけでは守れない）
- 個人情報を扱うと、何が必要になるか
- 後から変えにくいのはどこか（データの持ち方は変えにくい）
いずれも実装できる必要はありません。「これはどうなっていますか」と聞けるようになれば十分です。 それぞれの中身はデータベースとは？非エンジニアが知っておくべき最小限のことで説明しています。
導入するときに起きる反発と、その対処
正直に書きます。ルールを入れようとすると、反発が出ます。
エンジニア側から出る反発
「後始末をさせられるのでは」
これはもっともな心配です。実際、AIが書いたコードの問題は表面化しにくいという調査もあります。
48%
AIが書いたコードを「必ず確認している」開発者の割合です。確認の負担が誰にかかるのかを決めないまま導入すると、この不安は現実になります。
対処：型1（試作専用の置き場）から始めてください。 本番に混ざらないと保証されていれば、この心配は消えます。
「品質基準が下がる」
対処：試作品は品質基準の対象外だと明示します。 「これは検証用であり、本番の基準は適用しない」と最初に合意しておきます。
PdM側から出る反発
「せっかく作ったのに作り直すのは無駄では」
対処：試作の目的を再確認します。 目的は「必要かどうかを確かめること」であって、資産を作ることではありません。確かめ終わった時点で、役目は果たしています。
経営側から出る質問
「開発費は下がるのか」
対処：正直に答えてください。 開発費そのものは大きく下がりません。下がるのは**「要らないものを作ってしまう損失」**です。ここを混同すると、期待値がずれます。
始め方
いきなり全社ルールを作らないでください。失敗します。
- 1
1つのチームで、1つの試作から始める
全社展開は後回しにします。まず1件、成功例を作ります。
- 2
型1（試作専用の置き場）で運用する
本番に混ざらない形なら、反対されにくくなります。
- 3
試作をエンジニアに渡してみる
ここで初めて、渡し方の課題が具体的に見えてきます。
- 4
起きた問題をもとにルールを直す
机上で作ったルールより、実際の問題から作ったルールのほうが守られます。
- 5
他チームに広げる
実績とルールがセットで説明できる状態になってから広げます。
判断に迷ったときの基準
最後に、シンプルな基準を示します。次のどれかに当てはまったら、PdMだけで進めないでください。
- 実在する顧客・社員の個人情報を扱うここが該当したら公開しない
- お金のやりとりが発生するここが該当したら公開しない
- 社外の人がアクセスできる状態にするここが該当したら公開しない
- 止まると業務が止まる
- 使う人が部署をまたいで増えそう
よくある質問
Q. PdMがコードを書けると、エンジニアの評価はどうなりますか？ A. 評価軸は変えないほうがよいと考えています。**エンジニアの価値は「書く速さ」ではなく「安全に動かし続ける判断」**にあります。ここは変わっていません。
Q. 試作品を作るのに、どれくらい時間を使ってよいですか？ A. 目安は数時間から2日です。それ以上かかるなら、作ろうとしているものが大きすぎます。範囲を狭めてください。
Q. デザイナーも同じルールでよいですか？ A. 同じで構いません。職種ではなく「本番に出るかどうか」で線を引いているので、そのまま適用できます。
Q. 情報システム部門にどう説明すればいいですか？ A. **「試作専用の置き場を使い、実データは扱わず、社外に出さない」**という3点を先に伝えてください。多くの懸念はこれで解消します。
Q. エンジニアが「そもそも反対」と言ったら？ A. まず理由を聞いてください。多くの場合、「後始末を押し付けられる」という懸念です。型1から始めることを提案すれば、話が進みやすくなります。
まとめ
- 棲み分けは**職種ではなく「本番に出るかどうか」**で引く
- 型は3つ。少人数なら試作専用の置き場を分ける型1から
- 変わったのは**「試作品を作る」の分担だけ**。それ以外は従来どおり
- 反発の多くは**「後始末を押し付けられる」という懸念**。型1で解消できる
- 個人情報・お金・社外公開の3つは、例外なく相談する
- 全社ルールを先に作らず、1チーム1試作から始める