カスタマーサポートプラットフォームとして、QANT Web、QANT コネクト、QANT スピーク、QANT VoC、QANT ナレッジデスクなど、複数のプロダクトを展開する株式会社RightTouch。プレイドからスピンオフして生まれた同社は、現在、コンパウンドスタートアップとして新たな事業・プロダクトの立ち上げに継続的に取り組んでいます。
RightTouchの開発組織を語るとき、しばしば登場するのが「プロダクトエンジニア」という言葉です。しかし、その言葉が指す役割や範囲は、一言で説明できるものではありません。なぜこの言葉が必要だったのか。どのような背景で生まれ、どんな迷いや試行錯誤を経てきたのか。
RightTouch CTOの籔悠一（yabu）と、プロダクトエンジニアの小室雅春（com）に、対談形式でプロダクトエンジニアについて語っていただきました。
前編では、プロダクトエンジニアという役割がRightTouchでどのように生まれ、組織の中でどう機能してきたのかをお伝えしています。
後編の本記事では、AI時代におけるプロダクトエンジニアの役割の変化や、求められる思考、キャリアのあり方について語っていただきました。
プロフィール
籔 悠一 / 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を妥協せず、最速で価値を作りたい。園芸好き。
AIと一緒に作る時代、エンジニアの役割はどこに残るのか
── AIを前提に開発する中で、人が担う役割はどう変わってきていると感じますか？
yabu： 正直に言うと「実装そのものはかなり加速しているな」という感覚はあります。フロントエンドでもバックエンドでも、AIを使うことでコードを書くスピードは明らかに上がりましたし、以前ならそれなりに時間がかかっていた作業が、思っていたより早く形になる場面も増えています。
その一方で「じゃあ考える時間が減ったか」というと、全然そんなことはなくて。「何を作るか」とか「どう作るか」を考える時間は、むしろ増えている気がしています。
AIがコードを書いてくれるからこそ「この方向で本当にいいのか」「どこまでやるのか、どこで止めるのか」、そういう線の引き方を、人がちゃんと引かないといけなくなってきている。その意味では、人間側の判断の重さは、前より増していると思います。
com： 自分も基本的には同じ感覚ですね。ただ正直に言うと、最初は「これって楽になったのか、それとも判断が増えただけなのか」よく分からなかったです。
実際に使い始めて感じたのは、とにかく試せる回数が増えたな、ということでした。以前だったら「これはちょっとコスト的に厳しいな」と諦めていた案も、とりあえず動かしてみることができる。その意味では、トライアンドエラーのコストは確実に下がっています。選択肢が増えた分「どれを選ぶのか」「どこまで作るのか」を決めないと前に進めない。結果的に、判断しないといけない場面は、むしろ増えている気がします。
── AIに任せてうまくいったこと、逆に任せなくてよかったと感じたことはありますか？
yabu： うまくいっているのは、かなり局所的な部分ですね。例えば、ある機能の一部分を試作するときとか、既存コードの書き換え案をいくつか出してもらうとき。そういう場面では、AIは本当に助けになります。「この方向はどうだろう」と考えているときに、叩き台をすぐ出してくれるのは、かなりありがたいです。
一方で、プロダクト全体の前提や長期的な設計に関わる部分については、任せきれないなと感じています。AIは過去のパターンからそれっぽい答えを出すのは得意なんですが、「今の事業フェーズ」とか「このプロダクトが置かれている状況」まで含めて判断することはできない。そこは、どうしても人が引き受けるしかないと思っています。
com： 自分が「任せなくてよかったな」と感じたのは、要件の解釈です。文章として書かれた要件をコードに落とすこと自体はAIでもできます。でもその要件が「なぜ出てきたのか」「どこまでが本当に必要なのか」というところは、人が考えないといけない。
AIが出したコードって、一見するとすごく正しそうに見えることが多いんですよね。でもそのまま採用すると、後から「あれ、なんか違うな」と感じることがある。その違和感に気づけるかどうかは、プロダクトをどれだけ理解しているかに、かなり依存すると思っています。
── AI時代だからこそ、プロダクトエンジニアの価値はどこにあると思いますか？
yabu： 実装スキルそのものだけで差をつけるのは、これからどんどん難しくなっていくと思っています。その中で差が出るとしたら「何を作るか」よりも「何を作らないか」を判断できるかどうかじゃないかなと。作れるから作る、ではなくて「今は作らない」「これは後回しにする」、そういう判断をする。
その判断が正しいかどうかは、技術だけを見ていても分からないし、プロダクトだけを見ていても分からない。技術・プロダクト・事業の状況を全部見た上で決める必要があります。そこを引き受けられる人が、プロダクトエンジニアなんだと思っています。
com： 自分は「目的設定」の力が一番の差になると感じています。AIを使えば、手段はいくらでも出てきます。でも、何を達成したいのかが曖昧なままだと、ただ試行回数が増えるだけになる。プロダクトエンジニアは、技術を使う前に「そもそも何のためにやるのか」「どこをゴールにするのか」、それを言葉にする役割を担っている気がしています。
その目的に照らして、今この実装が本当に必要なのかを判断する。その積み重ねが、最終的にプロダクトの質を決めていくんじゃないかなと思います。
プロダクトエンジニアは、どう育つのか
── プロダクトエンジニアは、どんな経験を積むと育つと感じていますか？
yabu： 最初からプロダクトエンジニアとして完成された状態の人はいないと思っています。自分自身も、意識してなろうとしたわけではなく、気づいたらその立ち位置にいた、という感覚に近いです。
育つ過程で重要なのは「自分で考えて決める」経験をどれだけ積めるかだと思います。言われた要件をそのまま実装するだけだと、判断の筋肉はなかなか鍛えられません。一方で、この仕様で本当にいいのか、別のやり方はないのか、と問いながら進める経験を積むと、少しずつ視野が広がっていきます。
com： 自分もいきなり今の役割ができるようになったわけではありません。むしろ、遠回りに見える経験の積み重ねが、後から効いてきた感覚があります。
例えば、仕様が曖昧な状態で開発を進めざるを得なかった経験や、後から「これは判断を間違えたな」と振り返るような失敗です。そういう経験があるからこそ、次に同じような場面に出会ったときに、立ち止まって考えるようになるんですよね。
yabu： あと、成長のために必須だと思っているのは「失敗しても修正できる環境で判断する経験」です。正解が分からない中で決めて、もし間違っていたら直す。そのプロセスを回せることが重要です。
AIの時代になって、試行回数自体は増やしやすくなりました。ただ、重要なのは回数ではなく精度です。何のために試しているのか、何を学ぼうとしているのか。その目的がはっきりしていないと、経験は積み上がりません。
com： 広くやること自体が悪いとは思っていません。でも目的なく手を広げると、結果的に何も残らないことがあります。自分の場合は「なぜこれをやるのか」を常に言葉にするようになってから、経験が線でつながるようになりました。
プロダクトエンジニアとして育つには、経験の量を積むことも大事だと思っています。ただ、それだけではなく経験の量よりも、その経験をどう解釈して次に繋げるかがより大事だと感じています。
── ご自身のキャリアを振り返って、今の仕事につながっていると感じる経験は何でしょうか？
yabu： エンジニアとしてコードを書き続けてきたこと自体が、今の判断の土台になっています。もし実装から離れていたら、ここまで踏み込んだ判断はできなかったと思います。マネジメントに進む選択肢もありましたが、自分はプロダクトを通じて価値を出したいという感覚のほうが強かったです。
エンジニアのキャリアって「専門性を尖らせる」か「マネジメントに寄る」か、みたいな二択になりやすい印象があります。でも自分は、プレイヤーとして作り続けながら、プロダクトの価値に責任を持つ方向に進みたかった。プロダクトエンジニアという立ち位置は、その延長線上にあるものだと感じています。
com： これまでのキャリアで役に立っているのは「うまくいかなかった経験」かもしれません。失敗したときに、なぜそうなったのかを振り返る。その積み重ねが、今の判断の引き出しになっています。プロダクトエンジニアは、特別なキャリアパスというより、経験の積み方によって自然と辿り着く立ち位置なのだと思います。
完成しない役割としてのプロダクトエンジニア
── プロダクトエンジニアという役割は、完成するものだと思いますか？
yabu： 正直、完成する役割だとは思っていません。プロダクトのフェーズが変われば、求められる判断も変わりますし、組織の形が変われば、引き受ける責任の範囲も変わります。
だから「プロダクトエンジニアとはこういうものです」と固定してしまうと、逆に本質から離れてしまう気がしています。その時々で、プロダクトにとって必要な判断を引き受ける。その結果として役割が変わっていく。その前提に立っている限り、この役割はずっと揺れ続けるものだと思います。
com： 自分も同じ感覚です。最初からこの形を目指していたわけではありませんし、今の形が正解だとも思っていません。ただプロダクトに向き合う中で、「誰かが考えなければ前に進まないこと」が確実に存在します。
そのときに、役職や肩書きに関係なく、自分が引き受ける。その積み重ねが、今の立ち位置につながっていると思います。
── RightTouchでプロダクトエンジニアとして働く面白さは、どこにありますか？
yabu： 一番の面白さは、判断の幅が広いことだと思います。実装だけをしていると見えない景色が見えるし、逆に、判断だけをしていても分からないことがある。RightTouchでは、実装と判断の間を行き来しながら仕事ができます。その分、楽ではありませんが「自分がプロダクトを前に進めている」という実感は強いです。
com： 自分は「ここまで考えていいんだ」と思える環境そのものが、面白さにつながっていると感じています。要件を疑うことも、前提を問い直すことも、歓迎される。その分、自分の判断がプロダクトに与える影響も大きいですが、それを引き受けることにやりがいを感じています。
── これからプロダクトエンジニアを目指す人に、伝えたいことはありますか？
yabu： 最初からプロダクトエンジニアであろうとしなくていいと思っています。むしろ、目の前のプロダクトにちゃんと向き合うことのほうが大事です。「この仕様でいいのか」「なぜ今これを作るのか」「作った先に何が起きるのか」、そういう問いを考え続けていると、自然と引き受ける範囲が広がっていきます。その結果として、後から名前が付く。それでいいと思っています。
com： 向いているかどうかを先に考える必要はないと思います。ただ「考え続けることを楽しめるかどうか」は大きいかもしれません。「正解がない状態で決めること」「後から振り返って修正すること」、そのプロセス自体を前向きに捉えられる人であれば、この役割はきっと面白いはずです。
── 最後に、RightTouchで一緒に働きたい人について教えてください。
yabu： プロダクトを通じて価値を届けることに、ちゃんと向き合いたい人にとっては、いい環境だと思っています。
お客さんに近いところで、何を作るかから関わって、それを実際に形にしていく。そういうことをやりたい人とは、一緒にやっていきたいですね。
一方で、プロダクト志向であることと、技術的に成長できることは両立したい、という声も多いです。RightTouchとしても、その両方を満たせる環境でありたいとは思っています。
com： プロダクトエンジニアって、何か完成された役割があるわけではなくて、これからもやり方自体が変わっていくものだと思っています。
だからこそ、「こういうものだ」と決めてから入るというよりは、変化していく中で、一緒に考えて、一緒に作っていける人のほうが合っている気がします。
正解がない状態で考えることや、後から見直して変えていくことを前向きに楽しめる人であれば、きっとこの環境は面白いと思います。
── 最後に、RightTouchにとってプロダクトエンジニアとは何でしょうか？
yabu： RightTouchにとってのプロダクトエンジニアは、肩書きではなくプロダクトに向き合う姿勢そのものだと思っています。だから人数が増えても、フェーズが変わっても、この考え方自体は大切にしていきたいです。
com： RightTouchにとってのプロダクトエンジニアは、「どこまで考えるか」を自分で決めている人だと思っています。
役割が決まっていないからこそ、考えなくても進めることはできる。でも、あえて立ち止まって考え、その判断を自分のものとして引き受ける。プロダクトの価値に対して、誰かの仕事としてではなく自分の判断として向き合う。
そういう人が集まっている状態そのものが、RightTouchにおけるプロダクトエンジニアなんじゃないかと思います。
一緒に働くメンバーを募集中
RightTouchには、yabuさんのように組織やプロダクト全体の判断を引き受け続けてきたエンジニアもいれば、comさんのように現場で問いを立て、自分の判断としてプロダクトに向き合い続けているエンジニアもいます。
タイプやキャリアは違っていても、「どこまで考えるかを自分で決める」「その判断を自分のものとして引き受ける」という姿勢は共通しています。
RightTouchでは、そうした姿勢を持ったエンジニアたちが集まり、価値あるプロダクトを開発し、顧客に届けるための挑戦を日々重ねています。
私たちは、「あらゆる人を負の体験から解放し、可能性を引き出す」というミッションの実現に、本気で向き合う仲間を求めています。
この記事を通して、RightTouchのプロダクトエンジニアという考え方や、向き合っている姿勢に少しでも共感していただけた方は、ぜひ採用情報をご覧ください。
