カスタマーサポートプラットフォームとして、QANT Web、QANT コネクト、QANT スピーク、QANT VoC、QANT ナレッジデスクなど、複数のプロダクトを展開する株式会社RightTouch。プレイドからスピンオフして生まれた同社は、現在、コンパウンドスタートアップとして新たな事業・プロダクトの立ち上げに継続的に取り組んでいます。
RightTouchの開発組織を語るとき、しばしば登場するのが「プロダクトエンジニア」という言葉です。しかし、その言葉が指す役割や範囲は、一言で説明できるものではありません。なぜこの言葉が必要だったのか。どのような背景で生まれ、どんな迷いや試行錯誤を経てきたのか。
今回、RightTouchを立ち上げた取締役CTOの籔悠一（yabu）と、プロダクトエンジニアの小室雅春（com）に、対談形式でプロダクトエンジニアという役割がどのように生まれ、形づくられてきたのかを語ってもらいました。
- 定義できないからこそ必要だった、RightTouchのプロダクトエンジニア
- 「役割を決めない」組織は、どうやって回っているのか
- ゼロイチとグロースで変わる、プロダクトエンジニアの「判断」
- 一緒に働くメンバーを募集中
プロフィール
籔 悠一 / RightTouch CTO
2008年にNECに入社し、防衛事業のシステムエンジニアとして従事。その後、エンジニアとしてベンチャー企業を2社経て、2019年11月にプレイドに入社。新しいサイト運営体験を実現する「KARTE Blocks」の開発に従事。現在は、プレイド初の子会社設立となる株式会社RightTouchの一人目エンジニア兼CTOとして入社し、RightTouchの1つめのプロダクトであるQANT Web（旧：RightSupport）の設計・開発から、現在展開している全QANTシリーズの設計・開発に携わる。
小室 雅春 / RightTouch プロダクトエンジニア
早稲田大学大学院を卒業後、16年に新卒で朝日新聞社に入社。複数サイトの開発や基幹システムのリアーキPJの立ち上げなど、主にFullTSで開発。21年からはカケハシにて薬剤師が利用する新規プロダクトの開発をリード。24年7月からはRightTouchにて新規プロダクトの開発リードを担当。Simpleを妥協せず、最速で価値を作りたい。園芸好き。
定義できないからこそ必要だった、RightTouchのプロダクトエンジニア
── RightTouchにおける「プロダクトエンジニア」とは、どんな役割なのでしょうか。
yabu： 「プロダクトエンジニアとは何か」と聞かれると、正直今でも一言で説明するのは難しいですね。RightTouchでは、最初から明確な定義を置いてこの役割を作ったわけではありません。ただ、はっきりしているのは、「実装だけをするエンジニア」では、この事業は前に進まなかったということです。
RightTouchはエンタープライズ向けのカスタマーサポートという、かなり複雑なドメインを扱っています。しかも単一プロダクトではなく、複数のプロダクトが連携して価値を出すプラットフォーム型の事業です。この開発では、エンジニアが単に仕様を受け取って実装するだけでは、どうしても判断が足りなくなる場面が多く出てくるんです。
たとえば「その要件は、どの顧客課題から来ているのか」「今このタイミングで作る意味があるのか」「将来、別のプロダクトとどうつながるのか」「コアデータや全体設計に、どんな影響が出るのか」といった問いに向き合わずに作ってしまうと、あとから必ず歪みが出る。
だからRightTouchでは、プロダクトや事業の文脈まで含めて考え、判断を引き受けながら実装できるエンジニアが必要になりました。
その結果として生まれた呼び名が「プロダクトエンジニア」です。
com： 自分自身、入社前から「プロダクトエンジニア」という役割を意識していたわけではありませんでした。自分の肩書きがどうなるかよりも、「この会社が何に向き合っているのか」のほうが気になっていたんです。
ただ、話を聞く中で「仕様を受け取って実装するだけの役割ではなさそうだな」という空気は感じていました。プロダクトそのものに向き合っている会社、という印象があったんです。
これまで働いてきた環境では、PdMやステークホルダーがいて、エンジニアとしてどこまで踏み込んでいいのかが分かりづらいと感じることが多くありました。仕様を見て違和感を覚えても、「これは自分が口出ししていいところなのかな」と迷ってしまう場面も少なくなかったです。
その感覚を持ったままRightTouchで開発を進めていくと、「踏み込んではいけないライン」がほとんど存在しないことに、少しずつ気づいていきました。前提を疑ったり、問いを投げたりすることを止められることはなく、むしろそれが自然な行為として受け止められていたんです。結果として、実装に入る前の段階で「この要件は本当に必要なのか」「前提は合っているのか」「別の選択肢はないのか」といった問いを立てることが、自分の中で当たり前になっていきました。
ただ意見を言うだけではなく、その問いの先にある意思決定やそれによって起きる結果を自分が引き受ける。そうした意識が強くなっていく中で、「プロダクトエンジニア」という言葉が、後から自分の中でしっくりくるようになっていったんだと思います。
── 一般的なPdMがいる開発体制と比べて、RightTouchのプロダクトエンジニアは何が違うと感じますか？
yabu： よく「プロダクトエンジニアって、PdMの代わりなんですか？」と聞かれることがあります。でも、自分たちの感覚としては、PdMの仕事をそのまま置き換えている、というわけではありません。
RightTouchでは、PdMという役職を置かない代わりに、プロダクトを前に進めるための意思決定を、特定の一人に集めないようにしています。役職で線を引くのではなく「その文脈を一番理解している人が判断する」という構造を意識しています。
たとえば、新規プロダクトや新しい取り組みを始めるときには、事業開発（BizDev）が顧客の一次情報を持ってきます。そこに事業計画やプロダクトの方向性も含めて全体を見ながら、どんなロードマップを描くべきかを考える。そのために関係者を集めて、前提を整理して、議論して、合意を取りながら進めていきます。
こうした動きは、一般的にはPdMが担うことが多いと思いますが、RightTouchではプロダクトエンジニア、とくにリーダーが中心になって動いています。
だから「実装だけをするエンジニア」という前提で入ってくると、「ここまで関わるのか」と感じる部分はあるかもしれません。それは職能を広げているというより、プロダクトを前に進めるために必要な判断を、誰かが引き受けている結果だと思っています。
結果として、RightTouchのプロダクトエンジニアは、最初から設計された職種というよりも、この事業、このドメイン、この成長スピードに向き合う中で、自然と必要になった役割に近いですね。
com： yabuさんの言うその「判断を引き受ける」という感覚は、日々の開発の中で強く感じています。技術的に一番きれいな選択肢と、プロダクトとして今やるべき選択肢、事業として優先すべき選択肢がきれいに一致するケースは実はあまり多くありません。
たとえば「技術的には作り直したほうがいい。でも、それを今やると顧客への価値提供が遅れてしまう」や、逆に「今すぐ価値は出るけれど、将来的には負債になるかもしれない」といった場面は日常的にあります。
その間でバランスを取るには、コードやアーキテクチャを理解しているだけでなく、顧客の状況や事業フェーズも踏まえて考える必要があります。だからこそ、技術が分かっていないと判断できないし、技術だけを見ていても判断できない。その両方を引き受けるのが、プロダクトエンジニアだと思っています。
自分が判断の重さを強く感じたのは、要件をそのまま実装するのではなく「本当にそれが必要なのか」を問い直すようになってからです。むしろ、その問いを出すと「じゃあ前提から整理しよう」と議論が自然に始まることが多かったです。
判断を引き受けるというのは、最終的に「これは自分が決めた」と言える状態を作ることでもあります。もしその決断が間違っていたら、あとから修正すればいい。でも、考えずに流してしまうことのほうが、後で大きな問題になる。そう感じる場面が何度もありました。
yabu： RightTouchでは「その問いを止めない」ことを大事にしています。プロダクト志向のあるエンジニアなら、決められたものが少ない中で、自分の発想や得た情報をもとに「こうしたらいいんじゃないか」と考えて、話すこと自体が楽しいはずだと思っています。
だから、できるだけルールを少なくして、自由に動ける環境を作りたい。僕自身は、開発の中で新しいことを決めるよりも、障害を取り除くことを意識していました。もし「仕様通りに作ってほしい」という文化だったら、ここまで踏み込んだ議論は生まれなかったと思います。
── プロダクトエンジニアは、実装も同時に担うんですね。
yabu： もちろんです。実際に開発もめちゃくちゃします。自分の中では、チームメンバーはみんなプロダクトエンジニアだと思っていて、各機能ごとにオーナーを持ってもらっています。その機能については、顧客に提供する価値を考えるところから、実装まで含めて責任を持つ。その上で、プロダクト全体や技術全体の意思決定は、プロダクトエンジニアリーダーが担います。
com： 実装を手放すことで判断ができるようになる、という考え方もありますが、RightTouchでは逆です。実装しているからこそ判断できる。コードや構造を知っているからこそ、どこでトレードオフが起きているかが見える。その前提は、これからも変えたくないと思っています。
yabu： 「プロダクトエンジニア」という言葉を聞くと、役割が広く見えるあまり、技術をあまり理解していないように受け取られることがあります。でも実際は逆で、技術が分かっていないと判断できない場面ばかりです。
ある要望をそのまま作るのが簡単に見える場面でも、全体としてどうなるのかは別問題です。技術的な制約を知らないまま「プロダクトとして良さそうだから」という理由だけで判断するのは危険ですし、逆に技術だけを見て、今の事業フェーズを無視するのも違う。その間でバランスを取るには、コードやアーキテクチャを理解していないと話になりません。
ただ、その広さは「何でも屋」という意味ではなく、判断するときに見ている範囲が広い、という話だと思っています。もちろん、ただ広いだけでは意味はありません。要件を変えるかどうかを判断するときには、この実装にはどれくらいのコストがかかるのか、将来的にどこが壊れやすくなるのか。そうした点が分かっていなければ、正しい判断はできません。
com： 「ギーク感があまり感じられない」「技術力が強そうに見えない」と誤解をされることもあります。でも、yabuさんが話していたように、実際は技術が分かっていないと判断できない場面が本当に多い。だからこそ、一緒に開発しているメンバーを見ると、みんな技術力はめちゃくちゃ高いと感じています。尖った一分野だけが強いというより、総合格闘技的な強さというか、フルスタックに何でもできるタイプの強さに近いですね。
「役割を決めない」組織は、どうやって回っているのか
── 役割や体制を固定しない中で、RightTouchの開発が実際にうまく回っていると感じる理由は何でしょうか？
yabu： RightTouchでは、プロダクトごとにチームの形がかなり違います。人数も違えば、関わる職種のバランスも違う。開発フェーズもそれぞれバラバラです。その中で共通しているのは、「このプロダクトを前に進める責任を誰が引き受けるのか」が、役職ではなく状況によって決まっている点だと思っています。
体制が固定されていないからこそ、情報の流れは速いです。誰か一人に集約されるのを待つのではなく、気づいた人が拾い、必要な人を巻き込んで進めていく。こうした動き方ができているプロダクトは、意思決定も早いですし、チームとしての当事者意識も強いと感じています。
com： 自分も、体制が柔軟だからこそ「自分ごと化」しやすいと感じています。役割がきっちり決まっていると、どうしても「これは自分の仕事じゃない」と線を引いてしまいがちですが、RightTouchではその線が最初から引かれていません。
例えば、仕様の検討段階で違和感を覚えたときも、誰かに確認を取る前に、まず自分で考えて仮説を持って話しに行く。そういう動きが自然に許されているので、結果的にプロダクトへの理解が深まり、判断の質も上がっていく感覚があります。
── 一方で、「役割を決めない」ことで難しさを感じた場面はありましたか？
com： 難しさを感じたことはありますね。特に、プロダクトが増えたり関係者が増えたタイミングで「誰が決めるべきか」が急に見えづらくなることがあるんです。誰が最終的に判断するのかが曖昧なままだと、動きが止まってしまうこともありました。その結果、あとから振り返って「もっと早く踏み込めたかもしれない」と感じることもあります。
yabu： その迷いは、構造的に避けられない部分だと思っています。役割を固定しないということは、裏を返せば「誰も決めない状態」が一時的に生まれる可能性がある、ということでもあります。
だからこそ、プロダクトエンジニアリーダーの役割としては、「誰が決めるのか」を常に明確にすることを意識しています。全てを自分が決めるという意味ではなく、この判断は誰が引き受けるのかを言語化する。それだけで、チームの動きやすさは大きく変わります。
── 意思決定や責任を特定の役割に集約しない体制の中で、不安や迷いを感じることはありませんか？ それでも開発が回り続けている理由は、どこにあると考えていますか？
yabu： 不安がゼロになることはないと思っています。ただ、RightTouchでは「決めた人が悪者にならない」構造を、かなり意識して作っています。判断した結果、うまくいかなかった場合でも、「なぜその判断に至ったのか」を振り返ることはあっても、「誰が悪かったのか」を問うことはありません。この前提があるからこそ、判断を引き受けやすくなっていると思います。
明文化されたルールは多くありませんが、共通しているのは「気づいた人が動く」という姿勢です。役割や担当に関係なく、違和感を覚えたら放置しない。その違和感を言葉にして投げる。その積み重ねが、結果的にプロダクト全体の質を支えています。
com： 自分もその安心感は大きいです。「間違えたら終わり」ではなく「間違えたら直せばいい」という空気があります。だからこそ、「完璧な判断をしなければならない」というプレッシャーよりも「今の情報で最善を尽くす」という意識で動けるようになりました。
責任が分散しているというより、判断が共有されている感覚に近いかもしれません。
あとは、「分からないまま進めない」という意識も強いです。分からないことを分からないままにしない。そのために時間を使うことは無駄ではない、という共通認識があります。この前提があるからこそ、役割が固定されていなくても、チームとして破綻せずに回っているのだと思います。
ゼロイチとグロースで変わる、プロダクトエンジニアの「判断」
── 組織のゼロイチとグロースフェーズで、プロダクトエンジニアに求められる思考はどう変わると感じますか？
yabu： ゼロイチのフェーズでは、そもそも何が正解か分からない状態が続きます。顧客も限られているし、仮説もまだ粗い。その中では、とにかく手を動かして、作って、反応を見ることが重要になります。
一方で、グロースフェーズに入ると状況は少しずつ変わってきます。顧客の数が増え、使われ方のパターンも見えてくる。その分、一つひとつの判断が与える影響は大きくなります。
このフェーズでは、スピードだけでなく「積み上がるかどうか」を強く意識するようになりました。今この実装を入れることで、半年後や一年後の開発がどうなるのか。チームが増えたときにも耐えられる構造になっているのか。そういった視点が、以前よりもはっきりと必要になってきます。
com： 一年半ほど開発を進めてきて、自分の中でも判断の重みが変わった感覚はあります。ゼロイチの頃は、多少荒くても前に進めることが正義だったと思います。でもグロースに入ると、その「粗さ」がそのまま負債として残ってしまう。
特に意識するようになったのは、後から入ってくるメンバーの存在です。自分たちが分かっている前提をそのままコードや仕様に埋め込んでしまうと、新しい人が入ったときに理解できない。結果として、判断できる人が限られてしまいます。
yabu： あとは、「全部を自分で把握しようとする」のをやめました。ゼロイチの頃は、プロダクトの全体像を頭の中に入れておくことができていましたが、規模が大きくなるにつれて、それは現実的ではなくなります。
その代わりに意識するようになったのが「誰がどこを理解していればいいのか」を明確にすることです。各機能にオーナーを持ってもらい、その領域についてはその人が一番詳しい状態をつくる。自分は全体の方向性を示したり、判断が衝突したときの調整に回るようになりました。
com： 自分は逆に「考えすぎない」ことを意識するようになりました。グロースフェーズでは、考えるべきことが増えすぎて、全部を最適化しようとすると動けなくなってしまいます。
だから、今この判断で十分かどうか、という基準を自分の中で持つようになりました。完璧ではないけれど、今のフェーズに合っているか。今の顧客にとって意味があるのか。その問いに答えられるなら、前に進めるようにしています。
── 人や役割が増えていく中で、手放したこと・逆に守ったことはありますか？
yabu： 手放したのは、細かい実装のやり方まで自分で決めることです。以前は、コードの書き方や設計の細部まで気になっていましたが、今はそこまで踏み込まないようにしています。
一方で、意識的に守っているのは「判断の背景を共有すること」です。なぜこの判断をしたのか、どんな選択肢があったのか。それを言葉にして残すことで、あとから入ってきた人も文脈を追えるようになります。それをやらないと、後から入ってきた人が判断できなくなってしまうので。
com： 自分が守っているのは「違和感を言語化すること」です。グロースすると、いろいろなことが当たり前になりやすい。でも、その当たり前に違和感を覚えたときに、それを流さない。人数が増えたからこそ、違和感を口に出すことの価値は上がっていると感じています。
── グロースフェーズでも「全員プロダクト担当」という思想は、どう保たれていますか？
yabu： 特別な仕組みがあるわけではありません。ただ、判断を特定の役職に集約しない、という姿勢は一貫しています。プロダクトに関する意思決定は、役職ではなく「誰が一番その文脈を理解しているか」で決める。この考え方を続けている限り、人数が増えても、全員がプロダクトに関わっている感覚は失われないと思っています。
com： 「実装して終わりではなく、その先まで考えるのが当たり前」という文化が根付いているのも大きいと思います。自分が作ったものが、どう使われているのか。どんな影響を与えているのか。それを知る機会がある限り、自然とプロダクト担当としての意識は保たれると思います。
後編では、AI時代におけるプロダクトエンジニアの役割の変化や、求められる思考、キャリアのあり方について語ってもらいました。ぜひあわせてご覧ください。
一緒に働くメンバーを募集中
この記事を通して、RightTouchのプロダクトエンジニアという考え方や、向き合っている姿勢に少しでも共感していただけた方は、ぜひ採用情報をご覧ください。
