Recommended
More Related Content
What's hot
What's hot (20)
Similar to 受託開発の会社が自社サービスを立ち上げて軌道に乗せるまでの取り組み
Similar to 受託開発の会社が自社サービスを立ち上げて軌道に乗せるまでの取り組み (20)
More from Yusuke Tamukai
受託開発の会社が自社サービスを立ち上げて軌道に乗せるまでの取り組み
- 2. 自己紹介 田向祐介（@fw_tx76129） ヴェルク株式会社 代表 / エンジニア フューチャーアーキテクト →10人規模のベンチャー →起業 現在でもバリバリコードを書いている
- 3. ヴェルクで取り込んでいること 受託開発でスタートした会社で、現在7名 受託と自社サービスとの両立を目指して取り組む 今期で自社サービス（board）の売上が全体の約6割になる 見込み boardはサービススタートから5年目 資金調達はせず、じっくり完成度の高いサービスを作って いくスタンス
- 5. boardとは
- 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人
- 12. プロトタイプからβ公開までの流れ 秋の連休に、プロトタイプを一気に作った そこから2ヶ月ほどで、最低限の機能を開発して、α版とし て自社で使い始める この辺で受託が忙しくてなかなか時間が取れず αからクローズドβまでは2ヶ月はバグフィックスが中心 クローズドβからパブリックβの3ヶ月は、公開にあたって 最低限必要な機能が中心で、思うような機能追加はできな かった
- 15. 初期開発時のうちの状況 受託のエンジニア・プロマネしかいない 資金調達していないから受託を減らせない 当然サービス専任は無理 Webサービス初めて マーケティング、広告、PR素人 CSやったことない UI/UX改善は見よう見まね CV改善は何やったらいいの？ KPI何それ・・・
- 19. 選んだ理由 - 開発 とにかくプロダクトそのものが一番大事 エンジニアの会社なので、当然ここが一番の強み 業務システムは、大規模を含め10年やってきているので、 唯一の強みで違いを作れるところ ファンになってもらう完成度を目指す
- 20. 選んだ理由 - サポート 無名の受託ベンチャーのサービスなんて知名度が低すぎて、 どう考えても新規獲得が課題 お試ししてくれた人を逃さないためにも、圧倒的なサポー トで差別化 急に知名度が上がったり、新規獲得を増やすのは無理でも、 サポートだったら今すぐにでも力を入れられる
- 21. 選んだ理由 - 企画 競合を参考にしながらやっていては差別化できない 自分たちの強みを徹底的に活かす 経営者＆経理＆開発者 これを兼任している人は少ない 開発しながらドッグフーディングできる 受託・コンサルで業務システムを10年やってきて、多 くの企業・業界の業務を多くみてきている
- 22. 選んだ理由 – PR（広報） それでもやっぱりメディア露出はしたい 活動しないとチャンスすらないので勉強も兼ねて
- 23. 選んだ理由 – SEO 最初は「board」で検索しても全然見つからない これはかなり深刻 サービス名重要・・・ 資金力がないので、広告を出し続けるのは無理 継続的な流入を維持するためには不可欠だが、急にやって もどうにかなるものではないため、最初から地道に続ける
- 24. 選ばなかった理由 それ以外のものは、スタートアップ界隈では当然やるべき ことと言われているけど・・・ 使ってもらえるだけの「モノ」がないと始まらない ユーザの満足度を上げる手段は、 ニーズに合った完成度の高いシステム 困ったらすぐに教えてもらえるサポート 他の点は、この2点以上の重要性はないと思う なので、本当に必要な最低限だけ突き抜ける方針
- 30. 開発の方針・スタンス
- 36. 口コミ頼み
- 37. 業務システムで口コミ？
- 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. まとめ
- 64. ご清聴ありがとうございました enjoy life and creation