CS勉強会レポート ： 「カスタマーサクセス×スクラム」で事業を最大化する
こんにちは！ご覧いただきありがとうございます。
CareMakerという在宅医療向けのVertical SaaSスタートアップにてカスタマーサクセス部門の責任者をしています、尾田（@knsn_07）と申します。
先日6/20(木)に開催された、sasket LLC 代表の山田ひさのりさん主催のカスタマーサクセス向け勉強会に参加したので、そのレポートをシェアします。
（※資料転載の許可は頂いています）
テーマは「スクラムCS」。カスタマーサクセス組織として色々なやりたいことがある中で、優先度を決めてチームで着実に前に進める為のHowとして、素早い検証を強みとした「スクラム開発」におけるプロジェクト管理手法をCSに落とし込んだ事例が紹介されました。
登壇されたChatworkさん・カミナシさんいずれも、成功と失敗の両面にフォーカスを当てながら進められてきた試行錯誤の軌跡が実践的に紹介されていて、私自身も非常に学びと刺激を受けた内容でした。
▼勉強会概要
・主催：sasket LLC 山田ひさのり さん（@hisyamada）
・登壇者：
- Chatwork株式会社 松木さん（@matsukiayako）
- 株式会社カミナシ 石井さん（@kenty_cs）
・会場提供：株式会社Asobica（@asobica）
・日時：6月20日（木）18:00 - 19:30（オンライン / オフライン同時開催）
・タイトル：「カスタマーサクセスｘスクラム」で事業成果を最大化する
・学べること：
- 「スクラムCS」とは何か？
- 「スクラムCS」にはどのような利点があり、かつ成果に繋げられるのか？
- 「スクラムCS」を実施した2社がどのような成果を得たのか？
1. スクラムCSとは何か
はじめに、スクラムCSの概要について主催者の山田さんから説明がありました。
スクラムCSとは、開発手法の「スクラム開発」から着想を得て、そのプロジェクト管理手法をビジネスサイドに転用したもの。
スクラム開発については私も正直なところ名前しか知りませんでしたが、完璧なものを長い時間をかけて作り上げるような開発手法とは反対に、「最低限のものを素早く開発して市場に問う」という思想に基づいた開発手法とのことだそうです。
（※余談ですが、「スクラム開発」という名前はラグビーの用語「スクラム」に由来しており、目標に向かって各々の役割を果たしつつチーム全員で協力しながら前に進める特色が似ていることから、この名前が付いたようです）
そこで用いられるプロジェクト管理手法が、「顧客の反応を見て動くカスタマーサクセスの施策を管理する手法としても相性が良いのではないか」という考えのもと、「スクラムCS」と名付けて今回登壇された2社で実践したところ、上手くいったということでした。
以降、2社の登壇者の方々がそれぞれ自社で実践してきた方法や成果について、詳細を発表されました。
いずれも、そもそも上段で「達成したいカスタマーサクセス組織のゴール」が存在し、そこに到達するための実行フェーズでのプロジェクト管理手法としてCSスクラムを取り入れた、という構造なので、ここを前提として捉えておくとより話が理解しやすいと思います。
2. Chatworkさん事例 ： 仮説検証型スクラム
2-1. 前提方針と概要
Chatworkさんでは、そもそもKGIとして「NRRの向上」をゴールに活動されているようで、そのために「①エクスパンション増加」「②解約削減」を方向性として掲げられていました。
そのために、顧客ライフサイクルの中では「導入期」と「更新期」が重要フェーズだと捉え、「それぞれにおける勝ち筋を検証しスケールさせる」ことが課題だったようです。
それぞれの勝ち筋を「仮説ベースで立案し検証しながら進める」ことに重きを置いたプロジェクト管理手法として、「仮説検証型スクラム」という手法を取り入れられました。
（※なお、後述するカミナシさんの「プロジェクト管理型スクラム」はこれよりもスクラム開発的な要素を少し省いたよりライトな管理手法のようで、勉強会の中ではまず「プロジェクト管理型スクラム」から始めて、慣れてきたら「仮説検証型スクラム」にチャレンジすることを推奨されていました）
2-2. 具体的な取り組み
a. 管理方法（スクラムボード）
取り組み内容は、JIRAでスクラムボードを作成して管理されています。
スクラムボードは、以下のような項目で構成。
・バックログ：これから検証したい仮説を貯める
・スプリント：現在検証中の仮説の進捗を管理
・（スプリント内）メインカード：仮説そのものを記載
・（スプリント内）子カード：仮説を検証するための細分化したアクションをそれぞれ記載
・DONE：検証が終了したカードを移行
具体例では、「導入期」のオンボーディング完了率を改善するためのボトルネックを「推進者の推進力欠如」としつつ、解決の為の仮説として「"Chatworkを活用すればこれぐらいROIが出る" と事前に成果イメージを示すことで、推進者が意義を実感して推進力が高まるのではないか？」 という仮説（メインカード）と、そのためのアクション（子カード）の1つが紹介されていました。
b.推進体制と会議体
プロジェクトを進行するための体制や会議体も、基本的にはスクラム開発のやり方に則りつつ、部分的にアレンジされています。
体制は、登壇者の松木さんがスクラムマスターを務めて全体を指揮しつつ、検証する仮説（スプリント）ごとにオーナー・作成物の開発者を計5名ほど立てて推進されていました。
その他にマネジメント層など3名の方がレビュアーとして入ったり、山田さんがコーチとして伴走するなどの体制でした。
（※ちなみに、もっとリソースが少ないスタートアップ企業だと体制はもっと少人数かつ兼業体制になるので、その場合は同時進行する仮説（スプリント）を完全に1つに絞るなど量で調整するのが良いと、山田さんに質問したところ仰っていました）
また、会議体は各回週次で合計5つあり、以下のような棲み分けです。
①バックログリファインメント：バックログ（仮説一覧）を精査する
②スプリントプランニング：次に取り組むスプリント（仮説）を計画する
③スプリントレビュー：レビュアーに作成物や検証結果に対してのフィードバックを受ける
④レトロスペクティブ：スクラム活動の全体を振り返り改善する
⑤ラフ会：本来スクラム開発ではデイリーのアクション進捗確認を行うが、CSだと頻度高すぎるので週2ぐらいで実施する
c. 取り組みにおける重要ポイント
取り組みを推進する中で、特に肝だと説明されていた箇所は以下2点です。
①バックログの切り出し方は明文化する。また同じ方向性のスプリントが同時並行している時は要注意（依存関係がある可能性あり）
②スクラム全体を振り返る「レトロスペクティブ」をしっかりと運営することが、進行全体の改善のためにとても重要
2-3. 得られた成果とメリット
a. 成果：当初の目的であった「勝ち筋」の特定が上半期内で完了
当初の課題であった、NRR向上のための「導入期」と「更新期」における勝ち筋が検証しきれたことで、下期以降のスケールの為の土台作りが完了したことが大きな成果であったとのこと。
※勝ち筋の具体例：
・「オンボキックオフの質の向上」のための事前案内動画/アンケート
・「リニューアル/エクスパンションのためのアウトカム(ROI) 特定ツール
また、勝ち筋はマーケティングやセールスなど他部門の施策としても横展開されているようで、カスタマーサクセスだけに留まらない展開性が生まれているようです。
（ex. ROI特定ツールをセールスの商談に活用して受注率を向上させる）
b. メリット：仮説検証型スクラムによって、週単位でPDCAが回るように
従来は四半期に1回、大きな仮説を検証するような進め方だったところから、スクラム管理により、毎週週単位で細かく仮説検証し成果を積み上げられるようになったとのこと。
失敗に気づけるスピードも早くなるため、仮説が間違っていた場合は「失敗を潔く認めること」も重要だという説明は納得でした。
以上、Chatworkさんの仮説検証型スクラムでは、KGI達成のための課題を解決するにあたり、①有効な施策を仮説ベースで立案しスピーディに検証する→②仮説が間違っていたらすぐに撤退して次の施策に切り替える といったスピード感が特徴で、今回の「エクスパンションを増やす」のように課題自体の抽象度が高く、施策に落ちきっていないケースにおいて特に機能する手法だと感じました。
3. カミナシさん事例 ： プロセス管理型スクラム
3-1. 前提方針と概要
続いてカミナシさんの事例では、対象となるエンタープライズユニットの四半期の目標として「1年目更新を見据えたサクセスを定義しチームで乗り越える体制をつくる」というゴールを設定されており、
その為の要素として「①1年目の終了基準の共通言語化」「②資料やドキュメントへの落とし込み」「③新スキームの適用と効果検証」の3点を、具体的に実現する事として掲げられていました。
上記のゴールに沿って、「仕組みを作りきる為のタスク管理」に重きを置いたプロジェクト管理手法として、「プロセス管理型スクラム」という手法を取り入れられました。
3-2. 具体的な取り組み
a. 管理方法（スクラムボード）
取り組み内容は、Notionでスクラムボードを作成して管理されています。
スクラムボードは、以下のような項目で構成。
・バックログ：四半期に実現したい事を更にブレイクダウンしたテーマ一覧
・スプリント：各テーマを具体的なタスクに分解して進捗を管理
なお、各テーマ（スプリント）は前述の四半期ゴールの1つ目「①1年目の終了基準の共通言語化」をまず行った結果として出てきた要素を元に定義されたようです。
b.会議体
会議体は異なる頻度で合計4つあり、以下のような棲み分けです。
①週次MTG：スプリントレビューに該当
②月次MTG：各スプリントで上がった大きいテーマについてワークを行う
③中間振返り：プロジェクト全体の進捗と評価、Q後半にやることを決定（バックログリファインメントに近い）
④最終振返り：プロジェクト全体の進捗と評価、次Qにやることを決定（バックログリファインメント + レトロスペクティブに近い）
なお、体制については細かい言及はなかったものの、スプリント単位でのオーナーが不明確だった点を反省として挙げられていました。
c. 取り組みにおける重要ポイント
取り組みを推進する中で、特に肝になっていたのは「バックログ」の存在だそうです。
というのも、スクラム管理を導入する前は、CSの取り組み全てを「カンバン方式」で管理されていたようで、タスクメインでの管理となるため目的迷子になりやすかったとのこと。
（※カンバン方式：トヨタ自動車が発明した生産方式がその由来で、縦の軸を境にしてタスクを進捗フェーズで区切りながら管理する手法）
一見するとカンバン方式もプロセス管理型スクラムもフォーマットは似ていますが、違いとして「バックログが存在する = 目的にいつでも立ち返られる」ことが大きく、これにより複数のテーマに沿ったプロジェクトを管理する場合でも、目的迷子にならずに効率的に取り組みを推進することが出来るということでした。
3-3. 得られた成果とメリット
a. 成果：3ヶ月でお客様に新スキームを適用できる（最低限の）状態を実現
仕組みを作りきるところまでのプロセスをメインで管理されているため、顧客に当てて検証しきる部分は今回メインのスコープではなかったみたいですが、スクラム管理のおかげで作りたい仕組みを3ヶ月でスピーディに作りきることができたようです。
b. メリット：仮説検証型スクラムによって、週単位でPDCAが回るように
メリットは大きく4つ提示されていました。
スプリントごとにリソースを集中できたり、オーナーを立てれば権限委譲できるといった点は仮説検証型スクラムにも共通して言えることですが、必ずしも「実行」に拘らず、「議論と実行のバランスを取れる」ことはプロセス管理型スクラムならではの特徴だと感じました。
以上、カミナシさんのプロセス管理型スクラムでは、今回の「1年目更新を見据えたサクセスを定義し、チームで乗り越える体制作り」のように定性的に組織のゴールが存在し、そのために要素として必要な施策が論理的に導き出せるケースにおいて、それを実行するプロセスを正確に管理するために特に機能する手法だと感じました。
4. まとめ・感想
以上、両社の発表内容を一部私の解釈も交えてですが、まとめさせていただきました。
冒頭にも記載した通り、スクラムCSはそもそも実行部分でのプロジェクト管理手法であるため、登壇された2社のように、そもそも自社のカスタマーサクセス組織の方針や課題を言語化できていることがまず先に必要だと思います。
その上で、最後に両社の違いを自分なりに表に整理してみました。
私の解釈では、それぞれ名前の通り重きを置いている部分がやや異なるため、言語化した方針や課題の内容によって相性が良い方を選択するという考えでも良い気がしました。
また、体制や会議体の部分も本家のスクラム開発にどこまで寄せるかは、組織規模やリソースに応じて各社アレンジしうると感じます。
最後に、今後もカスタマーサクセスに関連する発信や、カスタマーサクセスに携わる方々とフランクに情報交換が出来ればと思っています。
Xでフォローやコメント、DMもお気軽に頂ければリアクションさせていただきます！（https://twitter.com/knsn_07/）