0 CSオンボーディング改善に おけるCRE的アプローチ CRE Meetup！ユーザー信頼性を支えるエンジニアリング実践例 2025/03/26 株式会社ログラス　開発本部プロダクト開発部CREチーム 子田　周平（こだ　しゅうへい） 

1 ● 名前 ○ 子田　周平（こだ　しゅうへい） ● X ○ @woody_kawagoe ● 経歴 ○ 2018年4月〜2024年1月　株式会社ブレインパッド ■ 広告、Webマーケ支援SaaSの開発・運用・保守 ■ PMO、問い合わせ対応などを担当 ○ 2024年2月〜現在　株式会社ログラス ■ Webアプリエンジニアとして入社 ■ CREに興味を持ち異動 ■ 現在はCSの業務改善に注力 自己紹介 

2 ● プロダクト開発の知見をどうCS業務に活かすのか ● どのように顧客への価値提供を効率化するか ● 事例を元に紹介 今日お話すること 

3 背景 

4 Webアプリエンジニアとして開発をする日々で思っていたこと 自分が作った機能は周り の社内の人から感謝され るものの、本当に価値があ るのだろうか？ せっかく作った機能も使 われてない、なんなら社内 にすら伝わってないことも ありそう 開発だけしても 意味ないんじゃ？ お客様と向き合っている CSがいて初めて価値を提 供をできるのでは？ Kyoto National Museum, CC BY-SA 4.0 , via Wikimedia Commons もっとCSを支援して スケールさせたほうが 良いのでは？ 

5 ● CSは顧客にサービスの価値を伝え、 伴走することで顧客の成功を促進する ● サービスの導入が決まったお客様に対し、 CSはオンボーディングを実施している ● だが複数の顧客を支援するのは時間的に限界がある ● オンボーディングの負荷を仕組みで解決したい CS(カスタマーサクセス)の役割 

6 ● 顧客がサービスを使いこなせるようになるまでの サポートプロセス ● 初期設定や実際の操作を通じて お客様がサービスを習得 ● 全工程に数週間かかる ● オンボーディングがうまくいかない → お客様がサービスを使いこなせない → 解約 オンボーディングとは 

7 ● オンボーディングのゴールが合意できていない 原因）ゴール設定のコミュニケーションの属人化 対策）ゴールの合意形成の標準化 ● オンボーディングのゴールが達成できていない 原因）顧客繁忙などによる進捗の停滞 対策）スケジュールに対するコミットメント強化 →　オンボーディングプロセスをシステム化 オンボーディングの課題と解決する対策の仮説 

8 対応 

9 ● オンボーディング作業の進捗状況の管理 ○ お客様が当事者意識を持ち、スムーズに進捗確認ができる ○ WBSやガントチャートのようなイメージ ● サービスの機能不足、不明点といった課題の状況把握 ○ お客様やログラスで担当者が交代しても、 現在のお客様・ログラスの担当者が過去の経緯を参照できる オンボーディング関連のタスク管理を行う外部システムの導入 

10 ● Loglassにログインしたらそのまま外部システムにSSOでログインできるのか ● 提供された機能で運用に耐えられるのか ○ お客様・ログラス側の作業負担が重くないか ● セキュリティリスクがないか 技術検証をCREが担当 

11 ● 毎朝ビジネスサイドと話す 時間を設ける ○ 進捗共有や相談 ○ リスクになりそうなところを 早く話す ● 毎週ふりかえりを実施 ○ プロジェクトの進め方に 問題なかったか見直す ○ うまく進んだところは お互いに褒め称える 「プロセスやツールよりも個人と対話を」 

12 ● 業務フローやデータ連携の 認識がずれてないか 図解してすり合わせる ● 外部システムを 提供しているベンダーにも 図を見せつつ相談 図解して認識のズレをなくす 

13 ● Loglassと外部システムでユーザの整合性をとる必要がある ○ Loglassで先にユーザを作成した場合、ユーザ連携作業は必要なのか？ ○ 外部システム側で先にユーザを作成した場合、後からユーザ連携できるのか？ ○ Loglassでメールアドレスを変更したら外部システムではどうなるのか？ ○ 外部システムでユーザ削除したらどうなるのか？ ● 場合によってはログインができなくなってしまう ● システムによって仕様も異なるので、それぞれ調査する必要がある ● 当然Loglass側のシステム仕様も把握しておかないといけない 特に認証・ユーザ管理周りは複雑でリスクも大きい 

14 ● 様々なアウトプットについて壁打ち ○ ベンダーへの問い合わせ内容 ○ SSOの設定手順 ○ サービス間連携用のスクリプト ○ テスト設計 ● 使い方 ○ 完璧なものが出てくるわけではなく、そのまま使えるものではない ○ 出力されたものを叩き台として修正していく ○ 立ち上がりが速く作業を進められている 技術検証では生成AIも活用 

15 結果 

16 ● 仕様を考慮して 業務フローを整理した結果、 ユーザ追加・移行時に 各ユーザの作業が必要と判明 ● お客様側の作業負担が重い ため断念 ● 一ヶ月の調査でお見送りの 意思決定できたことは 迅速な判断として評価 当初想定していたシステムはお見送り…… 

17 ● 別のシステムを調査 ● 検証結果 ○ 柔軟に設定ができ、おおむね要件を満たせることがわかった ○ 初期運用は特に問題なく、今後改善されると判断 ○ 第一候補の検証内容を元にスムーズに調査が進行 ● 導入はこれから 次に調査したシステムを採用決定！ 

18 まとめ 

19 ● 現状と今後 ○ 進捗管理の可視化はまだ導入段階 ○ 導入後は顧客の不安を減らし、CSの負担軽減が期待できる ● 学び ○ 「プロセスやツールよりも個人と対話を」 ○ 生成AIとの壁打ちにより素早く解決策を導出できた ○ CREは単なる技術支援ではなく、 顧客の成功を支えるためにプロダクトと顧客の間の橋渡しをする 外部システムの技術検証も、プロダクト開発の知見を活かせた 

20