受託开発の会社が自社サービスを立ち上げて轨道に乗せるまでの取り组み
- 2. 自己紹介 ? 田向祐介（@fw_tx76129） ? ヴェルク株式会社 代表 / エンジニア ? フューチャーアーキテクト →10人規模のベンチャー →起業 ? 現在でもバリバリコードを書いている
- 3. ヴェルクで取り込んでいること ? 受託開発でスタートした会社で、現在7名 ? 受託と自社サービスとの両立を目指して取り組む ? 今期で自社サービス（board）の売上が全体の約6割になる 見込み ? boardはサービススタートから5年目 ? 資金調達はせず、じっくり完成度の高いサービスを作って いくスタンス
- 5. 产辞补谤诲とは
- 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