プロダクトの優先順位も仕様の確認も、これまでは経営者自身が見てきた。けれども営業や資金調達、採用に時間を取られるようになり、プロダクトの判断が少しずつ滞りはじめている。そのようなときに最初に浮かびやすいのが、「CTOにPdMを兼ねてもらえないか」という選択肢です。
CTOはプロダクトの中身を誰よりも知っていますし、開発チームからの信頼もあります。新しく人を採用するより早く、費用もかかりません。一見すると、もっとも無理のない選択に見えます。
ただし、CTOがPdMを兼ねる体制には、うまくいく状況と、かえってプロダクトの判断が偏ってしまう状況があります。その分かれ目は、CTO個人の能力よりも、会社の状況と任せ方にあります。
本記事では、CTOにPdMを兼任してもらうと起きやすいこと、兼任がうまくいく4つの条件、任せる場合の進め方、そして見直しの目安を解説します。
「CTOにPdMを兼任してもらう」という選択肢が浮かぶ理由
まず、この選択肢がなぜ魅力的に見えるのかを整理しておきます。理由は主に3つあります。
- プロダクトを深く理解している：CTOは、プロダクトの構造やこれまでの経緯を把握しています。新しく迎える人が数か月かけて身につける前提知識を、すでに持っています。
- 開発チームとの距離が近い：仕様を決める人とつくる人の間に伝達の手間がなく、決めたことがすぐに開発に反映されます。
- すぐに始められる：採用活動には数か月かかることも珍しくありません。CTOへの兼任依頼であれば、来週からでも体制を変えられます。
これらはいずれも事実であり、実際に兼任がうまく機能している会社もあります。特に創業から間もない時期や、技術そのものが競争力の中心にあるプロダクトでは、CTOがプロダクトの方向性まで担うことが自然な場合もあります。
一方で、この選択肢は「いま手元にいる人で解決できる」という手軽さから選ばれやすく、兼任によって何が起きるかを十分に検討しないまま始まることも少なくありません。次の章で、兼任によって起きやすいことを見ていきます。
CTOがPdMを兼ねると起きやすい3つのこと
ここで挙げるのは、CTOの力量の問題ではありません。「どうつくるか」に責任を持つ役割と、「何を・なぜつくるか」に責任を持つ役割を、1人が同時に担うことから生じる構造的な傾向です。
1. 優先順位に「つくりやすさ」が入り込む
PdMの仕事の中心は、顧客の課題と事業への影響から、何を先につくるかを決めることです。一方CTOは、実装の難しさや、既存の設計との相性を誰よりも具体的に想像できます。
この2つを同じ人が担うと、優先順位を決める段階で「これは実装が重い」「これは今の設計だとすぐできる」という見立てが、無意識のうちに判断に混ざります。実現のしやすさを考慮すること自体は必要ですが、本来は「顧客にとっての価値」を先に並べ、そのあとで「つくる手間」と照らし合わせるものです。同じ頭の中で同時に行うと、手間のかかる施策が検討の土台に上がる前に外れてしまうことがあります。
反対に、技術的に面白い施策や、設計をきれいにする作業が優先されやすくなる場合もあります。どちらも悪意があるわけではなく、見えているものの違いから自然に起きます。
2. 顧客の一次情報が届きにくくなる
経営者がPdMを兼ねていたときは、商談や顧客との会話で得た情報が、そのままプロダクトの判断に反映されていました。経営者自身が顧客に会っているためです。
CTOに判断を移すと、この経路が途切れやすくなります。CTOは開発チームと向き合う時間が長く、顧客と直接話す機会はそれほど多くないことが一般的です。顧客の声は営業やカスタマーサポートからの伝聞として届くようになり、「なぜその要望が出ているのか」という背景が抜け落ちます。
その結果、要望をそのまま機能として実装する判断が増えたり、反対に、背景が分からないために要望が後回しになり続けたりします。
3. 技術の仕事が後回しになる
見落とされやすいのが、CTO本来の仕事への影響です。PdMの仕事は、関係者との調整、仕様の確認、問い合わせへの回答など、細かく割り込んでくるものが多くあります。
これらを引き受けると、設計の見直し、技術的負債の整理、エンジニアの採用や育成といった、まとまった時間を必要とする仕事が押し出されます。こうした仕事は後回しにしてもすぐには問題が表に出ないため、気づいたときには開発の速度が落ちている、ということが起こります。
経営者の兼務の限界を解消するために始めた兼任が、今度はCTOの兼務の限界をつくってしまう。この点は、兼任を依頼する前に、CTO本人と率直に話しておきたいところです。
兼任がうまくいくかを確かめる4つの条件
では、どのような状況であれば、CTOによるPdMの兼任が機能しやすいのでしょうか。確かめたい条件は4つあります。
条件1：CTOが顧客の声に直接触れている
もっとも重要な条件です。CTOが商談や導入支援、顧客へのヒアリングに日常的に同席しているのであれば、先に挙げた「一次情報が届きにくくなる」問題は起きにくくなります。
開発者向けのツールや、技術者が利用者であるプロダクトでは、CTO自身が顧客にもっとも近い存在であることもあります。この場合、兼任はむしろ自然な選択です。
反対に、CTOがこれまで顧客とほとんど話しておらず、今後もその時間を取れる見込みがないのであれば、兼任を始める前に、顧客に触れる機会をどう確保するかを決めておく必要があります。
条件2：CTOの手に余力がある
開発チームが数名で、CTOがマネジメントに追われていない段階であれば、PdMの仕事を引き受ける時間を確保しやすくなります。
エンジニアが増え、採用・育成・設計の判断だけでCTOの時間が埋まっている場合は、兼任は現実的ではありません。目安として、PdMの仕事には、少人数のチームでも週に1〜2日分ほどの時間がかかると考えておくと、無理のない判断がしやすくなります。CTOの今の1週間のうち、その時間をどこから捻出するのかを、具体的に確認してみてください。
条件3：任せたいのが「形にする仕事」である
プロダクトの仕事は、大きく2つに分けられます。どの顧客のどの課題に取り組むかという「方向を決める仕事」と、決まった方向に沿って優先順位をつけ、仕様を詰め、リリースまで進める「形にする仕事」です。
CTOに任せやすいのは、後者の「形にする仕事」です。開発チームとの距離の近さがそのまま強みになります。一方、「方向を決める仕事」は、顧客や市場、事業計画の情報が必要であり、これらは経営者の側に集まっています。方向を決める仕事まで一度に渡そうとすると、CTOは判断の材料が足りないまま決めることになります。
条件4：期限を区切った体制である
兼任は、「1人目のPdMを迎えるまでの半年間」のように、期限を区切った体制として始めるほうがうまくいきやすくなります。期限があれば、CTOは技術の仕事のうち何を一時的に止めるかを決められますし、経営者の側も、期限までに次の体制を考える必要が生まれます。
期限を決めずに始めた兼任は、問題が大きくなるまで見直されないまま続きがちです。恒久的な体制としてCTOがプロダクトの責任者を担うのであれば、それは兼任というより役割の再設計であり、技術面を支える別の人を置くことまで含めて考える必要があります。
4つの条件のまとめ
| 条件 | 兼任が機能しやすい状況 | 別の人を立てたほうがよい状況 |
|---|---|---|
| 顧客との距離 | CTOが商談やヒアリングに同席している | 顧客の声は人づてに聞いている |
| CTOの余力 | 開発チームが数名で、時間を確保できる | 採用・育成・設計判断で手一杯 |
| 任せたい仕事 | 優先順位や仕様など「形にする仕事」 | 顧客課題の探索や方向性の判断まで |
| 体制の期間 | 期限を区切った暫定の体制 | 期限を決めない恒久的な体制 |
4つすべてがそろう必要はありませんが、条件1と条件2のどちらかが欠けている場合は、兼任を始める前に手当てを考えることをおすすめします。顧客の情報が届かない、あるいは時間がない状態で兼任を始めると、任せた仕事が進まず、結局は経営者に判断が戻ってくるためです。
CTOに兼任してもらう場合の任せ方：4つのステップ
条件を確かめたうえで兼任を依頼すると決めた場合は、次の順序で進めます。
ステップ1：渡す仕事と残す仕事を書き出す
まず、経営者自身がこれまで担ってきたプロダクトの仕事を書き出し、CTOに渡すものと自分に残すものを分けます。「プロダクトのことは任せた」という頼み方では、CTOはどこまで自分で決めてよいのか分からず、結局すべてを確認しに来ることになります。
たとえば、次のように分けます。
- CTOに渡す：開発バックログの優先順位、仕様の確定、リリースの判断、開発チームからの質問への回答
- 経営者に残す：来期に狙う顧客層、料金に関わる判断、大型顧客への個別対応の可否
- 一緒に決める：四半期ごとのロードマップ、開発期間が1か月を超える施策の着手
ステップ2：判断の線引きを言葉にする
次に、CTOが1人で決めてよい範囲と、経営者に相談してほしい範囲の境目を、具体的な基準で決めます。「重要なことは相談して」という伝え方では、何が重要かの受け取り方が人によって異なるため、基準になりません。
「開発期間が2週間以内の施策はCTOが決める」「既存顧客の使い方が変わる変更は事前に共有する」「料金や契約に影響するものは経営者が決める」のように、判断に迷わない形にします。
ステップ3：顧客に触れる機会を仕組みにする
兼任を始めると同時に、CTOが顧客の一次情報に触れる機会を予定として組み込みます。意識に頼るのではなく、仕組みにしておくことが大切です。
- 月に2〜3件、商談や顧客との定例に同席する
- 商談の録画や議事録のうち、要望が出た部分を週に1度まとめて確認する
- 問い合わせの内容を、件数だけでなく原文で読む時間を取る
すべてを行う必要はありません。CTOの時間に合わせて、続けられるものを1つ選ぶだけでも、判断の質は変わります。
ステップ4：期限と見直しの日を決める
最後に、兼任の期限と、途中で状況を確かめる日を決めます。たとえば「期間は6か月、3か月の時点で一度見直す」といった形です。
あわせて、CTOが兼任の間に止める技術の仕事も確認しておきます。何かを引き受けるなら、何かを止める必要があります。止めるものを決めずに兼任を始めると、CTOがすべてを抱え込み、どちらも中途半端になります。
兼任を見直す4つのサイン
兼任を始めたあと、次のような状態が見られたら、体制を見直す時期です。
- 優先順位の理由が、開発の都合で語られることが増えた：「工数が少ないから」「今の設計に合うから」という説明が続く場合は、顧客の課題から考える視点が薄くなっている可能性があります。
- 営業やカスタマーサポートから「要望が届いていない」という声が出る：顧客の情報がプロダクトの判断に反映されなくなっている兆しです。
- 設計の見直しやエンジニアの採用が、数か月動いていない：CTO本来の仕事が押し出されています。
- CTO自身が「どちらも中途半端になっている」と感じている：本人の実感は、もっとも早く現れるサインです。定期的に、率直に聞く場を設けてください。
これらのサインが出たときに大切なのは、CTOの力不足として扱わないことです。1人で担うには仕事の量と種類が多すぎる、という体制の問題として捉え、次の打ち手を一緒に考えます。
CTOの兼任以外に考えられる選択肢
4つの条件に照らして兼任が難しいと判断した場合や、兼任の期限が近づいてきた場合には、次のような選択肢があります。
社内の別のメンバーに任せる
エンジニアやカスタマーサクセスの担当者など、プロダクトと顧客の両方を理解しているメンバーに、PdMの役割を任せる方法です。CTOは技術に集中でき、社内の事情を知っている人が担うため立ち上がりも早くなります。ただし、その人が元の仕事を離れることになるため、抜けた部分をどう補うかを合わせて考える必要があります。
業務委託のPdMに入ってもらう
週に数日、業務委託のPdMに入ってもらい、優先順位の整理や仕様の具体化を任せる方法です。CTOと経営者の間に立ち、顧客の情報と開発の事情をつなぐ役割を担えます。
業務委託のPdMとして複数のスタートアップに関わってきた中でも、「CTOが兼ねていたが、技術の仕事に戻りたい」という段階でご相談をいただくことがあります。その場合、CTOが抱えていた仕事のうち、どこからを外部に渡すかを一緒に整理するところから始めます。CTOが持っている技術的な見立てはそのまま活かしつつ、顧客の課題を並べる役割を分けることで、判断の偏りを抑えやすくなります。
1人目のPdMを採用する
プロダクトの判断が継続的に必要であり、任せたい仕事が言葉になっている場合は、1人目のPdMを採用する段階です。CTOが兼任していた期間に整理された「誰が何を決めるか」の線引きは、そのまま求人票や引き継ぎの材料になります。兼任の期間は、採用の準備期間としても活かせます。
よくある失敗
- 「プロダクトは任せた」とだけ伝えて始める：渡す範囲と判断の線引きが決まっていないと、CTOは確認を繰り返すか、反対にすべてを1人で決めるようになります。どちらの場合も、経営者との間にずれが生まれます。
- 技術の仕事を減らさずに兼任を頼む：CTOの仕事を何も止めないまま役割だけを足すと、時間の足りなさがそのまま判断の遅れになります。
- 顧客との接点を用意しない：顧客の声が伝聞でしか届かない状態で優先順位を任せると、判断の根拠が開発側の事情に寄っていきます。
- 期限を決めずに続ける：暫定のつもりで始めた体制が1年以上続き、CTOの疲弊や開発速度の低下として表に出てから見直すことになります。
- CTO本人の意向を確かめない：技術に集中したいと考えているCTOに、断りにくい形で兼任を依頼すると、引き受けてもらえたとしても長続きしません。本人がプロダクトの判断に関心を持っているかを、最初に確かめます。
具体例：半年の期限で兼任を始め、業務委託に引き継いだケース
従業員12名、創業3年目のBtoB SaaSスタートアップを想定した例です。プロダクトの判断は経営者が担ってきましたが、資金調達の準備が始まり、仕様の確認が1週間以上止まることが増えていました。そこで、エンジニア4名を率いるCTOにPdMを兼ねてもらうことを検討しました。
4つの条件に照らすと、CTOは導入支援の打ち合わせに月数回同席しており、顧客との距離は近い状態でした。チームも小さく、時間の確保も可能でした。一方、来期にどの業種を狙うかという方向の判断は、商談の情報を持つ経営者に残すほうが自然でした。そこで、渡す仕事を「バックログの優先順位と仕様の確定」に絞り、期間は6か月、3か月の時点で見直すと決めました。CTOは兼任の間、予定していた基盤の刷新を一時的に止めることにしました。
3か月の見直しでは、仕様の確認待ちがなくなり、リリースの間隔が安定したことを確認できました。一方でCTOからは、「基盤の刷新をこれ以上止めると、半年後の開発速度に響く」という懸念が出ました。
そこで期限の6か月を待たず、業務委託のPdMに週2日入ってもらい、CTOが担っていた優先順位の整理と仕様の具体化を段階的に引き継ぐことにしました。CTOが兼任していた期間に、判断の線引きと渡す仕事がすでに言葉になっていたため、引き継ぎは短い期間で進みました。
この例で兼任が機能したのは、条件を確かめたうえで範囲を絞り、見直しの日を先に決めていたためです。兼任そのものを最終的な体制とせず、次の体制へ移るための期間として使ったことが、結果につながりました。
よくある質問（FAQ）
Q1. CTOではなく、リードエンジニアにPdMを兼ねてもらうのはどうですか。
考え方は同じです。顧客の声に触れているか、時間を確保できるか、任せる範囲が絞られているか、期限があるかの4つを確かめます。リードエンジニアの場合は、実装の中心を担っていることが多いため、条件2の余力を特に丁寧に確認してください。
Q2. CTOがプロダクトの方向性まで担っている会社もあります。それは問題でしょうか。
問題ではありません。技術そのものが価値の中心にあるプロダクトや、CTOが顧客にもっとも近い立場にある会社では、自然な体制です。その場合は「兼任」というより、CTOがプロダクトの責任者であるという役割の設計になります。技術面のマネジメントを別の人が支える体制まで含めて考えると、無理なく続けやすくなります。
Q3. 兼任を依頼したいのですが、CTOに負担をかけるのではと気が引けます。
依頼の前に、渡したい仕事の範囲と、想定している期間、止めてよい技術の仕事を整理して伝えると、CTOも判断がしやすくなります。「引き受けるかどうか」を含めて相談する形にし、難しいという返事であれば、他の選択肢を一緒に考えるという進め方をおすすめします。
Q4. CTOが兼任している間、経営者はプロダクトから完全に離れてよいですか。
完全に離れることはおすすめしません。方向を決める仕事と、顧客から得た情報をCTOに渡す役割は、引き続き経営者の側にあります。週に1度、30分ほどでも、顧客の状況と優先順位をすり合わせる場を持つと、判断のずれを小さいうちに直せます。
Q5. 兼任がうまくいっている場合、PdMを採用する必要はありませんか。
うまくいっている間は、急いで体制を変える必要はありません。ただし、開発チームが大きくなるにつれてCTOの技術面の仕事は増えていきます。見直しの日を定期的に設け、先に挙げた4つのサインが出ていないかを確かめ続けることをおすすめします。
まとめ
CTOにPdMを兼任してもらうことは、すぐに始められる現実的な選択肢です。ただし、「どうつくるか」と「何を・なぜつくるか」を1人が担うことで、優先順位につくりやすさが入り込む、顧客の一次情報が届きにくくなる、技術の仕事が後回しになる、という3つのことが起きやすくなります。
兼任が機能しやすいのは、(1)CTOが顧客の声に直接触れている、(2)CTOの手に余力がある、(3)任せたいのが「形にする仕事」である、(4)期限を区切った体制である、という条件がそろっているときです。任せる場合は、渡す仕事と残す仕事を書き出し、判断の線引きを言葉にし、顧客に触れる機会を仕組みにし、期限と見直しの日を決めてから始めます。
まずは、CTOがこの1か月で顧客と直接話した回数と、PdMの仕事に充てられる時間を、本人と一緒に確かめるところから始めてみてください。その会話が、兼任を選ぶ場合にも、別の選択肢を選ぶ場合にも、判断の土台になります。
プロダクトマネジメントについてお気軽にご相談ください
プロダクトマネジメントの顧問支援や、1人目のPdM採用・育成のサポートを承っています。
「経営者が兼務してきたが、そろそろ限界かもしれない」という段階からでもお気軽にご連絡ください。
おおむね2営業日以内にご返信します。
