※この記事は2025年4月に『RightTouch公式note』に掲載した記事を転載しています。

冒頭

こんにちは、RightTouchで新規プロダクトの開発リードをしている小室です。RightTouchは先日、プロダクト3周年記念を迎え、この度シリーズAの資金調達を行いました。

https://righttouch.co.jp/news/FpF1waA5

3周年記念と資金調達を記念して、RightTouchではリレー形式でのブログ投稿を行っています。

https://note.righttouch.co.jp/m/md84f0da0727f

はじめに

近年、新規立ち上げの機会はますます増えてきていると思います。
技術的なトレンドが大きく変化していることや、一昔前と比較してコンパウンドスタートアップが増え、企業はよりトータルなソリューションの提供が求められている背景があります。
そして、立ち上げのフェーズはプロダクトにとって最も重要な時期です。新規開発は初速が速いことがもちろん大切ですが、その後に継続的な開発速度を維持したり、短期的な機能開発と将来的なビジョンに向けた機能開発とのバランスを取ったプロダクトプランニングをする必要があります。また、初期フェーズで蓄積された技術負債や硬直化したプロセスは時間軸に従って拡大する傾向があるという点でも重要性の高いフェーズです。
また、LLMの進化などで技術環境が変わる中、開発チームのあり方も変わり目にあると考えています。
本記事ではこうした背景を踏まえた上で、新規開発チームに関するモダンなチーム構成や運用方法について、私が日々RightTouchで実践していることを元にまとめたいと思います。
対象の読者はエンジニアに限りませんので、気になった方はぜひご一読いただけるとうれしいです。

従来式の開発プロセスとその課題

脱スクラム

スクラムやアジャイル開発の手法は、反復的なプロセスによって短期間で成果を上げる強みがあります。
一方で、PMFまでの新規フェーズのような不確実性のレベルが高く、大上段のWhyから考える時間が相対的に多くなるような状況では、スクラム運用が馴染まないことがあります。まだタスク自体が曖昧だったり、日々の変化が大きかったりするので、精緻なプランニングが難しかったり、スプリントバックログの運用が膨大なトイルとなることがあるためです。
特に、新規フェーズで革新的なプロダクトを構築していくためには、細やかな管理プロセスに縛られるよりも、個々人の能力を最大限に活かし、自律的に開発を進め、様々な方向にオーバーランしていけるのが望ましい状態です。その上で、「振り返り駆動」式に、やったことに関して方向性をすり合わせてNextActionを調整することでチームとしての全体感を維持する様な進め方が現実に即していると実感しています。

PdM中心モデルのトレードオフ

従来のPdM（プロダクトマネージャー）中心のモデルでは、PdMにプロダクト要件の確定する役割が期待されますが、新規フェーズではいくつかの考慮点があります。
まず、新規フェーズの要件検討は曖昧性の観点で本質的に難易度が高いため、プロトタイピングを繰り返したり、各メンバーの専門性や情報を集積して議論することでなんとか仮説を立てていくということが多々発生します。
また、PMFに到達するまでの構築段階では、クライアントをセグメントではなくN1で捉えてインサイトを引き出していくことが求められるため、具体的な顧客と良い共創関係を構築していくためのビジネス・コミュニケーション力に関してもプロフェッショナルである必要があります。
これらのことすべてをPdMに依存すると、ボトルネックを作るリスクが高くなります。また、複数のプロダクトを開発するコンパウンドスタートアップにとって、そのような人員を各プロダクトに配置する計画は無謀でしょう。
現実的には、新規フェーズに求められるこれらの重要な要件を、各メンバーで分担していくのが地に足のついた考え方になると考えます。

PdM不在の立ち上げモデル

開発における3本柱の見直し

まずは従来のモデルを整理していきたいと思います。

従来の開発の3本柱

基本的に開発プロセスには、要件・仕様・設計という大きく3つの要素が想定されます。
このうち、PdMはプロダクトの仕様についてオーナーシップを持っているため、「要件」部分に対して主な責任を持っています。一方、エンジニアは技術に関して責任を持っているため、「設計」を中心に責任を持ちます。そして、その中間に位置する「仕様」部分で双方の事情のすり合わせ、ギャップを埋めていきます。

ここで気になるのが、このモデルが本当に新規プロダクト構築における重要な要素を押さえているのか？という部分です。
前節で課題に出したことを踏まえると、たとえば以下のような要素が抜け落ちていそうです。

• 事業の成長に関わるビジネス戦略
• 要件を決定する前提となる、よりハイレベルな要件検討
• 顧客との(共創)関係構築

初期フェーズではここで挙げた様な要素が、タスクの優先順位を大きく前後させるなど、日々のプロダクト開発全体に大きく影響することは想像しやすいと思います。そのため、要件・仕様・設計に閉じて考えていては片手落ち感があります。
そこで、こぼれ落ちているこれらの要素をまとめて、「戦略」という要素にして、プロダクト開発の3要素から4要素として拡張してみたいと思います。

「戦略」を加えた、開発の4本柱

チーム構成と新たな役割分担の枠組み

唯一のPdMに依存しないチーム構成を考えたときに、最低限必要になるメンバーは、BizとDev(Designer)です。今回は便宜上、デザイナーもプロダクト開発のメンバーと言う観点でDevに含めて考えると、Biz・Devの2者に分けられます。
この構成を前提にして「開発の4要素」の現実的な分担を考えていきたいと思います。
Bizメンバーはビジネスと顧客コミュニケーションのプロフェッショナルであり、主に「戦略」に責任を持ちますが、それをプロダクトに落とし込むためにある程度の粒度まで要件のオーナーシップを持つと良さそうです。そうなると、Devメンバーは残りすべてを担うことになります。従来の責任範囲と比べて、Devメンバーがより要件レベルの検討に入り込むことで、状況変化の激しい中でも全体を俯瞰した機能設計を進めることができ、Bizメンバーの事業進捗をサポートすることができます。

まとめると、従来モデルではPdMとDevが「仕様」ですり合わせていましたが、「戦略」を含むこの4要素モデルではBizとDevが「要件」ですり合わせる事になり、エンジニアに求められる責任が1段階広がっています。
この様な役割分担モデルから導き出される、従来のDevよりも広い視点と責任範囲でプロダクト開発全体を視野に取り組むエンジニアのことを、「Product Engineer」と捉えています。

プロダクトエンジニアとして取り組むメリット

顧客に会うことが開発のモチベーションにつながること

まず、基本的ながら見落とされがちな点としてモチベーションがあります。不確定要素の多い新規フェーズでは熱量を持ってプロダクトに向き合う推進力が重要になります。しかし、多くの人にとって、顔も名前も知らない誰かのために、本気でプロダクト開発に取り組むことは難しいでしょう。
もちろん従来の開発現場でも、本気で「システム開発」に取り組んでいるエンジニアをたくさん見てきました。しかし、技術力の高いエンジニアが「プロダクト開発」という視点である程度技術的なこだわりから離れ、価値創出にWillを持ち続けるには顧客と対面して「この人たちに価値を届けたい」と真に実感して自発することが一番の原動力になると感じます。

Whyを考えるフェーズに適していること

冒頭でもお話した通り、プロダクトマネジメントの4階層(Core->Why->What->How)を考えたときに、グロースフェーズのプロダクトではWhat・Howを考える時間が多くを占めます。一方、PMFまでの新規開発フェーズでは、そもそも要件を削り出す作業の比重が大きいため、Why・Whatについて思考する時間が相対的に長くなります。そのため、Devメンバーもよりプロダクトの「戦略」に踏み込んだコンテキストを持っておくことが重要になります。
PdMはBiz・Devの間に位置し双方のコミュニケーションを交通整理しますが、この場合Biz・Dev間のコミュニケーションにおける情報密度は低下します。
「どれだけコンテキストを密に共有するか」 vs 「どれだけ認知負荷を制限するか」
が、PdMを配置するべきかどうかの1つのトレードオフポイントになっていると考えられます。
また、新規フェーズでは高い認知負荷をある程度許容し、コンテキスト共有を重視してくことが多くなると考えています。

メンバー間のコミュニケーションに齟齬が生まれにくいこと

責任分界点が `プロダクト vs 技術` という(対立)構造ではなく、みんながプロダクトを起点に責任範囲を分担することによって、認識の齟齬が生まれにくくなります。前述の通り、新規フェーズでは個々人の能力を最大限に発揮し、個々がいろんな方向にガシガシオーバーランしていくような動きが望ましいのですが、それでもプロダクトチーム全体として同じ方向へ成果を創っていくためには、「プロダクト価値」の視点を拠り所とするのがリーズナブルです。
私のチームでも全員がプロダクト目線で思考していることにより、自然とYes/But的な会話が発生し、HRTが生まれる土壌になっていると感じます。

意思決定の分散

新規フェーズで重要なアジリティを確保するために、メンバーが自律的にアクションしていくためには、適切に意思決定権を分散するような構造が必要です。
ここで、PdMやPOがオーナーシップを持つような構成では、彼らの持つ権限を移譲するなんらかの方法が必要になります。ただ、皆さんも経験があると思いますが、既存の権限を移譲するというのはなかなか難しいものです。
デリゲーションポーカーなどいくつか整理するための手法があったりもしますが、それで「パキッと明快に権限が移譲ができた！」という経験をしている人は多くないのではないでしょうか。
初めから「要件」に関する責任を分散させた状態でチームを構成すると、Biz・Devともに自律的な取り組みがしやすくなります。
よくあるアンチパターンとして「責任を分散すると責任の所在が曖昧になる」というものがあります。もちろんこれは重大なトレードオフになりえますが、Devがプロダクトエンジニアとして取り組む様なプロダクト価値に焦点が合っていて、メンバーが主体的に行動しているチームでは抑制される部分と考えています。

YAGNIで進めよう！

良くも悪くも新規フェーズはその後のプロダクト、チームの性質を決めてしまいます。
これはパスディペンデンス(経路依存性)や組織慣性という性質で理解できます。権限移譲の例でもありましたが、最初に行われた決定を真の意味で変革させていくには、決定時よりも遥かに大きな労力がかかります。
エンジニアでなくても今や"技術負債"という言葉は有名ですが、初期フェーズの意思決定はそれが良い決定だったか悪い決定だったかに関係なく、将来に対して大きくレバレッジを効かせることになります。
ここで何が不可逆な判断になるのかですが、簡単にいうと「決まり」だと考えています。経験則になりますが、つまり、権限や役割・プロセスなどは「決まり」として、その後のチーム運営に深く影響を与えていくと考えています。
もちろん、必要なプロセスを導入することは効率的な組織運営をする上で重要なことですが、プロセス導入の判断そのものは時間とともに不可逆性を帯びていくことを忘れてはいけません。
そこで参考になりそうなのが、エンジニアではみんなが知っているところの「YAGNI」という言葉です。YAGNIはYou Aren't Gonna Need Itの略で意訳すると、「良かれと思って先立って作ったモノのほとんどは、将来的にやっぱり必要がなくなったり、ちょっと違うものが欲しくなったりする」、ということを表現した経験則です。YAGNIを徹底して、本当に必要になるまでその機能を作らないことが、技術負債を溜め込まないための良い方針であることを多くのエンジニアが理解しています。
チーム運営においても同じく、初期フェーズでは本当に必要な権限やプロセスだけを導入・設計していくことが重要になると考えています。

プロダクトレベルのメンタルモデルが構築しやすいこと

プロダクトエンジニアのメリットの最後として、やや抽象度の高い話をします。
曖昧性の高い初期フェーズのプロダクトに関して、チームメンバーが如何に一貫した思考を積み重ねて行くかということは大きな課題の1つです。各メンバーの役割が細分化されている環境では、プロダクトを理解するためのメンタルモデルが分散してしまい、それぞれの立場間でコミュニケーションする中でロスが発生したり、メンタルモデルの衝突が発生したりします。
プロダクトエンジニアとしてフルスタックかつ、要件までフルサイクルに活動することの強みは、全体最適を見つけ易い点です。これをもう少し解像度を上げると、プロダクトを俯瞰した状態でのメンタルモデルを構築しやすいことです。
技術的な用語でいうと「ドメイン駆動設計」に近いと思います。個々の技術領域ではなくプロダクトが相対するドメインを中心にミニマルなメンタルモデルを構築することで、Biz・Dev問わず全メンバーで1つのメンタルモデルを共有することができ、一貫した議論を積み重ねることができます。

RightTocuhでの考え方

ここまでで、プロダクトエンジニアとして取り組むメリットについて説明してきましたが、最後に弊社でプロダクトエンジニアとしての取り組みを補助する様な考え方を、弊社のMVV(RightTouch Mind)から例として2つご紹介いたします。

承認より謝罪より事後報告

初期フェーズの不確実性を乗り越えるには、メンバーが自律的かつクイックに仮説検証を繰り返せる文化が必要です。私自身、「これってこのまま進めて大丈夫かな〜...」と足踏みする気持ちになることばかりですが、承認や謝罪をするよりまずは行動して結果を報告しよう、というこのバリューにはいつも勇気づけられています。
また見方を変えると、責任を自分で引き受ける覚悟でもあると言えます。事後報告するためには誰かに承認してもらうのではなく、自律的に意思決定して進める必要があります。この点で、権限の分散にもつながる良いバリューだと思っています。

全員顧客担当・全員プロダクト担当

顧客と会話すること自体が、多くのエンジニアにとってややコンフォートゾーンを越えた行動であることも珍しくないと思います。また、Bizのメンバーが「プロダクトのことはDevに任せた!」となってしまったら、ここまでの議論していたことは成立しません。
全員が顧客・プロダクトに向き合うからこそ、認識の齟齬が少なくなり、メンバー個々が自律して取り組みながらもチーム全体として一貫した方向へ成果を出して行くことができます。また、Biz・Dev双方の気持ちを理解することで組織全体にHRTが生まれる良いバリューだと思います。

最後に

本記事では、新規フェーズのプロダクト開発チーム運営の1つのパターンをご紹介しました。
スクラムやPdMの配置は今日の開発チームの鉄板パターンの1つではありますが、状況に合わせて様々なパターンを選択できることが重要だという観点で、対象的に紹介してみました。アジャイルな考え方や、モデリング技術など、プロダクト開発で本質的に重要な点は変化しませんが、取り組み方については、常に状況に合った方法を模索していきたいと考えています。
また、近年LLMの進化により、エンジニアの活躍のフィールドはこれまで以上に広がってきいきます。(私を含め)純粋なギークとしての振る舞いが減少することへの一抹の寂しさを感じる方もいると思いますが、一方で、顧客価値の本質に真っ直ぐ向き合う様なプロダクトエンジニアライクな働き方は、多くのエンジニアにとって大きなやりがいにつながることだと感じています。今回ご紹介したパターンも、そうしたプロダクトエンジニアのアプローチの一例として、どこか参考にしていただける部分があれば幸いです。
「プロダクトエンジニア」に関しては、まだまだ捉え方に広がりのある状況だと認識していますので、機会があれば皆さんの実践例もぜひ教えてください。

株式会社RightTouchでは一緒に働く仲間を募集しています

Business
ビジネスデザイン
カスタマーサクセス
エンタープライズセールス
BDR
マーケティング

Product
プロダクトエンジニア
リードエンジニア
カスタマーエンジニア
UI/UXデザイナー

Accelerator
法務（正社員）
財務経理（Accounting ＆ Finance）