Rails Tutorialで詰まったこと（第3章 ほぼ静的なページの作成）

本記事の目的

• 本格的なプログラム言語学習を独学するに辺り、自分が躓いた場所を逐一残していおくことで他の独学者の皆さんの役に立つことを狙って
• 自身の忘備録として

第3章ほぼ静的なページの作成

この章では、1〜2章で作成した簡易アプリケーションに静的ページを追加し、それをRailsでルーティングする等、Rails内で静的ページをどのように作成・保持するのかを主に学びました。 また、そこに多少の動的要素（テンプレートエンジンの使い方等）とテスト（TDD）の方法やそれを可能にするRailsの機能についても触れています。

問題1. あれ？このGitHubリポジトリPrivateにしたっけ問題

• 原因 : UI上の選択をしっかりかんがえないままボタンをポチポチするだけで作業をすすめていたこと

• 対策 : リポジトリのSettings > General > Danger Zoneを確認

  • Danger zoneのメッセージが「This repository is Currentry Private.」ならPrivate

  • ちなみにPublic repositoryなら「This repository is Currentry Public.」となる

【結論】
自分が作ったリポジトリがPrivateかPublicか迷ったら、リポジトリのSettings > General > Danger Zoneをすぐ確認すること！
PrivateのつもりがPublicに全情報を公開という惨事は避けましょう！

問題2. Herokuにアプリをデプロイできない

• 原因 : railsとbootstrapのバージョンがテキスト通りだとデプロイできない

  • 試したこと① : teratailでの質問
  • 試したこと② : Twitterで愚痴る

• Gemfile上のrailsとbootsnapバージョンを上げる

  • 解決の経緯
    • 私の愚痴を見たYassLab（Rails Tutorialの運営会社）の安川さんに伝わったようで、週末にも関わらずデバック頂き、再現することが判明。

      こちらの件、RailsとBootsnapのバージョンをそれぞれ更新することでHerokuでも動くことを確認しました！ https://t.co/yEOsQCJEil
      
      テキストの方も後ほど更新しますが、ひとまず下記gemをそれぞれ次のように更新することでデプロイできるか試してみていただけると幸いです 🙏✨#Railsチュートリアル pic.twitter.com/umIWdE0YQR

      — 安川要平/Yohei Yasukawa (@yasulab) 2022年2月26日

【結論】
今回は不運にもテキスト通りに進まない箇所がありました。一方で解決するためにTeratailで質問したりTwitterで発信することで、公式に状況が届き、解決に至ったのは非常に有り難かったです。

Twitter上での感謝を伝えていますが、この場においてもご対応頂いたYassLabの安川さんには改めて御礼申し上げます。

Rails Tutorialで詰まったこと（第2章 Toyアプリケーション）

本記事の目的

• 本格的なプログラム言語学習を独学するに辺り、自分が躓いた場所を逐一残していおくことで他の独学者の皆さんの役に立つことを狙って
• 自身の忘備録として

第2章 Toyアプリケーション

この章では前回作成した簡易アプリケーションに多少機能を追加したものを改めて作成し、Gitへ載せる→GitHubのリポジトリ登録→Herokuへのデプロイという流れを復習するものでした。
その中で、本章では特にDBの生成コマンドである(scaffold)やMVCというアーキテクチャにふれることで段々と内容が濃くなって来ました。

問題1. GitHubの個人アクセストークンがわからなくなってGitHubにコードを上げられなくなる

• 原因 : GitHubの個人アクセストークンは生成時にしか表示されないことを読み飛ばしていた
• 対策 : 再度個人アクセストークンを生成し、そちらは保存しておく

【結論】
説明はちゃんと読みましょう！

問題2. コマンドで生成するDBのカラム設定を間違えた

• 原因 : テキストをコピーせず打ち込んだため発生したミス
• 対策 : ソースは一度全消しの上、GitHub上の保存地点まで巻き戻し

上記の対策を思いつくにあたっては、以下の記事が参考になりました。 Gitの操作自体にまだまだなれていないため、トラブった時に冷静に処理できるようになりたいところです。

qiita.com

【結論】
コマンドは手打ちにせず、はじめはコピーすること。
手打ちでコマンドを覚えることも必要だが、間違える場所によっては影響が大きいのではじめはコピー&ペーストでOK。
その代わり、テキストでの説明をしっかり読むこと。

3. rails generate scaffoldコマンドが動かない（ハングアップする）

• 原因 : どうやらspringというプログラム関連で止まっているとエラーが出た
• 対策 : springなるプログラムを一度停止の上、同コマンドを再実施

この問題は同じエラーメッセージで苦しまれていた方の以下のブログ記事を参考に対策を実施、成功しました。ありがとうございます。
qiita.com

【結論】
エラーメッセージに解決のヒントはある。

Rails Tutorialで詰まったこと（第1章 ゼロからデプロイまで）

本記事の目的

• 本格的なプログラム言語学習を独学するに辺り、自分が躓いた場所を逐一残していおくことで他の独学者の皆さんの役に立つことを狙って
• 自身の忘備録として

第1章 ゼロからデプロイまで

この章ではRuby on Railsでの簡易アプリケーションを作成し、それをGitに載せ、自身のGitHubのリポジトリに登録し、最終的にはHerokuのサーバにデプロイする方法までを一貫して学びました。

問題1. Cloud9にrailsで作成したサイトへPreviewアクセスできない

• 原因：説明文をちゃんと読んでいない
• 対策：テキストの通り明示的にホワイトリストをクリアした後、別タブでlocalhost:3000にアクセスする

恥ずかしながら、上記の問題を解決策に気がつくまでに「RubyとCloud9の知識不足」を疑いUdemyの以下の講義¹をずっと学習していました。（約10時間程度）

www.udemy.com

結果としては、Rubyの構文やRailsの知識が深まったため問題ありませんでしたが、とても長い遠回りになりました。

【結論】 他の方にはサクッと目的のRails Tutorialを進めて頂きたいため、説明テキストはよく読むことをオススメ致します。

問題2. コマンドラインから自身のGitHub, Herokuアカウントにログインできない

• 原因①:GitHubではPassword入力時に個人アクセストークンの入力が必須（2021年8月²より）
• 原因②:HerokuにMFA（多要素認証）を設定しているため、Passwordログインができなくなっていた
• 対策:どちらのアカウントでもtokenを発行し、password欄にtokenを入力してログイン

この時に参考にしたドキュメントは下記となります。

• 個人アクセストークンを使用する（GitHub Docs）
• Herokuにtokenでログインする方法（株式会社Orfoolブログ）

【結論】 GitHubやHerokuからPasswordの入力を求められても、token入力の場合があるのでエラーメッセージをよく読んで調べ、対応すること。 大切なことはエラーメッセージに書いてあります。

---

1. このコースはCloud9というIDEでRubyの基礎からRailsでのアプリケーション作成までをコツコツと学ぶものです。延々と写経（素振り）しながら学ぶタイプの硬派なもので、個人的には辛いけど楽しかったです。↩

2. GitHub公式によるPassword認証廃止アナウンス↩

イベントレポート「SaaS CS集中講座（3）リニューアルマネジメントとエクスパンション」

参加の背景

• カスタマーサクセスへジョブチェンジをしたが、そもそもSaasという業態やカスタマーサクセスへの理解が不足しているため
• それを埋めるための勉強として参加
• CSMサポート・テックタッチ領域担当としてエクスパンション支援を行うことが決まったが、そもそもエクスパンションとはどのような状況で発生するのかをしるため
• エクスパンション発生のために自分自身が何を出来るのかを考えるきっかけを得るため

イベント情報

• イベントページ

セッション内容サマリー

セッション内容：
（１）リニューアルマネジメントの意義とやるべきことの再確認
（２）ROIの考え方と算出方法
（３）CS的なエクスパンション戦略を立てよう
（４）CSM一人あたりの保有MRRと適正なエクスパンション目標とは？

☝️内容サマリー
▶︎CSM、CSMマネジャーにおすすめ！
▶︎チャーン削減の要であるリニューアルマネジメントと、それを成立させるために重要なROIロジックについても説明します。加えて、CSとしてのエクスパンションへの向き合い方と、妥当な目標設定についても考察します

（１）リニューアルマネジメントの意義とやるべきことの再確認

• リニューアルマネジメントを行う意義
  • リニューアル＝契約更新
  • リニューアルマネジメントをやる意義は「自社の利益を最大化させる」様々なアクションを引き起こせる機会
  • 山田さんの中では「2番め」に重要な施策（1番はオンボーディング）
    • 理由：解約が減らせる
  • 組織にゆとりがなければ自動更新のままでもよいが、チャーン抑止をしたければリニューアルマネジメントを行うと良い
• 導入目的の達成に時間がかかることがあるので、顧客に目的意識を持ってもらうことでサクセス推進することが可能→サクセスロードマップ大事
  • Sansanでは、プロダクトの利用状況を知らせる、期待値すり合わせを行う
  • ROIでの確認（後述）
  • 顧客体制の再確認・再構築
    • 1年立つと体制が変わる、管理者不明はザラなのでマネジメント必須
    • 体制を崩れないようにする、崩れているのを見つけて戻す必要がある
      • 引き継ぎ用のガイドブックをSansanでは作っていた
  • 決済ラインの把握と関係構築
    • これも時間が立つと変化するので、顧客の社内パワーバランス/構造を確認・調整する（特にエンプラ）
  • 更新意思の確認
    • 当たり前だが一番大事！
  • VoCの収集
    • 自社プロダクトの成長のため、継続的な収集の仕組みを作る
    • リニューアル時は偉い人からの声も集められるいい機会（活かし方は第5回で詳細を！）
  • エクスパンション機会の探索（後述）
  • リニューアルスケジュール例
    • 更新前3ヶ月前から10営業日以内に実施
      • 1.顧客社内のパワーストラクチャ及びプロダクト推進・管理体制の把握
      • 2.利用状況の提示と振り返り
      • 3.プロダクト・CS支援に関する顧客不満のPickup
      • 4.更新可否の確認
      • 5.アップ/クロスセル提案
  • チャーン阻止活動（目玉）
    • 予防：より長く・深く利用してもらう
    • 対処：解約を思いとどまってもらう
      • 阻止活動のフェーズ分け
      • 
      • 
      • 
      • 
      • 

        （２）ROIの考え方と算出方法

• Gainsightが提唱するヘルススコアの1つがROI
  • ROIは顧客がサクセスしているかどうかを表す
• ROIの特定手順
  • 顧客から帰ってくる場合→それをROIにする
  • 顧客から帰ってこない場合→ROIになりそうな数値を明確化して提案
    • シナリオパターン（ASSFの山田さんBlogより）
      • 1.サクセスシナリオの明確化
      • 2.事業貢献数値を特定する‍
        • コスト減or売上げ増
      • 3.ロジックとファクトの考案
        • 直接「事業貢献数値」につながらなくても、どのようにつながっているのかを考えて提唱する
        • このロジックとファクトを出せるのはカスタマーサクセスだけ！
        • 
        • 
        • お客さんと話す中でROIの要素が出てくることがある

          （３）CS的なエクスパンション戦略を立てよう

• エクスパンションの3要素
  • 
  • 1.アップセル
    • 顧客のサクセス前提
      • 理論的に上限がある（お客さんの社員数が上限になる）
      • 時間がかかる
  • 2.クロスセル
    • プロダクト戦略が必要
  • 3.従量課金
    • これを持てると強い
      • 理論上無限に上がるので上限なし
• CSQL戦略
  • CSQLに関する山田さんの過去note
  • 
  • 複数プロダクトを持っているとオンボーディング中にクロスセルの機会を発掘することが可能！
    • オンボーディング中の製品以外の別の課題を見つけることができれば可能
  • セミナー最後にアンケートを行って、クロスセル商材を紹介
  • プロダクトのログイン画面に支援メディアに飛ばしてコンバージョンポイントを作る

    （４）CSM一人あたりの保有MRRと適正なエクスパンション目標とは？

• CSM1人あたりのARR適正
  • 前提
    • 担当社数
    • 
    • 
• ARR
  • 
  • 
• ARR算出方法
  • オンボーディングが1番大事なので、オンボーディングに裂ける人数を基準に他の人員割り振りを考える！
  • 
  • 

質疑

• Q.リニューアル阻止活動のためのグラデーションを決める基準は？

  • A.大切なお客さんから行う
    • 大切なお客さん
      • 1.MRRが高いお客さん
      • 2.PMF（プロダクトマーケットフィット）しているお客さん
        • 自社内でPMF基準があればそれに準じる
        • 長く使ってもらえるお客さんはPMFしていることが多いので、PMFが重要

• Q.VoCを集める活動とは？コロナ化で行う

  • A.リニューアルマネジメントを行えば大丈夫！
    • 定期的な顧客接点を持つこと！
    • 時期性なイベントを作って行うことでVoCは集めやすい。

• Q.テックタッチとしてハイタッチのサポートにできることは？

• A.プロダクト経由で行うのが良い
  • お客さんの日々の状況に合わせてエキスパンションを行う
    • プロダクトに支援サイト出す
    • リニューアル時期にメールを行う
    • ヘルススコアを見ながら、良い会社にエキスパンション強めのメールを送る

イベントレポート「SaaS CS集中講座（2）CSMの基本マインドとオンボーディング編」

参加の背景

• カスタマーサクセスへジョブチェンジをしたが、そもそもSaasという業態やカスタマーサクセスへの理解が不足しているため
• それを埋めるための勉強として参加
• CSMが行う製品・サービスオンボーディングで何が行なわれているのかを知ることで担当するCSMサポートやテックタッチ領域での業務範囲を理解シたかったため

イベント情報

• イベントページ

セッション内容サマリー

（１）CSMにとって重要なマインドとは？
（２）もう一度オンボーディングの意義を考え直そう
（３）オンボーディングプロセスのデザインで意識すべきこと
（４）オンボーディングにどの程度のリソースをかけるべきか？
☝️内容サマリー

▶︎CSM、CSMマネジャーにおすすめ！
▶︎CSの基本ユニットであるCSMを受講対象として、持つべきマインドセットを説明し、CS活動の基礎と言われるオンボーディングについて徹底解説します。

（１）CSMにとって重要なマインドとは？

• CSの基本マインド
  • カスタマーサクセスと顧客満足（カスタマーサティスファクション）の違いは？
    • 主語の違い
      • カスタマーサクセスの主語は「自分」と「顧客」
        • 顧客も自分（CS）も「良し」
      • カスタマーサティスファクションの主語は「自分」
        • お客さんにリピートさせたい
    • カスタマーサクセスには「お母さん感」（子どもを思う親の気持ちに近い感情）が大事
    • 顧客とカスタマーサクセスの立場の違いを突破するのが「お母さん感」
      • 
      • 優秀なCSMはお客さんの言っていることを傾聴しながら、御用聞きはしない
      • 「顧客満足」にとどまらず、「将来どうなる」まで考えて行動する
• 顧客ライフサイクル
  • オンボーディング期
  • サクセス期
• サクセスまでの道のりとタイプ別戦略
  • サクセスまでの道のり
    • 環境を構築する(Onborading)
    • 現場の「習慣」が変わる（Behavioral Success）
      • 1~3年かかる
    • 現場の「業務」が変わる (Operational Success)
  • サクセスタイプ
    • ライトサクセス
      • 業務課題の解決
      • 現場の満足
      • 3ヶ月〜6ヶ月で達成できるが、2年ほどでチャーンされるリスクがある
    • ディープサクセス
      • 経営課題の解決
      • 経営層の満足
      • 1年以上かかり成功すると大きいが、そこまで現場が疲れてしまう
• ※資料のキャプチャを貼る Aタイプ：運用命（後期段階でCSのサポート必須） 　　　　　極めれば業務に深く結びつく Bタイプ：初期段階でCSのサポートが必須 Cタイプ：ライト・ディープ両方のサクセスが取れるように機能開発 Dタイプ：基本Cタイプ同様

  （２）もう一度オンボーディングの意義を考え直そう

• オンボーディングの結果は後のヘルススコアに影響を与えるか
  • かなりの影響がある
  • 約２倍のヘルススコアの開きあり
  • チャーン案件の研究
    • 継続年数が上がると継続・チャーンともにヘルススコアは上昇
    • チャーン案件では全体のヘルススコアが低い
    • チャーン因子となるヘルススコアを持ち、それが最大化（顧客の限界を超える）するとチャーンに繋がる
    • オンボーディングの結果は3〜4年後に結果が出る

（３）オンボーディングプロセスのデザインで意識すべきこと

• オンボーディングでやることを決めてステップ化
  • 進捗しやすい単位に区切って、個別に進捗を管理
  • ここを人に依存させない（全社的に型を作る）
• 顧客側の体制構築
  • 
  • 推進者と運用担当者は分ける！
  • 運用者は時間のある人にお願いする（でないとオンボーディングが終わらない）
  • 体制ごとのロールを明確にすることで適切なアサインを促す

    （４）オンボーディングにどの程度のリソースをかけるべきか？

• オンボーディングに掛ける人的リソース
  • 
• SanSanで実証した結論
  • テックタッチで最大約3割は立ち上がる（オンボーディングの成功にたどり着く）
  • 
  • 1.最短導入マップ
    • オンボーディング全行程をWebサイトで共有
  • 2.ステップメール
    • オンボーディングステップを定期的にメールで共有
    • 導入マップや動画をメールに乗せて共有
  • 3.Call To Action(CTA)
    • プロダクトと顧客のデータからアラートをCSMに飛ばす
    • そのアラートを確認してCSMがサポートに入る
• 成功ポイント
  • お客さんに成功の型をインプット
  • 利用状況に合わせて適切なタイミングでステップメール化出来た
  • 苦労したこと
    • 導入前に「成功の型をお客さんと握る」かどうかが成功の可否を左右する
• 山田さんの所感
  • オンボーディング自動化は最大で3割にできる
  • 3割の自動化をゴールに目指せばよいのでは

質疑

• 顧客の立場からしたら、CSからのしつこいアプローチに対して、うんざりしてしまい、そもそも連絡のやり取りができなくなるリスクも有るかと思いますが、どのような判断軸で行動をしていく必要がありますか？
  • 「お客さんにしつこく連絡したせいで連絡が取れなくなった」を定義、各案件が該当するかどうかを管理（数をカウント）。
    • SanSanではそういう案件にしてしまったCSMの責任としていた。
    • 「お母さん感」が足りない、押し付けたCSMが信頼を損ねていると理解して、コミュニケーションのとり方を分解。
    • 数を数えることで上手く出来ている、出来ていないが把握できる

イベントレポート「SaaS CS集中講座（1）CS組織化のポイントとKPI設計編」

参加の背景

• カスタマーサクセスへジョブチェンジをしたが、そもそもSaasという業態やカスタマーサクセスへの理解が不足しているため
• それを埋めるための勉強として参加

イベント情報

• イベントページ

企画背景

• カスタマーサクセスに携わる人に実践的Tipsや体系的な知識を身につける機会を

セッション内容サマリー

（１）SaaS CSの組織構成について考える （２）組織・個人KPIと評価基準の決め方 （３）人の増やし方と組織拡大のタイミング

• 内容サマリー
  • COOや事業責任者、CSマネジャーにおすすめ！
  • カスタマーサクセスを事業上どのように位置づけ、組織の成長戦略を構築していけばよいかについて考えます。

受講の注意点

• ①本講座ではカスタマーサクセスの「型」を説明
  • 「型」学習のメリット
    • 学習コストの短縮
    • 失敗の回避
    • 自身流の応用・派生・否定を生み出すことにつながる
• ②当時の山田さんのベストプラクティスを紹介
  • 時間経過で適切でなくなることがある
  • 自分の事業にフィットしているかを考えて欲しい
  • 紹介内容を実践するのに時間がかかる覚悟をしてほしい

「SaaS事業の鉄則」のおさらい

• SaaSの金言「解約率は成長の上限を決める」（ユーザベース佐久間氏）
  • 解約率が高いと成長できない
    • 解約率10％を切っていると10年〜30年の間に連続的に成長可能
• 事業投資のタイミング
  • 年間解約率10%以下を達成し成長基盤を整える→その後マーケティング費用を投下して成長加速させる
• LTV
  • LTV = 売上 / 解約率
  • LTVを上げるには「売上」と「解約率」の2つの指標が大事
  • ここでカスタマーサクセスの出番

    CSの事業貢献

• カスタマーサクセスの雄「Gainsigt」（米国）
  • 青本の作者の1人はGainsigtの社員
• Customer Sucess Matyrity Level
  • CS組織の成長が会社のGRR・NRRの数値が高くなる（=会社の成長）
    • Reactive
      • 要求を受けて活動する
    • Insigts&Actions(ほとんどの会社はこの辺り)
      • 収集した顧客データから先回り
    • Outcomes(このレベルの会社は国内外でも少ない)
      • 顧客がアウトカムを出している
    • Transform
      • 顧客を完全にコントロール

• Customer Success Element

• Q&A

  • CSの成熟度のレベルは、CSのワークロードにも関係していて、CS一人当たりの受け持ちが多くなると、reactiveな活動しかできないのが常だと思います。一人当たりの適切な担当者数/担当売上数などは、どうやって定めるべきでしょうか？

    • 第3回の講義でお話します。
    • 顧客の月次辺りの流入数から導き出したほうが良いかと。
    • Maturity Levelが上がるとCSの支援組織ができるために、CSが持てる顧客数が減る。

  • Q.山田さんの知る限りで、CSが”Transformation”のフェーズを実現している会社があれば教えてください。

    • 個人的な感想としては、Google workspaceのチャーンレートが低いかなと。（Transformかどうかは分からない）
    • MSとGoogleのようなグループウェアはチャーンレート低い。
    • バーティカルSaaSもお客さんと密結合に成りやすいため、行きやすいと思います・

（１）SaaS CSの組織構成について考える

• CS部門の位置づけ
  • 営業近接型
    • 営業から引き継ぐ（CSと営業が密）
    • PMF判断
  • プロダクト近接型
    • プロダクトサイドに近い
    • PMMの権限
    • 機能追加の優先順位

• B2B SaaSの事業フェーズの例

• 創業期

  • カスタマーサクセスも一緒に7人8脚で成果にこだわる組織を作る
• 成長期
  • 個別対応を行うハイタッチCSM（点）
  • チーム対応を行うロー・テックタッチCSM組織（面）
• 拡大期
  • 契約・規模別に合わせたCSM組織、CSMを支えるテクノロジー活用組織を作る

（２）組織・個人KPIと評価基準の決め方

• Churn Rateの問題

  • 定義曖昧である
  • 月次解約率はARRで10％以下（/12でMRR）

• 最近のCSKGIのトレンド

  • NDR（Net Dollar Retrantion）
  • Q. SaaSビジネスで最強のSales Efficiencyを得る方法とは？
  • 全てのNet Dollar Retentionが同じように作られるわけではない
  • CSの成果にExpantionが含まれていればNDRを利用すれば良い

• 目標の立て方

  • （月次更新解約率から割り出した）更新金額, 月次追加受注額（平均成績から算出） + 月次新規受注額
    • 更新金額：季節要因＞人的要因
      • 時期が重要
    • 追加、新規受注額：（季節要因＜人的要因）*プロダクト数
      • 人やプロダクトが増えれば増えやすい

• CS KPIの考え方

  • 契約継続するための背骨となるロジックを作る（以下黒枠）
  • そのそれぞれのロジックにKPIを紐付ける

• チャーン/エクスパンションはヘルススコアと連動＠Sansan

  • ヘルススコアが悪いとチャーンしやすい（50％）
  • ヘルススコアが良いとエクスパンションしやすい（70％）
  • オンボーディングの成否で1年後のヘルススコアが2倍の差
    • ヘルススコアを上げるにはオンボーディングの成功が必須

• ロジックを持てない場合

  • 施策や数値が連動する前提でKPIを絞り込み、えいやで決めても良い
  • 振り返りを行う前提で決定する

• Q&A

  • Q.ヘルススコアのデータ分析ができるようになったのはいつ頃ですか？
    • 最近です。きちんとデータをとって動くことを意識した組織にならないと中々できない

      （３）人の増やし方と組織拡大のタイミング

• 山田さんの見立て
  • SIのコンサルタントに多い
  • SIのプロマネ（ただし顧客牽引型）がおすすめ
• 青本の作者の見立て
  • 自社の事業領域の専門知識
    • 製品以外に関しても顧客と深い会話が可能
  • 製品の専門知識
    • ユーザ視点で会話可能
  • 顧客対応スキル

• ワークサンプルテスト

  • CSのKickoffをロープレ
  • 実際にCSの面接でロープレすることで企業・候補者ともに満足度が高くなった

• CSのキャリアプランをもたらすJob title@Sansan CS

  • CSMへのキャリアアップ意識を持たす
  • 扱える案件によってJob titleが決まっている
    • トレーニー
    • アソシエイト
    • マネージャー
    • シニア
    • 外部の営業コンサルのロープレ試験をクリアする

• CSへの教育（OJTは1on1で実施）

  • 座学
    • SalesforceのTrailheadを活用
  • 筆記試験
  • ロープレ試験

質疑応答

• 1. BtoBに限った話かと思いますが、サービスが成長する中で、パートナー戦略は重要視される事が多いかと思います。そのような自社ではない第三者による販売が増えた場合、CSの力を発揮しにくい場面があるかと思いますが、CSとしてパートナーとの向き合い方（パートナーサクセスの考え方）として参考になる事があればお教え下さい！
  2. 第3回に回答を入れておきます。即答は難しいです。
• 1. プロダクト採用者の移動で再オンボーディングが発生する場合どうするか？
  2. 第2回で話をします。プロダクト特性によった話は次回。

次回予告

CSカレッジ - コミュニティタッチサミット2021 イベントレポート

概要

会社でテックタッチ・コミュニティタッチ方面を伸ばしたいという話が上がっていたので、 そもそも他社でどんな風にコミュニティタッチが進められているのかを知るために参加。
https://connpass.com/event/218481/
基調講演1名+事例発表7社の講演・発表が行われた。

Twitterのハッシュタグ：#CSカレッジ

当日の参加者によるツイートまとめ

togetter

開始前雑談

• コミュニティタッチの成果は？
  • マネフォさんは会社独自のKPIでは成果が出ている
  • オンリーストーリーさんはLTV上がって、ユーザから「コミュニティがないと困る」という声
• コミュニティ開始/立ち上げへの不安は？
  • N数（母数）をトライアンドエラーで増やしていくしかない(オンリーストーリー吉田さん)
  • Box山口さんはコミュニティ立ち上げ期知らないので伝聞。少人数のお客さんへの声を掛けから小さく始めたらしい。

基調講演

カスタマーサクセスを「強化」「拡張」「進化」させる、コミュニティの効果

発表者

• 小島 英揮様
  • Still Day One合同会社 代表社員 / パラレルマーケター
  • コミュニティづくりの実績から執筆講演
    • AWSでJAWS-UG(AWSユーザコミュニティ)を作った
    • 本業のマーケティング文脈でなく、カスタマーサクセス文脈でコミュニティについて話す

      内容

• カスタマーサクセスにコミュニティタッチを入れない理由がない
  • コミュニティタッチをカスタマーサクセス文脈で作られた資料
  • 従来のハイタッチ/ロータッチ/テックタッチに追加で「第4の施策」としてお客さんとつながる
    • これまでのジレンマをコミュニティで改善・補完する
• コミュニティとは？
  • 特定のテーマ・トピック・ビジョンで人が集まり、賛同する人たち
  • ポイント
    • コミュニティを通じて認知を拡げる
    • 口コミで製品・サービスを知ってもらう
• コミュニティで付加される3つの効能
  • 拡張：プレオンボーディングの実現
    • 製品導入前に正しい期待値設定や用途・運用理解が一定レベルになる（期待値や用途理解のズレによるトラブル回避）
    • コンバージョンやチャーンの改善、LTVの向上
  • 強化：ユースケースの共有
    • コミュニティが広がると、ユーザから発信されるようになり、課題から「逆引き的」にどの機能を使えばよいかユーザが理解できる
    • 課題が解決しやすくなり、LTVが向上
  • 進化：製品へのフィードバックループの構築
    • 従来の一方向から、双方向のコミュニケーションになり、足りない機能・求められている機能・想定通りに使われないもの改善に必要な情報が集まる
    • フィードバックループが構築でき、サービスの進化が早くなり、LTVが向上する
• 適切なコミュニティを作るポイント
  • コンテキスト：コミュニティの明確な目的を用意する
  • トラスト　　：信頼できる関係を作る
  • アウトプット：参加してくれたお客様が自ら発信してくれる環境を作る（アウトプットを促す、流通する仕組みを作る）
• 詳しくは小島さんの本より

事例発表講演

1.日本IBM流コミュニティタッチ2.0 ～"未来×テクノロジー"を学び、創り、繋がる場の設計と運用の全て～

発表者

• 戸倉 彩様
  • 日本アイ・ビー・エム株式会社
  • Developer Relations（開発者向けテックタッチ/コミュニティタッチ）を実施している

    内容

• ゴール
  • IBMのテックタッチ事例から、日本におけるコミュニティ文化について考える切っ掛けになってほしい
• DevRel:Developper Relations
  • 3C
    • code:ソースコードや技術情報の提供
    • contents:接点となるコンテンツ発信
    • comminity:技術者コミュニティ
  • 開発者と「一緒に」問題を解決するコミュニティ
    • これまで、ユーザ会としては約60年活動していたが終了。2020年にコミュニティを再構築。
    • IBM Community Japan
    • キーワード
      • マナブ：一人でも始めやすい「マナブ」。未来を変える場所への原動力としての「マナブ」場
      • ツクル：アイデアを多くの仲間と専門家で切磋琢磨し、カタチにしていく「ツクル」場
      • ツナガル：IBM Community Japanのメンバー同士がデジタルに「ツナガル」、あるいは成果物そのものを融合させる「ツナガル」、あるいは成果発表の場でFace to Faceに「ツナガル」場
• IBM Customer Success
  • お客様を成功に導く
    • 能動的にお客様に働きかける
    • 中期的にお客様に寄り添って活動する
    • お客様のビジネスの成功/ゴールを理解する
    • IBM製品の価値を最大限にご活用頂く
    • Win-Winを目指す
• CSにおけるコミュニティタッチ
  • CS(Customer Success) = CX(Customer Experience/体験) + CO(Customer Outcome/成果)
  • 3C（code/contents/community）
  • Developer Experience→Developer Relations

2.Box Localがユーザー会からコミュニティに昇華する日～2年間の成功と失敗の軌跡を辿る～

発表者

• 山口 文香様
  • 株式会社Box Japan カスタマーサクセス部 アソシエイトカスタマーサクセスマネージャー
  • ロータッチ/テックタッチを担当（メンバーは2名とのこと）
    • その中でコミュニティと関わる

      内容

• 対象
  • ユーザ会を盛り上げたい人
  • ユーザ同士の交流を増やしたい人
• 紹介する施策
  • 管理者のためのユーザ会
    • ユーザが関心の高い内容について四半期に一回、勉強会やパネルディスカッション等を行う（2015年〜）
    • 課題
      • ユーザコミュニティとまではいかず、一方通行（運営主体がCSチームのため）
    • 失敗例
      • 懇親会前に8割帰ってしまった（オンライン/オフライン共に）
    • 成功例
      • 交流会と銘打って、「情報交換会」にしたら7割の参加者がディスカッションに参加してくれた
    • 教訓
      • イベントは、話を聞く・ユーザ同士の課題共有、どちらかにフォーカスしたほうが良い
  • カスターマーアワード
    • 昨年から始めた年1回イベント（500人規模）
      • 管理者・エンドユーザ視点含めたユースケース共有イベント
      • ビジネス課題をBoxでどのように解決したか？を共有
      • ユーザから課題解決事例を集めて表彰・イベントレポート化する
  • 上記2施策は両輪
    • 片方を盛り上げると自然ともう片方も盛り上がっていく
    • ユーザ会でコミュニティの下地を作って、アワードでアウトプットを促進する
• ユーザコミュニティへのNextチャレンジ（決意表明）
  • 未だコミュニティには成りきれていないので下記をやりたい
    • エンドユーザを巻き込みたい
    • オンラインコミュニティ
    • ユーザ主導に

3.コミュニティから始まったスケールするカスタマーサクセスへの挑戦

発表者

• 渡辺 俊平様
  • UiPath株式会社 コミュニティマネージャー
  • 日本ユーザコミュニティ（UiPathFriends）立ち上げ・企画・運営

    内容

• なぜコミュニティに取り組んでいるのか？
  • RPA市場のプレイヤー増加
  • コミュニティを強みに差別化ポイントに
    • コミュニティづくりは簡単にできず、構築に時間がかかるため続かない
    • コミュニティマーケティングとカスタマーサクセスを両輪にしたい
• UiPathの持つコミュニティ
  • グローバル
    • 教育、ジョブボード等
  • 日本（UiPathFriends）
    • 企業・ユーザを含めたミートアップ
  • オンライン
    • フォーラムでユーザ同士で課題解決
• UiPathFriends（日本コミュニティ）
  • ユーザ主体のコミュニティ
    • 現在は地域別コミュニティをオンライン中心で開催
  • 目指している事
    • ユーザがレベルアップして楽しみながら成長できる
      • ユーザがどんどんコミュニティ運営に関わる
      • 社内外でノウハウを共有できる仲間をみつけられる場所に
  • 企画
    • カンファレンス/表彰式/ブログ発信（アドベントカレンダー）
    • 定期もくもく会
  • 参加者が感じるコミュニティのメリット
    • 1人でできないこと、会社でできないことを経験できる
    • 情報発信していたら、結果的に自分が知らない情報が入ってくるようになった
• カスタマーサクセスとコミュニティの連携
  • カスタマーサクセスジャーニーへのコミュニティの組み込み
  • サクセスに至るまでのスピードアップ
  • サクセスユーザの取り組みを拡げる場としてコミュニティ活用

4.ウイングアークユーザーコミュニティ”nest”は今が変革期！？再生期を乗越えて 今描く未来

発表者

• 大野 美枝子様
  • ウイングアーク１ｓｔ株式会社 マーケティング本部 Customer Marketing Group
  • カスタマーマーケティング部門立ち上げ、ユーザコミュニティの運営リーダー担当

    内容

• ユーザコミュニティ”nest”とは？
  • 製品を活用しデータ活用を促進する人・企業のためのユーザコミュニティ
  • 活動
    • ワーキンググループ
    • SNS交流
  • 運営メンバーをユーザコミュニティから募集
• ビジネスの変化とコミュニティの変遷
  • 元々オンプレミス型→クラウド/サブスクリプション型へ変化
    • カスタマーサクセス・ユーザコミュニティを立ち上げ
  • 2020年新型コロナ流行による全面オンライン化に伴い、様々な課題に直面
• 3年目に訪れたコミュニティの負のスパイラル
  • 下記により、コミュニティ存続の危機
    • 新規登録者数が増えない
    • Active率が上がらない
    • 有益な情報共有できない
  • 打開策＆施策＆効果
    • コミュニティの役割の再定義
      • コミュニティ外のイベント登壇、メディア露出強化を行い社内外への認知強化
      • 新規会員 5倍以上/月平均
    • ユーザ会員サイトの最大活用
      • ユーザに価値を継続的に訴求
      • Adovocator(情報発信者)になるユーザが3名に
    • コミュニティインフラの再検討
      • インフラをFacebookからCommuneへ以降することで、Facebookの利用障壁を解消
      • イベント参加者 約3.9倍/回平均
• 今後の取り組み
  • コミュニケーションの活性化
  • コミュニティブランドの確立
  • 具体策
    • バーチャルオフィス活用した常設サロン設置
    • テーマ（業種・課題）別の情報発信

5.SmartHRが、フラッと立ち寄れるユーザーコミュニティ「PARK」を立ち上げるワケ

• 篠原 恵利子様
  • 株式会社SmartHR マーケティンググループ　アドボカシーユニット
  • 会社としてコミュニティに本腰を入れたはこの1年程の模様

    内容

• 2つのコミュニティ
  • ユーザコミュニティ「PARK」
  • PMMコミュニティ「Senseiコミュニティ」
• ユーザコミュニティ「PARK」
  • 「SmartHRユーザが困ったときにフラッと立ち寄れる広場」がコンセプト
  • なぜやるのか？
    • ユーザさんのペインに対して解決策としてのコミュニティ
  • 提供バリュー
    • 学ぶ：活用方法・人事労務の知識を学び、成長につなげる
    • 繋がる：社外の仲間を作り高め合う
    • 育てる：プロダクトフィードバックを通じて、サービスをともに育てる
    • 発信する：自らの学び、トライをコミュニティで発信し、人事労務業界を盛り上げる
  • なにをしているのか
    • イベント中心
      • 年一度の大型イベント
      • 小規模交流会
      • LT形式「突撃！となりの人事労務」
• コミュニティ立ち上げのための準備
  • 2020年
    • 課題を持っている熱意をもっているユーザを探し、声掛け
    • ユーザさんを集めて小規模イベントを実施
  • 2021年
    • コミュニティリーダーを探しつつ、イベント実施
  • 2022年
    • オンラインコミュニティ立ち上げ予定
    • ここは他社の事例から学びたい
• 半年コミュニティを運営した所感
  • 難しい
    • 全社で本気で取り組まないと、（コミュニティ）立ち上げすらできない
  • 全社でカスタマーサクセスに取り組む会社風土と噛み合っている
  • すでに効果が出ていること
    • 先輩ユーザが導入中のユーザに設定を教えている
    • 気になっている機能についてユーザから質問が来た
  • 社内を巻き込むには？
    • エモ（定性）×定量
      • エモ
        • いい話を共有する仕組み
      • 定量
        • NPS（ネットプロモータースコア）との関連性あるのでは、という仮説
  • 関連記事
• SmartHRの製品をもっと使ってもらうために
  • コミュニティの成果を循環させる
    • ユーザがユーザを呼びたくなる仕組みづくり
    • CSで閉じないスケールする仕組み
    • 「心はCS、手法はマーケ」
• これからコミュニティで取り組みたいこと
  • ユーザ同士での課題解決、オンボーディングできる仕組みづくり
  • 活用事例をどう見つけるか？
  • 活用アワード

6.カスタマーサクセスを実現するために、マネフォが「BizBASEコミュニティ」を立ち上げた理由とその方法〜具体的なコミュニティ運営方法も大公開！〜

発表者

• 高垣内 友己様
  • 株式会社マネーフォワード 事業推進本部 カスタマーサクセス横断戦略部 部長 兼 BizBASE PJオーナー
  • コミュニティ責任者
• 山田 裕己様
  • 株式会社マネーフォワード 事業推進本部東日本事業推進部　東北支社長・コミュニティマネージャー
  • コミュニティマネージャー

    内容

• BizBaseとは？
  • 概念。活動
  • 2つのコミュニティが派生
    • ポータル：フォーラム
    • コミュニティ：
• BizBaseコミュニティの立ち上げ
  • 立ち上げ前
    • ハイタッチ中心のCS
    • コロナ環境による顧客の変化
  • 目指した世界
    • オンラインマニュアル
    • サービス学習動画
    • セミナー
    • ユーザ同士が話せる場
  • コミュニティでユーザが課題解決し、そのユーザのビジネスが成功する
• 設計・構築
  • メンバー集めと社内承認取り
    • 企画し、構想と施策をまとめる
    • COOに企画を提案
    • 協力して欲しいメンバーに個別に参加を打診
  • 全体コンセプト設計
    • 社内デザイナーを巻き込む
    • ストーリー・ユーザの体験を考える
    • メンバーと意見を収集し、コミュニティ名とコンセプトを設計
  • オンラインコミュニティ（ポータル）の構築
    • 必要コンテンツの洗い出しとサイト構造の設計
    • コミュニティサイトを選定→coorumを利用
    • 動画・マニュアルの作成
    • サイトビジュアルを作成・サイトの構築
    • ポータルへのユーザ導線を実装
  • イベント体験の設計（小島さんのコミュニティマーケティングを参照）
    • 「ファンの定義」と「コミュニティの理想の状態」を整理
• 運営（集客・運営方法）
  • 3本の柱
    • ミートアップ
    • 部活動
    • コミュニティサイト
• 実績
  • 参加ユーザ1300名以上
  • コミュニティ参加者の80％以上が社内独自ヘルススコアで「健全」となっている

7.日本最大級の決裁者プラットフォーム企業が語るコミュニティタッチの極意～年間約300件のユーザー会運営から見えてきた秘訣～

発表者

• 吉田 航平様
  • 株式会社オンリーストーリー 執行役員／CRO（Chief Revenue Officer）
• 宮下 莉奈様
  • 株式会社オンリーストーリー カスタマーサクセス事業部　イベントリーダー

    内容

• なぜコミュニティ化？
  • マッチングサービスであるため、ユーザが増えることでサービス拡大
  • コミュニティを作れば、ビジネスの循環・サービス活用の拡大に直結する
• コミュニティづくりとしくじり
  • 課題
    • 成果が出るユーザとそうでないユーザの二極化
    • マッチング後に不満が発生し、マッチングできなくなった
    • コミュニティで売り買いするそれぞれのユーザを集めたつもりが、売りたいユーザしか集まらなかった
• しくじりから見えた秘訣
  • TakerのコミュニティとGiverのコミュニティどっちが理想？
    • Taker:サービスを売りたい、目先の利益を出したい
    • Giver:投資、紹介することを厭わない
  • ユーザのGiverマインドを刺激するために実施し、成果が出たこと
    • 初期獲得ユーザに集中してロイヤルユーザと繋ける
      • オンボーディングとして、先輩ユーザとつながってもらう
      • ロイヤルユーザの事例・使い方を他のユーザに共有して、機能を使ってもらう
        • アップデートにユーザが追いつけるようにお手伝いする
    • 経営が顧客と直接コミュニケーションを取る
      • 経営が作りたい世界観を共有でき、共感を広げられる
      • ユーザの要望を早くキャッチアップでき、ユーザへの誠意を見せる
• まとめ
  • コミュニティに大事なのは「Giverマインドの醸成」