カスタマーサポート領域向けのWebサポートプラットフォーム「RightSupport by KARTE（以後、RightSupport）」を開発する株式会社RightTouchは、プレイドからスピンオフして始まったBtoBスタートアップです。

現在は、複数プロダクトを提供するコンパウンドスタートアップとして、常に新たな事業、プロダクトの開発に向けて動いているRightTouchですが、初期プロダクトの開発には紆余曲折がありました。

顧客のペインを探索していく過程で、当初の想定が崩れるなか、どのようにエンジニアたちは価値あるプロダクトの開発に取り組んでいったのでしょうか。今回、RightTouchを立ち上げた取締役CTOの籔悠一（yabu）と、1人目エンジニア兼テックリードの齋藤成之（nari）の2人に当時のことを振り返りながら、語ってもらいました。

2人がRightTouchに関わり始める経緯・様子はこちらの記事をどうぞ。

ペインの探索を経て「Web行動データ」から「サポートデータ」に軸をシフト

──当初、RightSupportのコンセプトはどのようなものでしたか？

yabu：
初期のコンセプトは「Web行動データから困りごとを発見する」というものでした。KARTEには大量の行動データが蓄積されていて、推定ロジックを組むことができれば、困りごと（ペイン）を自動的に発見できるのではないかと考えていたんです。当初は、このコンセプトを実現するという夢を抱いていました。

nari：
当初のコンセプトが実現できれば、他社が真似できないような、一人ひとりのお客様にあった最適なカスタマーサポートが実現できるはず。そう考えていたものの、どう実現するのかなどは固まっていなかった。初期のメンバーで一緒にホワイトボードに書き出しながら、実現の方法を検討していったんです。

──コンセプトの実現方法は見つかったのでしょうか？

yabu：
当時の時点で、コンセプトの実現方法を見出すのは難しかったですね。なかなか、Web行動データだけでは、問い合わせ前の行動分析からペインポイントを見つけられず、困りごとを発見する上で十分な精度を出すことができなかった。

全自動でのWeb行動の分析と並行して、Webサイトのどのページを経由した問い合わせが、どの程度あるかを分析できるような機能の開発を進めていました。カスタマーサポートの担当者が顧客を分析する上での武器になればと考えていたんです。

当初想定していたペインはうまくいきませんでしたが、リリースに向けて当初目指していたものよりもアルゴリズムをシンプルにして開発を進めることにしました。

CTO 籔悠一（yabu）

nari：
最初は、機械学習で実現したいと考えて開発していたのですが、シンプルな統計分析に切り替えました。KARTEにあるWeb行動データだけでなく、困りごとそのものである問い合わせ情報などのサポートデータも持っていたので、そのデータを活かすだけでも価値を生み出せるだろうと。

顧客に価値を提供できるプロダクトにするために、軸を切り替えるという判断を早い段階でできたのは、今振り返っても良い意思決定だったと思います。初期のコンセプトに拘って、使われないプロダクトを作るのでは意味がありません。

このときの試行錯誤と、シンプルなアルゴリズムでサポートデータも活用する方向性へのシフトは、現在のコンパウンド型の事業化につながった要因でもあると考えていて、価値ある探索だったと思います。

コンセプト軸か、データ軸か。タイプの異なる2人のエンジニアがいかに連携して初期プロダクトを開発したか

──実際に思い描いていたコンセプトから軸を変えるとなると、ハードルも大きかったのではと思いますが、どのようにシフトしていたのでしょうか？

yabu：
きっかけになったのは、実際のデータの分析にフォーカスしたこと。顧客に価値を提供するためのプロダクトにしようと試行錯誤するものの手応えがなかなか得られない。そんなとき、nariさんが実データを分析して示唆をいろいろと出してくれて、それが新たな方向性を検討する際のヒントになったんです。

自分はなかなかやりきれていなかったところだったので、nariさんがいてくれて助かりました。当時は入社したばかりだったと思いますが、nariさんがデータから示唆を出そうと考えたのはどうしてだった？

nari：
コンセプトを実現するための抽象的な議論も大切ですが、個人的には手触り感を大事にしたかったんですよね。そのためには、実際のデータを見たほうがいいし、結果として開発の速度を早められるのではないかなと考えての行動でした。

yabu：
実際のデータを見ることに加えて、カスタマーサポートのオペレーターへのヒアリングなども実施してましたよね。そこまで行動するエンジニアはなかなかいないよなぁと驚いたことを覚えていて。nariさんにとっては自然なことだった？

nari：
どうなんでしょう。自分の特性として、いろいろな角度から実態を把握した上で抽象化して捉えたいという気持ちが強いんです。もともと、物理学で博士号を取得してからエンジニアとして仕事をし始めたこともあり、問題解決のアプローチとして物理学のものと近いのかもしれない。

1人目エンジニア兼テックリード齋藤成之（nari）

──nariさんはなぜRightTouchに？

nari：
どうせなら大きいなテーマで、誰も挑戦したことのない課題を解きたいというのが転職理由でした。転職する前は、課題の抽象度が高くて、不安もあるけれど、それも含めて面白がってやっていきたいと思っていました。

取り組む課題の大きさのほかには、顧客に向き合いたいというのも強い理由でしたね。ソフトウェアの価値を高めるために、クライアントやエンドユーザーにしっかりと向き合いたい。

だから、RightTouchに転職した後も、エンドユーザーやオペレーターが何に困っているのかを知って、解像度も上げたいと考えていたんですよね。それもあって、データもしっかりと分析して示唆を得たいという気持ちが強かった。

ただ、このアプローチはその時点の延長線で解決策を考えがちという自覚もありました。そうすると、発想が矮小化してしまいやすい。yabuさんのようなあるべき姿を思い描いて、実現方法を考えるというアプローチと、両方があったから初期プロダクトの開発はバランスよく進められたと思います。

yabu：
個人的に、できるだけ思考する際に誰かの気持ちや思考を組み込まないように意識しているんですよね。それを組み込むことで、そちらに無意識に引っ張られてしまった結果、大切な何かを見落としてしまうことを危惧していて。だから、データの重要性は認識しているし、インプットもするけれど、できるだけ距離をとって、フラットに向き合えるようにする傾向がある。

そうすると、どうしても思考は抽象的になりがち。抽象的な議論や計算式などで話すだけではわからないことが、直接データを見ることで定量的にわかる。初期のプロダクト開発においても、実際のデータを踏まえて議論し、判断していくことは非常に重要だと改めて感じました。nariさんがスピード感を持って、実際のデータから示唆を出してくれたから非常に助かった。

左から籔（yabu）、齋藤（nari）

──ふたりともエンジニアとしてのタイプがけっこう違ったんですね。

yabu：
個人的に、エンジニアのタイプには2種類あると思っています。1つめは、抽象度の高い領域が残ったまま進めることに抵抗がないタイプ。2つめは、実際のデータを見て可能な限り具体化して進めるほうがやりやすいタイプ。

この2つのタイプは良い悪いではなくて、うまく手を取り合って開発していけると良いプロダクトが開発できると思っています。僕は1つめのタイプで、nariさんは反対で2つめのタイプ。

これはエンジニア組織の作り方にも現れるなと思っていて、僕は現在の人から発想するのではなく、あるべき姿を描いた上でバックキャストしてどう進めるかを考える。けれど、nariさんは現在いるエンジニアから組織をどうしていくかをボトムアップで検討する。これはアプローチは違えど、突き詰めると同じところに行き着く。

どちらかのタイプの思考やアプローチに偏ってしまうと、プロダクトも組織もまとまっていかない。両方のタイプがうまく相乗効果を発揮していくことが大切だと思っていて。nariさんが参加してくれたことで、初期のプロダクトが素早く形になっていったと思いますね。

──タイプが違うことで衝突などはなかった？

nari：
「コトに向かう」というカルチャーがあるから、議論が白熱しても衝突のような状態になることはなかったですね。

yabu：
議論はするけれど、互いにリスペクトを持ったうえで会話ができていたと思います。これはエンジニア同士に限らず、Bizのメンバーと議論するときも同様ですね。

Bizを信頼し、プロダクト志向でリリースに向けて邁進

──初期のプロダクトコンセプトから離れて、リリースに向けてどのように進めていったのでしょうか。

nari：
ベータリリースが差し迫っていたので、当初に想定していたスコープを狭めなければなりませんでした。ではどこを削るのか？本当にこれで価値が出るのか？について、かなり議論を重ねました。

価値が最大化できて、かつコストパフォーマンスが高い”妥協点”はどこなのかを探して、ベータリリースに向けて開発を進めていきました。妥協点とは表現しましたが、リリース後も1年ほどペインや価値の探索は続けていましたが、飛躍的に価値をあげるペインを見出すのは難しかった。今、振り返ってみるといい妥協点だったと思います。

yabu：
エンジニアとしては妥協点という手応えでしたが、それはエンジニア目線での価値の捉え方でした。代表の野村や長崎といったBizで張っていたメンバーが顧客と話したときに「これは価値になる」と手応えを得られたという話を信頼しなければ、開発はできなかった。当時、エンジニアはあまり顧客とコミュニケーションができていなかったこともあって、なかなか手応えを掴めていなかったんですよね。不安はありましたが、ビジネスメンバーが「これなら売れる」と言い切ってくれるので、それを信じて開発を進めていきました。

──Bizのメンバーの存在も大きかったんですね。

yabu：
大きかったですね。現在でも共通して、エンジニアとして背中を預けられるBizのメンバーだと思います。ウィジェットに特化したことやレポート周りなど、リリースに向けて思い切った意思決定もいくつかありました。これらのBizの意思決定を信じられたことは、価値あるプロダクトとしてリリースできたことに影響していると思います。

nari：
個人的には入社して時間は経っていなかったこともあり、yabuさんほどBizのメンバーを信頼できていたかはわかりません。多少のモヤモヤもあったかもしれない。とはいえ、リリースは迫っているのでやるしかないの状態ではありました。この方針で開発して価値あるプロダクトになるならいいし、そうならなかったとしても学びになると考えて開発に取り組んでいました。

──エンジニアとして価値を信じるというのはなかなか難しかった？

yabu：
難しかったですね。エンジニアは、自分たちが開発しているものの仕様を理解しているからこそ、プロダクトを過小評価してしまう傾向もあるのではないかと。「こんな仕様のプロダクトは、他社でも簡単に開発できてしまうのでは？」と感じてしまう。技術的に容易に実現できるのであれば、価値が出ないのではないか、と考えてしまいがちですが、本当はそうではない。技術面だけでなく、Bizが向き合っている顧客の言葉、Bizが「価値がある」ということを信じるのもエンジニアとしては大事ですね。

nari：
Bizのメンバーも、意識的にエンジニアをリスペクトしてくれているのを感じますね。「顧客の課題はこれ、それを解決できたら、これくらいのインパクトがある」という背景の部分を丁寧に伝えてくれる。そこから共有してもらえるから、信頼もできるし、チームとして一緒に開発を進められている手応えがありますね。

BtoB SaaSのプロダクト立ち上げに大きく寄与した「リファレンスカスタマー」の存在

──Biz以外に、初期のプロダクト開発に大きく影響した要素はありますか？

yabu：
あとは、「リファレンスカスタマー」の存在が大きいですね。リファレンスカスタマーがいたから、確信をもってプロダクトをつくれたし、方向性も変にブレずに進めることができました。私たちのようなスタートアップのプロダクト開発で、エンタープライズ企業がリファレンスカスタマーになってくれるケースはなかなかありません。スタートアップではなかなか扱えない、エンタープライズ企業の大きなデータを活用させてもらいながら、実態に即した分析ができました。

nari：
データを使えたのも大きいですし、エンジニアにとっての価値あるプロダクトを開発していると信じられる、心の拠り所のひとつでもありましたね。もし、リファレンスカスタマーがいない状態で「サポートウィジェットに価値がある」と言われても、すぐには信じられなかったかもしれません。

エンタープライズ企業がリファレンスカスタマーとして初期のRightTouchのプロダクト開発に携わってくださったのは、Bizのメンバーが信頼を築いてきたからこそ、実現できたことだと思います。

SaaSの世界では、技術やアーキテクチャの強さはもちろんですが、組織全体としての強さが大きな差別化になると思っています。Bizと一緒に、リファレンスカスタマーの協力を得ながら、市場でのポジショニングや、活用できるケイパビリティを組み合わせて開発したことで、価値あるプロダクトにできたと思います。

──事業性を考慮してプロダクトを開発することに対して、エンジニアとしての葛藤や難しさはある？

yabu：
エンジニアとしては、事業性に関係なく「こんな機能はどうだろう」と、アイデアが浮かんできます。そうやって浮かんだアイデアも、事業性が薄いと判断すれば、優先度が下がる。Bizを信頼して、事業というコトに向かっていけたことでシンプルなプロダクトを開発できました。コトに向かう、プロダクト志向な姿勢を持ち続けることは大切ですね。

nari：
プロダクトの価値に向かうことを重視して、尖った技術選定ではなく、事業成長のために最速で価値を届けられる選択をするようにしてきました。なにより、リファレンスカスタマーの本質的なニーズに応えることを大切に。オペレーションが重要であるCS領域は、求められるサービスレベルも高くなりますが、そのレベルに応えられるようにしてきました。

──それはマーケットのニーズに合わせて開発したということになるのでしょうか？

nari：
SaaSにおいてビジネス的に価値のあるプロダクトを、本当に純粋なプロダクトアウトの姿勢で進めようとすると、なかなか実現が難しいと考えています。そういう観点では、マーケットインをうまく取り入れて開発を進めてきたことで成果につながったと思います。

yabu：
マーケットインに偏重していたかというと、そうではないと思います。Bizのメンバーとの議論の際、エンジニアの目線から意見を伝えてすり合わせながら、機能を開発していきました。やりたいことを共有できている場合、それを実現するための具体的な方法にはいくつか選択肢があります。具体的な実現方法においてエンジニアの意見や考えを反映できているという意味では、プロダクトアウトだと言えるかもしれない。解くべき課題の抽象度が高ければ、エンジニアとして介在する余白はあり、面白がって取り組めると思います。

nari：
最初に、課題がBizかDevのどちらから出たのかでも、変わってきますよね。最終的なアウトプットは互いの意見をすり合わせて作らないといけませんが、バランスが崩れてどちらかに偏ってしまってもいいモノにはならない。初期のRightTouchは、Bizから課題やアイデアの種から出ることが多く、それをDevが一緒になってどう実現するかを議論していく進め方でした。

yabu：
そう考えると、マーケットインとプロダクトアウトの双方を行き来しながら、うまく融合させた開発のスタイルをとっているのかもしれない。

RightTouchでは、2人のように異なるタイプのエンジニアが集い、価値あるプロダクトを開発して顧客に届けるために日々挑戦を重ねています。

共に「あらゆる人を負の体験から解放し、可能性を引き出す」というミッションの実現に挑むエンジニアを募集しています！

関心のある方は、下記の募集をぜひご覧ください
https://righttouch.co.jp/jobs/engineer

RightTouchの採用情報はこちらから
https://righttouch.co.jp/recruitment

コンセプトもデータも重視。タイプの異なるエンジニアたちが連携して事業成長に貢献するRightTouchの開発現場