とあるSaaSスタートアップCXOの3年間
CXO (Chief Experience Officer) ってどんな役割なんでしょうか。デザイン領域で語られることが多い役割なので、なんとなく「デザインマネージャー」や「プロダクト責任者」のようなイメージがありつつも、まだまだ曖昧な役割だと思います。
2019年から2021年まで約3年間、BtoB SaaSスタートアップにて、分からないなりにCXO業をやっていたので、「こんなことやってたよ」という記録を残してみます。無職になって2ヶ月近く立ち、記憶が薄れはじめている自分のための備忘録でもあります。
オチはありませんが、似た状況にいるどなたかの参考になれば嬉しいです。
コンテキスト
ひとくちにCXOといっても、会社のフェーズや事業内容、他の経営メンバーの強み弱みによって、実態は大きく変わるかと思います。私のコンテキストはこのような感じでした。
フェーズ: 入社時点で創業5年目、30名規模の組織
経営メンバー: 取締役は代表と自分の2名体制
自分はプロダクトに、代表はセールスに強み
事業: 採用領域のBtoB SaaS
特にカスタマーサクセス (CS) が深く入り込むハイタッチ型
まとめると、CSが重めのBtoB SaaSを事業とし、所謂「30人の壁」に当たる組織で、2人目の経営メンバーをしていました。太字にした変数がひとつでも違えば、別の行動をしただろうと思います。
またCXO自身のバックグラウンドも変数のひとつです。私はキャリアをエンジニアとしてスタートし、状況に応じてプロダクトマネージャーやデザイナーに役割を切り替えてきました。そのため、良くも悪くも技術・デザイン・プロダクトマネジメントのバランスを取った意思決定をしがちです。
1年目: なんでもやる
入社した2019年当時は、業績は毎月伸び、メンバーも増加し続ける成長期。ただプロダクトの長期的な方向性は描けておらず、目の前のビジネス成長に追いつくために、技術面でもデザイン面でもプロダクトに負債を貯めている、、というありがちな状況でした。
3年後の青写真を描く
入社時は業務委託契約だったこともあり、最初の数ヶ月は組織上はメンバーを持たずに動いていました。その自由な期間を生かし、セールスやCS同行、社内インタビューなどをしながら組織やプロダクトの現状を理解することに時間を使っていました。
そうしていくうちに、大きく2つの課題が見えてきました。
プロダクト: ITベンチャーから飲食チェーンまで多様な顧客をワンプロダクトでカバーしきれず、身動きが取りづらくなっていた
組織: プロダクトの力不足による負担が、CSメンバーに集中していた
ビジネス成長を止めないという前提の上で、これらの課題を解決するために、自分のなかで「式年遷宮」と呼んでいるアプローチを取ることに決めました。詳細はこちらのnoteで書いていますが、一言で言えば、顧客のゾーニングを目的とした新規プロダクトの立ち上げです。
これによって、負債をこれ以上増やさず返済時期を遅延しつつ、小回りが効く状況を作ることで、プロダクトのアップデート速度を早めていこうと考えていました。
この時期に決めた方針は随時更新をしつつも、結果としては大きくブレずに3年進むことになりました。最初の1-2ヶ月は「目の前で見えている課題になぜ取り組まないのか」といった声が上がることもありましたが、わかりやすい課題に囚われずに数年先を見据えたことは、プロダクトの方針にひとつ筋を通す上で必要だったと思っています。
多能工でスモールチームをつくる
次に組織の話です。社内のことを深く知るにつれ、「縦割り意識の強さ」をたびたび感じるようになりました。
この意識は、「エンジニアにプロダクト開発以外の仕事を依頼し辛い」、「『開発さん』のような職種呼びが一部にある」、「マーケティング関係のデザインや開発が外部ベンダーに依存しブラックボックス化」、などなど各部門内での部分最適な行動として現れます。
縦割り意識の強さはSIerなどBtoB出身者が多かったという要因もあるのですが、それ以上に組織構造と目標の置き方にあるのでは、と考えるようになりました。
BtoB SaaSでは、“The Model” という組織構造がひとつの型として参照されることが多くあります。私たちも例外ではなく、The Model型を採用していました。
The Modelでは、インサイドセールスは商談数を、フィールドセールスは受注数、カスタマーサクセスは継続率を…など明確なKPIの分割が行われます。全部門のKPIが (概念的には) 同じ方向を向いていることから、SaaSは美しいビジネスモデルとも言われます。
私たちの場合は、それを愚直にやっていたことで、ビジネスは一時的に伸びたものの分業による縦割り意識が強くでているように見えました。SaaSのスケールには各部門の連携は欠かせないとも言われます。
ちょうど前述のプロダクト方針から、新規プロダクトの立ち上げを決めていました。
そこでそのチームは、「セールス兼カスタマーサクセス」のように1人の人間が複数領域を担当する「多能工」で構成することにしました。The Modelの良い部分は残しつつも、縦割り意識を変えるための一時的な逆張り。ソフトウェア開発でいう逆コンウェイの法則みたいなものかなと思っています。
これはエンジニアやデザイナーも例外ではなく、ビジネスへの越境を誘発するような役割分担としていました。
具体的にはデザイナーはプロダクトデザインだけでなくカスタマーサクセスも一部担当する、エンジニアはプロダクト開発だけでなくSalesforceの開発など、ビジネス支援にも技術の力を使う、といったことを意識的にしていました。
のちにこのスモールチームは解体し、全社にマージすることとなりますが、多能工により部門越境を誘発し、縦割り意識を崩すことは、その後の組織づくりでも常に意識していました。
この取組みのなかで、いちカスタマーサクセスのメンバーだった若手がビジネス全体を見るようになり、後年は執行役員として責任範囲を広げていくきっかけを作れたのは、今振り返っても良かったなと思っています。
副業・フリーランスの巻き込みやすさを考える
エンジニア・デザイナー採用が難しい現在では自然なことですが、フリーランス・副業人材 (業務委託) をチーム作りの中心に置くことは当初から考えていました。
「新規プロダクトの立ち上げ」という方法を取ったのには、彼らの巻き込みやすさも理由のひとつです。年季が入り複雑化した既存プロダクトの開発に比べると、ゼロから作り始める新規プロダクトのほうが彼らの力は借りやすくあります。
その他にも細かなことの積み重ねですが、こんなことをしていました。
フェアな契約
既存の契約書テンプレを使うと、不必要に会社側に有利になっていたりする (競業避止など)
予算は外注予算だけでなく採用予算としても捉える
将来的に正社員採用を視野に入れるのであれば、予算の扱いをアドホックな外注費のみにしてしまうと、長期的な関係性が築きづらい
プロダクト開発に関することはなるべく文書化し、細切れのコミット時間でもキャッチアップしやすくする
優秀な人ほど複数案件を掛け持ちしており、自分たちはone of themであることを忘れない
正社員と業務委託の違いは契約形態だけと考えて、ドキュメントやSlackを不必要に制限しない
これらは特別なことではなく、情報の透明化や非同期コミュニケーションを円滑にするといった当たり前の積み重ね。そしてそれは正社員 (特にリモート社員) にも優しくなります。
ありがたいことに、前職でもSaaS立ち上げをしていた繋がりから、強いフリーランス・副業メンバーを初期から巻き込むことができました。それは単なる「外注」ではなく、開発・デザインに対する社内メンバーの目線を上げる効果もあります。
これらの結果として、現CTOを含め、複数人は業務委託から正社員採用につなげることができました。
働き方の柔軟性を上げる
今では当たり前すぎて書くか迷いましたが、時間や場所に縛られずに働ける状態をつくることは入社直後から取り組んでいました。
フルフレックス勤務、リモートワーク
オフィスにWebカメラやスピーカーなどの整備
不要な定例ミーティングを徹底的に削減
特にフルフレックスやリモートに関しては、知人の労務マスターにサポートしてもらいつつ規約面を詰めて全社に展開する、ということを入社1週間後にやっていた記憶があります。
オフィスで時間をともにすることの良さも勿論ありますし、コロナ禍以前の2019年にこの取組みの論理的な正当化は難しかったです。この時点では「柔軟な働き方ができる組織にしたい」という私のエゴでしかありませんでした。そしてコロナ禍になり、先手を打っておいて良かったと実感することになります。
またこれらの取り組みも、正社員に限ったことではなく、副業・フリーランスの巻き込みやすさに繋がります。正社員が柔軟に働いていれば、地方在住の方も自然とチームの一員にできます。実現はしませんでしたが、タイムゾーンがだいたい同じであれば、国内である必要もないなと思っていました。
今日の開発定例、気づいたら東京・京都・大阪・広島・沖縄の5拠点開催になっててうけた
— degoo (@dex1t) June 18, 2020
代理CTO業
1年目は経営メンバーが私と代表だけ、とくに技術のリーダーが不在であったことは、私の動き方に大きく影響しました。私もバックグラウンドはエンジニアですが、スキルや志向的に、技術のリードをとるのに自分は適切ではないと思っています。
早いうちにリーダーを誰かに任せることを念頭に置きつつ、基本は現場メンバーに意思決定を委ねていました。ただ次のような要所では、アジリティを上げられるような意思決定を意識していました。
開発メンバーの流動性を高めることを重視した技術選定
複数あるプロダクトの技術セットを統一し、プロダクト間の流動性を高めること
「エンジニア兼デザイナー」が手出ししやすい技術 (React, React Nativeなど) を重視して選び、職種間の流動性を高めること
現代のBtoB SaaSらしいアーキテクチャ選定
マルチテナンシーの実現方法など、間違えるとビジネスにも影響がでる部分 (前職でSaaSを作っていたときの反省を生かしつつ)
「エンジニア兼デザイナー」に関しては、チームにこのタイプが多かったという事情からです。私自身もそうなので、採用時に見極めとアトラクトがしやすい (類は友を呼ぶ) ことによる影響だと思います。
メンバーの流動性を高めることで、複数プロダクトがありつつも、エンジニア・デザイナーを少数精鋭で保つことができていました。
この時期は技術的な意思決定やエンジニアのマネジメントだけでなく、プロダクトコードも自分でかなり書いていたのですが、そこはもうちょっと時間の使い所を考えるべきだったな、、と反省しました。
リブランディング
ようやくデザインっぽい話です。2019年当時に会社の顔として掲げていたロゴを初めとするクリエイティブ (VI) が、事業や組織など実態を表していないという歪みを入社前から感じていました。それを解決するために、会社のリブランディングに取り組むことになります。
その思いやプロセスについては上記のnoteを見ていただきたいですが、アウトプットとして「ロゴを新しくする」こと以上に、重要視していたことがあります。
ブランディング施策とビジネスを接合させること
組織全体のデザインに対する目線を上げること
広義のデザインプロセスにビジネスメンバーに参加してもらうこと
平たく言えば、ビジネスメンバーからみて「なんかデザイナーたちが新しいロゴつくってる」という他人事な認識にしたくありませんでした。
冒頭に触れたコンテキストにも繋がりますが、私たちのようなBtoB SaaSは、デザイナーはユーザーから遠い存在。デザイナー以上に日々ユーザーと接しているのは、セールスやカスタマーサクセスです。
そんな彼らに会社のリブランディングを自分事にしてもらうことで、「自分たちが何者なのか」を熱を持って語れる状態をつくることは、SaaSビジネスにも受注数や継続率といった形で、長期的に還元されるはずです。
2年目: 力の入れどころを変える
1年目は何をしたらレバレッジが効くのかがわからず、多方面になんでもやりすぎたという反省がありました。逆に得られたもので一番大きかったのは、「BtoB SaaSにおいて、日々ユーザーと接しているのはビジネスメンバー」というシンプルな理解です。
言い換えれば、ユーザーが抱くプロダクトへの期待は、セールスやカスタマーサクセスが担っていて、プロダクトの開発工程だけを良くしてもレバレッジが効きづらいということです。
これはハイタッチなBtoB SaaS特有であり、同じSaaSでもSlackやNotionのようなテックタッチ型だとまた変わってくると思います。
CTO採用決定と動き方の変化
2年目の最大の変化は、1年越しで誘いつづけていたCTOの入社がついに決まったことでした。彼が入社した時点で、私はエンジニアのマネジメントは全て手放し、自分でコードを書くこともプロトタイピング以外ではしなくなりました。
その代わりに増えたのはビジネスメンバーとのコミュニケーションです。日々ユーザーと接しているのが彼らなのであれば、彼らが「広義のデザイナー」のように振る舞えたら話が早いと思ったのです。
特に当時一緒に動いていたCS責任者には、インタビュー手法のインストールや設計のレビューなど繰り返ししていました。また事業部での合宿にデザインスプリントの要素を加えてみたり、入口と出口を抑える意味で、ビジネス職の面接や評価にも絡むようにするなど、1年目とは動き方が変わっていきました。
体験設計をビジネスプロセスに反映する
もちろん全員が「広義のデザイナー」のように振る舞えるわけではありません。カスタマーサクセスは比較的親和性が高いですが、特にセールスは受注数をとにかく最大化するようなシンプルな動きが得意な人も多くいます。
手法のインストールを個人にするだけでなく、みんなが無意識に実践できるような仕組みにすることが必要だなと感じていました。
そんなときに、「パーセプションフロー・モデル」という考え方を知りました。詳細は長くなるので記事を見ていただきたいのですが、プロダクト開発における体験設計的な考え方を、セールスやマーケティングプロセスの設計に適用するためのフレームワークだと私は捉えています。
大雑把に言えば、事業が目指す方向性を定義し、それに対して顧客 (見込み客) がどの認知状態 (パーセプション) にいるのかを管理する手法です。よくある営業活動では受注確度をAヨミ Bヨミ…のように管理しますが、パーセプションフロー・モデルでは、顧客の認知をどれぐらい変えられたかを管理します。
プロダクトに対する誤った期待を顧客に抱かせ、力技で受注できたとしても、パーセプションフロー・モデルにおいては評価されません。SaaSにおいてそのような受注は、CSや開発部門に負担をかけることになり、その負担に耐えられなくなると解約に繋がります。
顧客に「このプロダクトを使い続けたい」と思ってもらうための、正しい期待をステージごとに定義し、それに紐づく営業・マーケ施策とKPIを設定し、Salesforceなどで管理する、、というのがこのフレームワークの要約です。
先の記事を書かれた方から実際にレクチャーを受けつつ、私と事業部長の二人三脚で実際にパーセプションフロー・モデルを使ったビジネスプロセスを設計していきました。
これまでの私は、プロダクトをつくること以外で、ビジネスにどう貢献したらいいのか分からず、なんとなく「自分では直接手出しできないもの」という壁をやんわり感じていました。まだ道半ばですが「これまでプロダクトに使ってきた体験設計力は、ビジネスプロセスの設計にも転用できる」という視点を得られたのは、ここでの大きな収穫でした。
コロナ禍での新規事業立ち上げ
ITベンチャーや飲食系のクライアントに対して、採用サービスを提供していた私たちにとって、コロナ禍の影響は想像以上に大きいものでした。ちょうどオフィスの契約更新時期もあり、何度も議論した結果、全社フルリモート体制に移行。そして、世の中的に採用活動がストップするなかで、採用軸とは別の新規事業を模索し始めます。
詳細は省きますが、この時期これまでとは違う業界をターゲットにしていたこともあり、いつもより入念にUXリサーチをしていました。
普段接点のない学生にインタビューするために、タイミーでリクルーティングし、Zoomでインタビューし、Figmaでプロトタイピングして使ってもらって、、というフルリモートでのサービスデザイン。
リモートワークに比較的慣れていたこと、サービス立ち上げは自分にとって何度もやってきたことなどあり、目新しいトピックはありません。細かい問題はあるにせよ、やってやれなくはないなという感覚でした。
このままだとマズいなという危機感のもと、この時期から新規事業の立ち上げに集中し、他のことは一切やらないことを決めました。
3年目: 葛藤
この辺りから泥臭いことが多く、書けることがなくなっていきます。
2年目に立ち上げた新規事業でなんとか資金調達もでき、会社のランウェイにも一時の余裕が生まれました。ただコロナ禍に入り会社の局面が変わるという事象は尾を引き、ビジネスメンバーを中心に離職も増えていました。
BTCトライアングルのどこに身を置くか
そんな状況もあり、3年目は組織にいま必要とされることをとにかくやる感覚でした。
それはBTCトライアングル (Business / Technology / Creativity) でいえば、自分が得意な“T”や“C”から離れ、組織として弱っている“B”に寄っていくことです。つくることよりも、セールスやカスタマーサクセスのブレーン的な立ち回りが中心になりました。
ただここで葛藤が生まれます。“B”に寄れば寄るほどに、自分自身のアイデンティティが薄れ、価値を発揮しづらい場面も増えていきます。いまの組織としての弱みと、自分の強みの相反。
小さな組織においてこういう状況でどう振る舞ったらいいのか、答えはまだ出せていません。ひとつは「より強力な“B”を採用する」というのが逆転のカードかなと思います。実際にシニアなビジネスメンバーの採用活動にも3年目は時間を使っていました。それは“T”に寄り過ぎた1年目、CTOを採用してバランスを取り戻したときと同じです。
BTCトライアングルのバランスは、ひとりで保つものではなくチームで保つもの。その中心に立つとされるCXOは、組織における重心の偏りによってやるべきことが変化する、ということがこの3年で分かりました。
こんな葛藤もありつつ、もともと資金調達を節目として考えていたこと、会社の方針を大きく変えることにしたこと、個人として“TC”領域に戻りたくなったこと、などなどあり昨年末で退任を決めました。
期待のマネジメント
話をまとめると、私の場合はCXOとして「デザインをマネジメント」するという感覚はあまりなく、「期待をマネジメント」するという感覚のほうが強かったです。
プロダクトの方向性 (期待値) を決めること
サービスデザイン、プロダクトマネジメント
会社やプロダクトに対して、顧客に正しい期待感を持ってもらうこと
CI/VIリブランディング、ビジネスプロセス構築
期待に応えるためのプロダクトをつくること
エンジニアリング、UIデザイン
リブランディングとビジネスプロセス構築のような、アウトプットが全く違うものも、期待形成という意味で同じ目的です。総じて、自分は組織における期待調整係みたいなものだなと思ってました。
また、一般的にCXOがやりそうな仕事として「デザイン組織づくり」がありますが、フェーズ的に必要最低限しかやっていません。逆に、組織全体をいかにデザイン活動に巻き込むかというのは常に考えていたような気がします。
ここに書いたことはあくまで記録です。CXOをまたやるつもりは今のところありませんが、もしやるとしてもコンテキストが違えば、全然別のアプローチをとりそうです👋
こんな話をポッドキャストでもしているので、よければ聞いてください💁♂️
この記事が気に入ったらサポートをしてみませんか？