起業家の前職は何をしてたのか?

ZENTECH DOJOというシードアクセラレーターを始めて、2年以上が過ぎました。振り返ると、10人以上の色々な起業家や起業予備軍とご縁を頂いたなぁと思います。

また、先日採択チームが発表されたKawasaki ZENTECH Accelerator では10社の若きハードウェアスタートアップの創業者をサポートしています。

こうした起業家って、一般には学生が多いというイメージかもしれませんが、案外、社会経験を経てから起業する割合はかなり多く、8割以上の方が何らかの社会経験をお持ちです。

だからと言って、社会人起業が良いと言いたいわけではありません。むしろ、起業は「資格」や「経歴」から一番遠い仕事です。

学生時代に起業して大成功した人の方が印象的かもしれません。例えば、マイクロソフトのビル・ゲーツは在学中に起業しましたし、ザッカーバーグも在学中にフェイスブックを作りました。

しかし一方で、アップルのスティーブ・ジョブズ(アタリ)、スティーブ・ウォズニアック(HP)は一度エンジニアとして就職しています。アマゾンのジェフ・ベゾスは投資銀行で30歳まで働き、かなり出世していました。さらにウォルマートを創業したウォルトンは40を過ぎて起業しています。

このような例からも、学生起業が良いのか?社会人経験があった方が良いのか?という議論は不毛だということはご理解頂けたと思います。

 

企業で勤めたことがマイナスに働くこともあります。(例:「営業」は営業担当者の仕事だと思ってしまうなど、変な癖がつく)。

一方で、会社での経験が役立っているケースもたくさんあります。

前職の経歴として多いものから順に、その経験のどういった部分が起業後も活かせているのか、述べてみたいと思います。

 

エンジニア

エンジニア出身の起業家が多いのは、誰もが認めるところだと思います。それは技術を扱いなれていて、ゼロから何かを作る感覚を持っているからだと思います。

対象がプロダクトであろうが、ビジネス全般であろうが、実験や試行錯誤から学び、修正していくプロセスは、さほど変わらないのではないかと感じます。もちろん、対象領域に対する知識も必要ですが、不確実性の高いスタートアップにおいては、事前の知識よりも学ぶスピード(ラーニングカーブ)が遥かに効いてきます。

例外:「エンジニア」という肩書きはついていても仕様書や設計書を書くばかりの仕事もあります。(エンジニアを採用するスタートアップもこういうエンジニアには注意しましょう。有名なプロダクトに関わっていたというエンジニアも要注意です。売れている製品にはリソースが沢山割り当てられるため、一人の業務範囲は小さくなりがちです。)

 

研究職

意外に思われるかもしれませんが、エンジニアと同じ理由で研究職も向いています。実験と試行錯誤を信条とする研究者は仮説を立てて、検証することにあまり抵抗がないようです。

一方で「専門領域」や象牙の塔のヒエラルキーに慣れ親しんでしまっていると、チャレンジをする力が削がれてしまうかもしれません。

研究者も、ある研究領域における知識を重視しているような方はあまり向きませんが、そういう方はあまり起業しないので問題ないと思います。

 

コンサルタント

DeNAの南部さんのように、M社やB社出身のコンサルタントが起業するのもよく見かけます。ある程度コンサルをやってしまうと、起業するのが割に合わなく感じられるようですが、そんなこと考えずにやっちゃう人は向いていると思います。

特にB2B系のビジネスであれば、色々な企業の組織力学を知っていることは固有知識としても役立ちます。文書作成能力が高いと提案書は通りやすくなりますし、ビジネス上の振る舞いが板についていると、他の企業と付き合いやすいはずです。基本的な取引を成立させ、ビジネスを軌道に載せる上でCOO的なスキルをコンサルタント時代に身につけているのだと思います。

 

マーケター

企業のマーケティングを経験してから起業される方もいます。このような方は、サービスの見せ方から入るので、とにかくキャッチーです。「つかみ」が上手でコミュニケーションに長けているので、スタートアップ初期のスピード感をどんどん出せるのではないでしょうか。

一方で、スタートアップの内部はさほどシンプルなコミュニケーションだけでは済まず、エンジニアとのコミュニケーションや様々な試行錯誤にフラストレーションを感じるようです。

 

セールス

わずかですが、営業マンから起業された方もいます。営業現場で顧客の状況を深く知り、深いインサイトと原体験をお持ちです。原体験がきっかけとなり、営業を超えて製品開発や研究へと守備範囲を広げる情熱は、周囲を巻き込みます。また、エンジニアと比べ、「個」で動くことに慣れているように感じます。つまり、一人で色々な問題解決をしながら事業を立ち上げるときのパワーが出やすいように見受けられ、「営業」というイメージに合わず万能な仕事ぶりを感じさせます。

 

色々と職種別にスタートアップで役立つスキルを挙げましたが、企業でどんな経験するかはその人次第なところ相当あるので、あてはまらない人も多いかもしれません。ですが一つ共通して言えるのは、「濃い」経験をして、会社での一つの職種を務めるだけでは解決できない問題に出会っているということくらいです。

解決したい問題を目の当たりにし、取り組んでみるものの会社や事業の限界を感じ、会社を起こす、という流れは一つのステレオタイプなパターンなのかもしれません。さらに、上手くいっている起業家はその「職種」ではなく、「課題領域」においての専門家となっている、というパターンがあるのも必然なのだと思います。

Written by Shingo Tsuda on 2018-12-10

ジョブ理論、ジョブの発見と表現のコツ

昨年、2017年の夏に「ジョブ理論」が出版されてから1年以上経ちました。
ジョブ(Jobs to be done)という言葉の認知度はジワジワと上がり、新規事業開発だけでなく、マーケティング、営業とジョブが語られる文脈も広がっています。我々は独自に開発した「JOBSメソッド」という形でジョブ理論を公開セミナー、企業研修、メンタリングの場で伝えてきました。セッションの参加者も3,000人を超え、さらに参加者の伸びは加速しています。

伝え方そのものも大分見直し、トレーニングセッションのクオリティも大分上がってきたと自負していますが、受講者が考え方を理解しても、理論を使いこなすには、訓練が必要です。特にジョブ理論はイノベーションを起こす方法とも繋がっているので、これまでの思考の仕方を変える必要があります。これこそが、ジョブ理論の価値であり、逆に実践する際の難しさとなっています。

ジョブ理論を実践する際の典型的なハードルが二つあります。一つはジョブを発見する際のハードル。もう一つは発見したジョブを表現する際のハードル。実践にてこずっている方へ、ハードルの超え方のコツをお伝えします。

 

ジョブの発見のコツ

ジョブは人間が特定の状況下でやりたい事/やらなければならない事。ソリューションはその事を実現したり/解決したりする。つまり、ジョブはソリューションに関係なく存在しているのですが、どうしても既存のソリューションの枠に嵌ってしまいジョブが見えなくなってしまう事があります。
例えば、自動車というソリューションが実現/解決するジョブは何か?を考えてみましょう。好きな時に好きな場所へ自由に移動する(機能的な目的)、ストレスを発散のために運転を楽しむ(感情的な目的)は直ぐに思い浮かぶと思います。では、エコ意識をアピールしたい(社会的な目的)はどうでしょうか?ここで「自動車は本来乗り物だしエコ意識をアピールするものではない、エコ意識をアピールするなら、そもそも自動車を使わない方がよい」と考える方は、枠に嵌っている懸念があります。
自動車を使わざるを得ない状況でもエコ意識をアピールしたいという状況はあります。例えば、運送会社の経営者が自社の環境への意識をアピールするために、ハイブリッド車を導入するという場合です。

ジョブを発見する際には、既存のソリューションの枠にとらわれずに、顧客の状況を想像し発想を広げるのがコツです。

 

ジョブの表現のコツ

ジョブを発見することはできても、頭にぼんやりとイメージは浮かんでいても、上手く表現できない。表現したときにニュアンスが抜け落ちてしまうという場面をよく目にします。
例えば、テレビが解決しているジョブを考えるとき、知識を得たい(情報番組)、映像を楽しみたい(映画)、リラックスしたい(バラエティ)等は比較的簡単に浮かんでくると思います。では、暇つぶしをしたいというジョブはどうでしょうか。そんな事言ったらテレビや番組を制作している方に申し訳ない気もしますが、娯楽があふれる今の時代には、暇つぶしの手段の一つとして雇われている/もしくは雇われていないというのが実態ではないでしょうか。
通常そのソリューションに対して使われていない様な表現にこそ、人間が本当にやりたい事が隠れていたりします。

ジョブを表現する際には、ソリューションの枠から外して、顧客の本音を表現するのがコツです。

 

発見と表現の二つのコツを紹介しました。そもそもジョブを発見するためには、ターゲット顧客の候補を探し現場で一次情報を得ることが不可欠です。貴重な一次情報からの洞察を活かすためにもこのコツを活用してください。

「ジョブ理論」を理解するところから始めたいという方には、定期的に公開セミナーを開催しておりますので、ご参加を検討ください。

直近の開催は以下です。

事業開発に役立つ「JOBSメソッド」基礎講座
2018年12月7日(金)10:00〜18:00
https://event.shoeisha.jp/bizgenews/20181207/

Written by Tatsuya Yamada on 2018-12-03

組織開発、その前に

近年の事業環境の変化や働き方改革の流れを受け、企業の組織開発はホットな取り組みの一つです。

 

労働人口が減っていく中で、働きやすさは採用の面でもエンゲージメントの面でも大切な要素ですし、さらに人材成長・組織成長へと繋げるために、企業側もあの手この手で手を打とうと考えます。企業側のニーズがあるので、自然と各種の研修やワークショップ、HRTechサービスも多数生まれています(ラベル違いの同じようなものも多数ありますが・・・)。人材開発や組織開発の主管部門の担当者は、数あるコンテンツの中から目新しい、有効そうなものをやってみるという姿勢になっているようにも見受けられます。

 

ただ、組織開発は7Sモデルに代表されるように、事業戦略と当然ながら密接な関係を持っており、人や組織という立ち位置から見つつも、会社全体の状況を捉え、ストーリーを持って一手を打たないと有効打にはなりにくいものです。ビジネスモデルを成立させるために構造上ブラックに働かざるを得ない状況だと、やはり業務環境はブラック寄りになっていきます。

 

例えば、利ざやが少なくかつ、仕事がマニュアル化・型化されていて、かつ会社の屋台骨の事業であれば、上長からの細かな指摘の方が多くなるのは構造上起こりやすくなります。少しのミスが利益に影響を及ぼすし、この事業の数字が直接経営へのインパクトに繋がりますので。その上、人の採用が困難な昨今、更に競争が激しくなれば残業が増えるのは構造的に起こり得ることです。このビジネス環境の議論を棚に置き、組織活性化ワークショップをやっても、効果を実感するところまで到達するのはなかなかハードな道のりです

 

また、既存事業での輝かしい経験を持ち、初めて新規事業のトップについた方が、メンバーの士気を上げるためにアイデア発想ワークショップをやっても、事業化まで至らず頓挫し、かつ士気が下がるいうケースも見受けられます。この場合は、ワークショップ後のアイデア選定の段階で、トップが「で、いくら儲かるの?」と既存事業の商品開発のノリで関わってしまったことが原因です。この振る舞いにより、世の中に類似商品・サービスがあって数字を作りやすい、既存事業の派生のようなアイデアしか残らなくなり、アイデアとしては有望だが世の中に類似サービスがなく、長期的な収益計画が立てづらいアイデアは通りづらくなってしまいました。結果、提案もされなくなり、却って温度を下げる結果となりました

 

一方で競合優位性のある技術で高利益を出している会社であれば、その上に乗っている組織活性化の施策は効果的に働くでしょうし、研究開発スパンが長い業界だと、ノー残業などの取り組みも有効に働く可能性が高いです。

 

組織開発は事業環境に大きな影響を受けますから、本当に組織の成長を得たいならば、事業の状況を鑑みながら、事業開発から入った方がよい、業務プロセスから入った方がよい、いやいや今こそまさに人と人との対話だ、といった作戦・ストーリーが必要です。

 

組織開発の取り組みを行う前に、一度自社の事業構造を捉えて、その取り組みは有効打になり得るかを考えてみては如何でしょうか。

Written by Yuichi Hoshino on 2018-11-21

カスタマーサクセスを成功させる組織

カスタマーサクセスに関する3部作の最終稿です。

その1:カスタマーサクセスとは何か?
その2:カスタマーサクセスとJobs to Be Done, Time to Value

 

前回は、カスタマーサクセスをサクセスさせるために重要な3つの要素を挙げ、最初の2つの要素について書きました。

(1)「顧客の成功」をいかに的確に捉えるか ( 顧客ジョブの把握)
(2)いかに早くその成功に近づけることができるか (タイムトゥバリュー)
(3)組織化とプロセス

今回は「組織化とプロセス」です。

 

カスタマーサクセスの組織化やプロセス化を目指す前に、一つだけ注意をするとしたら、

PMF前にカスタマーサクセスはできない

ということです。

 

しばしば、PMFに到達する前にカスタマーサクセス部隊を作っている会社を見かけますが、「1勝もする前から勝ちパターンはない」ことに気づいた方がよいと思います。

PMFして、顧客がどんなジョブのために製品を使っているのかを把握できた後に、初めてそれをパターン化したり、組織として運用することが可能になります。逆に、そのパターンがあることによって、例外が際立ち、アクションもしやすくなるという循環も生まれます。

 

タッチを決める

カスタマーサクセスの方法論として、フィットしたプロダクトと顧客に応じて「タッチ」を設定するということがまず重要になってきます。

「タッチ」というのは、顧客接点、この場合はカスタマーサクセスの濃密さ、を指す言葉です。ホテルのサービスで言えば、超高級ホテルや旅館はハイタッチです。おもてなしを提供するための接触が濃密ですね。大規模シティホテルは中くらいでしょうか。ロータッチと言えると思います。ビジネスホテルは、セルフサービスが多いです。宿泊客が自助的に過ごしやすくする工夫はされていますが、ホテルの職員が積極的に顧客に関わることはあまりありません。このように、技術を提供することで顧客が価値を最大化する支援をすることをテックタッチと呼びます。

ビジネスモデルキャンバスに精通している方には、CR (Customer Relationships)と同じことを言ってる!とすでにお気づきだと思います。

 

プロセス&KPI

組織・プロセスを考える手順としては、

顧客のKPIを知る → PMFしたプロダクト・顧客に対してタッチを決める → タッチを決める → 顧客のKPIを高めるために必要な資源と活動を定める → 活動を行うための資源を準備し、スキルを集める → 自社の活動のKPIを決め、継続的に計測する

 

タッチは利益構造を決めます。高付加価値製品は、高単価ですし、顧客企業の経営レベルが購入の意思決定をするため、ハイタッチなサポートが必要です。逆に、担当者レベルが使用するようなSaaSであれば、一人一人に個別な対応は困難です。限られた利益が一度に吹っ飛んでしまいます。したがって、技術を使い、顧客の自助的な「サクセス」を促すような活動をカスタマーサクセス部門が目指すことになります。

この新しいカスタマーサクセス部門に適切なKPIを設定することができれば、活動を修正しながら、さらに高い効果が出るようにすることができます。理想は顧客のKPIを、自社のKPIにすることですが、さすがに計測が困難かもしれません。そういうときは、サービスの活用度や利用率といった、自社でも計測可能な指標を設定します。自社KPIを顧客KPIに基づいて決めることが何よりも大切です。ついつい、「売上」のような数値を設定しまいがちですが、これでは漠然としていますし、カスタマーサクセスに取り組む前と代わり映えしません。顧客の成功と直接因果関係のある指標を設定します。

営業支援サービスなら、顧客の売上、客単価、顧客数などが顧客にとってのKPIですが、さすがにこれらを把握することは難しいかもしれません。ですが、システムに登録されている顧客候補数や、顧客増加のためのキャンペーン数などがKPIとして良いかもしれません。

BoxやDropboxのようなオンラインストレージなら、有料無料かかわらず記録されているデータの容量とか、読み書きされた回数とか、共有されているユーザ数、デバイス数などが考えられます。

Written by Shingo Tsuda on 2018-10-11

カスタマーサクセス・JTBD・Time-to-Value

前回の記事では、カスタマーサクセスとは何かを書きました。

カスタマーサクセスとは、「顧客が成し遂げようとしていることを支援するための考え方およびその組織、戦略、オペレーションである。」

という長い書き方と、

カスタマーサクセスとは、「顧客のジョブ解決をゴールとする組織とその機能」

という短い書き方とがありますし、数式が好きな人には

CS (Customer Success) = CO (Customer Outcomes) + CX (Customer Experience)

という数式の方が覚えやすいかも知れません。

 

このカスタマーサクセスをサクセスさせるためには、3つのことが重要になってきます。

(1)「顧客の成功」をいかに的確に捉えるか ( 顧客ジョブの把握)
(2)いかに早くその成功に近づけることができるか (タイムトゥバリュー)
(3)組織化とプロセス

 

 

まず(1)です。どうやったら的確に顧客の成功を捉えられるのでしょうか?

「カスタマーサクセス」という言葉が主にSaaSのようなB2Bビジネスに使われることを考えると、顧客のジョブは割とシンプルな質問でわかります。
「(顧客の)部署のKPI(目指す指標)は何ですか?」

もちろん、KPIがあまり明確に設定されていない企業や部署も多く、はっきりしないかも知れません。ですが、会話を通じて、その顧客が重要視している指標を理解することは可能です。

 

例えば、人事部の採用課が相手である場合を考えてみましょう。

「KPIは?」と尋ねても「は?」みたいな顔をするかも知れません。なので「採用を増やしたいのですか?それとも質を高めたいのでしょうか?」と尋ねてみます。

すると、「採用する人数は各事業部から上がって来るので、人数は決まってるんですよ〜。。。しかも誰でも良いわけではなく、実はAI系のエンジニアの採用が難しくて・・・」と返ってくるかも知れません。

この返事から、採用課が目指していることは「各部門の要望を満たすこと」であることがわかります。特に、開発部門からの評価が得られれば「大成功」です。

このように顧客の成功を捉えると、単に人材を紹介するだけではなく、各部門の要望を整理したり、分析したりすることの重要性が見えてくるはずです。仮に人材紹介のプラットフォームを提供している企業だとすると、カスタマーサクセス部門にとって重要な仕事は「人事部が、各部門の求める人材像を理解しやすくする」ことになります。

シンプルに捉えるなら、ジョブはその部署のミッションやKPIだと考えるとよいでしょう。

 

(2)はタイムトゥバリューです。

つまり、いかに早く顧客が価値を感じることができるか、です。先ほどの人材紹介プラットフォームなら、使い始めてできる限り早く紹介できる人材が伝わるとよいでしょう。サービスを使い始めたとしても、肝心の人材情報に行くつく前にたくさんのフォームを記入させたり、ややこしい説明が多かったりすると、その前に顧客は諦めてしまうかもしれません。諦めなかったとしても、顧客側の負担が大きすぎて十分な価値を感じられないことも考えられます。フェイスブックは、初めてログインしたユーザーができる限り早く友人と繋がるか、という指標を重視することで顧客のタイムトゥバリューを高めています。

総じて、多くのサービスはタイムトゥバリューの設計が甘いように感じます。顧客の要望をしっかりと聞いて、無駄やリスクのない状態で価値を提供しようとするあまり「但し書き」「準備」が先立ってしまいがちです。ウェブサービスの「UX」や「デザイン」の問題という風に認識されているかもしれませんが、要は「使い始めてすぐに価値を感じられるか?」という観点でとらえてはどうでしょうか?価値を提供する場面まで極力ストレートな導線を描くのです。

 

一昔前までは、ユーザがサービスを使いこなすにはマニュアルを読み込むことが当たり前でした。使い方を一通り読んで、それから使用してみて、試行錯誤しながら成果を出してやっと価値を感じることができる時代でした。

その後、「ヘルプ」が当たり前になりました。マニュアルをさほど読まなくても、使用中に「ヘルプ」をクリックすると手助けが得られるというわけです。

「ヘルプ」ではまだ、ユーザの質問に対応する受動的な手助けだということで考えられたのが「ウィザード」のような仕組みです。ウィザードでは、最初にいくつかのシンプルな質問にユーザが答えれば、結果や結果に近いものを即時的に出すようなUXを提供します。

また、優れたタイムトゥバリューを提供する手法として「テンプレート」が挙げられます。あらかじめ用意された複数のテンプレートの中からユーザは選ぶだけで、ほぼ完成したものを手にすることができます。例として、インスタグラムは、どんなフィルターなのかを説明することなく、ユーザの希望するであろうフィルターを複数提示し、タップするだけで写真におしゃれな加工を施します。前時代的インスタグラムが存在するとしたら、ぼかしの入れ方や、彩度や明度の調整方法を紙のマニュアルでユーザに読ませるようなものだったでしょう。これでは、素敵な写真を共有したいという目的に到達する前に骨が折れてしまいます。

長くなってきたので、(3)は次回に回します。

Written by Shingo Tsuda on 2018-10-02