受託開発しながら自社サービスを作る時に工夫したこと ## はじめに クレイはWebシステムやスマートフォンアプリなどの依頼を受けて開発をする受託開発を事業の柱としています。新事業として、[DocBase](https://docbase.io)という情報共有サービスを開発、運営しています。 自社サービスやスマートフォンアプリの開発に何度も挑戦し、失敗と改善を繰り返しながら工夫したことをご紹介したいと思います。 ![a629b39d-307a-4dba-8128-2d133ecc762d-e1445216958902.jpg](https://image.docbase.io/uploads/172906a2-8a58-4fdf-9f60-06df33bca53f.jpg =WxH) ## これまで開発した自社サービスやスマートフォンアプリ 「受託開発会社が自社サービスに挑戦する」というのはよくある話ですが、弊社もこの8年間、様々な自社サービスに挑戦してきました。 公開せずに開発途中で断念したものを含めると、全部で11プロジェクトあったようです。 - iPhoneアプリ x 4（公開 3） - Webサービス x 7（公開 4） iPhoneアプリの総ダウンロード数は318,000、総売上は19,460ドルでした。 Webサービスは次のように寂しい感じですが少しずつ成長が見られます。 | サービス名 | 総ユーザー数 | アクティブユーザー数 | コンテンツ数 | |----|----|----|----| | Tripclip | 213 | ？ | 314 | | SORTIE | 636 | ？ | 1142 | | DocBase | 3,000 | 1,000 | 41,000 | ※ _アクティブユーザー数は2015年10月現在_ [DocBase](https://docbase.io)は2015年7月に正式リリースしていますが、無料のサービスであるTripclipやSORTIEに比べて、有料のサービスであるDocBaseが短い期間で一番成長できているということは、自分たちのサービス開発が改善できていると言えるのではないかと思います。（正直、公開するのを躊躇うような数字でしたが、改善されていることがわかりやすいので公開しました。） もちろんユーザー数、売上など誇れるような数字ではないのですが、お金を払って継続して使っていただけるお客様がいるのは、本当に嬉しくて、一社一社お礼を言いに行きたいぐらいです。 サポートにもほぼ毎日要望をいただいていて、プロダクトオーナーである私が全て返信しています。 ## これまでの失敗から学び、工夫したこと - 自分たちにとって必須となるものを作る - 開発メンバーと利用メンバーを分ける - 作る前に探り、仮説を立てる - 実際に触れるものを小さく作る - 段階的に公開する - 作る前も作った後も、何度もインタビュー ### 自分たちにとって必須となるものを作る サービス開発ではターゲットは誰か、サービスに価値はあるのか、追加しようとしている機能は必要なのか、迷うことは山ほどあります。少しでも正しい判断するためにインタビューやデータ分析が必要です。 スタートアップではない弊社のような小さな会社では、自社サービスだけに集中もできないため、全くリソースが足りません。そのため、**価値があるかどうかの判断をなるべく自分たちができること**が必要と考えました。（だからといってユーザーヒアリングが必要ないわけではなく、絶対必要だと思ってます。） DocBase以前に作っていたサービスは社内の誰かが欲しいと思って作ったサービスやアプリばかりですが、自分たちが毎日使うようなサービスではありません。DocBaseはクレイ社内で1年間ずっと使いながら改善を続けて、正に自分たちにとって必須となったサービスです。 ### 開発メンバーと利用メンバーを分ける 開発当初、弊社7人の内、エンジニア3人、プロダクトオーナー1人の4人で開発を開始し、残り3人は開発に関わらず、利用するだけとしました。 開発メンバーは受託開発の合間の空いた時間に[DocBase](https://docbase.io/?utm_source=kray.jp&utm_medium=blog&utm_campaign=workout-product-plans)の開発を行っています。開発スピードだけを考えれば、全員参加して、空いた時間を全て自社サービス開発に充てた方がいいのですが、自分たち自身がターゲットであることから、分けることで冷静な意見を聞けたと思います。 ### 作る前に探り、仮説を立てる 本格的に作り出す前に、社内の利用メンバーそれぞれに技術情報の「保存」と「共有」を**なぜ**、**誰に**、**いつ**、**どのように**行っているかインタビューを行いました。それぞれまとめていき、特に**なぜ**を洗い出すようにしています。 ![393e838d-5b1a-473e-9e42-fc523f6425da-668x501.jpg](https://image.docbase.io/uploads/2f0ebdfb-c847-464f-8aec-195e1f410a32.jpg =WxH) ### 実際に触れるものを小さく作る 所謂MVP（実用最小限の製品）ですが、デザインや動画を作ったり、顧客調査を行ったり、様々な形があるかと思います。弊社ではプロトタイプを作るという、比較的コストがかかるMVPとしました。これは開発会社なので、実際に作ってしまうのがコストが低く判断しやすいという結論に至ったからです。（企画の段階で画像のみのものは作っています） #### 実際に作ったMVP MVPに比べると、現在はかなり変わっています。この段階ではデザイナーに入ってもらっていません。 ![b5d0feca-84c4-4b7b-81c0-19f20aee062d.png](https://image.docbase.io/uploads/bd807dbc-0531-470a-8d5b-b4b2f4d78046.png =WxH) ### 段階的に公開する [DocBase](https://docbase.io/?utm_source=kray.jp&utm_medium=blog&utm_campaign=workout-product-plans)は2014年3月から7月まで社内のみ、2014年8月から12月まで10社程度に使っていただきました。段階的に公開することで必須となる機能を絞り込んでいけました。 #### 社内のみで公開 - 実際に自分たちで使えるのか、役に立つかが肌で感じられる - アイデアをすぐ盛り込める - ダメならサービス自体もアイデアもすぐやめられる - 価値のある機能以外は作らなくていい 最初に社内に公開したバージョンは開発者3人で３日程度で作りました。その後も空いた時間に小さく開発をしながら、社内で公開しています。 #### 社外10社ぐらいに限定公開 - 社外に公開することで自分たち以外にも役に立つかが判断しやすい - 実験的な機能を盛り込みやすい - 完璧を目指さなくてもいい 弊社のように受託開発をしている企業ですと、「質の低いものを出すと発注が減るのでは」という意識が働いて、完璧なものしか出したくないと考えてしまいます。小さく限定公開とすることで、完璧を目指さなくていいのは良かったです。 限定公開の頃はリリース情報をevernoteの共有機能を使って出していました。以下は実際に社内メンバー向けに出したリリースです。 ![スクリーンショット 2025-03-13 17.54.47.png](https://image.docbase.io/uploads/4a99fec4-b675-4cd9-82e0-7bd0ce9c21ec.png =486x374) ### 作る前も作った後も、何度もインタビュー 作る前、限定公開、オープンβ、リリース後、それぞれの段階で5社ぐらいずつインタビューを行っています。インタビューでは質問を投げるのではなく、なるべく**体験を聞く**ことを心がけています。 段階によってインタビュー内容は変わるのですが、次のようなことを学びたいと思ってインタビューを行っています。 - DocBaseを導入前のチームや組織内での情報の保存と共有 - コンセプトや価値の理解 - 導入のきっかけや導入時の障害 - 感じている価値 - 期待とのズレ 実際に使ってくれているお客様と話すのは大変勉強になりますし、インタビューする度に発見があります。 ## 受託開発と自社サービス開発の相乗効果 受託開発と自社サービス開発は異なる点が多く、並行して進めていくのはとても難しいのですが、片方で得た知見をもう片方に応用していくことで、より良い開発ができると考えています。 ### 受託開発で得たものを自社サービス開発へ 受託開発ではターゲットや要件、技術に関して様々な案件があるため、技術領域も視野も広がりやすいです。また別の文化を持つ人たちと一緒にチームを組んで開発していくのは刺激になります。 また弊社では[受託開発にアジャイルは適用できるか？](https://kray.jp/blog/agile_entrusted_dev/)の記事のように受託開発でもアジャイル開発を進めています。案件ごとにお客様と創意工夫しながら、そのチームに合った開発をしていくことで、自社だけではできなかった工夫を生み出せると思います。 このように受託開発で開発力を強化して自社サービス開発を改善していくことができます。 ### 自社サービス開発で得たものを受託開発へ 自社サービスの開発では、どのように作るのかではなく、**なぜ作るのか、誰のために作るのか**という、実際に開発する前の部分を鍛えることができると考えています。 受託開発では**どのように作るのか**に意識が集中しがちです。自らサービスを開発することで、発注主であるお客様のためでもあり、その先の使う人のために開発していることを常に意識できるようになれるのではないかと思います。 ## 課題 - 受託開発が忙しくなると開発が進まなくなる - 開発バカなのでプロモーションができない - 仮説検証が満足にできていない - お客様からいただく要望の取捨選択にとても悩む 課題については、今後改善していかなければいけません。 次のブログなどは大変参考になります。 - [受託開発の会社が本格的にWebサービスを開発・運用してみてぶつかった課題（只今5ヶ月目）](https://blog.velc.jp/post/100993948274/web-5) - [受託開発を軸にしながら自社開発を継続するために行っている工夫（時間・お金の話など）](https://blog.velc.jp/post/87770884089/%E5%8F%97%E8%A8%97%E9%96%8B%E7%99%BA%E3%82%92%E8%BB%B8%E3%81%AB%E3%81%97%E3%81%AA%E3%81%8C%E3%82%89%E8%87%AA%E7%A4%BE%E9%96%8B%E7%99%BA%E3%82%92%E7%B6%99%E7%B6%9A%E3%81%99%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AB%E8%A1%8C%E3%81%A3%E3%81%A6%E3%81%84%E3%82%8B%E5%B7%A5%E5%A4%AB%E6%99%82%E9%96%93%E3%81%8A%E9%87%91%E3%81%AE%E8%A9%B1%E3%81%AA%E3%81%A9) ## 最後に 弊社のミッションは**開発に関わる全てのチームの力を強化する**です。今回の記事が、開発に関わる組織やサービスを作っているチームにとって、少しでも参考になればと思っています。そして「うちはこんな風に工夫しているよ」という情報がまた出てくればなと思ってます。