受託開発の会社が自社サービスに取り組むにあたっての課題

弊社の場合、私自身を含め、ずっと受託開発をやってきたメンバーだったため、自社サービスを開発・運営していく上でいくつか課題がありました。

1.受託開発の場合、基本的にお客さまが企画や要件を決めるため、自分たちでゼロから企画を考え、要件を決めていくという経験がなかった

2.受託開発の場合、作ったシステムのマーケティングを自分たちでやることはありません。マーケティング・PRなどの分野は全く未経験だった

3.基本的には受託開発をメインでやっているため、受託が忙しくなると、どうしても自社サービスの開発が止まってしまった

その他細かい課題はいくつもありますが、大きく上記のような課題がありました。

受託開発をしながら自社サービスを開発する上で取り組んだ「10のこと」

前述のような課題がある状態から、サービスを立ち上げ、事業として軌道に乗せるまでに取り組んだ「10のこと」を紹介したいと思います。 今回は概要編で、次回以降、それぞれ細かい話を書いていきたいと思います。

1. ブレスト・企画

受託開発の仕事では、ゼロから企画を考えたり、ブレストでアイデアを出し合ったりするという経験がほとんどありません。そのため「アイデアを出す」ということが苦手でした。

そこで「1つテーマを決めて1時間のうちに100個アイデアを出す」という”トレーニング”を何度も行い、アイデアの良い・悪いではなく、「アイデアを口にだすこと」に慣れる取り組みをしました。

2. プロトタイプ

リーンスタートアップが流行った後だったということもあり、できるだけ手間をかけず検証すべく、3日程度でプロトタイプを作り、コンセプトが間違っていないかなどの確認を行いました。

プロトタイプを作って検証するというのも受託であまりないやり方ですね。 ペーパープロトタイプなのか、実際に動くものなのか。そして、どこまで作るべきか、ということが非常に大事でした。

3. ドッグフーディング

自社サービスの経験値が少ない状態で、自分が関係ない分野のサービスを成功させることは非常にハードルが高いと思います。

ドッグフーディング（開発したサービスを開発者自身がユーザとして日常的に使うこと）できることであれば、自分たちでニーズを把握できたり、使い勝手を検証できたりします。そのため「ドッグフーディングできること」に限定して進めることにしました。

boardの場合、自分自身の課題（業務や経営の効率化）を解決するために開発をスタートし、「受託ビジネス（=案件単位で仕事を受けるもの）」にターゲットを絞っています。

4. 段階的な公開

boardは、社内α版→クローズドβ版→パブリックβ版→正式リリースという形で、2〜3ヶ月程度のスパンで1つずつ進んでいきました。

これはうちにとっては非常に効果的でした。

自社サービスを公開するということに慣れていなかったので、段階的に公開することで少しずつ運用の経験ができたり、ユーザからの問い合わせの対応に慣れていくことができました。

5. マーケティング・PR・SEO

現在でも相変わらず課題ですが、受託をやっていた会社にとって未知の分野で、かつ弊社のような知名度が高くない会社だとかなり苦労します。

弊社の場合「受託で稼いだお金を自社サービスの開発に回す」というスタンスのため、広告に大量の資金を投入するようなことはできず、また知名度がない会社だとメディアにも取り上げられにくく、一気にサービスが認知されるということはかなり難しいです。

そのため、大きな打ち上げ花火を狙うのではなく、持続可能なコストやリソースのかけ方で、自分たちにあったマーケティング・PRの方法を模索しています。

また、検索からの流入は、ある程度安定した新規獲得につながるので、当初から力を入れてきました。基本的にはコンテンツマーケティングを中心に取り組んでいます。

エンジニア集団が取り組んだデジタルマーケティングは、1つひとつながらも着実な改善を重ねることで、少なくないインバウンドの獲得までいたりました。

6. 受託と自社サービスのバランス

当初はかなり苦労しました。

収益としては受託に依存しているため、どうしても受託が忙しくなると、自社サービスの開発がスピードダウンしてしまいます。

「自社サービスを軌道に乗せる」という覚悟のもと、継続可能なリソース配分で「まずは自社サービスのリソースを確保」し、それ前提で受託の営業やスケジューリングをするようにしてからは、安定してバランスを保つことができるようになりました。 このバランスの保ち方は多くの受託会社さんにとって参考になるのではと思います。

7. 要望対応の整理方法と判断基準の確立

要望対応の判断基準は、受託と180度違うため、最初はかなり苦労しました。

受託開発の場合、お客さんの要望を実装することになるケースがほとんどですが、クラウドサービスでそのスタンスでやることはできません。

そこで、現在では下記の点を自問自答して優先順位を整理しています。

・自分自身がその機能を欲しいか（最重要）
・自分が使わない機能の場合、納得感があるか（使わない立場として、その必要性を理解できるか）
・自社サービス（board）の方向性とあっているか

また、要望の整理にはTrelloを使っていますが、詳しくは連載の第7弾くらいのタイミングで書きたいと思います。

8. 開発ロードマップの公開

boardでは、正式リリースした頃から開発予定をブログで公開するようになり、2015年の頭から、正式に開発ロードマップとして公開しています。

ロードマップの公開はあまり一般的ではないですし、「競合に見られるのでは？」とよく聞かれるのですが、競合に見られるほどまだ広まってはいなかったですし、それよりもユーザさんへのメリットが大きいと考えていました。

実際ロードマップを公開していて、その姿勢を評価して使ってくれる方などもいてかなり好評でした。 第8弾では、メリットと改善点についてお伝えします。

9. 開発者自身によるユーザサポート＆即レス対応

ユーザサポートは全て私自身が回答していますが、企画者・開発者自身が直接ユーザサポートをすると、ユーザがどのような点で困っているのか、何がわかりにくいのかなど、肌で感じることができて非常に良いです。

また、基本的に打ち合わせに入っている時以外は即レスするようにしていて、また一次回答までの時間を公開（12月は6分！）するなど、オープンなスタンスで取り組んでいます。

規模的に、コールセンターを整備したり、専属のサポートメンバーを置くようなことはできませんが、自分たちなりにできることで、ユーザサポートのクオリティを上げるようにしています。 チャットはIntercom.ioを使っていまして、こちらもこの記事のタイミングあたりでご紹介したいと思います。

10. 無駄なものを作らない

無駄なものを作らないというのは、当然そうしたいのですが、非常に難しいものでもあると思います。

今現在でも、受託と並行してboardの開発を進めているということもあり、開発リソースがかなり限られています。

そのため、無駄なものを作らないための工夫として、「○○の機能を作るのにどれだけ時間が必要」というスタンスではなく、「この時間で何ができるか」という視点で考えることで、できるだけ開発する機能を削り、余計なものを作ってしまわないように務めています。

数多くのチャレンジの中で失敗もたくさんありました。今回ご紹介した「10のこと」はそのチャレンジの中でも「受託の会社が取り組むことができ、かつ効果的だったこと」と考えているものです。

今回、概要からご紹介させていただきましたが、次回以降からそれぞれの項目を深掘りして書いていきたいと思います。 自社サービスの開発から軌道にのるまで、すべてを洗いざらいお話します。ひとつでも多くの企業さんにとってヒントになれば幸いです。