受託開発の会社が自社サービスを1年運用してきた内容・結果と今後の課題

boardというサービスを正式リリースしてからちょうど1年が経ちました。

以前、「受託開発の会社が本格的にWebサービスを開発・運用してみてぶつかった課題（只今5ヶ月目）」という記事を書きましたが、その続きというか、現在の状況を書きたいと思います。

boardの開発の始まり

boardは2年前の9月に開発を始めました。
その頃は起業して3年目の後半で、案件の管理や見積書・請求書作成などはExcelでやっており、案件数の増加とともに、Excel管理がだいぶしんどくなってきていました。
そこで、何か請求書作成系のクラウドサービスを使おうと思って探し始めたのですが、案件単位で受注するビジネスモデルにフィットするようなサービスがなく、また支払管理・売上管理・見込み管理など、自分が会社を経営する上で必要な部分まで欲しいレベルでカバーしているものがありませんでした。
ちょうど9月の連休があったので、自分が作りたいものを作ろうと、連休中あまり寝ずに、一気にプロトタイプを作ってみたのがboardの始まりでした。

プロトタイプが意外と良かったこともあり、本格的に開発を進めていくことにしたものの、基本的に受託と平行して進めていたので、2013年12月に社内α版、2014年2月にクローズドβ版、5月にパブリックβ版、8月に正式リリースという形で少しずつ進めていきました。

現在の状況と1年間やってみた感想

まずは、1年間、大きな障害もなく、無停止でサービスを提供できてよかったなと思います。

広告費はかけられないので、基本的にはインバウンドと口コミで知ってもらっているという状況なので、急に大きく伸びることはないですが、毎月安定して新規の有料ユーザが増えていて、なんとか年内か年明け早々には、事業として内部人件費も含め単月黒字化まで行けそうな段階まできました。

エンジニアなのでコード書いて何かシステムを作ること自体はできるけれど、この1年は、作ったものの”事業化”に取り組んだ1年で、本当に色々勉強になったなと思います。

受託をやりながらなので、資金的時間的制約が多い中で、企画・開発・運用・ユーザサポート・マーケティング・プロモーションを一通りトライ&エラーを繰り返して、自分たちにあったスタンスを探し続けたという感じです。

この「自分たちにあった」というのが重要なポイントでした。Webサービス専業の会社や、受託と自社サービスのチームが完全に分かれている会社のやり方と同じ方法をやることは、リソース的になかなか難しいです。
なので、世の中でよく行われていることを真似するのではなく、それらを学びつつ、自分たちにあった方法が必要でした。

そういう中で試行錯誤して辿り着いた開発や運用の進め方などを紹介したいと思います。

開発・テストのペースの確立

当初から現在でも、僕自身がメイン開発者で、もう1名品質管理・テストのメンバーがいるという2名体制が基本で、他のメンバには、受託の合間などに少し手伝ってもらったりしています。

僕ももう1名のメンバも受託の仕事があるので、1ヶ月で割ける時間は1/3〜半分程度。

受託と平行して進める上で、受託でもboardでも、「大きな山を作らない」という点を気をつけています。「大きな山」があると、どうしても他のものが止まってしまいます。そのため、boardの開発は薄く長くというスタンスで、常に受託と平行して存在しているタスクという位置づけで考えています。

ただ、当然ある程度まとまった開発時間が必要なものもありますので、基本的に2軸で開発を進めるようにしています。

boardでは開発ロードマップを公開しているのですが、基本的に、月1回程度のペースで大きめの機能をリリースし、その間に平行して1〜2週間ごとに細かい機能追加や改善を行うという想定で3ヶ月前後のスパンでロードマップを作成しています。

細かい機能追加や改善は、開発自体は1〜2日あれば十分なものが多いので、週の前半に開発し、後半に品質管理のメンバが確認し、確認が終わり次第リリースというサイクルです。
大きめの機能は、一度ざっと実装した段階でもう一人のメンバが確認し、初見で使いにくい点やわかりにくい点があれば指摘してもらって、それを踏まえてきちんと実装し、その後テスト・リリースという流れが多いです。

これらを平行して進めることで、ある程度リリース頻度を保ちつつ、新しい機能を追加していくというペースを作っています。

企画者と開発者が同じなのでコミュニーケーションコストがかからないのは大きいのですが、上記のような薄く長くというペースを確立してからは、安定的に回せるようになりました。

開発予定の管理とメンバ間の共有

開発候補の機能はTrelloで管理・共有しています。要望でもらったものや自分で追加したいと思っているものは全てTrelloに書き出し、優先順位別のリストに入れています。

リストは
・アイデアの種：具体的に考えていない、思いつきレベル。
・アイデア（低）：優先度低め。長期的なスパンでの開発候補。
・アイデア（中）：あると良いが、急ぐ必要がない、またニーズは多くないと思われるもの。
・アイデア（高）：対応する可能性は高いもの。時間ができ次第やりたいもの。
・要件検討中：対応自体は決まっているが、具体的な要件はまだ考え中のもの。
・開発準備OK：対応・要件が決まったもの。
・次開発予定：次に開発する予定のもの。
・開発中：現在開発中のもの。
・テスト準備OK：開発が終わって、テスト担当者がテストする前の段階。
・ベータ環境テスト中：ベータ環境でテスト中の機能。
・ステージング環境テスト中：ステージング環境でテスト中の機能。
・リリース準備OK：テストが完了し、リリースしてOKな機能。
という感じです。
ロードマップに公開しているものは、「要件検討中」以降のものが多いです。また、問い合わせの状況などを踏まえ、わりと頻繁に入れ替えたりしています。

仕様はざっくりTrelloのカードの中に書き、開発が終わったら担当を変えて、「テスト準備OK」に置いておくと、もう一人のメンバがテストし、終わったら「リリース準備OK」に移動する、という感じの流れです。

機能追加の判断基準

これまで多くのご要望を頂いていて、また自分でも追加したい機能もあり、Trelloに上がっている機能候補は数百もあり、全部対応していたらいくら時間があっても足りないですし、boardのコンセプト自体がブレてしまう可能性もあります。

そこで、
・自分自身がその機能を欲しいか（最重要）
・自分が使わない機能の場合、納得感があるか（使わない立場として、その必要性を理解できるか）
・boardの方向性とあっているか
ということを自問自答して優先順位を整理しています。

完全に個人に依存した形ですが、単純に要望の多さだけだとboardのコンセプトがぼけてしまう可能性もありますし、これを何かしらのルール化するのは難しいので、誰かが責任をもって、一貫した感覚で判断すべきと考えています。

幸い、自分自身がboardのメインターゲットとなるユーザなので、その感覚を大事にしつつ、「自分仕様」になりすぎないように気をつけています。

ユーザからの要望はものすごく大事ですが、ユーザが答えを持っているわけでもないですし、全体のバランスも重要なので、自分の中で「要望に流されない軸」が必要です。
初期の頃はこの基準がなく、要望に対してどう向き合ったら良いのかがわからず、かなり気苦労が絶えませんでしたが、自分の中でこの基準がしっかりできてからは、非常に楽になりました。

“使いやすさ"に対する考え

UIの使いやすさは非常に大事だと思っていて、自分なりに色々と勉強しつつ、かなり意識して取り組んでいます。ありがたいことに、「使いやすい」と言って頂けることが多いです。
ただ、業務システムの場合、本質的な使いやすさは、UI以前に業務にどれだけフィットしているか、という点が最も重要だと考えています。

実は、現状、ユーザビリティテストのようなものはやっていません。もちろんやりたいのですが、そこまでリソースを割けないということもあり、「業務とのフィット感なしに、UIだけを頑張っても使いやすいシステムにはならない」という考えから、まずは「業務とのフィット感」という点に集中しています。

限られたリソースの中でやるための選択と集中です。

そういう点では、実際に業務や経営をやっている僕自身が企画・開発にがっつり入っているということはひとつの強みだと思ってます。

ユーザビリティテストができない分は、開発者自身が問い合わせ対応することでユーザがわかりにくそうにしている点を肌で感じることを大事にしています。

ユーザサポートのスタンスと実績の公開

ユーザサポートは、boardの特徴的なもののひとつかもしれないです。

今のところ、ユーザからの問い合わせは基本的に全て僕が回答しています。

要望をもらって、「ありがとうございます。検討します」という一次回答だと味気ないというか、定型的な返信でよくないなと思っていまして、わりと突っ込んだコミュニーケーションを取るようにしています。

また、企画者や開発者が直接問い合わせ対応をするというのは非常にメリットがあると思います。

要望を頂いた時に、その背景や理由などを一緒に聞くことで、それの重要性・汎用性などを把握して、今後の計画のどこに入れるかという点をその場で検討しています。要望を頂いた時は、ユーザのニーズを把握できる一番のチャンスなので、企画者自身がそこに入ることは非常に重要だと思います。そして、すぐにその場でTrelloに登録しています。

開発者としては、どういう質問が多いのか、特に使い方がわからないという問い合わせはユーザビリティや仕様に問題がある可能性もあり、それをリアルタイムに肌で感じることで、すぐに日々の開発に反映することができます。

また、可能な限り即レスしています。
一次回答までの時間を公開しているのですが、打ち合わせに入っていなければ、15分程度では返信していることになります。

「15分」という数字はよく驚かれるのですが、これは単純に、逆の立場だったらわかると思うのですが、何かに困っているから問い合わせをしていると思うんです。それが半日・1日と待たされてしまうと、業務が止まってしまいますし、本当に急いでいる時は困ってしまいます。
そのため、体制的に即レスを保証はできませんが、打ち合わせ中や移動中でない限り、問い合わせが来たらすぐに答えるようにしています。

個人的には、普段の受託の仕事でお客さんとやり取りしている時も同じようなペースで返信しているので、その延長という感じです。受託の場合、自分が返信せずにボールを持ったままにしてしまうと、全体の進捗が止まってしまいますからね。それと同じだと思っています。

開発ロードマップの公開

これもよく驚かれることなのですが、開発ロードマップを公開しています。

元々は、β版の頃によく要望をくれたユーザさんからの意見だったのですが、実際公開してみると、ユーザの方々にとっては今後の予定が見えるのでプラスになると思いますし、僕としてもある程度開発のプレッシャーになるのでちょうど良いです。

受託をやっていると「納期」があるわけですが、それがない自社サービスは意外とモチベーション管理が難しかったので、ロードマップの公開はそういう意味でもプラスでした。

「競合に見られてしまうのでは？」と言われることもあるのですが、別にロードマップを見られたからといって同じ機能ができるわけでもないですし、たぶんそれほどベンチマークされる対象にもなっていないと思いますし。それよりもユーザさんに対するメリットの方が大きいかなと。

ちなみに、ロードマップについては「自社サービスの開発ロードマップを公開してみて感じたこと」に詳しく書いています。

マーケティング・プロモーションにおけるスタンス

知名度が高くない会社がやっているサービスの場合、やはりここが一番課題です。

リリース時こそいくつかのメディアに取り上げて頂きましたが、それ以降はなかなか難しく、そもそもメディアの方々からはboard自体を認識されていないだろうなという感じです。

なので、最近は「メディアに取り上げて頂いて露出が増える」というのはわりと諦めていて、地道に行こうというスタンスです。
＊もちろん取り上げて頂けるのは大歓迎です！

また、広告をどんどん出して集客するのは資金的に難しい。

なので、地道に、コンテンツマーケティングやSEOを頑張ってインバウンドを増やすのと、ありがたいことに、boardを使って頂いている方が結構薦めてくれていて、口コミもかなり多いようです。

そんな感じなのでスローな成長になりますが、堅調には伸びているし、今は無理して何か露出を増やすというよりは、今まで通り、しっかり地に足をつけて、いいものを作くというスタンスでいいのかなと思っています。

こんな感じで1年運用して、なんとか軌道に乗ったものの、まだまだいくつも課題があります。

開発体制強化

受託とのバランスを見つつ、さすがにもう少し開発体制を強化していきたいなと考えています。

基本的に受託を削って自社サービスにリソースを割く、ということはやってきていなくて、あくまでも受託での売上はきちんと達成しつつ、その空いた時間で自社サービスをやるというスタンスでいます。
そのために、数年のスパンで、メンバの育成だったりチームビルディングをしてきた結果として、今期、僕の受託の割合をぐっと減らすことができ、boardに時間を割くことができました。

このスタンスはたまに迷います。やはり、どこかでアクセルを踏んで、boardの開発を加速させるべきではないのかと。

ただ、単に機能をどんどん追加していくことがユーザにとってプラスになるというほど単純ではないと思ってもいます。リソースがあると無駄なものを作ってしまいがちですし。

なので、今のように、徹底的に吟味し、最小限のリソースで無駄なものを作らないことを維持するのも大事だなと。

そのため、開発メンバを増やすことで、単純にその分開発量を増やすというよりは、僕がもう少しマーケティング寄りの仕事ができるようになったりするといいかなと思っています。