入社から9年。「優しさ」に頼っていた問い合わせ対応を、「チーム」で解決率90%の組織に変えるまで

1. はじめに

こんにちは。スパイダープラスのCRE（Customer Reliability Engineering）部のくっきーです。
私が入社してから、早いもので9年が経ちました。今でこそ「CRE部」という専門組織があり、弊社のサポート対応は社外からも高い評価をいただいていますが、ここまでの道のりは平坦ではありませんでした。
入社当時の混沌とした状況から、どのようにして「チームで解決する組織」へと脱皮してきたのか。私自身の目線で振り返ってみたいと思います。

2. 「誰がやるべきか」が決まっていなかったあの頃

9年前、お客様から寄せられる「製品の挙動に関する問い合わせ」の対応は「開発業務の一環」ではあったものの、実態は開発メンバーの「優しさ」によって辛うじて回っている状態でした。
当時抱えていた課題は、大きく2つあります。

課題1：後回しにされる問い合わせ

「誰がやるべき仕事か」が明確に定義されていなかったため、どうしても自分たちのメインである開発業務が優先され、問い合わせ対応は後回しになりがちでした。
悪気があるわけではなく、みんな忙しい中で「手の空いた人が善意で拾う」という運用だったため、結果として何日も返信ができない状態が続いていました。

課題2：伝わらない「エンジニアの言葉」

開発から回答が戻ってきたとしても、どうしても意識が内部構造に向き、受け手である顧客がどう感じるかまで気が回らないのが実情で、CS（カスタマーサクセス）担当者はそれを顧客向けに翻訳できず困惑。
両者間のコミュニケーションが文章だけでは上手くいかず社内の空気もどこかギスギスしていました。

このままではいけない。

そう感じてサポート担当者と打ち合わせを繰り返し、問い合わせ時に聞くべき情報のリスト化や返信期限のルール決めなど、できることから着手していきました。

こうした現場での試行錯誤を経て、会社としても「顧客の信頼を守るための専門組織が必要だ」という判断に至り、現在のCRE部の立ち上げへと繋がっていきました。

3. 「お客様への翻訳」を文化にする

立ち上げ当初、私が特にこだわったのは「お客様に説明できる言葉で返す」という定義です。
「ロジックがこうなっているから不具合です」ではなく、「〇〇の動作をしたときに不具合が発生し、データが更新されなかったため今の挙動になっています。このような手順で回避できます」と、「挙動と回避策をセット」で伝える。

これを徹底するために、CSからのフィードバック・夕会での意見交換などでブラッシュアップを続け、お客様に伝わる書き方のナレッジを一つずつ積み上げていきました。

4. チーム全員で勝ち取った「チーム内解決率90%」

ここまでは立ち上げ期の話が中心でしたが、今のCRE部の本当の強みは、メンバー全員が「仕組み化」にコミットしている点にあります。

当初はチームだけではナレッジが足りず、結局開発チームの手を借りて、彼らのリソースを圧迫してしまうという壁にぶつかりました。
そこから「自分たちで解決できる仕組みを作ろう」とチーム一丸となって動いた結果、現在のチーム内解決率90%という数字に繋がっています。

具体的には、以下のような「現場を楽にする工夫」をチームで生み出してきました。

定型作業の自動化：弊社のCREは、本番環境の設定変更やデータメンテナンスも一部担っています。
以前はテンプレートを元にした手動の書き換え作業が中心でしたが、これらをスクリプト化したことで、安全かつ迅速な対応が可能になりました。
結果としてミスを防ぐだけでなく、大幅なリソース削減にも繋がっています。
AIによるナレッジ活用：サポートからエスカレーションが来た際、GitHub Issueを自動作成し、そこにAIが過去の類似事例を調査してIssueに追記する仕組みを導入。調査時間を大幅に短縮しています。
部門を横断した仕組み・フローの構築：バッチやGASを用いて、事前にサーバーの状態をキャッチし、トラブルが起きる前に必要部署と連携できる仕組みを整えました。

こうした煩わしい運用フローに対しても、AIやプログラミングの知識を活かして自動化を推進しています。
業務上の「不便」をエンジニアリングで解決する動きを加速させています。(具体例などはこれからもメンバーが記事にしていくと思うので乞うご期待！)