受託開発の会社が自社サービスを開発・運営する中で見つけた自分たちにあったスタンス
•
9 gefällt mir•2,184 views
DevLOVE関西(https://devlove-kansai.doorkeeper.jp/events/29746 )での発表資料です。 board(https://the-board.jp )開発の現場を紹介しています。
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie 受託開発の会社が自社サービスを開発・運営する中で見つけた自分たちにあったスタンス
Ähnlich wie 受託開発の会社が自社サービスを開発・運営する中で見つけた自分たちにあったスタンス (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (9)
受託開発の会社が自社サービスを開発・運営する中で見つけた自分たちにあったスタンス
- 2. 田向祐介（@fw_tx76129） ヴェルク株式会社 ITコンサル→ベンチャー→起業 現在起業して5年目 スマホアプリ開発・クラウド・Webシス テム開発など 自己紹介
- 7. 受託開発の会社が 自社サービスをやるにあたっての壁 • 受託とのバランスや継続性 • 自分たちで企画・ビジネスを考えること • マーケティングや集客 • ユーザのニーズの把握や継続的な改善 などなど
- 11. 1〜２年目 • iPhoneアプリをいくつか出して、自分たちで企画・開 発・プロモーションしてみるということを経験する • ここで利益は追求しない • ブレストのトレーニングをしたり自分たちで試行錯誤し ながら企画を練り、自分たちで考える力をつける • 作ったものをプロモーションしてみたりして、想像以上 にうまくいかないことを体験する • 頭ではわかっているけど、どこか期待してしまうの で、それを打ち砕く
- 12. 3年目 • スマホアプリCMS「Patto」を開発 • 自社サービスの事業化を目指す • 営業はいないのでインバウンドマーケティングに取り組 み始める • ソリューション型の製品なので、半分受託的要素もあり、 自分たちの土俵でやりやすく、結果論だけど、いきなり Webサービスではないところがよかった
- 14. 平行して受託案件の安定化への取り組み • 両立のためには受託の安定化は不可欠 • 1〜2年目の受託案件は、創業社長がエンジニアの会社に ありがちな社長依存度が高い状態 • この4年間で段階的に受託における自分への依存度を下 げる取り組みを続ける • メンバーの育成、特に、リスク感覚の一致を重視して、 自分があまり入らなくても問題なく納品できる体制作り • この土台があって初めて両立のための取り組みがで きる
- 15. boardってなに？
- 20. ドッグフーディング
- 21. 開発している自分たち自身がユーザ
- 22. 自分たちに必要なものを作る
- 24. “boardは受託ビジネス向けって言っているけど、 よく出来てるし、他の業態向けは作らないの？” 他の業態は自分がやったことがないのでわからない ドッグフーディングできないからやらないというスタンス
- 26. ドッグフーディングの落とし穴 • 自分たちに最適化しすぎてしまう • 自分たちでドッグフーディングした結果が正しくない 可能性もある • システムや新機能を始めてみた時の感覚を失う • 新規ユーザへの配慮を忘れがち
- 27. 小さいチームで素早く開発する
- 28. 無駄なものを作らない • あらかじめ無駄なものがわかっていれば苦労はないけど、 無駄なものを作らない努力は必要 • 「○○を作るのにこれだけ期間が必要」ではなく、「この期 間でどれを開発しようか」という視点で考えていると、本 当に必要と思うものだけ吟味するようになる • リソースが限られていると、自然と無駄なものが減る気が する • 少し足りないくらいでリリースしてみる
- 29. コミュニケーションコストを最小限に • boardの場合、企画（仕様）を考える人と開発する人 が同じなのでコミュニケーションコストがかからない • 受託での仕様のやり取りを考えると、これはもの すごく大きい • ドッグフーディングできる内容だとこれが可能 • そもそもチームが小さいとコミュニケーションコスト は少ないので、中途半端な関わりのメンバーはなくす
- 30. 他のタスクとの兼ね合いを考慮する • 受託と平行して自社サービスをやる場合に非常に重要 • 受託案件の波やタスクの内容とタイミングを調整する • 例えば・・・ • 受託案件のリリース前後は、自社サービスは軽微 な改善のみにする • お客さんに引き渡して受入テスト中は、少し空く ので集中的に自社サービスの方を進める
- 31. 自分達の適した進め方を自分達で考える • いろいろな開発手法・プロジェクト管理手法があるけ れど、たぶん受託と平行して進めることを前提で考え られているものはない • リソースのバランスが一番重要で、ここの舵取りは、 自分たちの置かれた状況にあったやり方を見つけない といけないと思う • boardでのやり方はこの後紹介します
- 32. board開発の進め方
- 34. boardの開発・運営体制 • 自分ともう1名の2名チーム • 2人とも受託案件との掛け持ち • 企画・開発・ユーザサポート・マーケティング関連は自分 が担当 • 品質管理（テスト）をもう1名が担当 • 必要なスキルの人を全部集めたら固定費が上がってしまう ので、出来る限り自分たちでできるようにする • 外部に協力を仰いだのは、広報とSEO • これも丸投げではなく自分でできるようになる
- 35. ドッグフーディングできるものを作る • 汎用的な書類作成サービスではなく、「受託ビジネ ス」にフォーカスを当てる • 受託ビジネス特有の業務や数字の見方など、最適され れるので業務にフィットし差別化に繋がる • 自分たちがやっている業務なので、よくわかっている • よくわかっていることであれば、調査やヒアリングの 時間はだいぶ削減できる
- 37. 受託とのバランスの取り方 • 受託案件もboardも大きな山を作らないようにする • 山があると他のことが止まってしまう • 受託の営業・要件定義段階からセットで考える • 常にboardの開発やユーザサポートが毎日タスクとして ある想定で受託案件の受注やスケジューリングをする • 受託案件単体でのスケジュールやリソース管理は行わず、 boardを含めた全体のリソース管理をする
- 38. 開発のペースの確立 • 小規模な開発（1〜2週間）と中規模な開発（1ヶ月）を 平行して進める • 大規模な開発は1年間は手をつけなかった • 小規模開発は、週の前半に開発し、後半にテスト、問題 がなければリリースというサイクル • 細かい開発・テストであればスキマ時間できる • 小規模なものと中規模なものを平行して進めることで、 素早い改善と機能追加のペースを維持
- 39. 開発対象の機能や仕様の決め方 • ロードマップは自分が一貫した軸を持って考える • 原則合議制は取らない • 話し合って決めると、中途半端な結論に落ち着きがちな ので、その業務を知っている者が責任を持って決める • ただし、もちろん迷った時は相談する • テストを担当するメンバーが仕様の詳細や背景を知らないと、 初めて触った時の分かりにくさや違和感に気づきやすく、そ れで修正した仕様はいくつもある • 事前にユーザビリティテストをできない分をここで補う
- 40. 要望対応の判断基準 • 要望はかなりたくさん頂く • 要望に流れさて軸がぶれないようにするため、自分なり の判断基準を作る • 自分自身がその機能を欲しいか（最重要） • 自分が使わない機能の場合、納得感があるか（使わ ない立場として、その必要性を理解できるか） • boardの方向性とあっているか • 業務効率化にプラスにならない独自の習慣に対する要望 はお断りする勇気
- 41. Trelloの運用 • 要望は基本的には全てTrelloに登録して管理する • Trelloのリスト • アイデアの種 • アイデア（低） • アイデア（中） • アイデア（高） • 要件検討中 • 開発準備OK • 次開発予定 • 開発中 • テスト準備OK • ベータ環境テスト中 • ステージング環境テスト中 • リリース準備OK
- 42. 開発ロードマップの公開 • 開発ロードマップを公開している • https://the-board.jp/blogs/roadmap_of_board • 今後の予定がわかるので、ユーザさんにとっても安心材 料になる • 自社サービスは受託と違って納期がないので、モチベー ション管理が難しかった • ロードマップの公開は程よいプレッシャーにある
- 43. 普通はやるであろうことをやらない • メルマガなどのマーケティングメールを出さない • 自分がユーザの立場だったら欲しくないというのもある けど、メルマガを作ることに時間を割けない • ユーザビリティテストをやらない • 本当はやりたいけど、これも時間がないため • 本質的に業務にフィットしたシステムを作ることの方が 使いやすさにとっては重要 • テストを書くのは後回し • 開発初期〜中期の頃はプロトタイプ感覚で、繰り返し、 作っては仕様を変えて作りなおしていたため、テストを 書くのは後回しにして、サービスとしての完成度を上げ ることを優先
- 44. ユーザサポート
- 45. サポート体制 • 今のところ自分が全て回答している • 企画者・開発者が直接ユーザサポートしていると、肌で 反応を感じられ、ニーズや使いにくい点などがリアルに わかる • 問い合わせ内容を定期的に集計する手間も不要だし、 集計した結果では感じられないものなので、結果的 にアウトプットの質が高まる • 自分が回答していることにより、要望に対しての予定や 方針などを即時回答できる
- 46. サポート実績の公開 • 毎月、問い合わせに対する初回回答時間の中央値を公開 している • 8月（直近28日）の中央値は8分 • https://the-board.jp/blogs/result_of_user_supports_201508 • 基本的に困っているから問い合わせてきていると思うの で、在席していればすぐに返すスタンス • かなり好評で、それをきっかけにやり取りが生まれて、 より深い話ができることもある
- 47. まとめ
- 48. まとめ • 受託開発も自社サービスの開発も、山を作らない。全体 のバランスが大事。 • 継続には固定費を下げることが大事なので、最小限の体 制の維持に務める。 • ドッグフーディングはアウトプットのクオリティを高め るだけでなく、そこに行き着くまでのコストも下がる • 答えはないので自分たちにあったスタンスを地道に探求 する
- 49. おまけ
- 50. boardで使っているサービス • AWS：サーバ • Scutum：WAF • intercom：問い合わせ管理 • webpay：決済 • airbrake：エラー通知 • Sendgrid：メール送信 • NewRelic：監視 • TypeForm：アンケート • Trello：要望・開発予定の機能の管理
- 51. enjoy life and creation ご静聴ありがとうございました