B-log

コンサル→ベンチャー。ビジネス系のネタ。

「ロジックで説得できない」時にコンサルが教えてくれない論理思考の基礎 :"sein"と"sollen"

世の中のロジカルシンキング研修・本において、全く触れられないことがものすごく不満な内容があります。
 
それは"sein"と"sollen"の区別です。
 
「ロジックで相手が説得できない」みたいな時に、この考えを知っていることは役に立つと思っています。
 

世の中には、2種類の命題がある

そもそも、命題には2つの種類があります。
  • sein命題(「である」の命題)
  • sollen命題(「すべき」の命題)
seinとsollenはドイツ語で、英語に直すと"be"と"should"でしょうか。
 
そして重要な話として
基本的に、「である」をどんなに積み上げても「すべき」を論証することはできません。
 
具体例で解説すると
  • 「である」命題 :「あのラーメンより、このサラダの方がカロリーが低い」 →証明は可能。
  • 「すべき」命題 :「ランチにはサラダを食べるべき」 →どんなに事実を積み上げても厳密な証明はできない。
という話です。
 
ラーメンよりサラダがカロリーが低いとしても、それに加えて「カロリー摂取は控えるべき」「痩せるべき」とかいう、他の「すべき」命題を前提としないと、「サラダを食べるべき」にたどり着かないからです。
そして「痩せるべき」を論証するためには・・と無限ループに陥ってしまいます。
 
「いや、俺不健康でもうまいもん食って死にたい」と言われたら終わり。
 
ロジカルシンキング本によく書いてある「ファクトベースで考えろ」が実は通じないわけです。
 
大学で論理学とか哲学を習うと、このseinとsollenの区別について何らか触れられることが多いと思います。
が、コンサルとかビジネスのロジカルシンキングには、なぜか出てこない。
 

なぜ、「である」と「すべき」の区別が問題にならないのか

ビジネスの世界で、「すべき」「である」の区別が問題にならないのは、
前提にできる「すべき」があるケースが多いからだと思います。
 
例えば、売上向上の施策を巡って
  • 商談数を増やす施策を打つべき
  • いや商談数より受注率を上げる施策を打つべき
みたいな対立は、表面上は「べき」の議論が対立です。
しかし、その上位にある「売上を向上させるべき」には相違がなくて、その先の話で意見が対立しているだけです。
 
なので、
  • 商談数を増やす方が売上が上がる
  • 受注率を上げる方が売上が上がる
という「である」命題に置き換えて、論理的に議論することが可能です。
 
上位にある「すべき」命題を共有できるケースでは、「すべき」命題は「である」命題に置き換えて論証ができそうです。
 

「すべき」と「である」の区別が問題になる時

問題となるのは、上位の「すべき」命題を共有できないケースです。
 
代表的なケースは、2つあると思います。
 

会社レベルで、対立する「すべき」命題が両方成立するケース

1つめは、会社レベルで、対立する「すべき」命題が両方成立するケースです。
 
例えば、
  • 人事評価は公正にすべき
  • 人事評価は効率的にすべき
は、両方成立する会社が多いと思います。
 
しかも、両者は「どちらを何割重視する」とか「こういうケースでは公正さじゃなくて効率が優先する」みたいな固定的な基準がありません。
「なるべく効率的にすべき」みたいなゆるい方向だけがあって、他の要求(例えば、他のタスクの優先度などなど)とのバランスで、時と場合によってそれぞれを尊重しながら「いいバランス」を追求することが求められます。
 
固定的な基準がないので、バランスの問題、もしくは価値観・意思の問題になってしまうのです。
 
このことに無自覚に
「人事評価は公正にすべき。だからこうするべき。」みたいな一本槍の理屈を構築すると、高確率で説得に失敗します。
 
ちなみに、先ほどの「商談数を増やす施策を打つべきか/受注率を上げる施策を打つべきか」というケースも、「売上を上げるには」という一つの軸をベースにして良い議論であればシンプルな「である」の議論にできるのですが
もし「短期の売上と長期の売上、従業員の働きやすさ、どれを重視すべきか」みたいな次元で対立があるとすると、ちょっと話がややこしくなりそうです。
 
 

個人と会社の「すべき」が対立するケース

「である」と「すべき」の区別が問題になる2つめは、個人と会社の「すべき」が対立するケースです。
 
ここで気をつけなくてはならないのは、
  • 個人が何かする/しないの判断軸は、会社の何かする/しないの判断軸と厳密に重なることはない。
  • だけど、表立って会社の判断基準と違う判断基準を個人は主張しにくい
  • しかも個人の判断軸はマトリックスで判断できるような二次元じゃなくて、0か1かでもなくて、ものすごく多層構造・多次元で曖昧な判断が行われている。
という3点から、
本当は単に「やりたくない」場合でも、表面的には「うまくいくわけない」みたいな形で反論として出てくることが多いです。
 
例えば、
(俺もマネージャーだし組織の方向に動かなくちゃいけないのはわかる。でも、正直これをやると部下のXXは反対しそうだなぁ。あいつとはいい関係を保ち続けたいんだよな。あと、俺も子供小さいから早く帰りたいしなぁ。とはいえ、そんなの部長に言うのもアレだしなぁ。やりたくないなぁ・・。報告書のデータ、正直細かくてよく理解できてないんだよなぁ、、。今更確認するのも恥ずかしいし。てか、今回の施策ってよく考えたら2年前に失敗したアレに似てない?そうだな、うん、似てる気がする。まぁ、今回の方が緻密に練られてるのは間違えないけど)2年前にやった施策と同じです。コンサルに2千万も払って。そんなんじゃ効果ないと思います。」
みたいな。笑
 
これ、表面上は「2年前にやった施策と同じです」って言ってるから、そうじゃないことを説明すればいいように見えるのですが、
実際上は腹の底で最初のsollenが微妙に食い違ってるから、どんなにデータを使っても説得できない可能性が結構あるのです。
 
そして、どんなに事実を積み重ねても個人が持っているsollenそのものを否定することはできない。
 
さらに、個人の意思決定構造ってのはコンサルがよく使うようなマトリックスで説明できるほどシンプルな話じゃない。
二軸なんてことは稀だし、しかも「どの軸を何割重視する」なんて単純な話じゃない。
 
こういう複雑さを無視して、
「会社はこうやった方が儲かるから、従業員たるお前はこうやるべき」ってロジックを振りかざしてもうまくいかないわけです。
 

補足:「すべき」命題にも2種類ある

上記では省略しましたが、実は「すべき」の命題にも、2種類あると言われています。
「原理」と「規則」と呼ばれるのですが、具体的には
 原理:個人の意見は尊重されるべき
 規則:期日の12月末までに決定すべき
みたいな話です。
 
わかりやすいのは「規則」です。違反してるのかしていないのかが明確にわかります。12月末までに決まったかどうかだから。
 
他方で、「原理」はわかりにくいです。「個人の意見が尊重されるべき」に違反してるかは簡単にはわからない。
もちろん、無限に一個人の意見を尊重する(その人の言う通りにする)ことはできますが、そうすると、反対の意見を持っている他の個人の意見が尊重されなくなるし、それ以外の原理(例えば「組織運営は効率的にすべき」)が損なわれる。
 
そんなこんなで、すべき命題の中でも「原理」としての性格を持っているものは、0or1で判断できないため、巷に溢れてるマトリクス思考的な安易なロジカルシンキングとは相性がとっても悪いです。
「あっちが立てばこっちが立たず」であり、その状況に応じた「バランス」が求められるからです。そしてそのバランスの根拠もまた価値観であるため…という感じです。
 
とはいえ、ビジネス実務では、どっかに多くの人が共有できるポイントはあるわけで、それを注意深く探り当てるのがミソだと思います。 
 

まとめ: "sein"と"sollen"を区別し、相手のsollenを注意深く理解する

そんなわけで、
  • 誰かを説得するときは、相手に「〜〜すべき」を要求している
  • 「〜〜すべき」は、事実を積み重ねても究極論証できない
  • 会社レベルで、相反する「すべき」を持っていることもある。
  • 個人の「すべき」の基準は、価値観によって異なるし、超複雑。ゆるい方向感しか示されないことが多いし、どんなに事実を積み重ねてもその人がそういう価値観であること自体は否定できない
  • 他方で、共有できる「すべき」の基準があると、「すべき」の議論もスムーズにいく。
  • ので、相手の「すべき」の基準・構造を、表面にとらわれず注意深く読み取ることが大切
  • その上で共有できる「すべき」の基準から議論を始めて、妥当な着地を探るプロセスが大切なんじゃないか
という話でした。
 
いずれにせよ、"sein"と"sollen"という2つの命題の違いについて自覚的になることは
ビジネスでロジカルシンキングを使いこなす上で、意外と大切な第一歩になる気がしています。
 
-
 
「ロジックで説得できない」現象に対して、コンサル出身者や経営企画が「現場はロジックじゃ動かないからね」みたいな言い方で片付けることがちょいちょいあり、
「むしろお前がseinとsollenの区別というロジカルシンキングの基礎に無自覚過ぎるんだよ!」と悪態をつきたくなることがあったので書いた記事でした。
 
 

 

 

営業出身者が企画系にチャレンジする上での3つのポイント

セールスの現場の人や、カスタマーサクセスの中でもやCSMと呼ばれる現場の人と話すと、結構キャリアに悩んでいる人がいます。
特に若手で、「いつまで営業の現場にいるのか」「このまま営業Mgrになるのか」みたいな悩みを聞くことが多い。
 
そんな悩みを持つ方にエールを送るエントリーです。
 

営業の経験は、事業運営に役に立つ

前提として、セールス職自体価値がありますし、
セールスの経験は事業を運営する上でとても重要(マーケや事業企画に行っても役に立つ)だと思っています。
 
セールスの経験は事業を運営する上で重要となる理由は2つあります。
 
-
 
1つめは事業の根本である「顧客理解」の方法が身につくこと。
これについては、コンサル出身の方が書いた この記事 がとてもわかりやすいので引用します。
 
事業ってすごい色々な角度で見て、自分が持ついろいろな引き出しを開けて、組み合わせて、ようやく筋がいい施策だったりが見つけられるもの。フレームワーク、なにそれおいしいの?状態です。
 
コンサル志望の学生が嫌う、泥臭く地を這って顧客を理解してきた営業出身者のほうがよほど事業企画、開発ができるのです。
 
なぜなら、事業とはすなわち顧客理解に他ならないからです。世の中の理解ではなく、顧客理解がキーだと僕は思っています。
1週間かけて現場のヒアリングした経験?そんなもんで理解できるなんて考えは甘い。
顧客理解は、顧客観察であって、ヒアリングではない。ヒアリングしても見える本質には限りがあると。
本気で売ろうとしてこそ得られる顧客理解があり、
事業とはすなわち顧客理解に他ならないからです。
 
 
2つめは、単純に自身のセールススキルが、事業責任者として「奥の手」になること。
事業責任者は、当然損益責任を負います。
「今期どうしても黒字にしたい」「あの大手アカウントを落とすと、市場から退場させられるリスクがある」みたいな場面で、
最後の最後にトップセールスで売り切る能力があるのとないのでは、事業としての仕上がりが全く変わります。
 
そんなわけで、営業の経験は事業運営に役立ちます。
 

営業出身者が企画系にチャレンジする上での3つのポイント

とはいえ、セールス出身者が全員、事業企画やマーケティングあるいは事業責任者として活躍するかというとそうではない。
では、活躍しやすいのはどんな人か、という点について、少し考えてみました。
 
色々ポイントはありますが、ここでは大きく3つのポイントを紹介したいと思います。
 

ポイント1:1対1で勝てること

 
大前提として、セールスの基本である1対1での営業力がある方が、他のキャリアでも活躍しやすい気がします。必須ではないけど。
それは、上述の「営業出身者が事業企画等として活躍できる理由」(=①顧客理解スキルがある、②究極自分で売れる)を、セールスで成果出している方ほど満たしている可能性が高いからだと思います。
 
また、セールスで成果を出す方というのは概してバイタリティが高く、事業企画や事業責任者には高いバイタリティが求められる、という点も影響しているかもしれません。
 

ポイント2:1対1の勝ちパターンを抽象化・型化できること

 
ただし、1対1で勝てるだけだと、セールスとしては成功しても、なかなか他のキャリアで成功しづらい気がします。
 
もしセールス以外でキャリアを形成するなら、
自分の勝ちパターンをいい塩梅で抽象化・型化できることが必要だと思います。
 
「こういう顧客の場合はこうする」みたいな自分の勝ちパターンを、粗すぎず・細かすぎもせず、いい塩梅で型化できる方はセールスとしても結果の再現性が保てますし、マーケティングや事業企画等のポジションでも成功しやすい気がします。
 

ポイント3:抽象化したものを、たくさんに適用できる形に仕立てられること

 
自分の勝ちパターンを抽象化できても、それだけではバリューは発揮できません。
それを、複数の顧客に適用する形に「仕立て」られるかというのが、セールスから事業企画等へのキャリアチェンジのポイントになります。
 
ここが苦手な人は、少し外の会社のビジネスとかを勉強するだけで、一気にここがブレイクスルーされたりケースがあると思います。
 
意外とここでつまづく人はいて
すごく体系化された顧客理解やセールスとしての引き出しは持っているのですが、「仕組みに仕立てる」という発想が持てない。
仕組みに仕立てようとすると、当然自分が営業の現場に立つ時には考えにくい副作用のようなものが発生します。例えば、「XXという顧客にはすごく効く施策が生まれたけど、それをやることでYYという顧客のロイヤルティが下がる。」みたいな。
この辺に配慮しながら仕組みに仕立てる発想が持てないと、自分の勝ちパターンを抽象化・型化できたとしても、何も現実を変えられれず「いや、会社はほんとはこうすればいいんだよ」と評論家的に言うだけでの残念な人になってしまいます。そういうベテラン営業、たまにいませんか?
 
-
 
セールス組織が一定規模以上になると、プロセス管理やセールスイネーブルメントが進化します。
それ自体は組織として望ましいのですが、プロセス管理やイネーブルメントが強烈になってくると、
「1対1の勝ちパターンを抽象化」するのはイネーブルメントやセールスフォースの仕事になってくるし、
「抽象化したものを、たくさんに適用するような形に仕立てよう」という発想が現場のメンバーから弱まってくる気がします。
そうなると、現場の若手メンバーにキャリアが開けにくくなるし、結果として組織に元気がなくなり、中期的には弱体化が進む気がします。
なので、経営サイドには、セールスメンバーにこのような発想を持つ余裕を持たせる努力をしてほしいし、
現場の若手には、大変なのはわかるけど、こういう発想にチャレンジし続ける気概を持ってほしいなぁ、と思います。
この辺、リクルートって会社はすごいですよね。
 
 

営業職に幸あれ

セールスやカスタマーサクセスの現場の仕事って、結構大変なこと多いです。顧客接点なので、まぁ色々言われる。
他方で、利益を生んでる人たちであるのは間違えなく、企業において、もっと尊敬を集めていい仕事だと思います。
でもなんとなくスタートアップが一定規模以上になると、セールスの現場(特に若手)に元気が無くなっていく気がしていて、それを悲しくみていました。
 
そんな若手にエールを送りたく、この記事を書きました。
セールス自体も価値ある仕事で、好きならそのまま続けてもいいと思うし、
徹底的な顧客理解につながるセールスの経験は、セールスはもちろん様々なキャリアにつながる(かつ、コンサルとか企画上がりの奴ら(と敢えて言う)には持ち得ない)営業出身者に稀有な経験です。
 
素敵なキャリアを歩むきっかけになればとても嬉しいです。
 

ヘルススコア設計と運用のポイント [カスタマーサクセス]

日本でも一般的になりつつあるカスタマーサクセス。
以下では、カスタマーサクセスのヘルススコアの設計・運用で満たすべきポイントについて、考えをまとめていきたいと思います。
  

そもそも何の為にヘルススコアが存在するのか

ヘルススコアについては色々なところで語られていますが、その目的について端的にいうと、
  • 解約を予測し
  • 効率的なサポートを提供する

ためのものです。

※ヘルススコアはエクスパンド(アップセル・クロスセル)にも時折使われますが、一旦それは横に置いておきます(後述します)。
 

ヘルススコア設計のポイント

上述のヘルススコアの目的に照らすと、ヘルススコアが満たすべき要件はシンプルです。
すなわち、
  • 解約を予測できる指標であること
  • サポートによりコントロール可能であること
の2点がヘルススコアの満たすべき要件です。以下、詳述していきます。
 

解約を予測できる指標であること

まず絶対押さえるべきなのは、「解約を予測できる指標であること」です。
 
ヘルススコアが解約を予測するものである以上、
解約の先行指標として最も切れ味が鋭いものが、ヘルススコアとして採用されるべきです。
 
分析がうまくできない場合、
  • そもそも、このプロダクトは顧客のどんな課題を解決するためのものか?(顧客はなぜこのプロダクトを買うのか)
  • そのための理想的な顧客体験はどうなっているのか?
  • どういう理由で辞める顧客が多い?
と言った基本をプロダクトオーナーやCSMに問い直すと、定量分析にあったっての仮説構築ができると思います。
特に「顧客はなぜこのプロダクトを買うのか」の問いは強力です。多くのケースで、この問いの裏返し、すなわち「購入の目的が達せられなかったから」というのが基本的な解約の理由となるからです。
 
「解約を予測できること」というのは大変シンプルな話ですが、色々考えているうちに意外と忘れがちな基本です。色々な人が否定しづらい色々なことを言ううちに様々な要素がヘルススコアにまぎれ込みがちです。例えば、「カスタマーエクスペリエンスの観点も大切だ!」とか言われると否定しづらい。
しかし誤解を恐れず言えば、解約との関係が証明できない指標はヘルススコアにとって不純物です。不純物はなるべく避けて、まずは「解約を予測できる指標であること」を第一にヘルススコアを考えた方がいい。
 

サポートによってコントロール可能であること

ヘルススコア設計でもう一つ見落としがちなポイントは、「サポートによってコントロール可能であること」です。
 
コントロールできないものは含めない
例えば、男女・エリアなどで解約率が異なるとしても、それらの属性は変えることはできません。
 
ヘルススコアは、それをコントロールすることで解約を防ぐためのものですから、
コントロールできないものは、ヘルススコアそのものとして採用しない方がいいと思っています。
 
もちろん、変化しない属性が解約を大きく決めることもあると思います。
その場合、変化しない属性情報はヘルススコアそのものではなく、ヘルススコアのセグメントの切り口としてその属性を用いるのがいいと思います。
 
例えば、こういうことです↓
  • エンタープライズ(大企業)もSMB(中小企業)もヘルススコアの指標は同じだが、基準値が違う ※男女で標準体重が違うのと同じイメージ
  • 製造業はXXをヘルススコアとするが、サービス業はYYをヘルススコアとする
 
ただし、分けすぎるとオペレーションが追いつかなくなるので、組織のオペレーションレベルに応じて「いい塩梅」で分けることが求められます。
 
複雑すぎるのもダメ
あまり複雑な指標もコントロールができません。
 
代表例がAIを活用した解約予測です。
データが豊富な企業であれば、データサイエンティストに依頼して機械学習・AIを活用すれば、高精度で解約を予測するモデルの構築が可能だと思います。
しかし、AIで作成したモデルは各特徴量(変数)がどのように結果に効いているかわかりにくいことも多い。
例えば、100の特徴量(変数)を統合してAIが算出した解約リスクのスコアをヘルススコアとして採用すれば、解約を予測する精度は抜群かもしれません。が、現場のカスタマーサクセス職が100の指標のうち何から手をつけたらいいのかわかりづらく、結局オペレーションに活きない気がします。経営層もヘルススコアがなぜ悪いのかが直感的にわかりづらくなる。そうなると「解約を下げる」というヘルススコアのそもそもの目的が達せられない。
 
もちろん、複雑なヘルススコアでも緻密なオペレーションを構築すればコントロール可能です。
しかし、SaaS/スタートアップのセールスオペレーション・組織は日々変わるわけです。緻密なオペレーションを維持できるイメージがあまり湧かないです。
(とはいえ、機械学習による解約予測自体は有効なので、活用余地は色々あると思っています。)
 

フレームワークはどう使うか

他方で、カスタマーサクセスのヘルススコアに関するフレームワークも紹介されるようになってきました。
例えば、2020年に出された超名著「カスタマーサクセス実行戦略」では”DEAR framework”を紹介しています。
すなわち、
  • Deployment :最適な利用条件の充足度
  • Engagement :顧客との関係値
  • Adoption :プロダクト・サービスの利用率
  • ROI :費用対効果
という観点から、ヘルススコアを設計するという考え方です。
 
こういったフレームワークは、あくまで観点を提供してくれるものですので
  • データがない時
  • データがあっても分析の仮説がうまく立たないとき
に使うのが良いと思います。
 
ただし、それでも「解約を予測できること」がヘルススコアの基本であることは変わりません。
そして、「そもそも顧客はなぜこのプロダクトを買うのか?」の裏返しを素直に考えれば解約を予測する指標は自ずと明らかになるケースが多い気がします。
フレームワークは予備的な役割でいいと思っています。
 

ヘルススコア運用上のポイント

ヘルススコア設計ができても、ヘルススコアが運用にしっかり乗って成果をあげるには意外と時間がかかります。
そこで、ヘルススコア運用にあたって、ぜひお勧めしたいダッシュボードが2つあります。
  • ヘルススコア別解約率
  • ヘルススコア別顧客構成比
です。
 
グラフイメージの方が早いと思います。
こんな感じです。

f:id:f-bun:20201019222054p:plain

f:id:f-bun:20201019222129p:plain

順に説明していきます。

 

ヘルススコア別解約率

ヘルススコアがちゃんと運用に乗るには「ヘルススコアが信頼されること」が何より大切です。
ヘルススコアの目的に照らすと、ヘルススコアが信頼されるには「ヘルススコアが解約を説明すること」が大切です。
なので、例えばRED / YELLOW / GREENの3つにヘルススコアを分類した時に、
ちゃんと「ヘルススコアGREENになれば、解約しにくいんだな」が納得性を持って示されることが重要です。
それが「ヘルススコア別解約率」。

f:id:f-bun:20201019222054p:plain

「ヘルススコア別解約率」は、ヘルススコアの信頼性を伝える
このグラフをことあるごとにカスタマーサクセスチーム内外に発信し続ければ、ヘルススコアは徐々に浸透していきます。
 
さらに、ヘルススコア別解約率をモニタリングし続けることで、
ヘルススコアが通じなくなった時に気づくことも可能です。
例えば、新機能のリリースなどでプロダクトの提供価値の構造が変わってくると、「ヘルススコア別解約率」でYELLOWの解約率が下がって、GREENと交差することもあり得ます。
そうなると、ヘルススコアが解約を説明する切れ味が鋭くなくなってきているということなので、要注意の状態です。
 
例えば、上記グラフで黄色と緑のグラフが交差するようだと、ヘルススコアが解約を説明できていない可能性があるので要注意の状態と言えます。(下グラフの状態)

f:id:f-bun:20201019222359p:plain

GREENの解約率がYELLOWよりも高くなっている状態。この状態だと、ヘルススコアが機能しなくなっている可能性がある。

ヘルススコア別顧客構成比

加えて、「ヘルススコア別顧客構成比」もモニタリング加えると、ヘルススコアをターゲットとしたカスタマーサクセスの活動がどれくらい効果を出しているのか見ることもできます。
カスタマーサクセスのヘルススコアへの介入がうまくいっていれば/セールスが「正しい顧客に売ろう」の原則を貫けていれば、ヘルススコアGREENの顧客比率が上がっているはずです。

f:id:f-bun:20201019222129p:plain

ヘルススコア別構成比は、顧客全体の健康状態を示す
 
上記の「ヘルススコア別解約率」と「ヘルススコア別顧客構成比」のグラフを定点的に見続けることで、ヘルススコアは社内で信頼を勝ち取っていきます。
 

補足:アップセル・クロスセルをヘルススコアにどう組み込むか

以上、カスタマーサクセスのヘルススコアについて、解約率を上位指標にした場合の説明をしてきました。
他方で、ヘルススコアをエクスパンド(アップセル・クロスセル)の指標として使いたい、という企業もあるかと思います。
 
端的にいうと、
ヘルススコアは解約予測のためのものにして、アップセル・クロスセルの指標は分けた方がいい」
というのが個人的な見解です。(これはかなり異論もあると思います)
 
というのも
  • 解約を予測する指標と、エクスパンド(アップセル・クロスセル)のしやすさを予測する指標は必ずしも一致しない
  • 解約を予測する指標にそれ以外の指標が混在すると、管理がしにくくなり、結局ワケがわからなくなる
からです。
 
アップセルについていうと、
例えば、従量の概念があるプロダクトでの上位プランへのアップセルは、解約のヘルススコアでスコアが良い顧客をターゲットにするとうまくいくことが多いと思います(使ってるほど従量が高くなり、ヘルススコアがよくなるし上位プランに移行しやすい)。特に、データ量やトランザクションの量によって料金が決まるようなタイプのプロダクトはこれが顕著だと思います。
こういうケースは、解約予測の指標とエクスパンド予測の指標が同じになるからわかりやすいです。
しかし、
同じアップセルでも、例えば従業員数自体が増えないと上位プランにアップセルできない(アカウント数課金のケースを想定)とかだと、ヘルススコアとアップセルのしやすさは必ずしも一致しないと思います。
 
クロスセルについては、
商品特性にもよりますが、クロスセルのしやすさと解約を予測する機能利用が一致しないケースがあることは容易に想像つくと思います。もちろん、「ヘルススコア高い→ロイヤルティ高い→クロスセルしやすい」という図式は成立することが多いのですが、それ以上にクロスセルのプロダクトが顧客の課題にフィットするかという方がずっと大切です。
とすると、クロスセルのしやすさをヘルススコアに組み込もうとすると、新たな指標を追加する必要が出てきます。
新たな指標を追加すると、解約のヘルススコアで説明した、シンプルなグラフが濁ります。
 
ヘルススコアが何を意味するのかがわかりにくくなり、オペレーションマネジメントが難しくなる。
 
それだったら、アップセルやクロスセルの指標は別立ててで管理した方が良い(そして多分、それをヘルススコアと呼ぶ必要はなくて、単純にクロスセルのセグメンテーション・ターゲティングの問題になると思う)、ということになろうかと思います。
 

まとめ

ヘルススコアの設計・運用は、カスタマーサクセスの組織に関わる人が最初にぶつかる課題の一つかと思います。
世の中的には色々なフレームワークが紹介されていますが
  • 設計上は、解約を予測できるか & コントロールできるか にフォーカスする
  • 運用上は、ヘルススコア別の解約率&顧客構成比 をウォッチし続ける
  • エクスパンド(アップセル・クロスセル)は別管理にする
あたりが、原則の原則として大切なのではないか、と思っています。
 
 

関連

 

 

 

能力開発の必読書「成人発達理論による能力の成長」解説 [ダイナミックスキル理論と目標設定]

能力開発の領域で、大変な名著だと思うのですが、なぜか広く知られていない気がする本を紹介します。
 

成人発達理論による能力の成長 ダイナミックスキル理論の実践的活用法

 

日々出くわす以下のような問題は、本書を読めば、結構な割合で解消されます。
  • 自分の能力開発目標に何書いたらいいのか分からない / メンバーが自分で書けない
  • ロジカルシンキング能力を鍛える」って目標が達成された試しがない
  • 能力等級で、一度昇格させた人間を降格させる説明がうまくできない
個人的にはとんでもない名著だと思っているのですが、
難しそうなタイトルのせいか、あまり知られていない本な気がするので、内容を一部紹介してみたいと思います。
 
ちなみにこの本、タイトルは難しいですが
  • 節ごとに要約がある
  • 「成長レシピ」と題して、一つ一つの理論に即したワークが紹介されている。(それを自分でもやってみる/部下にやらせてみるだけで、実際の成長を促せる)
という親切な本です。
 

「成人発達理論による能力の成長」の一部要約解説

この本の目次は、以下の通りです。
序章 自他成長を促す「知性発達科学」
第1章 「ダイナミックスキル理論」とは
第2章 大人の能力の成長プロセス
第3章 自他の能力レベルを知る
第4章 既存の能力開発の問題点とその改善法
以下では、この本の理論的根幹をなす「第1章 『ダイナミックスキル理論』とは」の内容を簡単に紹介しつつ、
オススメポイントについて触れたいと思います。
 

「成長」は2種類ある

本書は、「なぜ人と組織は変われないのか」のロバート・キーガン教授の発達モデルを引用して、人間の成長には2種類あるとします。
すなわち
  • 人間としての器(人間性や度量) の成長
  • 発揮する具体的な能力(スキル) の成長
です。
そして、「2つの成長は相互に独立したものでありながらも、相互に影響を与えあって」いるとします。
そのため、「私たちが全人格的に成長するというのは、器の成長と能力の成長が掛け合わさった時に初めて実現されます。」とします。
 

「スキル」の成長はダイナミック(動的)である

その上で、本書は「スキル発達」について
私たちの能力は、多様な要因に影響を受けながら、ダイナミックに成長していくものである
というダイナミックスキル理論の立場に立ちます。
 
ここでいう「ダイナミック」とは、直線的でも階段状でもなく、うねうねと伸びていくということです。
 
図示するとこんな感じです。

f:id:f-bun:20200831184201p:plain

「ダイナミックな成長」とは
 

「スキル」の発達は、網の目のような性質を持つ 

その上で、スキル及びその発達は、「網の目」のような性質を持つ、と主張します。
ここでポイントは、網の目のスキルは、総体として作用する装置であり、相互に作用し、「レベル感」があるということです。

f:id:f-bun:20200831184248p:plain

「網の目」としてのスキル
「網の目」の概念は、直感的にはわかりにくいのですが
  • 能力は、複数のサブ能力の総体である
  • 能力は、相互に作用しながら発達していく
  • 能力には、レベル感がある
というあたりが、この例えのミソかと思います。
 
例えば、「リーダーシップ」という能力についていうと
  • 「リーダーシップ」という能力は、「ビジョン構築力」「統率力」「部下育成力」...といった能力の総体である(この「リーダーシップ」の要素となる能力を「サブ能力」と呼ぶ)
  • これらの能力(や周辺能力)が相互に作用しながら発達していく(「ビジョン構築力の次は統率力を身につけて...」と一つ一つクリアしていくタイプのものではない。しかもビジョン構築力と統率力は相互に影響しながら発達する)
  • 「リーダーシップ」は、ある/ないの二元論ではなく、レベル感がある
ということです。
 

「スキル」は、以下の3つの性質を持つ

そして、本書はスキルは以下の3つの特徴を持つとします。
  1. 環境依存性 :外部の環境により、能力発揮レベルは変わる
  2. 課題依存性 :取り組む課題により、能力発揮レベルは変わる
  3. 変動性   :自身のコンディションにより、能力発揮レベルは変わる
 これらが、スキル成長のダイナミックさをもたらしている原因だとします。(後述の「能力開発で大切なこと」とセットで理解いただくと良いと思います)
 

網の目としての特徴、及び3つの依存性からスキルの成長はダイナミックになる

上述の通り、ここでいう「ダイナミック」とは、直線的でも階段状でもなく、うねうねと、伸びていくということです。
 
発達の仕方との関係でポイントを補足すると、下図のようになります。

f:id:f-bun:20200831184546p:plain

ダイナミックな成長
なお、ここでは意図しない変化を「ノイズ」、意図した変化を「変動性」と読んでいます。
 

「最適レベル」「機能レベル」「発達範囲」

上述の特徴
  1. 環境依存性
  2. 課題依存性
  3. 変動性
という特徴から、能力の発揮レベルは3つに分かれます
  • 最適レベル :他者や環境からのサポートによって発揮できる、自分が持ってる能力の最も高度な発揮レベル
  • 機能レベル :他者や環境からのサポートなしで発揮できる、自分が持ってる能力の最も高度な発揮レベル
定義から「最適レベル」と「機能レベル」には、常に差が発生します。この差を「発達範囲」と言います。
図示するとこんな感じです。

f:id:f-bun:20200831184743p:plain

「最適レベル」「機能レベル」「発達範囲」
 
そして、フィッシャーの研究で面白いのが、発達範囲は年齢を重ねるごとに、このギャップ(発達範囲)が拡大していくということです。
大人になれば他者の支援を必要しなくなるのではなく、むしろ高度な能力を獲得するためには、他者からの支援が不可欠ということです。
 

能力開発で大切なこと

以上から、能力開発にあたっては、以下が大切になります。
  • 「網の目」「深さ」レベルを意識すること、サブ能力に注目すること
  • ノイズや変動をもたらす要素に自覚的になること

大切なこと① 「網の目」「深さ」レベルを意識すること、「サブ能力」に注目すること

例えば、「リーダーシップ能力を高めたい」といった時に、
スキルの「網の目」状のイメージを持って、必要な「リーダーシップ」のサブ能力や深さレベルを見極めることは有益です。
 
より具体的に言うと、深さとしてどのレベルでリーダーシップを持って組織を推進できるようになりたいのか。その深さを前提とした時に、強化が必要なサブ能力は、「ビジョン策定能力」なのか、「戦略構築力」なのか、「対人コミュニケーション能力」なのか。「対人コミュニケーション能力」だとして、どういうタイプの人とのどういう「コミュニケーション能力」なのか、など。
「網の目」「深さ」「サブ能力」を意識することで、より効果的な目標設定ができるようになります。
 

大切なこと② ノイズや変動をもたらす要素に自覚的になること

能力の発揮は、
  1. 環境依存性
  2. 課題依存性
  3. 変動性
という特徴を持ちます。
 
とすると、まず振り返りをするときは、
どういう環境・課題・変動性の中で自分が能力を発揮できたか自覚的にならなくてはならない(他の環境・課題・変動性の中で同じ能力が発揮できるとは限らない)、と言うことになります。
 
能力開発をするときも、
例えば単に「リーダーシップを身につける」よりも、「リーダーシップ」という能力を「信頼性獲得力」「ビジョン構築力」「統率力」「指導力」などのサブ能力に分けた上で、
「今のマーケチームのメンバーで、リードの倍増という課題を前提に、信頼性獲得力を高めることで組織としての成果を最大化する。そのために〜〜〜」みたいに、具体的な環境・課題を置いた上で目標設定をした方が、能力開発も進むし期末の振り返りもうまくいくと思うのです。
 
なお、ここで、ノイズや変動は成長のスパイスとして扱われます。
例えば、同じ環境・課題と向き合っているだけだとスキルの成長は限定的になります。
しかし、環境や課題が変わると、これまでのスキルは通用しなくなる。その代わりに、スキルひとつひとつの要素が強化され、網の目の性質を持つスキルがより強固なものになっていくイメージです。
 

実務での応用

以上は、「成人発達理論による能力の成長」の内容のごく一部です。
実際の本では、上記のような特徴を持つスキルを発達させる方法についても語られています。
 
ただ、上記で紹介した内容だけでも
  • スキル成長の「ダイナミック性」
  • 「網の目」「レベル」「サブ能力」
  • 「環境依存性」「課題依存性」「変動性」
といった、実務でとても役立つコンセプトが示されていると思っています。
これらを理解することで、例えば以下のような応用が可能です。
 

ケース:「ロジカルシンキング能力を高める」という能力目標

例えば、目標設定の場面でロジカルシンキングができるようになる」「商談力を高める」とかいう類の能力開発目標、よく見かけますよね。でも、達成されたの見たことありますか?
 
私個人はこういう目標を見飽きてうんざりしているのですが、これまで、こういう目標の問題は「SMART(要は後から測りやすい)を満たしていない」ことだと思っていました。
 
でも「成人発達理論による能力の成長」を読んで理解したのは、
ロジカルシンキング能力を高める」という目標設定の問題点は、そんな目標設定の書き方の問題ではなく、もっと本質的なところに問題があったということです。
すなわち、ロジカルシンキング能力を高める」という能力目標の問題は、「ロジカルシンキング」というスキルの環境依存性・課題依存性・変動性を無視して、能力の網の目・レベル感という特性も無視してサブ能力に注目していないことにあると思うのです。
 
では、どうすべきか。
こういう目標が出てきたときは「環境依存性」「課題依存性」を意識して
  • どういう状況で
  • どういう課題について、
  • どういうことができるようになりたいのか
いくつか具体例を文章にする、というアプローチが大変有効です。
このプロセスをメンバー側が踏むことで、一気に目標設定に「血が通った」感が増します。
状況・課題が特定できたら、能力の「網の目」「レベル」「サブ能力」という性質に注目して、必要な能力をサブ能力に分解していきます。
振り返るときもスキル成長の「ダイナミック性」を前提に、様々な外部の要素も考慮しながら何故できた/できなかったのか、今後再現性が担保できそうなのはどのレベルなのか、というのを切り分けて振り返ることができます。
 
 
これ以外にも、「環境依存性」「課題依存性」を理解すれば、能力等級における降格で生じる「俺の能力が下がったっていうのか?」という問題にも一定の対応が可能になるなど、結構実務的に役立つコンセプトだと思います。
 

能力開発・目標設定にオススメの名著

以上、「成人発達理論による能力の成長」の内容の一部を紹介しつつ、オススメポイントを解説しました。
難しそうなタイトルのせいか、あまり知られていない本な気もするのですが、大変な良書です。
 
特に、なんとなく「能力って上がっていく一方」と思っていた自分にとって
「能力(の発揮度合い)は、環境や課題に依存しながら、上がったり下がったりしながら発達する」
というダイナミック成長理論のコンセプトとそれに基づいた様々なレシピは、大変大きな気づきと、日々の業務への実益をもたらしてくれました。
 
しかも
  • 節ごとに要約がある
  • 「成長レシピ」と題して、一つ一つの理論に即したワークが紹介されている。(それを自分でもやってみる/部下にやらせてみるだけで、実際の成長を促せる)
という親切ぶり溢れる本です。
 
目標を設定する側の人も、部下の目標設定を手助けする側の人も、一読して損はない良書だと思います。
 

クレームに向き合うカスタマーサクセスに伝えたい3つのこと

カスタマーサクセスが、クレーム対応で傷ついている

カスタマーサクセスには、誠実で共感性が高い人がたくさんいる

カスタマーサクセス職が日本でも広がっています。
カスタマーサクセスの教科書として知られる赤本では、カスタマーサクセス職は
①引く手あまた!
②カッコいい!
③豊かな人生を送る!
なんて書かれています。
 
そして、そんな素敵なカスタマーサクセス人材の要件の一番目として
共感性(Empathy)が強い
という点が掲げられています。
 
確かに、カスタマーサクセスは「仕事だから」ではなく、人の役に立つのが好き・頑張る人を助けたい・貢献したいという基本的な欲求に突き動かされている人が活躍しているイメージがあります。
カスタマーサクセス・プロフェッショナル」著者のルーベン・ラバゴ氏が、あるイベントで「カスタマーサクセスの魅力は、IT業界の真ん中で、極めて人間的な仕事であること」みたいな趣旨のことを言っていたこととも重なります。
 

他方で、カスタマーサクセスはクレームと隣合わせ

他方で、カスタマーサクセス(特にCSM(カスタマーサクセスマネージャー)と呼ばれる人)は、顧客接点です。
なので、顧客からクレームを突きつけられることもあります。
 
比較的早い時期に日本にカスタマーサクセスを紹介した資料として有名な「カスタマーサポートのことは嫌いでも、カスタマーサクセスのことは嫌いにならないでください」では、
カスタマーサクセスの役割を
 × クレームを処理する
 ○ 顧客と話す
としています。
 
カスタマーサクセスの特徴は「プロアクティブ」な課題解決とされ、リアクティブに顧客のクレームに向き合うことは推奨されていません。
でも、そんなのは理論系・実験室の中の話であって、実際にはAWSが障害を起こせばシステムは止まるし、その結果顧客と契約内容で揉めることはあるわけです。
 

結果として、多くの人が傷ついていく

結果として、多くの人が傷ついていきます。
共感性が高いから、クレームの精神的ダメージをモロに食らう
「お客さんの役に立ちたい」という青臭くも美しい気持ちを持っているから、「こんなプロダクト/会社に自信が持てない、私はこんなことやっていていいんだろうか」と自責の念に駆られます。
もっとも悲しいのは、クレームによって顧客の嫌な面を見て、顧客を愛することもできなくなってしまうことです。
プロダクトも顧客も愛せなくなると、誠実で共感性が高い人はもうそのポジションでカスタマーサクセスはできなくなって転職していくことになります。
 
そんなわけで
  • カスタマーサクセスには、誠実で共感性が高い人がたくさんいる
  • でも、顧客接点だからクレームは避けられない
  • 結果として、多くの人が傷ついていく
という問題が発生するわけです。
 
 

クレームと向き合うカスタマーサクセスに伝えたい3つのこと

IT界隈で、今風に言えばカスタマーサクセスやプロダクトマーケティングマネージャーのような仕事を10年近くしてきました。
カスタマーサクセスとクレームの問題は、気持ちの部分が大きいのでとても難しいのですが、まぁ有り体に言えば一定程度は「傷を舐め合う」ことも大切だと思っています。
 
実際に顧客の意見をどう建設的な問題解決に繋げていくかが一番大切なのは言うまでもありません。
ただし、それについてはカスタマーサクセスの本や各種イベントで語られている気がするので、ここでは敢えて感情論的なことを少し書きたいと思います。
 

①大体どこにだって、クレームはある

カスタマーサクセスの世界では、プロアクティブな問題解決が推奨され、クレームなんてあたかもないかのように語られることがあります。
でも、そんなの嘘です。
  • 昨日のイベントに登壇してキラキラ輝いて見えたあの人も
  • 大型資金調達/IPOしてイケイケドンドンに見えるあの会社も
  • noteで「オンボーディング率が大幅に向上してチャーンが減った」って書いてるあの人も
つい5分前まで、オンボーディング失敗して更新タイミングを迎えた顧客から値引き交渉付きのクレームを受けていたかもしれないし
去年のAWS大規模障害で、休暇中なのにハイタッチの顧客からケータイにクレームが鳴りまくってたかもしれません。
 
自社の落ち度 / 顧客の落ち度 / 第三者の落ち度 問わず、どんなプロダクトだってクレームは起きます。
他の良い部分が、クレームを隠しているだけです。
 
「でも、うちの経営層は成長を優先して、カスタマーサクセスを優先していない」と感じることもあるかもしれません。
そんな時は、青本の第1章を補足説明までよく読んでみて下さい。
理想の世界なら、会社は理想的な顧客だけに販売すればいい。だがもちろん、成長企業には収益を伸ばさないといけないという途方もないプレッシャーがあるものだ。そのため、効果的に成長するには、理想的な顧客の定義を拡大せざるを得ない場合もある。 
第1原則で「正しい顧客に売ろう」と宣言する青本でさえ、「理想的な顧客の定義を拡大せざるを得ない場合もある」という成長企業の宿命を、実は受け入れているのです。
 
クレームが起きるのはあなたのプロダクトだけではないということを、認識いただきたいです。
 

②誰だって、クレームに対応なんてしたくない

共感性が高く、誠実なカスタマーサクセスの人にとって、クレームへの対応は大変なストレスです。
「顧客の成功」という青臭くも美しいコンセプトに心惹かれた人ほど、そのギャップに苦しむ傾向がある気がします。
 
でも、それはあなただけではありません。
 
クレーム対応に慣れていそうな大型コールセンターのオペレーターも
非協力的に見えるサーバーサイドのエンジニアやデータサイエンティストも
一見サイコパスに見える経営者も
いまあなたにクレームを言ってきているクライアントも
 
クレーム対応なんてしたくありません。
それはみんな一緒です。クレーム対応に向いてる人(好きでやってる人)って、実はそんなにいないのです。

③それでも顧客の成功は存在するし、否定されない

そんなわけで、多くのカスタマーサクセスが、隠れてクレーム対応に追われているわけですが、
いま目の前の顧客からクレームを浴びたとしても、
顧客の成功は実在するし、否定されません。
 
先月オンボーディングしたあの顧客の成功も
どうにかリニューアルにこぎつけた大規模顧客も
今クレームを言ってきている顧客がオンボーディングした瞬間に顧客に提供した成功も、
嘘じゃなくて実際に社会に提供された価値ですし、クレームによって否定されません。
 
思うに、クレームはカスタマーサクセスやってると避けられないし、クレーム対応ホント嫌なんですけど、
結局は「それでも顧客の成功が嬉しい」という一点によって、最後顧客接点の仕事ってどうにか続けられるんだと思うんですよね。
 
言い換えると、クレーム受けてる時はすごく嫌な気持ちだと思うんで、仲間内で適度に愚痴り慰め合いつつ
  • どこに行ったってクレームは一定避けられない
  • 誰だってクレーム対応なんてしたくない
ってメタ認知しながら、やり過ごすしかないと思うのです。
その上で、気持ち切り替わったら、次の成功に向かって進めばいいのかなぁ、と。
 
 
 
メタ認知できたら、建設的な問題解決で、クレームと対峙していただければと思います。
まだ気分転換が必要な方は、こんなのもどうぞ。 笑

 

クレームと向き合う気になったら、クレーム対応の本は古いものから色々あるので、読んだ上で場数を踏めば誰でも一定のレベルにはなれます。 

 

 

解説「文系AI人材になる」 :非エンジニアにおすすめの入門書

 
機械学習系のプロジェクトのビジネスサイドのプロマネを何回かやっているため、
非エンジニア・非データサイエンティストから、「AIについて、ちょっと勉強してみたい」という相談をちょくちょく受けます。
 
自分が実務の中で知識をつけてきたこともあり、何をオススメしたらいいんだろう?と悩んでいたのですが、最近は、「文系AI人材になる」という本をとりあえず読むことをお勧めすることにしています。
 
ただこの本、ちょっと読み方にコツがある気がしていまして、それとあわせてご紹介したいと思います。

 

[追記] なんてオススメしているうちに、いつの間にか「文系AI人材になる」が、Kindle unlimitedの対象になっていました!この内容を無料で読めるのはかなりおすすめです。Kindle unlimitedユーザーの方はもちろん、それ以外の方も多分トライアル期間ありで、スマホでもPCでも読めるので、これを機に↑のリンクからどうぞ!

 

「文系AI人材になる」とは

 
「文系AI人材になる」はzozo等でご自身も文系AI人材として活躍されている野口さんという方が書かれた本です。
 
目次的には、以下から構成されています。
第1章 AI社会で職を失わないために
第2章 文系のためのAIキャリア
第3章 STEP1 AIのキホンは丸暗記で済ます
第4章 STEP2 AIの作り方をザックリ理解する
第5章 STEP3 AI企画力を磨く
第6章 STEP4 AI事例をトコトン知る―業種別×活用タイプ別の45事例
第7章 文系AI人材が社会を変える

 

これを一通り読むことで、
  • AIってなんなの?
  • 文系の私は何ができるの?
  • 実際どんなプロジェクトがあるの?
が、ザクっと理解できます。
 

「文系AI人材になる」の読み方

ただこの本、ちょっと読み方にコツが要る気がしています。
個人的には、
  • 1章は、軽く読み飛ばす
  • 2~4章を読んで、内容を理解する
  • 5章は軽く読んで
  • 6章は興味あるところを中心に一通り
  • 7章は、興味あれば
という感じで、2-4章・6章を中心に読むという感じが良いと思っています。
以下、詳細に、章ごとにポイントとオススメの読み方を紹介していきます。
 

1章は軽く読み飛ばす

第1章は、「AI社会で職を失わないように」というタイトルです。AI時代におけるキャリアや「AIと人間の共働き」のスタイルについて語られています。
この内容は大切だし、本の構成上必要だと思います。ただ個人的には、この本にたどり着いて理解できる(そしてその後活用できる)レベルの人であれば、「既になんとなく知っていた」内容が多めな気がします。
なので、軽く読み飛ばす、でいいと思います。この後役たつ内容があるので、ここで詰まっていてはもったいない。
  

 

2~4章をちゃんと読んで理解する

AIについてこれから学習する方は、2~4章を特にちゃんと読んで理解するのが大切だと思います。
この2~4章の内容だけでも、この本は買う価値があると思います。
 
2章は、「文系のためのAIキャリア」という章です。
タイトルは「キャリア」ではあるのですが、その前提として、
  • AIの基本的な作り方/使い方
  • AIプロジェクトのプロジェクトマネジメント
  • AI人材になる
が紹介されているので、ちゃんと読んだ方がいいです。
 
3章は、「AIのキホンは丸暗記で済ます」です。この本で特に秀逸なのは、この章と次の4章ですね。
AI・機械学習を理解しようとすると、複雑な数学が出てきたりして、そこで挫折してしまう人が多いです。
その点、この本はそこを「丸暗記」と割り切ってテンポよく説明してくれます。
「丸暗記」とはいうものの、簡単に仕組みは説明してくれるので、言うほど暗記しろって感じでもありませんし、実務で役立つと思います。
 
触れているポイントも良い意味でスタンダードですし、説明の仕方もわかりやすいです。
 
より具体的には、3章「AIのキホンは丸暗記で済ます」を読むと、例えば以下のような事項が理解できます。
この辺わからないと、実務でデータサイエンティストとは会話できないので、とっても良い内容だと思います。
 
繰り返しですが、AIの学習でつまづくパターンの一つは、数式でつまづく→全体像が見えない→どこが重要かわからない→わからなくてもいい数式でつまづく..のループの途中で挫折するパターンだと思います。
その点、全体像をザクッと押さえられる本章は大変オススメです。
 
 
4章は、「AIの作り方をざっくり理解する」です。
本章もとても秀逸で、タイトル通り「AIの作り方」がざっくり理解できます。
2つくらいポイントがあって
  • データ前処理など、実務上結構問題になるポイントがちゃんと押さえられていること
  • 識別系/会話系/実行系 の分類ごとの作り方が解説されていること
という2点から、とても役立つ内容になっています。
これだけの内容を、これだけポイント押さえて文系にわかりやすく説明できるって本当にすごいなぁ、と感じました。 
 

5章は軽く読む

5章は、「AI企画力を磨く」です。
内容的には、AIを使った諸々の企画のフレームワークや考え方が紹介されています。
確かに、この能力(AIに関する企画力)は間違えなく必要です。紹介されているフレームワークそのものも、類書に比べて良心的かつキレイに整理されているように感じます。
ただし、現時点で「文系AI人材」としてプロマネ等の立場に立つ可能性がある人って、この章で語られる企画能力や思考力はどこかしらで既に磨いてるんですよね。だとすると、本書でそこまで熟読する必要はなくなる。別に読まなくても自分の頭の中に似たものがあるから。
もちろん、今後よりAIが一般的になってきて色々な人がAIプロジェクトに関わるようになってきたり(まさにこの本が想定しているのはそういう世界だと思います)、あるいは二十代前半とかで経験が足りない人は5章も読んだ方がいいと思いますが、
現時点で一定経験がある人は「なるほど、この人はこういうフレームで考えているのね」と、本書を読み進めるのに最低限必要な程度の斜め読みでいいかな、というのが個人の見解です。
 

6章は、興味あるところを中心に一通り

6章は、実際の事例集です。
これは人によって結構参考になるので、興味あるところは読んでみてもいいと思います。
この章の魅力は、たくさん事例が載っているところです。事例が多いので、何かしら興味を持てる事例が載っていると思います。
ただし、そこまで詳しく書かれているわけではないので、何かしら自分で追加リサーチするとより学習効果が出るかもしれません。
(むしろ、基礎から押さえてる本でこれだけ網羅的に事例も載せられるのすごいと思っています)
 
 

7章は、興味あれば

7章は、「文系AI人材が社会を変える」です。
この章も面白いは面白いのですが、自分のキャリアについて考えたい人が読めばいいかなって感じはします。
 
ちなみに、本来本書自体のフレームワークとしては、文系人材になるためには
  1. AIのキホンを丸暗記する(3章)
  2. AIの作り方をザックリ理解する(4章)
  3. AI企画力を磨く(5章)
  4. AI事例をトコトン知る(6章)
というステップが必要である、という構成です。
ただ、上述の通り5章の「AI企画力」のところが、現在この本を手に取る読者の感じからするとちょっと既知な感じがするので、上記のような読み方をお勧めしている次第です。
 
 

非エンジニアがAIを勉強するのにオススメの入門書

「文系AI人材になる」、現時点で類書があまりない良書だと思っています。わかりやすい。
 
感覚としては、むかし自分が数ヶ月かけて身につけた基礎知識を、数時間で習得できるんじゃないかと思うくらいです。
  • なんとなくAIが気になる
  • AIのプロジェクトにアサインされたけど、なんか手触り感がない
  • AIのプロジェクト普通に進められるけど、ビジネスサイドの人に説明するのが面倒
みたいな方は、一読の価値があるんじゃないかと思います。

地方拠点とカスタマーサクセス

2020年、コロナの諸々がなければ、もっと話題になっていただろうなぁと思うカスタマーサクセスの話題があります。
それは、「カスタマーサクセスの地方拠点問題」です。 

「カスタマーサクセスの地方拠点」が話題になる土台が整ってきた

そもそも2010年代、「カスタマーサクセス」という名前の組織を持って、この職種をリードしてきたのは東京のSaaS系スタートアップでした。
まだ会社自体も単一拠点のことも多く、日本において「カスタマーサクセスの地方拠点」という論点はそこまで共通の課題としては取り上げられてきませんでした。
 
しかし、2020年現在、その状況は変わりつつあります。
 
第一に、カスタマーサクセスを牽引してきたSaaSのスタートアップのビジネス・組織が拡大してきました。その結果、地方企業もその顧客に多く抱えるようになってきました。さらに顧客層も様々になってくる中で「おたくは来てくれないの?」と言われる機会も増えてきたと思います。地方顧客との向き合い方が問われるようになってきました。
 
第二に、元々全国規模で営業組織を張り巡らしている大きな会社が、カスタマーサクセス組織を導入するようになってきました。そうすると、従来の「営業部大阪支店」とカスタマーサクセス組織の関係が問題になってくるようになってきました。
 
結果として、カスタマーサクセスの地方拠点が話題になる土台が整ってきたように思います。
 

具体的なカスタマーサクセスの地方拠点のあり方

では、カスタマーサクセスの地方拠点はどのようにあるべきでしょうか?
 
前提として、「わざわざ地理的に(顧客の近くの)地方に作る」わけですから、
カスタマーサクセスの地方拠点の使命はテックタッチやロータッチではなく、ハイタッチ寄りになるのが、素直な発想な気はします。
 
その上で、敢えてパターンを考えれば、3つくらいのパターンがあると思います。
 

パターン1:ハイタッチの純粋カスタマーサクセス部隊

1つ目は、「ハイタッチでカスタマーサクセスだけをやる部隊」を地方に置くパターンです。
これは一番シンプルです。イメージとしては、東京で成果を出したCSM+若干名を立ち上げメンバーとして派遣して、そこでCSM部隊を立ち上げるイメージでしょうか。
大阪に本社がある顧客を対象に、オンボーディングやらを担当する部隊が出来上がりそうです。
難点を挙げるとすると、「カスタマーサクセス専属で、地方にそんなに人材置けない」という企業は多そうです。
また、意外と「大阪支店として」のマネジメントが難しくなることがあるのがこのフォーメーションの難点です(セールスの長とCSの長がいるわけですから、両雄並び立たず的な。逆にセールス置かずにCSだけで地方拠点作るオプションもあるんですかね...あまり想像つきません)。
 

パターン2:セールスもカスタマーサクセスもやりますよ部隊

そこで2つ目は、「セールスもカスタマーサクセスもやる部隊」です。
1つ目との違いは、組織図上「大阪支店・カスタマーサクセスグループ」を作らない、という点です。一つのチームでセールスもカスタマーサクセスも担当させます。
ヘッドカウント少なく柔軟にやれるのが、このパターンの魅力です。
そもそも東京においても「エンタープライズではフィールドセールスとカスタマーサクセス分けてない」という組織設計も多く、特にそういった組織においては、この選択肢も結構現実的だと思います。
難点を挙げるなら、スタートアップにそれだけの(セールスもカスタマーサクセスもバランスよくこなせる)人材をちゃんと地方拠点で採用・リテンションできるのか、というのは課題として残るかもしれません。
あるいは、伝統的に営業が強く、文化としてのカスタマーサクセスが定着していない組織でこのフォーメーションやると、セールスに力点が置かれすぎて「カスタマーサクセスってなんだっけ?」ってなることもありそうですね。なんか2年後とかに組織再編とか起きていそう。
 

パターン3:思い切ってロータッチ・テックタッチも

思い切った3つ目の選択肢は、地方にロータッチ・テックタッチの部隊も作ってしまおう、という選択肢です。
ロータッチ・テックタッチなら究極どこでもできるわけですから、選択肢としてはアリな気がします。実際、地方にカスタマーサポート部隊を置いていた会社が、カスタマーサポート部隊を発展させる形で、結果としてこういうフォーメーションを取っているケースとかもありますね。
ただし、難点はヘッドクォーターやプロダクトとの(物理的)距離が空いてしまうことです。これはこれでマネジメント上の課題がありそうです。プロダクトフィードバックとかも、ちょっと精度落ちそうですね。この辺は、会社としてのリモートワークへの考え方や定着度にも依るかとは思います。
ただ直感的にですが、この3つ目のパターンは、安易に採用すると特に上手く行きづらいと思います。実際こういうフォーメーション取っている会社も存じ上げてはいるのですが、難易度高い気がします。プロダクトや会社全体の方針と連動させてカスタマーサクセスの理念や方法論がちゃんと根付くのがちょっと大変かなぁ、と。
 

まとめ

アメリカとは地理的状況・交通事情も商慣習も異なる日本において、「カスタマーサクセスの地方拠点」がどう発展していくのかは、まだまだこれからの論点だと思います。
さらにコロナでオンライン商談の(特に顧客側への)普及が一気に進んだという特殊事情が加わって、この論点は少し読みづらくなった気がしています。
 
ベースになるパターンは上述の通り3つくらいな気がしていますが、会社ごとの事情もあると思うので、結構悩ましい論点だなぁ、と。
今後の議論・プラクティスに注目したいと思っています。