PMとエンジニアの責任分界 — CTO不在チームで「要求」と「技術判断」の境界をどう引くか
CTO不在のスタートアップで最も見落とされがちな組織課題は、「意思決定の仕組み」ではなく「役割の境界線」です。CTOがいないスタートアップの技術意思決定では意思決定オーナーマップやADRといった仕組みを解説しましたが、仕組みを設計しても、PMとエンジニアが「どこまでが自分の持ち場か」を認識していなければ機能しません。本稿では、意思決定の仕組みを一段階下げ、PMとエンジニアの間で「何を」「どこまで」分担するかという役割分担の粒度に焦点を当てます。
PMとエンジニアの間に生まれる「責任の押し付け合い／空白」
CTOがいるチームでは、技術的な要求とエンジニアリングの実行の間にCTOという緩衝材が存在します。CTO不在のチームでは、その緩衝材がなくなり、PMとエンジニアが直接向き合うことになります。ここで典型的に起きるのが次の3つのパターンです。
パターン1：押し付け合い
パフォーマンス低下やバグの増加が起きたとき、PMは「エンジニアの実装品質の問題」と捉え、エンジニアは「要件定義が曖昧だったせいで手戻りが多発した」と捉えます。双方の主張がどちらも部分的に正しいため、責任の所在が曖昧なまま対立だけが残ります。
パターン2：空白
「セキュリティ要件」「パフォーマンス目標」「エラーハンドリングの方針」など、機能要求に付随しない非機能要件は、PMの管轄にもエンジニアの管轄にも見えるため、誰も手を挙げません。空白は障害が起きて初めて顕在化します。
パターン3：越境の常態化
PMがAPIの実装方式やデータベース設計にまで踏み込んで指示を出す、あるいはエンジニアが機能の優先順位や事業インパクトの判断まで担ってしまう状態です。短期的には意思決定が速く見えますが、専門性のミスマッチによる判断ミスが蓄積しやすくなります。
これら3パターンに共通するのは、「What/Why」と「How」という異なる種類の判断が、明確な境界線なしに同じ会話の中で混在していることです。
要求（What/Why）と技術判断（How）の境界線
役割分担を機能させる出発点は、判断を2つのレイヤーに分けて捉えることです。
| レイヤー | 内容 | 主な担い手 | 典型的な問い |
|---|---|---|---|
| 要求（What/Why） | 何を実現したいか、なぜそれが必要か | PM | 「このユーザーのどんな課題を解くか」「なぜ今このタイミングでやるべきか」 |
| 技術判断（How） | どう実現するか、どんなトレードオフを取るか | エンジニア | 「どのデータ構造で持つか」「同期処理か非同期処理か」 |
この境界線自体は目新しいものではありません。プロダクトマネジメントの一般的な原則としても語られます。しかし実務でこの境界線が崩れる理由は、原則を知らないからではなく、境界線上に位置する判断が存在するためです。以下の3種類が特に境界を曖昧にします。
境界1：非機能要件
「レスポンスタイムは2秒以内」「同時接続1,000ユーザーに耐える」といった非機能要件は、事業上の要求（Why）でありながら、実現方法は完全に技術判断（How）です。PMが数値目標を持たずにエンジニアに「速くしてほしい」とだけ伝えると、エンジニアは何を優先すべきか判断できません。
境界2：技術的負債の返済
「このコードをリファクタリングすべきか」は一見するとHowの領域に見えますが、リファクタリングに投じる時間は新機能開発の時間を奪うため、実質的には事業の優先順位（What）に関わる判断です。
境界3：段階的な実装方針
「まず簡易版をリリースし、後で本格的な実装に置き換える」という判断は、事業上のスピード要求（Why）と技術的な実現可能性（How）の両方にまたがります。
境界線上の判断を「どちらか一方の管轄」と決めつけるのではなく、双方が数値・基準を持ち寄って合意するという運用に切り替えることが、越境や空白を防ぐ鍵になります。次のセクションで、この運用を非機能要件と技術的負債の優先順位付けに当てはめて具体化します。
非機能要件・技術的負債の返済を誰が優先順位付けするか
境界上の判断で最も頻繁にもめるのが、非機能要件と技術的負債の優先順位です。ここでの原則は「どちらか一方が決める」のではなく、PMが事業側の制約を数値で提示し、エンジニアが技術側の見積もりを数値で提示し、両者の交点で優先度を決めるという運用です。
具体的には、以下の3ステップで運用します。
- PMが事業インパクトを言語化する：「このリファクタリングを1ヶ月放置すると、機能追加のリードタイムがどれだけ伸びるか」をエンジニアに問い、影響度を事業言語（開発速度・障害頻度・顧客影響）に変換してもらう
- エンジニアが技術的な見積もりを提示する：返済にかかる工数、放置した場合に発生しうる障害の確率、影響範囲を提示する
- 両者が共通のスコアリング基準で優先度を決める：「事業インパクト × 発生確率 ÷ 対応工数」のような簡易スコアで、他の機能開発タスクと同じバックログに並べて比較する
このプロセスの要点は、技術的負債の返済を「エンジニアの内輪の都合」として切り離さず、事業のバックログと同じ土俵で優先度をつけることです。切り離してしまうと、技術的負債の返済は常に機能開発に押し出され後回しになります。技術的負債がスタートアップにもたらす具体的なリスクパターンは「技術負債」の正体とスタートアップで問題になるパターンで詳しく整理しています。
非機能要件についても同様です。「速くしてほしい」ではなく、「主要画面の初回表示を2秒以内にする」のように、PMが具体的な数値目標を持ち込むことで、エンジニアは実装方式の選択肢を絞り込めます。数値目標がない状態でエンジニアに丸投げすると、エンジニアは「どこまでやれば十分か」の判断がつかず、過剰最適化か過小対応のどちらかに振れがちです。
PMとエンジニアの協働を機能させる仕組み
役割分担の原則を理解しても、日々の運用に落とし込む仕組みがなければ形骸化します。実務で機能しやすい仕組みは以下の3つです。
共通言語の整備
PMとエンジニアが同じ言葉で会話できるよう、事業影響を表す指標（コンバージョン率・解約率・サポート問い合わせ件数）と技術指標（レスポンスタイム・エラー率・デプロイ頻度）を対応づけた一覧を作成しておきます。これにより「技術的に重要」という主張を、PMが理解できる事業言語に翻訳するコストが下がります。
定例での役割の明示
週次のプランニングやスプリントレビューで、議題ごとに「これはWhat/Whyの議論か、Howの議論か」を最初に明示します。会議の冒頭でこの区分を宣言するだけで、PMが実装方式に踏み込みすぎたり、エンジニアが事業判断まで担ってしまったりする越境を防げます。
意思決定ログの共有
境界上の判断（非機能要件の目標値、技術的負債の優先度決定）は、後から参照できる形で記録に残します。判断の記録がないと、同じ議論が数ヶ月ごとに再燃し、双方が「前回はこう決めたはずでは」と食い違う原因になります。
これらの仕組みは、CTOがいないスタートアップの技術意思決定で解説した技術定例・ADRの運用と組み合わせることで、意思決定の「型」と役割分担の「粒度」の両方が揃い、より機能しやすくなります。
アンチパターン：PMの丸投げとエンジニアの孤立
境界線の設計がうまくいかないチームには、対照的な2つの失敗パターンが見られます。
アンチパターン1：PMが技術を丸投げする
「技術のことはエンジニアにお任せ」という姿勢は、一見エンジニアへの信頼のように見えますが、実際には非機能要件や技術的負債の優先順位という「本来PMが持ち込むべき事業側の判断材料」を提供しないまま、判断そのものを放棄している状態です。エンジニアは事業インパクトの情報がないまま技術判断を迫られ、結果として「エンジニアの主観」だけで優先順位が決まっていきます。あとになって「なぜこの機能より先にリファクタリングをしたのか」とPMが疑問を持つ事態は、この丸投げが原因であることが多くあります。
アンチパターン2：エンジニアが事業から孤立する
逆にエンジニアが「言われた通りに実装するだけ」の姿勢に閉じてしまうと、非機能要件やアーキテクチャ上のリスクをPMに提起しなくなります。エンジニアが事業のKPIやユーザーの利用状況を把握していないと、「技術的に正しいが事業的には不要な最適化」に時間を使ってしまうこともあります。エンジニア組織がどの程度事業と接続できているかは、エンジニア組織の健全性をどう評価するかで扱った評価軸とも重なる論点です。
両方のアンチパターンに共通する処方箋は、境界上の判断を「相手に任せる」のではなく「双方が材料を持ち寄って合意する」プロセスに変えることです。丸投げも孤立も、突き詰めれば「相手の領域に踏み込まないようにする」という遠慮から生まれます。しかし境界上の判断はそもそもどちらか一方の専管事項ではないため、遠慮ではなく共同作業として扱う必要があります。これは個人の心構えの問題であると同時に、そう振る舞える組織構築ができているかという体制の問題でもあります。
AI時代の境界線：Howの一部はAIへ、エンジニアはWhatに近づく
ここまでの整理は「PMがWhat/Whyを、エンジニアがHowを担う」という前提に立っています。しかし、コード生成AI・AIコーディングエージェントの実用化が進むにつれて、この前提そのものが動き始めています。
実装（How）の相当部分——定型的なCRUD処理の生成、テストコードの作成、既存パターンに沿ったリファクタリング——は、すでにAIへ委譲できる領域が広がっています。この変化が意味するのは、単に「開発が速くなる」ことではありません。エンジニアの役割の重心が、正しく実装できることから、何を実装させ、AIの出力をどう検証・統合するかを判断できることへ移っていくということです。これは実質的に、エンジニアの持ち場がHow側からWhat側へ一歩近づくことを意味します。
この変化がPM/PdMにもたらす機会は明確です。これまでPMは、実装コストや技術的な実現可能性を気にして機能要求を控えめにしたり、実装の詳細をエンジニアと調整したりすることに時間を割く必要がありました。エンジニアがWhat側の判断——「このユーザー課題に対してどんな機能が有効か」「AIが生成した実装案は事業要求を満たしているか」——にも関与できるようになると、PM/PdMは実装の詳細から解放され、Why（なぜそれをやるべきか、事業上のインパクトは何か）によりリソースを集中できる環境を作りやすくなります。これは「PMがHowを手放す」というより、「組織としてPM/PdMがWhyに集中できるよう、エンジニアの持ち場をWhat寄りに再設計する」ことに近い変化です。
ただし、注意すべき点が2つあります。第一に、AIに委譲できるのはHowの一部であり、全てではないということです。アーキテクチャ判断・非機能要件のトレードオフ・セキュリティやデータ整合性など、影響範囲が大きく覆しにくい判断には引き続きエンジニアの専門性が必要です。むしろ、AIが生成したコードの妥当性を評価する「メタなHow」の視点の重要度は増していきます。AIが生んだ実装の品質や技術的負債リスクをどう評価するかは、AI駆動開発が生む技術負債リスク：投資家・DD担当者のための評価フレームワークで詳しく扱っています。
第二に、この移行は組織の仕組みが伴わなければ実現しません。エンジニアの評価軸を「実装速度」から「判断力・AI出力の目利き力」へシフトさせる、PM/PdMの育成を「実装の理解」より「事業インパクトの解像度」に重心を置く、といった評価制度の再設計が必要になります。仕組みが伴わないまま「エンジニアもPMも同じことをする」状態になってしまうと、責任の所在がかえって曖昧になり、本稿冒頭で触れた「押し付け合い」が別の形で再燃しかねません。境界線を引く基準は固定ではなく、AIの実力に応じて動き続けるものとして運用する組織構築の姿勢が求められます。
まとめ：境界線は「引く」のではなく「運用する」
PMとエンジニアの責任分界は、一度きれいな線を引いて終わるものではありません。非機能要件や技術的負債の優先順位のように、境界そのものが「双方の合意」を必要とする領域が存在するためです。さらにAIの進化によって、How自体の担い手が変わりつつあるため、境界線そのものが時間とともに動きます。重要なのは、越境や丸投げが起きたときに「どちらの管轄か」で押し問答をするのではなく、境界上の判断は共同で扱うものだと最初から前提を揃えておくことです。
CTO不在のチームでこの役割分担を設計し切れないと感じる場合、スタートアップがCTOを採用すべきタイミングと判断基準で採用タイミングの見極め方を解説しています。また、外部の技術アドバイザリーが役割分担の設計から伴走することも選択肢の一つです。Tied株式会社のスタートアップ向け支援では、こうした組織設計の壁打ちから継続的なアドバイザリーまで対応しており、お問い合わせから相談を受け付けています。