Haruki Kawashita

Sanshiro Sakai

Nariyuki Saito

Aaron Madlon-Kay

Tomoaki Oiki

Yuma Takeuchi

RightTouch Blog 編集部

Daichi Kanke

Yuichi Yabu

<h2>はじめに</h2>
こんにちは。<s>アニメでチ。を見てつい原作まで買ってしまった</s>RightTouchでCustomerEngineerをしている川下です。
早いもので、<a href="https://blog.righttouch.co.jp/slack-app-with-craft-functions">入社直後にブログ記事を書いて</a>から半年以上が経過しました。 
半年というと、漬け始めた梅酒がもう飲み頃になっているくらいの期間です。梅酒を漬けたことはないのでわかりませんが。
今回、テックブログを運営しているメンバーから「エンジニアがコンタクトセンター見学（以後、「センター見学」）をして感じたことについて書いてほしい」という依頼があり、久々に筆を取りました。
前回は試用期間中の執筆だったため下手なことはかけませんでしたが、無事試用期間を乗り越え自由を手にしたこの身は、自由な文体でこのブログという大空を飛び回りたいと疼いております。
ということで、旅を始めましょう。
<h2>そもそもなぜセンター見学をしてるのか？</h2>
飛び立つ前に、まずはビジネスマンらしく前提と目的の整理からです。
弊社では月~2回程度の頻度で、クライアントに依頼しコンタクトセンター見学をさせていただいています。
クライアントの電話応対やチャット応対のログを見せてもらったり、実際にオペレーターの方が応対をされているデスクやPCの画面を見せてもらったりと、内容はまちまちですが毎回顧客対応されている現場を見るということをさせてもらっています。 
※もちろん、情報管理には十二分に気をつけた上で実施しています
１回の見学でお邪魔する人数は数人程度ですが、このセンター見学には職種関係なく参加しています。
セールスもサクセスもエンジニアもアクセラレーター（管理部門の弊社での名称）も、全員等しく参加します。 それも１回で終わりではなく、何度も異なるクライアントのセンター見学に行くのが通例です。
目的はいくつかありますが、やはり質と量に優れた一次情報を取るためという点は大きいです。 
端的に言うと、センター見学をするとクライアント（とマーケット）の解像度が爆上がりするから行くのです。
事業を進める上で、マーケットの解像度は極めて重要です。
プロダクトを作るにしても、「このプロダクトは誰が、どんな場面で、どんな思いで使うのか？」を具体的にイメージできなければ、使い道のないプロダクトができてしまいます。
プロダクトを届けるにしても、「クライアントのどの業務を代替/改善するのか？」を具体的にイメージできなければ、プロダクトを運用に乗せることはできません。
常に使う人がいる以上、その人が普段何をしていて、どんなことで困っているのかをとにかく知ることが、価値を提供するためには欠かせないのです。
そしてその「クライアントをとにかく知る」ために一番良いのは、現場を直接見に行って一次情報を得ることです。
現場の方にお時間を割いていただきリアルな声を聞くことで理解を深め、そして深めた理解をプロダクトを通して価値に変換しクライアントに還元するために弊社はセンター見学を続けています。
助走が長くなりましたが、ようやく飛び立つ時が来ました。
<h2>プロローグ</h2>
某月某日、三田。 
ラーメン二郎 三田本店の吐き出す濃厚な香りが微かに届く小さなテナントビルの５階で、歓喜の声が響いた。
「え！？ようやく自分の番ですか！！？」
入社から数ヶ月、想いを募らせてきたセンター見学に、漸く参加できる時が来たのだ。
思えば、永かった。入社当初抱いていた「今時はノンボイス対応（チャット対応）もあるしコールセンターよりコンタクトセンターといった方が正しいのかな？」という些細な疑問が、時の流れの中で忘れ去られていくほどに—
今回の訪問先は某生命保険会社様のオフィス。
あの大手保険会社の現場を見せていただけるのか。筆者の心は昂った。
参加が決まってからの筆者の動きは、速かった。何の備えも無しに、その日を迎える訳にはいかない。貴重な時間を割いていただく以上、こちらも入念な準備は欠かせない。徹底的なリサーチをせねばなるまい。
センター見学の準備で抑えるべきは、クライアントの基本戦略・現在の進捗率・弊社プロダクトの導入/活用状況・抱えている課題など数多くある。 
また、失礼が無いようセンターの一般的な事情も把握しておく必要があるだろう。
社内にある過去の見学ログを読み漁りセンターの一般的な事情を把握し、さらに担当サクセスによるクライアントの現状共有により、必要な知識をインストールしていく。
これらの工程を経て、出来上がった質問リストは40個。どうしよう、こんなに質問する時間あるかな？知らないこと、知りたいことだらけだ・・・
<h2>当日</h2>
<h3>センター概要についてのご説明</h3>
モチベーションは最高潮に、いざ先方オフィスへ。時刻は14時を回った頃。 
エントランスでの簡単なご挨拶の後、早速会議室へ通していただく。 
名刺交換の後、30分程度でまずは先方コンタクトセンターの概要についてご教示いただく。
<h4>【内容】</h4>
センター全体として取り組んでいるテーマ、拠点（東京/地方エリア）ごとの差異、インバウンド/アウトバウンドそれぞれのコールフローや体制等についてのご説明。 
その後、Q&amp;A。
<h4>【感じたこと】</h4>
部署を跨いだ対応も少なくないため応対の後に引き継ぎ書を作成されているが、新人の方はこの作成に手間取ることがあったり、Voicebotの対応でも文字起こしミスがあるため人が起票していたりと、所々に「痒いところ」があることを実感。
フルスキルな人材が育つまでは１年以上はかかると言うお話もあり、改めてコンタクトセンターの業務の幅の広さと深さを痛感しました。
<h3>応対ログの確認</h3>
概要をお話しいただいたあとは、同じく30分ほどを使って（個人が特定できないよう十分なマスキングを施した）応対ログをもとに、どういった応対をされているかをご教示いただく。
<h4>【内容】</h4>
それぞれ異なるお問い合わせ内容での入電への対応。 
どちらも用件把握の後本人確認、手続き内容のご説明。 
その後、Q&amp;A。
<h4>【感じたこと】</h4>
お客様の問い合わせ内容や音声のトーンに合わせて話し方を変えているベテランオペレーターの手腕は流石と言う他ありませんでした。
今回紹介いただいた応対はどちらもVoicebotで代替可能な内容には感じましたが、音声トーンなどの「お客様に寄り添った応対」という点において人とボットとの圧倒的な差を感じました。
プロダクト開発の際はつい分かりやすい機能に目を向けてしまいますが、特に弊社がターゲットとしているカスタマーサポート市場においてはこういった「お客様の快さ」を重視する必要があると再認識できました。
<h3>モニター、利用ツールを見せていただく</h3>
その後場所を移し、実際に応対をしている執務エリアへ。 
入電音とオペレーターの方の話し声が微かに聞こえる中で、実際に使っているPCを元に操作方法をご説明していただく。
<h4>【内容】</h4>
普段使っているツールのご説明、入電時の操作の流れや応対中のツールの使い方などのレクチャー。 
その後、Q&amp;A。
<h4>【感じたこと】</h4>
自社構築のツールを使われているとのことでしたが、お客様との会話中に応対用画面とCRMと社内ナレッジを行ったり来たりと、業務難度が高いことが感じられました。 
逆に言えば、センターとしての教育レベルが相当に高いことが伺えました。
<h3>ナレッジ管理についてご説明</h3>
最後に、再度会議室に戻りナレッジ管理についてご教示いただく。
<h4>【内容】</h4>
業務項目ごとの対応スクリプトの概要や管理・更新方法、オペレーターの教育についてなどのインプット。 
その後、Q&amp;A。
<h4>【感じたこと】</h4>
「これが応対に必要な社内ナレッジの全てです」とお渡しいただいたマニュアルは、誇張抜きで広辞苑より大きかったです。そしてSVレベルになるとこの内容をほぼ全て記憶しているとのこと。凄すぎて若干の恐怖を感じました。
社内一般用・オペレーター用で同じ内容の記事を別々で管理していたりと、マニュアルの維持管理でもかなりの工数がかかっていることが伺えるため、これをITの力で楽にして本来充てるべきところにリソースを投下できるような貢献をしたいと思いました。
<h2>エピローグ</h2>
文体が変わるレベルで、驚きと学びの連続でした。 
確かに、デジタル化が進んでいない部分があったり、AIの導入でもっと楽にできる余地は大いにあるように感じます。
その反面、ただツールを統合したりSaaSを導入するだけでは解決できない問題があるということも同時に実感しました。
例えば、社内ナレッジを統合すれば二重管理の手間が減るため大きな工数削減ができるかもしれません。 
しかし、そうするとオペレーターがナレッジを読み解くのに時間がかかるようになり、それはAHTの増加につながり、ひいては待ち呼の増加などの顧客体験の悪化につながります。
我々SaaS提供企業は、ただ表面的な課題に対して解決策としてのプロダクトを提示するのではなく、クライアントのその先のエンドユーザーにまで寄り添っていかなければ、本当の意味でサポートの負の体験をなくすことはできないのだと痛感しました。
今回の見学では実際の現場を知ることで、弊社プロダクトがどう活きているか、どう活かせるかを深く知るとても良い機会となりました。 
帰り道ではサクセスメンバーと「このプロダクトは入れてもらえたら絶対体験が良くなるから提案してほしい」「しかしそうするとこういったリスクが想定できるからどう乗り越えるべきか」など熱い話を繰り広げるまでに至りました。
<h2>後日談。</h2>
と言うか、今回のオチ─
年末から自分はカスタマーエンジニアとして、Voicebotのプロダクト立ち上げに関わっています。 
<a href="https://righttouch.co.jp/news/UmmmSdRh">Voicebotは新プロダクト</a>なので、方針の話などにも同席していますが、この見学の経験が確実に活きています。
例えば、応対の基本的な流れやVoicebotを組み込んだ際のクライアントの業務フロー検討・Voicebotで発生するACW※など。実際の応対の流れを知っていることで、そこから想像力を膨らませて運用に落とし込んだ際の体験もイメージすることができるようになりました。 
※After Call Work（平均後処理時間）。顧客との通話後にオペレーターが行う作業にかかる時間の平均のこと
たった１回の見学で充分な解像度が確保できたとは考えていませんが、それでもこの経験に助けられることは多くあります。
これからも、ただ「クライアントのコスト削減に貢献できるVoicebot」ではなく、「クライアントにとってもエンドユーザーにとっても最高の体験を提供できるVoicebot」を作り、届けていきたいと思っています。
是非、この記事を読まれているあなたも、もしまだであればクライアントの現場に足を運んでみてください。豊富な一次情報を持っているのとそうでないのとでは、極めて大きな差があることをその身を以て体験できるでしょう。
<h3>オマケ（これで本当に終わりです）</h3>
クライアントのオフィスのある街はスイーツで有名だと聞き、早めに現地入りしてランチとティータイムを楽しんでからセンター見学に赴きました。 
この梯子のお陰で、最高のモチベーションと集中力によりセンター見学を120%のパフォーマンスで迎えることができました。
弊社の次のオフィス移転先はこんなオシャレなお店がある街だといいなぁ。
【内容】
ランチ：手作りボルシチとピロシキ（どっちも人生初）。どちらもアツアツ作りたて。最高。
<img src="https://ik.imagekit.io/righttouch/3be258a2-7fcc-431c-8c34-c2d995d1b8a8/se-01.jpg" alt="手作りボルシチとピロシキ">
デザート：おしゃれなカフェで紅茶と一緒にショートケーキを。何だこのショートケーキは。おしゃれすぎんだろ・・・！
<img src="https://ik.imagekit.io/righttouch/e5a7d6f5-11f9-4076-9d00-2fad7db84e71/se-02.jpg" alt="ショートケーキ">
【感じたこと】
とっても美味しかったです。流石スイーツとロシア料理の街。 
けどボルシチは熱々すぎて舌が火傷しました。痛かったです。
最後まで読んでくださりありがとうございました。
皆様も、どうかボルシチを食べる時は火傷にお気をつけて。
<h2>最後に</h2>
RightTouchではカスタマーサポート市場を一緒に動かす仲間を絶賛募集中です。 
少しでも興味を持った方がいればぜひお話ししましょう！
エンジニア求人情報の詳細 
<a href="https://righttouch.co.jp/jobs/engineer">https://righttouch.co.jp/jobs/engineer</a>
採用サイト 
<a href="https://righttouch.co.jp/recruitment">https://righttouch.co.jp/recruitment</a>

セ。〜センター見学の学びについて〜

「あらゆる人を負の体験から解放し、可能性を引き出す」をミッションに、カスタマーサポート（CS）領域に特化したエンタープライズ企業向けSaaS事業を展開する株式会社RightTouchは、プレイドからスピンオフして始まったBtoB SaaSスタートアップです。
昨年、RightTouchでは、1つ目のプロダクトであるWebサポートプラットフォーム「<a href="https://rightsupport.karte.io/">RightSupport by KARTE</a>（以後、RightSupport）」をリリースした際の中心機能であったサポートウィジェットに蓄積していた技術的負債を解消するために、サポートアクションの開発プロジェクトを推進しました。
エンジニアたちが主体的に動き、現場主導で行われた開発の裏側について、取締役CTOの籔悠一（yabu）と、プロダクトエンジニアの追木 智明（ikki）の2人に話を聞きました。
<h2>顧客の要望に応えるなかで蓄積していったプロダクトの負債</h2>
──最初にプロダクトをリリースした後のRightSupportが抱えていた課題について教えてください。
yabu： 
RightSupportは、エンドユーザーによる自己解決を促進するために、困りごとが生じたタイミングでFAQを表示できれば、という考えのもと、ポップアップ形式で情報を表示する「サポートウィジェット」という機能を中心にリリースしました。 
この機能は、企業がノーコードで配信を設定でき、エンドユーザーがサポートウィジェットをクリックすると、お困りごとの自己解決ができるというものです。リリースからしばらくの期間はサポートウィジェットだけで問題なかったのですが、少しずつ課題が生まれていきました。
<img src="https://ik.imagekit.io/righttouch/9c2d2b44-1898-4a75-a52a-21a3072b1115/suppurt_widget.png" alt="suppurt_widget.png"><center>移行前のサポートウィジェットの画面</center>
ikki： 
お客様からの要望が段々と多様になっていったんですよね。たとえば、サポートウィジェットに表示する文言をカスタマイズしたい、Webサイト内のボタンをクリックするとサポートウィジェットが表示されるようにしたい、表示する内容を分岐させたい、Webサイト内にFAQを埋め込みたい、など。お客様の要望にはできるだけ応えられるようにと、サポートウィジェットに仕様を追加して開発を進めていたのですが、徐々に限界が見えてきていました。
yabu： 
サポートウィジェットをWebサイトに埋め込むとなったときは、「はたして、それはウィジェットなのか？」という疑問が生まれて。その他の要望と合わせて、実現するためにサポートウィジェットを改良していきましたが、次第に技術的負債が溜まっていきました。
<img src="https://ik.imagekit.io/righttouch/da1b4c2f-6d07-4294-b5a8-8e203f4d8db7/IMG_6375.jpg" alt="IMG_6375.jpg"><center>取締役CTOの籔悠一（yabu）</center>
ikki： 
技術的負債以外にも課題がありましたね。当時、エンドユーザー向けに配信するシステムのフレームワークは、コンパクトさを重視してプレイドでも使用していたものを踏襲していました。一方、管理画面では別のフレームワークを活用していたので、そこの同期が難しい状態でした。たとえば、なにか新しい機能を実装した際に、お客様の画面には反映されているけれど、プレビューの画面には反映されない、といったことが起きていたんです。
yabu： 
技術的負債や仕様の負債なども溜まっていって、このままではいけないと社内で話になることも増えました。サポートウィジェットを軸に体験をつくるのではなく、体験をつくるために必要なコンポーネントを用意し、組み合わせられるようにしたほうがいいのでは、といった議論を重ねて。サポートウィジェットのまま改善していくことは止めて、工数をかけてでも理想のWebサポートを実現するための開発に着手しました。
<img src="https://ik.imagekit.io/righttouch/56e4df07-7672-4a62-b261-a2c957773bf0/support_action.png" alt="support_action.png"><center>新たに開発したサポートアクションの画面</center>
<h2>チームで進めたサポートアクションの設計と開発</h2>
──理想とするWebサポートの実現に向けて、まずどんなことから取り組んだんですか？
yabu： 
サポートウィジェットと比較して、より汎用的で将来的な拡張性を持った機能を開発しようと思い、チームで仕様を描きました。ただ、最初は理想を描きがちなので、キャンパス上でコンポーネントとコンポーネントをつないでアクションを構築していくものをつくろう、とGUIがっつりな仕様を描いていました。そうしたら、社内のエンジニアから「もっとシンプルでもいいのでは？」と海外の事例と合わせて提案されてしまって（笑）
ikki： 
yabuさんがビジョナリーに理想を語りつつ、周りのメンバーが現実的な解を見つけていくのが、RightTouchのエンジニアリングの特徴でもありますね。自分はそのなかで「どうしたらバランスがとれるだろうか？」と考えながら、仕様の設計に参加していました。
タイプが異なるエンジニアの恊働についてはこちらの記事もどうぞ。
<ul>
<li><a href="https://blog.righttouch.co.jp/interview1-rightsupport">コンセプトもデータも重視。タイプの異なるエンジニアたちが連携して事業成長に貢献するRightTouchの開発現場</a></li>
</ul>
<img src="https://ik.imagekit.io/righttouch/8df2347e-ea12-4b0c-b0ad-a8c7f8953286/IMG_6360.jpg" alt="IMG_6360.jpg"><center>プロダクトエンジニアの追木 智明（ikki）</center>
yabu： 
メンバーとの議論を経て、改めてタスクをひとつずつ設定していけば完了するような、お客様にとって使いやすいUIになるように仕様を検討。将来性も考慮して、コンポーネントを組み合わせて、さまざまなことを実現可能にしていけるモデルを設計しました。
──仕様設計の次は何に着手を？
yabu： 
まずは、プロトタイプをつくりましたね。サポートアクションの開発をするまではプロダクトの中での開発が中心でしたが、大型の開発をするために「サンドボックス」をつくって、実験をしていきました。実験と議論を繰り返しながら、モデルの型を固めていきました。 
モデルの形を定義する力を高めるために、TypeScriptの型をクイズ形式で勉強するサービスをチームみんなでやろう、という話になったんです。そしたら次の週には、nariさんが「自分がわからない姿を見せるのが嫌だから」ってひとりで全部解いてしまった、なんてこともありました（笑）結局、Devメンバーが集まるランチミーティングのときに、わいわいみんなで挑戦しました。
──なんだか楽しそうな雰囲気ですね（笑）
yabu： 
大変なプロジェクトではありますが、シリアスな雰囲気にはならなかったですね。実験を重ねたおかげで、仕様も決まり、柔軟なモデルもできたので、あとはチーム全員でサポートアクションを実装していきました。実際に形になった機能を触ったときは、純粋に楽しかったですね。 
ある程度、実装が進んだ後は、社内でお披露目をして、しっかりとドッグフーディングを実施。おかげで、開発チームだけでは気付けない問題点も見つけることができて、修正を進めて完成度を高めていきました。
<h2>顧客の協力のもと、サポートアクションへの移行を進める</h2>
──サポートアクションの開発が完了した後、移行をどのように進めていったのでしょうか？
yabu： 
開発がおおよそ終わったのが2023年の年末、2024年1月にサポートアクションをリリース。このタイミングで、RightTouchでテックリードとして複数のプロダクトを横断的に見ているnariさんが異動のためチームから抜けて、サポートアクションへの移行をikkiさんがリードすることになったんですよね。
ikki： 
そうなんです。「やります！」って言ったはいいものの、内心は何からやればいいんだろうと不安でしたね（笑）まずは現状把握から進めて、設定されていたサポートウィジェットが全部でどれだけあるのか、どんなお客様がどのようにサポートウィジェットを使用中なのか、などを確認していきました。 
移行には、カスタマーサクセスの協力が必須だったので、4名のカスタマーサクセスメンバーと毎週定例会議を実施して、それぞれのお客様の移行状況を確認するようにしました。お客様は「そもそもサポートアクションとはなにか？」ということがわからないので、頭出しをしながら移行を進めていきました。
yabu： 
サポートアクションの開発を進めている際に、どうやって移行をしていくかについても練らないとな、とは考えていたんですよね。たとえば、サポートウィジェットをサポートアクションに変換するロジックを組んで、自動で切り替えるシステムをつくれないか、など。開発し始めたときには考えていたものの、開発自体にリソースがかかってなかなか移行については追いついていない状況だったんですよね。
<img src="https://ik.imagekit.io/righttouch/ee947e4e-5591-4568-b74b-3ebe3252141e/IMG_6352.jpg" alt="IMG_6352.jpg">
ikki：結局、システマチックに一括で移行するのは、各お客様の状況に合わせて対応するのが難しかったため、見送りにしましたね。当時は、お客様の数もまだ60〜70社ほどだったので、人力での移行を進めることにしました。 
当時のサポートウィジェットの数は、全体で合計1500ほど。お客様ごとに偏りがあって、積極的に活用しているお客様であれば100種以上のサポートウィジェットを設定してました。このサポートウィジェットは将来的にコードをなくすことが目標なので、ひとつでもサポートウィジェットを残すわけにはいきません。すべてのサポートウィジェットを移行する必要がありました。
──お客様への働きかけはどう進めていったのでしょうか？
ikki： 
「これまでのサポートウィジェットよりも、サポートアクションのほうが圧倒的にいろんなことをできるんです！」、ということを丁寧に伝えていきました。たとえば、説明会を開催して、お客様のやりたいことはサポートアクションでさらに実現できると伝えました。 
「できることが広がるのなら」と、喜んで移行に対応してくれたお客様もいらっしゃいましたね。協力してくださるお客様が多くて、これはカスタマーサクセスのメンバーが日頃から関係を構築できていたからこそ実現できたことだと思います。 
移行されて減少したサポートウィジェットの個数を可視化して、サポートアクションのほうが個数が大きくなったタイミングでSlackに共有して「超えました！」と投稿したり、移行状況をグラフ化したりして、お祭り感を出すようにしました。
<img src="https://ik.imagekit.io/righttouch/ab6453d7-a2b1-4a01-b7b8-7e9aac439e35/image6.png" alt="image6.png"><center>移行状況のグラフを共有した際のリアクション</center>
yabu： 
新しいメンバーにサポートアクションへの移行を担当してもらって、新機能のオンボーディングを兼ねるなど、メンバーの巻き込みはいろいろ工夫しながらしましたね。
ikki： 
ほかには、サポートアクションの機能をつかって、サポートウィジェットの機能がクローズするというお知らせを出すなどの活用もしました。思い浮かぶことを試しながら、お祭り的に進めていきました。 
移行は2024年2月からスタートし、ほとんどの移行は4月には完了。一部、動作確認が必要なお客様がいたため、そこから2ヶ月ほどかかって、6月ごろに移行完了。この移行は、RightTouchが経験した移行プロジェクトとしては相当に大きいものだったので、やりきれたことで自信につながりました。
<h2>「全員プロダクト担当」だから素早く実現できた新機能への移行</h2>
──サポートアクションに移行してみて、感触はどうですか？
yabu： 
サポートウィジェットのときに複雑になりすぎて実装できなかった機能を、サポートアクションに切り替えることで数多く追加できるようになりました。以前は、既存機能との兼ね合いを考えながら新機能を開発しなければなりませんでしたが、サポートアクションではコンポーネント間の結合度が低いため、新機能の開発に集中しやすくなりました。これからもさまざまなコンポーネントを追加していく予定なので、さらにサポートアクションを進化させられるのは楽しみですね。 
開発以外のことも含めると、今回のサポートアクションの開発と移行は、会社にとって大きな変更です。これを実行できたのは、自分以外の経営層も今回の件に対して「本質的に価値のある移行であり、コストをかける必要がある」と理解し、意思決定したことが良かった。Devチームに対する信頼もあり、「全員プロダクト担当」というMind（RightTouchのValue）のもと、部署をまたいでワンチームで動けたことで、スピード感をもって話を進めることができました。
<img src="https://ik.imagekit.io/righttouch/3c36c681-19ec-41b3-9438-9b7628890f42/IMG_6400.jpg" alt="IMG_6400.jpg">
ikki： 
新旧の機能が混在していると新機能の価値がすべてのお客様に届かず薄れてしまうので、この移行はなんとしてもやり切らなければならない、という強い意志があったことも、推進の後押しになったと思います。技術的負債や仕様の負債を、いつ解消するのかというタイミングは常に難しい問題です。今回はあえて工数を投じてでも思い切って作り直す決断をしたことで、RightSupportで実現できることの幅が大きく広がったと感じています。
共に「あらゆる人を負の体験から解放し、可能性を引き出す」というミッションの実現に挑むプロダクトエンジニアを募集しています！
関心のある方は、下記の募集をぜひご覧ください 
<a href="https://righttouch.co.jp/jobs/engineer">https://righttouch.co.jp/jobs/engineer</a>
RightTouchの採用情報はこちらから 
<a href="https://righttouch.co.jp/recruitment">https://righttouch.co.jp/recruitment</a>

「全員プロダクト担当」で挑んだ技術的負債の解消。新機能への移行プロジェクトの裏側

2025/3/4に弊社オフィスにて、「<a href="https://pesess.connpass.com/event/344220/">Product Engineer Session #1</a>」を開催いたしました。
Product Engineer Sessionは「技術力だけでなくユーザー価値を最も大切にし、プロダクト視点で日々の開発に向き合っているプロダクトエンジニアの交流の場」としてRightTouchのエンジアメンバーが立ち上げたコミュニティです。
第1回ながら、当日はエンジニアやPdMを中心にいろんな形でプロダクトに関わるたくさんの方にご参加いただきました！
<img src="https://ik.imagekit.io/righttouch/1416f66f-cdea-4aea-a4ee-73c77b480493/250304-01.jpg" alt="イベント開始時の会場の様子">
<h2>当日レポート</h2>
当日は5人の方がプロダクト開発に関する知見をLTしてくれました！ 
RightTouchからも2名のエンジニアが登壇しました！
<h3>小規模組織のプロダクトエンジニアとしてアンラーニングしたこと（株式会社RightTouch Hedrallさん）</h3>
<ul>
<li>小規模組織におけるプロダクトエンジニアとして、従来のエンジニアが仕様以降を担当するだけでなく、要件、戦略にも入り込んでいく重要性について語っていました。</li>
<li>スライド: <a href="https://speakerdeck.com/righttouch/xiao-gui-mo-zu-zhi-nopurodakutoenziniatosite-anraningusitakoto">https://speakerdeck.com/righttouch/xiao-gui-mo-zu-zhi-nopurodakutoenziniatosite-anraningusitakoto</a></li>
</ul>
<img src="https://ik.imagekit.io/righttouch/0ca8d4ea-bc3f-4c7c-85c6-be7b5023bc61/250304-02.jpg" alt="小規模組織のプロダクトエンジニアとしてアンラーニングしたこと">
<h3>プロダクトの価値を考えたらメイン機能を1から実装し直すことになった話（株式会社RightTouch toikiさん）</h3>
<ul>
<li>プロダクトを作っていると必ず遭遇する「作り直したい」というタイミングにおいて、ドラスティックな意思決定をした上で利用推進をプロダクトエンジニアがやることの重要性についてにお話しされていました。</li>
<li>スライド: 非公開</li>
</ul>
<img src="https://ik.imagekit.io/righttouch/bf15f0c8-61c3-4314-b102-ab9360c032e2/250304-03.jpg" alt="プロダクトの価値を考えたらメイン機能を1から実装し直すことになった話">
<h3>AIスタートアップのCEOが求めるProduct Engineerの役割（nmatsumoto4さん）</h3>
<ul>
<li>AI時代のプロダクト開発において、どこにベットするのか？不確実性とどう戦うのか？など難しい意思決定が必要な状況の中でエンジニアに求められる立ち回りについてお話しされていました。</li>
<li>スライド: <a href="https://speakerdeck.com/nmatsumoto4/aisutatoatupunoceogaqiu-meruproduct-engineernoyi-ge">https://speakerdeck.com/nmatsumoto4/aisutatoatupunoceogaqiu-meruproduct-engineernoyi-ge</a></li>
</ul>
<img src="https://ik.imagekit.io/righttouch/8411271c-a4b5-49c6-b1aa-1396b60b1d2e/250304-04.jpg" alt="AIスタートアップのCEOが求めるProduct Engineerの役割">
<h3>0→1フェーズで社内ツールを作ったら思ってた以上に使われるツールになった話（nusukeさん）</h3>
<ul>
<li>ふとしたきっかけで0→1フェーズにおいて高速で検証を回すための社内ツールの開発したことや、社内ツールであっても通常のプロダクト同様ユーザーヒアリングなどを行い、いかにユーザーに近い位置で開発するかの大切さについて共有してくださいました。</li>
<li>スライド: 非公開</li>
</ul>
<img src="https://ik.imagekit.io/righttouch/3b7feb6d-9657-4ec2-9dde-cf0ffc594c88/250304-05.jpg" alt="0→1フェーズで社内ツールを作ったら思ってた以上に使われるツールになった話">
<h3>エンジニアがPdM領域に踏み込む挑戦——10%ルールの実践と学び（MasayaOkudaさん）</h3>
<ul>
<li>組織においてボトルネックになりがちなPdMを少しでも補うために取り組んでいた10%ルールの取り組みと、実際にやってみたことによるリアルな失敗談や気づきを話してくださいました。</li>
<li>スライド: <a href="https://speakerdeck.com/masayaokuda/enziniagapdmling-yu-nita-miip-mutiao-zhan-10-percent-rurunoshi-jian-toxue-bi-0980cc86-e6d0-440d-b8e0-162ee8775106">https://speakerdeck.com/masayaokuda/enziniagapdmling-yu-nita-miip-mutiao-zhan-10-percent-rurunoshi-jian-toxue-bi-0980cc86-e6d0-440d-b8e0-162ee8775106</a></li>
</ul>
<img src="https://ik.imagekit.io/righttouch/52c1ef5c-dc44-4bcd-9745-a1f9262986ef/250304-06.jpg" alt="エンジニアがPdM領域に踏み込む挑戦——10%ルールの実践と学び">
<h2>懇親会</h2>
懇親会までたくさんの方が残ってくださり、お互いに普段どんな形でプロダクト開発に携わっているかなどを語り合っていました。
実は当日は雪が降っており、公共交通機関がどうなるかもわからない中、解散時間が過ぎてもしばらく話しているくらいには盛り上がっていました！
<img src="https://ik.imagekit.io/righttouch/ad5094ca-52dd-4d47-bbd9-5b95698c8c75/250304-07.jpg" alt="懇親会の様子">
<h2>参加した方の声(一部抜粋)</h2>
<div style="margin-inline: auto; max-width: 550px;">
<blockquote class="twitter-tweet">今日めちゃくちゃイベント楽しかったし勉強になりました！RightTouchの皆様、企画いただきありがとうございました✨🙌 <a href="https://twitter.com/hashtag/PdESession?src=hash&amp;ref_src=twsrc%5Etfw">#PdESession</a>&mdash; okkun (@masaya_okuda) <a href="https://twitter.com/masaya_okuda/status/1896916984643858824?ref_src=twsrc%5Etfw">March 4, 2025</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
<blockquote class="twitter-tweet">色々なプロダクト開発の話が聞けて楽しかった！ 定期的に他社の事例を聞くのは大事だなと改めて感じました。 LTする機会もいただきありがとうございました🙇<a href="https://twitter.com/hashtag/PdESession?src=hash&amp;ref_src=twsrc%5Etfw">#PdESession</a>&mdash; nusuke (@nusuke_y) <a href="https://twitter.com/nusuke_y/status/1896945276038099261?ref_src=twsrc%5Etfw">March 4, 2025</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
<blockquote class="twitter-tweet">各社、プロダクトの発展という軸でエンジニアリングができていて素晴らしい✨️<a href="https://twitter.com/hashtag/pdesession?src=hash&amp;ref_src=twsrc%5Etfw">#pdesession</a>&mdash; takuya CTO #GoogleCloud Next LV (@takuya_stmn) <a href="https://twitter.com/takuya_stmn/status/1896891200340472077?ref_src=twsrc%5Etfw">March 4, 2025</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
</div>
<h2>Product Engineer Session #2やります！</h2>
<img src="https://ik.imagekit.io/righttouch/323945de-5d13-4e5e-841e-34cfd6ff38de/%E3%82%B5%E3%83%A0%E3%83%8D%E3%82%A4%E3%83%AB(2).png" alt="pes_2.png">
とても素敵な会となった第1回ですが、なんと第2回も開催することになりました 🎉
すでにLTの抽選枠は定員オーバーしており、今回も盛り上がること間違いなしです！
オフライン参加枠はまだまだ枠がありますので、ご興味のある方はぜひ<a href="https://pesess.connpass.com/event/346505/">こちら</a>からご参加ください！
<h2>最後に</h2>
RightTouchではカスタマーサポート市場の改革に挑むプロダクトエンジニアを絶賛採用中です。 
少しでも興味を持った方がいればぜひお話ししましょう！
エンジニア求人情報の詳細 
<a href="https://righttouch.co.jp/jobs/engineer">https://righttouch.co.jp/jobs/engineer</a>
採用サイト 
<a href="https://righttouch.co.jp/recruitment">https://righttouch.co.jp/recruitment</a>

「Product Engineer Session #1」を開催しました

RightTouch Blog編集部です！
2025/1/29に株式会社estie、ASCEND株式会社、株式会社RightTouchの3社合同で「<a href="https://estie.connpass.com/event/340354/">プロダクトエンジニア〜ユーザー価値を支える技術〜</a>」というイベントを開催しました。
各社からフェーズや成り立ちが異なるプロダクトエンジニアが集い、ユーザー価値の向上やプロダクト開発における新たなアプローチを紹介しました。
<h2>小規模組織のプロダクトエンジニアとして、アンラーニングしたこと</h2>
RightTouchからは<a href="https://x.com/_hedrall">小室(com)</a>が「小規模組織のプロダクトエンジニアとして、アンラーニングしたこと」という題目で登壇しました。
<img src="https://ik.imagekit.io/righttouch/ff937a42-4899-4767-89db-29c92ac17764/250129-01.jpg" alt="登壇風景">
当日の発表スライドを公開しているので、ぜひご覧ください。
<iframe class="speakerdeck-iframe" frameborder="0" src="https://speakerdeck.com/player/ebf23dd9f53746fc8a30087f94f3a33a" title="小規模組織のプロダクトエンジニアとして、アンラーニングしたこと" allowfullscreen="true" style="border: 0px; background: padding-box padding-box rgba(0, 0, 0, 0.1); margin: 0px; padding: 0px; border-radius: 6px; box-shadow: rgba(0, 0, 0, 0.2) 0px 5px 40px; width: 100%; height: auto; aspect-ratio: 560 / 315;" data-ratio="1.7777777777777777"></iframe>
<h2>PdMがいないチームにおけるエンジニアの役割とは？</h2>
PdMがいないチーム体制においては、これまで仕様と設計にフォーカスしてきたエンジニアも戦略や要件に入り込んでいくことが非常に重要になります。
<img src="https://ik.imagekit.io/righttouch/559fc6cc-57ae-4266-94ae-96d94c56e704/250129-02.jpg" alt="プロダクトエンジニアは要件・仕様・設計のプロダクト全体に責任を持つ">
特に新規プロダクトの初期には代表が直接コミットするケースがあります。この場合、視座の違いから従来のフレームワーク等では議論の粒度が揃わないケースが多く、議論から落とし込まれたタスクも状況の変化によってすぐに無意味なものになりがちです。
さらに、<a href="https://www.amazon.co.jp/INSPIRED-%E7%86%B1%E7%8B%82%E3%81%95%E3%81%9B%E3%82%8B%E8%A3%BD%E5%93%81%E3%82%92%E7%94%9F%E3%81%BF%E5%87%BA%E3%81%99%E3%83%97%E3%83%AD%E3%83%80%E3%82%AF%E3%83%88%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88-%E3%83%9E%E3%83%BC%E3%83%86%E3%82%A3%E3%83%BB%E3%82%B1%E3%83%BC%E3%82%AC%E3%83%B3/dp/4820727508">INSPIRED</a>で定義されているような理想的なPdMは実質スーパーマンであり、RightTouchのような様々なプロダクトを並行して立ち上げるような組織においてはボトルネックになる可能性が非常に高いです。
PdMというチーム機能を補う上で、意識的にエンジニアが戦略や要件のすり合わせに入っていくことで限られたリソースの中でも効果的が議論がしやすくなるということを語っています。
<h2>プロセスは変わっても、開発の基礎は変わらない</h2>
日々流動的に状況が変わっていく中でエンジニアとしての立ち振る舞いも都度変化していきます。とはいえ、開発の基礎は常に変わらない部分としてエンジニアとして制御しやすい部分です。
<img src="https://ik.imagekit.io/righttouch/1286772f-2b44-4450-a285-bdec25de0516/250129-03.jpg" alt="Clean ArchitectureやDDDなどを取り入れる効果">
Clean ArchitectureやDDDなどを積極的に取り入れることで
<ul>
<li>プロダクトの雛形を作ることによる横展開のしやすさ</li>
<li>PdMがいない環境での思考をモデリングという形で残し、不確実性の高い状況においても一貫した思考と説明をするためのメンタルモデルを構築しておくこと</li>
</ul>
など、新規プロダクト開発においてこれまで培ってきた知見をこだわりを持って実行していくことも大切であるという話で全体を締め括りました。
<h2>プロダクトエンジニアのコミュニティ始めます</h2>
RightTouchでプロダクトエンジニアとして活躍するメンバーが主体となって「Product Engineer Session」というコミュニティを立ち上げました！
「Product Engineer Session」は、技術力だけでなくユーザ価値を最も大切にしてプロダクト視点で日々の開発に向き合っているプロダクトエンジニアの、ユーザーに価値を届けるためのフルサイクルの活動の中で得られた知見や気づきを共有し合う交流の場です。
<a href="https://pesess.connpass.com/event/344220/">初回のイベント</a>を3/4(火)にRightTouchのオフィスで行います！
<a href="https://pesess.connpass.com/event/344220/"><img src="https://ik.imagekit.io/righttouch/72159e16-9a62-4eff-8455-23d39d1d8006/pdesession.png" alt="Product Engineer Session #1"> 
</a>
エンジニアに限らず、PdM、Engineering Manager、Designerなど、価値を生むプロダクト開発について日々考え実践されている方の、より深い学びの場になると信じていますので、興味がある方はぜひご参加ください！
<h2>最後に</h2>
RightTouchではカスタマーサポート市場の改革に挑むプロダクトエンジニアを絶賛採用中です。 
少しでも興味を持った方がいればぜひお話ししましょう！
エンジニア求人情報の詳細 
<a href="https://righttouch.co.jp/jobs/engineer">https://righttouch.co.jp/jobs/engineer</a>
採用サイト 
<a href="https://righttouch.co.jp/recruitment">https://righttouch.co.jp/recruitment</a>

2024年の記事

Archives

Writers

2024年 の記事

Archives

Writers

2024年の記事