受託開発をやっている会社がboard（https://the-board.jp/ ）という自社サービスの開発・運営をしていく中で工夫していることの紹介です。

1. 受託の会社が自社サービスをやる中で
取り組んでいる開発・運用の工夫
2016/02/08
Startup Geeks #1
ヴェルク田向祐介

2.  田向祐介（@fw_tx76129）
 ヴェルク株式会社
 フューチャーアーキテクト→ベンチャー
→起業
 現在起業して6年目
 スマホアプリ開発・クラウド・Webシス
テム開発など
自己紹介

3. ヴェルクという会社でやっていること

4. 受託開発と自社サービスを
両立しようとしている

5. 受託では
Rails・Obj-C・Swift・Titanium・
AWS・BigQuery・Tableau
などを使って開発

6. 自社サービス
クラウド型業務・経営管理システム
「board」
スマホアプリCMS「Patto」

7. 受託の会社が自社サービスをやる際の壁

8. 2012年の自分のブログ
当時の苦悩が・・・
http://blog.velc.jp/post/26303968292/7

9. 受託開発の会社が
自社サービスをやるにあたっての壁
• 受託とのバランスや継続性
• 継続開発
• 自分たちで企画・ビジネスを考えること
• マーケティングや集客
• ユーザのニーズの把握や継続的な改善
などなど

10. これらに対する取り組みは
今日は全部はお話できないので
興味がある方はブログをご覧ください
http://blog.velc.jp/

11. boardってなに？

12. https://the-board.jp
見積書・請求書の作成・発行から
発注管理・売上見込管理・経営分析など
個人事業主・中小規模の会社の
業務・経営をサポートするシステム

13. 自分が会社を経営していく上で
欲しいから作った

14. 見積書や請求書のサービスはあるよね？

15. 書類を作ることも大事だけど
経営する上では
いかにして売上の見込みを把握するが重要
既存の見積書・請求書サービスだと
経営管理のために別途Excelで
集計しないといけなかったので
経営者視点で設計・開発

16. ドッグフーディングしながら開発している

17. 新しい分野のサービスではない
でも既存の分野で不十分な部分はたくさんある
業務と向き合って
ドッグフーディングして
スモールビジネス向け業務システムの
レベルを向上させたい

18. 有料継続率98%
“こういうのを
待ってた”
“業務をわかってい
る人が作っている”
“今まで使った業務
系システムで断トツ
で使いやすい”
“ユーザと一緒に
開発している感じ
がする”“なんで有名じゃ
ないんですか？”
“ファンになった”
1年半ほど運用して・・・

19. 受託の会社としてのサービス開発の工夫

20. 受託で稼いだお金を投資している形なので
コストをかけられない
boardでコストがかかりすぎると
それを補う受託の方が大変になる
とにかく最小限の体制・コストで！

21. boardの開発・運営体制
• 自分ともう1名の2名チーム
• 2人とも受託案件との掛け持ち
• 企画・開発・ユーザサポート・マーケティング関連は自分
が担当
• 品質管理（テスト）をもう1名が担当
• 必要なスキルの人を全部集めたら固定費が上がってしまう
ので、出来る限り自分たちでできるようにする
• 外部に協力を仰いだのは、広報とSEO
• これも丸投げではなく自分でできるようになる

22. ドッグフーディングできるものを作る
• 汎用的な書類作成サービスではなく、「受託ビジネ
ス」にフォーカスを当てる
• 受託ビジネス特有の業務や数字の見方など、最適され
れるので業務にフィットし差別化に繋がる
• 自分たちがやっている業務なので、よくわかっている
• よくわかっていることであれば、調査やヒアリングの
時間はだいぶ削減できる

23. 受託とのバランスの取り方
• 受託案件もboardも大きな山を作らないようにする
• 山があると他のことが止まってしまう
• 受託の営業・要件定義段階からセットで考える
• 常にboardの開発やユーザサポートが毎日タスクとして
ある想定で受託案件の受注やスケジューリングをする
• 受託案件単体でのスケジュールやリソース管理は行わず、
boardを含めた全体のリソース管理をする

24. 無駄なものを作らない
• あらかじめ無駄なものがわかっていれば苦労はないけど、
無駄なものを作らない・機能を削る努力は必要
• 「○○を作るのにこれだけ期間が必要」ではなく、「この期
間でどれを開発しようか」という視点で考えていると、本
当に必要と思うものだけ吟味するようになる
• リソースが限られていると、自然と無駄なものが減る気が
する
• 少し足りないくらいでリリースしてみる

25. 開発のペースの確立
• 小規模な開発（1〜2週間）と中規模な開発（1ヶ月）を
平行して進める
• 大規模な開発は1年間は手をつけなかった
• 小規模開発は、週の前半に開発し、後半にテスト、問題
がなければリリースというサイクル
• 細かい開発・テストであればスキマ時間できる
• 小規模なものと中規模なものを平行して進めることで、
素早い改善と機能追加のペースを維持

26. 開発対象の機能や仕様の決め方
• ロードマップは自分が一貫した軸を持って考える
• 原則合議制は取らない
• 話し合って決めると、中途半端な結論に落ち着きがちな
ので、その業務を知っている者が責任を持って決める
• ただし、もちろん迷った時は相談する
• テストを担当するメンバーが仕様の詳細や背景を知らないと、
初めて触った時の分かりにくさや違和感に気づきやすく、そ
れで修正した仕様はいくつもある
• 事前にユーザビリティテストをできない分をここで補う

27. 要望対応の判断基準
• 要望はかなりたくさん頂く
• 要望に流れさて軸がぶれないようにするため、自分なり
の判断基準を作る
• 自分自身がその機能を欲しいか（最重要）
• 自分が使わない機能の場合、納得感があるか（使わ
ない立場として、その必要性を理解できるか）
• boardの方向性とあっているか
• 業務効率化にプラスにならない独自の習慣に対する要望
はお断りする勇気

28. 開発ロードマップの公開
• 開発ロードマップを公開している
• https://the-board.jp/blogs/roadmap_of_board
• 今後の予定がわかるので、ユーザさんにとっても安心材
料になる
• 自社サービスは受託と違って納期がないので、モチベー
ション管理が難しかった
• ロードマップの公開は程よいプレッシャーになる

29. 開発者がユーザサポート
• 使いにくい機能をリリースしたら問い合わせ対応が大変
になるので、必死に考えるようになる
• ユーザの反応を肌で感じられるようになるので、「声の
大きさ」に惑わされなくなる

30. 現在取り組み中のこと

31. 他のメンバが受託の空き時間にboard
• 仕様を詳しく知らなくてもできる簡単な改善を残してお
く
• 他のメンバーが受託の空き時間に数時間〜数日で対応
2ヶ月ほど試してみたところ・・・
• board自体の改善は進む
• 簡単な改修だと面白くないという問題

32. 一気に全員が関わるのではなく
ひとりずつ仕様理解度を上げていくべき？

33. おまけ

34. boardで使っている技術・サービス
• フレームワーク：Rails
• リポジトリ：Github
• 開発環境：Vagrant（基本的に各自自由）
• サーバ：AWS
• 構成管理：Ansible
• 監視：NewRelic
• CI：CircleCI
• エラー通知：airbrake
• WAF：Scutum
• IDS/IPS：Deep Security
• セキュリティテスト：VAddy
• メール配信：SendGrid
• 決済：WebPay
• サポート：intercom
• タスク管理：Trello

35. エンジニア募集しています！
https://www.wantedly.com/projects/42986

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