受託の会社が調達せずに自社サービスを立ち上げ事業として成立するまでの企画・開発・サポート・マーケティング
•
94 gostaram•79,766 visualizações
BPStudy#120の発表資料です。 board（https://the-board.jp/ ）を立ち上げて事業として成立するようになるまでの取り組みを発表しました。
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (20)
Semelhante a 受託の会社が調達せずに自社サービスを立ち上げ事業として成立するまでの企画・開発・サポート・マーケティング
Semelhante a 受託の会社が調達せずに自社サービスを立ち上げ事業として成立するまでの企画・開発・サポート・マーケティング (20)
Mais de Yusuke Tamukai
Mais de Yusuke Tamukai (9)
Último
Último (9)
受託の会社が調達せずに自社サービスを立ち上げ事業として成立するまでの企画・開発・サポート・マーケティング
- 2. 自己紹介 田向祐介（@fw_tx76129） ヴェルク株式会社 代表 / エンジニア ITコンサル→ベンチャー→起業 受託開発と自社サービスの両立
- 3. ヴェルクで取り込んでいること 基本は受託開発 設立以来、自社サービスとの両立を目指して取り組む 今期でboardの売上が全体の約3割、その他含めたストック 売上が約半分になる見込み 自社サービスは、資金調達はせず、受託の売上でやりくり していくスタンス
- 5. boardとは
- 7. 一般的な請求書作成サービスとの違い 書類作成のために作られたシステムではなく、業務・経営 を効率化・自動化するために設計されたシステム 大手企業の業務システムを構築してきた経験を活かして、 スモールビジネス向けに、経営者自身が設計・開発 営業戦略や経営判断で重要な、未来の見込みを把握するた めの仕組み 書類作成サービスではなく業務・経営管理システム
- 8. 現在のboardの状況（2017/8/31現在） 有料アカウント：923社 毎月の新規お試しアカウント：300〜500社 毎月の新規有料アカウント：50〜60社 解約率：0.5%〜1%前後 数人〜数十人規模の会社が一番多い 業界はIT関連が一番多いが、最近はあまり偏りはない
- 11. 初期開発時のうちの状況 受託のエンジニア・プロマネしかいない（当時） 資金調達していないから受託を減らせない 当然サービス専任は無理 Webサービス初めて マーケティング、広告、PR素人 CSやったことない UI/UX改善は見よう見まね CV改善は何やったらいいの？ KPI何それ・・・
- 18. 選んだ理由 - 開発 エンジニアの会社なので、当然ここが一番の強み 業務システムは、大規模を含め10年やってきているので、 唯一の強みで違いを作れるところ ファンになってもらう完成度を目指す
- 19. 選んだ理由 - サポート 無名の受託ベンチャーのサービスなんて知名度が低すぎて、 どう考えても新規獲得が課題 お試ししてくれた人を逃さないためにも、圧倒的なサポー トで差別化 急に知名度が上がったり、新規獲得を増やすのは無理でも、 サポートだったら今すぐにでも力を入れられる
- 20. 選んだ理由 - 企画 競合を参考にしながらやっていては差別化できない 自分の強みを徹底的に活かす 経営者＆経理＆開発者 これを兼任している人は少ない 開発しながらドッグフーディングできる 業務システムを10年やってきている 大企業の基幹システム構築も経験してきている 受託・コンサルでお客さんの業務を多くみてきている
- 21. 選んだ理由 – PR（広報） それでもやっぱりメディア露出はしたい 活動しないとチャンスすらないので勉強も兼ねて
- 22. 選んだ理由 – SEO 最初は「board」で検索しても全然見つからない これはかなり深刻 サービス名重要・・・ 資金力がないので、広告を出し続けるのは無理 継続的な流入を維持するためには不可欠だが、急にやって もどうにかなるものではないため、最初から地道に続ける
- 23. 選ばなかった理由 それ以外のものは、スタートアップ界隈では当然やるべき ことと言われているけど・・・ 使ってもらえるだけの「モノ」がないと始まらない ユーザの満足度を上げる手段は、 ニーズに合った完成度の高いシステム 困ったらすぐに教えてもらえるサポート 他の点は、この2点以上の重要性はないと思う なので、本当に必要な最低限だけ突き抜ける方針
- 24. それ以外は本当に何もやっていないの？ 実はそんなことはなくて、「検証してみないとわからない」と は思っているので、検証目的でやってみている それらの成果・費用対効果を踏まえて、今年に入ってからはほ ぼ何もやっていないが、過去最高に伸びている 2016年（1ヶ月あたり） 新規お試しアカウント：100〜200社前後 新規有料アカウント：20社前後 2017年（1ヶ月あたり） 新規お試しアカウント：400〜500社前後 新規有料アカウント：50〜60社前後
- 25. よく言われること 「力を入れていないと言うけど、使いやすいし、デザインも良 いのは何で？」 業務システムにおける「使いやすさ」は、UIが致命的でない 限り、業務フィット感が一番大事で、そこは自信がある UI/UXは仕様のまずさをカバーするものではない 起業直後から、収益目的ではなく経験を積むために、iOSア プリを自分たちで出して、試行錯誤してした経験は大きい ゼロから自分でデザインはできないけど、その時の経験から、 「良い悪い」の感覚を少しは身につけたし、受託の仕事の中 でも日々意識するようになったのでその積み重ね
- 31. 昨年（board 2年目）までの リソース配分の優先順位 受託 > board
- 32. 1〜2年目の経営の中でのboardの位置づけ 2年目までは全く売上の予算に入れていなかった 受託だけで十分な売上を上げる予算の組み方 会社としては、大きな利益は追わず、最低限ボーナスを払 える分だけ稼げればOKというスタンスで、そこに到達し そうだったらboardへのリソース配分を増やす 今期（board3年目）初めて、予算の中にboardの売上を見 込として入れた
- 34. 企画・開発
- 37. 企画・仕様 限られたリソースの中では、ドッグフーディングできる分 野を選択することは重要 「サービスを作る」ことを目的に起業したわけではないの で、自分が弱い分野で戦うつもりはない。業務システムは 10年以上やってきていて自分の土俵 バズワードで企画・仕様を決めない。課題・ニーズから考 える。
- 38. 開発における方針 最初から「技術的」な観点でのあるべき姿を求めすぎない できるだけ最小限の労力で売れるものを作る 開発手法、方法論、設計、採用技術などは妥当であれば十分 こだわりゼロ。継続的に開発して改善していけばよい 自分の環境にあった方法を自分の頭で考えることが重要 独自UIの実装は時間がかかるので頑張らない まずはbootstrap・JQueryの世界だけで それでも、「使いやすい」「デザインがいい」と言われるの で、使い方次第 時間をかけるのは、業務フィット感やユーザ視点での完成度
- 39. スモールスタート？ 一般的にはスモールスタートすべきと言われている 当然だと思うけど、無名のサービスを試してもらえる機会は少ない マーケティングコストをかけられない、知名度が低いからこそ、一度 試したら使い続けたくなる・シェアしたくなるレベルの完成度は最初 から到達しておく必要がある 「多機能」ではなく「完成度」 そもそも自分自身が当事者として業務課題・ニーズは把握していたの で、そこの検証があまり重要ではなかった スモールすぎると前に進まないので、バランスは重要で、自分の強 み・弱みを考えて、「リスクを取るところ」と判断した。
- 40. でもコストをかけるのはリスクでは？ ずっと業務システムを開発してきたエンジニアの会社なの で、boardの分野は自分の土俵 そうでない会社に比べたらコストはかからない 自分が素人な分野に時間をかける方がリスク 一応、段階は踏んでいる 社内用α版：自社の業務が回るかの検証 クローズドβ版：知り合いを中心に外部の感想を得る パブリックβ版：この時点で十分な完成度を
- 41. 開発の進め方1 作ってみてダメだったら捨てる覚悟 これまで何度か、作ってからボツにした機能はある PRベースでコードレビュー 他のメンバーが開発する場合は必ず実施 自動テスト 当初は全く書かず 最近どんどん増やしていっている 事業としてうまくいくかわからない段階ではここにコストは 割かず、ユーザが直接メリットを享受する機能開発に専念 逆に、現在は、安定した継続開発のための取り組みに比重を 移動させつつある
- 42. 開発の進め方2 継続的な改善 大きめの追加開発のタイミングで関連する部分を大規 模にリファクタリング おそらく3年前のコードの9割は書き換わっている 初期の頃は「機能実装」が最優先で、ここ1年でようや くこういった内部的な改善に時間を割けるようになっ てきた
- 43. インフラ あまり難しいことは考えず、シンプルに、EC2・RDS・ ElastiCache・S3などを使ったオーソドックスな構成 最近、LambdaやSQSなど 業務システムの場合、アクセス数が多いわけでもないし、凝っ たことはしない 特に初期段階ではパフォーマンスに開発時間を割きたくないの で、最初から大きいインスタンスを使うなど、お金で解決 ある程度軌道に乗ってきてから、将来的なことを見据えて、ア プリケーション側のパフォーマンスを改善していっている
- 44. セキュリティ 専門ではないのでお金で解決 WAF：Scutum IDS・IPS：DeepSecurity セキュリティテスト：VAddy
- 45. コミュニケーションコスト 企画者と開発者が同じだとコミュニケーションコストが圧 倒的に低い 特殊な状況だが大きな強み 他のメンバーが開発に入った時は、特に開発中の改善サイ クルのスピードが明らかに落ちるので、同じ完成度でリ リースするためには、倍は想定してスケジューリングする 時間がかかることが問題ではなく、それを想定しておくこ とが重要
- 46. 無駄なものを作らない工夫 競合はほとんど見ない 競合が搭載している機能 ≠ 本当に必要な機能 サポートでユーザと向き合っていれば、自然とニーズ はわかってくる boardの世界観・思想・方針を大事にする 心理的にも迷ってしまうので 「限られた時間」は、無駄なものを作らないためには良い 本当に必要かどうかをかなり慎重に吟味する 「あったらいいね」レベルに時間を割けない 結果的にかなり厳選される
- 47. ユーザの声に直接触れる ユーザの声は改善の源泉 ただし、「大きな声」に左右されない軸は必要 3年間、サポートをやり続けてきた 開発者がサポートに関わるメリット 使いにくい機能を作ってしまった時にツライので、かなり気 をつけるようになる 整理された「要望リスト」ではなく、肌で強弱が感じること ができる 30分で実装できることで劇的に問い合わせが減るような改 善に気づける ツライこともあるけど、オススメです
- 48. 要望の管理 要望は全てTrelloに登録 700件以上あってもうカウントやめた 問い合わせで使っているintercomのconversationのリン クもカードに登録し、対応時に連絡できるように Trelloのリストを優先順位・軽微で時間がある時にやるも のなどに分類 2〜3ヶ月に1回程度、全部目を通し直す 自分のイメージと違い、意外と要望が多いものを把握
- 49. マーケティング・PR（広報）
- 51. PR（広報） 全く素人だったので、boardリリース前後から1年ほど、広報のプロにお願 いして、毎月ディスカッション＆施策を考えていた 「メディアに掲載してもらう」という点ではあまり成果を出せず ASCIIさんだけはがっつり記事を書いてくれたので感謝しかない http://ascii.jp/elem/000/001/145/1145452/ http://ascii.jp/elem/000/001/221/1221201/ このディスカッションの過程で得たこと 広報の基本 伝え方・表現の仕方、注意すべき点 外の人から見た意見 自分の頭で考えられるようにしないと、自社にあった方法は見つけられな いと思うので、その土台という意味で非常に重要な取り組みだった 「広報活動=メディア掲載」という視点だけで判断しない
- 52. マーケティング メディア露出がうまくいかないと、地道にやっていくしかない 事例インタビュー SNSでシェアしてもらったり、口コミのきっかけにもなる 協力して頂いた方々に本当に感謝です ブログ 自分のブログで取り組みをどんどん公開していく それをきっかけにboardを知ってもらう マーケティングがうまくいかないとユーザ数が伸びないので焦 るが、素人が見よう見真似でやったところでうまくいくわけも ないので、銀の弾丸は探さず、腰を据えて、地道な活動をして いく
- 53. メールマーケティング 資料請求や会員登録をした人にメルマガを送るのはやらない 明示的に「メルマガを購読」ではなく、サービスを使いたくて 登録したのにメルマガが来るのは、個人的に好きではない その時間・手間は開発に当てたい 業務システムの場合、効果があるのか懐疑的 会員登録を促す「仕掛け」で登録してもらっても、継続しな い可能性も高いし、そもそも業務ニーズが合っていること、 タイミングが合っていることの方が重要
- 54. ステップメール 会員登録後の数日が「最も意識が高い期間」なので、その間に 使ってもらうことが、継続してもらう確率が高くなるらしい 会員登録後の最初の3日だけ、3通に分けて、「ファーストガイ ド」を送って、それに沿って使ってみてもらうという施策を やってみた 数字的な成果はほぼなく、現在はやめた ただし、そのメール内に「個別相談会の案内」や「お問い合 わせ方法」を書くようにしたら、個別相談会やお問い合わせ が増えた気がするので、その点では効果あり 現在は、登録完了メールの中で、個別相談会・お問い合わせ・ ヘルプ・ファーストガイドなどを紹介している
- 55. 過度な表現はしない 「ワンクリックで」「○分で」「AIを使って」「○○を自動化！」 「（お試しも含めた数で）導入社数○○！」みたいな表現を使わないよ うにしている ちなみに最初の頃は「ワンクリックで」を少し使ってた 実際にシステムを使うと、「ワンクリックでできるのはごく一部じゃ ん・・・」と感じて、そのギャップは「がっかり感」に繋がる 「使ってもらうキッカケ」にはなるけど、ユーザに対して不誠実だと 思っているので、使わないことにした 受託と違い対面しないので、信頼感を落とすようなことはしない 新規獲得よりも、使ってくれている人との信頼関係の方が大事
- 56. 口コミ boardは口コミで支えられている かといって、何か口コミを誘発するような施策はしていない とあるベータユーザ 「本当にいいと思ったら、何も仕掛けやメリットがなくても 知り合いに紹介しますよ」 結局「提供しているシステムの価値の向上」が最重要で最優先 口コミの仕掛けではなく感謝の意味を込めて、還元するために 「紹介プログラム」みたいなものはやりたいけど、本質的な価 値が十分なレベルになってからでいいと思ってる
- 57. SEO お金をかけずに継続的な流入を確保するために非常に重要 「board」で1ページ目にくるまで半年以上かかったのでサービ ス名大事・・・ boardの場合、「請求書」などのキーワードを争うのが、 Misoca・freee・MF・MakeLeapsなど、規模も歴史もずっと上 のサービスでツライ 変なことはせず、地道に長い時間をかけて、良質なコンテンツ を増やしていくしかない 時間がかかるので、とにかく継続することが大事
- 58. 営業・訪問・電話 訪問しての説明、電話での説明は一切対応していない 月額980〜5,980円のサービスなので、訪問したら赤字 依頼があってもお断りしている それ以来連絡がなくなる会社も結構ある 説明が必要なケースは、後述する個別相談会でフォロー
- 59. 初期ユーザの獲得 マーケティング・PRはずっと課題。では、どうやって初期ユー ザを獲得して、口コミが広まっていったのか 開発中からTwitterでつぶやいてて、身の回りの人に、「何か 作っている」というのを知ってはもらっていた ベータリリースしたら、身の回りの人達がFacebook・Twitterで シェアしてくれた システムの特性上、Facebookは相性が良かった アーリーユーザが広めてくれた たぶん「システムの完成度」「期待感」など キャッチコピー「バックオフィス業務のために起業したのでは ない」はアタリだった
- 60. 継続的な情報発信 メディアには露出できなくても自分では発信できる ブログの本数は少ないけど、毎回しっかりと、やっている ことを書いている 他のサービスをやっている人から聞かれれば、積極的に取 り組みを紹介している 一度自分でやったことは、既に過去のものなので、積極的 に公開する方針で、それはプラスになっていると思う
- 61. サポート
- 62. 現在のお問い合わせ状況 intercomを使ったチャットサポートのみ 初回回答時間の中央値を公開 7月は4分 月300〜400件程度 チャットなのでその中で何度かやり取りがある
- 64. サポート運用の仕組み intercom→メール・Slackに流れるようになっている デスクトップ通知をトリガーにすぐに気づく ヘルプを充実させて、簡単に説明後、「詳しくは下記をご 覧ください」という形でヘルプへ誘導 回答時間の短縮・サポート効率の向上 ヘルプを認識してもらう→ヘルプを検索してくれるよ うになる ヘルプが不十分な場合は、その場で追記して回答 （日々のサポート業務の中でヘルプを改善）
- 65. 心がけていること1 「初回回答時間の中央値」を公開しているからと言って、 それをマーケティング的に使うために、その数字を上げる ためのことはしない 例えば「お問い合わせありがとうございます」と、と りあえず回答すれば速いが意味がない チャットだからといって五月雨式にメッセージを送らない ユーザは回答をしてじっと待っているわけではなく、 他の業務に移っていることが大半 バラバラと回答するとその都度手を止めてしまうので、 居心地が悪い。1回で回答するようにしている
- 66. 心がけていること2 相手に応じて表現や説明の詳しさを使い分けているので、 マニュアル化・回答のほぼテンプレート化はしていない 使い始めなのか、ある程度使っているのか システム系の会社かそれ以外か 経営者・経理・総務・システム部・営業など 質問が多い人か、初めてか 対面で話をする時は、当然相手に合わせて話をするので、 サポートのチャットでも同じことをする
- 67. 心がけていること3 boardの方針として対応しないとしているものは、きちん と理由を説明する 理解してもらえないケースはあるが、ポリシーはしっ かりと伝える 中期的に考えると、その場の解決よりも、理解を深め てもらうことの方が重要 それによって退会してしまうケースもあるが、それは 仕方ないと思っている
- 69. サポートのKPI 「どういうKPIを見ているんですか」ってよく聞かれる KPIは見ていない サポート回答時間の中央値は公開は、「いつ返事が返って くるかわからない」というユーザの不安に対するものなの でKPIにはしていない サポートについては、「可能な限り即レスで、正しい回答 をする」以外は考えておらず、他のことはそれができてか らで良いと思っている
- 70. 個別相談会 こちらから訪問はしないが、来社・Googleハングアウトでの個 別相談会は実施している 時間枠を決めて予約制で、デモ+質疑で1時間前後 個別相談会参加者の有料転換率は65%程度と非常に高い 全体の有料転換率は14%前後 営業的な売り込みはしない。システムの説明、質疑に専念 直接お話できる唯一の機会で、これまで120回ほど開催してい るが、全て自分が出席している
- 71. 開発ロードマップ サポートとは直接関係ないけど好評 今後どういった機能が追加されるのか、どういう方向性な のかがわかる 「ロードマップを公開する」という姿勢を気に入ってもら うことも多い これも対面することがないユーザさんとの信頼関係構築の 一つだと思う
- 72. まとめ
- 76. うちの場合は、 開発・サポート > マーケティング 既存ユーザ > 新規獲得
- 80. 最近取り組んでいること・今後取り組みたいこと 自動テストをはじめとした自動化のさらなる推進 少人数体制を維持したいので 開発体制・サポート体制の強化 DR（ディザスタリカバリ） SRE（Site Reliability Engineering） ユーザとの直接の接点を増やす
- 84. ご清聴ありがとうございました enjoy life and creation