カスタマーサポート領域事業を複数展開する、私たちRightTouch。10月には、β版として提供してきたWebサポートプラットフォーム「RightSupport by KARTE」が正式リリースとなり、また新プロダクトの「RightConnect by KARTE」の提供も開始されるなど、プロダクト・チーム共に日々進化しています。
ですが、開発を担うRightTouchのエンジニアは、まだ約10名ほど。2023年11月現在、エンジニアメンバーはRightSupportチーム・RightConnectチーム・Talkチームとプロダクト機能ごとに3つのチームに分かれています。エンジニアチームは、どのような取り組みやコミュニケーションを行い、立て続けのリリースを、着実に前進させてきたのでしょうか？
チームそれぞれの特徴や仕事の進め方、今後の課題など、各チームのリーダーに座談会形式で話を伺いました！
座談会参加メンバー
RightSupportチームリーダー・yabuさん
RightConnectチームリーダー・ikkiさん
Talkチームリーダー・Aaronさん
――それぞれのチームのメンバーや役割など、特徴について教えてください。
yabu：RightSupportチームは、RightTouchの主プロダクトであるWebプラットフォーム「RightSupport by KARTE」を担当しているチームです。体制としてはエンジニア5人、デザイナー1人の計6人で、PdMは僕自身がエンジニア兼務で担当しています。
RightSupport自体が、RightTouchが提供するプロダクト全ての開発基盤でもあるため、他の2つのチームが担当していないものは全て見ているような位置付けです。また、新しく入社した人にはまず、RightSupportチームに加わってもらうようにしています。RightSupportの基盤やコードを見ることで、プロダクト全体を把握しやすいこともあり、オンボーディングを兼ねたOJTが行いやすいからです。
ikki：2023年10月17日から提供を開始した「RightConnect by KARTE（β）」の開発をしているチームです。yabuさんのRightSupportが、問い合わせ「前」の顧客体験を扱っているのに対し、RightConnectはその後のプロセス、つまり電話での問い合わせ体験と問い合わせオペレータの対応プロセスを変革することを目的にしたプロダクトです。
現在のメンバー構成はPdMが1人、カスタマーエンジニアが1人、エンジニアが3人の計5人です。新プロダクトを担当しているチームなので、顧客の生の声を集め、それを元に設計・開発・改善を重ねていくことが特に強く求められるフェーズなのが特徴だと思います。複数の職種で構成されたチームなので、様々な視点からプロダクトの議論ができるのは面白いですね。特に今は、リリース前でタスクも多いことから、エンジニアメンバーは、やるべきことを黙々と着実に進められる人が多い印象です。
aaron：Talkチームは、グループ会社のプレイドがもともと開発・運営していたプロダクトを、RightTouch設立時にRightSupport内の一つの機能として引き継いだチームになります。チームメンバーはエンジニアが2人、外部委託のエンジニアが1人、そしてPdMのチームです。
他2つのチームは、ゼロスクラッチで新しいプロダクトを開発していますが、Talkはその前提が異なります。KARTE内での歴史・顧客がすでにあるプロダクトなので、その引き継ぎをRightTouchの方に行いながら、並行して障害や問い合わせなどの顧客対応をしてきました。そのため、つい最近まで新しい開発に時間を割くことができていませんでした。移行作業がようやく落ち着いてきたので、新規開発の余裕が生まれ始めてきたところです。顧客やプレイド側との調整も多いため、総合的な技術力が求められるだけでなく、ハードシングスにも臆せず対応することが必要とされるチームかもしれません。
――RightTouchのような創業期だと、どのタスクも緊急度が高く、やりたいことが溢れている印象があります。どのように目標や優先すべきタスクを決め、組織・プロダクトとしての前進を図っているのですか。
yabu：エンジニアチーム全体で、3ヶ月単位の目標を立てています。これは全社の四半期目標から紐づいて設計されています。Q期初のキックオフでチームごとに目標を発表しています。
半年ほど前までは、目標共有後に細かな進捗を確認することはあえてしていませんでした。というのも、メンバー人数がそう多くなく、開発プロダクトもRightSupport一つだけだったので、言ってしまえば“阿吽の呼吸”で進捗できていたからです。
ですが新しい仲間も増え、プロダクトも複数になる中、チームとして各自が何をやっているかが見えない状況はまずいと思い、半年ほど前からやり方を変えました。今は、Q初めにチームで集まり、全社目標を達成するために何をやるのかといったタスク整理だけでなく、何のためにやるのか、どういう状態だと達成したと言えるのか、誰がやるのがベストか、といったことをみっちり話し合い、Notionにタスクボードとしてデータベース化しています。取り組むべきアクションや開発項目が一覧化され、進捗状況をいつでも誰でも確認できるようになったので、チーム間での可視化が進みました。
ikki：RightConnectチームはやるべきことが明確＝プロダクトリリースだったこともあり、タスクの管理らしいことはしていませんでした。ですが、yabuさんが始めたタスクボードのやり方が良いなと感じ、今Qから取り入れています。リリースもひと段落したところですが、今後はタスクや改善事項も増えてくると思います。ボードを参考に、優先度やアサイン状況を可視化していきながら開発計画を立てていきたいと考えています。
aaron：Talkチームは、業務内容と人数の制約から、今までは顧客要望や社内フィードバックをベースにやることを決定し、管理していました。今後はそのフィードバックも落ち着いてくるので、自分たちのタスク管理が重要になってくると考えています。
yabu：もちろん常に開発スケジュールに余裕があるわけではなく、全社で決まったリリース日や、緊急度の高い顧客要望など、期限にヒリヒリしながら対応することもあります。ですが、RightTouchが大事にするのはバリューでもある「インパクト志向」。リリース日が迫ってもクオリティが低ければ、大胆にスケジュールを引き直しますし、より大きなインパクトが出せる機能が提案されれば、現状のタスクを止めてそちらに舵を切ることも厭いません。
タスクやフィードバックはもちろん重要ですが、それを鵜呑みにしすぎず、「もっとインパクトが出せる方法はないんだっけ？」という対話をチームでも増やして、効果的な目標設計やタスク管理を継続して模索したいと思っています。
――チーム内では、どのようにコミュニケーションを取っているんですか？
yabu：RightSupportチームでは、完全リモートや半分出社など出社体制がバラバラなので、オフラインで気が向いたときに話す時間を設けています。また、バーチャルオフィス「Around」に入って話すこともあります。
aaron：Talkチームは随時コミュニケーションをとっているわけではありませんが、困ったことが出てきたときはSlackやZoomで話し合いや議論を重ねるようにしています。
ikki：RightConnectチームも、出社スタイルはバラバラなので、コミュニケーションの選択肢を活用してメリハリをつけています。特にプロダクトリリース前は、細かい調整や議論など対面で行った方がスムーズに進むものもあったので、その類のものは意識してオフィスで行うようにしていました。オフィスも広くなって、エンジニアにとっても快適な環境になりましたからね！
yabu：また、RightTouch全社の取り組みとしては、四半期に1回のオフサイトと月1回の全社振り返り会を行っています。エンジニアチーム横断では、隔週に1回Demo Dayを開催しています。チームごとに担当プロダクトが異なっているので、細かい仕様や設計の裏側まで把握することは正直難しいです。そこで、開発担当者がデモを見せながら詳細を発表することで、その情報格差を埋めることを目的にしています。Demo Dayが形式化しないように、慢心することなく改善し続けたいと思っています。
――各チームそれぞれが考える今後の課題は何ですか？
aaron：今までのTalkチームは、チームとしての品質担保よりも、とにかくスピード重視で顧客リクエストに対処することを最優先にしてきました。ですが、ここからは人数も増えていくフェーズです。より「チーム」を意識したレビュー・実装体制に変えていかなくてはいけないと思っています。スピーディーかつタイムリーにレビューできるような方法・体制を考えるのがこれからの課題ですね。
yabu：RightSupportチームの課題は、開発スピードを落とさないようにしながらも技術負債を減らしていくバランスを取ることですね。プロダクトフィードバックは、チケット化して貯めていますが、最近はチケットが増える一方で（苦笑）クリティカルな問題はすぐに解消していますが、手が回り切っていない段階です。プロダクトの立ち上げ期だと、どうしても新規の開発にリソースが割かれてしまいますが、中長期的なインパクトを担保するためにも、負債へ対応できる余裕を仕組みを作ってうまく生み出していけたらと考えています。
ikki：チームとしての進捗している実感をもっと醸成していきたいです。直近はリリース作業に追われていたので、それぞれがタスクをこなすことに必死でした。プロダクトのフェーズが変わったので、属人化を脱し、細かいゴールを設定・共有しながらチームで前に進んでいることを実感できるよう、タスクボードの運用など一歩一歩積み重ねていきたいです。
今回の記事では、RightTouchエンジニアメンバーが属する3つのチームの特徴を紹介しました。組織・プロダクトフェーズにとって最適な体制をとっているので、今後変わっていく可能性はもちろんありますが、今のRightTouchを少しでも知っていただけたなら嬉しいです！
より細かいチームの情報は、カジュアル面談などでお話したいと思いますので、少しでも興味を持ってくださったら、採用サイトやWantedlyからぜひ気軽にエントリーください。
▼採用サイト
https://recruit.righttouch.co.jp/engineer
▼Wantedly
https://www.wantedly.com/projects/1493065
