経営コンサル出身者が学んだ、スタートアップで価値を出すための"姿勢"
はじめまして。Ubie株式会社でプロダクトオーナー(PO)を務めています、まつむら(@matsumura_ubie)といいます。
この10月で、Ubieへ転職してちょうど1年になりました。前職の経営コンサルから転じ、スタートアップでの事業開発、そして今年4月からはプロダクトオーナーを経験していますが、今もワクワクしながら働いています。
一方で、この1年は失敗と学びの連続でした。正直に言うと、Joinする時点では「若手コンサルとしては十分な実力があるはず、即戦力として自分が入って会社を飛躍的に成長させてやる」と本気で考えていました(傲慢)。もちろん今も、その気概を持って働いていますが、話はそう簡単ではなく、なかなか貢献が出来ない苦しい日々も続きました。その理由を考えた際に、一つ大きな壁になったのが「コンサルタントとしての経験と自負」です。
今回、初めてのエントリーとして、スタートアップへ飛び込むことの楽しさと同時に、コンサル出身者がぶつかった壁と、その乗り越え方を書きたいと思います。
特に現役コンサル/経験者で、起業したい、スタートアップに挑戦したいと考えている方に読んでいただきたいです。また、コンサル出身者と肩を並べて働く、スタートアップメンバーにも参考になるかと思います。
【特にこんな人に読んで欲しい】
・コンサル経験者で...
・起業やスタートアップでの挑戦を検討している人
・なんとなく事業やりたいなーと思っている人
1. 自己紹介 : コンサルからUbieへのJoinまで
一口に「経営コンサル出身」と言っても、専門性も働き方も様々かと思いますので、前提として経歴をお伝えします。ただの自己紹介ですので、飛ばして次のセクションに行っていただいても構いません。
私は工学系研究科で修士を得た後、新卒で野村総合研究所(NRI)の経営コンサルとして働き始めました。コンサルを選んだのは、「頭と論理性を武器にした仕事への興味」「企業のサポートを通じた日本の産業への貢献」といった月並みな理由です。実は国家公務員とも迷っていましたが「目の前のクライアントの手触り感のある課題解決のほうが性に合っている」と思ったのも決め手です。
このNRIという会社、コンサルファームとしては特徴があります。私の経験の前提になるのでいくつか挙げると、
・一般的にシンクタンクと分類されがちですが、実態はほぼ完全にコンサルに特化していること(官公庁系の案件もあります)
・実は、会社の売上の9割ほどはSI部門が売り上げていること
・シンクタンクを出自としているので、調査や事業戦略立案領域に強みがあり、ほぼ全てのインダストリー(事業領域)をカバーしていること
・上場企業で終身雇用なので、若手全員への育成・機会付与が盛んなこと
NRIで4年半ほど働き、様々な経験をしました。社会人の出発点として色々と学ばせていただき感謝しています。配属やプロジェクトは次のとおりです。
・インダストリーではなくソリューション系の部署を中心に配属
・業界は様々。製造業、通信業、教育業、ファンド、官公庁、etc.
・事業戦略立案や業務改革支援を中心に、時々グループ再編や経営管理、マーケティング支援やシステム構築など。
・直近は、デジタル企画支援系のプロジェクトに、リーダーとして継続参加(デリバリー、セールス)
1年前の2019年10月にUbieにJoinしましたが、実はこの直前ではコンサルの仕事が充実しており、転職は全く考えていませんでした。先に働いていた友人からの紹介を通じて、自分もUbieのビジョンを実現したい、今の自分なら貢献できそうと思ったのが転職の理由です。主に次の3つです。
ビジョンを実現できそうという展望が見えた
・プロダクトの提供価値、社会貢献性、事業の成長ストーリーと、ビジョン実現への強いつながりや展望が見えた
・「超えないと行けないハードルはとても多いが、逆にハードルはある程度見えていて超えればきっと実現できる」代表の阿部の言葉に納得感があった
サービスが人々の行動変容・価値観変容につながる期待が持てた
・私自身のWill(野望)である「局所的・限定的にではなく、広く世の中の行動や価値観を劇的に変えるサービスを作りたい」が実現できそうと思った
個性的で自走力のあるメンバーと働きたいという気持ちになった
・様々なバックグラウンドや得意領域がありながら、全員が会社のビジョン実現に邁進ししているチームに惹かれた
かくして、意気揚々とスタートアップでの活動が始まります。
2. どのような壁にぶつかり、乗り越えたか
冒頭に書いた通り、意気込んでJoinしたものの、自分自身はなかなか会社に貢献できていないな、と思う日々が続きました。どのような壁にぶつかり、どのように乗り越えたのか(乗り越えつつあるのか)をまとめつつ、コンサルからアンラーンし、スタートアップ人材としてラーニングしたエッセンスを、整理したいと思います。
自分がぶつかった3つの壁
【1】忙しく働いている割に、会社の成長に貢献できる成果が出ない
【2】仕事を抱えすぎて、チーム全体のスピードが低下してしまう
【3】仕事の「型」の習得に躍起になり、学習が進まない
【1】忙しく働いている割に、会社の成長に貢献できる成果が出ない
UbieにJoinして自分が最初にぶつかった壁です。当時のUbieは、医療機関向けの業務効率化SaaSである「AI問診ユビー」のPMF(プロダクト・マーケット・フィット)が達成できつつありました。私は、自ら全国の医療機関へ往訪して提案しつつ、並行してセールス(営業)とカスタマーサクセス(導入・活用)のプロセスの型作りを行っていました。
情報の整理が得意スキルでしたので、業務整備や型化として、例えば営業資料やマニュアルの整備、営業ナレッジの集約や、セールスフォース(SF)のデータ整備、価格テーブルの更改などを行っていくのですが、どうもこれがうまく行かない。営業活動の傍ら作業を続けているのに、入社して1ヶ月2ヶ月経ってもなかなか目立ったアウトプットが出せていない。少しずつ焦りを感じ始めました。
■何が起きたのか? 何が原因だったのか?
端的に言うと、「計画を作り込みすぎ」「アウトプットを作り込み過ぎ」だったのだと思います。過剰品質への意識が捨てられていなかったことが原因です。
例えば、営業ナレッジやマテリアル、ルールなどを社内の情報共有ツール(Notion)に「営業ポータル」として集約するタスクを行っていましたが、明らかに「計画を作り込みすぎ」てしまい、(割と)理想的なナレッジサイトを構築する段取りを何日も考えていました。営業人員300人を抱える大企業ならともかく、高々30名のスタートアップでは散逸している情報が一旦集約されれば最低限の営業活動には十分なわけで、考え込まずにすぐ作り、翌日の営業から効率を上げるといった小さな成果を狙うべきでした。
また、医療機関への往訪で得られた知見を元に、営業資料やマニュアル等のアップデートも行っていましたが、こちらも「アウトプットを作り込み過ぎ」てしまいました。もう少しこまめに更新し、目の前の1回1回の商談の成功率や効率を少しずつ上げることで成果が出せたはずです。
■この失敗から学んだこと
あらためて「Done is better than perfect.」の重要性を身につまされる出来事でした。
これらの失敗は、実は十分に予期できていたが故に、ショックでもありました。スタートアップに飛び込んだ手前、「常にスピード感を持って仕事をしていく」ことの必要性は頭では分かっていましたし、ゴールや課題、タスクが柔軟に変わるような、難易度の高いコンサルプロジェクトを回してきたという自負もあったためです。
失敗したのには理由がありました。それは、Ubieの定めるValueの一つである "Giant Leap"(=目指すのは少しの背伸びでなく、規格外の広がりと非連続の成長)へのアプローチを間違えていたからです。大きな成果を出すためには大掛かりな取り組みをしないといけない、と考えてしまったことが誤りで、それはホームランを狙っていきなり打席でバットを大振りし、三振を重ねるようなものでした。チームメイトは日々着実に成果を出していて、それがある時大きな成果に繋がっていく、というのを目の当たりにして、日々スモールに成果を出し続ける意識が大切なのだ、ということを学びました。
なぜスタートアップで、スモールに成果を出し続けることが大切なのかは、同じくUbieでコンサル出身の Hyodo Katsuya がこちらのnoteに分かりやすく整理してくれていますのでご覧ください。
また、「走りながら考える」ことも重要です。「営業ポータル」を作るのであれば、全体の構造をクイックに考えた後、いくつかのコンテンツを早速充実させながら、足りない点があればまた全体の設計を振り返ればいいわけです。作業しながら、移動しながら、商談しながら考え続けることが求められている、というのを体感しました。
最近のUbieでは、notionに加え、docbaseという情報共有ツールを導入し、クイックにメモを作って議論することが当たり前になっています。これまではスライド数枚作って社内で議論することがありましたが、多少構造化した文章があれば実際は十分です。
【2】仕事を抱えすぎて、チーム全体のスピードが低下してしまう
産休の前任POに代わり、今年の4月からPO業務を始めた後、次の壁にぶつかりました。あらゆるスクラム本に書いてありますが、POはステークホルダーとスクラムチームの間に立つため、しばしばミーティングや雑務が増えて忙しくなりがちで、それは典型的なアンチパターンとされています。
そして見事に、私も「タスク抱え込みすぎ」状態に陥り、深夜労働が続く事態になりました。当時、COVID-19の第一波が流行し、Ubieも対応に追われたという環境要因もありますが、私がスクラムPO、事業開発(bizdev)、さらにはユーザーサポートチームの立ち上げ、と3つの役割を掛け持っていた影響も大きかったです。これで、チーム全体の開発スピードに影響が出ることになりました。
■何が起きたのか? 何が原因だったのか?
語弊を恐れず言うと、私の長時間労働それ自体が大きな問題だったわけではありません。コンサルではプロジェクトの状況によっては徹夜に近い形でプレゼン資料を作ることもありましたし、言ってしまえば忙しい状況には"慣れて"いました。(※念の為お断りですが、Ubieは自由な働き方を標榜しており、多くの人がメリハリつけて働いています。恒常的な長時間労働は、もちろん良くないことです。)
また、個人のアウトプットの総量が減ってしまったわけでもなかったと思います。通常の120%働いたとして、100-120%の成果は出ていたのではないかと思います。
この私の働き方が、チーム全体の生産性に少なからず影響してしまったことが重要な問題だと後になって気が付きました。それは、私がタスクを抱え込むことでチームの「スピード感」が失われてしまったためです。前任POの Riho Nishimura が記事として投稿している通り、POは「2秒でぶれない意思決定をする」ことが最も重要です。特にCOVID-19禍の中、開発のReturnやInvestは刻一刻と変わるので、Slackでチケットの確認が来たらタイムリーにスクラムチームに返信する、Bizチームがユーザーニーズを捉えたらすぐに議論してその公約数を見つける、といった活動を1秒でもクイックにやり続けるべきでした。
大きな原因は、コンサル時代の働き方のまま、マインドを変えられなかったことです。特に「タイムリーにレスポンスするための余白を持っておく」「継続してパフォームするように自分を整える」ことの重要性に気がつくのが遅れました。コンサルはアサインされるプロジェクトが明確で、かつ工数管理も行われるので、業務量の調整と見通しがつけやすい仕事です。また、仕事に緩急をつけやすく、例えば毎週水曜の定例の前日に徹夜したとしても、次の日は昼頃出社する、といった調整が可能でした。
一方、スタートアップ(というか、事業会社)はいつ何が起こるか分かりませんし、その業務分担も最初は明確ではないため、常に即応できる時間的・精神的余白が必要です。また、常に自分のパフォーマンスを最大化できるように、よく寝ることも当然重要です。これに気が付かず、私の疲弊がチームの生産性を下げる一因になってしまいました。
■この失敗から学んだこと
一つは、「コンサルのハードワークは、決して働き方のベストプラクティスではない」という当たり前の事実に気がついたことです。プロジェクト型のクライアントワークでは通用しても、時々刻々と状況や対応が変わる働き方では必ずしもワークしませんでした。また働き方だけでなく、業務の進め方も然り、です。先述の(過剰)品質よりスピード感を大切にすることはもちろん、透明性の観点で情報は即座に公開・整理・配信されるべきで個人のローカルフォルダに置くべきでない、といったような所作が一つ一つ当たり前のように違います。自身のマインドから、働き方を柔軟に変える必要がありました。
なおUbieでは、特に"透明性"に関して、並々ならぬ力を入れて取り組んでいます。詳しくは「透明ガイド」をご覧ください。
また、より大きな観点では「勇気ある取捨選択、フォーカス」が重要です。Ubieでは、目標にフォーカスするためにOKRを取り入れていますが、個人の仕事も、取捨選択していく必要がありました。アウトプットが1週間遅れるのであれば、それは自分がやるべきでないか、今やるべきでないか、そもそも必要ないかのどれかです。優先順位付けをすることの重要さが身にしみてわかりました。
私の場合には周囲のアドバイスもあって、ユーザーサポートチームの立ち上げ業務を(より得意な)同僚に引き継いだり、biz要素の強い業務を少しずつ移譲し、よりPO業務に集中できるようになってきています。会社全体としては、よりエッジーにOKRを運用したり、ホラクラシーという権限移譲のフレームワークを導入したり、よりフォーカスと分担が進んでいます。これらは別の記事に譲ります。
【3】仕事の「型」の習得に躍起になり、学習が進まない
3つ目の「壁」は、学習に関するものです。初めてのスクラム開発で、POとして活躍できるよう、様々な書籍や記事で振る舞い方や仕事の進め方を身につけようとガムシャラになっていました。
すでにPO業務を始めて半年になるので、各種セレモニーや、Product Backlog Listの管理・更新などの責務は、その意義も含めて一通り理解し、活動できています。ですが、果たしてチームのROIを最大化するようなPOとして振る舞えているのかどうか、成長できているのかどうか、実は自信の無い期間が続いていました。
■何が起きたのか? 何が原因だったのか?
端的に言うと、スクラムにおける「学習」を、自分がうまく取り入れられてなかったのだと思います。作業の仕方といった「型」から入り、それを必死にコピーすることに時間と意識を使ってしまいました。本当に大切な、スクラムの「思想」に気がつくのは、大分後になってからです。スクラムガイドには、「確約・勇気・集中・公開・尊敬の5つの価値基準は、スクラムの仕事を進める中で学習・探索する」とあります。型を一回覚えて終わりではなく、学習を続ける中でこれらの価値基準を習得していくことが大切だということでした。
その結果として、セレモニーではうまく振る舞っていても、より良くするために次スプリントはどうするのか、という学習が進まず、いつまでも再現性や成長を実感できずにいたのだと思います。
原因として一つあるのは、「型」を習得しきればそれで終わり、と考えてしまっていたことです。コンサルは、"ソリューション"という形でベストプラクティスが存在し、その思想や背景、勘所は理解しつつも、それを顧客の課題にうまく当てはめれば、プロジェクトとして成立し、個々のタスクは進めることができます(少々乱暴な説明ですが)。あるいは、そのようなベスプラを作ることが、コンサル事業開発に求められるところでもあります。スクラムも同様にベスプラがある、と早とちりをしてしまいましたが、その実は「経験主義的に」学びつづけていくというフレームワークだ、というところがミソでした。
この失敗から学んだこと
「経験主義」的に学ぶことの重要性です。実は私は、スクラムガイドを始めて読んだ時「経験主義」という言葉が指すものが分からなかったばかりか、若干の抵抗感を覚えていました。本来、ベスプラがあって然るべきというコンサル的価値観だと、既知の知識と経験から学んでいけばいい、という曖昧な部分に違和感があったのでしょう。
「経験主義」的に学ぶ、意味が少しずつ分かってきました。スクラムでは、プロダクト開発で成果をあげていく上で、チームの理解やプロダクトの状況に応じて、経験を通じて学習しながら最適な方法を習得していくプロセスこそが大切、と説いているわけです。もっとシンプルに言うと「これといったやり方はない。走り学び続けることでチームが強くなっていくことができる」成長と学習のフレームワークだと、私はそう大雑把に理解しています。
これらの理解は、スクラムを体得しているスクラムマスターを中心に、レトロスペクティブ(振り返り)を繰り返すことでなんとなく分かってきました。KPTを使っており、毎週のスプリントで課題(Problem)をあげ、次のスプリントでの挑戦(Try)を決めて実行するわけですが、正解やベスプラがあるわけでは決して無く、経験から学んで次の挑戦をしてみる、という姿勢があるだけなのだと思います。
スクラムに限らずこのような、仕事の進め方自体を、仕事を進めていく中で考え学習していく、というスタイルは、Ubieが組織的に挑戦していることでもあります。直近では、プロダクトの開発と検証を行う方法としてのディスカバリーチームなどの試行をしていますが、これも別の記事に譲ります。
3. コンサル出身者はどのように活躍できるのか?
ここまでお恥ずかしながら、私個人の失敗と学びを書いてきました。では一体、コンサル出身者は、どのようにスタートアップで活躍できるのでしょうか? コンサル出身者が強みを活かせる領域、またそのための工夫について、個人の経験や周囲のコンサル出身者の活躍を踏まえて、私なりの考えを記したいと思います。
1. 「考え抜く」力を「走りながら考え続ける」力に変えて価値を出す
手を動かさず、計画を立てたり考え続けるだけでは、事業や状況が目まぐるしく変わるスタートアップでは成果を出しにくい、と書きました。コンサルであれば、社内で発散的な議論をしたり、机にかじりついて考えるといったタスクの時間を確保しやすいですが、スタートアップでは「考える」というタスクにまとまった時間を取りづらいのが現実です。
一方で、コンサル出身者の強みはやはり、一つの物事を徹底的に考え抜いてきた、という豊富な経験にあると思っています。外部環境と事業の状況からクライアントの経営イシュー仮説を考え抜く、膨大なファクトを適切に整理する軸を考え抜く、最も端的に伝わるストーリーとメッセージを考え抜く...
となると、走りながら考え続ける、ということが価値を生むと思っています。これには2つの側面があり、一つは手を動かすことと考えることをなるべく小刻みに、極力並行して行うということです。そしてもう一つ、日々成果を出しつつも、事業の展望や中長期のストーリー、2手3手先の選択肢などを常に頭の片隅で考え続けることも重要です。「戦略を考える」「段取りを考える」ことだけに時間を使えるほど専門分化されていない組織規模の段階では、どうしても中長期ストーリーのイメージは経営者など一部の人間を除いて曖昧になりがちです。これを自分なりに精度高く持っておき、必要な時に認識合わせをすることは、もちろんスタートアップメンバーの全員がやるべきですが、コンサル出身者の価値の出しどころの一つかと思います。新幹線での移動時間、ニュースを読む時間、外部の人と交流する時間...に、頭の中やメモ帳を使って常に「考え続ける」ことで価値を発揮できそうです。
2. 現地現物の姿勢を忘れず、仮説の精度の高さで価値を出す
プロダクトに限らず、あらゆる開発の初期の段階では、タネとなる仮説(課題仮説。施策の仮説ではない)の精度が、その後の仮説検証のスピードをある程度左右します。施策(例えば、プロダクト)の検証は施策を実施することで出来ますが、そもそも解くべき課題が適切なのか、優先度の高い課題なのか、は即座に検証が難しい場合があります。ユーザーは必ずしも課題意識を自覚・言語化できるわけではないので、施策を実行した後で、実は課題でなかったとか他の事が課題だった、ということが容易に起こりえるためです。これをなるべく小刻みに、高速に行うのが「リーンな開発」という思想ですが、初期仮説の精度が高いに越したことはないと思います。(リーンな開発で、仮説精度をどこまで追求しに行くか、というのは難しいテーマだと思いますが。)
仮説の精度を高める上で、ユーザーの1次情報、他社や他業界の事例などを総合し、帰納的に課題仮説を作るアプローチを繰り返してきたコンサル出身者は強みを発揮できそうです。「クライアントの課題(イシュー)を適切に捉えられたら、プロジェクトは半分終わったようなもの」なんて言われることもあるコンサル業界で、多様な意見の集まりである1次情報から公約数を見つけ出す整理・抽出力、クライアントの立場や思考をトレースする斟酌力、それらを通じた課題発見力が身に付いているのであれば強みですし、開発の初期にも価値を発揮できそうです。そのために、現地現物で常にインプットを増やしていく心がけは忘れないでいたいものです。
3. 状況に応じた適切なメッセージングでスピードアップの価値を出す
役割分担がさほど進んでいない、けれどもメンバーは少なくない、という規模のスタートアップでは、社内コミュニケーションは大きなオーバーヘッドになります(30-50名くらいが最大か)。特にUbieのような、全員経営の意識や透明性を重視しているスタートアップでは、その傾向は顕著です。
そのカオスな状況下で、コンサル出身者は端的なメッセージングで価値を出せると思っています。「極力端的に伝える」「状況に応じて情報量を使い分ける」ことの2つが要素になりそうです。
「極力端的に伝える」ことは、イメージが容易かと思います。くどくど説明せず1文で書ききる、構造が整理されている... 等は、コンサルのベーススキル(※イージーではない)ですし、もちろんスタートアップでも有用なスキルです。「状況に応じて情報量を使い分ける」はそう簡単では無い分、より価値を発揮できそうです。例えばUbieでは、社内には医師・エンジニア・デザイナーetc. がいて、対外的には医療機関の医師・看護師・事務や製薬企業、官公庁や医師会などの方々と接点があり、多種多様です。各人の理解の前提や、受け入れる姿勢などは当然異なるため、説明をリッチにする程度、ポジティブやニュートラルな表現の使い分け、など伝えるための工夫がかなり重要になってきます。コンサル出身者が、経営者から幹部、現場の各種担当者とそれぞれ渡り合ってきた経験が、すぐに役に立つと思います。
4. 最後に
私の失敗と学びを通じて、コンサルタントがスタートアップでぶつかりがちな壁とその乗り越え方、さらに活躍できる領域や工夫の考え方を書いてきました。やや乱暴にまとめると、コンサル出身者はスキル面では大いに活躍ができる、一方でスタンス・姿勢についてはアンラーンと学習が必要になる場面も多い、と言えそうです。培ってきたスキルを最大限活かして貢献するためにも、常に柔軟な気持ちで事業や業務に取り組む姿勢が大切なのだと分かってきました。
Ubieは事業はもちろん、組織的にも様々な挑戦をしています。コンサル出身者に限らず全員が、日々学習をしながら、ビジョンを達成するべく全力疾走しています。ご自身の経験を活かしつつ、新しいフィールドに飛び込んで挑戦してみたいという方や、興味はあるが不安もあるという方は、ぜひお気軽にTwitter等でお声がけください!
いつか、読んでいただいた皆さまと、同じスタートアップのフィールドで働けることを楽しみにしています!
この記事が気に入ったらサポートをしてみませんか?