ヴェルク - IT起業の記録

受託開発と自社サービスの両立への取り組み

boardのCSで大事にしているスキル

boardはβリリースから約4年ほどは、ほぼ僕が一人でサポートをやってきました。

昨年前半にCS専任のメンバーが入り、一年ほどかけてスキル移管をしつつ、徐々に体制をシフトさせていっているのですが、その過程で、boardのサポートで最も重要なスキル・大事にしているスキルが、自分の中で明確になってきたので書いてみたいと思います。

 

boardのサポートについて

boardは、見積書・請求書作成を中心とした業務管理・経営管理のB2BのSaaSです。

そのため、問い合わせは主に「○○という業務をやろうとしているけどどうすればいいですか」「○○という機能はありますか」などの使い方・機能の有無や、業務に合わせてどういった使い方をしたらよいか、といった質問が多いです。

サポートはチャットのみで、電話でのサポートはやっていません。
*チャットはintercomというサービスを使っています。

現在、有料導入社数は約1900社で、それをCS二人体制で余裕を持って運用できています。

また、サポートの回答時間の中央値を公開していて、2015年11月以降、10分以下を継続しています。

ユーザさんからは、「今回もさすがです。短期間で解決に辿り着けました。最高のサポートでした!」「こんな情報が少ない質問で的確に切り分けして頂いて、ありがとうございます!」などのようなコメントを頂くなど、それなりに評価して頂いていると思っています。

あとはこんなことを言って頂いていたりします。

どちらのコメントも開発者としてもとても嬉しいのですが、CSとしては 「サポートの的確さ」というのはとても嬉しいですね。

 

boardのサポートの一つの強みは、やはり僕自身がやっていたことは大きく、同時に大きな課題でもあります。

僕の場合、経営・会計・経理周りがわかるし、メイン開発者なのでシステムを隅から隅まで知っているし、長く業務システムの受託・コンサルをやってきているので、多くの業務・企業を見てきて引き出しも多いので、相手の状況を想像しやすく、わりとどんな質問がきてもすぐに対応できて、たぶんそれなりのクオリティの回答ができています。

ただ、これを他のメンバーが一人で同じことをやるのは難しいのは重々承知で、とはいえ、サポート品質を大きく落とすわけにはいかないので、引き継ぐにあたって、何を大事にするか、というのをずっと考えてきました。

boardのサポートは能動的なアクションせず受け身だし、ユーザの行動は分析していないし、KPIはないし、ハイタッチなどの分類もしていないので、おおよそ最近のカスタマーサクセスとは異なる方向性に力を入れているのですが、サポートの本質はコミュニケーションと課題解決だと思うので、「一回のやり取りで一発で解決すること」を理想として、ここのスキルアップに全力を注いでいます。

 

サポートにおけるコミュニケーションの難しさ

コミュニケーションはほんとに難しいと思っています。

口頭で話す際は、その場の雰囲気だったり流れだったり相手に関する知識だったり、様々な情報を元に、コミュニケーションギャップが生まれないように補完しながら話していると思うのですが、チャットサポートというテキストコミュニケーションだと、それらの情報が抜け落ちてしまい、コミュニケーションの曖昧さがより顕在化するんじゃないかなあという気がしています。

特にサポートにおいて難しいポイントがいくつかあります。

相手の基礎情報の不足

普段一緒に仕事をしているメンバーでもコミュニケーションギャップは生まれてしまうのに、サポートの場合、一度も会ったこともないケースが大半です。
しかも、相手がどういう立場・役割なのか、どういう業種なのか、システムに慣れているのかそうでないのかなど、基礎的な情報が全く無い中で対応します。

わからないことを質問する難しさ

自分自身もそうですが、質問する側の立場からすると、「わからないことを質問する」というのはとても難しいことだなと思います。

そのため、質問の文面だけでは状況を把握できないというケースもよくあります。

複数の選択肢があるケース

例えばboardの場合、「発注書」というのは受注・発注の両方にあります。
受注側:顧客から自社にもらう発注書で、こちらで用意し、捺印して返送してもらうためのもの
発注側:自社から発注先へ発行する発注書

そのため、「発注書について質問です」と言われると、「どっちの発注書か」というのがわからないと回答できないのですが、ユーザさんの立場からすると、そもそも2つあることを知らないかもしれないし、知っていたとしても、普通はなかなかそこまで考慮して質問するのは難しい気がします。

「担当者」も「自社の担当者」や「顧客の担当者」などがあるので同じですね。

このように、1つの単語から複数の選択肢があり得てしまうケースもよくあります。

board上に存在しない用語

異なる用語でも同じ意味を示すものは多くあり、業務上使われる用語は会社や業界によって様々です。

質問を頂く際、やはり普段使っている用語を使うことが多く、board上に存在せず、かつ、こちらとしては普段使わない用語だったりすると、board上の何のことを指しているのかわからないことがあります。

直接関係ない情報

ユーザさんは仕様を熟知しているわけではないので、「関係がない情報」が多く含まれていることがあります。

ただ、読み手(CS)側からすると意外とそれらに惑わされがちです。

本来の目的が抜けてしまっている質問

色々と試行錯誤をして頂いた結果、やはりわからずにお問い合わせ頂くケースでよくあるのが、本来の目的(やりたいこと)が抜けてしまっていて、試行錯誤した最後の段階の部分の質問だけが書かれていることがあります。

この場合、質問に対してだけ答えると、ユーザさんが本当にやりたいことではないということになってしまいます。

あの「顧客が本当に必要だったもの」の図でも、「顧客が最初に説明していること」自体が「本当に必要だったなもの」とズレていますが、サポートでも、これはよく起こることだなと思っています。

 

これらの難しさに対応するスキル

前述のような「難しさ」を適切に扱えないとどうなるか。

ユーザさんから見ると、「解決までに時間がかかる」「何度もやり取りが発生してしまう」「質問の意図が伝わらずイライラ」という、よくあるサポートに対する不満になってしまいます。

ユーザ体験というのはシステムだけのことではなく、サポートもboardの大事なユーザ体験の一つだと思っています。

そういう点で、サポートにおけるコミュニケーションの難しさをうまく扱えるスキルがとても重要だと思っています。

これまでのブログにも何度か書いていますが、小さい会社なので全方位に力を入れるだけのリソースはありません。各分野で何か1つ、強みになるレベルに引き上げるまで集中してやるというスタンスでやっていて、サポートの場合はこのコミュニケーションの部分です。

サポートで必要なコミュニケーションスキルというのは、うまく話すこととかではなく、「適切に理解して簡潔に説明する」ということだと思っています。

でも、これがとても難しく・・・。

ポイントは読解力・想像力・文章力だと思っていて、それらの向上に取り組んでいます。

読解力と想像力

「サポートにおけるコミュニケーションの難しさ」の中で書いたとおり、質問者がやりたいことや質問の意図を、文面から正確に把握するというのはとても難しいです。

とはいえ、何度も確認していたら、ユーザさんからしたら面倒ですよね。

そのため、「いかにして限られた情報から質問の意図や本質を把握するか」というのが、スムーズで居心地の良いサポートには不可欠だと思っています。

これには、例えば、以下のようなものの組み合わせが必要になります。
・文章の読解力そのもの
・書かれている情報の要否の切り分け
・可能な限り集められる情報
・相手の状況の「想像」するための想像力。それを可能にする業務や機能の知識
・エスパー(行間以上のことに気づく必要があるケースもある)

エスパーは別として、それ以外については、CSメンバーの育成の中で、「なぜこう解釈したのか」「なぜこういう切り分けをしたのか」ということを論理的に分解しながら解説しています。

これには純粋な「読解力」は不可欠なので、まずは日本語力の強化がベースになります。

その上で、可能な限りの情報を集めて、想像する上で必要な情報を補足していきます。

例えば、以下のようなことをやっています。
・利用開始時期やログイン回数から、使い始めなのか、使い慣れているのか
・コーポレートサイトを探して、業種や規模を確認
・どういった立場なのか(役員だとコーポレートサイトに掲載されているので判断ができる)
・ユーザ権限(管理者なのか担当者なのか)
・質問の内容から、経営者・経理・営業などの職種を想像
・質問の仕方でシステムを使うことに慣れてそうか

質問文の読解に加えて、上記のような情報を合わせて、相手の状況や質問の意図の把握をしていきます。

また、相手の状況を想像する力は、やはり業務的な背景や商習慣の引き出しがものを言います。
これは、時間をかけて増やしていくしかないので、僕が日々の問い合わせを題材にCSメンバーに説明したり、「boardはなぜこういった仕様か、どういう業務を想定しているのか」ということを毎日1トピックずつ書いて共有するなどして伝えています。

わかりやすく伝える文章力

これは自分自身にも言えることなのですが、どうしても色々詰め込みすぎたり、余計な言い回しが多くなって、文章が冗長になりがちです。

なるべく簡潔に無駄な情報がなく、わかりやすい文章を書いていくことで、すっと読むことができます。

特にサポートの場合、読み手に考えさせてしまうような文章はダメだと思っているので、そういった文章力を上げる取り組みをしています。

日々の回答の際は、僕がCSメンバーの文章を校正していたのですが、より改善するため、board初期の頃に広報を手伝ってくれていた方に、「広報の視点でサポートの文章を改善する」という取り組みを月一でやってみています。
*これはとても良い効果があったので、また別途書ければと。

コミュニケーションギャップに気づく仕掛け

どれだけ気をつけても、コミュニケーションギャップは必ず生まれてしまうと思っています。

そのため、「それに気づくことができる仕掛け」を回答の中に入れることがあります。

簡単な例で、例えば「一覧で○○(項目名)を出力することはできますか」という質問があります。

これは、以下のいずれのケースもあり得ます。
・CSVに出力したい(一覧画面ではCSV出力ができるので、"出力"という単語からCSVと解釈)
・一覧に表示したい(画面表示のことを出力という方もいます)

この質問の場合、対象の項目は画面表示はできるが、CSVには含まれない項目でした。

「○○を一覧画面に表示したいといことですか。それともCSVに出力したいということですか」と確認することもできますが、このような質問の場合、大半は「CSV出力」です。そのため、「CSV出力」前提で回答してもほとんどの場合は問題ありませんし、ほとんどのユーザさんからすると、その方が確認のやり取りなしで一発で解決します。

ただ、まれに「画面に表示」のケースもあるので、CSV前提で回答すると、画面表示はできるのに「対応していない」と思われて、認識のズレが発生してしまい、その方にとっては、できることなのに、それを知る機会が失われてしまいます。

そのため、質問の言葉をそのまま使って、「○○を出力することには対応していません」と回答するのではなく、「○○をCSVに出力することには対応していません」という形で情報を補完して回答します。

そうすると、「CSVではなく画面のことです」と質問者が気づくことができます。


明らかに確認が必要なケースはもちろん確認を挟むのですが、このように「ほとんどのケースではこっち」という場合、このように、質問の文面上は情報が足りないことはよくあって、それを補完しつつ回答すると、ズレがある場合に気づくきっかけになります。

コミュニケーションのズレを防ぐ努力はしますが、事前に100%防ぐことはできないので、このような感じで、ズレに気づけるちょっとした仕掛けを入れることで、少しでもズレを拾えるようにしています。

 

まとめ

サポートというのは本質的にはコミュニケーションだし、コミュニケーションはとにかく難しいので、boardのサポートは、ひたすらそのレベル向上を最優先にしています。というか、それしか取り組んでいません。


現在CSメンバーは2名いて、1名は昨年3月、もう1名は昨年11月に入社し(フルタイムは12月から)、今年2月からはどちらかが休みでない限りは、僕は必要な場合のみフォローに入る程度で、基本的には二人で回す体制にシフトしています。

「少ない人数で回す」「10分で回答する」ためには回答の効率化が必要ですが、マニュアル化して機械的な効率化を図ることはやっていません。むしろ逆で、よくある質問だと定型的な回答になりがちなのですが、マニュアル的な対応をしたことで、「間違ってはいないけど微妙な会話のニュアンスのズレ・違和感がある」というのが一番ダメだと思っていて、CSメンバーがこれをやると、僕が一番不機嫌になるパターンです。

そういった効率化ではなく、相手の意図を把握すること、素早く適切な説明ができること。これによって、やり取りの回数を減らすことで、少ない人数で素早い回答を実現するということを目指してやっています。

これは、CSに限らず、経営でも開発でもマーケティングでも共通した自分のスタンスですが、「急がば回れ」だと思っています。

 

今回は、こういうことを目指してやっているという内容でしたが、このために1年ほどかけて色々と取り組んできたので、 具体的にどんなことをやってきたかについては、また別途書きたいと思います。

SaaSの問い合わせを減らすための改善

現在、boardはリリースしてから5年目ですが、リリースから4年ほどは、サポートはほぼ自分一人でやってきたので、「社長もサポートやっている」というより「社長しかサポートやっていない」みたいな状態だったのですが、やはりリリースから3年ほど経って、導入社数が700〜800社くらいになってきた頃には、一人で対応するのがだいぶ大変になってきていました。

2年ほど前に採用したCSメンバーが、仕事内容やカルチャー的に合わずにすぐに退職することになった際、「導入社数の増加とともに、このまま問い合わせが増え続けると一人では対応できなくなるのが目に見えていてやばい」という状況だったため、本格的に「問い合わせを減らす取り組み」を始めました。

 

ちなみに、boardというサービスやヴェルクという会社は、ざっくり以下のような感じでやっています。

  • boardは、見積書・請求書の作成から業務管理・経営管理などを行うことができるサービスで、主に数人〜数十人規模の中小企業がターゲットユーザ層
  • boardの有料導入社数はもうすぐ1900社
  • 弊社(ヴェルク)は現在7名の会社で、10名前後までの小規模組織を維持したいという方針

詳しくは下記をご覧頂ければと思います。

tamukai.blog.velc.jp

 

取り組みの概要

ヘルプを見てもらいやすくするための工夫や、問い合わせが多い箇所を中心に、1〜2週間に1つずつくらいのペースで改善をしていきました。

元々、1〜2週間に1回くらいのペースで何かしらリリースしていたので、リリースペースは変えず、それに乗せていく形です。

改善対象を決めるのは、単純な問い合わせ件数ではなく、問い合わせ対応をしている中で感じた「ここをこういう感じで改善したら問い合わせ減りそう」という肌感覚を大事にして、対応箇所や方法を検討しました。

ちなみに、問い合わせが多くても、内容が複雑なものはこの取り組みではやらず、どちらかというと、ヘルプを見れば一発で解決するような簡単な問い合わせを減らすことを目的としました。

 また、問い合わせが多いということは、わかりにくい点・躓きやすい点だと思うので、そういった箇所の改善は、ユーザさんがスムーズに使ってもらうためにも重要です。

 

取り組みの成果

2018年の1年間で、有料導入社数が約700社ほど増えたのですが、その1年間の問い合わせ件数の推移が以下です。

f:id:fw_tx76129:20190314234942p:plain

 月によって上下はありますが、導入社数は増加してても、問い合わせ件数はそれほど増加傾向にはありません。

ちなみに返信数が以下。

f:id:fw_tx76129:20190314235123p:plain

 1回の問い合わせで何度もやり取りが続くことがあるので、普段は基本的には問い合わせ数ではなく返信数を見ているのですが、これも同じような傾向です。


その結果、2018年前半まで(1400社くらいまで)は自分一人体制でなんとかしのげて、2018年中盤から徐々に自分ともう1名のCSメンバーの二人体制になり、今年からはCSメンバーが二人になり、その二人で余裕を持って回せています。

1900社+お試し中の方々を、自分を除いた二名で回せている状況は、かなり良い感じだなと思っています。


以下、実際に取り組んだことを紹介していきます。

 

初回ログイン時のセットアップウィザード

boardの各種設定のデフォルトは、一般的に多そうな設定をデフォルトにしていますが、会社や業種によって、ばらけるような設定もあり、これらはどうしても問い合わせが多くなっていました。

例えば、以下のような設定です。
・見積書や請求書への単位の表示有無
・見積書や請求書での内税での入力
・窓付き封筒の利用有無

そこで、会員登録後の初回ログイン時に、ウィザード形式でこれらの設定を選んでいくようにしたところ、これらの設定に関する問い合わせは大幅に減りました。

f:id:fw_tx76129:20190314235529p:plain

ちなみに、初回ログイン時にウィザードを入れることで、ここでの離脱が増えることを懸念していたのですが、それはほぼありませんでした。

 

ヘルプ検索

元々、ヘルプページ上で検索はできたのですが、board内からヘルプの検索を直接できるようにしました。

f:id:fw_tx76129:20190315000532p:plain

これによって、ヘルプのアクセス数は3倍以上になり、簡単な問い合わせも減り、「ヘルプを見てもわからなかったので質問させてください」といった感じで、ヘルプを見て頂いた上での問い合わせが増えました。

 

ヘルプの内容の改善

boardのヘルプはかなりしっかり書いているので、ヘルプを評価して頂くことも多いのですが、「どの権限でこの機能を使えるのか」というのがわかりにくく、「ヘルプのスクリーンショットにあるメニューが表示されていない」系の問い合わせはそれなりにありました。

そこで、各ヘルプページの先頭に、その機能を利用できる権限を書くようにしました。

f:id:fw_tx76129:20190315000919p:plain

これによって、権限関連の問い合わせはかなり減りました。

 

仕様に気づく仕掛け

多くの場合、事前にヘルプをしっかり読んでから使うのではなく、操作しながら使い方を把握していくことが多いかと思います。

そのため、表面的には把握しにくい仕様は、操作の過程で「あ、こういう仕様なんだ」ということに気づくきっかけを入れるようにしてみました。

このための仕掛けは色々やったのですが、細かい仕様の話になってしまうので、わかりやすい例で、「失注」ステータスのケースを紹介したいと思います。

 

受注ステータスという受注状況を管理するステータスに「失注」というものがあります。

失注案件はデフォルトでは案件一覧に表示されなくなるため、「失注にしたものが見つからない」という問い合わせが結構ありました。

「失注にすると、デフォルトでは案件一覧に表示されない」という仕様は画面上からは把握できないんですよね。

変更時に「確認ダイアログを出す」という方法も考えたのですが、確認ダイアログって読まずに押されることが多いので、あまり効果がなさそうな気がしました。

そこで、「失注」ステータスに変更する時だけ、以下のように、失注案件の検索方法のスクリーンショット付きの確認ダイアログを出すようにしました。

f:id:fw_tx76129:20190315001213p:plain


普通の確認ダイアログよりも目立つので見てもらいやすくなり、変更前に失注ステータスの検索方法が異なることを把握しやすくなります。

この結果、失注ステータス関連の問い合わせがだいぶ減りました。

 

問い合わせが多い要望を集中的に対応

boardでは「開発ロードマップ」を半年ごとに決めて公開しているので、軽微なもの以外は、あまり途中で差し込むことはしないようにしているのですが、2ヶ月ほどの間に限定して、集中的に、問い合わせが多く、かつ「時間があれば対応したい」と思っていたものを一気に対応しました。

質問や要望が多いものを中心に対応するので、それらが対応されれば、当然その分の問い合わせは減ります。

必要ないものを無理に対応することはしないですが、「時間があればやりたい」と思っている軽微なものは、どんどん対応していった方が、お互いにとっていいなと思いました。

そのため現在では、Trelloに「軽微な改善」リストがあって、ここにあるものは、他の開発メンバーがスキマ時間に勝手に取ってやっていきPR出してもらうという運用にしています。

ちなみに、本来の開発の進捗に影響しないよう、「軽微な改善」リストは、数十分から数時間程度で終わるものに限定しています。

 

時間外問い合わせの自動返信

これは、「問い合わせを減らすための施策」としてやったものではないのですが、予想外に効果的だったので紹介したいと思います。

boardのサポートではintercomを使っていて、intercomに時間外の自動返信の仕組みはあるのですが、日本語が微妙で(今はわからないですが少なくとも当時は)、自分で初めて見た時に、意味がよくわからず「?」だったため、これをユーザさんに体験させるわけにはいかないなあと思い、使っていませんでした。

全て自分が回答していた頃は、時間外であろうと、仕事している時だったらすぐに回答していたのですが、他のCSメンバーにそれをやらせるわけにはいかないので、昨年途中から時間外は回答しないようにしました。

ただ、そうすると、ユーザさんから見ると、いつ返事が返ってくるのかわからない状態になってしまうので、自動返信の仕組みを作りました。

 

時間外に問い合わせをすると、以下のような自動返信が返ります。

f:id:fw_tx76129:20190315001809p:plain

 

仕組みとしてはシンプルで、

問い合わせ→intercom webhook→AWS API Gateway→Lambda→intercom API

という形で、intercomのwebhookとAPIを使って自分で自動返信の仕組みを作った形です。

 

自動返信自体は問い合わせ数を減らす取り組みではなく、「いつ返信がくるのかわからない」という課題の解決のために作ったのですが、この仕組みを入れてから、サポート時間外であることを明確に把握できるようになったからか、以前に比べて時間外の問い合わせが減りました。

たぶん、「時間外だから」ということでヘルプなどで自己解決したんだろうなと思っています。


ちなみにこの自動返信の方法だと、intercomの自動返信機能とは異なり、メッセージも自由に書けるし、曜日だけでなく日本の祝日・年末年始にも対応できるし、平日の臨時休業にも対応できるのでとても良いです。

 

まとめ

問い合わせ自体は気軽にして頂きたいと思うのですが、そもそも質問をしなくて使える方がずっと良いと思うので、とくに簡単な機能や設定に関しては、問い合わせをせずに気づける・自己解決できるための改善を継続することは、双方にとってメリットが大きいなと感じています。


問い合わせは改善の源泉で、これを定量的な数字ではなく、ユーザさんを肌で感じて考えることはとても大事だと思っています。

CS二人体制が起動に乗り始めたため、先月からは僕が常時回答することは減り、難易度が高いものや問い合わせが立て込んだ時、CS二人のうちどちらかが休みの時などだけになりました。

でも、今のところ、毎日全ての問い合わせは目を通していて、どういった問い合わせが多いのか、どういったことで困っているのかなど、機能追加や改善は随時あるので、それによる変化は常に追うようにしています。

 

ちなみに余談ですが、この一連の取り組みで、問い合わせ数の増加を抑えられたという効果と共に、「簡単な問い合わせ」が明確に減ったので、昨年入ったCSメンバーが、最初の頃に簡単に対応できるものが少なく、CSメンバーの最初のハードルが高くなったという副作用がありました・・・。

ヘルプのバージョン管理・編集・デプロイの仕組みを整備した話

前々から、ヘルプのバージョン管理をしたいと思っていたのですが、なかなか手が回らず放置していたところ、フリーランスで編集者をやっていた者がCSメンバーとして入社したので、それを機に、本格的に準備を進めて、今年頭から、運用を始めてみました。

1ヶ月ほど運用してみて、なかなか良い感じなので、紹介したいと思います。

ちなみに、boardという見積書や請求書作成・業務管理・経営管理などができるSaaSのヘルプです。

the-board.jp

なお、仕組みとしては、GithubのプルリクエストとWebhookを使っているだけなので、何か特別なことをやっているわけではなく、ソースコードのレビューやデプロイと同じようなことをヘルプ記事にも適用したという感じです。

これまでのboardのヘルプ

現在357記事あり、通常のヘルプが226記事、FAQが131記事あります。

通常のヘルプは、機能・仕様や効率的な使い方などの説明で、長めの記事が多いです。FAQは、問い合わせが多い質問を中心に、簡単な説明+ヘルプへの誘導という簡潔な内容です。

これまでのヘルプは、 WYSIWYGなHTMLエディタを組み込んだ管理画面を用意して、そこから登録していました。そのため、本文データはHTMLで、DBに保存されていました。

f:id:fw_tx76129:20190224173230p:plain

 

ヘルプに関しては、ユーザの方から「内容が充実していてほとんどヘルプだけで解決する」などのコメントを頂くことも度々あり、実際、有料導入1800社以上いて、CS二人で余裕を持って回せているので、かなり自己解決の役には立っているのではないかなと思っているのですが、今回の取り組みで、より安定した品質と、編集を通すことで読みやすさを改善して、さらにレベルアップさせていきたいと思っています。

今回の方針

バージョン管理を行う方法として、管理画面側に自前で実装する方法も考えられますが、今回、バージョン管理だけでなく編集・校正の運用をしたく、これをGithubのプルリクエストでやりたかったので、管理画面での自前実装はせず、Githubで管理することを軸に考えました。

そのためには、まずは、現在DBに入っているヘルプのデータをファイルにしていく必要があります。

 

ヘルプデータをファイルにするにあたって、HTMLからMarkdownにすることを検討しました。ヘルプなので、それほど複雑な表現は必要ないし、HTMLタグがない方が差分も見やすいかなと。

ただ、以下の理由で、今回は、HTMLのままにすることにしました。

  • できるだけ工数は最小限に抑えたく、ヘルプの表示側の実装は変更したくない
  • データ形式の変更に伴うテスト・内容のチェックなどの時間を確保するのが難しい
  • 表形式で表示している箇所があり、Markdownのテーブルだと厳しかった

ということで、今回は、これまで登録されていたヘルプのHTMLデータはそのままにし、ヘルプの表示側(board上でのヘルプ)の実装は変えず、その手前でバージョン管理をしていく、という方針で考えました。 

今回の仕組みと運用方法

ざっくり図で表すとこんな感じです。

f:id:fw_tx76129:20190224222706p:plain
 バージョン管理はGitを使い、校正のフローはGithubのプルリクエストを使います。

あとは、よくあるシステムのデプロイと同じように、所定のブランチにマージされたら、自動的にステージング環境・本番環境にそれぞれ反映される仕組みです。

現時点ではヘルプの運用に関わるのは、僕と@note103の二人です。@note103 はこれまで10年ほどフリーランスで編集者をやっていたので、僕がヘルプを書き、彼が編集をするという役割分担です。

なぜか普通にgitを使える編集者なので、わりとそれに依存した仕組みではあります。

 

ちなみに、長く編集者をやっていた彼が入社した経緯は本人のブログをどうぞ。

note103.hatenablog.com

 

運用フローは主に以下の2パターンです。

<新規のヘルプ>

  1. 僕が新規のヘルプを書いて、Githubでプルリクエスト
  2. @note103が編集・校正
  3. プルリクエストをマージしてステージング環境へ自動反映→最終チェック
  4. masterにマージして本番環境へ自動反映

<既存ヘルプの修正>

  1. @note103が気づいた点を随時修正してプルリクエスト
  2. 僕が内容に間違いがないかをチェック
  3. プルリクエストをマージしてステージング環境へ自動反映→最終チェック
  4. masterにマージして本番環境へ自動反映

 

上記のように、Gihtubのプルリクエストを使って運用していくため、現在、DBに入っているヘルプのデータをファイルにする必要があります。

ただ、本文のHTMLだけでなく、タイトル・メタ情報・OGPなど、本文以外の情報もあります。

そこで、以下のようにしました。

  • 本文データはそのままDBから取り出して、記事ごとにHTMLファイルにする
  • それ以外の情報は、YAMLファイルにし、1記事ごとに本文のHTMLと対になるように生成

記事ごとに、本文のHTMLファイルと、それ以外の情報を持ったYAMLファイルをセットで管理するような形です。

本文のHTMLだけファイルを分けたのは、単独のファイルにすることで、HTMLエディタで編集ができたり、Middlemanに組み込んで、ローカル環境で、実際のスタイルを当てて見栄えを確認しながら編集できるようにするためです。

ちなみに、文章をGitで管理するということに関しては、「k16's note: 執筆・編集のためのGit(GitHub)ワークフローを考えてみた」がとても勉強になりました。

ヘルプの場合は1つ1つが大きな文章ではなく、文章の骨組みの大幅な変更などはあまりないので、上記の記事にある「じっくり読まなければ何となくいい感じ」からスタートしているイメージの運用です。

この仕組みのメリット

バージョン管理という点では、ブランチを切れたり、簡単に戻せたり、いつでも過去の履歴を確認できるなど、ソースコードのバージョン管理と同じようなメリットがあります。

また、編集をプルリクエストに乗せることで、管理しやすく、差分も確認しやすいので、編集の運用がスムーズです。

ここまでは想定通りなのですが、実際に運用してみて、Githubからのwebhookでヘルプのデプロイができるのがとても良いなと。

ステージング環境でしっかり確認したものをそのまま反映できるので、本番に反映するにあたってオペレーションミスがありません。

システムのデプロイでは当たり前なんですけど、ヘルプでも、本番環境のものは当然ユーザさんの目に触れるものだし、その品質管理は重要だと思っていて、そういう点で、しっかり確認できたものを、人手によるミスがない方法で反映できるというのはとても良いなと思いました。

また、2/10に全体的なデザインが少し変わったことで、スクリーンショットを全て差し替える必要があったのですが、200以上の記事のスクリーンショットを全部差し替えて行くという作業を、管理画面のHTMLエディタでやっていたら、たぶんいくつもミスがあったのではないかなと思います。

ただ、この仕組みのおかげで、スクリーンショット差し替え用のブランチで事前に準備しておき、事前にステージング環境で入念に確認し、リリース時に、ヘルプの方もmasterにマージして自動的に反映されるという、とても楽な方法で一括反映できました。

ちなみに、約150記事を本番に反映した際、3分程度で終わりました。

この仕組みのデメリット

実際運用してみて、やはり管理画面から直接編集していた時に比べて手間はかかるので、「ちょっと修正したい」という時に面倒だなとは思います。
例えば、開発ロードマップの状況を更新するだけの時とか。

あとは、gitに依存しているので、うちの場合は、普通にgitを扱える編集者だったので良かったですが、ここはちょっとハードルにはなるかもしれないです。 

編集者視点での感想

せっかくなので、@note103に感想を聞いてみました。 

■履歴・記録を残せる

一番良いと思うのは、履歴を残せることですね。というのも、日本語の修正・編集って一発で決まるものばかりではなくて、あーでもないこーでもない、と迷いながらやることが多いので、一回決まったと思っても、「やっぱり前のが良かったかも・・」となりやすいです。

そういうときに、記録が残らない方法だと前の内容を参照することは難しいですが、バージョン管理ができると「いつでも戻れる」という前提があるので、逆に気軽にサクサク直していけるという、心理的負担が軽くなる効果があると思います。

 

■複数人で共有・分担できる

あとは、やっぱり修正した内容(差分)を他人が確認できる、ということも大きな利点ですね。これの良いところは、単に「修正内容を共有できる」というだけのことではなくて、「直す人」と「本番環境に反映する人」を分けられるということが重要だと思います。

実際の話、日本語の修正なんてある意味誰でもできるわけですが(とくにタイポの修正など)、でも本番に反映する作業は誰がやっても良いわけではないので、「直す人」がコミット&プッシュして、「反映する人」が差分を見てマージする、という分担の流れはとても効率が良いと思います。

それに関連して、もう一つ地味に大きいのが、自分でも「どこを直したのか」を確認できるのが良いですね。とくに1つのファイルにいくつも修正がある場合、自分がどこを直したかすべて覚えておくことはできないので、後から自分自身で修正箇所をチェックできるというのはメリットだと思っています。

 

■作業がラク

あとはテキストファイルで管理されているので、普段使っているエディタなど好きな環境で作業できるのもありがたいです。いつも使っている検索コマンドをそのまま使えたりして、簡便だなと。これがもし、ヘルプ管理用のブラウザの画面などで一つひとつ直していく、という感じだったら、もっと大変だったかなと。 

まとめ

履歴を管理したり、レビューをしたりというのは、ソースコードでは当たり前にやっていることだと思うのですが、同じような感じで、ヘルプでも運用してみたところ、とても良い体験を得られたのでオススメです。

この運用を始めた年明け以降、新たに追加するヘルプは全てこの運用に乗せて、編集を通しています。

既存のヘルプに関しては、日々のサポートの中で説明の仕方がどんどん改善されているので、それを反映するために全てのヘルプを頭から見直していくつもりで、それなりに時間がかかりそうですが、説明も文章も、今より一段レベルアップしていけるのではないかなと思っています。


余談ですが、編集者の仕事を間近で見るのは初めてなのですが、数百字程度の文章でも、日をおいて何周かチェックして、都度、細かい修正を入れている過程はとても勉強になるので、最終的な修正内容だけでなく、コミットごとの差分を追っていたりします。

10人の会社で1万社が使うサービスを目指す

boardの現在の有料登録数は1700社なので、1万社はまだまだ遠いですが、最近よく「10人で1万社」という言い方をしています。

数値目標を立ててそれを目指してやっていくというのは苦手だし好きではなく、普段から
・会社としては、みんなの賞与を出せるレベルで利益を出す
・boardとしては、前年レベルの成長率は維持する
くらいしか考えていません。

5年ほど前から「売上の座布団を増やしていくためにストック売上を増やす」と言ってきましたが、これも具体的な数値目標や期限は設けず、毎年期末のまとめの際に、社内のみんなに対して「早く50%くらいまで行きたいね〜」「今年は○%まで増えた」という話をするだけでした。

「10人で1万社」というのも、「いつまでに」というのはないし、成長や売上のための目標というよりは、「営業・運用に人手をかけない仕組みを作っていくため」の目標みたいな位置づけです。

人手がかかるやり方をしていたら10人の会社で1万社を獲得し運用するのは到底無理なので、営業においても、システム運用においても、とにかく人手がかからない仕組みを目指しています。

ちなみに、役員2人以外は残業することはほぼないので、もちろんこの状態を維持しつつ。

 

なぜ10人?

サービス以前に、うちの会社は、規模を大きくしない(10人前後まで)という方針でやっています。

もちろん小さい会社でできることというのは限られてきますが、小さい会社でないとできないこともあるし、小さい会社でも多くの人に使ってもらえる仕組みを作れるのがシステムの良いところだなと思っています。特にSaaSは、その傾向が強い印象です。

 

現在の状況

うちは自分を入れて8人の会社で、boardにフルタイムで関わっているのは4人、総務兼任が1名。一人は最近入社したばかりなので、この1年はフルタイム3人 + 総務兼任1名でやってきました。
フルタイムの3人は、エンジニアが1名、CSが1名、あとは僕がプロダクトマネージャ・開発・CS・マーケティングなどを担当しています。11月に入社したのはCSメンバーなのでCSが2人体制になります。

また、総務が個別相談会のデモやテストなどを兼任していて、残りの3名は受託がメインで、たまに手が空いた時にboardの開発を手伝ってもらっていたりします。

 

人手をかけないものとかけるもの

小さい会社では常に人手は足りないし、分野的にカバーできる範囲は限られるので、ある程度思い切った選択が必要だと思っています。

うちの場合は、営業メンバーはいないし、広告運用の経験があるメンバーもいないので、これらはやらない前提で考えるようにしています。

また、そもそもboardの価格帯(月額980円〜5980円)のサービスを人が営業して売っては利益が出ないし、広告もペイしないので、短期的に一気に伸ばす場合を除いては、営業・広告に頼らず売っていかないといけない価格帯なのかなと思っています。

一方、CSには相当力を入れています。
2015年3月から、サポートの回答時間の実績値を公開していて、ここ3年ほどは回答時間の中央値は10分を切っています。

また、他にやる人がいなかったというのもありますが、サービスリリースして3年以上も社長がCSをほぼ一人でやり続けていて、かつ、自分の中では、自分が持っている経営・開発タスクよりも優先度が高い位置づけになっていました。

これは、営業・広告にコストをかけて新規獲得を増やすことができないので、一度会員登録してくれた人をできるだけサポートして使ってもらえるようにしたいということもあり、サポートに力を入れてきました。

 

CSは労働集約型

しかし、サポートは完全に労働集約型の仕事です。

導入社数が増えれば比例して問い合わせも増えてくるので、CS体制も増やしていく必要があります。そのため少ない人数で多くのユーザを抱えるサービスを運営していくためには、ここが大きな課題になります。

例えばチャットボットを導入して、ある程度自動化することも選択肢としてはあるとは思います。しかし、boardのサポートは業務的に込み入った話も多く、わりと人間が頭を使って回答しなければいけないものがたくさんあるため、現時点で、それらをチャットボットで解決できるイメージは湧きません。

サポートもサービス全体のUXの一つと捉えています。サポートとのやり取りでどういう体験をするかというのは極めて重要な位置づけで、少なくとも現時点では、人間がやるべきと考えています。

そのため、以下のようなことを継続的に取り組んでいます。

問い合わせを減らす対策

・問い合わせが多い機能を1〜2週間に1つずつ改善していく
・問い合わせ内容から随時ヘルプを改善
・ヘルプの検索のしやすさの改善
・CSの回答の中で、その場の解決だけを目指した回答をするのではなく、仕組みを理解してもらうための説明をする(将来的な問い合わせを減らす)

回答効率と手離れの良さの改善

・僕のサポートノウハウの整理とすぐにそれを検索できる社内用の仕組みの構築
・マニュアル化ではなく、個人の対応力の向上(業務理解、読解力、文章力、説明力などの強化)
・毎日、質問と回答のチェック・フィードバック・改善を繰り返し、よりやり取り回数を減らすことができる、わかりやすい回答にしていくための取り組み

 

問い合わせ数という点では、特に「問い合わせが多い箇所の改善」は効果的でした。問い合わせが多いということは、わかりにくかったり、躓きやすいところなので、そこを改善していくことで、それ関連の問い合わせが劇的に減りました。

その結果、ここ1年で有料導入社数が700社以上増えましたが、問い合わせ数・返信数は横ばいです。

現在の問い合わせ量だと、CSはほぼ一人で対応できていますが、新しく入ったメンバーも含め、2人体制で4〜5000社くらいまではいけそうな気がしています。

 

バグ・障害の少なさとリリース後の手離れの良さ

バグや障害があると問い合わせが増えてしまいます。そのため、少人数で回していくためには、バグや障害の少なさというのはかなり重要なポイントと考えています。

また、仕様の適切さや完成度もとても重要で、機能追加しても、仕様が中途半端だったり業務とフィットしていなければ問い合わせが増えますし、急遽、当初予定になかった改修が必要になります。これはプロダクトマネージャとしての質ですね。

質の良さは、問い合わせを減らす効果があり、またリリース後の手離れが良く、スムーズに次の開発に入れるので、開発サイクル全体としても効率的になります。

そのため、自分の中では、感覚的には受託の時の2〜3倍程度のコストを品質管理にかけていて、それが結果的に、トータルでのコスト低減や安定したペースでの機能追加・改善に繋がっていると思っています。

boardの場合、少し状況が特殊で、リリース後3年以上、ほとんどの期間でほぼ僕一人で開発・CSをやっていたので、バグを出すと全て自分に返ってきます。

新しい機能をリリースしてバグがあったり既存機能に影響があったりすると、問い合わせが立て続きます。自分でその問い合わせ対応をしないといけないので、その結果修正の時間も取れないという、完全に負のスパイラルに入り込みます。バグ1つの重みがとても重かったのです。

元々受託においても、お客さんから「バグや手戻りがとても少ない」という評価を頂くことが多かったのですが、それよりも遥かに高いレベルのものを自分自身に求め、いかにしてバグを未然に潰せるか、そのプロセスと品質管理の仕組みを改善していきました。

その結果、リリース頻度(年40回前後)と規模を考えると、仕様面での後悔はとても少ないですし、バグもかなり少なく抑えられているのではないかと思っています。ユーザさんからも「他のサービスと比較検討していたけど、品質の良さが決めての一つ」と言われることもあったりします。

もっとも、全体としてはそういう傾向というだけであって、バグは当然あるし、いちユーザから見ると、バグを引いた方も当然いるわけで、そういう人からすると、これを読んで「いや、俺バグ引いたし」と思うと思うので、あまり大きなことは言えませんが・・・。

 

SREやDR

「この価格帯のサービスで、この規模の会社でDRやるの?」と言われたりするのですが、最近、DRやSREに対する取り組みを始めています。

ユーザさんにとっては、当然安定してサービスが利用できることに越したことはありません。

また、うちとしてもこれまで書いてきたように、少ない人数で回していくためには、障害の少なさというのは非常に重要になってくるので、ここは今以上に強化していきたい分野です。

これらの強化はこれから本格的にスタートしたところで、今後、継続的に取り組んでいく予定です。

 

完成度の高さやユーザ体験という差別化

小さい会社は、知名度やリソース(人・金)では戦えません。

システムの完成度・質(仕様的な意味も含めたトータルの質)・ユーザ体験が生命線で、そのために、アプリケーションそのものはもちろん、運用やCSなどを磨き続けていき、そういう差別化を目指しています。

サービスを比較検討する際、機能の○×や知名度は、とてもわかりやすい指標なんですよね。でも、小さい会社はその土俵では戦えないので、程よくターゲットを絞りつつ、その中で圧倒的な完成度に持っていく。

昨年、別にboardのパフォーマンスは悪いわけではないのに、さらなるパフォーマンスの向上の取り組みをしていたのも、「速さは最大のUX」だと思っているので、「ユーザ体験」をより向上させるための投資でした。そして、これは今後も継続してやっていきます。

 

たぶん、今後boardが進む方向はこういう方向なんだろうなと思っています。

とてもぼやっとしていてわかりにくいですが、引き続き地味にじっくり、開発もCSも磨き続けていきたいと思います。

 

そしてそれが実現できれば、ユーザさんに対しては、より高品質のものを今の価格帯のまま提供を続けることができるし、社員のみんなには大きな額の賞与として還元してみんなの収入をぐっと引き上げることができるので、それを目指してやっていきたい。

 

こういう方向に進むための「10人の会社で1万社が使うサービスを目指す」という方針です。

 

ちなみに、エンジニアを募集中です。

こんな方向性でやっているので、興味があるエンジニアの方がいましたら、ラフに話を聞きたいレベルでも全然問題ないので、お気軽にご連絡を頂けると嬉しいです。

 

8期振り返り〜自社サービスのアサイン割合が受託を超えた年

2018年11月に8期目が終わったので振り返りです。

前期は、僕の交通費の経費精算回数が1桁という、あり得ないくらいオフィスに引きこもって、ひたすら開発とサポートをやっていました。ベンチャー社長の中でトップレベルで外出しなかった自信がありますw

それくらい、開発・サポートといった手を動かす方に集中していたわけですが、「受託の会社が自社サービスを立ち上げていく」という取り組みの中で、ビジネス構造としては大きな転換期だった1年でした。

 

売上構造の変化

8期は売上・利益ともに過去最高でしたが、その額よりも、売上構造の変化が、自分の中で一つラインを超えたと感じています。

5年ほど前から、「売上の座布団を増やす」と言って、ストック売上を積み上げていくことを目指していました。

受託ビジネスは納品基準で請求することが基本なので、どうしてもキャッシュフローに波があります。そこで、経営を安定させるために、ストック売上を増やして波を小さくしていこうという狙いです。

8期は、このストック売上の割合が約6割になり、初めて半分を超えました。自社サービス(board)の伸びが一番大きいのですが、それ以外にも保守をはじめ、その他色々と積み重ねた結果です。

今期はストック売上が7〜8割ほどにはなる見込みで、売上構造が受託の会社のものではなくなり、だいぶ直近の売上に振り回されずに済むようになってきました。

これにより取れる選択肢が広がるので、事業を展開していく上でとても大きく、強い経営基盤ができてきていると感じています。

 

受託と自社サービスのアサインの割合

現在うちの会社は、取締役2人を入れて8人ですが、一人は11月に入社したばかりなので、8期は実質7人でした。

内訳は、受託メインが3人、自社サービスメインが3人、総務兼自社サービスが1人と、初めて自社サービスへのアサイン割合が受託を超えました。

自社サービスの事業を進めていく中で、「受託の利益を食いつぶしながらやるのではなく、自社サービスの売上の中でまかなえるアサインで事業を進めていく」というのを基本スタンスでやってきました。

売上が少ない初期の頃は、僕が自社サービスをやりつつ足りない分は受託で稼ぐということをやっていて、ある程度売上が上がるようになってきてからは、その売上でまかなえる範囲で他のメンバーを少しずつアサインしてきました。

そのため、「自社サービスに投資するから一気にリソースを増やす」ということはやっておらず、身の丈にあった形で少しずつ社内の体制も変化させてきたので、この割合が逆転したというのは、自分の中ではとても大きな出来事でした。

 

受託

7期(前々期)から、僕はboardの方が忙しすぎてあまり受託に入れてはいなかったのですが、7期の頃は営業だけは入っていたりしました。

ただ、8期は営業も入ることはなく、昔からやっている3案件のみ引き続き持っているだけで、基本的にはもう一人の取締役(津久井)が中心になって進めています。

受託は好きなので完全に離れつつもりはなかったのですが、boardの方が順調なこともあり、時間が足りなすぎるということで、完全に離れる方向で体制をシフトしています。

ここ2年ほどかけて受託体制の転換を行ってきて、うまく切り替えられたかなと思っています。

また、受託の内容も、以前はわりとなんでも受けていたのですが、最近は関わる人数が減ったこともあり、津久井がずっとやってきたデータ分析支援(小売・大学など)を中心にやるようになってきました。

 

board

boardは、12/5に有料1700社を突破し、1ヶ月半〜2ヶ月に100社のペースで増えています。

初期の頃は、どうやって伸ばしていくかということを試行錯誤していましたが、ここ2年ほどは、営業もせず広告も出さず、「売る気あるの?」って言われたりするのですが、自分自身、営業は得意でも好きでもないし、SaaSなので営業せずに売れる仕組みを作っていこうという思いでやっています。

前期は普段どおりの機能追加・改修は続けつつ、以下のことをやっていました。

  • パフォーマンスの向上
    元々わりとサクサク動いていましたが、速さは最大のUXなのでさらなる高速化への取り組み(今後も継続していく予定)
  • 自動テストの本格的な整備
    これまでほとんど書いていなかったので、単体〜E2Eまでをかなり時間をかけて一気に整備
  • ライブラリのアップデートを日常にする
    自動テストを整備したことにより、Dependabotを使ってライブラリのアップデート間隔を短くする運用を開始
  • テストケースの整備
    僕の中に品質管理のノウハウが閉じてしまっているので、それの整理とアウトプット
  • DR(ディザスタリカバリ)のための取り組みを始める

前々期まではほぼ自分一人で開発してきましたが、前期はもう一人を1年間フルアサインできたので、今後に繋がる内部的な改善などに取り組みました。ちなみに、リリースは年間で40回ほどだったので例年よりも少し少なかったです。

boardは契約社数が1700社を超えるまでに成長してきたので、もう立ち上げのフェーズではなく、今後は、いかにして、品質を落とさず安定して継続開発できるか、そのための土台整備にある程度時間を割き、これは今期も継続していきます。

また、今後はそれに加え、SRE・DRといった、さらなる安定性・耐障害性を高めていくための取り組みをしていきたいと思っています。

「どんどん機能追加をして拡張していくフェーズ」から、「機能追加・改善は継続しつつ、完成度・使い勝手のさらなる向上や非機能要件的な内容をもう一段レベルを上げていこう」というイメージです。

ちなみに現時点で安定性・耐障害性などに課題感があるわけではないのですが、少ない人数で回していくことを考えると、この部分はとても重要で、そこを更にレベルアップしていこうとしています。

 

ユーザさんは、「同じレベルやちょっと良い程度」であれば有名な方・大きい会社の方を選ぶと思っています。

そのため、うちみたいな小さい会社が戦っていくためには、完成度・品質・ユーザ体験などが生命線で、これまでもそれで戦ってきたつもりですが、それをさらに追求していくつもりです。

 

採用

前期は初めて1年間で二人採用をしました。二人ともboardのCSです。

一人は3月に入社し、もうだいぶ軌道に乗ってきています。夏以降は僕ではなくほぼ彼が回答しています。

 

その後は募集はしつつも、急がずに「いい人がいれば」というスタンスで考えていました。

一人目のCSメンバーに色々と教えていた過程で、boardのCSに必要なことや考えが整理されてきて、それが「読解力」「想像力」「日本語力・文章力」でした。

最近のカスタマーサクセスの流れとは全然違いますが、やはり会ったこともない、背景も知らない、立場も知らない人からの問い合わせから、「本当にやりたいこと」を読み解くのはとても難しく、CSの本質は「ユーザさんが本当にやりたいことを正しく把握して、正しく説明すること」なので、様々なKPIを追うのではなく、もっと本質的な「読解力」「想像力」「日本語力・文章力」の強化というところに行き着きました。

ただこれが本当に難しくて、でもCSの8割はこれだと思っているので、他のことは置いておいて、ここにだけフォーカスしていこうという方針でやっています。

というようなことをツイートしてたら、長らくフリーランスで編集者をやっていた@note103 の目に止まり、CSとして入社してもらうことになりました。この辺の経緯は、@note103のブログをぜひ。

note103.hatenablog.com


ということで、CSは二人体制になり、また社内で文章力・日本語力を強化していく体制もできたので、今期は僕がCSから徐々に離れていき、二人で回していける体制に移行できればと思っています。

 

CSはある程度目処が立ってきたので、今後の採用のメインはエンジニアです。

会社規模は10人前後までと考えているので、エンジニアはあと二人くらいのイメージです。

スタートアップ的な勢いでやっているわけではないし、やっぱり無名の小さい会社は採用が大変すぎるので、「人手が足りないからリソース確保のため」の採用ではなく、「うちの会社やサービスをよりレベルアップさせることができるいい人がいて、カルチャーに合えば」というスタンスでじっくりいこうと思っています。

ご連絡頂いて1〜2時間ほどラフに話をするといった感じのこともよくあるので、少しでも興味がある方がいれば、Twitterコーポレートサイトから気軽にご連絡頂ければと。

 

特にboardに関しては、前述した通り、機能面・非機能面ともに、現時点でわりとしっかりしたレベルでできていると思っていますが、これを更にレベルを上げていきたいと思っています。

そのため、スタートアップ的なスピード感というよりは、時間をかけて、通常より高いレベルに引き上げていくようなスタンスで仕事をしたい方の方が向いているかもしれません。

直近では、品質管理やSRE・DRなどに力を入れてやっていくので、この辺が強い方はぜひといったところですが、小さい会社なので、特定分野だけということはなく、「事業に必要なことをやっていく」スタンスになると思います。

 

今後の方向性

よく「受託はまだ続けるの?」と聞かれるのですが、今のところやめるつもりはありません。

受託をやりたいメンバーもいますし、boardだけをやっていると、どうしても知識・経験の幅が狭まってしまうと思っています。

boardは、僕のこれまでの十数年のコンサル・受託の中でお客さんの業務を数多く見てきた経験がとても役に立っていて、これがあるからこそ考慮できるものがたくさんありました。

うちの会社は、僕自身を含め、何か特定の技術や分野に特化するようなタイプはいないので、技術的にも業務的にも、常に引き出しが増えていく環境があることはとても大事で、そういう意味で、受託はとても大きな役割を担っていると思っています。

baordに関しては、「10人の会社で1万社が使うサービスにしていく」というのを最近よく言っています。

これは成長や売上のための数値目標ではなく、「営業・運用に人手をかけない仕組みを作っていくため」の目標みたいな位置づけです。

これについては、また別途詳しく書きたいと思います。

boardの価格戦略

戦略というほどのものはないのですが、boardの価格に関する方針について書きたいと思います。

 

最初にうちの会社について簡単に書くと

・受託をやりながらサービス開発している
・上場もバイアウトも目指さない。身の丈に合ったサービス開発・運営
・会社の規模(人数)を大きくしない。10人前後まで。(現在8人)
・営業・マーケティングにコストはかけず地道に伸ばしていく

というスタンスでやっていて、boardは現在、有料登録が1700社を超えたところといった状況です。

詳しくは以前書いた下記をご参照頂ければと。

tamukai.blog.velc.jp

 

boardの料金体系

boardの料金は、
・プラン別料金
・有料アドオン
・郵送代行
の3つに分類されます。

プラン別料金は、Personal(980円)、Basic(1,980円)、Standard(3,980円)、Premium(5,980円)の4段階で、基本的にはユーザ数に応じてプランが分かれています。

Premiumプランの50名以上の場合は1ユーザ月額216円で追加することができます。

有料アドオンは、現在4つあり、月額324円または540円です。

郵送代行は、1通あたり170円(切手代込み)です。

the-board.jp

 特徴としては、以下の点かと思うので、その辺の背景を書いていきたいと思います。
・提供している機能に対してとても安い(と言われる)
・有料アドオンという形態を取っている
・プランは人数による違いがメインで機能差は少ない

 

リリース時に料金はどのように決めたか

ベータ期間中に知り合いから、「仕事で使うものを無料で使いたくないので、早く有料スタートして」って言われて急いで検討したので、正直なところ、あまり深く考えていませんでした・・・。

boardは、一般的な請求書サービスと中堅向けのERP・業務システムの中間に位置するようなサービスですが、入口としては請求書サービスと比較されることが多いだろうなと思っていたので、他の請求書サービスの価格帯をある程度参考にして決めました。

また、バックオフィスの経験をしてから起業する人はほとんどいませんので、boardを使うことで、最低限やらなければいけないことや見なければいけない数字などがわかるようにしたいという思いもboard開発の目的の1つです。

自分自身が起業した直後のことを考えると、バックオフィスのサービスに月数万円は出せないなあという感覚があるため、起業直後から使える価格帯にしたいと考えていました。

今から思えばもう少しちゃんと考えれば良かったのかなとは思いますが、後悔はしてないし、仕入原価がかかるものでもないので、この価格帯に決めた以上は、これで事業として成立させるのが僕の仕事という考え方でやっています。

 

かなり機能が増えても基本料金の価格改定はしていない

料金は2014年のリリース時から変更しておらず、当時でも「安い」という反応が大半だったのですが、それから相当量の機能が追加されているため、最近では「安すぎて心配なのですが」「もう少し料金を上げてもいいのでは?」「数倍でも使いますよ」と言われることが多くなりました。

ただ、今のところ、機能が増えても料金は変えていません。
*税込価格で金額をそろえたので、消費税増税の時はどうするか迷っていますが・・・

「機能追加によって提供できる価値が増えたので価格を改定する」というのはよくある話ですし、提供価値が上がっているのであれば当然そうなると思うのですが、その機能が必要ないユーザにとっては単なる値上げでしかないので、サービス提供者側の理論だなあと感じています。

特にboardのターゲットユーザである中小企業の場合、今の機能でも十分ということも多々あります。その場合、値上げは満足度の低下を招くし、何よりも「また値上げするかもしれない」というように、サービスに対する「安心感」が損なわれてしまいます。

最近、弊社で使っている、あるサービスの月額料金が倍になる価格改定があったのですが、さすがに倍はキツく、最初からこの価格なら導入していないなと思いつつ、乗り換えを検討し始めました。

 

boardのように、営業・マーケティングをほとんどやらずに、あまり表に出ないで地道に伸ばしていくスタンスでやっていると、値上げによって売上が増えることよりも、そこで失われる安心感・信頼関係の毀損のダメージの方が大きいなと。

あとは、価格が上がるほど営業コストもかかると思っています。うちのように営業がおらず、「営業せずに売る」という方針を軸に考えた場合、あまり価格は上げられないと考えています。

 

また、「上のプランほど使える機能が多い」というパターンも考えたのですが、ユーザ視点で考えると柔軟性がなく、「上のプランのうち、この機能だけ使いたいだけなのに」というケースも結構あるように思います。

 

そのため、boardのプランは人数ベースで機能差は最小限にし、機能が増えてもプランの料金は変えずに、「これはプラスαで頂きたいなあ」という一部の機能を「有料アドオン」という形で、必要な人のみ払って頂くという方法を取っています。

ただ、有料アドオンは増やしすぎると「結局いくらかかるの?」というのがわかりにくくなるため、あまり安易には有料アドオン化しないように気をつけています。

今のところ有料アドオンは4つしかなく、ほとんどの追加機能は標準機能として追加しているのですが、プラスαの機能で開発規模が大きかったものを中心に、有料アドオンとして提供しています。

有料アドオンも、月額324円・540円といった価格帯なので、個別相談会などで価格を説明すると、笑われることも多いですがw

 

営業・マーケティングコストをかけられないゆえの選択

boardは、リリース以降、ほとんどの月で有料継続率が99%以上を維持しています。
*3月だけ退会数が倍くらいになるのですが、たぶん期が変わる会社が多いからですかね。

通常、価格が高い方が解約判断がシビアになるように思います。boardの場合、費用対効果が高いと感じて頂いていることが多いので、その結果、解約率が低くなっているように考えています。

うちのように、営業・マーケティングにコストをかけられない場合、新規獲得を急激に増やすということは難しいです。そのため、一度使い始めてくれた方には、多少安くても長く使ってもらう方がありがたいと考えています。

もちろん、長く使ってもらうためにはシステムそのものの価値が第一なので、ここ3年間は毎年40回以上リリースして、継続的に改善・機能追加を続けています。ただ、ユーザさんの中での意思決定(導入判断)としては、価格と価値のバランスは重要なので、それを「費用対効果の高さ」重視に寄せている感じです。

 

ターゲットがぶれないための価格設定

これは完全に後付けというか、「こういう効果もあるな」と思ったものですが。

業務システムの場合、小さい会社から大企業まで全部にとって使い勝手が良いものというのは無理だと思っています。UI的な意味ではなく、システムの設計としてニーズが異なります。

アップセルを狙うためには、どうしても規模が大きい会社をターゲットにしていく必要があると思っていて、そうすると、当初のターゲット層とずれてきます。

その結果、大企業が増えて売上は向上したけれど、元々使ってくれていた小さい会社からすると使いにくくなった、というのは避けたいと考えています。

実は最近、自分自身が他のサービスを使っていてそう感じることが何度かあって、改めて、「あー、やっぱりターゲット層を上に引き上げるとこうなるんだなあ」と思ってたりします。これはビジネスとしては悪いことではなく、ただ自分がそのサービスのメインターゲット層ではなくなっただけなのですが、使いづらさを感じてしまうのは正直あるなと。

そのため、boardは「数人〜数十人規模」がメインターゲットというのはぶらさず、「その規模で無理なく払える金額」で、サービスを提供し続けようと考えています。

 

この価格戦略の課題

売上の成長率が上がらない

このスタンスは、当然、客単価は上がりません。

リリースしてから4年ほど経っていますが、初期の頃と比較すると、1アカウントあたりの平均単価は1.5倍程度で、ほとんど上のプランを使う会社が増えた分、という印象です。

うちは資金調達もしていないし、「いつまでに売上をここまで伸ばす」といったプレッシャーも目標もありませんので、のんびりはしていますね。


ただ、資金力が豊富なわけではないので、それでも十分利益を出せるような運営をするようにしています。

基本的に営業も広告もしておらず、マーケティングコストがほぼかかっていない状態で、内部の人件費とサーバやセキュリティ対策関連のコストがほとんどです。

人件費も、開発は僕を入れて2人、CSは最近2人体制になったばかりです。開発とサポート以外で人手がかかることを可能な限り減らして、最小限の人数でやっています。

代理店が機能しにくい

これはリリースしてから気づいたのですが、低価格だと代理店制度がほぼ機能しないですね。代理店にとって取り分が少ないので、boardを積極的に売ろうとするメリットがないので。

そのため、現在代理店として紹介が増えているのは、税理士事務所など既存クライアントに対してboardを紹介しているケースですね。

価格が低いと、広告もペイしにくいですし、売り方の選択肢が狭まるということを後から気づきました。

 

おまけ

いち開発者として、価格改定に伴う対応は、面倒だしリスクもあるので、正直気が乗らないんですよね・・・。

その時間・労力・神経を、他の開発に回したいという思いもあります。自分の中では、経営者として短期的に売上を増やすことよりも、boardを強くして中長期的な売上の土台を固める方が優先度が高いんですよね。 

受託の会社が自社サービスをリリースして4年が経った現在地

8/19でboardの正式リリースからちょうど4年が経ちました。

有料アカウントは1500社を超えたところで、会社全体の売上の4割ほどにまでに成長してきました。
単価が安いサービスなので、1500社でやっと4割かという感じがします。

現在、boardにフルタイムでアサインしているのは3人で、エンジニア1名、CS1名、自分がプロダクトオーナー&開発者&CSといったメンバー構成です。

他のメンバーは受託を軸にスポットでboardに入ったり、総務をしながらテストをやったりといった感じで兼任しています。


boardに対するスタンス

これは当初から変わらず、「boardだけでやっていくぜ!」という感じでもなく、急激な成長を目指すわけでもなく、自分たちにできることを自分たちのペースで、着実に続けています。

相変わらず営業もマーケ担当もおらず、ようやくCS専任のメンバーが入り、僕の手が離れつつあります。
まさか、4年目まで、有料アカウントが1000社を超えても社長が1人でCSやることになるとは思ってもいなかったですw

*ちなみに、昨年夏頃からさすがに1人だときつくなってきたので、問い合わせが多い箇所の改善などを続けたところ、導入社数が倍増しても問い合わせ数が横ばいだったので、そういった改善も大事だなと思いました。

 

ここ1年以上、外向けの活動はほとんどできておらず、日々、ひたすらサポート・個別相談会・開発をやっている状況です。
なんせ、僕の今年の交通費精算、まだ片手で数えられる数ですw
そのくらい引きこもってサポート・開発だけをやってます。

「いいもの作れば売れる」という時代ではないのは重々承知ですが、小さい会社は知名度や露出では戦えないので、サービスそのものでは負けない完成度にしようと、地道に改善を続けています。

ちなみに、リリースの回数は以下で、毎年同じようなペースですね。
2014年:25回
2015年:36回
2016年:43回
2017年:49回
2018年:27回(8/19現在)

初期の頃から続けている開発ロードマップの公開や、サポートの回答時間の中央値の公開も続けています。

 

そして、「新規獲得より既存ユーザ」というスタンスも変わらずなので、サポートを一番大事にしていて、全回答時間の中央値は現在でも10分を切っています。

最近のカスタマーサクセスの流れとは真逆ですが、「来た問い合わせに全力で対応する」という受け身のスタンスで、ただ、そのやり取りのクオリティの向上にひたすら取り組んでいます。(これについてはまた別の機会に書きたいと思います)

 

boardはこんな感じで、何か特別なことをするのではなく、粛々と地道な改善を継続していて、すごくありきたりですが、やはり「継続すること」「1つ1つのレベルを上げること」が大事だなと思っています。


受託

boardがかなり成長してきましたが、引き続き受託もやっています。

まだboardだけでは売上が足りないというのもありますが、受託の方が好きなメンバーもいるし、boardだけやっていると引き出しが少なくなってしまうので、今後も受託は続けていくつもりです。

ただ、昨年から僕がboardのサポートにかかりっきりになって受託に入れなくなってしまい、受託は実質3人で回しているので、お待たせしたり、お断りすることが増えてきてしまっています。

とはいえ、人数をどんどん増やすつもりはなく、「10名前後まで」と考えているので、悩ましいところです。

 

勤務時間の短縮

今期から勤務時間を1時間短くしています。

元々、社員のみんなはほとんど定時で帰っていたし、boardの成長に伴って労働集約的な割合がぐっと減りました。

そのため、勤務時間を1時間減らしても、特に売上にネガティブな影響はありませんでした。

ちなみに、勤務時間が短くなったことについて、社外の人からは色々リアクションをもらうのですが、社内のみんなはわりとノーリアクションなのがうちの会社っぽくて面白いですw

 

会社の人数を増やさないという方針

今に始まった話ではないですが、今まで以上に、「人数をどんどん増やすことはしない。10人前後まで」という方針を明確にして、そのための取り組みに軸を移しています。

boardの問い合わせを減らすための改善や、こちらから営業的なことをしない方針など、とにかく可能な限り人が動く・介在することを減らしていくようにしています。

boardにフルタイムで関わっている3人なので、3人で1500社を回せているのは十分効率的だとは思いますが、ここはもっと追求していきたいと思っています。

そのため今後は、「導入社数が増えても運営に関わる人数を最小限に留めるための仕組み作り」がテーマで、自動化・安定性・問い合わせを減らすための改善などを今まで以上に力を入れていくことになりそうです。

 

経営的な変化

「売上の座布団を増やす」という言い方をしているのですが、ストック売上(納品がなくても毎月上がる売上)を増やす取り組みを5年ほど前から続けています。

基本的には、短期的な売上よりも中長期的な売上の仕組みを作っていくことを優先しています。

boardが一番大きいですが、それ以外も加えて、今期売上の65%ほどがストック売上になりそうです。

 

これは、受託の会社の経営的には本当に大きな変化です。

起業して1年目の頃にあった「今月売上が20万しかない!」みたいなことがないので、キャッシュフローに追われることがなくなり、より本業に集中できるようになりました。

個人でも会社でも、経済的な余裕がないとやれることが制限されてしまうと思っているので、そういう意味で、5年ほどかけて売上の座布団を積み上げていくという取り組みは、本当にやって良かったなと思っています。

 

今後

基本的に、大きくは変わらず、今のスタンスでやっていくつもりです。

boardに関しては、継続的に改善・機能追加を続けていきつつ、SRE・パフォーマンス・自動テスト・品質管理周りが今後の重要なテーマになりそうです。

 

会社の人数も10人前後までと考えていて、現在7人なのであと3人。
10人の会社で、1万社が使うサービスを回せたらいいなと思っています。

そして、こんな小さな会社で働いてくれているみんなにはもっと還元していきたいと思っています。

 

エンジニアもあと1〜2名は採用する予定ですが、のんびり考えているので、「まだすぐには転職しないけど、興味があるので話だけ聞きたい」くらいのレベルで全然OKですので、ご興味があればぜひ声かけてください。

 

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

以前からブログで「受託と自社サービスの両立の取り組み」を書いてきましたが、ついに、2017年11月1日にboardの有料アカウントが1000社を突破しました!

f:id:fw_tx76129:20171205124843p:plain

1000社突破したらに、これまでの取り組みや現在のスタンスなどの総まとめを書こうと思ったのですが、8月のBPStudyで「受託の会社が調達せずに自社サービスを立ち上げ事業として成立するまでの企画・開発・サポート・マーケティング」という発表をしまして、これらのテーマについては、このスライド以上に書くことがなかったので下記のスライドを見て頂き、ここではそれ以外のことについて書きたいと思います。

 

 

BPStudyのスライドは、はてブでもたくさんコメントを頂いていて、「受託メンバーとの兼ね合い」が結構多かった印象でした。

 なので、今回は土台になっている、経営や受託とのバランスについて書きたいと思います。


経営方針

ヴェルクは受託開発の会社としてスタートして、2017年11月で7期目が終わりました。

現在自分を入れて6名の小さな会社なのですが、人数をどんどんと増やして拡大していくつもりはなく、10人前後を一つの目安と考えています。

元々、何か特定の技術を扱いたいとか、サービスを立ち上げたいとかで起業したのではなく、「この業界の変化は早いので、それに対応していけるチームや環境を作って、自分含め、エンジニアが継続的・安定的に技術に取り組める環境を作りたい」というのが起業のきっかけです。

そのため、当初から上場やバイアウトといったものは全く考えていません。というか、そういう感じでやっているので、投資対象として向かないですね。

僕の経営者としての仕事は、上記を実現するために、

  • 短期的には、きちんと利益を出せる受託案件を取ってくること
  • 中期的には、経営を安定させる事業を作ること
  • それを、社員にはオーバーワークさせず定時で帰ってもらい実現すること

だと思っています。

自分の感覚的には経営者というよりは事業責任者に近くて、経営者っぽいことはあまりやってません。社内で、経営理念とか方針とかそういう話をしたこともないですし・・・。


これらのことに取り組むにあたって、一つの重要なテーマとして考えているのが「労働集約型」からの脱却です。

受託開発は労働集約なので、人数を増やせばある程度それに比例して売上も上がりますが、拡大とともにクオリティの維持が難しく、利益率にも限界があります。

また、小さい会社にとって採用は本当に本当にハードルが高く、しかも人口は減少傾向なので、「人を増やすこと」に依存したモデルは厳しいと感じています。

社内で冗談半分で「10人で利益を10倍にする方法を考えるのが自分の仕事」と言ってたりします。数字は具体的な目標ではなくあくまでイメージですが、2倍とかだと「労働集約型のまま頑張る」という選択肢が残ってしまうので、根本的にビジネスモデルを別で考えないといけない「10倍」にしています。

そのため、ここ3〜4年の僕のミッションは、「中期的に経営を安定させる事業を作って、労働集約型のモデルから脱却すること」で、その一つがboardでした。


ストック売上を増やす

「中期的に経営を安定させる事業を作る」に関連して、僕がずっと社内で言い続けていたのが、「ストック売上を増やす」でした。

受託開発の場合、基本的には「納品」してから請求です。普通に数ヶ月単位で大きな納品がない時期があって、そうするとキャッシュフローが悪化します。

ちなみに、今までで一番預金残高が少なかったのは、起業4ヶ月目に20万という時がありました。その後すぐに入金の予定があったので大丈夫でしたが、キャッシュフローの計算を間違えていないかヒヤヒヤものでした・・・。

そういうリスクを減らすためにも、納品の有無に関わらず月額でお金が入ってきて、売上の座布団になるようなものを増やしていこうという方針です。

最近は、よく「サブスクリプション」という言葉を聞くようになりましたが、当時はそういうことは全然考えておらず、とにかく「売上の座布団を増やしたい」という意識でした。

*「売上の座布団」という言い方が一般的かわかりませんが、僕はよく使っていて、保守のように、納品有無に関わらず毎月請求するタイプのものを指しています。

 

とは言え、すぐにそんな事業を作ることはできませんし、そこに賭けて社員にリスクを負わせるわけにはいかないので、まずは堅実に保守を増やしていくことから始めました。

ちなみに、「保守だけ受ける」ということはやらず、保守がある開発案件を優先するというスタンスです。

ただ、保守ばかり増やしていくと、そっちに手が取られて開発案件ができなくなってしまうし、開発者としては面白くないので、そこはバランスよく、また運用保守に手がかからない仕組みにするように気をつけていました。例えば、自動化できるものは自動化したり、運用回避な要件は避けたり、運用上定常的なオペレーションが発生しないようにしたり。

少しずつでも売上の座布団が増えてくれば、納品ベースで稼がないといけない売上は多少下がっていきます。その積み重ねが余力になってくるし、その余力が自社サービス開発の時間を捻出します。

その後は、知り合いの医学生とのコラボで医療系学生向けの解剖学のアプリをレベニューシェアで出したりしつつ、2013年(3期目)に初めての本格的自社製品「Patto」、2014年(4期目)に「board」をリリースと、自社サービスをリリースしていきました。

毎年期末にその期のまとめとして、売上や振り返り、来期の見込みや方針などを社内で話しているのですが、その時の資料を見返してみると、3期目(2013年11月)の終わりに初めて「ストック売上」という言葉を使っていて、4期目(2014年11月)の終わりに「3年後にはストック売上で50%」という目標を掲げていました。

普段具体的な数値目標を上げることはほとんどないのですが、今から思うと、だいぶ思い切った数字ですね。たぶん、全く具体的に考えていなくて漠然と上げた数字です・・・。

で、その3年後というの7期(2017年11月)なのですが、めでたくストック売上は無事50%を超えました。言ってみるもんですね。


ほどほどの売上に抑える

boardとは関係なく起業当初からの取り組みですが、それぞれの給与に応じて「このメンバーの受託での年間売上はこのくらい」みたいな目安が自分の中にあって、基本的にそのラインまでいったら、ある程度受託へのアサインを抑える、というスタンスでやっていました。

そのため、年間を通しての稼働率は平均7割程度で、空いた時間は、技術的な検証だったり、自社のスマホアプリを作ったりしてました。

各メンバーがもう1つ案件できるくらいの稼働率なわけで、その分も受託で埋めた方が利益を出せます。ただ、そうすると、「次」に繋がる取り組みができないので、稼働率は7割程度に抑えるようにしてきました。

例えば、boardの前に「Patto」というスマホアプリ関連の製品をリリースしているのですが、この時は、boardと違って僕ではなく社員がメイン開発者だったので、「最低限上げて欲しい売上を上げた後はそのメンバーは受託から外し、自社製品の開発に注力して、全体として売上が足りなかったら自分が稼ぐ」という形で進めました。

経営者として、もっと売上を上げられるのに抑えるというのは難しいところですが、リソースは有限なので、中期的に考えてどこに時間を割くべきか、ということを考えるようにしています。

ただ、「それほど多くはなくてもボーナスは出せるレベルの売上は維持する」というのも大事にしていて、「稼働率7割」というのは厳密なルールではなく、状況に応じてバランスも重要です。

社員にとっての受託と自社サービスの関係

僕含め、うちの会社はわりと受託が好きな人が多く、よく聞く「受託がツライから自社サービスを」みたいな思いでは全くやっていません。

2年ほど前に、うちの3人のエンジニアそれぞれに、「今後、受託とboardとどっちやりたい?」って聞いたところ、「boardより受託」「どっちでもいい」「boardやりたい」という形できれいに分かれました。

この前のBPStudyの資料のはてブコメントを見ていると、「受託と自社サービスのメンバーが仲悪くならないの?」「受託をやっているメンバーのモチベーションは?」といったコメントがちょいちょいありましたが、意外と社内ではboardの開発は人気ないのですw

そもそもうちの会社は自社サービスをやりたくて集まったメンバーではないですし、boardのような業務系サービスの場合、ほとんどのエンジニアにとっては直接関係しない業務を扱っています。

なので、あるメンバーが「boardで扱っている業務に縁がないので、業務を聞きながらやっていくことになるから受託と大きく変わらないと思ってる」って言ってたりしたのですが、エンジニアにとってはドッグフーディングできるものではないので、この壁は高い気がしています。

とある知り合いの会社で、B・C向けそれぞれのサービスを出しているところで、中のエンジニアには圧倒的にC向けサービスの方が人気あるという話を聞いて、業務系サービスあるあるな気がしています。


また、うちは、数ヶ月〜半年程度で終わる小規模な案件が多く、案件ごとに新しい試みを取り入れやすいので、それを理由に「受託の方が良い」と言っているメンバーもいます。

あと、受託案件で大変な状況になることはほぼないですし、みんなほぼ毎日定時に帰っているので、受託を積極的にやめる理由もないのかなと思います。


受託と自社サービスのアサインのバランス

現状、「受託チーム」「自社サービスチーム」という形ではっきり分かれているわけではなく、「boardも受託案件同様アサイン先の一つ」で、行ったり来たりしています。

もちろん人によって割合は異なり、例えば、「boardより受託が良い」というメンバーはほぼ受託をメインにしています。

唯一「boardをやりたい」と言っているメンバーは一番若手で、まだまだ多くの経験を積んでほしいので、年間を通して半々くらいになるようにしています。

受託でも自社サービスでも仕事の内容は開発なわけで、個人的には「受託」「自社サービス」といった区別ではなく、各個人が、モチベーション高くできる仕事だったり、足りないものを身につけられる仕事だったり、もしくはつまらないけどやらないといけない仕事かもしれないけど、そういったバランスを大事にしている感じです。


受託をやっているメンバーに負担をかけない

自社サービスを開発する上で、自分の中で決めているポリシーとして、「受託をやっているメンバーに負担をかけない」というものがあります。

「受託と自社サービスの両立」というと、どうも受託の利益を食いつぶしながらサービス開発をしている印象を持たれることが多いのですが、その方法をとると、受託側に負担がかかってしまうので長く続きません。

「サービスがリリースできるまで大変だけど頑張ろう!」みたいな感じでメンバーにオーバーワークしてもらうのは嫌だし、うちはそういうノリの会社ではないので、受託に食わせてもらいながらサービス開発をするというスタンスはとりませんでした。

余談ですが、起業直後に、昔からお世話になっているとある先輩経営者から、「テンション・勢い・イベントなどの"波"に依存した経営をしていると、次はもっと大きい波が必要になって、結果的に長続きしない組織になってしまう」と言われたのがとても心に残っています。

なので、「自社サービスを開発する」というのをイベントにはせず、淡々と進めていました。


boardの場合は、元々僕の個人プロジェクトから始まって、リリース後1年半ほどまでは、僕も普通に受託をやっていて、自分がいち受託メンバーとして上げなければいけない売上はあげつつ、boardを開発していました。

boardの売上が増えてきたら、徐々に僕が持っている受託案件を減らすという進め方で、boardに関わるコストをboard自体で賄えない時は僕が受託で稼ぐというスタンスでした。

これは、自分自身が経営者で、労働時間の概念があってないようなものなのでできたことですが、たっぷりお金がある状況でない以上、どこかで無理をして捻出しないといけなくて、それを社員にやらせるわけにはいかないので、そこは自分がやったという感じです。

 

受託を安定して回すための取り組み

受託をやりながら自社サービスを立ち上げるためには、これが基本だと思っています。

受託の会社である以上、受託を安定して回せることが前提になっていて、それができていないうちは、まずは受託の方に力を注いだほうが良いと思っています。

この話をすると「それができれば苦労しない」ってよく言われるのですが、「受託が大変」という状況を解決するための自社サービスではないと思っているので、自分としては、ずっとこの課題に取り組んできました。

 

まず一番大事なこととして、「適切な価格と適切なスケジュールで受けること」だと思っています。安すぎる受注額だったり、最初からスケジュールが厳しいと、安定して受託を回すのは無理です。

うちの会社は営業がいないので、仕事を取ってくるのは僕か取締役の津久井なのですが、二人ともバリバリ現場でやっていることもあり、見積もりやスケジュールを間違えにくかったり、悪い条件でも受注しようという考えはないので、まずここはクリアできています。


次に仕事の進め方についてです。

僕は、方法論や手法には全くこだわりがなく、うまくいけば何でも良いと思っているし、そもそもメンバ・お客さん・開発するシステムの種類などによって最適な方法は異なると思っています。

基本的には「個人の能力を上げること」が一番重要だと思っていて、そのため、前述した通り、アサインにあたっては「そのメンバーにどういう経験を積んでほしいか」を考えて、受託でもboardでもアサインするようにしています。


この前のBPStudyのはてブのコメントを引用させて頂くのですが、

「オレ」が受託開発にリソースを注ぎまくらなくてもボーナス払える状態っていうのが地味に強みなんじゃなかろうか 

というものがあり、まさにこれだと思っています。


うちの会社には、定例も進捗報告も日報も週報もなく、「進捗報告はいらないから、リスクがある時だけ相談して」というスタンスを取っています。

リスクに対するアラートが適切であれば、そうそう大きなトラブルになることはないと思っています。相談する内容を間違えず、早すぎず遅すぎず。これを「リスク感覚の一致」と呼んでいます。

別に社内で「リスク感覚を一致させていこう」という話をしたわけではないのですが、2〜3年かけて、日々の仕事の中で、これを一致させるようにしてきました。

もちろん最初からうまくできたわけではなく、相談が早すぎたり、問題が大きくなってから相談に来たり。

なので、みんなに任せて放置するのではなく、最初は僕がみんなの動向・状況をかなり気にしつつ、危なそうだったらさりげなく軌道修正するようにしていました。

みんなからしても定例や進捗報告は面倒ですし、とはいえ、そういったものがないと、アラートのタイミングをミスると大変になるので、時間とともにその精度が向上していきました。

もちろん、これは一人ひとりの状況がよく見えている小さい組織だからこそできる方法だと思っています。また、最悪、自分がリカバリに入れば良いと思っていて、リカバリできるギリギリのところまでは任せておこうという感じです。

マネジメント手法は正解があるわけではなく、規模・メンバーの特性などに応じて、最適な方法を考えるべきだと思っているので、自分自身やメンバーの特性、会社の規模などを踏まえて、こういうスタンスに辿り着きました。

結果的に、この取り組みによって、マネジメントコスト・コミュニケーションコストが極めて低いチームになり、僕がそこに割く時間が非常に小さくなりました。

中途で入ってきたとあるメンバーが、「うちの会社のエンジニアって、みんなそれぞれの立場・レベルでの当たり前を当たり前にやっていて、それがすごいし、だから最低限のマネジメントでうまく回っている」という表現をしていたのですが、確かになあと思ったことがありました。

それが納品後の手離れの良さにも繋がっていて、結果的に「余裕」を生んでいます。

小さい受託の会社にとって、創業社長が現場にがっつり入らなくても回るようにするというのは一つの大きな壁で、最初の3年かけてそれができたのが、board開発の土台となっていると思っています。


まとめ

すごく高利益率の仕事をしているのであれば別ですが、普通に受託をやっていると、自社サービスを開発している時間はなかなか確保できないと思います。 うちの場合、決して安い単価で低利益の仕事をしているわけではありませんでしたが、ビジネス構造としては普通の受託の会社でしたので、時間的資金的に、自社サービスを開発するための十分な余裕があるわけではありませんでした。

そのため、「売上の座布団」を作っていって、少しずつ余裕を作るという取り組みを続けてきていたのは、ひとつの重要な取り組みだったなと思います。

急がば回れで時間をかけてやってきているので、「今すぐサービスを立ち上げたい、軌道に乗せたい」というケースにおいては不向きな進め方ですが、受託をやっていると直近の売上は立てられるので、特にtoBであれば、じっくり着実にやっていくという方法もありなんじゃないかなと思っています。

現在、boardがこれだけの規模になってきても、うちの会社では、どこか「案件の一つ」みたいな雰囲気があって、僕自身も、各メンバーのスキルや経験、受託の営業状況、boardの開発予定などを考えて、どういうアサインが良いかというのを考えています。

経営は「ヒト・モノ・カネ」といいますが、残念ながら「カネ」は潤沢にあるわけではないので、「ヒト・モノ」が重要になります。

ただ、小さい会社にとって、採用はほんとに難しく、ずっと課題です。なので、今いるメンバーを大事にしたいし、もっと成長するための機会・環境を継続的に用意したいと思っています。

そういうものの積み重ねが、受託をやりながらboardを生み出せる土台になったんじゃないかなあと思っています。

B2B SaaSの個別相談会を100回やったので振り返り

1年半ほど前に始めたboardの個別相談会、4月に実施回数が100回を超えていたので、個別相談会を開始した経緯や効果などを振り返ってみたいと思います。

 

個別相談会とは

説明会のような大人数が集まる形式ではなく、1社ごとに打ち合わせ形式で、デモ・質問・相談などに対応しています。

本来はこちらから伺いたいところなのですが、うちの会社では営業がいないのと、低価格なサービスのため、訪問してしまうとコスト的に厳しいため、弊社に来社頂くか、Googleハングアウトを使ったオンラインで実施しています。

 

個別相談会は、週2枠用意して、予約制で実施しています。

予め枠を用意しておくことで、こちらは予定をブロックしておくことができるので、都度日程調整ではなく枠を用意して予約制という形を取りました。

始めた当初は週2枠埋まることは珍しく月4〜5件くらいでしたが、ここ半年ほどは週2枠では足りず、週4〜5件入っていることが多いです。

 

個別相談会を始めたの経緯

個別相談会を始めたのは、サービス開始してから1年ほど経った2015年9月でした。

受託の会社なのでサービスのことは右も左も分からず、最初の1年はサポートや継続開発を軌道に乗せることで手一杯でしたが、この頃になると、ある程度慣れてきて、ようやく、サービス開始当初から課題として感じていた、「スムーズに導入してもらうこと」に対する対策としてスタートしました。

 

個別相談会の基本的な構成

個別相談会は以下のいずれかの内容で行うことが多いです。
・基本的なデモを実施して、随時ご質問頂く
・最初から質疑ベースで進める

事前にある程度boardを使い込んだ上で個別相談会にいらっしゃる方は質疑ベースになることが多いですが、割合としては8割くらいがデモベースです。

デモの内容は、質問による中断がない状態で20分くらいの内容で、
・基本的な構成・考え方を理解してもらう
・どういった機能があるのか、といったことを知ってもらう
といった内容が中心で、個別相談会から帰って自分でやってみてもらう際に、迷わないで使えるようにすることを目標にしています。

 

デモの内容は、毎回改善を繰り返しています。

聞いているだけだと飽きてしまうので、なるべく長くなりすぎず、でもしっかり説明するというバランスを試行錯誤しています。

ここ1年ほどは、デモは僕ではなく別のメンバーがやっているので、僕が気になった点をその場でメモして、終わった後に「ここの説明がわかりにくそう」「ここの説明が冗長だった」などをフィードバックして改善するようにしていて、かなり完成度が上がっています。

実際は、デモの途中で質問があったり、デモの後に自社の事業・業務内容を伺ってどういった活用方法が良いかといった話をすることが多いので、1時間〜1時間半ほどになることが多いです。

 

また、たまにboardとは関係なく、バックオフィス業務全般の効率化の相談や、社内システム・セキュリティについてなどの相談があることもあります。

boardの個別相談会は、今のところ必ず僕が出席していて、システム・経営・経理・会計・業務効率化などを、board以外の話もひと通り対応することができます。

あとは、稀に、「どういう会社か見ておきたかった」「ブログに書いてあったDIYオフィスをみたかった」「田向さんに会ってみたかった」というのもあります。

 

無理に売り込まないスタンス

boardの個別相談会なので、当然boardの説明をするのですが、僕自身、エンジニアであって営業ではないためか、「なんとしても売ろう」という意識が薄く、「売り込む」というスタンスではなく、「正しく伝える」「課題を解決する」といったスタンスで臨んでいます。

そのため、ニーズがboardと合わない場合、「○○(他のサービス)の方が合っていると思いますよ」という感じで、正直に伝えるようにしています。

 

個別相談会のメリット

個別相談会のメリットは以下のような点があると考えています。

間違った使い方を防げる

間違った使い方をして、「このシステム使いにくい」「自社にとってメリットない」と判断されてしまうのは、お互い不幸です。

個別相談会のデモでは、単なる使い方だけではなく、
・どういう意図で作られているのか
・どういうシーンを想定しているのか
なども説明するようにしています。

正しい使い方で合わない場合は仕方ないですが、「知らなかった」「勘違いしてた」で満足度が下がることを回避できます。

有料登録して頂ける割合が高い

デモの中で概要を伝えることができるので、その後スムーズに使えることが多く、結果として個別相談会に来た方がそのまま有料登録して頂ける割合が非常に高いです。

有料転換(お試し登録から有料登録への転換)率は、全体では14%前後ですが、個別相談会参加者に限定すると65%前後です。

個別相談会に来る時点である程度真剣に考えているということもありますが、「概要をつかむ」という最初のハードルを個別相談会でクリアできることも非常に大きいのかなと思っています。

また、boardの概要や基本的な設計思想を理解した上で使うと、より有効に活用できるので、おそらく継続率にもプラスになるんじゃないかなと思っています。

問い合わせだけではわからないことを把握できる

業務課題や困っていること、システム導入におけるポイントなどを直接聞いたりディスカッションしたりすることができます。
話した結果、実はあまり重要ではなかったり、ちょっとした工夫で改善できることも多く、要望や課題が、必ずしも額面通りとは限らないのため非常に重要だと思います。

今後の開発のヒントになる

元々、コンサルっぽい仕事をしていたり、受託でもわりとお客さんの方にがっつり足を踏み込むスタンスでやることが多いので、こういった話からニーズや課題を拾って解決策を考えていくのが好きで、それを今後のロードマップに反映していくといったことをやっています。

お互いを少しは知ることができる

僕個人としては、ずっと受託をやってきた人間なので、やはり顔を合わせずにずっと仕事をするというのは、なんか違和感があります。
低価格なサービスなので、全員に会っていたらそれだけで赤字になってしまうので無理ですが、できるだけ面と向かう機会を作りたい、1時間しっかり話す機会を作りたいという思いはあります。

それによって、どういう人か、どういう会社かを把握できるので、チャットサポート時の説明の仕方を調整したりしています。

また、表現が非常に難しいのですが、問い合わせが雑な方は少なからずいるのですが、個別相談会参加後は、丁寧になったり、無茶なことを言ってこなくなるといったことがよくあるので、お互い少しでも知っているということは大事だなと感じています。


個別相談会の課題

体制

個別相談会の申し込みの際に簡単なアンケートをお願いして、事前にある程度はどういう業態なのかを把握できるようにしていますが、それでも蓋を開けてみないと、どういう内容になるかわからないことが多いです。

今のところ必ず僕が参加しているので問題ないですが、単にデモにとどまらず様々な話になることが多く、結果的に扱うテーマが広くなります。今のクオリティを維持しようとすると、簡単に代わりができないので、開催数をなかなか増やすことができません。

オンラインの場合の快適さ

個別相談会は、弊社にご来社頂くか、Googleハングアウトを使ってオンラインで実施していますが、オンラインは、相手側の環境によって快適さがかなり左右されてしまいます。

度々切れてしまったり、音が割れて聞き取れなかったり、そういったトラブルはそこそこあり、もう少しどうにかならないかなあと考えています。

 

まとめ

boardは、マーケティングコスト(広告費などだけではなく社内のリソースとしても)をほぼかけていないのですが、個別相談会にはしっかり時間を割くようにしています。

有料への転換率を高める施策というのは色々あると思いますが、そういった色々な手は打たず、基本的に、個別相談会への参加を勧め、直接顔を合わせて話をするということを大事にしています。

小さい無名の受託会社がサービスを伸ばすにあたって、他と同じことをやっていてもダメで、自分たちの強み(受託の経験)を活かすことを考えた時に、個別相談会で対面して、課題を聞きながら説明していく、というのはぴったりでした。

受託で業務系のシステムをずっとやってきたので、それで増えた引き出しが役に立ってるなあと思います。

 

競合ではなくユーザと業務の現場をみてサービス開発する

昨年ぐらいから、「◯◯さん、ものすごくboardを意識して、調査しているらしいですよ。やっぱり競合として意識しているんですか」みたいなことを言われることが増えました。

2年ほど前までは、競合ではない分野のB2BのSaaSの人たちから、「開発ロードマップの公開」「即レスのチャットサポート」「サポートの回答時間の公開」などの取り組みに興味を持って頂いて、「真似させてもらいます!」みたいなことを言われることはあったのですが、ここ1年ほど、明確に「競合」という言葉が出てくるようになって、ようやくそういう土俵に上がるようになってきたのかなあと思ってたりします。
たぶん2年前は存在を認識されていないw

最近、飛ぶ鳥を落とす勢いの某サービスの人から、「競合さんが、サポートに根掘り葉掘り仕様の質問をしてくる」という話を聞いて「なんだかなあ」と思ったのもあったので、自分の考え・スタンスを書いてみました。

競合はほとんど見ていない

boardの開発にあたっては、競合サービスはほとんど見ていません。

boardの場合、競合が請求書サービスなのか販売管理システムなのか微妙なところですが、多くの人は、「請求書」を入口にサービスを探しているようなので、たぶん競合は請求書サービスなんだと思います。

ちなみに、いくつかの請求書サービスのアカウントは持っていますが、元々boardを開発する前はそれらを使おうと思っていたので、その時に作成しました。

なぜほとんど見ないかというと、実際それらのサービスが自分が求めているものであればboardは作っていないですし、欲しいものと違った(自分自身の課題は解決できなかった)からboardを作り始めたわけです。

なので、他のサービスを見て真似していたらダメだし、影響を受けてブレてしまうのが怖い。

boardはboard。

他のサービスがどういう機能を追加していようがあまり関係ないことかなと思っています。

思想のないツギハギでは使い勝手が悪いわけで、同じ課題に対してでも、boardのアプローチと他のサービスのアプローチは異なります。

であれば、あまり競合を見る意味もないですし、その時間はコードを書いてたいという感じです。

大事にしているのは機能の有無ではなく世界観・居心地・体験

同じ分野の業務システムを作っていると、最終的にはある程度同じ機能をカバーするようになってきます。

そうすると差別化要因は機能の有無ではなく、そのサービスを通してどういったことを実現しているか、という点だと思っています。

例えばboardは、「クラウド上で請求書を作ること」が実現したいことではありません。

すごく曖昧なのですが、単に機能ということではなく、解決しようとしている課題や、サポート・開発・運用のスタンスなどを含め、「boardの世界観」みたいなものを大事にしている感じです。それは真似するものではなく、自分たちで作り上げていくもの。

とある人に要望をもらった際に、「boardの"適度な自動化と適度なゆるさ"を考えるとこんな感じじゃないですか」って言われてすごく嬉しくなりました。boardが目指しているものが伝わっているような気がして。


ターゲットとするユーザ・課題を明確にして、そこを見て開発する

boardは、ある程度業態を絞って、そこに最適化することで、機能的にも使い勝手的にもフィットする人にはものすごくフィットする、というサービスを目指しています。

それは汎用的でマスを狙った請求書サービスや販売管理システムとは別の方向だと思っているので、競合サービスを見ても、そういったものは出来上がってきません。

「競合が実装している機能 = boardユーザにとってニーズがある機能」とも限りません。派手な機能をリリースして注目を集めたけど、実際ユーザはあまり使っていないという話も聞いたりします。

ユーザのニーズは現場にしかないし、ユーザの不満・不便はユーザからしか吸い上げられないと思っています。

それは、アンケートとかそういった形式的な手法によるものではなく、サポート等を通じて直接肌で感じるべきで、そのために、僕自身がずっとサポートをやっています。

これまで1〜2週間に1回程度のリリースを繰り返してきていますが、その多くは、サポートの中で出てきた要望やアイデアです。

そして自分自身もターゲットユーザなので、ドッグフーディングしながら実装に落とし込んでいきます。

「この機能は失敗した。作り直したい」「この機能不要だった」と思ったことや、ユーザさんから「使いにくい」「業務と合っていない」と言われることなどは、この3年間ほとんどありませんでした。

それはこういう取り組みの成果なのかなと思っています。

まとめ

抽象的は話になってしまっていますが、「他のサービスよりちょっと使い勝手が良いもの」を作りたいわけではなく、既存のサービスでは解決できなかった問題を解決したいと思ってサービス開発をしています。

そのためには、ユーザや現場の業務と向き合うことが大事なんじゃないかなと思っています。

 

あと、完全に個人的な意見ですが、いち作り手として、真似して作るのは面白くないですよね。