強めマッサージ好きが本当にオススメする家で使えるマッサージアイテム

みなさんはマッサージは好きですか?わたしは、大好きです。

マッサージで「強さはいかがいたしますか?」ときかれたら食い気味に「強めで」と答えるくらい好きです。

仕事をしているとたまに、めちゃくちゃ疲れがたまった感じがして、筋肉が緊張して、血流が無みたいになるときがあります。 そういうときは、そもそも体が硬くなるし、運動すると腰を痛めたり、首を痛めたりするので本当に疲れているときは運動する気になれません。

そこまで疲れてしまったときの私の強い味方は、マッサージです。

特に大好きなマッサージのお店は、下北沢にある、アロマヒーリングです。

beauty.hotpepper.jp

このお店には、痩身インドエステ、というメニューがあります。

痩身インドエステで全身を揉みほぐすメニューです!セル脂肪を熟練の手技でグイグイ揉み解す!終わった後のスッキリ感は癖になる。女性限定♪

目的には 痩身 はとありますが、あったまるタイプのベットの上でほかほかになった全身を、屈強な女性スタッフが、足先から頭まで、凝りも駄肉もパンかと思うほどこねくり回して伸ばして流して徹底的にマッサージしてくれます。最後は汗だくになって終わります。

めちゃくちゃ痛いんですが、最終的には強制的に血流が回復されて、よっしゃいっちょ運動でもしてやるか、というところまでコンディションと気力が回復します。 マッサージって相性が悪いと、終わった後「?」ってなること多いのですが、ここのはめちゃくちゃやってやった感を得られます。

しかし、問題は、めちゃくちゃ高額ということです。 誕生日プレゼント並に高額なので庶民の私は本当にたまの本気のご褒美としてしか自分に与えてあげることができません。 この店でなくもう少し価格帯が低くても、マッサージは全体的に結構高くて、都内で安心できるところなら60分6,000円〜が相場ではないでしょうか。

頻繁に行けない、となると、家で自分で何かできるものはないかと考えるようになります。 こういうご時世ですので、家でできるとうれしいことはたくさん。

そこで今日は、強めマッサージ好きが本当にオススメする家で使えるマッサージアイテムを紹介します。

やわこ

  • 筋肉をほぐす系
  • テニスボール2個分
  • ねころがって体の下に置いてぐりぐりする
  • お尻の下や、脇の下、太腿、肩など自分の好みのツボを押せる!

トリガーポイント

  • 棒状
  • 直径:14cm 長さ:33cm
  • この上に寝転がって、太腿やふくらはぎ、腰まわりをグリグリする
  • ツボではなく、全体的に筋肉を圧迫してほぐす
  • やわこより手軽じゃないけど、こっちの方が効く気がしてます

Matty式シリーズ

解毒こぶし

Matty式解毒こぶし

Matty式解毒こぶし

  • 作者:Matty
  • 発売日: 2017/10/02
  • メディア: 単行本

  • Mattyさん(マッサージ師)の拳の形を模したもの
  • これをメリケンサックのように掴んで、肩、首、足、顔とにかくどこでもグリグリする
  • 力をかけずに確実に凝りを捕らえられます
  • ただのプラスチックなので、お風呂場でもどこでもパッと使えます
  • 掌サイズなので場所もとらない

解毒棒

  • Mattyさん(マッサージ師)がリンパを流すときの手の形を模したもの
  • ふくらはぎ、ふともも、二の腕、脇の下、などリンパをながしたいところをざっざっと流すようにマッサージする
  • 摩擦があるのでマッサージオイル的なもの必須です
  • むくみが取れて細くなる
  • ダイエットのお供に
  • 使い方は玄人向け
  • 痛い

YA-MAN 電動頭皮ブラシ

  • お店でうけるようなヘッドマッサージを再現できる
  • 海洋生物っぽいくうようよ動く足で頭皮を揉みほぐす
  • 眼精披露とかにも効くし、頭皮をほぐすと顔のリフトアップにも効くそうです

最後に

  • みなさん作業環境が変わったり、あつ森やり過ぎたり、凝りの多い日々をお過ごしのことと存じます
  • ツールも使いこなして、いい感じにリラックスして過ごしていきたいですね

テックブログカンファレンス に参加してみた

今日は 「テックブログカンファレンス」に参加してきました。

connpass.com

レポートとして自分なりの理解をメモしました。内容や理解が間違っている、というところを見つけた方がおられたらぜひお知らせください。

開催はIIJさんのオフィスへ。 ノベルティにマスクをいただき安心。

今日のテーマ

以下はイベント詳細より。

<テックブログカンファレンス>

技術に関する様々な情報を発信する「テックブログ」

その担当者に「なぜ、テックブログをはじめたのか?」と問えば、いろいろな答えが返ってくるかと思います。自社サービスを知ってもらうため、採用のため、技術に対する純粋な愛...などなど。

そして、そこにはたくさんの悩みがあることでしょう。

どうやって運営すれば良いの?運営体制は?長く続けるコツは?というか、楽しみながら書いてもらう仕組みとか作れないかな...。そんな悩みやテックブログ運営に関するTipsをこのイベントで語り合いませんか。

風穴さん(サイボウズフリーランス編集者)「techブログを続けるために大事にしてること」

speakerdeck.com

  • フリーランス編集者として活動しつつ、サイボウズさんで「コネクト支援チーム」として活動されている
  • コネクト支援チームは
    • 5年後、10年後のエンジニア採用をやりやすくするための活動」をされている
    • チームは4名

blog.cybozu.io

blog.kintone.io

  • ほぼ毎週記事投稿されている。すごい!

techブログのためにやったこと やってないこと

  • SEO / ノルマ管理 / 特別報酬

techブログのために(意識して) やったこと

  • 繋がる / いいね! / Enjoi!
  • 「読みたいドリブン」
    • 社内の人とあって話して、面白いことやってるね、あれいいね、という何らかのリアクションをたくさんされた
    • 宣伝のミッションを持たず、周囲の読みたいという気持ちを書く人のモチベーションに変えている
  • 気軽にブログアップできるように、チェックフローをなくした
    • 不安だったら周りの人にみてもらってくださいね、くらい限りなくハードルを下げた
  • 「編集者とは」

(われらが) 井上さん「サーバー監視サービス・Mackerel のブログ記事ができるまで」

speakerdeck.com

blog.a-know.me

  • 10年以上続けている。すごい!

mackerel.io

  • こんな流れで書いている。
  • 一番難しいのは冒頭の時効の挨拶
  • あとがきも難しい!個性を出せるのすごい。
  • ユーザーの立場に立って有益な情報をちゃんと考える
  • 自分もユーザーであり続ける意識
  • ブログ書いて投稿する作業をトータル1時間でできる。すごい!

荒木さん(アマゾン ウェブ サービス ジャパン)「AWSデベロッパー向けに日本独自の新メディアを始めた理由」

  • AWS はブログのチャンネルがたくさんある。10以上。
  • AWS News Blogは今は70人くらいで書いている(70人!!)
  • 基本的にはみんな独自企画をしてアウトプットしている
  • 日本語訳する主要記事というのは日本では決めていなくて、1週間かかる。待っていられなくて日本のメンバーが先に記事を選別して翻訳している。
  • 日本語の独自ブログもある
  • エンタープライズ、スタートアップ、SMB、Developerまで全部がターゲット

日本向けのことを主体的にやりたい

  • 日本にいて、ブログでしかAWSと接点がない人に向けて書くべきでは、となった
  • オフラインのイベントは接点は一度きり。繋がりを活かすための継続的なコンテンツ戦略を
    • イベント中に15分に1回記事を出した
    • ソーシャルでみられて一時的に盛り上がるだけになってしまった
  • 書きたい人のモチベーションを編集する人が、投稿数を制限するようになった
  • 月間12-13個。クオリティの高いものだけを厳選するメディアを作った

aws.amazon.com

  • AWSに直接関係ないような記事まである
  • でもコンテンツとして品質が高く、継続してみたくなるようなものに厳選されている

堂前さん(インターネットイニシアティブ)「テックブログなんてやるつもりはなかった」

speakerdeck.com

  • IIJさんもたくさんブログがある
  • 今日の話題は2つ
  • 堂前さんはエンジニアから広報部に転身!

techlog.iij.ad.jp

eng-blog.iij.ad.jp

  • 会社ブログはコミュニティと同じ
  • コンテンツはコミュニティの賑わいとニワトリたまご
  • どうやって、このサイクルをまわすか?
    • 自分でかく
  • 頼みこんで書いてもらう。本人に頼む!
    • ただし、なんでもいいからは負担
  • 社内wikiのネタを見つけて、これを書いて、とお願いする
  • ヒット記事が出ると、社内の中でブログが話題になっていく
  • 編集部として何ができるか
    • ネタの発掘
    • 文章・体裁の整理
      • 書式はこだわらない
      • 場合によっては、文章の整理も提案
    • 公開記事の承認
      • 記事公開の責任を書いた人からはがすため
      • 責任を広報部でひきとる
    • 執筆者へのフィードバック
  • 盛り上がってからは、持ち込み記事が出るようになった

佐藤さん(ファインディ)「エンジニア向けにブログを書く上での考え方や信念」

speakerdeck.com

findy-code.io

  • ブログ = 論文
    • 構成がほぼ一緒
    • 教授にフィードバックをもらう視点と似てる
  • ブログも一つのウェブサービス
  • 届けたいユーザーに届いてる?
  • 想定したいユーザーから期待するアクションまで考える
  • 次のアクションを必ず作る
  • そのまま実行できるようにする
    • ブログ内に疑問を残さない
    • 読者として初心者を想定して全部丁寧に書く
  • 人やモノをディスらない、比べすぎない
  • ノウハウ集ではなく、考えや背景をセットで知りたいので、体験談やインタビューなど実情を交える
  • 正確性、公平性、論理性、流行、多少のエモさ
  • 楽しく書く!

佐々木さん(クラスメソッド)「テックブログとCI」

dev.classmethod.jp

  • 成長するためのテックブログ
  • 成長するには学習
  • 学習にはアウトプットがセット
  • その人がその技術について知っていることの印になる(評価)
  • モチベーション / 学習 / アウトプット / 評価
  • ブログを企業のカルチャーとしてうたっている
  • 企業のアイデンティティになっている
  • アクセス数もシェア数も最初は伸びないけどとにかくやり続ける
  • トップダウンで偉い人が率先して書く
  • テックブログは目的ではなく、学習やそのアウトプットが目的
  • アウトプットの内容の間違いは咎めない、アウトプットしたことをまず評価する

感想(明日すぐやってみたいこと

  • チームに編集者ほしすぎる
  • コンテンツをストックして、編集者が厳選する。やってみたい!
    • これまで個人ブログとかに分散しているものも含めたらあらためて自社記事としてコンテンツを組み立てるとかもできるようになる?
  • ブログも一つのウェブサービスという視点で見直ししてみたい!
  • テックブログ、蓄積されたコンテンツ量とか、コンテンツを生み出すコミュニティの成熟度とかによって、どう取り組むかフェーズがありそう

レポートは以上です。

データアーキテクト(データ整備人)を”前向きに”考える会 に参加してみた

今日は 「データアーキテクト(データ整備人)を”前向きに”考える会」に参加してきました。

analytics-and-intelligence.connpass.com

レポートとして自分なりの理解をメモしました。内容や理解が間違っている、というところを見つけた方がおられたらぜひお知らせください。

今日のテーマ

以下はイベント詳細より。

データを整備・抽出・加工したりダッシュボード作ったりとエンジニアとアナリストの間にある「誰かがやらないと別の誰かが困るのに、なぜか誰もやりたがらない役割」であるデータアーキテクト(データ整備人)のスキル・ノウハウ・キャリアなどについて、恨みつらみではなく”前向き”に考えようという会です。

参加者であるわたしの状態

ほぼはじめてデータ分析に関わる勉強会に参加しました。 カスタマーサクセス話題だと10のうち6とか7くらいについてはわかった状態で、残りの特有の話題について新しく知見を得る、という感じですが、データ分析まわりについては10のうち、1とか2とかの理解で、基本的な文脈についても憶測して補いつつ、新しい文脈についても知る、という感じで、なかなか難易度が高かった……

なので今回はレポートという感じではないかも...? 念のため、これを読む方が、余計な情報に触れないように、わたしがどういう人で、どういう視点で聞いた話かを書いておきます。

  • わたしはBtoBのSaaSプロダクトのカスタマーサクセス的立場(職種名はCRE
  • カスタマーサクセス方面の関心でデータを触っている
  • データ分析については初級本を1冊読んだ
  • SQLの本、pandasの本を最近2,3冊必要に応じてペラペラ読んでみている
  • もともとは、SQLは書いたことある。むかしOracleの資格とった。けど、業務で触ったことなかった
  • 最近会社でデータ分析の勉強会なども開催されていていろんな話題に触れつつある
  • チームメンバーと言葉を合わせたい、課題感を共有したい、自走できるレベルを上げたい、というようなモチベーションで参加

登壇者の方々は以下。みなさん資料がしっかりしていて、レポートを書かずとも、資料を見たらよい!という感じでした。すごい…

お話を聞くのに必死でほとんどメモれなかったので以下は資料リンク一式と本当にわたしが気になったぽちぽち書いたキーワートやぼやきだけです…基本的には資料読み込まれることがおすすめ。

本編

しんゆうさん データアーキテクト(データ整備人)の概観とこれからの展望と課題

speakerdeck.com

  • データエンジニアという職種で働いている人は少なくて、多くは何かのエンジニアが兼務している
  • データを集めるところからデータを扱うところまでの間にある仕事=データアーキテクト(データ整備人)
  • データ整備人に向いている人
    • エンジニアは何かを作る人、なので、エンジニアではないけど、エンジニアリングのスキルもゼロではないし
    • 一方、分析の経験がないと利用者とのコミュニケーション、提案が難しくなる
  • 企業がデータを扱い始めたのは2010年代ころ

非分析者・分析者という区分けはじめて聞ききました。 データ整備人は...スキルセットを定義するのが難しそう。 アプリケーションについてもまあまあ知っていて、ビジネスについてもまあまあ知っている必要もあるし、コミュニケーション能力が必要そう(わたしのことでは!? あとは、無料で講演に来てくれるらしい。来て欲しい!!

ゆずたそさん 【永久保存版】3社の事例から学ぶ!現場で使われるダッシュボードの作り方

speakerdeck.com

  • コミュニケーション重要
  • PDCAで何度か微調整を重ねて業務で使われるようにしている
  • 5W1H(データを扱う人や目的)とPDCAが大事
  • botつかって業務の中で自然と必ずPDCAに触れる機会をつくっている(天才では
  • アジェンダPDCAが回る項目を追加している

shinaro iwaiさん データ整備業でぶつかった5つの課題・データ整備人に求められる3つのスキル

speakerdeck.com

  • Google Colaboratory
  • ipynb
  • SQLを再利用可能な状態にしておく。パラメーター変えるだけでSQLわからなくても叩けるようにしておく
    • こういう工夫で営業の人にやってもらえるようにする
    • CREATE TEMP FUNCTION 使って冒頭に書いて修正箇所が見つけやすくする
  • クエリレシピ をまとめている(私もまとめたい。今雑に書いているけどフォーマットつくろうかな
  • データ整備は組織として専任がいるわけではない
  • データを2つの形式にまとめられるのではという仮説を持っている
    • 行動分析
    • ユーザー分析

堀野将晴さん サイエンス視点からのデータアーキテクト

www.slideshare.net

  • データ活用部門が3つ
    • サービスサイド
    • サイエンス
    • データ活用推進する部隊
  • サイエンスのためにデータを使う
  • データ活用とサイエンスの違い
  • コミュニケーションは重要
  • HiveQL

すでにこの時点で知見で頭の中がいっぱいでメモも少なめですみません。また、あとでゆっくり復習しよう......

理解まとめと感想

理解まとめ

  • データエンジニア、アナリティスト、サイエンティストが抱える狭間の課題がある
  • それを解決する人に名前をつけるならデータアーキテクト(データ整備人)
  • この課題を解決するための課題
    • 誰かがやらないといけないけどやる人が決まってない、誰かがまとめてやっている
    • エンジニアスキルもヒューマンスキルも必要な立派な仕事だけど評価する仕組みがない
    • リソースが足りない......etc
  • データが求められる場面
    • サービスや業務のKPI
    • プロダクトサイドの改善
  • データに触る2つのやり方(わたしの理解
    • データ活用ぽいところ
      • 今までいろいろなところにころがっていてすぐに使えなかったデータを使えるようにして集計などを簡単にする
    • データサイエンス
      • サイエンスの力を借りて課題に対して新しい切り口を見出す(これはわたしはまだまだわからない
  • 関連しがちな部署など
    • 事業責任者や企画をしているひと
    • プロダクトを改善したい人
    • 広告収入をあげたい人
    • 日々の自分の業務を改善したい人
  • 本質的にはいろんな人がデータを見てそれぞれのKPIに沿って活用して課題解決できる
    • ただ、KPIの建てつけによって必要なデータや形式は変わる
    • だからデータ整備人は、いろいろなロールの人の意見を聞いて適切に深掘りしたり優先度づけしてデータを整備する必要がある(高スキル!!
  • 大事なこととして言われてたこと改めてまとめ
    • コミュニケーション
    • 5W1HPDCAが意識された業務フロー
    • データを取り扱いやすい形にして自動化、ユーザーが手間なく使えるように
    • データまわりはまだまだあたらしい分野。スキルセットや評価方法を定義するのが難しい(自分がなるかは別として会社のためにやっていきたい

文脈関係なく疑問におもったこと

  • いろんな人からいろんな方面で課題が集まるというコメントが多かったけど、そもそもデータ分析にとってよい課題の立て方、よい問題文の書き方、課題の絞り方ってどうやってやるの
  • データアナリティクスについてかじりたい場合は何からはじめたらいいの。今やってるpandas練習がそれか?

明日すぐやってみたいこと

  • データ活用の 5W1H はすぐ考える!
  • ゆずたそさんの資料見る。

レポートは以上です。 はあ〜〜まだまだレベルアップしないといけないことが山積みですね。

成功企業と最新事例から学ぶカスタマーサクセス最前線 に参加してみた

今日は 「成功企業と最新事例から学ぶカスタマーサクセス最前線」に参加してきました。

asobica.connpass.com

レポートとして自分なりの理解をメモしました。内容や理解が間違っている、というところを見つけた方がおられたらぜひお知らせください。

今日はVOYAGEさんのオフィスへ。めちゃくちゃおしゃれ。 最初に案内されたバーコーナー?のようなところでいただいた空腹でのコーラ最高に美味しかったです。

今日のテーマ

以下はイベント詳細より。

昨今、SaaSサブスクリプション事業者を中心に多くの企業がカスタマーサクセスに注力していますが、目まぐるしく変化する日々の中で最新の手法・ツールに対応できている企業はほんの一握りではないでしょうか。「興味はあるが何から始めたら良いのかが分からない」「立ち上げてみたものの思うように成果が上がらない」といった声が多く聞かれます。

セミナーでは、カスタマーサクセスで成果を出すために必要なことを、最新事例を用いてご紹介します。

第1部では、業界初となるカスタマーサポート特化型AI「KARAKURI(カラクリ)chatbot」を運営するカラクリ株式会社取締役の麹池氏が、カスタマーサクセスにおける効果的な手法について最新事例を交えてご紹介します。 また、freee社をはじめとした多くの成長企業が導入する、顧客成長プラットホーム「coorum」を運営する株式会社Asobica代表の今田氏が、カスタマーサクセスの本質や効果的な運用方法などをご紹介します。 第2部では、Eightコミュニティマネージャーの小父内氏をモデレーターとし、カスタマーサクセスの最前線でご活躍中の、株式会社ABEJAの丸田氏、Sansan株式会社の山田氏にご登壇いただき、カスタマーサクセスにおける工夫や現在の取り組みに関して色々お聞きする予定です。

ラクリ 麹池さん エンタープライズ向けSaaSを成功に導くスクラムCS

サクセスが何かを定義

karakuri.ai

  • カスタマーサポート特化型のAIチャットボットSaaSのカラクリさん。
  • 麹池さんはコンサルティングのバックグラウンドからカラクリのセールスのリードに従事しつつ、カスタマーサクセスの採用に取り組んでおられるとのこと。
  • エンタープライズ向けだと、
  • サービスの成長に伴い問い合わせ数も伸びるけれども、オペレーターのキャパシティは伸びないということがある
  • 例えば
    • ユーザー数が増えていても、1ヶ月でチャーンしているユーザーも......
    • 解約理由はログインがうまくいかないという初歩的なもの......
  • こういった課題を解決できるとチャーンを回避して、サービスもさらに成長できる
  • サクセスロードマップをはじめにつくる
  • 経営目標まで書いていただいているとのこと
  • 何ヶ月目までにどのような状態になっていたいかをコミットされている
  • 事業KPIや現場のKPIにまで落としこんで、目線を合わせる

データ分析

  • データオリエンティッドで改善していく
  • 提供するサービスの中で、KPIに関わるデータを測定できるようになっているとのこと。(これはすごい。便利

### 三位一体 -> スクラム

  • エンタープライズならではのカスタマイズ要件の高さ
  • お客さまも優先度づけができていない
  • サクセスロードマップにしたがってスクラムで開発していく
  • 三位一体のチーム
    • アカウントエグゼクティブ
    • CXD
    • エンジニア(Web/AI)
  • SMB向けだとここまでできないけれども、エンタープライズ向けであれば担当エンジニアを立てられる

質問

  • KPG・KPIを立ててないユーザーもいると思うけどどうするの
    • ワークショップで一緒につくる
    • ある程度イメージがある場合は素案を作る場合もある
  • 課題をどうやって見つけるの
    • お客さまが認識している課題を聞いたあとにも、実はこういうことがないですか?ということを聞いている

Asobica 今田さん "Core fan heal everything" コアファンは全てを癒す

coorum.jp

エンゲージメント向上を実現するユーザーコミュニティ構築サービス coorum
  • カスタマーサクセスに関するよくある間違い(4つあったけどまとめきれなかった......
    • 顧客の規模でサポートを変える
      • 規模が大きい、単価が高い場合にハイタッチにしようというのはちょっと違う
      • 成熟度で変えましょう
      • NPSも成熟度取得タイミングをもうけましょう
        • すると成熟度、打ち手に対するNPSがわかり、課題を洗い出す事ができる

  • セルフサービス=不親切?
    • そもそも問い合わせをしないユーザーの方がNPSが低い

  • コアファンは
    • 事例になってくれる
    • SNSで情報を提供してくれる
    • ユーザー同士のコミュティも支えてくれる
    • 製品へのフィードバックや改善もしてくれる

パネルディスカッション Sansan 山田さん × ABEJA 丸田さん × Eight 小父内さん

bizzine.jp

青本の著者の方との対談記事とのこと!

山田さんは、BIz/Zineでカスタマーサクセスのノウハウ記事を連載中。

bizzine.jp

こちらですね。

丸田さんは、人事コンサルティングのバックグラウンドが。 カスタマーサクセスは結局組織変革みたいなところに落ちていく。 AIは武器。それで強い敵を倒しにいく。そういう仕方で組織を変えていけると考えておられるとのこと。

connpass.com

丸田さんが、やっておられるCSカレッジというコミュニティはこちら。

www.slideshare.net

このスライドも印象深いですよね。

小父内さんは工事現場で働きつつ、ラッパーをしていたバックグラウンド。 ラップとCSは相性いいのでしょうか。

SanSanに入社され、今はEightでコミュニティマネージャーをされているとのこと。

ここからはパネルディスカッション。気になったキーワードをピックアップしていきます。

トークテーマ① CSの立ち上げ

  • 最初は契約しているIDがすべて使われているかどうかがもっとも重要なチャーン指標になっている(山田さん
  • 製品とお客さまの理想にギャップがあるときそれを埋めに行くのがカスタマーサクセス(丸田さん
    • それが、お客さまのリテラシーの問題なのか。それとも製品の問題なのか。
    • 洗剤を作っても、洗濯機を持ってなかったら使ってもらえない。洗濯機をもっていってあげるようなブリッジをCSがやらなければならない
  • まずはコスト削減からやろう(山田さん
    • チャーン削減、NetRevenueとかを目標にすると、目に見えるのに年単位でかかるのでやっている人のモチベが上がりにくい
    • 日々発生している、お客さまの工数を削減するように働きかける
    • お客さまのサイクルが年単位で回っているので、効果が見えてくるのも年単位
      • 1年まわさないと去年こうだったからこうしてみよう、という話がやっとできてくる

トークタイム② 他部署との連携

  • CSは板挟みになりがち??
  • 営業とCSでKPIを交換したりシェアしたりしている(丸田さん
  • 一番困るのはセールスとの連携だと思う。アドバイスできるとしたら、SanSanはクロージングブックというのを作っている。(山田さん
    • 最初のCSのタッチポイントで「クロージングブックは読みましたか?今後はこれに基づいて支援していきますね」というところから会話をはじめる
  • CSのチームは顧客の規模で分けている(山田さん

トークテーマ③ CSの"これから"

聴き入ってしまいました。

KPIについて

山田さん

  • チャーンの金額を持っている。営業と折半している。営業の動きによってチャーンが回避されたりすることもある
    • 折半=責任を共有している
  • オンボーディングの成功率を持っている
  • ヘルススコア。これは最初の2つよりは少し重要度は低め
  • オンボーディングの定義は、かなりCSのチームによって個別化する
    • 期間と定義をまずはきめましょう
    • SanSanならすべてのユーザーがログインして、一度でも名刺を取り込んでいること

丸田さん

  • チャーンレート。アップセルの金額の2つ。を見ている。

質問

  • (質問)チャーンを防ぐ施策は?
    • お客さまとの期待値コントロールを。Why、What、Howが大事。Howの部分、成功までのロードをCSを作成して提供する。(丸田さん
    • 資料はマーケがつくっている。それがよい(山田さん
  • (質問)
    • 最初は人を増やしてよい。でも10人ほどで臨界点がくる。それと平行してテクノロジーの基盤を用意しておくと立ち上がりが早い(山田さん
    • 人が足りなかった。コミュニティを作ったら、お客さま同士でサクセスされる仕組みがワークしていった(丸田さん
    • 少人数で成功できるのがコミュニティのよさ。ハイタッチで得たノウハウをコミュニティに活かす(小父内さん

感想(明日すぐやってみたいこと

  • 今やっているカスタマーサクセスジャーニーマップ。実際に利用してくださるユーザーレベルでのものになっているけど、エンタープライズに使っていただくには、KPG / KPI まで見えるように作っていかないとな......これがめっさ難しい
  • まずはユーザー/自分たちのコスト削減をCS目線でやる という切り口は自分のチームでも考えやすいかもなあ。考えてみたい

レポートは以上です。

日本でもっと “カスタマーサクセス” を盛り上げよう!! Japan Customer Success Community(JCSC) #11 に参加してみた

今日は 「日本でもっと “カスタマーサクセス” を盛り上げよう!! Japan Customer Success Community(JCSC) #11」に参加してきました。

jcsc11.peatix.com

レポートとして自分なりの理解をメモしました。内容や理解が間違っている、というところを見つけた方がおられたらぜひお知らせください。

SmartHRさんの セミナールームで行われました。すてきな会場ですね。

https://twitter.com/mur_ms_/status/1198898200607768580

ご飯も豪華でした。ありがたや......

今日のテーマ

登壇タイトルは「顧客を成功に導くオンボーディングの削ぎ落とし方とは?〜トレタが辞メタ、4つのポイント〜」。

以下はイベント詳細より。

詳細 ■当日は、こんなお話をする予定です ・オンボーディングで4つのことを辞めたら、オンボーディング卒業率がUPした!? ・再オンボーディングはやっぱり難しい。だから初回オンボーディングは外せない! ・自社だけではなく、パートナー企業を巻き込んでできるサクセスは?  等

テーマは、"オンボーディング"。

登壇されたのは、トレタ株式会社 カスタマーサクセス部 部長 鈴木 高太郎 さん もともとはセールス出身で、トレタの7番目のメンバーなんだそうです。いろいろなご経験がある方ですね。 第二回 カスタマーサクセス天下一武闘会 - CS HACK #20 でも登壇されていらっしゃいました。

cshack.connpass.com

お客さまにサクセスしてもらうためにはやりたいことはたくさんあるし、むしろやり過ぎてしまっていることもある。けれど、敢えてやらないことを決めることでオンボーディングの成功率を高めるという目から鱗の登壇内容でした。

鈴木さんの携わっておられるトレタは、トレタは顧客台帳・予約台帳・Web予約をiPadから操作可能なものとして提供しているSaaS

toreta.in

CS1人あたりの担当店舗が1,000店舗超え。 トレタは飲食店に特化しているバーティカルSaaS。店舗のアイドルタイムである、14:00-17:00の3時間のみでどこまでできるかがポイントになる、とのこと。

オンボーディングの歴史

  • オンボーディング完了の定義は、以前まで使っていた予約台帳がなくなったこと。紙台帳を使っていた人がきちんとすべてiPadでできていること。紙からコピーしていたらそれはNG。
  • それができているかを電話して確認している。
  • Metabase でちゃんと使っているかどうかをみている。
  • 定着率については別の指標でみている(今日はテーマからそれるのでこの話はしない

www.metabase.com

Metabase。知らなかった。 そして、そもそもまずすべてのユーザーをオンボーディングされておられる。オンボーディングの成功率を計測できている。すごい......

機能説明をしないということへの決断

  • みんなのやり方がバラバラな時期にした決断
  • 人は7つまでしか覚えられないのでそもそもたくさん説明できない
  • お客さまは、細かい機能より、現状のオペレーションにフィットするかが不安
  • 機能説明は、日々の業務で疲れ切ってるお客さまは聞いていて寝ちゃう
  • ハイパフォーマーとローパフォーマーの違いがある
  • 合わせるためには?
    • スクリプトは柔軟性が失われる。ディスカッション形式にした
    • 機能説明 60分->15分 とした。45分は質問対応
      • 相手のオペレーションに必要なコミュニケーションだけになる
    • 便利機能は一切説明しない
    • ちなみに〜〜できます。を全て排除
      • このボタンでいけますが、ちなみにこのボタンからもいけますよ。みたいなのは無し
  • 信頼関係が構築しやすくなった
  • 当たり前の質問への回答が早くなって、お客さまからの重箱のすみをつつく質問がなくなった
  • ちなみに〜、ちなみに〜、とはじめの段階から言っているとお客さまからも「ちなみに〜〜もできますか?」と聞かれて「いや、それはできないんですよ」みたいな話がはじまってしまう
  • 便利機能は2タッチ目にお伝えしている
  • 成果
    • ローバフォーマーが底上げされた
  • 最終的には、機能説明などはパートナーさんにお願いするというチャレンジもされているとのこと

お客様のところに行かないという決断

  • オプションが増えてオンボーディング対応が増えた時期にした決断
  • オプションが増えるとすぐに売上が増える、反面CSは対応する対象が全体の10%増える
  • お客さまは、すぐに問題を解決したい。早く使いたい。それなのにCSの対応が契約から2ヶ月待ち。CSで対応しきれなくなってセールスに助けを求めることに
    • 地方対応も......
  • CSが獲得のボトムネックになる。効率化しないと未来がないと思った
  • 逃げ場がない環境設定
    • しきりをつけて、リモートで打ち合わせ対応できるようにした
    • CS担当とお客さま両方の心理的なハードルを下げた
      • CS担当には、行ってもいいけど一回リモートでやってみて、という
      • お客さまには、一回リモートでやってダメだったら行かせてくれ、という
      • チームに訪問未経験なメンバーを混ぜる。訪問慣れしている人は訪問した方が楽
  • 成果
    • オンボーディング成功率が5%上がった
    • 2タッチ-> 4タッチになった。7x4=28つの情報をお客様が得られるようになった
    • オンボーディング期間も短縮された。28日間->14日間

人が説明しないという決断

  • お客さまどんどん欲求が高まってしまう。オンボーディングが完了したら、もっともっと活用したいという気持ちになる
  • メンバーの8割がオンボーディング業務になってしまった。カスタマーサクセスやりたいのにやれない
  • 顧客ごとにカスタマイズしていない部分は動画にした
  • 動画はタッチポイントのたびにプッシュする
    • 何度もプッシュしよう
  • 大事なのは、動画をみてもらうだけでなく、宿題を出すこと
    • ちゃんと入力をしてくださいね、というところまで宿題を出す
    • 平均オンボーディング成功率4%アップ
  • 成果
    • 14日間->7日間
    • 全員がサクセス活動できるようになった

感想(明日すぐやってみたいこと

動画をみてもらうだけでなく、宿題を出すこと

私のチームでは動画コンテンツを作るところまではできていないですが、ハンズオン後の対応としても同じことがいえると思いました。ハンズオンをしたお客さまに向けてきちんと宿題を出す、というのは明日からでもやりたい!

レポートは以上です。 登壇でお話いただいた内容から参加者の方々からの質問までしっかり中身の詰まったイベントでした。 次回も参加したい!!

こども哲学ハンドブックという本を書きました。

2018年5月頃から(と記憶しております)、1年以上に渡りコツコツ執筆していた本がついに発売されることになりました。本日8/21より書店に配本される予定です。 著者名は所属する団体名となっていますが、本を開いていただくと、奥付に執筆者の一人として私の名前を見つけていただくことができるかと思います。

f:id:missasan:20190821142117j:plain:w400

Amazonからも購入可能です。

こども哲学ハンドブック 自由に考え、自由に話す場のつくり方

こども哲学ハンドブック 自由に考え、自由に話す場のつくり方

なぜITのあの字もないような本を書いていたかというと、私は実は平日日中帯のお勤め以外のプライベートの時間を一部費やして「こども哲学 おとな哲学 アーダコーダ」(以下、アーダコーダ)という特定非営利活動法人で理事をしています。 (お仕事の繋がりの方が、この活動もしているというのをあまりお伝えできていない気がしたので、こういう書き方をしてみました。哲学畑で知り合った方の方が普段はITの人というのをご存知かもしれない)

この本は、その団体が年に3-4回のペースで開催する講座(ワークショップ)の内容を文字やイラストに起こしてまとめたものです。

どんな内容かをざっくりご紹介すると、「哲学」という、これまでアカデミックな場でしか触れる機会がなかったものを、日々のくらしの中や、身近なコミュニティで楽しむことをおすすめしたり、そういう場をつくりたい人にいろいろな方法や、楽しむためのコツをお伝えするための本です。 しかも、それを幼稚園から中高生くらいまでのこどもと一緒にやることを念頭にしています。

なので、内容もたとえばプラトンアリストテレスの議論や文献をおさらいしたり、哲学の歴史をたどるようなものではありません。 日々こどもが触れる何気ない問い、ただし、「答えが1つとは限らない、答えがすぐには出ない、あるいは答えがないかもしれない」ような哲学の文脈でも扱われるような問いについて、おとなが答えをこども教えてあげるのではなく、なんとかして一緒に取り組んでいくための本になっています。 そういったことに興味がある、哲学っぽいアプローチで問いを解決していくことを試してみたい方向けの(学術書ではなく)実用書です。

哲学なんて勉強したことがないからよくわからん、という方でも関係なく読める本になっています。日々のくらしで哲学するってどういうこと?と気になった方はぜひ読んでみてフィードバックください。

最後に

団体が発足したての頃に一番によせられれていた声は、こどもがいるおとなや、学校の先生が、こどもと哲学をやりたいというものでした。学習指導要領の改訂や、アクティブラーニングという言葉への関心の広まりも追い風になって、今ではこども哲学は全国で、有志のコミュニティだけではなく、学校の中でも実施されています。

実はジョインした当時の私の個人的なモチベーションは、友達とボードゲームで遊ぶように、哲学っぽい対話を日々のくらしに持ち込みたい、哲学っぽい対話で遊べる仲間を増やしたい、というところにありましたが、数年をかけて、私の思惑や想像をはるかに超えた活動になっています。

私が団体にジョインした2014年ころは、今とはまた別の会社でめちゃくちゃ時間を使って仕事ばかりをしていて、かつその環境では、とにかくビジネスにとってメリットのある答えをいかに早く出せるか、ということが重視されていました。 大学時代に哲学講座に所属して、日がな抽象的な話をさかなに安酒を飲んでいた学生時代がなつかしくなっていた時期でもありました。会社員になって数年経って少しそういうことを懐かしむ余裕がでてきた頃だったんだと思います。その頃、学生時代の友人に声をかけたら、ちょうどこの団体が発足される間近だったので、私自身はしばらく哲学から離れてしまっていたのでが、無理をいって立ち上げメンバーに混ぜてもらったのでした。

そこから数年して、このような執筆の機会をいただけるようになったのは、チャレンジする機会を持たせてくれてサポートしてくれた力強いメンバーのみなさまのおかげと思っています。すごく感謝しています。

カバレッジモデルを導入してよかったことと感じた課題

前回の記事で最後に、次はNPSについて書きたいと言っていたのですが、NPSをはじめる重要なきっかけとなったカバレッジモデルについて先に触れることにします。

カバレッジモデルとは?

カバレッジモデルは、青い本では、ハイタッチ、ロータッチ、テックタッチという3つのモデルに分けて触れられています。 顧客をいくつかのセグメンテーションに分け、CRE(特にカスタマーサクセス)としてどのようなものをユーザーに対して提供するか(内容や頻度)を戦略的に決めるためのモデルです。 Mackerel では、青い本を参考に、ざっくりと以下のように定義しています。

  • ハイタッチ
    • 四半期〜半期に一度はお伺いしてコミュニケーションする
  • ロータッチ
    • 一年に一度はお伺いしてコミュニケーションする
  • テックタッチ
    • メールや電話、公式イベントなどでコミュニケーションする

上に行くほど、1つのユーザーへのコミュニケーションの頻度や深さが高まり、下に行くほど対象となるユーザー数が増えるというピラミッドの構造になっています。

なぜ導入したか

Mackerel の CRE チームはまだまだ小さいチームなので、残念ながら全てのユーザーにハイタッチを行うことはできません。 Mackerel は BtoB のサービスですが、サーバー台数をベースとした従量課金で少額でもはじめられるため、個人で使っていただいているユーザーもいます。ユーザーによって、1台から数千台と、利用状況はさまざまです。サーバーが1台の環境と、数千台の環境では、システムのアーキテクチャはもちろん、使う人の体制や使っている機能、監視に期待することなども大きく違います。 そういった背景から、すべてのユーザーがハイタッチを求めている、とは限らないだろう、という仮説もありました。

私たちには、ハイタッチないしはロータッチができるユーザーを選択していく必要がありました。 そこで、私は、顧客を売上や利用機能、過去のコミュニケーションの状況などを可能な限り洗い出して一定のルールに従ってセグメンテーションし、カバレッジモデルを導入することにチャレンジしました。 主に私はロータッチを担当し、そのユーザー群に対して、1年に1回は最低でもお会いすること、ということを目標に訪問を続けました。

カバレッジモデルを取り入れるよさ

カバレッジモデルを取り入れて一番変化したのは、ユーザーの訪問が、これまで、少なからず過去の経緯や担当者の感覚に頼って判断して行われていたものが、他の人にも説明しやすい仕方で(とはいえ、ゆるやかに)ルール化されて、一人でも判断して進められるようになったということでした。 また、そもそもこのカバレッジモデルを立てるために行った、ユーザー状況の精査ということによって、自分たちの顧客にはどういった人がいるのか、どういう課題を抱えているのか、ということを知ることができました。 精査する際は、以下のような項目を洗い出しましたが、かなり地道で時間のかかる作業でした。それでも、やってよかったと思っています。

  • 顧客窓口
  • 利用深度
  • 運用・監視の課題
  • 次のステップ --- など

カバレッジモデルを取り入れても解決できなかった課題

カバレッジモデルを取り入れることで、悩まずにユーザーを訪問できるようになりました。ただ、このあたりから私の中で、いくつかの新しい課題が芽生えはじめました。 それは、こちらからアポイントメントをとって訪問するタイミングが、ユーザーにとってほんとうにうれしいタイミングとは限らないのではないか?という疑問です。 というのも、訪問していろいろとヒアリングしていると、以下のようなことをおっしゃるユーザーの方もおられました。

  • 困っていたことがあったけど忘れてしまった
  • 困っていたけど、なんとか自分で解決した(ほかのツールで解決した)
  • 今後頼るかもしれないが、今はまだ困っていることはない --- など

これらのコメントをもらう度、わたしの中には以下のようなことが浮かんでいました。

  • 訪問するタイミングが遅いのではないか?
  • もっとユーザーが求めるタイミングでコミュニケーションできたほうが、有意義なのでは?

訪問のような濃い、かつお互いのコスト(時間)がかかるようなコミュニケーションをしているのに、ポイントをはずしているのではもったいない、という気持ちになりました。

NPSへのモチベーションの高まり

こういうことがあって、私の中で、NPSを取得することへのモチベーションがじわじわと上がっていきました。つまり、ユーザーの状況を正しく理解して、ちょうどよい、痒いところに手が届くタイミングで訪問したい、という気持ちが高まったのです。NPSが顧客の状況を正しく知るための、一つの指標になりうると考えはじめました。

実際には、Mackerel のユーザーの状況を正しくつぶさに知るための指標は、これ以外にも多くあります。じゃあなぜNPSからはじめたの?ということろをお話したいのですが、今日はこの辺りまで。次の記事に続きます。