受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入5000社に行くまでの振り返り

2024年1月9日にboardの有料登録社数が5000社を突破したので振り返りです。

boardの正式リリースは2014年8月20日なので、約9年半ほどで、推移はこんな感じでした。

＊「社数は累計ですか？」と聞かれることがよくあるのですが、累計ではなくその時点のアクティブな数です。

 

1000社刻みで定点観測的に書いているので、過去の記事も貼っておきます。

受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入1000社に行くまでの経営・受託とのバランス（BPStudy発表時の補足）

受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入2000社に行くまでの振り返り

受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入3000社に行くまでの振り返り

受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入4000社に行くまでの振り返り

 

boardとは

見積書・請求書の作成から業務管理・経営管理などを行うことができるサービスで、主に数人〜数十人規模の小規模な会社をメインターゲットとしています。

自分自身が会社を経営する上で欲しかったものを作るというのが開発のきっかけで、今でもメイン開発者として開発を続けています。

 

基本的なスタンス

会社の規模をどんどん大きくしていくことはせず、「10人の会社で1万社が使うサービスを」という方針で会社およびサービスを運営しています。

「10人」という数字にこだわっているわけではなく（現在11人いますし）、「小規模な会社を維持する」「事業の成長を人数で解決しようとしない」ための目安みたいなものです。

現在のboard関連へのアサインは、自分を含めエンジニア4名、サポート4名です。

弊社の働き方は、勤務時間を1時間短くしたり、基本的にほぼ残業もありません。機能リリースを急ぐことよりも、無理のない持続可能なペースで、安定して高い品質の開発・運営を維持することを目指しています。

また、これまで同様、営業も広告もやっておらず、口コミと検索からの流入という受け身のスタンスで運営しています。

こんなスタンスで運営しているので、急激な成長というのはなかなか難しく、「2ヶ月前後で純増100社」というのがここ数年のペースで、そこからさらに成長スピードを上げるということができていません。

今のような「営業をしない、広告も出さない」というスタンスでいつまでも伸ばせるものではないと思っており、ここ数年、「いつか急激にペースが落ちそう」と思ってたのですが、なんとかこのスタンスで5000社まではあまりペースを落とさずに到達できました。

 

4000社→5000社の期間の大きなトピック

4000社到達が2022年4月でしたので、この2年弱ほどの期間にあった大きなトピックについて書いていきたいと思います。

法改正対応（電子帳簿保存法・インボイス制度）

ここ1〜2年は、開発もサポートも、やはりこのトピックが中心でした。

「法改正需要でかなり伸びたのでは？」とよく聞かれるのですが、冒頭のグラフの通り、わりと今まで通りのペースといった感じです。むしろコロナ禍に入ったころの方が伸びた気がします。

法改正は、SaaSに限らず関連する業界にとっては商機なので、やはり各社、マーケティング・プロモーションに相当の力の入れようだったように思います。

そんな中で、うちはこれまでとあまり変わらないスタンスといいますか、露出を増やすような施策は全然やっていないので、完全に露出負けしてたというのが正直なところで、こういうタイミングだったわりには大きく伸ばせなかったですね。

露出負けしている自覚はあったので、むしろ、なんとか今までとあまり変わらないペースでは伸ばせたので「思ったよりも良かったな」という印象です。

一方で、開発・サポートにおいては当然ながら法改正対応はしっかりと進めており、CSチームにいる元経理のメンバーの大活躍や、アドバイザーをやってくれている税理士さんのアドバイスもあって、関連機能はいい感じで仕上がったと思っています。また、実際に使用している方からも評価していただいています。

この辺は商売が下手だなと思うところですが、自分自身、経営者よりも作り手側の意識の方が強く、「事業を伸ばす」という観点では弱いところだなとは認識しているのですが、急に違うことをやってもうまくいかないので、今後も良いプロダクトと良いサポートを提供することで、事業を伸ばしていきたいなと思っています。

法改正対応の副産物

法改正対応はそれだけやっても面白くないというか、ユーザーさんの業務改善に直接的に繋がるわけでもないですし、プロダクトの強化に繋がるわけでもないので、個人的には、単に法改正対応するだけだとあまり面白みがないんですよね。

なのでここ数年は、法改正対応を実現する過程で、よりプロダクトを強化できる仕組みに変えていき、その延長線上で法改正に対応していくということをやっていました。

この結果、より多くのシチュエーションに対応できるようになったり、イレギュラーな業務に対応できる可能性が増えたり、そういった柔軟性が向上しました。

これらは、直接的に何か大きく影響するというよりは、既存ユーザーさんにとって運用上の課題を減らせたり、今は問題なくても将来的に課題になる可能性を減らせたり、お試ししている方がboardを使ってもらえる可能性の向上したり、サポートコストの低減に繋がったりするので、そういうチリツモな効果が期待できるのではないかと思っています。

開発体制

自分を含めてboard本体で3人、自社開発をしている問い合わせ管理システムで1人という4人体制で、ここ数年、人数もメンバーも変わっていません。ちなみに今でも僕はバリバリ開発しています。

最近は、1人1つずつ大きめの開発を3ヶ月〜半年スパンくらいで持ちつつ、その他の細かいタスクを平行してやっていく、というスタイルが定着しています。

大きめの開発は、法改正のような期限があるもの以外は、基本的には期限を決めていません。「このくらいにリリースできると良いかなあ」くらいはありますが、頑張ってそれに間に合わせるということはしていません。

もちろん早くリリースできた方がユーザーさんに早く価値を提供できるので良いですが、それよりも完成度の方が大事なので、とくに期限は設けず、じっくり時間をかけて開発するようにしています。

並行してやっている細かいタスク系は、最近みんなが勝手に拾ってやってくれることが増えてきていて、とても良いなと感じています。それぞれ強い分野・関心がある分野が違うので、メインのタスクを持ちつつ、それぞれの視点で改善点を見つけていっているという状況です。

サポート体制

CSチームは、この期間で1人減って1人増えたという状況なので、ほぼ4人体制でした。

インボイス制度開始時の前後はかなり問い合わせが増えましたが、それ以降は平常時に戻っており、有料登録社数の増加に対して問い合わせ数の増加はかなり抑えられています。そのため、4人体制であれば、ある程度余裕のある状態、休みを取りやすい状態を維持できるので、当面は4人体制が適正かなと考えています。

現在のCSチームは、「元エンジニアでサポートキャリアが長いメンバー」「元編集者で文章のプロ」「元経理 x 2」という4人で構成されていて、かなりレベルもバランスも良いと感じています。

また、みんなしっかり時間をかけてレベルアップしていく姿勢があり、毎日のサポート時間終了後に、その日のすべての問い合わせに目を通し、改善点や、よりわかりやすい回答のためのフィードバックなどをしあっていて、まだまだ良くなりそうで楽しみです。

とくにここ1〜2年のインボイス制度関連では、元経理のメンバーが大活躍でした。国税庁の資料をしっかり読み込み、問い合わせに対して適切に対応するだけでなく、開発へのフィードバックもたくさんありとても助かりました。

また、法改正のタイミングでは、どうしても問い合わせ内容もそれ関連のものが多くなり、業務的な理解度によって、回答のレベル感がかなり変わってきます。そういった中で、元経理のメンバーが中心となり、CSチーム全体の業務知識のレベルアップにも繋がったので、とても良かったなと思います。

 

boardのサポートは、有料1300社くらいまでは、僕の1人体制でした。僕自身、boardの開発者なので隅から隅までよく知っていますし、プロダクトオーナーなので仕様の意図もよくわかっているし、会計や経理の話題もある程度わかるので、知り合いからたびたび「このクオリティーの回答が即レスで返ってきたら絶対に他の人に引き継げないのではw」と言われてました。

業務背景や仕様の意図を理解しているかどうかは、回答のポイントの「微妙なズレ」を防ぐためにものすごく重要で、でもここは、説明したからといって、そうそう簡単に身につくものでもないんですよね。

自分自身、CSチームができるまでの4年間ほどは1人でがっつりサポートをやっていたので、サポートとしてのスキル・経験もしっかり身についた上で、現在でも毎日すべての問い合わせを確認し、必要に応じてCSチームにフィードバックを続けています。代表や開発者がこれだけサポートに時間を割いているケースも珍しいのではないかと思うのですが、それくらい重要な位置付けとして考えています。

こうやって何年もかけて、CSチームの業務理解度・仕様理解度の向上に取り組んできました。そして現在では、僕の方が良い回答を書けるであろうケースはかなり少なくなって、もうだいぶ出番は減ってきました。

 

ちなみに、「サポートの質の改善はどうやって取り組んでいるのか」ということをよく聞かれるのですが、ざっくり言うと、

• 読解力の向上とその背景にある本質的なゴールを捉える力（業務理解や行間を読む力など）を上げていく
• わかりやすい文章および構成のための文章力を上げていく
• 多様な視点・状況があることを理解し、それを想像するための引き出しを増やしていく
• マニュアル対応にならず、1つ1つ丁寧に個別ケースとして対応していく

ということを愚直にやっているようなイメージです。

文章の読み書きのレベルをひたすら上げていくという取り組みは、社内に元「本の編集者」がいるのは強いですね。一般的な「文章がうまい」とはまったく別次元です。

多様な視点を持つという点では、サポートキャリアが長いメンバーはさすがですし、元経理のメンバーは、実務経験者ならではの理解ができるので、チームとしてとてもバランスがよく強いなという感じです。

そしてチームとして大事なことは、なあなあにならず、指摘することはきちんと指摘しつつも、攻撃的にならずにニュートラルで建設的なフィードバックを続けられること、ですね。

問い合わせ窓口のシステムの自社開発

約3年ほど前に、問い合わせ窓口のシステムを自社開発に切り替えました。

tamukai.blog.velc.jp

「エンジニアが数人しかいない小さい会社で、ここにコストをかけるの！？」と散々言われたのですが、これは本当にやって良かったなと思っています。

boardでは、サポートは本当にコアな位置付けと考えていて、その業務改善のための投資をしているようなかたちです。

高品質なサポート対応を継続的・安定的に提供するということは、本当に難易度が高い仕事です。日々たくさんの問い合わせの対応をするので、当然、うまく話がかみ合わないケースや、人為的なミスが発生する可能性もあります。また、ごく稀にですが、理不尽な問い合わせによって大きなストレスがかかることもあります。

そういった状況下でも、CSメンバーがその能力を安定的に発揮できるよう、システム的に手助けできることをやっていき、業務や仕組みを洗練させ、気にするポイントを減らして、可能な限り快適に業務ができるような環境を作っていっています。

問い合わせ管理のSaaSはたくさんありますが、自社開発することで、上記のような部分を追求していけるので、自社開発に切り替えたのは、本当に正解だったなと感じています。

障害対応訓練

以前、以下に書いたように、障害時を想定した対応訓練を行いました。

tamukai.blog.velc.jp

tamukai.blog.velc.jp

その後、障害時の対応はある程度スムーズにできるようになってきたので、少し違う系統の対策として、「田向が交通事故に遭って急遽連絡がつかなくなった」場合を想定して、CSチームからのエスカレーション体制の冗長化などの準備を進めました。

boardはもともと僕の1人プロジェクトだった経緯もあり、サポート対応の中でのエスカレーションなど、僕のみが行っている業務が残っていました。

そういったものをリストアップし、それぞれごとに対応方針や引き継ぎなどを行い、体制の冗長化を進めました。

準備がある程度できて、実際にその想定でテスト運用してみた後に僕がコロナに感染して、高熱が続いて3日間ほど何もできなかったのですが、問題なく運用できたので準備は大事だなと痛感しました。

 

boardの事業的な話

有料登録数の増加ペース

有料登録数の増加ペースは、多少の増減はあるものの、おおよそ「約2ヶ月で純増100社」というペースで、これはここ3〜4年ほどと同じ水準です。

2020年前半ごろは「1.5ヶ月で純増100社」ペースだったのですが、これはコロナ禍の影響もありそうです。また、2023年10月・11月は「1ヶ月で純増100社」に近いペースでしたが、これは完全にインボイス制度の駆け込み需要のため例外ですね。

ここ4年ほど、ペースは上げられていないものの、ある程度維持はできているという状況です。

これについては、4000社のときにも書いていますが、「営業をしない（いない）」「広告を出さない」「露出の機会がほとんどない」「お試し登録後もこちらからアプローチはしない」というスタンスでは、このくらいのペースが限界なのかなあと感じています。

そして、ここ数年ずっと思っていることですが、今の完全に受け身のスタンスで、いつまでも事業を伸ばせるということはないだろうなと思っています。

ということで、もう少し先になりますが、弊社初のマーケメンバーが入社することになりました。とはいえ大幅にスタンスを変えるということではなく、boardらしさを保ちつつ、より事業を伸ばせる方法を模索していこうと思います。

＊実は、冒頭のグラフでも少し雰囲気がわかるかもしれないですが、2023年に入ってすぐはちょっとペースが遅くて、「お、いよいよか」と思ったのですが、その後は、元のペースに戻ったというのがありました。

有料継続率

2014年のリリース以降、ほとんどの期間で99%台を維持しており、とくにここ数年は、99.5%前後という状況です。

とくに何か手を打っているわけではないので、基本的には、プロダクトやサポートの質の向上によるものではないかなと考えています。

業務システムは、基本的には合う合わないがありますし、この数字を改善していこうという意識ではやっていないのですが、プロダクトとサポートをより改善していければ、結果として、継続率もより良くなっていくのではないかと思っています。

 

その他の取り組み

アクセシビリティー

取り組みとしては大きく変わらず、今までの取り組みを継続しています。

以下、参考までに過去のブログを紹介します。

tamukai.blog.velc.jp

tamukai.blog.velc.jp

引き続きディーゼロさんに支援してもらいながら、毎週のデプロイの中で少しずつ改善していっています。

各種支援活動

boardでお世話になっているOSSをはじめ、以下の活動の支援を継続的に行っています。

• カラーユニバーサルデザイン機構（色覚多様性への取り組み）
• azu（textlintなどの開発者）
• NV Access（スクリーンリーダーの開発）
• MUI（MUIの開発）
• Rubyアソシエーション
• Railsガイド

 

5000社を超えて、今後・・・

これまで、プロダクトとサポートの質の向上をひたすら地道に続けてきたわけですが、今後も同様のスタンスで取り組んでいくつもりです。

ありがたいことにboardの事業を評価していただいて、「どうやって伸ばしているか話を聞きたい」と聞かれることがたびたびあるのですが、boardでやってきたことはシンプルで、「自分事としてドッグフーディングしながらプロダクトを開発し、地味な改善をひたすら続けること」「プロダクトとしての軸をぶらさないこと」「サポートの質を最大限上げること」、そしてとにかくそれを「ずっと継続すること」でした。

小さい会社は、どうやっても知名度で勝負することはできず、中身を見ずに「○○は有名だけど、boardってよく知らないので、○○にしよう」ということはよくあります。

「小さい会社を維持する」という方針で会社をやっている以上、知名度負けする状況を変えることはかなりハードルが高いので、提供しているプロダクトとサポートの質で勝負するしかありません。そのため、今後も引き続きそれを続けていきます。

5000社に行くまで約9年半かかったわけなので、これだけ時間をかけるということは、スタートアップだとなかなかできないやり方なのかなという気もします。ただ、うちは資金調達をしているわけでもなく、自分たちでできる範囲のことを地道に継続してやっています。

そしてこれまでを振り返ると、1つ1つが小さくても、時間がかかっても、とにかく「継続すること」というのは、本当に大事だなと感じています。

そんな感じで、今後も引き続き、持続可能なペースで、より良いプロダクト、より良いサポートを提供できるようにしていきたいと思います。