こんにちは、株式会社ベーシックの山下です。
私は現在ベーシックのPLG事業部に所属し、フォーム作成管理ツール「formrun」の事業に携わっています。

私は2022年4月に正社員として入社したばかりの新卒1年目ですが、2021年の6月から内定者インターンとして働いており、ベーシック歴という意味では1年を少し過ぎたくらいになります。

私がベーシックに入社しようと思った大きな理由として、ベーシック社員の「人の良さ」に加え、年の近い先輩社員が行なっている「仕事の裁量の大きさ」に惹かれたことが挙げられます。
実際に私も、社員になった直後に、お客様からformrunへいただいたお問い合わせのfirst reply time（初回返信時間）の短縮プロジェクトのリーダーを任されました。

インターンとして事前に働いていたからということもありますが、同じく新卒として働き始めた大学の友人は、まだまだ絶賛研修中だったり、先輩社員のサポート業務をしているという人が多く、本当に早くから裁量を与えてくれる喜びと心地良い重圧を感じながら毎日働いています。

今回のnoteでは、ベーシックで働き始めてから1年という節目に当たり、私がどのようにプロジェクトに取り組んだのか、新卒として入社した私から見るベーシックの雰囲気や魅力をご紹介したいと思います。
以下のような方にぜひ読んでいただけると嬉しいです。

formrunとは

まず始めに、私が現在携わっている「formrun」というサービスについて簡単に説明させてください。formrunは、「お問い合わせ」「申し込み」「アンケート」など40種類のテンプレートから適したものを選択するだけで手軽にフォームを作成でき、お問い合わせがあったエンドユーザーの管理や、エンドユーザーへのメール送信などを、一気通貫で対応できるサービスです。

formrunをご利用いただくお客様としては「お問い合わせ対応が属人化していた」「フォームを作成するのに制作会社やエンジニア・デザイナーとの連携が必要で、時間がかかりすぎる」などの課題を抱えている方がメインです。

formrunはそれらを解決し、フォームを使う人が煩雑な作業から解放され、本来情熱を捧げるべきコアな業務に集中できる世界を目指しています。

後の話と関連するので少し補足しますが、formrunはいわゆるPLG（Product-Led Growth）型と呼ばれるSaaSです。PLGで有名なプロダクトといえば、Notion、Slack、Zooｍ、Dropboxなどが挙げられますが、どのプロダクトも基本的にはセールスが存在せず、プロダクトの改善を日々行い進化させることで、口コミやWebマーケティングを通じて、プロダクトの認知を広げていくモデルになっています。

このPLGについては、PLG事業部長である佐々木が以下の記事でも詳しく語っていますので、よろしければ合わせてご覧ください。

エンハンス＆サポートグループの役割

そんなformrunを運営するPLG事業部ですが、その組織体制は以下のようになっています。

私はその中でエンハンス＆サポートグループに属しており、いわゆるカスタマーサポートの機能もこの中に含まれています。日々のお問い合わせへの対応や、新機能リリース対応に加え、プロダクトグループと連携し、顧客の声をよりプロダクトへ反映させるための機能改善策を考えることも行っていることが特徴です。

そのため、お問い合わせに対する対応スピードやサポート満足度の改善はもちろん、プロダクトの改善件数などもKPIとしています。

このプロダクト改善へも貢献するというのは、まさにfomrunのカスタマーサポートの特徴であり、より具体的な仕事内容と面白さについては、同じくPLG事業部で働くワタナベが詳しく紹介していますので、よろしければ合わせてご覧ください。

お問い合わせ対応における課題

ありがたいことに2022年8月現在、formrunは20万を超える多くのユーザーにご利用いただいています。

ユーザー数が多い分、日々の機能リリースや改善に関してのご質問も多く、1日のお問い合わせ数は少なくとも20〜30件はあります。
お問い合わせの対応フローについては後ほどまたご紹介しますが、ユーザー様に正しい案内をするため、私ともう1人の2名体制でお問い合わせに対する返信の下書き内容の“レビュー（確認）”を行うプロセスを取っていることもあり、その件数の対応をしようとすると、それだけで1日が終わってしまうこともあります。

そんな中、冒頭で触れた通り、私が取り組むことになったプロジェクトが、このお問い合わせ対応におけるfirst reply time（初回返信時間。FRT。）の短縮でした。

それまでのformrunのサポートでは、とにかく対応の「質」に重点を置いていました。間違った案内をせず、より分かりやすく、ユーザー様に寄り添った回答をすることが重視されていました。
もちろんそれはそれで非常に重要なことではあるのですが、先ほどお伝えした通り、formrunはPLG型のサービスです。PLGはセールスがいない組織だからこそ、プロダクトが成長するためには、お客様が迷いなく、より迅速にサービスを利用できることが重要になります。

しかし、それまでのFRTの中央値を改めて確認してみたところ、3時間40分ほどかかっていることが分かりました。私はformrunの前に、別の事業部であるferret One事業部でもインターンをしていたのですが、そこでのFRTが30分であったことと比較しても、これは決して早いとは言えないスピード感でした。

これではお客様が迅速にサービスを利用することの妨げにもなりかねず、PLGであるfomrunだからこそ、このFRTの長さは明確に課題であり、短縮が必要な状態でした。

そこで、まずはプロジェクト開始からの約2カ月間で、それまでの対応の質は維持しつつ、FRTの中央値を現状の約半分の時間である「1時間30分以内」にするという目標を掲げ、お問い合わせ対応を担当している他のメンバーも巻き込みながら、私がプロジェクトのリーダーとして推進することになりました。

初回返信時間を改善するための取り組み

FRT半減に向けて、まずは現状のお問い合わせ対応のフローを洗い出しました。そしてそれを分析した結果、FRTが長かった理由には、主に以下の2つがあると考えました。

• お問い合わせがきた順に対応できておらず、後回しになっているお問い合わせがある

• エンジニアを巻き込んだ技術的な確認・調査が必要なお問い合わせがある

上記を解決するためにいくつか施策を行ったのですが、今回はその中でも比較的インパクトが大きかった以下の3つをお話しします。

①お問い合わせに着手するまでのフローの変更

formrunのサポートグループでは、formrunのフォームを複数活用し、お問い合わせを受け付けています。また、formrunの各種お問い合わせフォームと社内コミュニケーションツールであるSlackを連携し、どのフォームからお問い合わせがあった場合でもSlackの1つのチャンネルに受信通知が届くよう設定しています。

しかし、お問い合わせ対応する際は、
1.“複数フォーム”のボード画面からお問い合わせを確認する

2.「担当者」を自分に変更する

3.お問い合わせの内容を確認する

4.返信の下書きを作成する

5.他のサポートメンバーによる二重チェック
6.送信
という流れでした。

このフローだとチームに複数人いる下書き作成者が、担当するお問い合わせを自由に選べる状態になります。また、どのお問い合わせが先にきているか別フォームと比較しなければならず、手間がかかる状態でもありました。

先ほどもお伝えした通り、FRTを短縮するためには、お問い合わせがきた順に即対応することが重要であるため、以下のようにフローを変更しました。

複数フォームの通知が同じチャンネルに届くようにしているため、複数フォームを作成していたとしても、先に来ていたお問い合わせが取り残される状態がなくなりました。

②10分考えて分からなければ相談してもらう

先ほど、FRTが長くなってしまっている理由の1つに「エンジニアによる技術的な確認・調査が必要な場合に時間がかかっている」ということを挙げましたが、このような場合は仕様なのかバグなのかの切り分けや、そもそもこれまで対応したことがない種類のお問い合わせであることが多いため、通常のお問い合わせと比べても難易度が高く、結果はるかに時間がかかってしまうという構造だったのです。

私自身も過去そうだったのですが、責任感が強いと「自分の力でなんとか対応しよう」と思いがちですが、10分考えてもわからなければ、その後どれだけ時間をかけてもアウトプットの質は大きくは変わらない、もしくは、結果的に誤った方向性のアウトプットとなってしまい二重に時間がかかってしまうということを痛感していました。

その解決のため、各下書き作成者に、10分考えて回答の方向性が分からない場合はすぐに相談してもらうことを改めて徹底しました。そしてその結果、エンジニアの確認がやはり必要となる場合は、素早く確認に移ることができるようにしました。

その上で、ただその方針を伝えるだけでは、下書き作成者からレビュアー（下書きの確認や修正を行うメンバー）への相談ハードルは下がり切らず、また、相談内容をSlackに書き起こす手間も発生してしまうと考えました。

そのため、その方針に加えて、お問い合わせ対応をしているメンバーが対応中は、常にSlackのハドル（グループ通話）に入ってもらうようにしました。通常はミュートにしておき、何か相談がある際はミュートを外して相談したいメンバーに呼びかけてもらう形です。ハドルの機能を利用することで、PCの画面を共有しながら話すことができるため、メンバー間の認識をすり合わせやすく、スムーズに相談しやすい環境を作っています。

③ 日々の振り返りと型化を徹底する

上記①②を行った上で、対応時間と対応状況の振り返りを日々行うことにしました。

• お問い合わせは何件きていたのか、その日のFRTの中央値はいくつだったのか、

• FRTが1時間30分を超えてしまったお問い合わせはあったか、あったとしたらどのフローに時間がかかったのか

• 時間がかかってしまったのは、今の施策が定着していないことが原因か、そもそも今の施策ではカバーできないものなのか

など、あくまで施策を打って終わりにするのではなく、その実装状況を徹底的に確認することを意識しました。

そしてこれら施策①②③、及び日々の振り返りの結果を踏まえ、最終的には以下をFRT短縮のための型として固めました。

取り組みの結果と、大切だと感じたこと

これらの結果、4月初めに3時間40分だったFRTは、5月末には目標として置いていた半減を大きく下回る1時間9分まで短縮されました。また、その後も施策の実行や振り返りを継続した結果、6月末には47分まで改善することができました。

大幅に短縮することができたのは、もちろん上司やサポートチームのメンバーの支えや協力があったからこそですが、今回プロジェクトリーダーとして、自分で施策を考え実行し振り返り、PDCAを回しながら改善に取り組めたことは、自分にとって学びになることが多かったです。この改善に取り組む中で大切だと感じたことは以下の3つです。

①まずは試す

自分の性格上、「失敗したくない・初めから完璧な施策で挑みたい」という気持ちがどうしても強くなってしまいがちです。しかしそれでは、わからないことをずっと抱えてしまい、進捗がない状態にもなりかねません。変なプライドは捨て、小さなことでもまずは試す姿勢に変えました。

「こんなに小さなことを試しても変わらないかもしれない」と思っていた施策を実行してみると、それが意外と効果があり、試して初めて分かることが多くあると学びました。もちろん取り組んだ施策の中で、あまり効果がなかったものもありましたが、失敗から学ぶことも多く、思い切って試すことができました。

ベーシックには「TRY&LEARN」という行動規範を掲げています。これは「間違ってしまっても、意志や理想を持ったチャレンジには学びがあり、それを次回に活かせばいい」という考え方であり、チーム内にも浸透している考え方のため、たとえ試した施策に効果が見られなくても、周りから咎められることもなく、安心して仕事ができました。

新卒1年目でまだまだ未熟であるにもかかわらず、私の意見を尊重し、自由度の高いタスクを与え、挑戦と学びの機会をくださった上司やサポートグループのメンバーには心から感謝しています。

②周りの人に頼る

プロジェクトリーダーに任命される前からカスタマーサポートの業務は行っていたものの、前述の通りそれまでのカスタマーサポートの方針は質重視だったため、いざFRTを短くするとなっても、最初は何をすればいいのかが正直具体的には分からない状態でした。
まずフローを書き出し、何にどのくらい時間をかけているのかを整理してみましたが、それでも1人では影響の大きそうな改善策を出すことはできませんでした。

新卒で入社したばかりということもあって、できるだけ周りに迷惑をかけず、自分だけの力で解決したい気持ちが初めは強かったのですが、そのこだわりだけでは結局何も進まないと思い、思い切って当時の上司のワタナベに相談・壁打ちをしました。
ワタナベは私からの相談を受けて、ただ答えや改善策を私に伝えるのではなく、あくまで私の意見や考えを尋ねた上でフィードバックをくれたり、迷ったときは目的に立ち返って考えることの重要性を何度も教えてくれました。

結果的にはこの相談を通じて、FRT改善のためにより有効な施策の方向性が固まり、また何度も自分の考えに対するフィードバックをもらうことで、自分自身の考える力もより深まったと感じています。

前述の通り、新卒社員は概して自分で抱え込みがちかと思いますが、大事なのはあくまでチームのミッションだと思っています。自分の変なこだわりや周りへ相談することへの恐れで、ミッションの達成が阻害されては何の意味もありません。

まずは自分で徹底的に考えることが前提ではありますが、それでも突破口が見えない時は、適切なタイミングで適切な人に頼ることが重要だと思っています。この”頼ることの重要性”については、改めて見てみると現上司の佐竹が同じく新卒自体に以下のnoteを書いていたので、恐らく多くの新卒が通る道なんだと思っています（笑）。

③大きな変更がある時はテキストではなく口で伝える

私が内定者インターンとしてformrunのカスタマーサポートを担当するようになって以降、お問い合わせのフローが大きく変わることはなかったため、今回のプロジェクトでFRTを短縮するにあたり、「サポートグループのメンバーに方針の変更や新しく施策の実行のお願いしてしまうことが負担ではないか」「フローとして定着するか」などとても不安に感じていました。

formrunではテレワークで仕事をしている人が大半のため、通常はSlackを利用しテキストベースでコミュニケーションを取ることが多いのです。
しかし、今回は方針自体が大きく変わることもあり、きちんと施策の意図や詳細を説明し、不明点やご意見を聞き、それを解消した上でチームで施策を実行したかったため、プロジェクトの内容についてはオンラインミーティングで説明することにしました。

口頭で伝えることによって、メンバーの表情や反応をみながら「この施策は馴染みそう・この施策は微妙かもしれない」ということをより具体的にイメージすることができました。
改めて振り返ってみても、プロジェクト初期にこれを通常と同じくテキストで行っていては、チームの中で完全には方向性が擦り合わず、今回ような成果が出せなかったと感じています。テレワークを活用して効率的にテキストコミュニケーションをベースに業務を行いつつ、必要なタイミングで口頭での説明を交えることの重要性を感じた一件でした。

今後の目標

今後は今回のプロジェクトを通じて改善できた、1時間以内のFRTということを確実にキープしつつ、さらに質の高いサポートを行うことを目標にしています。

FRTの観点に加え、formrunユーザーには「回答時間の満足度」「サポートの回答内容の満足度」をヒアリングしているのですが、6月時点でそれぞれ約94%、約84%という結果でした。5月と比較するとどちらも満足度は上がっているものの、こちらはまだまだあげていくことができると感じています。

またFRTについても、エンジニアへの確認や社内確認が必要なお問い合わせへの対応（解決）は、今回の施策を打った後でも、やはりまだまだ時間がかかる傾向にあります。その要因としては、エンジニアさんが調査する際に、細かい追加の確認が発生してしまっていることが挙げられると感じています。
今回ご紹介した既存の施策の実行に止まらず、エンジニアの皆さんがより迅速に調査に取り掛かれるよう配慮した対応フローを整えたりすることで、更なる改善を進めていきたいと考えています。

PLGはセールスが不在だからこそ、誰にどういう体験価値を届けるかの共通認識をもつことや、一貫した体験を実現することが必要になります。特にカスタマーサポートはお客様の声を最前線で吸収する部署だからこそ、エンジニアやプロダクトグループのメンバーにその声を共有し連携を強めながら、コミュニケーション設計や機能改善を行い、より多くの方にご利用いただけるプロダクトにしていきたいと思っています。

そして、formrunのカスタマーサポートは、どのPLGのサービスよりも、「対応スピードが早く、そして質も高い」とユーザーの皆様に言っていただけるよう、これからも頑張っていきたいです。

そんな私たちカスタマーサポートを始め、PLG事業部全体で一緒に働く仲間を絶賛大募集しています！ noteを読んで、少しでも気になった方がいらっしゃいましたら、ぜひ一度採用サイトも覗いてもらえると嬉しいです！

最後まで、お読みいただきありがとうございました。