「ECRSの原則」とは ：業務改善は、最初に「やめる」を検討する
ECRSの原則とは、業務に対する改善を
- Eliminate（やめる）
- Combine（他と一緒にやる/分けてやる）
- Rearrange（順番や担当者を入れ替える）
- Simplify（簡素化 / システム化）
の4つに分けて、1から順番に検討していきなさい。
というものです。
最大のポイントは「順番」
ここで最大のポイントは、「順番」です。
特に、
最初に「やめる」がきて、
最後に「システム化」来る
ということです。
必ず、最初にやめるを検討する
「やめる」が最初に来るべき理由は２つあります。
①一番カイゼン効果が大きいから
②目的が明確化されるから
①一番カイゼン効果が大きいから
業務削減効果が一番大きいのは、その業務自体を「やめる」ことです。
改善幅が必ず100%になるから。
さらに、カイゼン実行に必要な色々を考えなくて済むので、
カイゼン活動自体も効率化されます。
②目的が明確化されるから
ただ、実際の業務はそう簡単にやめられるものは少ないです。
それでも、絶対に最初に「やめる」を本気で検討すべきです。
なぜなら、その業務本来の目的が浮かび上がってくるからです。
そして、実はここがECRSの本当のミソ。
目的がないところで業務改善はあり得ない
実際、コンサル時代、お客さんに
「この業務、やめたら困ります？」
と聞いてました。
そうするとお客さんは
「そりゃ困るよ。だって・・・。」
と、答えます。
実はこの回答を待ってたりします。
この「だって・・・」こそが、その業務が存在する本来の目的だからです。
そうすると
- その目的は、本当に必要なのか？
- その目的に対して、今のやり方は正しいのか？
- その目的だったら、他の業務で代替できるのではないか？
と、具体的な改善策に切り込んでいけることが多い。
そもそも、目的ないところで改善策なんて、本来考えられっこないのです。
あらゆる業務は、何かの目的のために、人が作り出したものなのだから。
業務の目的の確認抜きで業務改善の議論をすると、ほぼ例外なく過剰/過少品質になります。
そして経験上、
「この業務の目的は？」と聞くより
「この業務やめたら困ります？」と聞くほうが
本質的な目的が見えることが多い。
だから、最初に「やめられないか」と問う。
実際「やめる」という最短ゴールを模索しつつ、
業務を残す場合の改善議論のキモとなる「業務の目的」を確認することが、大切なのです。
あとはご自由に。ただ、システム化の原則は最後。
業務の目的が明確になったら、もう８割は成功です。
なので、正直
2.Combine（他と一緒にやる/分けてやる）
3.Rearrange（順番や担当者を入れ替える）
4.Simplify（簡素化 / システム化）
の内容とか順番まで、多くの人は覚える必要はない。
ただ、一つだけ留意するなら、
「自動化・システム化は最後に検討」です。
これには２つ理由があります。
①自動化・システム化には時間・コストがかかる
②自動化・システム化すると、「悪いやり方が固定化」する
昨今、理由の①は成り立たなくなりつつありますが、
②とか、傾聴に値するなぁ、と私なんかは思います。
「自動化しちゃえばいいじゃん」ではなく「やめればいいじゃん」
ITベンチャーに勤めてると、条件反射的によく
「そんなん自動化すればいいじゃん」
という話になります。
でもその前に、ちょっとだけ
「てか、そもそもやめちゃわない？」
と問いたい。とってもいいことがあると思います。
なぜ、あの部門は「残業なし」で「好成績」なのか? 6時に帰る チーム術
- 作者: 小室淑恵
- 出版社/メーカー: 日本能率協会マネジメントセンター
- 発売日: 2008/12/30
- メディア: 単行本
- 購入: 8人 クリック: 175回
- この商品を含むブログ (75件) を見る
- 作者: 日本能率協会コンサルティング
- 出版社/メーカー: 日本能率協会マネジメントセンター
- 発売日: 2010/02/17
- メディア: 単行本
- 購入: 4人 クリック: 16回
- この商品を含むブログ (1件) を見る
総務部の本当の役割考察 〜理想の総務部は「自らシゴトを作り、自らを切り出す」
意外と共通認識がない「総務の理想形」
総務とか管理部と呼ばれる組織は、世の中にたくさんあるのですが、その「理想形」については、あまり語られることがないと思います。
セールスやマーケ、商品開発などの組織に比べて、「理想形」の共通認識がない気がします。
そんな背景もあり、昔、コンサルの大先輩にふと「理想の総務部って？」という問いを投げたことがあります。
その答えが
「シゴトを作るところ」
というものでした。
聞いた瞬間、「シゴトを作る」という表現に強烈な違和感を覚えました。
が、詳しく聞いていくと、「これはアリかも」と思えるコンセプトだったのです。
自分なりの解釈も追加して、紹介したいと思います。
「理想形」を語るにも共通の議論の拠り所も少ない総務部論（？）において、
議論の一つの出発点としては割と結構いい線行くんじゃないか、と思っています。
結論として、歴史に学ぶと、
理想の総務部は「自らシゴトを作り、自らを切り出す」という話です。
一般的に、総務部は何をしているのか
そもそも、総務部に含まれる機能は、例えば以下のようなものです。
※下の方は、専門の部署がある会社も多いと思います。
- 固定資産・オフィス管理
- 消耗品管理、備品管理
- 文書管理
- 社内システム運用
- 受付・来客対応
- 慶弔対応
- 福利厚生
- 会社行事運営
- 社内広報
- 社外広報
- リスクマネジメント
- 株主総会・IR
ポーターのバリューチェーンの支援活動の「色々」のうち、
① 少量で部門として切り出すほどじゃないもの
② 業務として定義しにくいもの
を総務部がやっている、と捉えるのがわかりやすいと思います。
その具体例が、上で挙げたような業務なのだと思います。
自らシゴトを作り、自らを切り出す：歴史に学ぶ強い総務部
上述の通り、総務部と呼ばれる組織の仕事は、ポーターのバリューチェーンの間接部門の「色々」のうち、
① 少量で部門として切り出すほどじゃないもの
② 業務として定義しにくいもの
と考えられます。
しかし、
① 少量で部門として切り出すほどじゃないもの
→組織の成長・変化や世の中の変化で重要課題となって業務量が増えてくると、この定義に当てはまらなくなってきます。
② 業務として定義しにくいもの
→世の中の変化で専門分野として確立してくることで、業務の定義できるようになってくるとこの定義に当てはまらなくなってきます。
という感じで、時代や組織の変化に伴い、状況は変わります。
これは、世の中の組織図の歴史（あるいは会社の成長）と重ねて考えると理解しやすいです。
総務がシゴトを作るとき
例えば、40年前の会社組織図を想像すると、「情報システム室」なんてない会社がほとんどだったはずです。
ところが、コンピューターの普及によって、コンピューター・情報システムの調達・運用機能が会社に必要になってきた。
初期においては、総務部が、世の中の変化や社長・事業部の「コンピューター使いたい」みたいな話を受けて、実際に導入しながら、会社として必要な調達・運用のルールや資産管理方法などを作っていったのではないかと思います。
もし当時、受け身で「コンピューター」というポテンヒットを拾うにとどまらず
時代の動きや自社の事業への鋭い洞察をもとに、むしろ積極的に、役員や事業サイドに先回ってコンピューター導入を議論して、役員や事業サイドを説得し切って、事業成果まで繋げた総務部があったとしたら、
それは、理想に近い総務部だと思うのです。
つまり、外部・内部の変化を見逃さず、必要な課題とこれまでにない業務を定義して、経営成果を最大化するという意味で「シゴトを作れる」総務部は強い。
（追記）
2020年のコロナウイルスの対応でも、総務部の対応分かれた気がします。リモートワークや職域摂取を積極的に仕掛けられたかとか。受け身にならず、いい意味で自分から「シゴトを作る」ことで従業員やビジネスを守った総務部があるんじゃないかと思っています。
総務が自らを切り出すとき
「情報システム室」の例を続けます。
さらにコンピューター普及が進む中で、業務の規模と重要性が増えてきたはずです。
例えば、一人一台パソコンを持つようになり、インターネットが普及しセキュリティなどの課題も増えてきたかもしれません。
これくらいのタイミングで、総務部から切り出す形で「情報システム室」みたいなのが生まれた、そんな歴史をたどった会社は多かったはずです。
（同じようなことが、中小企業が大きくなる過程でも発生すると思います。例えば、中小企業で「法務」「IR」などの領域が、総務部（管理部）から独立する過程は、想像がしやすいかと思います。）
自ら作り出したシゴトに対して、専門化を進めれば、業務はより明確に定義できるようになります。
また、そのシゴトが時代を先取りしたものなら、必然的に少しずつ重要性と業務量は増えていくはずです。
そうなると、だんだん冒頭の「総務部」の定義にある「少量」「定義しにくい」という枠に収まらなくなってきます。結果として、自らを切り出して別部署とする瞬間が来るのです。
つまり、会社や世の中の流れを汲んで専門化を進め、最後は別組織化するという意味で「自らを切り出せる」総務部は強い。
自らシゴトを作り、自らを切り出す
このように
- 外部・内部の変化を見逃さず、必要な課題とこれまでにない業務を定義して、経営成果を最大化するという意味で「シゴトを作れる」
- そして、会社や世の中の流れを汲んで専門化を進め、最後は別組織化するという意味で「自らを切り出せる」
という2点が、理想の総務部の重要ポイントという見方が成立すると思うのです。
理想の総務論の一つの出発点
この話は、ベンチャーだと「管理部」と呼ばれる組織の一部にも適用できると思っています。
私は総務の仕事をする人をとても強く尊敬しています。
隣人愛に溢れているから。そして、会社を支えてくれているから。
しかし、世の中一般的にキャリアや働きがいの文脈で「総務」という仕事がポジティブなイメージが持たれているかというと、残念ながらそうでもないと思います。
確かに、古い会社だと「総務は出世ルート」なんて話もあると思います。
でも、なんか多くの人にとって、「総務部の3ヶ年ビジョン」とか、ワクワク感を持って描きにくくないですか？
そんな中、
「自らシゴトを作り、自らを切り出す」
は、総務部の理想形の一つだと、私は思うのです。
当然いろいろな組織があっていいと思うので、絶対的な正解ではないかもしれないけど、議論の一つの出発点としては割と結構いい線行くんじゃないか、と思います。
このコンセプトをスタートとして、具体に落とす中で、総務部がワクワクするビジョンも描けるような気がしています。
おまけ）経営企画の役割も参考になるはず
総務部や管理部と近い組織として「経営企画」なんてのもあります。その役割について考えることも、総務部や管理部の役割を考える上で参考になるはずだと思っています。
ということで、その役割についてもまとめました↓
参考になりそうな本↓
機械学習プロジェクトで、予め精度の保証を求めてはいけない：ビジネスサイドから見たAIプロジェクトのコツ
機械学習のプロマネは、普通のプロマネとちょっと違う
最近、機械学習とかAIを使ったプロジェクトに関わる機会が増えてきました。
世の中的にも、機械学習を使ったプロジェクトは増えているように思います。
自分は機械学習の専門家ではありませんが、
そして、そのような役割の人間からすると
予め精度の保証を求めてはいけない
その一つが、機械学習を使って予測・判断のモデルを構築するプロジェクトにおいて、「予め予測精度の保証を求めてはいけない」ということです。
機械学習を使って、予測モデルを作るプロジェクトで
みたいなやり取りが発生し、ビジネスサイド「それって、どれくらい精度出るの？」データサイエンティスト「やってみないとわからないです」
結果、お互いモヤモヤが残る。
こんな場面に遭遇したことある方、少なくないはずです。
これには、構造的な背景があると思っています。
機械学習プロジェクトの大まかな流れ
そもそも、機械学習のプロジェクトは、大まかに以下のような流れを取るようです。
①ビジネス上の課題定義 ＞ ②データ収集 ＞ ③分析・モデル構築 ＞ ④システム開発 ＞ ⑤運用
今回は、上記の①とか②の段階で「精度を求めてはいけない」という話です。
例えば、「会計ソフトのデータから、倒産リスクを予測する」というモデルを構築するとします。その場合、
「①ビジネス上の課題定義」では、
- そもそもなぜ倒産リスクを予測したいのか
- 「倒産リスク」とは何年後の倒産リスクなのか
- 具体的に、そのアウトプットを使ってどんなことがしたいのか
- なぜ、今の手法のままではいけないのか
などを定義します。
「②データ収集の工程」では
- 考えられる変数（特徴量）は何か
- どういったデータが取得可能か（社内/外）
- それは、過去および未来に渡って、どれくらいの期間取得が可能か
- データ量は、機械学習に十分か
などの検討に加え、実際の学習用のデータを作る泥臭い作業が待っています。
これらを経て、
「③分析・モデル構築」の工程で初めて、様々な試行錯誤を経て、精度XX％の倒産予測モデルが構築されます。
なぜ、事前に精度を求めてはいけないのか
冒頭の
というやりとりは、このプロセスに沿って理解するとわかりやすいです。ビジネスサイド「それって、どれくらい精度出るの？」データサイエンティスト「やってみないとわからないです」
データサイエンティストの言い分
まず、データサイエンティストからすると、
実際、「③分析・モデル構築」の工程に入らないと、精度はわからないことが多いでようです。
これは、単に予防線を張っているわけではなく、実際わからないことが多いようです。
その理由を聞くと
あたりが主要な理由なようです。
ビジネスサイドの言い分
他方で、ビジネスサイドからすると
- そもそも、何らかの施策を打つんだから、投資対効果を知りたい。せめて精度の目処は欲しい。
- ちゃんとスケジュール引きたい。
- 「①ビジネス上の課題定義」「②データ収集」と、「③分析・モデル構築」の初期だけでも、相当時間を投資することになりそう。だから尚更早めに目処が欲しい。
なので「それって、どれくらい精度出るの？」と聞きたくなってしまう。
この２つによって、不幸な行き違いが生まれるのだと思います。
解決の方向
基本的な方向は「３パターンくらい、ゆるく、見立てを共通認識とする」
では、どうするのか。
結論としてお勧めしたいのは、
「楽観 / 悲観 / 中間シナリオ くらいのゆるさで、精度の見立てを分析サイドとビジネスサイドで共通認識として形成すること」
です。
実際、データサイエンティストに聞いてみると、実際は、楽観 / 悲観 / 中間シナリオ くらいなら、経験に照らして見立てを出せるケースが多そうです。
ただし、この見立ては外すことも多そうなので、約束・目標とするのは抵抗があるとのこと。
なので、事前の精度の見立ての必要性に関する共通理解の下、あくまで「見立て」であって「コミットメント」ではないことを強調しつつ共通認識を形成する
そうすれば、（変数の振れ幅大きくて難しいのですが）プロジェクトを設計・遂行できると思うのです。
データサイエンティストに求められること
そのために、データサイエンティストには
- なぜ、精度を予め保証できないのか（上述のような理由）
- 世の中的にもそんなもんだということ（できれば、具体的な事例ベースで）
を、ビジネスサイドに対して（どうか「こいつアホだ」と諦めずに）分かりやすく説明いただけると嬉しいです。
そして、
- ビジネスサイドは、ビジネス上の課題解決にすごいプレッシャーを負っていることへの理解
- ビジネス（特にオペレーションレイヤー）って内部/外部環境のちょっとした変化で打ち手変わるから、リクエスト（課題定義）が曖昧なのは仕方ないこともあることへの理解
- プロジェクト設計上必要なら、「参考程度ゆるい見積」として楽観 / 悲観/ 中間の３パターンくらいで、精度の見立てを提供できること
を示してくれると、もっと嬉しいです。
ビジネスサイドに求められること
逆に、ビジネスサイドの人間としては
- 上述のような理由から、事前に精度を保証させるのは無理っぽいということ
- それは世の中的にもそんなもんで、今自分の前にいるデータサイエンティストの腕が悪いのでは決してないこと
をしっかり理解する必要があると感じています。
その上で、
- とはいえ、ビジネスとしては課題を解決したいこと（その向こうにお客さんや世の中がいること）
- プロジェクト設計はしたいから（「見立てが外れても俺のプロマネ力でどうにかしてみせる！」という気概を持って）「参考程度ゆるい見積」として楽観 / 悲観/ 中間の３パターンくらいでいいから、見立てがほしいこと
を、データサイエンティストに誠実に伝えなくては、と思っています。
そして可能な限り、統計や機械学習の勉強をして、見立ての背景にある変数や、各シナリオの成立条件について理解できるようになりたいと思っています。
（「最初の一冊」には「文系ＡＩ人材になる―統計・プログラム知識は不要」がオススメ）
そうはいうものの、、
ただ、そうはいうものの、こういうコミュニケーションは、現状としてどうしても限界があります。
なぜなら、ビジネスサイドは「数式アレルギー」ある人多すぎるし、
他方でデータサイエンティストは、「正確だが難しい数式」か「過度に簡略化した比喩」や「こういうもんです！」で説明しがちで、「ちょうどいい塩梅」の説明ができる人が少ない（気がする）からです。
なので、その間に立てる人材になれれば、あと５年くらいはバリューの出しどころがあるんじゃないかなぁ、と個人的には思っています。
<<関連記事>>
そもそも「精度」って書いちゃいましたが、ビジネスサイドがなんとなく使う「精度」には色々な意味合いがあります。その辺も解説しました。
ビジネスサイドの人に 「文系AI人材になる」はホントおすすめ
日報から学びにつなげるたった１つのコツ
マネジメント・育成の観点から
メンバーに日報や週報という名前で振り返りを出させることは多いと思います。
それ自体はいいことで、実際、日報を活用して成長するメンバーもいる。
しかし、イケてない日報を書き続けて、成長もしないメンバーもよくいます。
世の中の惜しい日報
例えばこんな感じ
今日は、●●課長と商談に同行しました。一番感じたのは、課長と私の顧客志向の違いでした。私もより顧客志向を意識しなくては、と強く感じました。
惜しい。惜しい。
きっとすごく良い経験をしたんだと思うのですが、全然伝わらないし、
「本当にこれだけ」だったら、たぶん現実は何一つ変えられない。
劇的に改善させる、たった一つの問い「具体的には？」
では、どうするか。
たった一言
「具体的には？」
を納得するまで問い続ければいい。
上記であれば
「顧客志向」とは、具体的にはどういうこと？
→商品ではなく、お客さんのニーズをベースに話をしていた。
具体的に、どこでそう感じた？
→一言目。「今日はお時間ありがとうございます。せっかくお時間いただけたので、まずはなぜお問い合わせいただいたかという点を改めて簡単に伺っていいでしょうか？」と聞いていた。これで流れが決まった気がする。
「意識する」とは、具体的に何するの？
→一言目を意識する。
より具体的には？
→明日のXX様の商談で、とりあえず真似してみる。
ここまでやって、やっと成長につながる学びになる。
成長する若手というのは、文章化するかどうかはさておき、ほぼ例外なくこういうPDCAを、「やりきって」いる。
具体→抽象→具体の学びのプロセス
そもそも、経験をベースにした実際の良質な学び（≠知識）のプロセスは、多くの場合、具体→抽象→具体というプロセスをとります。
先ほどの例でいけば
①気づき「あ、課長の商談は一言目が私と違う」
最初の「気づき」は、超具体的。
②考察「ああ、これは顧客志向の現れだな」
考察・学びは、一回抽象的になる。
③ネクストアクション「明日のアノ商談で、このやり方を真似してみよう」
ネクストアクションは、具体的。
多くの人が自身の活動を文章化するとき、「②考察」だけ文章化する。
「①気づき」の瞬間を省くから、
個人や文脈が失われ、
その辺の本に書いてあるようなつまらない内容になる。（というか、その辺の本の方が当然ずっとよくまとまっているから、それ以下の内容になる）
「③ネクストアクション」を本気で具体的に詰めないから
実際の血となり肉となるような、学びに昇華できない。
「具体的には？」という問いは、この良質な学びのプロセスを強制的に想起させるミソだと思うのです。
ヤフーの1on1―――部下を成長させるコミュニケーションの技法
- 作者: 本間浩輔
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2017/03/25
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
シリコンバレー式 最強の育て方 ― 人材マネジメントの新しい常識 1 on1ミーティング―
- 作者: 世古詞一
- 出版社/メーカー: かんき出版
- 発売日: 2017/09/13
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
HIGH OUTPUT MANAGEMENT(ハイアウトプット マネジメント) 人を育て、成果を最大にするマネジメント
- 作者: アンドリュー・S・グローブ,ベン・ホロウィッツ,小林薫
- 出版社/メーカー: 日経BP社
- 発売日: 2017/01/11
- メディア: 単行本
- この商品を含むブログ (3件) を見る
カスタマーサクセスがサクッとわかった気になるおすすめ情報まとめ（無料＆書籍）
カスタマーサクセス(Customer Success)とは、主に月額課金系のビジネスで
顧客を成功に導く一連の活動や組織を指します。
SaaS・Web界隈で、ここ数年よく使われる概念です。なんとなく、ここ1-2年で、WebやIT系の人にとっては必修科目になった感があります。
自分もSaaS界隈の端っこに身を置く関係で、カスタマーサクセス周辺の仕事もしたことがあるのですが
「ネットでいい情報を探すのが大変。」
と思っていたことがあり、ふと、ライトなリンク集をまとめてみます。
＜目次＞
1.無料編
1-1.カスタマーサポートのことは嫌いでも、カスタマーサクセスは嫌いにならないでください
まず、超名作。
カスタマーサクセスの背景、概念から基本的なポイントをわかりやすく解説。
無料でこんな勉強させてもらっていいの？ってレベル感。「とりあえずこれ読んどけ」としてはとても十分。
商品企画や事業企画の方であれば、
- セールスアニマルになろう スタートアップ初期の営業戦略 （同じ作者のSlide Share）
- Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)
- バリュー・プロポジション・デザイン 顧客が欲しがる製品やサービスを創る
あたりと一緒に読むと、とても理解が進む気がします。
1-2.逆説のカスタマーサクセス
「カスタマーサポートのことは嫌いでも〜〜」と同じマイクロソフト→東大の馬田さん作成のスライド。続編。
同じ方の情報を紹介する形になってしまいましたが、日本語で公開されている無料の情報だと、本当に、群を抜いて良質な情報だと感じます。
ちなみに、この方が書いた本はこれ。これも面白かったです。
1-3. The Essential Guide to Company-wide Customer Success
英語大丈夫な方はこれがおすすめ。
後述「青本」の著者がCEOを勤める会社で、カスタマーサクセスツールトップベンダーのGainshight社の体系的な考え方がわかります。自己診断ツール付。
個人的には、カスタマーサクセス（というかSaaS）界隈ってアメリカが色々先行している関係で、ちょっと英語しんどい人も頑張って英語読むだけで半年分くらいは情報優位に立てること多い気がします。
おまけ
こんなのも作りました。一番サクッと読めると思います。笑
2.書籍編
2-1.カスタマーサクセス――サブスクリプション時代に求められる「顧客の成功」10の原則
カスタマーサクセス――サブスクリプション時代に求められる「顧客の成功」10の原則
- 作者: ニック・メータ,ダン・スタインマン,リンカーン・マーフィー,バーチャレクス・コンサルティング
- 出版社/メーカー: 英治出版
- 発売日: 2018/06/06
- メディア: 単行本
- この商品を含むブログを見る
問答無用の一冊目。
カスタマーサクセス界隈では「青本」とも呼ばれる。必読書。
2018年まで翻訳がなくて、この翻訳が出た時、一気にカスタマーサクセスのコンセプトが、実務レベルで浸透したイメージがあります。
「10の原則」でまとめられているので、自分のビジネスに適用するときのチェックリストっぽく使えるのもポイント。
（追記）逐条解説＆紹介を書いてみました
2-2.カスタマーサクセスとは何か
カスタマーサクセスとは何か――日本企業にこそ必要な「これからの顧客との付き合い方」
- 作者: 弘子ラザヴィ
- 出版社/メーカー: 英治出版
- 発売日: 2019/07/03
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
これも必読。「青本」に対して「赤本」と呼ばれる本です。
「青本」がアメリカで書かれた本の翻訳なのに対して、「赤本」は日本で書かれた本です。
「〜とは何か」系の本って、抽象的なことも多いですが、この本は実務的に使える知見にあふれています。事例も日本だし。特に第２章の「カスタマーサクセスとはいったい何か」あたりは、実務的示唆にあふれ、参考になる部分多いのではないかと思います。
2-3.the MODEL
THE MODEL(MarkeZine BOOKS) マーケティング・インサイドセールス・営業・カスタマーサクセスの共業プロセス
- 作者: 福田康隆
- 出版社/メーカー: 翔泳社
- 発売日: 2019/01/30
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
これも問答無用系の必読書。
SaaSにおけるマーケティング〜インサイドセールス〜セールス〜カスタマーサクセスという、一連のプロセスのエッセンスがギュッと詰まった本。
カスタマーサクセスの前行程などに広げて全体像を理解したい人は必読。
2-4.サブスクリプション――「顧客の成功」が収益を生む新時代のビジネスモデル
サブスクリプション――「顧客の成功」が収益を生む新時代のビジネスモデル
- 作者: ティエン・ツォ,ゲイブ・ワイザート,桑野順一郎,御立英史
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2018/10/25
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
この本の著者はZuoraという会社の創業者。
Zuoraという会社は、カスタマーサクセスをサポートするSaaSを提供している会社です。
そういう（カスタマーサクセスが流行ると儲かる）バックグラウンドだと、「自分のビジネスの宣伝でしょ」と捉えられるかもしれませんが、中身は面白いです。
読んだ人の間で盛り上がったのが、ギターメーカー「フェンダー」の事例。
カスタマーサクセスの事例は、正直SaaSとかWeb界隈が多い中で、市場が縮小傾向にあったギターメーカーがオンライン教育動画サービスを提供して・・と、月額課金ビジネスへと変貌していく事例は、Webとかベンチャーからちょっと遠い人たちにも、良いインスピレーションを与えると思う。
あとは、サブスクリプション・マーケティング――モノが売れない時代の顧客との関わり方とかもありますが、個人的にはこっちの「サブスクリプション」の方が好き。
2-5.CRM―顧客はそこにいる
- 作者: 村山徹,三谷宏治,アクセンチュア,CRMグループ,戦略グループ
- 出版社/メーカー: 東洋経済新報社
- 発売日: 2001/07/01
- メディア: 単行本
- 購入: 5人 クリック: 39回
- この商品を含むブログ (16件) を見る
敢えて2001年と古い本。
カスタマーサクセス以前に流行った概念”CRM”について、日本語で書かれた良書。
流行りの概念は、一つ前の概念と比べて理解するのがポイントだと思うのですが、この本は、CRMとカスタマーサクセスの差分を理解するという意味でもおすすめ。
3.終わりに
ここ数年で、「カスタマーサクセス」というワードを耳にする機会がグッと増えた気がします。
加えて、「青本」の翻訳出版により、月額課金の（もしくは月額課金にしたいと考えている）事業に身を置いていると、この辺は「もはや必修科目でしょ」って感があります。
現に、元々はその道のプロではない私も、+αの勉強と多少の実戦機会に恵まれています。
その割に、ネット上で良質な情報にたどり着くのが難しい気がしてまとめてみました。
PDCAサイクルよりYWTサイクル
YWTサイクル・・何の略だと思いますか？
Y：やったことW：わかったことT：次やること
まさかの日本語。笑
最初このフレームワーク（？）を聞いたときに、
「なんだ、PDCAサイクルの焼き直しか」
と思ったのですが、
実は、味わい深い、ミソがたくさん詰まったフレームワークなのです。
<目次>
YWT最大の特徴：最初にYが来る
PDCAサイクルとYWTの最大の違いは、Planの有無です。
YWTには、Planに該当する概念がない。
その結果として、
YWTにおける「わかったこと」は
「（予定外も含めて）やったことすべて」を受けて、学びを抽出していく。
PDCAでは、Planが最初に来る。
なので、PDCAを正しく使うと、
PDCAにおける学び（Check）は、
基本的に、仮説(Plan)と実行(Do)の結果の差分にフォーカスされる。
逆に仮説外から学びは抽出されにくい。
PDCAは、あくまで仮説ありきで、それと差異にフォーカスするのに対し、
YWTは、やったこと森羅万象から学びを引き出そうとする（逆にフォーカスはしない）。
なんというか、日本的。
「PDCA」ってぶっちゃけ使いにくくないですか
今や、新卒でも「高速でPDCAを回していきたいです！（キラッ）」とか言います。
私も、会社で「PDCA回していきましょう」とか言います。
でも、本当にPDCA高速で回せる人って、結構いい会社でも、二十代で10%もいない。
それには、以下の３つの構造的な理由があると思うのです。
①Planがない仕事だって、ぶっちゃけある
そもそも若手の仕事では、本当の意味でPlanをさせてもらえないことが多い。
例えば、新人研修一つ一つについて、「この講座で何を学びたいか」とかのディスカッションさせてもらえない。
「黙って受けろ、ばか」の世界です。
そして配属されたところで、まずは簡単な「業務=Do」が落ちてくることが多い。
そもそもPが欠落しているのです。でも日々も業務（Do）は積もっていく。
②知識がない人が立てるPlanなんてトンチンカン
もちろん、一つ一つの業務(=Do)の中でも、小さいPDCAを回すことは可能です。
背景・目的を頑張って理解した上で、自分なりのプランを都度立てていけば。
実際、若くして成長する人って、こういう基本動作がしっかりしてますよね。
ただ、実際はちゃんと背景や目的を理解するのは大変です。
Planの背景には、いろいろな知識が前提になっていることが多いから。
しかし、背景まで丁寧に教えてくれる先輩なんてそうそういない。
多くの人は、自分で背景を理解するために一つ一つ知識をインプットする時間も能力もない。
逆にそんな状況で、頑張って仮説(=Plan)立てたところで、
知識がない状態で立てる仮説なんてトンチンカン。
仮説がトンチンカンなんだから、学びもトンチンカンになりがちです。
③そんな状況で、標準的な地頭力で使いこなせるほどPDCAは簡単じゃない
さらに、そもそもPDCAのPって、ちゃんと検証できるように立てないとダメです。
これ、ビジネス実務に適用するには、ちょっと慣れが要るんですよね。
地頭がそこそこないと、最初から使うのは無理。
結果として、こんがらがる
つまり、
状況下で、「PDCA回せ」を要求すると、なんかこんがらがっちゃう。①Planがない②Planを立てる知識がない③特筆すべき地頭もない
それを直す（これまた標準的な地頭の）指導役も、どこから直して良いのかわからない。
そんな目も当てられない状況に、よく出くわします。
さらに最悪だと「PDCA回せ」って言われて、
考え過ぎて行動量自体が極端に減ることで、
一番大切な「やってみて学ぶ」機会自体を逸失していることもあります。
だったらYWTでいいじゃん
だったらいいじゃん、特に新人はYWTで。
「素直な新人」みんな好きでしょ。
悪口じゃなくて、実際「素直さ」って、成長のための大きな才能だと思うのです。
それを、半端にロジカルな「似非PDCA」で浪費なんかしないで
（Y）やったこと「お前、昨日何やった？全部書け」
（W）わかったこと「どう思った？何かわかったか？気づいたことや考えたことは？全部書け」
（T）次やること「じゃ、次何やる？3つに絞っていいから絶対やりきれ。」
これをホントに日次で回せたら、すごいスピードで成長していきます。
T（次やること）のやりきり力で、差は出ますが。
繰り返しますが、「似非PDCA」は、素直な学びを阻害します。
だったらYWTでいいじゃん。
私は30過ぎた今でも、
転職・異動とかで新しい領域にチャレンジするときは、
自分用のYWTを日次でアウトプットすることがあります。
15分以上時間をかけたものは、ランチでも、「やったこと」に入れます。
そうすると、ふとした会話からの学びが強制的に抽出されます。
（おまけ）YWTを最初に考えた人
ちなみに、この「YWT」、メーカーの研究所でよく使われる概念なのですが
考えたのは
日本能率協会の岡田幹雄さんという方だそうです。
聞いた話によると、
あるプロジェクトの最終報告前に行き詰まってたメンバーを前に
「簡単だ。『やったこと』『わかったこと』『次やること』をまとめればいい。」
と言ったとか。
天才肌の人で、「技術KI」というメーカー技術者の生産性向上のパッケージを完成させた人だそうです。
で、その思想は東大の伊丹敬三先生の手を経て、本にもなっています。
そんなわけで、賢い研究者もこんがらがった時は「YWT」使っているのですね。
機械学習プロジェクトは、分析結果をビジネス成果につなげるところがポイント
＜目次＞
機械学習のプロマネは、普通のプロマネとちょっと違う
最近、機械学習とかAIを使ったプロジェクトに関わる機会が増えてきました。
世の中的にも、機械学習を使ったプロジェクトは増えているように思います。
そして、私のような純粋ビジネスサイドの人間からすると
分析結果をビジネス成果につなげるところがキモ
その一つが「アウトプットをアウトカムに昇華させるのがキモ」ということです。
ここでいうアウトプットとは、データ分析結果を指します。
アウトカムとは、ビジネス上の成果を指します。
「分析結果が、ビジネス上の成果に結びつかない！」
という悲しい叫びは、誰か一人のものではなく、
経営者・ビジネスサイド・データサイエンティスト、それぞれから多く聞こえてきます。
機械学習でアウトプットとアウトカムが繋がらないのは構造的な問題である。
なぜ、機械学習のプロジェクトで分析結果がビジネス成果につながらないのか。
これには、構造的な問題が背景にあると思っています。
まず機械学習より前の話。
以上の結果、分析結果とビジネス成果は比較的シームレスにつながりやすかった。
- 分析結果の読解は、難しくなかった。Excel二次元とかだから。
- 分析する人も、コンサル出身者のようなビジネスサイド寄りの人間が多かった。
しかし、機械学習のプロジェクトの時代
- 分析結果を読み解くことに、一定のデータリテラシーが求められる（ことが多い）
- 分析する人であるデータサイエンティストは、ビジネス上の成果にそこまで興味がない（ことが結構多い）
結果、分析結果とビジネス成果に断絶が生まれがち、というわけです。
実際のケース
あるビジネスで、ユーザーの行動等から、機械学習を使ってコンバージョンの可能性の予測を立てたことがあります。
「機械学習で予測したコンバージョン可能性が高いユーザーに対して、アプローチしていきましょう」という施策。
まず、分析結果を正確に読み解くのが、意外と難しい。
そもそも分析結果を理解するだけでも、ちょっと面倒。
このケースでは、機械学習のアウトプットとして、コンバージョン可能性が0~1のスコアで示されるのですが、スコア≠実際のコンバージョン率でした。
これをある閾値で切ってみる、というアプローチをとっていました。
例えば、「スコア0.7以上の人は、コンバージョンに至る可能性が60%」みたいな。
さらに、実務にちゃんと落とすには
「スコア0.7以上、かつ、実際にコンバージョンする人は、コンバージョン全体の10%をカバーする」のように
既にここまでで、（私の説明下手もあって）そこそこわかりにくいと思います。
※興味ある方向けに、この辺の話をまとめました：
さらに、機械学習のモデルの中身・計算過程のロジックまで理解しようとすると、結構な勉強が結構必要です。
「数式が出てきただだけでアレルギー」の人も多い現実の世の中で、
「これからの時代必要だから」って全員にこれを求めるのは雑だと思う。
分析結果をビジネスをつなげるのも、そこまで簡単じゃない。
仮に読み解けたとして、この分析結果をビジネス成果につなげるのは、結構難しいです。
最初、ビジネスサイドはシンプルに「予測が当たった方がいいじゃん」と、
正答率（正確には適合率）を高めるリクエストを出しました。
そのリクエストを受けて、データサイエンティストは、正答率を高めてくれました。
しかし、途中で状況が変わって、多数の顧客に一気に質高くアプローチできることがわかってきた。
こうなると、正答率20%でも、コンバージョン全体に対するカバー率（再現率）80%の予測モデルの方がありがたい。
この時点で
「正答率は一定を超えればいいので、その中でうまく再現率も高く欲しい」
とリクエスト自体が変わります。
そして、リクエスト変更は１回で終わることではありません。
実際のオペレーションや組織の状況で、結構流動的に変わるんです。
ちょっと雑に要約すると
- 分析
- ビジネス施策
の２つを行ったり来たりして
一番いい組み合わせを探っていくことが、機械学習プロジェクトでは求められる気がします。
だけど、この「行ったり来たり」をスムーズにできる人材・チームがなかなかいない。
じゃ、どうするの？
方向は２つあります。
①データサイエンティストが、分析結果→ビジネス成果 の翻訳力をつける
②ビジネスサイドで、データサイエンティストのアウトプットを読み解く力をつける
①を満たす人（ビジネスへの落とし込みができるデータサイエンティスト）が採るのが一見簡単です。
しかし、データサイエンティストと呼ばれる人は、日本ではまだ数が少なく、採用しにくい印象があります。
（少なくとも、私がここに書いているところでつまづいている組織が、そんな素敵な人を採る難易度は高いはず）
なので、個人的には、現実解としてのお勧めは②です。
コンサルや経営企画・マーケ出身者で戦略寄りだったり、数字に強めの人が統計と機械学習の基礎の勉強をすれば
②を満たす人（データサイエンティストのアウトプットを読み解いてビジネスにつなげる人）になれると思います。
かくいう私も、②を志向して、向こう５年くらいは食っていけるかなぁ、という感触があります。
正直、現時点で「AIのスペシャリスト」を目指すような関心も気概もないですが
確かに「AIとビジネスの間」みたいな領域はポテンヒットになりがちです。この点は実務として強い実感があります。
ビジネスサイドの偉い人たちは、AIのアウトプットを読み解いて、適切にフィードバックできるまで勉強しているとは限らない。
しかし、AIを司るエンジニア達に、ビジネスサイドのリクエスト、多数のオプションと同時に正しく伝えるのも、結構大変な作業。
ということで、「分析結果をビジネス成果につなげる」というところは機械学習プロジェクトのキモの一つで、
私は当面それでバリューを出せるんじゃないか、となんとなく思うわけです。
関連エントリ
データサイエンティスト養成読本 ビジネス活用編 (Software Design plusシリーズ)
- 作者: 高橋威知郎,矢部章一,奥村エルネスト純,樫田光,中山心太,伊藤徹郎,津田真樹,西田勘一郎,大成弘子,加藤エルテス聡志
- 出版社/メーカー: 技術評論社
- 発売日: 2018/10/30
- メディア: 大型本
- この商品を含むブログ (1件) を見る
