1年間でMRR0→1200万突破したスタートアップでCTOがやってきたこと
こんにちは！株式会社デジタルレシピでCTOをしている古川です。
私は現在、Slideflowというサービスを開発しています。
この「Slideflow」は、
『パワーポイントからワンクリックでWebサイトが作れる』
というコンセプトで開発したサービスです。
HTMLやCSSの知識も不要で、パワポさえ使えれば誰でもファイルをアップロードするだけでWebサイトが作る事が出来ます。
2022年3月現在は法人向けのみで提供をしていますが、既に導入して頂いた企業様の例で言うと、IT・美容・飲食店・士業など、業種に囚われない幅広い業種で活用してもらえています。
現在も機能追加やユーザー体験向上のため、さらなる開発を進めています。
そしてタイトルにもある通り、この1年間でデジタルレシピ社はMRR1200万の売上を達成し、私もCTOとして貢献をする事が出来ました。
MRR（Monthly Recurring Revenue）は、「月次経常収益」などと言われ、会社の定期的な売上が毎月どれだけ得られているかを判断出来る指標になります。
つまり、この金額が大きいほど、事業の安定性や成長率が分かると言われています。
（なお、ここで表記しているMRRは3ヶ月以上の継続顧客売上を指しており、継続期間が3ヶ月未満の売上については含んでいません。）
もちろん、ここまでの道のりは簡単ではありませんでした。
スタートアップ企業のCTOとして、Slideflowの開発も含めてゼロから始めたので、最初の仕組みづくりやプロダクト開発は試行錯誤の連続です。
ここでは、自分の振り返りの意味も込めて、この1年で私がMRR0→1200万を作り上げるまでに私がやってきた事をまとめてみました。
今後の組織作りやプロダクト開発を目指す起業家の方や、スタートアップ起業がどんな事を考えて開発を行っているのかを知りたいエンジニアの方などに是非参考になればと思います。
そもそもCTOの役割とは？
私がどのようにこのプロダクトを育ててきたのかという本題に入る前に、ここではまずCTOの役割についてお話をさせてください。
CTO（Chief Technology Officer）は、日本語では最高技術責任者、と呼ばれます。
技術に関する意思決定を行うことは当然ですが、私は特に立ち上げ期のスタートアップにおいては「技術者」である以前に「経営者」であるべきと考えます。
私が考えていたことは主に以下の内容です。
技術によって社会にどのような影響を与えるのか
どのような形でプロダクトとして提供するのか
どのように会社を発展させていくのか
CTOとは、会社が成長していくための事業計画を作り、アクションプランを立て、初期の頃はそれを先陣を切って行動していき、会社を成長させる責任があると思っています。
もちろん中には、「技術力」そのものが会社のアイデンティティであったり、短期的な収益を考える必要がない会社もあるとは思います。
ただ、会社のキャッシュが尽きて潰れてしまったら意味がありません。
スタートアップ企業のデジタルレシピ社では、「経営者」としてのCTOの役割が求められていたということです。
これらを踏まえ、私がCTOとして実際に取り組んだ内容についてお話していきます。
組織体制の強化
最初に私がやった取り組みは、組織体制の強化です。
チームとしては1年前は役員含めて5名程度でしたが、今では業務委託の方々合わせて30名程度のチームになりました。
そこに至るまでに実施したことは、「採用の取り組み」と「カルチャー作り」の2つです。
それぞれどんな事をやったのか詳しく解説します。
採用の取り組み
会社のスケールアップに、優秀な人材は欠かせません。
新規の採用にはIndeedやWantedlyなどを利用して、外部からの人材採用の仕組みを整える必要がありました。
ざっくり以下の順序で実施しました。
各役員から必要な人員のヒアリング
その内容を元に求人の雛形を作成
採用バックオフィス担当者のアサイン
応募から面接、採用、契約書送付、契約後のオンボーディングの作成
職種を問わずオンボーディングは自分が担当しました。
オンボーディングとは、新規採用人材のサポートを行い、組織に早く定着してもらうためのプロセス作りです。
まだまだ不安定なスタートアップだからこそ、会社が何を目指しているのか、何を大切にしているのか、どのようなロードマップを描いているのか、という点を丁寧に伝えていきました。
どんなに優秀な人材でも組織の中でパフォーマンスを発揮してもらうには、円滑なコミュニケーションを生む環境を用意する必要があると考えました。
エンジニアであれば聞いたことがある人が多いであろう、Google社で唱えられているHRTの考え方（謙虚（Humility）、尊敬（Respect）、信頼（Trust）)を重視し、やるべきことをやるのは当たり前で、その上でお互いに人として尊重し合って高め合うことを大切にしています。
また、知名度が低いスタートアップに興味を持ってもらうには、魅力的なプロダクトがあることはもちろんですが、一緒に働く人たちの人となりが見えることが大切だと思います。
その一環としてWantedlyでは役員のインタビューを掲載しました。
採用の段階から人柄を見せる事で、会社の雰囲気や理念、大切にしているものなどを知ってもらおうという試みです。
こちらのインタビュー記事も自分が企画してみたのですが、2人の人柄が出ていてとても面白いのでぜひご覧ください。
川崎COOインタビュー記事
https://www.wantedly.com/companies/digital-recipe/post_articles/375715
伊藤CEOインタビュー記事
https://www.wantedly.com/companies/digital-recipe/post_articles/366968
ちなみに私自身のインタビューは今回スケジュールの関係で裏方に回ったのでまだ作成できていませんので、またの機会に載せたいと思ってます。
カルチャー作り
これは、会社内でのコミュニケーションや業務推進をどうやって行うのかという試みです。
デジタルレシピ社は、Slideflowというサービスがあるものの、戦略的にセールス主導の販売形式をとっているので、オフラインや電話対応も多めでした。
しかし、エンジニアチームは日本全国に住んでいることもあり、全員フルリモートです。
CTOである自分も、現在では完全にリモートで作業をしています。
そのため、まずは組織のコミュニケーションをリモートでも円滑に進める必要があります。
そこで当社で使用していたコミュニケーションツールのSlackをもっと有効活用していくことにしました。
Slackはチームコミュニケーションに特化した業務効率化アプリです。
もちろん単に「業務コミュニケーションにSlackをもっと使いましょう」という事ではなく、テキストコミュニケーションによる業務文化を根付かせるために、様々な試みを行います。
例えば、テキストでのコミュニケーションを最大限に活かせるよう、専用スタンプを作ったり、社内Twitter的な感じで日々のぼやきや、面白いニュースを発見したらみんなに共有して、コミュニケーションのきっかけを作りました。
みんなが自由に投稿できるチャンネルを作ったり、自分が積極的に発信をする事で他のメンバーを巻き込んで、よりコミュニケーションを促そうとしたんですよね。
仕事に関係ない話も多いですが（むしろそっちがメイン？）、結果的に社内ではSlackの普及が進み、業務のコミュニケーションもスムーズに進んでいます。
もちろん、Slack導入で終わりではありません。
経理や総務などのバックオフィス業務やフルリモートでの業務フローを、私が代表をしている株式会社ネクストライフで作った仕組みをそのまま移植させました。
ネクストライフでは2020年にオフィス移転を行い、完全リモートで約50名のパートナーとWebマーケティング業務を行っています。
そのノウハウをデジタルレシピ社でも生かして導入する事で、オンラインでもバックオフィス業務を円滑に行えるようにしました。
英語に抵抗がない方はこのZapierが出している、「 The ultimate guide to remote work」という厨二心くすぐるタイトルの素晴らしい資料があるので、ぜひご一読することをおすすめします。
マインドセットから、実際の使用ツールやルールなど事細かに記載されており、参考にできることが非常に多いです。
https://zapier.com/learn/remote-work/
プロダクト開発
プロダクト開発は、まさにCTOとしての腕の見せ所ですね。
私は当初、プロダクトマネージャー（PM）とテックリードの役割を1人で行ってきました。
CEOの伊藤さんが掲げていた「パワーポイントからWebサイトを作る」というコンセプトを元に、開発に必要な要素をまずは全部洗い出すところから始まりました。
ここでは、PMとテックリードとして、それぞれの立場から自分がどのように動いてきたのかを解説します。
PMとしてのプロダクト開発
PMはそのプロダクトでどんな人のどんな課題を解決したいのか、類似のサービス事例の調査、プロトタイピング、ユーザーヒアリングなど、今はまだ存在しないプロダクトのイメージを膨らませていく工程です。
少し大げさかもしれませんが、私は目の前の人がSlideflowを使う事でその人の世界がどう変わるのかをイメージしながら作業をしています。
そのためには、いくつかの問題提議を行い、解決方法を模索していく必要がありました。
具体的に私がPMとして取り組んだことは4つあります。
①技術的な観点からフィージビリティスタディの実施
これは簡単に言えば、開発するプロダクトが実用可能なのか、どのような技術を使うことで実現できるのか、どのような選択肢が取れるのかを考える事です。
せっかく思い描いたサービスが絵に描いた餅では意味がありません。
サービスとしての理想と、実現可能な技術のギャップをすり合わせる必要がありました。
②ユーザーの視点から見たプロダクトの評価
これは、開発するプロダクトが「誰の、どんな課題を、どうやって解決するのか」を明文化する作業です。
あらためてユーザーファースト、課題ファーストに立ち返り、技術者としての視点ではなく、一般ユーザーの視点で物事を考えるということです。
その上で、海外サービスのリサーチ・検証を行います。海外サービスを20個くらい実際に課金してUIや機能を書き出していきました。
このようにユーザー視点でサービスに求められていることはどういうものなのかを突き詰めていきます。
③各種資料の整備
エレベーターピッチや、インセプションデッキの作成を行いました。
エレベーターピッチはサービスのことを30秒で説明する資料、インセプションデッキはプロダクトの全体像をメンバー全員が共通の認識として持つことが出来るようにするための資料です。
PMとして開発の目的や方向性、何を優先すべきか、コストや必要なスキルの把握、開発環境の整備をするにあたり、このような資料に起こしていく必要があったのです。
この辺りから自分の脳内にあったものをしっかりと明文化して、周りの人にも見せていきつつ人を巻き込んでいきます。
もちろん、最初から全て言語化することは難しいですが、この工程を通じて、自分がきちんと整理できていなかった部分や曖昧だった箇所がわかるので、大事な工程です。
特にエレベーターピッチは短い間で聞いた相手に
このサービス面白そう！お金を払ってでも使いたい
これはまさに自分のことを言い当てられている、やば！
自分もこのサービスを一緒に開発したい！
という気持ちにさせることが大事なので、いくつかパターンを作って試していました。
④組織にユーザーの解決したい課題を問い続ける
ここは日常業務の話になるのですが、私はCEOやCOOからの機能追加に関する要望に関して、多くの「No」を言い続けてきました。
これは、解決したい課題の本質が「機能の拡張」によって実現するものなのかを組織に問い続けるためでした。
意見をもらうことがあっても、多くの場合は「こういう方法で代替できますよね？」とか「欲しい機能単位の話ではなくて、ユーザーが困っていること、解決したいことってなんですか？」という質問で返していた気がします。
もちろん、単にNoを突き返すだけだと、「意見を言っても聞いてくれない人だ」と思われてしまいます。
そうならないために「プロダクトの軸はここだよね、その人が本当に解決したいことってなんだろう？」というディスカッションをした結果として「No」を伝えるようにしてきました。
テックリードとしてのプロダクト開発
PMがプロダクトの全体管理をする立場なら、テックリードは実際に開発を進めていく立場になります。
はじめのうちは、多くのスタートアップがそうであると思うんですが、ほぼ1人で開発をしていました。
私自身、学生時代から個人事業主として、Web系の開発に制作にディレクターやエンジニアとして気づけば10年近く関わっていたので、プロダクトのイメージは自分の頭の中にはっきりとあり、これを一気に作りたかったのです。
プロダクトがある程度形になってきた頃、徐々にエンジニアを増やしていき、1年経って現在は
社員1名（2月に入社。エンジニア1人目！嬉しい！）
フリーランスでフルタイム1名
正社員として働きながらの副業 2名
開発会社から2名
の6名体制になりました。
エンジニアの方たちは、別のプロジェクトで一緒に仕事をしていた方に声をかけたり、Indeedで応募してきた方、自社採用ページから応募をしてきた方達です。
開発フローとしては、一般的なGitHubフロー、ZenHubでの簡易スクラムでやっています。
フルリモートで副業メンバーがメインのチームで、どのようにスピード感と質を保った開発を行えるように工夫しているかについては、別の記事で書いてみようと思います。
この1年でCTOとして感じた課題
私自身、この仕事を楽しんで取り組んできましたが、もちろん進めていく中でいくつもの課題はありました。
ここではそんなSlideflowを開発する中での個人的な課題などについて述べてみたいと思います。
課題思考ではなく、プロダクトありきの思考になってしまった
Slideflowは『パワーポイントからワンクリックでWebサイトが作れる』というインパクトもあってサービスを説明すると多くの方から「すごいじゃん！」と言ってもらえました。
一方でコンセプトが先行してしまい、いざ開発の過程や現状の問題点を洗い出してみると、解決しなくてはいけない課題は思っていた以上にたくさん見つかりました。
例えば、「課題を解決したい」という課題解決思考と「パワポからWebサイトを作る」というプロダクト思考が脳内バトルを繰り広げて、その迷いが実際のリリースタイミングにも影響がでてしまいました。
ここに関しては常に発生するものだとは思うので、引き続きうまいバランス感覚を持ち続けていきたいところです。
サービスに対するプレッシャーも感じていた
上で挙げた開発に関する困難は確かに大きな課題でしたが、それは表向きの理由で、本当のところ私自身、期待値の高いサービス故にそこへ答えなくてはいけないというプレッシャーも大きかったと思います。
Slideflowはサービスの事前登録の段階で2020年12月にバズって最初の1週間で3000人以上、その後、約半年間で6000人以上の方に登録をしてもらいました。
もちろんそれだけの人達がサービスを待ってくれている事は私自身、とても嬉しい事です。
でも逆に言えば、それだけの人たちが事前登録をして待ってくれているということです。
その期待に答えようと、私はユーザーファーストの視点を常に持ってプロダクトの開発に取り組みました。
しかし、考えれば考えるほど「この人たちは何に困っていて、何を求めている人なんだ？」という事に悩みました。
そしていろいろな課題を突き詰める度に、「この課題の解決策は、Slideflowである必要性はない」という結論に至った事も多々あります。
たくさんの人が期待しているからこそ、その人達により良いサービスを届けたいという想いが、プロダクト開発をより難しいものにさせていたと思います。
とはいえ、この経験があらためてサービスを俯瞰して見る機会を作ってくれたので、結果的に必要なプロセスであり、良かったと思っています。
営業チームが1ヶ月で50サイトを作るという目標を達成した！
紆余曲折がありながらも、Slideflowは2021年夏頃には非公開ながらもサービスとして実用段階に入ります。
ここで、実際に営業チームでSlideflowを使ってLPやホームページ作成を請け負ってみようという事になりました。
この時のSlideflowの訴求軸としては、『とにかく早くできること』を徹底的な強みとして、喋るだけでサイトができる「Talkflow」という形でリリースしました。
そこで「1か月で50サイトを作る」という目標を掲げました。
ちなみにここで立てた「50サイト」という数字は定量的な根拠がある数字ではありません。
簡単には達成できないけど、みんなで頑張れば達成できる、くらいの数字で会議中に自分がパッと言った数字です。
みんながこの目標に納得してくれたのは、それだけこのサービスに自信を持っていたからでした。
さて、結果はどうなったかと言えば…。
なんとこの目標を見事に達成する事が出来ました！
もちろんクライアントにサービスを魅力的に感じてもらえた事も理由ですが、営業チームの力があってこそ達成出来た事なので、みなさんには本当に感謝しています。
そして現在では、商品設計もブラッシュアップを行い、ここからのリファラル、つまり知り合いや既存顧客からの紹介のおかげもあって、MRR1200万を達成する事が出来ました。
これは3/18に正式リリースのプレスリリースを出すまではほぼ紹介だけで達成した数字です。
目の前の人を楽にさせたいという想いでプロダクトを作る
私は、「まずは目の前の人を楽にさせたい、助けたい」という考えを大事にしています。
なぜなら、目の前の1人も幸せにできないのに、その延長にある世界を幸せにすることなんてできないと思っているからです。
実際、これまでに「世界を変える！」とか「イノベーションを起こす！」とか言っている人で人遣いが荒かったり、身近な問題を解決出来ていない経営者を何人も見てきました。
少なくとも私の周りではその経営者がその後上手くいったという話を聞きません。
目の前の問題が解決していないのに、その先の未来にコミットすることは難しいのではないでしょうか。
目の前のたった1人を助けることができないのに、顔も名前も知らない「誰か」をハッピーにすることなんてできないと思うんです。
プロダクトを作る上でもこの考えは同じで、「売れるサービスを作りたい」ではなく「目の前の人がどんなサービスを使えば喜ぶか」を考えます。
プロダクトが「正しく」作られているかの評価として、プロダクトマーケットフィット（PMF）という概念が挙げられます。
これは、自分達が売り出したい市場（顧客）にプロダクトが適合するのかを評価するというものです。
このPMFがよくプロダクトの分岐点に挙げられますが、法人向けのプロダクトの場合には、まずはオペレーションフィットが大事だと考えています。
これは、提供したプロダクトが実際にどの業務に置き変わるのかについて考えるというものです。
例えば、Slideflowのコンセプトである「パワーポイントでWebサイトを作る」ですが、サービスを使って欲しい人をもっと具体的に落とし込んでいく必要があります。
パワポを簡単に使っている人向け？パワポを難しいと感じる人向け？
Webサイトって一言で言っても、名刺代わりのとりあえずサイト？広告をガンガン回すサービスLP？
事業会社で自分達用のサイトを作る？制作会社でクライアントワークのサイトを作る？
キャッチコピーを見た人は、パワポでサイトが「作れる」ことなのか、それともパワポで「編集できる」ことに魅力を感じているのかどうなんだろう？
もちろん最終的に全てをカバーしたいとしても、リソースは有限なので、しっかりと取捨選択をしていく必要があります。
顧客像をしっかり絞り込んでから業務フローの解像度を上げて、Slideflowが業務の中でどう置き換えるのか、そのために必要な機能は何かを考えて実装することを繰り返しました。
まとめと今後の課題
以上が私がこの1年でやってきたことです。
プロダクトの方針決定、開発を行い、採用フローや広報やバックオフィスの整備なども行ったことで、他の役員や営業メンバーが内部のことを気にせずドンドン攻めていくことができたのではないかと思っています。
今後の課題としては、
7月までにMRR 2500万突破する
開発チームは現在6名体制ですが、7月までに16名まで仲間を増やす
マーケティング、セールスチームは正社員を中心に月間数名ずつ仲間を増やす
というわけで絶賛採用中です。
非合理的な動きをできるだけせず、主体的かつ自律的に働きたい、という人にとってはとてもマッチする環境だと思います。
少しでも、Slideflow・デジタルレシピ面白そう！自分も一緒に開発をしていきたい！一緒に働いてみたい！と思った方はお気軽にWantedlyや、古川のTwitterDMまでご連絡ください。
業務委託・副業・正社員問わず募集中です。
https://www.wantedly.com/companies/digital-recipe/projects
最後までご覧いただきありがとうございました！
この記事が気に入ったらサポートをしてみませんか？