ヴェルク - IT起業の記録

ブログ移転しました。

http://tamukai.blog.velc.jp/

11月に無事に6期目が終わりました。

ブログを見返してみると、この1年で2本しか書いてなかった。「最近全然ブログ書いてないですね」ってよく言われるわけです・・・。

この1年は、boardの存在がどんどん大きくなってきたり、初めて1年で2名採用したり、税務調査があったり、貸倒引当金の出番があったり、そんな1年を振り返りたいと思います。

board

boardは今年の8月で正式リリースから2年が経ち、おかげさまで11月末時点の有償導入社数が530社まで増えました。有償継続率も99%超を維持し、事業単体では単月黒字化もしましたし、成長スピードは速くはないですが毎月安定してアカウントが増加するなど、とりあえず軌道には乗ったという感じです。

1年前の5期終了時のブログを見ていると、まだまだ運営に手探り感がすごくあるのですが、この1年は、実はあまりそういう感じはなく、これまでやってきたことを堅実に行い、相変わらずこまめにリリースを続けてきました。

たぶん今年1年ブログを書いていないのも、あまり新しいことをやらず、昨年までにやってきたことをしっかりやって、土台を作っていたため、書くようなネタがなかったからかな、という言い訳です。

開発の内容自体は、昨年に比べて今年の方が大きめの機能開発が多く、これは、よく問い合わせを頂くような内容はある程度カバーできてきており、要望が分散するようになってきたため、まとまった時間が必要な大きめの機能開発に着手するようになったという感じです。（昨年は、大きめの開発は後回しにして、既存機能の改善・充実を優先していた）

開発は相変わらずほとんど1人でしたが、今年後半からようやく1人アサインして、大きめの機能を開発してもらっています。1人開発チームはそろそろ卒業できそうです。 サポートも結局まだ1人で、こちらの方が大きな課題ですね。boardはシステムの特性上、月末月初にアクセスも増え、問い合わせも集中します。そのため、月末月初は、ほぼ1日中問い合わせ対応をしていて、自社の月末業務が遅れがちです・・・。

サポートは、単にマニュアル化された対応をすれば良いというわけではないと考えています。 うまく活用してもらえるようなカスタマーサクセスの視点は不可欠ですし、うちとしても、ユーザさんから見たらboardの印象そのものになるので極めて重要だと考えています。特にうちのように小さい無名の会社だと、ユーザさんとの唯一の接点であるサポートのクオリティを落とすわけにはいきません。 そのため、サポートの対応は、ユーザさんのboardの活用度合い・業務効率化にも影響しますし、boardのマーケティングやブランディングそのものですし、問い合わせの大半は、お試し期間中の30日間に集中することを考えると、セールスでもあるわけです。

ちなみに、サポートメンバーは絶賛募集中なので、少しでも興味がある方がいらっしゃいましたら、「とりあえず話を聞いてみたい」でも大丈夫ですので、ぜひぜひご連絡ください！！

プロモーション・集客という点では最初から今でもずっと頭を悩ませていて、結局答えが見つからないままです。リスティングやFacebook広告などもやってみたのですが、費用対効果が非常に悪く、成長スピードを上げるためにアクセルを踏みたいけど踏めない、という状況が続いていますね。 今のように、早くはないけど着実に成長している方が、うちに合っているのかなという気もしてきましたw

来年は、兎にも角にも、CS体制の強化ですね。倍の問い合わせ数になったら、どうやっても1人で捌ききれない・・・。

受託体制の変化

昨年、自分が受託の「開発」から抜けるという取り組みをしていて、現在は「自分が受託そのものから抜ける」ことに取り組んでいます。

受託自体は好きですしやめたい訳ではないのですが、さすがに手が回らないのと、他のメンバーの成長を促す意味でも、一旦受託は他のメンバーに任せようと。特にここ数ヶ月は、営業に関わる機会も減らしています。

これはそこそこリスクのある取り組みで、営業の口が1つ減ること、プロジェクトを回す人が1人減ることになります。 幸いにも、boardやPattoなどの自社サービスとその他諸々で、月額で入ってくる売上が、必要な売上の約1/3まで増えてきたため、ある程度リスクを取ることができる環境になってきたので、思い切ってその方向に舵を切りました。

何年も前から徐々に準備をしてきたので、案件を回す方はあまり問題はないかなと思っていますが、営業面の方が未知数ですね。

その結果どうなったかは1年後の7期まとめブログで。

採用における受託と自社サービスの違い

これは、経営者として自分が完全に受託寄りなので抱えている問題ですが、受託の採用と自社サービスの採用の違いを最近感じています。

受託の採用は、仕事さえ取れれば、ある程度人数に比例して売上を上げられます。一人採用してから売上が立つ期間が短いので計算しやすいです。 しかしサービスの採用は、一人増えたからと言って売上が増えるわけではありません。とあるクラウドサービスをやっている知り合いが、「人数増えても売上はそんなに急に増えないから！」って言っていたのが印象的です。

そのため、一人採用することのインパクトが、受託よりも大きいんだなということに最近気づきました。 資金調達せずに自己資金でやっていると、ここが厳しいですね。採用において先行投資がしづらい。

受託と自社サービスの関係

自分のキャリアは、基本的には受託・SI・コンサル系なのですが、この経験は、サービス開発・運営に本当に役にやっているなと。

自分の考え方の根底や手に染み付いているのは受託で身につけたもので、逆にサービス開発・運営はゼロだったわけです。

そのため、boardの開発・運営をする上でやっていることは、背景には受託の経験があります。

例えば、 ・即レスチャットサポートで好評を頂きましたが、元々受託でもメールが来たらすぐに返してたのでその延長だった ・設計思想やシステムの完成度を評価してもらいましたが、ずっと業務系システムをやってきた者としてはいつも通りだった ・サポートで必要な、問い合わせ内容の行間や背景を読む力や異なる業種の業務を理解する力は、要件定義でのヒアリングで培ったもの などなど。

もちろん、マーケティング・プロモーションなどは全然経験なく、これは依然として課題として残っていますが、受託系ベンチャーとしての強みは、サービスの開発・運営においても十分活かせるんだなと思いました。

あと、最近自分の中でホットなもので、社会人2年目の時に、連結会計のデータ連携部分の仕様を決める仕事をしていました。超大企業のグループ会社を回って、経理の人からヒアリングして、各社の会計データを洗いざらい調べて、連結会計システムへの連携仕様を決めていく。1年半、ほとんど技術から離れて。

でもそれが今、boardから会計システムへのデータ出力機能でものすごく役に立ってたり、経理の人と話がスムーズにできたり。 どこで何が役に立つのかほんとにわからないので、しっかり十分なレベルでできるようになっておくことを積み重ねるって大事だなと。

初・税務調査

今年、初めての税務調査がありました。

基本的にはきれいにやっているので全然問題ないのですが、どういう感じで進むのかドキドキでした。

しかも、ここ数年で一番というレベルで忙しい時に重なったため、事情を説明したところ、3ヶ月ほど待ってくれました。優しい。

2日間の日程で、1日目の最初だけ自分も立ち会い、後は、税務署の方と税理士さんのみ。立ち会ったといっても、15分程度、経歴やビジネスについてなど聞かれた程度で、あとは仕事に戻ってOKでした。

ちなみに、税務調査とは関係ないですが、税務署の人はメールアドレスを持っていないらしいです。セキュリティ上、インターネットが繋がるPCを使っていないそうです。

オフィス移転を決める

来年1月にオフィスを移転します。また市ヶ谷ですが、2.5倍くらいの広さで、会議室付き。

今が格安物件ということもあり、家賃が3倍になるという・・・。

いくつか理由はあるのですが、 ・boardの個別相談会で来て頂くことも多いので、話しやすいよう、区切られた会議室が欲しかった ・小さいオフィスだと、フリースペースが作りにくく、開発が行き詰まった時などに気分を変えにくいので、スペースに余裕が欲しかった など、環境面の改善が主な目的ですね。

おまけ

だいぶ久しぶりのブログかつ、久しぶりにboardネタではないエントリです。

少し前に、顧問弁護士をお願いしているGVAさんに依頼して、社内用の法務マニュアルというものを作成して頂きました。

この取り組みがなかなか良かったので紹介したいと思います。

日々の仕事の中で、法務的なリスクというのはたくさんあると思うのですが、自分自身含め、社員全員が法務的な知識を十分に正しく持っているということはなかなか大変だと思います。

ただ、知らなかったでは済まない問題でも多くあります。

例えば、ソフトウェアのライセンスや画像の著作権などは、日々の仕事に直結する身近な法務リスクです。

そこで、予防法務の一環として、受託開発における契約や瑕疵担保、ソフトウェアの著作権やOSS、ブログや資料における画像利用など、うちの会社の業務に関係する法務トピックで重要なものをピックアップし、それに対して解説を書いてもらいました。

「うちの会社」を想定して書いてもらったため、「自分ごと」の内容になっています。

自分自身、全く知らなかったといものはありませんでしたが、理解が曖昧だったものがクリアになりましたし、迷った時はいつでも参照できます。

また他のメンバーにとっては、知らなかったこともあるでしょうし、そういうことを知る・意識するきっかけになったのではないかなと思います。

もちろんこれだけで全ての法務リスクを防げるわけではないですが、内容を自分たちの業務に合わせることで、かなり「自分ごと」になりますし、「そういうリスクがあるんだ」ということを知っておき、いつでも確認できる状態にしておくことが、予防法務の第一歩になるのではないかなと思うので、オススメです。

boardをリリースしてから約1年半、問い合わせは全て自分で対応してきました。

基本的には在席していれば即レスするようにしていて、初回回答時間の中央値を公開しています。（12月は6分！）

この即レス対応はユーザの方からはかなり好評で、また自分にとっても非常にメリットがありましたので、この取り組みで気をつけていることやそのメリットを紹介したいと思います。

なお、問い合わせの仕組みは、intercom.ioというサービスを使っています。 intercomは、問い合わせフォームというよりは、チャットをイメージして頂いた方が近いです。

まずは気をつけていること・取り組んでいることから。

安易な一次回答はしない

数字の力は強いですよね。

「初回回答時間○分」という数字を公開していると、この数字のために動いたり、これを少しでも短くしようという心理が働いてしまいがちです。 ユーザサポートの結果であるべきなのに、それが目的化してしまうというか。

例えば、一次回答として、「確認します」や「お問い合わせありがとうございます。」などの一言をすぐに返してしまいがちです。

もちろん、「お問い合わせ拝見しました」ということは伝わるのでそれはそれでメリットがあると思いますが、「初回回答○分」と公開している以上、上記のような一言は初回回答とは言わないですし、実態とずれている数字を公開してアピールするのは個人的にすごく嫌いだったりします。 ＊公開している初回回答の時間は問い合わせ管理で使っているintercom.ioというサービスで計測してくれるのですが、最初に回答したものまでの時間なので、一言でも返せば初回回答になってしまうため。

そのため、「質問に対しては、初回の回答の1回で済むことを目指して、スクリーンショットなどをつけて丁寧に回答する」ようにしています。

問い合わせの返信は画面上に表示されるので、ユーザさんにとっても、一回で回答が返ってきた方が業務の邪魔にならないと思いますし。

もちろん全てがそうなりませんが、過去のやり取りを振り返ると、 質問→回答→「わかりました。ありがとうございます。」 と3回のやり取りで終わるパターンが多く、問い合わせ対応としても手離れがよく、すぐに他の仕事に戻れます。

掛け持ちでサポートをやっている場合、手離れの良さは非常に重要なポイントだと思います。

ちなみに、操作を文字で説明するは難しいことが多いので、データが整っているデモアカウントは常に用意しておき、スクリーンショットを撮って、そこにコメントを入れて、それを説明とともに送る、ということをよくやっています。 

打ち合わせ中や移動中は回答しない

一人でユーザサポートをやっていると、当然回答できないタイミングがあります。

私の場合、board以外にも、受託の営業やプロマネなどの仕事もしているため、半分以上はboard以外の仕事をしています。 例えば、社内で打ち合わせしている時や移動中などは、何かクリティカルな障害でもなければ、基本的に対応しないようにしています。

これは、「継続可能なペースでやる」というポリシーのもと、このようにしています。 無理してやると続けるのがきつくなりますからね。

ヘルプやFAQを充実させる 

リリース当初はヘルプすらなかったのですが、可能な限り細かい機能を含め整備し、また問い合わせがあったものを随時FAQに反映していくなど、ヘルプ・FAQを充実させる取り組みをしてきました。（現在ヘルプ・FAQで200記事を超えてました）

そして、お問い合わせの回答の際、「簡単な説明＋詳しくはヘルプをご覧ください」という形で回答するようにしてします。

ヘルプは、スクリーンショット付きで丁寧に解説しているので、そちらの方がわかりやすいためそのようにしているのですが、ヘルプの存在に気づいていない方もいるため、毎回そのように回答していたら、「ヘルプを見たけどなかったので質問させてください」みたいな形で、ヘルプを見てから問い合わせしてくれる方がかなり増えた印象です。

実際、アカウント数・アクティブユーザ数・PV数も増え続けているのですが、問い合わせ件数は、直近3ヶ月はピーク時から半分程度になりました。

要望はその背景をヒアリングする 

多くのご要望を頂くのですが、弊社では発生しない業務で詳しくわからない場合や、こちらが全く想定していなかったような要望、背景にある業務が見えないような要望を頂くことも多くあります。

もちろんすべてを対応することはできませんが、わからないものは詳しくヒアリングしてその要望の背景にある業務を理解するように務めています。その結果、必要性を理解して実装することにしたものもあります。 また、実装するタイミングで、再度こちらから連絡して、詳しく確認するケースもあります。

こうすることで、弊社ではやっていない業務でも、実態とかけ離れた使い勝手になってしまわないように気をつけています。

次にメリットです。

ユーザとの距離感が縮まる（気がする） 

こちらの勝手な思い込みかもしれませんが・・・。

即レス対応していると、ユーザさんとの距離感が縮まる気がします。

面識がない人でも、気軽に問い合わせしてくれたり、意見を言ってくれたり、要望に対してディスカッションしたりしています。

これは、本当にありがたいことだなあと思います。

ユーザの反応を肌で感じることができる 

サービス開発において、非常に重要な点だと思います。

例えばサポート専任メンバーがいる場合、開発者自身は1つ1つのやり取りを見ることは少なく、定期的にサポートメンバーから共有してもらうなどで、ユーザの声や反応を把握していることが多いのではないでしょうか。

もちろんそれでもある程度は把握できると思いますが、実際に問い合わせに対応していると、肌感覚や微妙な変化を感じることができます。

その微妙な変化にはかなり注意を払っています。 例えば、問い合わせ内容の微妙な変化はユーザ層の広がり・変化だったりします。 また、リリースした機能がわかりにくかったり、業務の実態とずれていたり、反応薄かったりした場合は、何かしら課題があります。

そういうものをリアルタイムに感じて開発に反映することができます。

boardでは、開発ロードマップを公開していて、ある程度の開発予定を決めていますが、最近は特定の要望が多いということは少なくなってきたので、こういう肌で感じた変化をロードマップに反映するようにしています。

使いにくい機能をリリースしたら自分がサポート業務で大変になる 

boardは、今のところ、多くの方に「非常に使いやすい」「今まで見てきた業務システムの中で最高」などと大変評価して頂いているのですが、うちはUI/UXの専門家でもなければ、事前にユーザビリティテストをやっているわけでもないので、機能追加のたびに不安です。

ただ、使いにくい機能や業務の実態に合わない機能をリリースすると、自分のサポート業務が大変になります。 それは、すなわち自分の開発時間がなくなるということを意味します。

だから必死になりますよね。 UI/UXについて勉強もするし、何度も何度も頭の中で業務をシミュレーションしています。移動中はだいたい使い勝手のことを考えています。

そうすることで、自分自身のそういうスキルが伸びて、良い循環が生まれる気がします。

開発の方針をすぐに回答できる 

頂いた要望に対して、単に「開発チームに伝えます」ではなく、初回の回答から、「ロードマップに入っている」「開発の候補には入っていて、どの程度の位置づけになっている」など具体的な方針を回答できます。

おそらく、これはユーザさんにとっては、対応するのかしないのかわからないよりも、ずっと良いのではないかと思います。

もっとも、「対応しない」「対応する可能性は低い」ことも素直に伝えているので、それが6分で回答返ってきたらちょっと嫌ですよね・・・。

boardの問い合わせ対応を全て私がやっているのは、単純にリソースの問題という点もあり、現実的には、サービスの成長とともに、全てを開発者自身が回答するということは難しいと思います。 ただ、一部でもいいので、開発者が実際に問い合わせ対応してみると、学ぶことが多いと思うのでオススメです。

こういうブログを書いておきながらあれですが、4月からサポートメンバーが一人入る予定です。

現時点ではまだ一人で対応できていますが、今後さらにユーザ数が増えた場合、さすがに一人でやっていると限界があるので、数年後を見据えて、今から準備をしていこうと思います。

少し前になりますが、11月で無事に5期目が終わりました。 

起業してもう5年も経つんですね。あっという間でした。 そして、今まで在籍した会社の中で、ヴェルクが一番長くなりました。

5期は、個人的にも、おそらく対外的にも、この1年はboardのイメージが強い1年でしたが、実はもう1つ、自分が新規の受託案件の”開発"から抜けるという取り組みをしていました。

この1年間やってきたことを振り返ってみたいと思います。

board

2014年8月に正式リリースして1年ちょっと経ってところなので、最近はだいぶ運用も慣れてきましたが、この1年は、うちなりの自社サービスの開発・運営の仕方を模索した1年だったように思います。

1年ちょっと前に書いたブログが「受託開発の会社が本格的にWebサービスを開発・運用してみてぶつかった課題（只今5ヶ月目）」です。

基本的にずっと受託をやってきたので、ユーザサポート・プロモーション・開発の進め方・受託とのバランスなど、色々と課題がある時期でした。

自分の中で、受託をやめてサービスに集中する選択肢はなかったので、この1年、これらの課題に取り組んできたという感じです。

現在どうなのかというと、ユーザサポートは、ある程度自信を持って、自分たちのやり方を見つけたように思います。 この1年間、開発ロードマップを公開するという取り組みを続けてきたり、昨年の3月から、問い合わせの初回回答時間の中央値（12月は6分！）を公開したりと、かなりオープンなスタンスでやっています。 また、問い合わせは基本的にすべて企画・開発を担当している自分が回答しています。

いわゆる絵に書いたようなユーザサポートではないですが、業務システムをずっとやってきた身としては、業務効率化は、単純に頭で考えたり、ユーザの行動を分析したりするだけではわからない部分があると思っていて、そういうものをより肌で感じるため、距離感の近い開発・運営をしていくためにこのようなスタンスで取り組んでいます。

プロモーションは相変わらず難しいですね。 うちのように小さな無名な会社の場合、メディアに取り上げられることもなく、口コミと検索からの流入が基本です。 それでも1年間を通して、安定して新規獲得ができているので、まずは土台としては出来上がった形だと思いますが、これを伸ばすための次の手が必要だなと思っています。

受託とのバランスも相変わらず難しいですが、先にboardの開発・サポートの時間を確保して、それ以外で受託を回すようにしているので、「受託が忙しくなると自社サービスが止まる」ということはなくなりました。

これらについては「受託開発の会社が自社サービスを1年運用してきた内容・結果と今後の課題」に詳しく書いているので、興味がある方は、こちらも合わせてどうぞ。

ひとまず正式リリースから1年経って、年間を通じて、サポートや継続開発をして、事業としては離陸できたかなと思っています。また、自社サービスの開発・運営にも慣れてきて、ある程度、自信がついたのも良かったと思っています。 正直なところ、リリースした時は、ここまで使えってもらえるとは思っていなかったし、そもそもそこに持っていけるイメージもありませんでした。

ちなみに、来月にはboard事業として内部原価も含め単月黒字化ラインまで行きそうな感じです。もっとも、board関連で採用して内部原価が上がる予定なので、つかの間の単月黒字化ですが。

「受託と自社サービスの両立」をずっと言ってきて、自分の中で、自社サービスが収益的にお荷物になっていては意味がないと思っていたので、ひとまずここまで来られたのは良かったなと思います。

自分が新規受託案件の"開発"から抜ける

実は5期の一番のテーマはこれでした。

コードを書くことも好きだし、受託も好きなので、個人的にはあまり受託の開発から抜ける理由はないのですが、一応社長なので、もう少し中期的な取り組みに時間を割くべきかなと思っていました。

元々、創業社長がエンジニアの会社にありがちな、自身ががっつり受託案件の開発に入っていて、かつ、売上の占める割合も非常に高いという状況でした。 ただ、いつまでもこの状態を続けておくのは良くないと常々思っており、また、もう少しboardに時間を割きたいということもあり、この1年は開発に入らないようにしました。

ちなみに、完全に受託から抜けたわけではなく、営業やプロマネとしては引き続き残っていますし、過去に自分が開発した既存案件の追加開発は引き続きやっています。

「社長がいつまでも受託やってたらダメだよ」なんてよく言われたりしますが、抜けることによって現場が大変になったり、クオリティが下がってしまっては本末転倒なので、4年目まではその準備をしてきたという感じで、ある程度土台が整ったので、5期目で受託の開発から抜けるという取り組みをしてみました。

結果としては、まずまずうまくいったかなと思っています。会社全体の売上としても必要なラインは上げられたし、自分の売上も4期目と比べて半分以下になりました。

ちなみに、受託の開発から抜けるにあたって、判断基準は以下の点でした。 ＜他のメンバーとのリスク感覚の一致＞ 「リスク感覚の一致」はこのブログでも度々書いていますが、これがある程度合っていると、こちらが危ないなと思うタイミングで報告・相談してくれるようになるので、そこまでは任せておきつつ、リスクが出てくれば、遅れることなく対応できるようになります。

この感覚がある程度一致してきたという感触があったので、「他のメンバーに丸投げ」ではなく「うまくリスクヘッジしつつ任せられる」という手応えを感じていました。

＜ストック型売上の増加＞ 自分が開発から抜けて、そのまま間接コストになってしまうと、自分の分のコストをみんなが負う形になります。 もっと人数が多ければ一人あたりの負担は小さいですが、うちの人数（自分を入れて6人）だと、一人あたりの負担が大きくなってしまいます。

そのため、自分を間接コストにしないため、自分が持っている受託案件の保守や、自社サービスのPatto・boardといった月額で入ってくるストック型の売上で、ある程度自分のコストはカバーできる状態にしようと考えていまいた。

5期目の初めの段階ではまだまだでしたが、ある程度boardの売上を伸ばせる想定で、他のメンバーの負担が大きくならない見込みだったので、チャレンジしてみることにしました。

レベニューシェア

実はboardと平行してもう1つサービスの開発をしていました。うち名義ではないので名前は伏せますが。

個人的にはあまりレベニューシェアは好きではなく、うまく行ったケースをあまり聞かないのですが、「人の信用」もあって取り組んでいます。

こちらもひとまずスタートできて、少しずつ売上があがるようになってきています。

なるべく早く、Patto・board・レベニューシェアで、売上の5割まで持って行きたいなと。そうすると、また色々と新しい取り組みができる気がしています。

課題とそれに対する取り組み

＜boardの開発＞ boardの開発は、これまでほぼ自分一人でやってきた状態だったので、まずはここをどうにかしないといけないと思っています。

ただ、boardの強みや評価頂いていることが、「経営者が開発していること」に起因するものが結構多いので、まずはコアな機能ではなく、既存機能の改善や使い勝手の向上から他のメンバーが入っていく予定です。

他のメンバーは全員受託案件を持っているので、数時間〜数日程度でできる小さな改善をプールしておき、合間ができたらそれを自由にピックアップして、プルリクエストしてもらう運用を試してみています。

「受託の手が空いたら」という、受託との両立で一番ダメなパターンだったりしますが、まずは小さいところからスタートしてみようと思っています。

＜ boardのサポート＞ ユーザサポートも同様ですね。今のところ全て自分で回答していて、それはそれでかなりメリットがあります。

実際のユーザの声や変化が肌感じられますし、使いにくい機能をリリースしてしまったら問い合わせが増えて開発時間が減るので必死です。また、要望に対しては、開発計画・構想を踏まえて回答できるので、おそらく回答のクオリティも高いんじゃないかと思っています。

ただ、導入社数の増加とともに問い合わせは増えるので、まずは、単純な使い方の問い合わせから他のメンバーで対する体制にしていこうと思っています。（4月からサポートスタッフが入る予定）

＜エンジニアの採用＞ 残念ながら、できませんでした。 ちなみに、現在、技術面で自分の代わりになるエンジニアを募集中なので、こんな会社に興味がある人がいたらぜひご連絡ください！

まとめ

5期は、自分が新規受託案件の開発から抜けるという、うちの会社としては大きなチャレンジをして、自分としては、それでできた時間で、中期的な売上を上げるための仕組みを作る取り組みをしていました。

両手を上げて「大成功」とまではいきませんが、きちんと土台はできた気がするので、あとはどれだけ伸ばせるかだと思っています。

そのためには、やはりマーケティング・PRが一番の課題です。無名のベンチャーにとって、これは本当に難しいです。

現時点でも、基本的にインバウンドのみで新規獲得しているので、全くできていないわけではないですが、予算がない・知名度がない中で、今以上に成長率を上げるためには、もう一工夫、何か必要なんだろうなと思っているので、この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の開発を加速させるべきではないのかと。

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

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

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

認知度の向上

もううちとしては永遠の課題ですね。

存在を認識してもらった上で選択されないのは、サービスとしての力不足なので仕方ないですが、まだまだ比較の土俵に乗っていないケースも多いだろうなと思っています。

ただ、急にどうにかなる問題でもないので、基本的には今の路線は継続しつつ、常に頭を悩ませて、トライ&エラーを繰り返していくしかないのかなと。

ユーザサポート体制の強化

いつまで僕一人でやるのかという点ですね。

とはいえ、他のメンバは受託の仕事もあるし、まだサポート専任のメンバが必要なほどのボリュームはないし、タイミングがなかなか難しいです。

ただ、できればトレーニングなども提供していきたいと考えているので、「トレーニング担当兼ユーザサポート」のメンバーを採用するのはありかなと思ってたりします。

このブログで、ずっと「受託と自社の両立」ネタを書いてきていて、とはいえ自分でそれをちゃんと結果で残さないとなあと思っていたので、boardはまだまだこれからですが、少しは形にできたので良かったなと思います。

boardというサービスを開発・運営しているのですが、これは見積書・請求書などの書類作成から営業管理・経営管理までをカバーするようなサービスで、元々自分が経営をしていく上で、Excel管理を卒業しつつ、書類作成だけでなく経営上必要な売上の予測管理をしていくために開発を始めました。

そのため、完全に「自分事」のシステムで、現在でも、企画・開発から運用・サポートまでを一貫して自分がメインで関わっています。

実際に業務・経営をしている人が仕様を考えて開発することで、リリース前から、よりリアルに実際に近い形で検証して改善を繰り返せるので、当事者が直接関わることは本当に大事だと思っています。 特に業務系サービスでは、「企画・開発している人は、実際にこの業務をやったことないんだろうな」と感じることも多く、ドッグフーディングは不可欠だと思います。

ただ、ドッグフーディングをしていて、気をつけないといけないなと感じていることがいくつかあるので、それを書いてみようと思います。

自分・自社に最適化されすぎてしまう

自分たちが、開発しているサービスの当事者であれば、当然そこにこだわりや自分の習慣があるかと思います。

boardの場合は、見積書や請求書作成という機能自体というよりは、書類関連の業務フローだったり、経営における数字の分析の仕方などは、組織によって異ることも多く、ドッグフーディングを繰り返すことによって、自分自身に最適化されすぎてしまう可能性もあります。

よくありがちなのは、「ほら、便利でしょ！」って押し売りする感じになってしまうパターンですね。

boardの開発において、「自分としてはこうだと思う」というのはかなり強く持っていますが、「これが自分の会社だけのことか、それともある程度幅広く活用できるのか」というのは何度も自問自答するようにしています。

自分たちの判断が間違っていることもある

自分たちが当事者のサービスだと、自分と関係がない分野のサービスを開発している場合に比べて、考え・感覚にそれなりに自信を持ってやるケースが多いように思います。

ユーザさんからの意見はもちろん重要ですが、それが常に正しいとは限らないですし、サービスとしての方針などもあるため、全てを受け入れることができるわけではありません。

そのため、ある程度自分の判断基準に照らし合わせて、対応有無を検討しますが、この際、自分が当事者のサービスだと、自分を過信しすぎて判断を間違ってしまうケースがあります。

自分たちでドッグフーディングして判断したことが、必ずしもベターでないケースもあるので、それは頭に入れながらドッグフーディングするようにしています。

初めてその機能を見た時の感覚を失う

機能追加にあたって、仕様を考えて、実装して、使ってみて改善して、というプロセスを経ると、「その機能を初めて見た時」という体験を自分でできなくなってしまいます。 もうその機能について、散々考えている状態ですからね。

初めてその機能を見た人がどう感じるのか。わかりににくくないのか、そもそもその新機能の存在に気づくのか。

これはかなり難しい問題です。

そのため、boardの開発においては、自分が開発して、もう一人のメンバーがテストをするというフローで進めていますが、テストをするメンバはTrelloで機能の概要を知っているレベルで、実際にテストをする時まで、画面すら見たことがないことがほとんどです。

そこで疑問に感じたことなどを上げるようにして、この問題に対して気づけるようにしています。

新規ユーザに対する考慮

自分自身でもそのサービスを使っていると、もう初めてサービスを使う時というのを想像ができなくなってしまいます。

どんなサービスでも、そのサービスがどういうコンセプトがあって、どういう特長があるのかを理解してもらえるかというのは、有効に使って頂く上では不可欠かと思います。

正しく特長が伝わっていなくて、使われなくなってしまうパターンが一番残念ですからね。

前述の機能追加のケースとは違い、社内のメンバはすでにサービスをよく知っている状態ですので、なかなかこの問題に気づくのは難しく、ドッグフーディングで解決できないものです。

ドッグフーディングでカバーできないユーザビリティの問題があるということを頭に入れておくことが重要かと思います。

そこで、使い始めたばかりの方からのお問い合わせ頂く内容が非常に重要になってきます。

boardのお問い合わせは、今のところ全て僕が回答しているのですが、そうすることで、リアルタイムにユーザの反応を肌で感じることができ、また要望の内容・傾向なども頭に入りますので、それで対応していくようにしています。

集計された結果ではなく、企画者・開発者が直接問い合わせ対応を行うというのは、普段忘れがちな感覚を思い出させてくれるため、とても大事だと思います。

まとめ

ドッグフーディング自体は本当に大事なことだと思っています。やはりその業務をやったことがない人に業務を効率化するシステムは作れないと思いますし、経営をしたことがない人が経営者の気持ちや欲しい数字はわからないと思います。

boardというクラウド型業務・経営管理システムを開発・運営しているのですが、昨年の夏頃からなんとなく開発予定の機能をブログに公開していて、今年に入ってから「ロードマップ」という形で細かく公開するようにしました。

これについて、「なんで公開しているのですか」とよく質問されるので、背景とその効果について書いてみたいと思います。

元々はユーザさんからの要望

β版初期の頃から熱心に使って頂いていたユーザさんからの要望でした。

このユーザさんは、おそらくβ期間中、最も多くの要望をくれたユーザさんなのですが、ある日、

「たくさん要望出しましたけど、サービスの方針として対応できるできないはあると思いますし、対応予定の機能を公開してくれると、何が対応されるのかわかって良いのではないかと思いました。あとマーケティング的にもプラスになると思いますし。」

という感じの連絡を頂きました。

当時はベータ版を出してまだ数ヶ月という頃で、本格的Webサービスを運営するのも初めてだったので、どんな感じで問い合わせ対応したらよいかわからず、「なるほどー」という軽い気持ちで書き始めました。

3ヶ月スパンでの公開

実際にロードマップを見て頂けるとわかるのですが、ざっくり3ヶ月ごとに対応予定のものを公開しています。

この中での順番は決めておらず、また、やっぱり対応を保留・先送りにすること、逆にここに載っていなくて対応することもあります。

ですので、厳密にここにあるものを必ずやります、というスタンスではなく、boardとして、「こういう感じで予定しています」という意思表明という位置づけですね。

公開してみた効果1：スケジュール管理

個人的に、ずっと受託開発をやってきていて、今でもそうなので、「納期がないという状況」がモチベーション的にもスケジュール管理的にも難しかったので、それが、「公開したからにはやらなければ」という状況になったのはすごく良かったです。

最近、僕自身は、受託案件の「開発」からは抜けているのですが、営業やプロマネは引き続きやっていて、相変わらずいくつも受託案件を抱えている状況なので、このロードマップがなければ、boardの開発ペースを落としてしまっていたかもしれません。

受託開発と自社開発を平行してやっていると、どうしても受託に引っ張られてしまい、自社開発の時間を割けなくなってしまいがちですが、ロードマップのおかげで継続して開発できたかなと思います。

公開してみた効果2：好評だった

思いのほか好評でした。

頂いた要望を全て対応できるわけではないので、ロードマップを公表すると、「対応しないもの」や「優先度が低いもの」が明確になってしまうので、どういう反応があるか少し怖い部分はありました。

ただ、実際に公表したところ、「どういう方向で進化をしていくつもりなのか明確になって、利用するかどうかの判断の参考にした」「透明性があって好感が持てた」など、総じて好評でホッとしました。

元々、開発予定の公開を提案してくれたユーザさんが「マーケティングにもプラスだと思うので」というのは本当だったなと。このユーザさんに感謝です。

公開してみた効果3：要望に右往左往しなくなった

以前、「受託開発の会社が本格的にWebサービスを開発・運用してみてぶつかった課題（只今5ヶ月目）」に書いたように、要望の対応について、どういうスピード感でやっていくべきなのか、優先順位付けをどうするかなど、最初の頃は非常に難しかったです。

ただ、ロードマップを公開することで、ある程度直近やることが明確になっているため、よほど緊急性の高いもの以外は、次のスパン以降で対応するもの、という一次切り分けが自動的にできるようになりました。

これは精神的に結構楽になったなという感じです。

「競合から見られるのでは？」

「競合から見られるのでは？」というのは良く聞かれます。

でも、競合をほぼ意識していないんですよね。もちろんある程度「把握」はしていますけど、たぶん、それを意識しながら作ってたらいいものが作れないと思うので。コピーを作っても仕方ないですし。

また、「見積書・請求書作成サービス」という観点では後発で、まだまだユーザ数も桁が違うと思うので、そんな気になる存在にもなっていないでしょ、と考えています。

「競合」よりも「使って頂いているユーザさん」に意識を向けるべきだと思っていて、ロードマップの公開は、ユーザさんにとってはメリットがあるようなので、今後も続けていきたいなと思っています。

もともと、「アイデアはどんどん外部の人に話すべき」と思っています。それによって色々フィードバックを得られますし、同じアイデアを考えている人は世の中たくさんいると思うので、大事なのは行動に起こすこと、手を動かしてアウトプットすること。隠しても仕方ないですからね。

boardというサービスをリリースして半年ほど経ちました。β版は5月なので、それからだと9ヶ月です。

ヴェルクという会社は基本的には受託開発の会社なので、リリース前もリリース後も、受託開発と平行してboardの開発を続けています。

よく「boardガンガン機能追加してますね！」って言われて、実際更新履歴を見ると、平均で10日に1回くらいのペースなので、確かにそこそこのペースでリリースをしているのですが、意外と淡々と開発している感じです。

そもそも、確か正式リリースした日も、特に感慨もなく、普通に受託の開発してた気がしますし。

資金調達をしているわけではないので、サービス開発にかかるお金は自分たちで受託開発で稼いだものを回します。そのため、当然ながら潤沢に資金があるわけではなく、やはり資金調達をしている会社のように、ガンガン広告を打って露出して急成長させる、というようなことはなかなか難しいです。

そこで今回は、受託開発をしながら見つけた自分たちなりのスタンスについて書きたいと思います。

初めは不安との戦い

本格的なWebサービスをやるのは初めてで、開発のスピードやサポート、プロモーションなどわからないことだらけでした。

問い合わせもらったらそれをどのくらいのスピード感で返すべきなのか、要望はどのくらいのスパンで対応すべきなのか。

プロモーションはどうするのか。競合サービスはガンガン広告出しているけど、うちも広告とか出すべきなのか。

考えること、調べること、やることが多すぎて、目まぐるしい状況でした。

ただ、受託の仕事もあったので、あれもこれもできない状況ではありました。

継続可能なペース

おそらく資金調達をした場合、ある程度一気にサービスを成長させる必要があるのだと思うのですが、うちの場合、受託開発で稼いだお金を自社サービスに投資している形なので、良くも悪くも、急ぐ必要に迫られていないんですよね。

露出を増やして一気にシェアを取る、というのは非常に重要な戦略の一つだとは思うのですが、自己資金でやっている以上、同じことはできないので、地道に価値のあるものを作っていくべきなんだろうなと思っています。単に表面的な機能数ということではなく、もっと本質的な部分で。

その覚悟を決めてからは、意外と周りが気にならなくなりました。

最近よく「board良さそうだから、資金調達して一気に勝負をかけるべきなんじゃないの？」って言われたりするのですが、僕もうちの会社もそういう感じではないので、こんなスタンスで、着実にやって行ければ良いかなと思っています。

boardは、お試し後の有料登録率は非常に高くて、たぶん実際に使って評価して頂いているのかなと勝手に思っているので、方向性は間違っていないのではないかと思っています。

派手な機能よりも本質的に必要な機能を優先

派手な機能の方が、取り上げてもらえるかもしれないですし、いいねがたくさん付くかもしれません。

もちろん、色々なところで取り上げてもらったりソーシャルで話題になるのは大変ありがたいことでぜひぜひお願いしたいのですが、そういう機能が本質的にユーザが求めているものなのか、ユーザ体験を向上させるものなのか、必ずしも一致するとは限らないと考えています。

boardの場合、見積書・請求書の作成などから営業管理・業務フロー・経営管理あたりをカバーしているのですが、自分が欲しかったもの、boardを作ることを決めた要因は「業務とのフィット感」でした。

単に要件を満たすだけの機能を作るだけなら、さくっと出来るんですよね。

でも、業務とシステムのギャップを最大限埋めることをずっと考えて、何度も何度も操作フローや画面構成、要件・設計を作りなおしていました。

ボタンの配置1つに1時間も考えてても、実際の業務とのギャップを突き詰めても、それが取り上げられるわけではないんです。外から見たら同じ1機能なのです。

でも、そういう積み重ねが、使い心地の良さや業務全体での効率化に繋がってくるのと、一朝一夕で作り上げられるものではないので、それを継続してやり続けておくことが、筋肉質なサービスを作るのではないかなと思っています。

高いテンションと情熱の違い

基本的に、ガッとテンションを上げて開発していると、サービスを開発している感があって楽しいですし好きなのですが、どこかで勢いは落ちてしまうし、冷静に自分たちが作っているものを分析できなくなってしまいます。

以前、知り合いの先輩経営者が、「打ち上げ花火のような盛り上がりに依存した組織運営をしていると、その快感が基準になってしまって後で厳しくなる。いいものよりも、花火を上げるために企画・開発するようになって崩壊する」って言っていたのが非常に印象に残っています。

テンション高く開発するのと情熱を持って開発するのは、似て非なるものだと思っています。

おそらく100%の時間を自社サービスに割り当てているとそうなってしまいがちですが、今の僕の場合、受託案件や営業やその他会社のことで、boardに割けている時間は全体の1/3くらい。

「もっとboardの開発に時間を割きたい」と思っているのですが、頭を冷やす時間があって、意外とちょうど良いのかもしれません。

ユーザさんとのコミュニケーション 

今のところ、頂いたお問い合わせは全て僕が回答しています。 社内のリソース的な問題もありますが、まだまだ進化の途中なので、ユーザさんの意見を肌で感じたいと思っています。

打ち合わせに入っていなければ、できるだけすぐに返すようにしているので、最短で数分で返信していたりしています。

何かご要望を頂いたら、そのシチュエーションや理由などを突っ込んで聞くようにしています。受託をやっている時の癖というか習慣なのですが、やはりその背景にある業務をヒアリングするところからが始まりだと思っています。

「Webのサービスでそこまでやる？」と言われたりすることもあるのですが、顕在化したニーズではなく、要望の背景にある本質的なニーズを理解しないと、いいものが作れないですからね。本当は直接ヒアリングに行きたいくらいです。

最初の頃は、Webのサービスとしての問い合わせ対応についてどうすべきか悩んでいましたが、今は、受託と同じ気持ちでやっています。

「いいものを作る」と「マーケティング・プロモーション」の関係

 「いいものを作れば売れる」という時代ではないことは重々承知していますが、「あまり完成度が高くないものをマーケティング・プロモーションで売る」というのも、作り手としてはやりたくないことでもあります。

そのため、前提として、作るものに妥協はしないようにしています。それは、エンジニアとしてだけでなく、操作性や本質的な業務効率化など、単に「機能の提供で解決する」以上のことを追求しています。 同時に、「マーケティング・プロモーション」についても、多くの予算をかけたことはできませんが、少ない予算の中で継続的に手を打っています。

「グロースハック」なんて言葉が流行ったように、サービスを成長させるために色々やらないといけないと思っていました。

もちろん、「まずは存在を知ってもらう」ということは絶対に必要で、これはまだまだなので頑張っていく必要がありますが、まずは、比較の土俵に乗った時に、選んでもらえるようなサービスにしていくことが大事だなと。

「いいもの」を「あまり多くはない予算」でうまく軌道に乗せられればいいなと思っていて、今のところ、それなりに順調には来ている気はします。

こんな感じで、最近は、ようやく自分たちにあったスタンスを見つけられたかなという気がしています。

ヴェルクを設立して4期目が終わりました。4年早かったなあという印象です。

以前、「起業して3年でやってきたこと」という記事で、これまでやってきたことをかなり詳しく書いたので、今回はその続きという感じです。

なので、今回の記事は、先に「起業して3年でやってきたこと」を読んで頂いた方が分かりやすいかもしれません。

新サービス「board」のリリースとドッグフーディングの重要さ

一番大きな出来事は、やはり「board」のリリースです。

起業してからこれまで、案件管理・書類管理・経営管理として、以下のことをExcelでやっていました。

・案件一覧を作成し、見込み案件の把握や受注済案件の請求日・入金日の管理 ・見積書、発注書、納品書、請求書、送付状を作成 ・案件一覧を元に月別、担当者別、顧客別の売上を手動で集計（4半期に1回程度） ・キャッシュフローが危なそうな場合は、入金日ベースでキャッシュフロー予測を作成

それなりにうまく仕組み化できていたのですが、案件数が多くなってきて、いいかげんExcelでの管理が大変になってきたので、見積書・請求書作成サービスを使おうと思い、ひと通り試してみたのですが、どうもしっくりこず。

「書類の作成」という点では問題ないのですが、見込み案件の管理や売上予測など、経営的に必要な点がカバーできていなかったり、機能はあるけど受託の会社の業務にあっていなかったり。

元々新卒で入った会社で業務系システムをよく作ってきた経歴であることもあり、「やっぱり業務システムは業態に合わせて作らないとダメだよね」ということから、受託ビジネスに特化した業務・経営管理システム「board」を作りました。

まだリリースしたばかりのサービスですが、これを通じて、「サービスはドッグフーディングできていることって重要だな」と痛感しています。boardの場合、うち自体が受託開発の会社だし、僕自身がメインターゲットのユーザで僕自身が開発しているので、日々、ドッグフーディングしながら開発している感じです。

受託の体制の変化〜派手な方針ではなく地道な取り組み

boardの影に隠れがちですが、実は経営的に重要だったのはこちらです。

会社を立ち上げて1〜2年目は、僕1人で売上の半分近くを上げるなど、起業したばかりのベンチャーにありがちな、社長依存度が極めて高い状態でした。

「起業して3年でやってきたこと」に書いた通り、1年目は表に出せる実績を作るため、他のメンバに自社アプリを開発してもらい、その分の売上は僕が頑張るという無茶なことをしていましたが、それを除いても、営業力・デリバリー力・収益力など、あらゆる面で依存度が高い状態でした。

ありがちといえばありがちですが、会社としては非常に大きな問題ですし、そもそも継続可能な仕組みではないので、この課題に対しては継続的に取り組んできました。

その成果がある程度形になって現れたのが今期だったように思います。

2点、取り組んできたポイントを紹介します。

・エンジニア一人ひとりのデリバリー力を上げる

僕が1つ1つの案件を細かく見なくても安定して納品まで進められるようにするため、仕事の進め方、リスクの察知、相談のタイミング、問題解決へのアプローチ、総合的な判断力など、技術的なスキルの周辺のスキルを上げる取り組みをしてきました。

ちなみに、本や勉強会とかそういうことではなく、数年のスパンで仕事の中で段階的にできるようになっていってもらうようにします。一人ひとり状況やスピードは違うので、仕事のアサインの仕方や距離感がとても重要で、すごく手間がかかりますが、それだけ重要なことだし、真剣に取り組むべきことかなと思っています。

・エンジニアの前にプロマネを増やす

ITの会社だと、エンジニアの採用ばかりに目が行きがちですが、元々ほとんどの案件のプロマネを僕がやっている状態だったので、これでエンジニアが増えたら、その分、僕の仕事が増えるだけでした。

そのため、まずはプロマネをできるメンバーを入れて、僕が入らなくてもプロジェクトが回る体制にしようと、創業メンバー4人の次に採用したのはエンジニアではなくプロマネでした。

取締役兼エンジニア2名、エンジニア2名という組織にプロマネが1名。だいぶバランスが悪い組織ですが、今後エンジニアを増やしていくにあたって、土台を築く狙いです。 ここで大事なのは、単にプロマネの頭数を揃えることではなく、きちんとうちの会社にあったやり方を本人なりに確立すること。

1年ほどかかりましたが、現在では、僕が全く入らず仕事を取ってきてプロジェクトを回せるようになりました。

急にできるようになるわけではないので、この2点を3年間かけて取り組んできたという感じです。

すごく地道です。急がばまわれです。

「○○やります！」と派手に方針を打ち出すのは簡単ですが、本質的に必要なことを継続的に取り組むことは非常に難しく根気が必要です。

これが今期は明確な結果として現れた気がします。

そして5期目は、僕の受託への関わり方として、プロマネはやりますが、エンジニアとして受託の開発には入らないようにするつもりです。別にやりたくないわけではないですが、一つのチャレンジとして。

ストック型のビジネスモデルを作る

受託開発の請求は、基本的に納品基準のため、請求できるまでには数ヶ月かかります。また、常に仕事があるとは限らず、営業状況によって空いてしまう期間もあります。

経営者としては、気が気でないというか、安定はしていないビジネスモデルだなと思います。

とは言え、長期でエンジニアを派遣して安定させるようなことはするつもりはないので、自分でそういう事業を作っていくしかないなと。

取り組みとしては2つ。 ・保守性の良いシステムを構築して、保守契約を積み重ねていく ・月額課金モデルの自社サービスを作っていく

運用保守は増えすぎるとそればっかりになってしまう恐れがあるので、オペレーションが伴うものは極力避け、自動化できるものは自動化し、可能な限り手が掛からないようにして、少額でも積み重ねていくようにしています。

自社サービスは、3年目の初めに作ったスマホアプリCMS「Patto」がもうすぐ2年になり、それなりに積み上がってきました。

そして前述のboard。まだまだこれからですが、ストック型の積み上げができる可能性があるサービスを作れたのではないかなと思っています。

ストック型のビジネスこそ急にできるわけではないので、継続して数年かけて構築していくことが大事だと思います。

受託と自社サービスの両立を収益化段階へ

このブログでもずっと書いてきた通り、受託と自社サービスの両立を目指しています。

1〜2年目は、iPhoneアプリの「まずは自分たちで作ってみる」という段階から、Patto・boardと1年ごとにサービスを出してきて、受託の会社が「自分たちで作る」というフェーズに関しては、ある程度できたと思っています。

この後は、小さい会社がやっているサービスをどうやって認知してもらうかというマーケティング・プロモーションや、継続的に開発を続けつつサービスからの売上を伸ばしていく、そしてそれをどうやって自分たちの資金だけでやっていくか、そういうフェーズに入ってきたのかなと思っています。

受託で食べていけていると、自社サービスでの売上は座布団であってメインではないという位置づけになりがちで、もちろんそれは大事なことではあるんですが、最近、それが言い訳にもなってしまうかなと感じています。

これまでも今後もサービス1本で勝負するつもりはないですし、資金調達して一気に勝負をかけるようなことをするつもりもなく、これまで通りやっていこうと思っていますが、受託で食えていることが、サービスの成長を止めてしまわないようにしないといけないなと思っています。

うちの会社は、基本的に受託開発の会社ですが、自社サービス開発の両立を目指しています。その取り組みの一つとして、今年の5月、boardという受託ビジネス向けのクラウド型業務システムのベータ版をリリースし、8月に正式リリースしました。

昨年、PattoというスマホアプリCMSをリリースしていましたが、これはどちらかというとソリューション型の製品のため、今回のboardが、うちとしては初めての本格的なWebサービスです。 ベータ版リリースから約5ヶ月、正式リリースから2ヶ月が経ったところですが、これまでにぶつかった課題について書いてみたいと思います。

まとまった開発時間がとれない

当然ですが、できるだけ早く開発して、早くリリースしたいという思いがあります。しかし、基本的に受託開発を止めて自社サービスの開発をしていたわけではないため、1ヶ月がっつりとboardの開発をする、ということができませんでした。そのため、「できるだけ早くリリースする」という思いは捨てて、毎月2割程度の時間を割いて、少しずつ開発していくというスタンスでやっていました。 9月後半に作り始めて、12月から社内α版で運用開始、2月にクローズドベータ、5月にパブリックベータ、8月に正式リリースという流れでした。 正式リリースまで1年弱かかったことになりますが、段階的に自分たちで使ってみては改善し、フィードバックをもらっては改善する、というサイクルができたので、結果的に良かったように思います。

開発が止まる時がある

受託開発と自社サービス開発を両立するにあたって、受託開発に押されて自社サービス開発の時間を削らないように、可能な限りバランスの維持に務めていましたが、やはり受託開発の納品直前や遅れ気味の時など、自社サービス開発の方を止めざるをえない時があります。 boardの開発の場合は、クローズドベータからパブリックベータまでの3ヶ月間が、そういう状態でした。クローズドベータのフィードバックを多少反映したのと、公開するにあたっての準備で手一杯で、本来追加したかった機能が後回しになり、案の定、そういうものはベータ版のフィードバックで多数指摘されました。 正式リリース後は、そういう状態になってしまうと問題なので体制を見なおしていますが、受託開発をしつつ並行して自社サービス開発を行っていると、大きな課題です。

要望対応のスピード感・優先順位付け・対応有無の判断が難しい

ベータ版公開以降、ありがたいことに非常に多くのご要望を頂きました。「もっとこうした方が良くなる」という意見が多く大変参考になったのですが、それをどういうスピード感で進めていったらいいのか、非常に判断が難しかったです。 全部さくっと対応できればよいですが、リソースの関係上難しいですし、元々予定していた機能追加の予定もあります。 特にベータ版公開後1ヶ月は、そういう状況に全く慣れていなかったので、「せっかく使ってもらったのに、早く対応しないとユーザが離れてしまう」という不安との葛藤でした・・・。

今は、Trelloに全ての要望や追加予定機能を書き出し、対応有無が未決定のものは3段階の優先順を付け、毎週これを俯瞰しながら、要望の多さや機能の重要度を考えながら順番を入れ替えたりしています。 とにかく目の前のことだけを見てしまわないようにすることが大事だと思っているので、こういう時はTrelloは非常にいいですね。 受託開発の場合はお客さんとの調整ごとですが、サービス開発の場合は特定のユーザと調整するわけではないので、本当に難しいなと思いました。 受託開発にはないパターンの悩みです。

問い合わせ対応の感覚が掴めない

受託開発の仕事をしていると、顔の見えない相手と仕事をすることがないので、会ったことがない多数のユーザさんを相手にするサポートに最初はかなり戸惑いました。 要望や質問などの問い合わせがあって、普段の仕事の感覚で即レスするとびっくりされることがよくあって、びっくりされたことにこっちがびっくりしてみたり。 boardでは、Airbrakeを導入しているのでエラーが発生したら検知できるようになっています。ベータ版の頃にあった不具合で、ある特定の操作をすると発生するエラーではまってしまっているユーザさんがいたので、こちらから「すみません、不具合なので修正します。今は○○という操作をして頂ければ回避できます」とメッセージを送ったらびっくりされたり。ちょっとストーカーっぽいので、今はやめましたが・・・。 結局未だに慣れているわけではないのですが、サポートの人を置いてマニュアル化されたような対応ではなく、開発者自身が生身の対応しているのがわりと好評らしいので、このスタンスで続けたいと思っています。

プロモーションが難しい

会社や経営者が有名だったりすると、新しいサービスを出せば認知される確率が高く、本当に羨ましいなと思うわけですが、うちは残念ながらそういう会社ではないので、頑張って認知してもらう方法を考えていく必要があります。 これが本当に難しい。 リリース直後は、プレスリリース出したり、メディアで紹介していただいたり、FacebookやTwitterでみんながシェアしてくれたりするので、最初はそれなりにアクセスを集めることができます。 しかし、当然それが継続するわけではなく、継続的にどうやって集客するか、というのは大きな課題です。 インバウンドで集客するためには、SEOやコンテンツマーケティングは頑張らないといけないと思っています。ただこれは成果がでるまでにはそれなりに時間がかかります。短期的に認知してもらうためには、広告は1つの手段だと思いますが、競合となるような請求書発行サービスが相当な広告投下量のため、単純に同じ土俵では戦えなかったり。 限られた予算の中でどうやって継続的に集客していくか。 受託の会社をやっていると自分でプロモーションをするということがないですし、資金調達をしているわけでもないので、広告で一気に認知度を上げるという方法も取れません。大きな課題です。

競合との差別化

「競合はどこか」と言われるとクラウド型の見積書・請求書発行サービスになると思います。 多くの見積書・請求書発行サービスは、「書類の発行」をメインにしていますが、boardは「書類の発行」だけでなく、業態を絞って「業務・経営管理の効率化」に軸を置いているため、個人的には、目指すものやニーズが異なるため直接競合するものではないと思っています。 ただ、サイトに来ていただいた人がサービスの説明を詳しく読むとは限らず、ぱっと見は同じに見えてしまう可能性があります。boardとしては、「見積書・請求書発行サービス」と捉えられたら負けなわけです。 それをどうやって伝えるか。 「最初にサイトを見た時の想定よりも実際に使ってみた後の方がずっと良かった」と何人にも言われたりするのは大きな課題です。 いかにして、ファーストインプレッションでサービスの特長を伝えられるか、コンバージョンを計測しながら、試行錯誤していかないといけないんだろうなと思っています。

コンバージョンを上げるための施策

現時点で全く出来ていない部分です。 ウェブマーケティングをやっている人に話を聞くと、アクセス解析に基づくサイトの改善だったり、お試し期間中に利用状況に応じたフォローメールだったり、キメの細かいフォローをするものだそうで。 確かにまだサイトに来たことない人を呼び込んだり、お試し登録したことない人にお試し登録してもらうハードルよりも、お試し登録してくれた人をフォローして、不明点や課題をクリアにして継続して使ってもらう方が確率としては高いと思うのですが、どうもそういうことをやってきていないと、気が回らないですね・・・。

広告にかける予算感

受託開発をやっている会社で外部から資金調達しているケースは少ないのではないかと思います。資金調達していない場合、かけられる予算はかなり限定されます。 そのため、最近よくある、多額の広告予算を投下して一気に露出を増やすということはできないわけです。 ITの会社なので、開発自体は自分たちでできます。ただ、モノを作っても勝手に認知され広まるわけではなく、プロモーションの方がずっと労力もお金もかかるものなのではないかなという気がしています。 そこに対してどのくらいの予算をかけていくのか。 その感覚がイマイチ掴めていないんですよね。 そもそも予算も限られているので、わかったところでできるわけではないですが、プロモーションに対応する費用対効果の感覚はまだ掴めていない感じがします。 システムを作ったり運用したりする部分は受託開発でもやっていることなので、自社サービスだからといって何か特別なことがあるわけではないと思うのですが、やはりその周辺の部分はかなり未知の分野で、なかなか悩ましいなあという感じです。

「受託開発と自社サービス開発の両立」の話をしていると、よく「受託開発が忙しくなると、自社サービス開発が止まってしまったり、尻すぼみになってしまう」という相談を受けます。 そこで、ヴェルクで取り組んでいることを紹介したいと思います。 ご参考までに。

まずは前提

これまでのこのブログで度々書いてきていますが、ヴェルクでは、受託開発と自社サービス開発の両立を目指しています。ただ、基本的に受託開発が軸で、「自社サービスで一発当てよう！」というスタイルではやっていません。 そのため、売上も時間的な割合も受託開発の方が圧倒的に多い状況です。割合的に「受託：自社」が7：3くらいでしょうか。そういう状況なので、なんとなくやってしまうと、受託開発に終始してしまいがちです。 そこで、以下のことに気をつけてバランスを取っています。

売上目標の位置づけ

経営者的視点での話になりますが、通常、会社として今期どのくらいの売上を目指すか、ある程度設定しているかと思います。 一般的に「目標」というと、高めに設定して、「そこまで頑張っていこう！」というようなものが多いかと思います。しかし、売上の目標を背伸びして設定してしまうと、当然受託開発に終始することになり、自社サービス開発の時間を確保できません。 そのため、経営的には、全員がフル稼働しないと達成しないような売上目標は設定しておらず、ある程度余裕を持たせた目標設定をし、それに合わせて営業活動をします。 厳密に建てた計画は、うまくいかなかった時の色々と破綻するので、基本的に細かく計画を立てることはしませんが、ざっくり「今期はこのくらいの売上（利益）を目指そう」という目標設定はします。この時点で、全体の割合として、2〜3割は自社サービス開発に当てられるような計画にしています。 商売人として、売上・利益を追求しないのはどうなのか、という声が聞こえてきそうですが、「○期連続増収増益！」なんてことには特に興味はなく、「受託開発以外のビジネスモデルの構築」に対する投資だと思っています。 将来に対して継続的に投資することは、経営者の重要な仕事ですよね。

目先の売上の誘惑に負けない

これも経営者・営業的な視点ですが、目の前に受託の仕事があれば受けたくなるものです。当然それで売上が増えるわけですから。 お話を頂いた仕事は基本的にあまり断らないようにしていますが、それによって自社サービス開発が圧迫される場合は、お断りしたり、少し待ってもらったりするようにしています。 これは経営者としては非常に勇気のいることで、それによって失注するかもしれませんし、そのお客さまとはそれっきりになってしまう可能性もあります。受託開発をやれば、きちんと納品すればお金が入ってくるわけで、自社サービス開発に比べて、売上を上げるという意味ではずっと楽で、経営的には誘惑なわけです。 ただ、会社として受託開発と並行して自社サービス開発をやっていこうとするのであれば、必要以上の売上を上げることで自社サービス開発の時間を圧迫していては、いつまでたっても時間を確保できません。 受託開発の案件でリソースが埋まっている場合は「リソースが空いていない」となっても、自社サービス開発でリソースが埋まっている場合は「自社なので後回し」にして受託開発にまわしてしまう事があります。 そうならないように、今期の売上目標と現時点の売上状況をふまえて、受託をとるか自社をとるかを常に考えるようにしています。

ちなみに、余談ですが、先日リリースしたboardというクラウド型バックオフィス業務・経営管理システムで、見込確度別の売上予測を目標・損益分岐点と合わせて見られるようになっているなど、分析機能に力を入れているのは、この判断をするために絶対に欠かせないものだったからです。 ＊boardは、僕自身が受託開発の会社を経営する上で必要なものを作るところからスタートしたので。

適正な価格で受注する

うちは僕自身が営業も兼ねているため、見積もりを誤るということはほとんどないですが、「技術がわからない営業が受注優先で安い金額で取ってきて現場が大変」という話はよく聞きます。 不当に高い金額で高い利益率を狙うのはモラル的に論外ですが、適正な価格で受注するということは非常に重要な事だと思います。 少ない利幅で受注した場合、エンジニアが少ない人数で回さざるを得なくなり苦労するか、会社としての利益が少なくなる、または最悪赤字になるということになります。 そういう状況だと、当然、自社サービス開発の時間など確保できず、より利益を確保するため、別の受託開発をすることになります。 経営者としては、「利益が低くても仕事がほしいタイミング」というのがあるのはよくわかります。そういう時はまた別の話ですが、それが日常にならないことが大事かと思います。

受託開発の利益率を落とさない

ここまでは経営的・営業的な視点でしたが、ここからは現場の話です。 せっかく適正な価格で受注してきても、プロジェクトを炎上させてしまっては、利益は吹き飛びます。 プロジェクトに関わるメンバそれぞれがきちんと仕事をして、きちんと納品することということは、プロとしては当たり前ですが、なかなか簡単ではないことも事実です。ただ、これがきちんと出来ないと、自社サービス開発をするための前提になる時間・利益を確保出来ないことになります。そのため、自分自身含め、全員のクオリティを高め、ここの精度を上げていくことは最重要事項です。 ヴェルクでは、これに対するアプローチとして、受託開発と自社サービス開発の両立を目指して、何年もかけて、継続的にレベルアップするように取り組んでいます。 これについては、以前書いた「起業して3年でやってきたこと」に詳しく書いています。

マネジメントコストを最小化

「マネジメントコストの最小化」というとなんだか教科書に載ってそうな言い方ですが、これは非常に重要だと思っています。 例えば、起業して3年ほどは、ほとんどの案件に僕が関わっていました。これを他のメンバーの成長と合わせて少しずつ割合を減らしています。ただ、それでクオリティを落としてしまっては本末転倒です。 そのための重要なキーワードが「リスク感覚の一致」です。 多い時で10以上の案件を見てたりすると、1つ1つの細かい報告を聞いていたらそれだけで1日終わってしまいます。そこで、その報告の頻度を最小化しつつ、リスクを見逃さないように、メンバーとリスク感覚を合わせていきます。 そうすることで、定例的な報告がなくて、メンバーが「危ないな」「これは早めに相談した方がいいな」と思った時に、適切なタイミングで相談してくれるようになります。このタイミングが早すぎるとこちらが面倒で、遅いとリスクです。ちなみに、僕が本気で怒る場合は、「遅すぎる時」ですね、たぶん。 もちろん一発でうまくいくようなものではなく、何年もかけて合わせていきます。 こうすることで、僕自身の時間を作れるのと、他のメンバも不要な報告が減り時間ができます。また、早い段階で自分で課題に気づき潰せるようになり、結果的に、安定した進捗に繋がりました。 余談ですが、個人的には「プロジェクトが全く問題なく進む」というのは稀だと思っています。システム開発の仕事は問題解決の連続です。そのため、「問題の察知力と解決力」を上げていくのが王道で、これを鍛えるためには、実践で感覚を磨いていくしかないと思います。そして、「リスク感覚の一致」という取り組みの中で、これが磨かれていっているように思います。結果論ですが。

まとめ

うちの場合、6人しかしないので、僕自身がすべて見ることができますし、だからこそできることかもしれませんが、経営・営業・現場の全てにおいて時間を作る取り組みをすることと、受託と自社のバランスを意識した進め方を追求することが重要だと思います。どれか1つだけで頑張っても難しいと思います。 また、一朝一夕にできることではなく、スキル・意識ともに継続していくことで身につくものだし、トライ＆エラーでバランスを見つけていくものだと思っています。 うちは現在4期目ですが、3期目・4期目でようやく形になってきた気がします。

リーンスタートアップが広く知られるようになったこともあり、新しく製品・サービスを作るにあたって、プロトタイプを作って検証するところから始める、という進め方は、最近は多く採用されるようになってきているかと思います。 うちの会社でも、基本的にプロトタイプを作るようにしています。 ただ、プロトタイプを作るにあたって、ペーパープロトタイプなのか実際に動くものにするのか、どのくらい時間をかけてどの程度作るのか、悩ましいところです。

個人的に「実際に作ってみないとわからない」派

個人的には「実際に作ってみないとわからない」と思っているので、出来る限り、実際に動くものを作るようにしています。ただ、当然ながらプロトタイプに時間をかけすぎては本末転倒なので、かけていい時間は数日〜1週間程度だと思っています。 例えば先日リリースした「board」というバックオフィス業務・経営管理システムの場合、既存の見積書・請求書発行サービスを使って感じた違和感・課題について検証するため、3日でコンセプトを確認するためのプロトタイプを作りました。 このプロトタイプは、紙芝居ではなく実際にDBを含めちゃんと登録処理までできるもので、コア機能部分の一連の操作をできるようにしています。 ＊もちろん実装は甘く雑で、最低限の動作しかしないものです。 実は、この時点でイマイチしっくりこなかったので、ソース・設計思想を全て破棄してゼロから考えなおしたのですが、実際に業務を回すイメージで操作してみて初めて気づいたため、ペーパープロトタイプでは気づけなかったかなと思っています。 プロトタイプのソースは捨てる前提であれば、スピード重視で開発できますし、ソースの負の遺産を引きずることもないので、割りきって開発ができます。 「何を検証するか」を明確にしておくことが非常に大事で、これがはっきりさせつつ、ソースの綺麗さを割りきってしまえば、1週間もあればそれなりに作れると思います。それによって、一歩目の間違えに気づけるのであれば、1週間程度の時間をかけても十分有益だと思います。

ただし、常に「実際に動くものを作るべき」とは思わない

前述の例は、「描いているコンセプトが業務にフィットするか」を検証したかったため、実際に動くものを使って業務を回してみる、ということが非常に大事でした。 逆に、画面上の配置の検討などは、ペーパープロトタイプの方が良いと思っています。UI部分を実際に作るとなると、意外と細かいところで時間がかかったりしますし、ペーパープロトタイプでも十分検証できるように思います。 そのため、前述のboardでも、UI部分はかなり手書きで色々と案を書いていました。

いずれにせよ「先に頭で考えない」ことが重要

先日正式リリースした「board」というバックオフィス業務・経営管理システムを開発していた中で、「2割のニーズのために8割の人の使いやすさを落とさない」という方針を強く意識していて、これが結構良いなと思うので紹介したいと思います。 ちなみに、2割・8割というのはイメージなので、厳密に調査して2割というわけではないです。

業務システムにありがちな大量の検索条件

新卒で入った会社が基幹システムを作っていた会社だった経緯もあり、これまで多くの業務システムを見てきました。そのほとんどにおいて、検索画面で、使うのか使わないのかわからないような大量の検索条件がありました。また、入力項目も膨大にあり、どこで誰が使うのだかわからないような項目がたくさんあったりします。 もちろん、検索条件が多かったり入力項目が多い方が、細かいニーズに対応できるのですが、そのために、ごちゃごちゃとした印象になり、また使いたいものがすぐに見つからないなど、細かいニーズが必要ない人にとっては使いにくいものになってしまいます。 Web系のサービスの場合、非常にシンプルなものが多いです。もっともそれはそれで不十分なケースもありますが、業務システムの場合、一般的に、ごちゃごちゃしすぎるなと感じていました。 boardは業務システムの部類になるわけですが、同じようになってしまわないように、「2割のニーズのために8割の人の使いやすさを落とさない」という基準を作りました。

「シンプル」だけだとニーズを満たせない

しかし一方で、シンプルすぎると、そもそも業務を進める上で支障が出てきてしまいます。 シンプルなシステムはぱっと見はすごく印象がいいのですが、いざ使ってみると、「あれ、これできないの？」ということになりがちです。特に業務システムの場合、業務上必要なことはできないと話にならず、サービスとして提供する以上、ある程度の業務の幅をカバーする必要があります。 そのため、単純に項目を減らしてシンプルにすれば良い、というわけでもなく、わかりやすさを維持できるのであれば、可能な限り色々できた方がよいと考えています。 そのため、「シンプルに作る」ではなく「8割の人の使いやすさを落とさない」なのです。

無視できないが全員が必要としないニーズ

一番扱いが難しいのがこれです。 boardの場合、「窓付き封筒対応」がまさにこれでした。 元々うちの会社では窓付き封筒は使っていなかったので最初は全く頭になかったのですが、β版をリリースしてから、一番要望が多かったのが窓付き封筒対応でした。 「そんなに窓付き封筒って使われてるのか？」と思い、知り合いの会社に聞いてみたところ、使っていない会社が多いものの、それなりの割合で窓付き封筒を使っている会社があり、機能としては必要という感じでした。 「窓付き封筒」に対応したレイアウトは郵送時は良いですが、PDFでメールする場合などは不要なので、請求書などの出力都度に指定できるようにしたいと思っていました。 しかし、使ってない会社の方が多く、常に表示されているのも邪魔なので、設定でON・OFFできるようにし、「窓付き封筒機能ON」の場合のみ、書類出力時に指定できるようにしました。 プラグインのようなイメージですね。

使いやすさ・わかりやすさを維持しつつ機能を拡張するということ

5月からベータ版を公開してきた新サービス「board」が本日（8/20）に正式リリースしたので、起業してこれまで感じてきたバックオフィス業務・経営管理の課題や、そこからboardの開発に至った経緯などを書きたいと思います。

月末のストレス

受託開発の仕事はなにかと月末納品が多いため、月末は納品に向けた最後の追い込みという感じで忙しいことが多いです。しかし、本業ではない総務・経理系の仕事も月末から月初に重なります。 月末に近くなると、まず各案件の納品状況を確認し、請求書を発行して大丈夫か確認します。そして納品書・請求書を作成し、印刷・捺印し、封筒に入れて切手を貼って郵送します。PDFでOKなお客さんはPDFをメールします。当然全て同じタイミングで処理できるとは限らないので、案件ごとにステータス管理し、全て請求書発行済になるまで気にかけておきます。 支払もやはり同じように月末に重なります。届いた請求書を確認し振り込みます。 その他、みんなの経費精算等を取りまとめて、月次の会計資料として税理士さんに送ります。 1つ1つのことがすごく時間がかかるというわけではないのですが、忙しい月末に、数時間取られることは痛いですし、何よりもストレスでした。「なんでこの忙しい時に、封筒に入れて切手貼ってるんだよ。」って思ってました。 起業してすぐに総務のスタッフがいるケースは少ないと思うので、これらは社長の仕事であるケースが多いのではないかなと思います。 「こんなことをやるために起業したんじゃないんだけどなあ」と思いつつ・・・。

キャッシュフローの不安

社員を雇っている場合、給与の遅配は絶対にやってはいけないので、とにかくキャッシュフローが一番重要です。 受託開発の場合、納品基準が一般的なため、小さめの案件だとしても、受注してから入金まで数ヶ月はかかります。そのため、例え仕事に困っていない状況だとしても、キャッシュフローが悪化するケースはあります。 そのため、特に1年目は、常にキャッシュフローを気にしていました。 毎月、月次の処理が終わった頃に、Excelでキャッシュフローのシミュレーションをします。受注済みの案件に加え、見込案件を確度ごとに分けてキャッシュフローを確認し、キャッシュ残高は問題ないか、危ないタイミングはいつ頃か、さらに仕事を取りにいった方がよいか、どのタイミングでどういう規模の案件が欲しいかなど、キャッシュフロー予測を元に考えていました。

Excel管理の限界

案件一覧・見積書や請求書などの書類・キャッシュフローの予測などをExcelで管理していましたが、案件が増えてくると、Excel管理だと厳しくなってきます。 本来、案件一覧も各種書類もキャッシュフローも連動しているべきものですが、Excelなので当然連動はしておらず、手運用が非常に多いため、間違いも発生しやすいし、とにかく面倒だったりします。 そこで何度か見積書・請求書発行サービスを検討したことはあったのですが、レポート機能がかなり貧弱で、今までやってきたExcel管理の方がよっぽどちゃんと出来ていたため、そのままずるずるとExcelシステムで3年経ってしましました。 しかし、起業して3年目も後半になり、毎月の請求書も増え、また自分の中の意識としても、「本来自分がやらないといけない仕事にもっとシフトすべき」という考えが強くなってきました。 よく「スタートアップの社長は雑用係」なんて言われたりしますが、それを受け入れすぎてしまっていたなあと。「自分が頑張ればいいので、ここの改善は後回し。」って思ってしまっていました。

いくつかのWebサービスで仮運用してみた

とにかく自分自身を総務・経理業務から可能な限り開放しようと思い、色々なウェブサービスを本格的に試してみることにしました。 うちの場合、会計は税理士さんに記帳も含めてお願いしていたので、会計システムは対象から外し、会計に行く前の見積もり・請求・売上見込・キャッシュフロー予測などを中心に探すことにしました。 実際にいくつかを3ヶ月ほど仮運用してみたのですが、何か違和感があり、逆に「なんでだろう？経営上必要なことについて、自分の感覚がずれている？」としばらく悩んでました・・・。 実際に使っていくうちに、自分の求めているものがだいぶクリアになってきたので、整理してみました。 ・簡単に見積書や請求書などの各種書類が作成できること（入力・操作の手間は少なければ少ない方がいい） ・実際の業務に実態にあった使い方ができること（送付状とセットで印刷できたり、分割請求などもあるので案件という単位で管理できるなど） ・見込み案件の確度ごとに売上予測を出せること（"確度ごと"が非常に重要） ・簡易的でいいのでキャッシュフローのシミュレーションができること（会計は"過去"なので、"未来"を予測するもの）

汎用性を高めると業務へのフィット感は低下する

既存の見積書・請求書発行サービスを使ってみて気づいたのは、どれも「汎用性」を重視している点。そのため、見積書や請求書を作成する「機能」を提供するサービスになっている感じでした。 それはそれでもちろんアリだと思います。ただ、僕が求めていたのは、「業務」を効率化し、適切な経営判断を助けるもの。 「業務」はビジネスモデルが異なれば変わってきますし、見るべき数字は当然違います。汎用性を求めれば、当然業務へのフィット感は低下します。 経営者として必要としていることは「見積書や請求書の作成」ではないんだなということを確信しました。

ないなら作ろう

世の中にないなら作ってしまおう。 元々、新卒でフューチャーアーキテクトに入った経験上、業務系のシステムは得意とする分野でした。しかも自分で経理・総務・経営をやっているので、実務もしっかりわかっており、結構いいものになるのではないかなと。 受託ビジネスをしている会社であれば、ビジネスモデルや商習慣は同じなので、基本的にはニーズは同じはず。 元々、Excelで管理していた仕組み自体、税理士さんから「そのExcel、欲しいくらい良く出来てる」と言われていたので、それを形にしよう。それによって、同じようにスタートアップで苦労している人たちの少しでも助けになるのではないかと。 そして、単に機能を作るだけでなく、「業務へのフィット感」を最大限追求したいと思い、プロトタイプから何度も試行錯誤し大幅な作り直しを経て今の形になりました。 これについては「新サービスのα版までに2.5回作りなおした話〜作って検証することの大事さ」で詳しく書いています。

boardが目指しているもの

個人的には、「こうすればうまくいく」的な方法論は好きではなく、プロジェクトはそんなに単純な話ではないと思っています。もちろん、最低限の知識としての方法論は必要ですが、それが解ではないかなと。 そこで、今回、僕が気をつけているポイントを書いてみたいと思います。

プロジェクト開始時の整地

ヴェルクでは、僕がプロマネに入っているプロジェクトにおいて、事細かに進捗を管理したりメンバに報告してもらったりはしていません。そんな時間がないという事情もありますが。お客さんとの窓口以外は基本的にメンバーに任せています。 ただ、任せる前に必ず「整地」をするようにしています。 お客さんとの関係や意思疎通、技術的な課題や難易度が高いもの、要件がぶれそうなところや膨らみそうな点を整理しておきます。もちろんメンバーに任せる時点で全て解決していれば良いのですが、そうもいかないので、これらの懸念を共有しておきます。 これらの意識を合わせた上で、プロジェクトをスタートします。

お客さんに合わせた柔軟性

ウォーターフォールなのかアジャイルなのかとか。正直なところ、個人的にはどっちでもいいと思っています。お客さんの状況にあっている方法でやるべきです。 自社サービスの開発をする時はアジャイルでやっていますが、受託開発の場合は、契約的な課題があったり、お客さん側の都合などもあり、必ずしもこちらが望む方法でできるとは限りません。 ウォーターフォールもアジャイルも、単なる手段であって目的ではないです。 そのため、「アジャイルだったらうまくいく」というのは、システム開発のプロとしてダメかなと思っています。お客さんの目的はアジャイルで進めることではなく、何かしらのシステムを完成させることなので。 全ての状況において万能な進め方はないと考えています。そのため、お客さんやプロジェクトの状況に合わせて最適な方法を提案・実践し、状況に応じて柔軟に対応していける「引出しの数」がプロマネとしては求められると思っています。

メンバーの力量と任せる範囲

プロマネの仕事は、メンバーのアサインで半分以上は終わっていると思っています。それくらい大事です。数合わせではないです。もっとも、うちの場合は人数が少ないので、あまりアサインの選択肢はないですが・・・。 どのメンバーにどういう役割を果たしてもらうか。単に人数を揃えるためのアサインなど意味がありません。 プロジェクトの難易度に応じて、誰にどこをどこまで任せるのかを考えてアサインし、そのメンバーのパフォーマンスに応じた結果を想像するようにしています。例えば、パフォーマンスが悪かった場合、平均的だった場合、良かった場合などのパターンで。 常にベストなパフォーマンスが出せるのが一番ですが、人間そうもいかないので、ある程度のブレを想定して、「パフォーマンスが悪かった場合」でのリカバリプランを考えておきます。

リスク感覚の一致

このブログでも度々書いていますが、「リスク感覚の一致」は非常に大事だと思っています。メンバーから適切なタイミングで適切な内容のアラートが上がれば、そうそう大きな問題に発展することはありません。 ただ、これは、定量的なものではないため、仕事をしていく中で、「アラートが早すぎ。もう少し考えてから」とか「アラート遅すぎ」などの指摘を繰り返して調整していきます。 これを繰り返していくことで、メンバーとのリスク感覚が一致してきて、適切なタイミングで適切なアラートが上がってくるようになります。 基本的に全く問題なく進むことは皆無だと思っています。プロジェクトは問題解決の連続です。ただ、その問題が大きくならないうちに潰せれば、それほど難易度が上がることはないはずです。そのため、このリスク感覚の一致をとても大事にしています。

説明できないことをやらない

これは個人的にすごく大事にしているスタンスで、メンバーにも同じことを求めています。 「なんでこうしたのか？」という問いに対して、きちんとした理由があるかどうか。 仕事をしている中で、個人レベルでも日々判断をするシーンがあります。その判断が、なんとなくだったり、人に説明できるような理由がなかったりするのはダメだと思っています。 判断が常に正しいとは限りません。判断が正解だったかどうかではなく、きちんと説明できるかどうか。これを自問することで、結果的に判断の精度が上がると思っています。 最近は、特に問題ないのでうちのメンバーにあまりこの問いをしなくなりましたが、昔は、「なんで？」「それお客さんに説明できる？」ってよく聞いてました。本人たちはそれを認識しているかわからないけど。そうやって、自然と仕事の会話の中で身につけていけるのがベストではないかなと思います。

形式的な報告ではなく実際の課題

よく「進捗○%」という報告をするのを見かけたりしますが、あまり好きではありません。数字の基準が曖昧だし、メンバーごとに感覚は違うのでバラつきはあるし、数字の魔力で正しい状況を把握できない可能性が高いです。 もちろん、ざっくりと把握するには良いですし、お客さんの報告で求められるケースはあります。そのため、僕自身も使うことはありますが、本質的な判断では使わないようにしています。 大事なのは、そのタスクが ・予定通り終わるのか終わらないのか ・終わらない場合はいつ終わるのか、もしくは先が見えていないのか ・遅れている場合はなにか課題があるのか という点です。 もちろん1つ1つのタスクについて細かい報告は必要ないので、重要な点についてのみ上記の点が共有できていれば十分だと思っています。

重要なポイントを極端に重み付け

受託開発をやっている会社にとって、マーケティングは大きなテーマではないかと思います。 同じような受託開発をやっている会社が非常に多くあること、また、お客さんの立場から見て、システム開発という形がないものを発注するにあたって、全く知らない会社やブランド力がない会社には頼みにくいのは当然で、受託開発をやっている会社からすると、新規のお客さんを獲得することは大きな課題です。 そのため、これまでの繋がりや紹介などでの受注が多いのではないでしょうか。 ヴェルクは現在4年目ですが、1〜2年目は、ほぼこれまでの繋がりや紹介で仕事を頂いていました。 もちろんそれ自体は悪いことではないですが、それでずっと食べていけるのかというと疑問ですし、会社としては、自力で新規顧客を獲得できないと危険だなと感じていました。 そこで、今回は、この課題に対して、ヴェルクで取り組んでいることを時系列で書きたいと思います。 ちなみに、マーケティング分野は全然専門ではないので、あくまで、エンジニアが自社のマーケティングに取り組んでいること、という位置づけでお読みください。

1〜2年目の失敗：プロモーションの前にマーケティングが必要

SEO・広告などはプロモーションの領域だと考えています。認知してもらわないと受注できないのでプロモーションは大事ですが、その前に、マーケティング・ブランディングができている必要があります。 この順序が逆だと、効果が出にくいと思います。 1〜2年目の頃、「何でもできます」ではダメだと思い、得意な分野であった「AWS」と「スマホアプリ」を全面に打ち出すことにしてプロモーションしてみましたが、明確な効果は出せませんでした。例えば以下のようなことをしてみました。 イベントのロゴスポンサーをしてみる AWSをメインで使っていたこともあり、AWS関連のイベントでロゴスポンサーをしてみたのですが、これは特に効果はありませんでした。 ロゴスポンサー自体がダメなのではなく、出してどうしたいのか、そもそもそのロゴを見てサイトにアクセスしてきた人向けのメッセージが準備出来ているのかなど。 要するにスポンサーというのは露出の機会を増やす方法であり、露出した結果、見に来てくれた人に「こういう製品があります」「ヴェルクはこういう会社です」というのが伝わる準備ができていませんでした。 マーケティング・ブランディングを考える前に、プロモーションをやってしまった形です。 営業代行を頼んでみる ヴェルクでは営業がいないため、プッシュ型の営業が苦手、というかできません。受託開発において、プッシュ型の営業がどの程度効果があるのかの検証も含めて、営業代行の会社に頼んで試してみました。 結果は全くダメ。 完全にパッケージ化された商品があれば売りやすいと思うのですが、受託開発という形のないものを、明確な差別化がない状態でプッシュ型の営業をしても、効率がいいはずもありません。 集客を急ぐのではなく、まずはきちんと土台を築くべき、ということに気づきました。  

マーケティングの第一歩〜自社の特徴と正面から向き合う

マーケティングやブランディングをするにあたって、SEOとか広告とかバズワードとか、安易にそういうものに乗っかるのではなく、まずは自分たちの特徴をしっかり抑えた上で、どういう方法を取るべきかを考えました。 うちの会社は、技術的には特別大きな特徴があるわけではないと思っています。 例えば、有名なスーパーエンジニアがいるとか、流行りのデータマイニングのスペシャリストがいるとか、特殊な技術を持っていてニッチなニーズを掴めるとか、そういう感じではありませんでした。 RubyとかObj-CとかAWSとか、エンジニアが多い、やっている会社が多い領域をメインとしています。そのため、「Rubyできます！」とか「AWS強いです！」とか、そういうものはどこの会社でも言えることで差別化が非常に難しいです。 もちろん、やっている内容を伝える必要はあるので、サイトにはRubyやAWSなどのキーワードは掲載しますが、それでブランディングしようとすべきではないと考えました。 マーケティングとは、売り方を考えることだけを指すのではなく、製品企画・コンセプトの段階からマーケティングを考えていくものだそうです。会社も同じで、どういう会社なのか、どういう強みを持っているのか、会社のマーケティングもそこからです。

ヴェルクのウリを考える

前述のとおり、技術的には大きな差別化になるわけではないですが、受託開発を安定的にまわすことにはそれなりに自信がありました。これはメンバーが必要な技術力を備えているのは当然として、技術力以外を含めた「バランスの良さ」からきていると思っており、打ち出すべき特長はここだと考えました。 ただ、例えば「技術力には自信があります！」とか「コミュニケーション力が高いエンジニア」とか「経験豊富なマネージャ」とか「提案ができるエンジニア」とか、いかようにでも言える言葉を並べたところで、意味は無いだろうなと。 そういう安易に言葉で伝えようとするのではなく、実践して形に表すべきだと考えました。

ウリを形にする

ヴェルクでは、創業時から、受託開発と自社開発の両立を目指していました。これは、「単に自社開発をやりたかった」というのもありますが、受託開発だけやっていると受け身になってしまいがちなことを避け、また自社開発で企画力や自主性を実践の中で身につけ、受託開発に活かすことが狙いです。 こういうコンセプトはこのブログなどで書いてきましたが、口だけでなく、それを形にする必要があります。 1〜2年目はiPhoneアプリを中心に軽めのものを作っていましたが、3年目はもう少し踏み込んで、本格的に事業化を目指して自社製品の開発に取り組みました。 このあたりの話は「起業して3年でやってきたこと」や「受託開発を軸にしながら自社開発を継続するために行っている工夫（時間・お金の話など）」などに詳しく書いています。 要するに、「受託開発と自社製品を両立する」というスタンスを明確にして、それをきちんと結果として残すことで、「ヴェルクはこういう会社です」というのが伝わるようにしようとしました。

"形"を見てお問い合わせ頂く

「受託開発の会社が自社製品で集客できるようになるまでにやったこと（失敗含む・・・）」にも書いた通り、昨年、Pattoという自社製品の集客を頑張ったことが大きいですが、この製品そのものではなく、サイト経由での受託開発の依頼も頂くようになりました。 直接お問い合わせ頂いたお客さまから「サイトを見て、コンセプトに共感して、この会社なら話が合いそうと思った」という主旨のことを何名もの方から言われました。 お問い合わせがものすごく多いかというとまだまだです。そういう意味では、全然知名度も高くないですが、1〜2年目よりは確実に進歩しています。コンセプトを体現することによって、少しずつ、ヴェルクがどういう会社か、ということが伝わるようになってきているように思います。

お金がたくさんあれば、広告をガンガン打ってブランディングするという方法も1つのやり方だと思います。繰り返し見聞きすることで、「知っている会社」になるわけですから。 ただ、ヴェルクではそういうやり方はできません。 身の丈にあったマーケティングを考えた時、会社としてのスタンスを明確にすること、そしてそれをちゃんと形に表すこと。 それがきちんとできていれば、時間はかかりますが、少しずつプラスの方向に向かっていくように思います。 前回の記事同様、急がばまわれ的な話ですが・・・。

受託開発のマーケティングはどういう会社か知ってもらうところから