ヤマムギ

growing hard days.

*

持ち帰って欲しいもの

   


カスタマーサクセス Advent Calendar 2018」にお誘いを受けまして、自分にとってのカスタマーサクセスとは、というのを見つめ返してみました。

私の役割の遍歴は、
* 事業部門でお客様への業務をしながら自分たちのツール開発
* お客様企業が使うソフトウェアの開発
* ユーザー企業IT部門
* ITインストラクター
なので、お客様と一言で言ってもスコープはさまざまなのでゴールもそれぞれかなと感じております。

カスタマーサクセスについて、もちろん仕事をする上で意識して当たり前なのですが、特別に書籍を読んだり、テクニックを学んだりしたことは皆無なので、思っていることだけを書きます。

頼られてなんぼ

すべての仕事は、誰かに何かを頼られ、その成果に対しての対価を受取ることだと思います。
成果がなければ報酬がないこともあります。
ソフトウェア開発をしていた時代に会社がなくなってしまい無給の期間があったので、報酬が当たり前だという感覚がそのときになくなりました。

何を頼られるかというと、課題に対しての解決です。

課題→解決、とすると
* 作業をして欲しい→作業をする
* 宿泊したい→部屋を提供する
* お腹が空いた→食事を提供する
* 手作業によってミスが起こる→自動化する
* 手作業によって残業している→自動化する
* 効率よく知りたい→学ぶ場の提供
* 知らない世界→新しい世界の提供
などなど

どんな仕事においてもこの依頼者の課題を受けた側が解決する、というのが仕事なのかなあと思います。

なので、課題のある人にいかに頼られるか、ということはすごく重要なことだと感じています。
「話しかけにくい」
「機嫌が悪そう」
「言ってもむだ」
「怒られそう」
「理解してもらえない」
など
ネガティブな印象を人に与えるのはそれだけ、仕事を減らしていることにつながるんだろうなあ。
常に人から相談されているぐらいになったほうがいいと思うし、そうならなければと思います。

大きな課題だけではなくて、そのプロセスの中でも小さな課題がそれぞれあって、
その小さな課題のほとんどは声を発することで解決できることが多くあります。
少なくとも黙っていて、解決されることはほぼありません。

なので、
「話しかけやすい」人になる。
「話しかけやすい」環境や仕組みを作る。

すごく大切なことだと思います。

終わらせること!=サクセス

課題が解決されることがゴールなので、そのプロセスはなんでもいいということになります。
ですが、世の中には契約など約束があり、一定の提供を受ければ対価が発生することが一般的となっています。
でもそのゴールがないままに終わると、次の依頼は減っていくはずです。

では、課題の解決が本当にゴールなのか。
より良いゴールは、その解決によって気づきが生まれること。
そして依頼者のこれからの人生においてのプラス要素を何か提供できることだと考えます。
言い換えるとその結果、感動が生まれるかどうかだと思います。

少なくとも終わらせることはサクセスではないし、終わらせることによって課題がただ隠されてしまうこともあります。
課題の本質的なところは終わらせないというのが正しいのかもしれません。
課題を持ち続けることによって成長し続けます。
終わらせてしまうことは成長が止まるということだとすると、そんなものサクセスではないはずです。

なので、
「終わらせないことで課題を解決し続ける」

落とし所なんて考える必要はないなあ。

サクセスはみんな違う

同じサービス(依頼)を利用した人でもそのサクセスは人それぞれなのではないか。
何に感動するか、100人いれば100とおりのサクセスがあるのでは。
多様性ですね。

「こうすればいい」
というガイドラインではサクセスを得る人と得ない人になる。
個人にあわせたプロセスとサクセスがある。
なので、パーソナライズが必要です。

デジタル化によってパーソナルデータは多かれ少なかれあるので、
それを分析してよりよいサクセスにつなげていく補助はできます。
オンラインのみであればここに注力することが重要かもしれません。

オフラインでこれを実現するには対人経験が必要なはずです。
テクニックだけではどうなるものでもないです。

「どんな人でもこう」
などと言う提供のされ方をして嬉しい人はいません。

過去に
「給与を下げられないからどんなに成果をあげても一気に給与はあがらない」
と言われたときに
「なぜ給与を下げられないのですか」
と聞くと
「一度あがった生活水準をさげることは誰もできないから」
と言われました。
こちらのことを気遣ったように見せる説明ですが、ただの決めつけです。
この考え方を好む人もいるとは思いますが、私は好まないです。

なので、
「同じ課題でもサクセスは違う」

これ難しいので、
まずは「決めつけない」を忘れないようにしたいです。

プロセスよりかはサクセス

サクセスのためにはプロセスはなんでもいいかというと、
なんでもいいけど、どうでもいいということではないと考えます。
ただし、プロセスを重要視するがあまり、サクセスを求められないのは悪です。

学校とかで、
「質問のある人」
として誰も手をあげなかったら放置されます。
これは誰かのサクセスになったのかというと疑問です。

“手を上げて質問をする”
というやり方を知ることはいいことですが、強制するべきではありません。

ここのゴールは不明なことや疑問点を解消することです。
なので”手を上げて質問をする”プロセスはどうでもいいです。

匿名質問も一つの方法です。
結果として質問した人に回答が伝わればいいのです。
もちろん誰が質問したかを知ることによってよりよい回答ができることもあるとは思います。
それでも選択肢は多くあるほうがいいし、質問できない状況を作るよりもなんぼもいいです。

ちなみに認定資格も一つのプロセスだと考えます。
一つだけ言えることは認定資格取得は絶対にゴールではありません。
取得することによって技術や知識のエビデンスになります。
そして頼ってくれる人から見ると、頼るために指標になり、より頼られる可能性が拡がります。

なので、
「より多くのプロセスを用意する」

マインドチェンジ->マインドスケーラビリティ

依頼する側、依頼を受ける側両方ともそうですが、
考える幅が狭いとサクセスにはたどり着けないです。

ある考えからある考えに変化することをマインドチェンジということがありますが、
変化した先の考えに囚われていては、サクセスする機会を失ってしまうかもしれません。

考える幅を広く大きくもつことが必要です。
またいつでも拡げられるようにマインドのスケーラビリティを確保しておきます。

なので、とにかく聞く。
否定的に受け取らない。
自分が絶対的に正しいと思わない。
やってみて確認する。
などなど

ギブ&ギブ

最近武闘派CIOからよく聞く言葉です。
好きです。
好きな言葉で
「利益はあとからついてくる」
という言葉があります。
これと似ています。

利益というのは対価のときもありますし、
“満たされた気分になる”
“技術や知識を身につける”
など、これらも利益といえます。

テイクを求めることに時間を使っているひまがあれば、
ギブをする時間に変えていく。
そのギブが誰かにとって価値のあるものであれば、
利益はついてくるはず。

そして多くの人に頼られる人はギブすることだけで忙しい。

ギブは直接頼られたときだけではなくて、発信してもいいです。
アウトプットです。

それがどこかで誰かの何らかの課題を解決することにつながればいいですし、
解決するかどうかは、受け取る側次第です。
なので発信する前から、後の評価をあまり考えすぎてもよくないです。
アウトプットを続けていればそのうちつながります。

少なくとも私はさまざまなテイクにつながっています。

「今は無理でも
いつかは見つかる
今は無駄でも
いつかはつながるさ
自分信じて
奇跡は起こせる
明日を信じて
無限の可能性
おまえの可能性
おまえの可能性」

THE STAR CLUBのYOU CANの歌詞です。
控えめに言って最高です。

個人のファン=組織のファン、組織のファン!=個人のファン

ある人のファンはその人が所属する組織のファンにもなります。
組織のファンはその組織に所属する個人のファンにはそのままではならないです。
これが健全なかたちだと思います。

その人のファンなのに組織のファンにならないという現象は、その人が組織に貢献していない場合起こりやすいと思います。
単純に好きな人が好きなものは好きになるってことです。

組織のファンだからといって個人のファンになるかどうかはその人次第です。
私は特に肩書だけで人を見たくはありません。

では、どうすればファンになってもらえるか。
知ってもらわなければ好きも嫌いもないです。
とにかく知ってもらうことが必要です。
なのでアウトプットです。

会社の都合でアウトプットし辛いという方もおられるかもしれません。
でもなぜアウトプットしないのかは不思議です。
すべてアウトプットという話ではないです。

出せる情報はあるはずです。
アウトプットもなく好きになってもらえることはないです。

定量と定性

お客様のサクセスをどう知るかです。
ここでKPIという言葉が出てくるかと思います。
気をつけないといけないなあと思うのは、2年ぐらい経ってはじめて傾向が見える数値情報だけに頼ってはないかという点です。
1年目の平均がこれぐらいで2年目と比較するなどです。
年で締めているとこうなります。
失敗や間違いに気づくのが圧倒的に遅れます。
なので、定量数値はリアルタイムに進捗や傾向を追うことが必要です。
そして定量数値を追うことは機械が得意です。

定性を測ることが出来るのが人間です。
定性結果の裏付けに定量結果を用いることもあります。

数字は重要ですが、最後は人対人です。
モノとモノではありません。
ならば定性を測るのか、というかなんのために定性を測るのか。
きっとホスピタリティとその結果だと感じます。

なので思いやりですね。
そしてその思いやりが間違えていないか。
失敗していないか。
これも人によって受け取り方は多種多様なのでやってみるしかないですね。
でもやって見る前に、想像しないとですね。
思いやりの押し付けにならないようにしなければ、
その行動は押し売りになっちゃいますね。

無反応の罪

誰に対してもそうですが、気をつけていることとして、
完全な無反応にならないようにしようということです。

何か反応しようと。

無反応というのは自分のためにもならないのですが、
もっと大きな罪を生みます。
それは人のやる気を奪うという大きな罪です。
(否定的な反応もやる気を奪いますが)

何をしても無反応で、いいも悪いもわからなければ、そのうち何もしなくなります。

「受け身だ」
「積極性がない」
「自主性がない」
と言っている人は特に、
誰かの何かの発信があったときにちゃんと反応しましょうね。
他の人たちが反応する環境を作りましょうね。

無反応な世界に何かを発信する人はいません。

持ち帰って欲しいもの

なんだかんだ書いてきましたが、
私が今ITインストラクターとして持ち帰って欲しいと思いっているもの。
それは端的に言えば知識ではなくて知識の使い方(知恵)です。

知識 < 知恵
知識よりも知恵につながる何かを持って帰ってもらえればと思います。

昨日までの非常識は新しいスタンダードになるかもしれません。
今日得た知識は、明日必要なくなるかもしれないです。

知識が大切でないということではないです。
知恵のためには多くの知識が必要です。

知識を得る方法も一つの知恵です。

楽しみながら知識を得ることは重要です。
印象に残りやすいからです。
子供の頃に感動したことをふとしたときに思い出すことがあります。
これは楽しんで得た感動だったからかもしれません。
THE STAR CLUBの冒険者という名曲の歌詞にもあります。

「生きてく知恵は知識じゃないぜ
子供の頃の遊びの中で
心に書いた宝の地図を落としたあの日手探りすれば
なくした過去にまぶたを閉じれば
なくした自分がまぶたを開いて
小さな冒険心」
掛け値なしの名曲です。

その知識をどう使うかは、それぞれの方々の課題によって変わります。
その課題に立ち向かうために得た知識を使うその力は、
きっと感動によって生まれると信じています。

感動してもらえるトレーニングを実施できるよう精進してまいります。

@yamamanx

開発ベンダー5年、ユーザ企業システム部門通算9年、ITトレーナー2年目のSoftware Engineerです。
質問はコメントかSNSなどからお気軽にどうぞ。
出来る限りなるべく答えます。

このブログの内容/発言の一切は個人の見解であり、所属する組織とは関係ありません。

また、勉強会やイベントのレポートは自分が気になったことをメモしたり、聞いて思ったことを書いていますので、登壇者の意見や発表内容ではありません。

 - event, study

ad

ad

  関連記事

Developers Summit 2018 「自然言語処理・機械学習を活用したファクトチェック業務の支援」を聞きました

以下は、思ったことや気になったことをメモしていますので、必ずしも登壇者の発表内容 …

「MasterCloud-Alexa makes the world a better place-」で登壇しました

クラウド全体を扱う勉強会MasterCloudのAlexaの会で登壇してきました …

「kintone カスタマイズハンズオン」に行ってきました

ハンズオン中のメモです Rest API ログイン認証だとトークン認証で出来ない …

LINEとAWSとTwilioとkintoneでBOTを作ってみるハンズオン (2)LambdaからSlackへ通知する2

作る部分 この部分のLambdaを作成します。 手順1でSlackのIncomi …

「IoTの法律勉強会 第1回」に行ってきました

「IoTの法律勉強会 第1回」に行ってきました。 「関西のIoTを盛り上げよう」 …

「大阪Pythonユーザの集まり」に行ってきました

「大阪Pythonユーザの集まり」 に行ってきました。 あんまりメモ取れてません …

「【Twilio x kintone 合同ハンズオン in 大阪】Twilio Studioとkintoneで電話受付システムをつくろう」に行ってきました

「【Twilio x kintone 合同ハンズオン in 大阪】Twilio …

MySQL勉強会 in 大阪(第10回)に行ってきました

MySQL勉強会 in 大阪(第10回)に行ってきました。 オプティマイザー、G …

「JAWS-UG in AWS Cloud Roadshow 2017 大阪」で運営をしました

AWS Cloud Roadshow 2017 大阪のナイトイベントで、「JAW …

第17回 人工知能研究会 「今後のDeepLearning技術の発展とビジネス応用」に行ってきました

第17回 人工知能研究会 「今後のDeepLearning技術の発展とビジネス応 …