受託開発の会社が自社サービスを立ち上げて軌道に乗せるまでの取り組み

1. 受託開発の会社が自社サービスを立ち上げて軌道に乗せるまでの取り組み明日の開発カンファレンス 2019

2. 自己紹介  田向祐介（@fw_tx76129）  ヴェルク株式会社代表 / エンジニア  フューチャーアーキテクト →10人規模のベンチャー →起業  現在でもバリバリコードを書いている

3. ヴェルクで取り込んでいること  受託開発でスタートした会社で、現在7名  受託と自社サービスとの両立を目指して取り組む  今期で自社サービス（board）の売上が全体の約6割になる見込み  boardはサービススタートから5年目  資金調達はせず、じっくり完成度の高いサービスを作っていくスタンス

4. 資金調達をせず受託を基本としながら非常に限られたリソースでサービスを立ち上げ伸ばしていくために行っている工夫や取り組みの話

5. boardとは

6. 見積書・発注書・納品書・請求書作成 + 周辺業務・経営の効率化 https://the-board.jp

7. 一般的な請求書作成サービスとの違い  書類作成のために作られたシステムではなく、業務・経営を効率化・自動化するために設計されたシステム  大手企業の業務システムを構築してきた経験を活かして、スモールビジネス向けに、経営者自身が設計・開発  営業戦略や経営判断で重要な、未来の見込みを把握するための仕組み書類作成サービスではなく業務・経営管理システム

8. boardの運営で特徴的なこと  開発ロードマップの公開（2015年1月〜）  即レスサポート  回答時間の中央値10分以下  回答時間の中央値公開（2015年3月〜）  個別相談会  これまで300回以上実施し、全て代表が出席している  boardの使い方はもちろん、経営的・業務的な相談にも対応

9. 現在のboardの状況（2019/4/24現在）  有料アカウント：1988社  毎月の新規有料アカウント：60〜80社前後  有料解約率：0.5%〜1%前後  ユーザ層  数人〜数十人規模の会社が一番多い  元々はIT関連の会社が一番多いが、最近はあまり偏りはない（受託型のビジネスモデルならどこでも）  社内体制  開発2人（自分＋もう1名）  CS：2人  個別相談会・テストなど：0.5人

10. 10人の会社で有料1万社を目指すため可能な限り人手がかからない運用を目指している

11. 限られたリソースを何に注力すべきか

12. プロトタイプからβ公開までの流れ  秋の連休に、プロトタイプを一気に作った  そこから2ヶ月ほどで、最低限の機能を開発して、α版として自社で使い始める  この辺で受託が忙しくてなかなか時間が取れず  αからクローズドβまでは2ヶ月はバグフィックスが中心  クローズドβからパブリックβの3ヶ月は、公開にあたって最低限必要な機能が中心で、思うような機能追加はできなかった

13. やっぱり受託をやりながらだと全く思うように開発が進まない・・・

14. しかも開発だけではなく、こんなに考えないといけないことがあるらしい企画開発自動テストマーケティング広告 PR （広報） SEO CS UI/UX 改善 CV改善 KPI etc ユーザヒアリング＊適当にリストアップしたものなので網羅しているわけではありません

15. 初期開発時のうちの状況  受託のエンジニア・プロマネしかいない  資金調達していないから受託を減らせない  当然サービス専任は無理  Webサービス初めて  マーケティング、広告、PR素人  CSやったことない  UI/UX改善は見よう見まね  CV改善は何やったらいいの？  KPI何それ・・・

16. 調達してリソースが十分あるスタートアップと同じことをやってもできるわけがない

17. 限られたリソースで広く浅くやるよりも思い切って “今”一番必要なことに絞ってしまおう

18. 集中すべきものを絞り込み企画開発自動テストマーケティング広告 PR （広報） SEO サポート UI/UX 改善 CV改善 KPI etc ユーザヒアリング

19. 選んだ理由 - 開発  とにかくプロダクトそのものが一番大事  エンジニアの会社なので、当然ここが一番の強み  業務システムは、大規模を含め10年やってきているので、唯一の強みで違いを作れるところ  ファンになってもらう完成度を目指す

20. 選んだ理由 - サポート  無名の受託ベンチャーのサービスなんて知名度が低すぎて、どう考えても新規獲得が課題  お試ししてくれた人を逃さないためにも、圧倒的なサポートで差別化  急に知名度が上がったり、新規獲得を増やすのは無理でも、サポートだったら今すぐにでも力を入れられる

21. 選んだ理由 - 企画  競合を参考にしながらやっていては差別化できない  自分たちの強みを徹底的に活かす  経営者＆経理＆開発者  これを兼任している人は少ない  開発しながらドッグフーディングできる  受託・コンサルで業務システムを10年やってきて、多くの企業・業界の業務を多くみてきている

22. 選んだ理由 – PR（広報）  それでもやっぱりメディア露出はしたい  活動しないとチャンスすらないので勉強も兼ねて

23. 選んだ理由 – SEO  最初は「board」で検索しても全然見つからない  これはかなり深刻  サービス名重要・・・  資金力がないので、広告を出し続けるのは無理  継続的な流入を維持するためには不可欠だが、急にやってもどうにかなるものではないため、最初から地道に続ける

24. 選ばなかった理由  それ以外のものは、スタートアップ界隈では当然やるべきことと言われているけど・・・  使ってもらえるだけの「モノ」がないと始まらない  ユーザの満足度を上げる手段は、  ニーズに合った完成度の高いシステム  困ったらすぐに教えてもらえるサポート  他の点は、この2点以上の重要性はないと思う  なので、本当に必要な最低限だけ突き抜ける方針

25. この話をすると “いいものを作っても売れなければ意味がない” “間違った方向で開発が進むリスクがある” と言われる

26. その通りだとは思うけど自分たちのリソースと強み・弱みを考えるとこの選択だった

27. とは言えサービスの成長が遅いと事業継続的に厳しいのでは？

28. そこが自己資金だけでやっている場合のメリットだと思う外からのプレッシャーはなく受託で食べているので収益化を急ぐ必要はない

29. このスタンスは経営者の割り切りが必要

30. 開発の方針・スタンス

31. 「開発カンファレンス」なので開発寄りの話に絞ってやっていることを紹介していきます

32. 開発においても初期段階で力を入れるところ後から対応していくところコアなものはどれかを考え明確に強弱をつける

33. いいものを作れば売れる時代じゃないけど知名度・営業力がないので他のサービスと比べて「明らかに良い」でないと売れない多くの人は「ちょっと良い」程度だと有名な方を選ぶ

34. “すごく良さそうなんだけどなんで有名じゃないんですか？” って何度言われたことか・・・

35. 営業をしない（いない）マーケティング担当いない広告を出すお金もない

36. 口コミ頼み

37. 業務システムで口コミ？

38. とても難しいでもそれで口コミで広まるくらいのプロダクトの良さを目指していくしかない

39. プロダクトそのものがすべて

40. スモールスタート？  一般的にはスモールスタートすべきと言われている  当然だと思うけど、無名のサービスを試してもらえる機会は少ない  マーケティングコストをかけられない、知名度が低いからこそ、一度試したら使い続けたくなる・シェアしたくなるレベルの完成度は最初から到達しておく必要がある  「多機能」ではなく「完成度」  スモールすぎると前に進まないので、バランスは重要で、自分の強み・弱みを考えて、「リスクを取るところ」と判断した

41. 開発における方針  最初から「技術的」な観点でのあるべき姿を求めすぎない  できるだけ最小限の労力で売れるものを作る  開発手法、方法論、設計、採用技術などは妥当であれば十分  こだわりゼロ。継続的に開発して改善していけばよい  自分の環境にあった方法を自分の頭で考えることが重要  独自UIの実装は時間がかかるので頑張らない  時間をかけるのは、業務フィット感やユーザ視点での完成度

42. 継続的な開発・リリース  なるべく細かくリリースする  リリース回数  2016年：43回  2017年：49回  2018年：39回  「○○があれば売れる」というような銀の弾丸はないので、コツコツ継続的に改善を続けることが大事

43. 開発ロードマップ  半年ごとに開発ロードマップの決めて公開  直接対面する機会がないので、boardはどういうスタンスなのかというのを知ってもらうきっかけ  一度ロードマップを決めたら、半年間はそれが軸なので、要望に惑わされなくなり、開発に集中できる  「要望に対する対応方針」も公開している

44. インフラ  あまり難しいことは考えず、シンプルに、EC2・RDS・ ElastiCache・S3などを使ったオーソドックスな構成  凝ったことはしない  特に初期段階ではパフォーマンスに開発時間を割きたくないので、最初から大きいインスタンスを使うなど、お金で解決  ある程度軌道に乗ってきてから、将来的なことを見据えて、アプリケーション側のパフォーマンスを改善していっている

45. セキュリティ  専門ではないので外部に頼る  WAF：Scutum  IDS・IPS：DeepSecurity  セキュリティテスト：VAddy  脆弱性検出：Vuls

46. 無駄なものを作らない工夫・仕掛け  競合はほとんど見ない  競合が搭載している機能 ≠ 本当に必要な機能  サポートでユーザと向き合っていれば、自然とニーズはわかってくる  boardの世界観・思想・方針を大事にする  心理的にも迷ってしまうので  「限られた時間」は、無駄なものを作らないためには良い  本当に必要かどうかをかなり慎重に吟味する  「あったらいいね」レベルに時間を割けない  結果的にかなり厳選される

47. ユーザの声に直接触れる  ユーザの声は改善の源泉  自分自身、サポートをやり続けてきた  開発者がサポートに関わるメリット  使いにくい機能を作ってしまった時のつらさ  整理された「要望リスト」ではなく、肌で強弱が感じることができる  30分で実装できることで劇的に問い合わせが減るような改善に気づける  ツライこともあるけど、オススメです

48. ユーザの声に惑わされない  でも、軸がぶれてしまってはダメ  ユーザの声が答えではない  社内政治的・営業的・マーケ的観点で決断しない  有名企業や一部からの強い声に流されない  「○○を対応してくれたら導入する」  申し訳ないけど、一切検討の土台に乗せない  プロダクトオーダーとしての自分は、軸を守って正しく進化させるのが仕事  マーケティング・営業的な立場と相反する別人格を作り出すイメージ

49. 要望の管理  要望はすべてTrelloに登録  現時点で1000件以上ある  Trello上、開発に着手する前の段階で細かく分かれている  アイデア（高・中・低）  対応候補  対応予定  ロードマップ公開済  軽微な改善（候補・対応確定）

50. 開発候補の優先順位付け  半年に1回の開発ロードマップ決定時にすべて見返す  以下をバランス良く配分  要望のある新機能  既存機能の改善  boardとして進みたい方向のための機能追加  やらないこと  要望が多くても方針・思想と合わないもの  有名企業・大企業の声を優先すること  個別カスタマイズとにかく一貫した思想と筋が通った設計を大事にする

51. 取捨選択で気をつけていること  業務システムである以上、「そこにある業務」をカバーしていないと使ってはもらえないので、「機能が少ないこと」を維持する難しさ  安易に機能の○×で売ろうとしない  「要望数」ではなくサポートの中で感じる肌感覚・温度感  一度リリースした機能を削除することはとても難しい  「自分たちのboardにこれは必要か」という感覚を忘れない  迷ったら、あえて少し足りないくらいでリリースしてみる  ほとんどの場合、それで問題なかったりする

52. 開発リソースの配分  システムそのものの完成度が一番大事  プログラム的な品質はもちろん、仕様・設計の完成度・品質  ヘルプやサポートも大事なユーザ体験のひとつ  ヘルプの検索性、効率的なサポートのためのCSチーム側の仕組み、時間外の問い合わせの自動応答など、システム的な観点でもそれらの改善を忘れない  導入のしやすさや継続率に影響してくると思うので、事業としてはとても大事

53. 最近力を入れていること

54. パフォーマンス  速さは正義  極めて重要なUXの要素だと思う  元々、「さくさく動いて快適」と言われることが多かった  ある程度、お金で解決していた部分  昨年、通常の開発と並行して、パフォーマンス改善  従来から40%ほど高速化して、かなりサクサクに  まだまだ改善の余地はあるので、パフォーマンスにはもっとリソースを投資したい

55. 自動テストの整備  開発初期〜3年目くらいまでは自動テストはなかった  エンジニア的にはダメかもしれないけど、事業がうまくいくかわからない段階で、そこにリソースを割けなかった  昨年1年間かけて自動テストやテストケースを整備  「ライブラリのアップデートを日常にする」という目的を置いて、そのためのテストの整備を行った

56. この後さらに力を入れていくこと

57. 安定性・自動化  少ない人数で回していくためには不可欠  エンジニア2名、CS2名で2000社を回せているのは効率的だとは思うけど、これをよりレベルを上げていきたい  自動化・安定化にリソース・コストをかけていく

58. まとめ

59. リソースが十分あるならやれることを全部やった方がいいと思う

60. でもそれが無理なら優先順位をはっきりさせて強弱をつける

61. プロダクトそのものが一番大事 '

62. 急がば回れで地道に開発・改善を継続する '

63. こんな感じで資金調達をしなくてもメディア露出が少なくても営業がいなくても事業として成立するレベルまでサービスを伸ばせるひとつの事例になればいいかなと

64. ご清聴ありがとうございました enjoy life and creation

受託開発の会社が自社サービスを立ち上げて軌道に乗せるまでの取り組み

受託開発の会社が自社サービスを立ち上げて軌道に乗せるまでの取り組み

Recommended

More Related Content

What's hot

What's hot(20)

Similar to 受託開発の会社が自社サービスを立ち上げて軌道に乗せるまでの取り組み

Similar to 受託開発の会社が自社サービスを立ち上げて軌道に乗せるまでの取り組み(20)

More from Yusuke Tamukai

More from Yusuke Tamukai(7)

Recently uploaded

Recently uploaded(7)

受託開発の会社が自社サービスを立ち上げて軌道に乗せるまでの取り組み