Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

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

21.354 visualizaciones

Publicado el

明日の開発カンファレンス2019の発表資料です。

Publicado en: Tecnología
  • DOWNLOAD FULL MOVIE, INTO AVAILABLE FORMAT ......................................................................................................................... ......................................................................................................................... ,DOWNLOAD FULL. MOVIE 4K,FHD,HD,480P here { https://tinyurl.com/yybdfxwh }
       Responder 
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí

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

  1. 1. 受託開発の会社が 自社サービスを立ち上げて 軌道に乗せるまでの取り組み 明日の開発カンファレンス 2019
  2. 2. 自己紹介  田向祐介(@fw_tx76129)  ヴェルク株式会社 代表 / エンジニア  フューチャーアーキテクト →10人規模のベンチャー →起業  現在でもバリバリコードを書いている
  3. 3. ヴェルクで取り込んでいること  受託開発でスタートした会社で、現在7名  受託と自社サービスとの両立を目指して取り組む  今期で自社サービス(board)の売上が全体の約6割になる 見込み  boardはサービススタートから5年目  資金調達はせず、じっくり完成度の高いサービスを作って いくスタンス
  4. 4. 資金調達をせず 受託を基本としながら 非常に限られたリソースで サービスを立ち上げ伸ばしていくために 行っている工夫や取り組みの話
  5. 5. boardとは
  6. 6. 見積書・発注書・納品書・請求書作成 + 周辺業務・経営の効率化 https://the-board.jp
  7. 7. 一般的な請求書作成サービスとの違い  書類作成のために作られたシステムではなく、業務・経営 を効率化・自動化するために設計されたシステム  大手企業の業務システムを構築してきた経験を活かして、 スモールビジネス向けに、経営者自身が設計・開発  営業戦略や経営判断で重要な、未来の見込みを把握するた めの仕組み 書類作成サービスではなく業務・経営管理システム
  8. 8. boardの運営で特徴的なこと  開発ロードマップの公開(2015年1月〜)  即レスサポート  回答時間の中央値10分以下  回答時間の中央値公開(2015年3月〜)  個別相談会  これまで300回以上実施し、全て代表が出席している  boardの使い方はもちろん、経営的・業務的な相談にも 対応
  9. 9. 現在のboardの状況(2019/4/24現在)  有料アカウント:1988社  毎月の新規有料アカウント:60〜80社前後  有料解約率:0.5%〜1%前後  ユーザ層  数人〜数十人規模の会社が一番多い  元々はIT関連の会社が一番多いが、最近はあまり偏りはない (受託型のビジネスモデルならどこでも)  社内体制  開発2人(自分+もう1名)  CS:2人  個別相談会・テストなど:0.5人
  10. 10. 10人の会社で有料1万社を目指すため 可能な限り人手がかからない運用 を目指している
  11. 11. 限られたリソースを何に注力すべきか
  12. 12. プロトタイプからβ公開までの流れ  秋の連休に、プロトタイプを一気に作った  そこから2ヶ月ほどで、最低限の機能を開発して、α版とし て自社で使い始める  この辺で受託が忙しくてなかなか時間が取れず  αからクローズドβまでは2ヶ月はバグフィックスが中心  クローズドβからパブリックβの3ヶ月は、公開にあたって 最低限必要な機能が中心で、思うような機能追加はできな かった
  13. 13. やっぱり受託をやりながらだと 全く思うように開発が進まない・・・
  14. 14. しかも開発だけではなく、こんなに考えな いといけないことがあるらしい 企画 開発 自動 テスト マーケ ティング 広告 PR (広報) SEO CS UI/UX 改善 CV改善 KPI etc ユーザ ヒアリング *適当にリストアップしたものなので網羅しているわけではありません
  15. 15. 初期開発時のうちの状況  受託のエンジニア・プロマネしかいない  資金調達していないから受託を減らせない  当然サービス専任は無理  Webサービス初めて  マーケティング、広告、PR素人  CSやったことない  UI/UX改善は見よう見まね  CV改善は何やったらいいの?  KPI何それ・・・
  16. 16. 調達してリソースが十分ある スタートアップと同じことをやっても できるわけがない
  17. 17. 限られたリソースで 広く浅くやるよりも 思い切って “今”一番必要なことに 絞ってしまおう
  18. 18. 集中すべきものを絞り込み 企画 開発 自動 テスト マーケ ティング 広告 PR (広報) SEO サポート UI/UX 改善 CV改善 KPI etc ユーザ ヒアリング
  19. 19. 選んだ理由 - 開発  とにかくプロダクトそのものが一番大事  エンジニアの会社なので、当然ここが一番の強み  業務システムは、大規模を含め10年やってきているので、 唯一の強みで違いを作れるところ  ファンになってもらう完成度を目指す
  20. 20. 選んだ理由 - サポート  無名の受託ベンチャーのサービスなんて知名度が低すぎて、 どう考えても新規獲得が課題  お試ししてくれた人を逃さないためにも、圧倒的なサポー トで差別化  急に知名度が上がったり、新規獲得を増やすのは無理でも、 サポートだったら今すぐにでも力を入れられる
  21. 21. 選んだ理由 - 企画  競合を参考にしながらやっていては差別化できない  自分たちの強みを徹底的に活かす  経営者&経理&開発者  これを兼任している人は少ない  開発しながらドッグフーディングできる  受託・コンサルで業務システムを10年やってきて、多 くの企業・業界の業務を多くみてきている
  22. 22. 選んだ理由 – PR(広報)  それでもやっぱりメディア露出はしたい  活動しないとチャンスすらないので勉強も兼ねて
  23. 23. 選んだ理由 – SEO  最初は「board」で検索しても全然見つからない  これはかなり深刻  サービス名重要・・・  資金力がないので、広告を出し続けるのは無理  継続的な流入を維持するためには不可欠だが、急にやって もどうにかなるものではないため、最初から地道に続ける
  24. 24. 選ばなかった理由  それ以外のものは、スタートアップ界隈では当然やるべき ことと言われているけど・・・  使ってもらえるだけの「モノ」がないと始まらない  ユーザの満足度を上げる手段は、  ニーズに合った完成度の高いシステム  困ったらすぐに教えてもらえるサポート  他の点は、この2点以上の重要性はないと思う  なので、本当に必要な最低限だけ突き抜ける方針
  25. 25. この話をすると “いいものを作っても売れなければ意味がない” “間違った方向で開発が進むリスクがある” と言われる
  26. 26. その通りだとは思うけど 自分たちのリソースと 強み・弱みを考えると この選択だった
  27. 27. とは言え サービスの成長が遅いと 事業継続的に 厳しいのでは?
  28. 28. そこが自己資金だけでやってい る場合のメリットだと思う 外からのプレッシャーはなく 受託で食べているので 収益化を急ぐ必要はない
  29. 29. このスタンスは 経営者の割り切りが必要
  30. 30. 開発の方針・スタンス
  31. 31. 「開発カンファレンス」なので 開発寄りの話に絞って やっていることを紹介していきます
  32. 32. 開発においても 初期段階で力を入れるところ 後から対応していくところ コアなものはどれかを考え 明確に強弱をつける
  33. 33. いいものを作れば売れる時代じゃないけど 知名度・営業力がないので 他のサービスと比べて 「明らかに良い」でないと売れない 多くの人は 「ちょっと良い」程度だと 有名な方を選ぶ
  34. 34. “すごく良さそうなんだけど なんで有名じゃないんですか?” って何度言われたことか・・・
  35. 35. 営業をしない(いない) マーケティング担当いない 広告を出すお金もない
  36. 36. 口コミ頼み
  37. 37. 業務システムで口コミ?
  38. 38. とても難しい でもそれで口コミで広まるくらいの プロダクトの良さを目指していくしかない
  39. 39. プロダクトそのものがすべて
  40. 40. スモールスタート?  一般的にはスモールスタートすべきと言われている  当然だと思うけど、無名のサービスを試してもらえる機会は少 ない  マーケティングコストをかけられない、知名度が低いからこそ、 一度試したら使い続けたくなる・シェアしたくなるレベルの完 成度は最初から到達しておく必要がある  「多機能」ではなく「完成度」  スモールすぎると前に進まないので、バランスは重要で、自分 の強み・弱みを考えて、「リスクを取るところ」と判断した
  41. 41. 開発における方針  最初から「技術的」な観点でのあるべき姿を求めすぎない  できるだけ最小限の労力で売れるものを作る  開発手法、方法論、設計、採用技術などは妥当であれば十分  こだわりゼロ。継続的に開発して改善していけばよい  自分の環境にあった方法を自分の頭で考えることが重要  独自UIの実装は時間がかかるので頑張らない  時間をかけるのは、業務フィット感やユーザ視点での完成度
  42. 42. 継続的な開発・リリース  なるべく細かくリリースする  リリース回数  2016年:43回  2017年:49回  2018年:39回  「○○があれば売れる」というような銀の弾丸はないので、 コツコツ継続的に改善を続けることが大事
  43. 43. 開発ロードマップ  半年ごとに開発ロードマップの決めて公開  直接対面する機会がないので、boardはどういうスタンス なのかというのを知ってもらうきっかけ  一度ロードマップを決めたら、半年間はそれが軸なので、 要望に惑わされなくなり、開発に集中できる  「要望に対する対応方針」も公開している
  44. 44. インフラ  あまり難しいことは考えず、シンプルに、EC2・RDS・ ElastiCache・S3などを使ったオーソドックスな構成  凝ったことはしない  特に初期段階ではパフォーマンスに開発時間を割きたくな いので、最初から大きいインスタンスを使うなど、お金で 解決  ある程度軌道に乗ってきてから、将来的なことを見据えて、 アプリケーション側のパフォーマンスを改善していってい る
  45. 45. セキュリティ  専門ではないので外部に頼る  WAF:Scutum  IDS・IPS:DeepSecurity  セキュリティテスト:VAddy  脆弱性検出:Vuls
  46. 46. 無駄なものを作らない工夫・仕掛け  競合はほとんど見ない  競合が搭載している機能 ≠ 本当に必要な機能  サポートでユーザと向き合っていれば、自然とニーズ はわかってくる  boardの世界観・思想・方針を大事にする  心理的にも迷ってしまうので  「限られた時間」は、無駄なものを作らないためには良い  本当に必要かどうかをかなり慎重に吟味する  「あったらいいね」レベルに時間を割けない  結果的にかなり厳選される
  47. 47. ユーザの声に直接触れる  ユーザの声は改善の源泉  自分自身、サポートをやり続けてきた  開発者がサポートに関わるメリット  使いにくい機能を作ってしまった時のつらさ  整理された「要望リスト」ではなく、肌で強弱が感じ ることができる  30分で実装できることで劇的に問い合わせが減るよう な改善に気づける  ツライこともあるけど、オススメです
  48. 48. ユーザの声に惑わされない  でも、軸がぶれてしまってはダメ  ユーザの声が答えではない  社内政治的・営業的・マーケ的観点で決断しない  有名企業や一部からの強い声に流されない  「○○を対応してくれたら導入する」  申し訳ないけど、一切検討の土台に乗せない  プロダクトオーダーとしての自分は、軸を守って正しく進 化させるのが仕事  マーケティング・営業的な立場と相反する別人格を作 り出すイメージ
  49. 49. 要望の管理  要望はすべてTrelloに登録  現時点で1000件以上ある  Trello上、開発に着手する前の段階で細かく分かれている  アイデア(高・中・低)  対応候補  対応予定  ロードマップ公開済  軽微な改善(候補・対応確定)
  50. 50. 開発候補の優先順位付け  半年に1回の開発ロードマップ決定時にすべて見返す  以下をバランス良く配分  要望のある新機能  既存機能の改善  boardとして進みたい方向のための機能追加  やらないこと  要望が多くても方針・思想と合わないもの  有名企業・大企業の声を優先すること  個別カスタマイズ とにかく一貫した思想と筋が通った設計を大事にする
  51. 51. 取捨選択で気をつけていること  業務システムである以上、「そこにある業務」をカバーしてい ないと使ってはもらえないので、「機能が少ないこと」を維持 する難しさ  安易に機能の○×で売ろうとしない  「要望数」ではなくサポートの中で感じる肌感覚・温度感  一度リリースした機能を削除することはとても難しい  「自分たちのboardにこれは必要か」という感覚を忘れない  迷ったら、あえて少し足りないくらいでリリースしてみる  ほとんどの場合、それで問題なかったりする
  52. 52. 開発リソースの配分  システムそのものの完成度が一番大事  プログラム的な品質はもちろん、仕様・設計の完成 度・品質  ヘルプやサポートも大事なユーザ体験のひとつ  ヘルプの検索性、効率的なサポートのためのCSチーム 側の仕組み、時間外の問い合わせの自動応答など、シ ステム的な観点でもそれらの改善を忘れない  導入のしやすさや継続率に影響してくると思うので、 事業としてはとても大事
  53. 53. 最近力を入れていること
  54. 54. パフォーマンス  速さは正義  極めて重要なUXの要素だと思う  元々、「さくさく動いて快適」と言われることが多かった  ある程度、お金で解決していた部分  昨年、通常の開発と並行して、パフォーマンス改善  従来から40%ほど高速化して、かなりサクサクに  まだまだ改善の余地はあるので、パフォーマンスには もっとリソースを投資したい
  55. 55. 自動テストの整備  開発初期〜3年目くらいまでは自動テストはなかった  エンジニア的にはダメかもしれないけど、事業がうまくい くかわからない段階で、そこにリソースを割けなかった  昨年1年間かけて自動テストやテストケースを整備  「ライブラリのアップデートを日常にする」という目的を 置いて、そのためのテストの整備を行った
  56. 56. この後さらに力を入れていくこと
  57. 57. 安定性・自動化  少ない人数で回していくためには不可欠  エンジニア2名、CS2名で2000社を回せているのは効率 的だとは思うけど、これをよりレベルを上げていきた い  自動化・安定化にリソース・コストをかけていく
  58. 58. まとめ
  59. 59. リソースが十分あるなら やれることを全部やった方がいいと思う
  60. 60. でもそれが無理なら 優先順位をはっきりさせて 強弱をつける
  61. 61. プロダクトそのものが 一番大事 '
  62. 62. 急がば回れで 地道に開発・改善を継続する '
  63. 63. こんな感じで 資金調達をしなくても メディア露出が少なくても 営業がいなくても 事業として成立するレベルまで サービスを伸ばせる ひとつの事例になればいいかなと
  64. 64. ご清聴ありがとうございました enjoy life and creation

×