以前からブログで「受託と自社サービスの両立の取り組み」を書いてきましたが、ついに、2017年11月1日にboardの有料アカウントが1000社を突破しました！
1000社突破したらに、これまでの取り組みや現在のスタンスなどの総まとめを書こうと思ったのですが、8月のBPStudyで「受託の会社が調達せずに自社サービスを立ち上げ事業として成立するまでの企画・開発・サポート・マーケティング」という発表をしまして、これらのテーマについては、このスライド以上に書くことがなかったので下記のスライドを見て頂き、ここではそれ以外のことについて書きたいと思います。
BPStudyのスライドは、はてブでもたくさんコメントを頂いていて、「受託メンバーとの兼ね合い」が結構多かった印象でした。
なので、今回は土台になっている、経営や受託とのバランスについて書きたいと思います。
- 経営方針
- ストック売上を増やす
- ほどほどの売上に抑える
- 社員にとっての受託と自社サービスの関係
- 受託と自社サービスのアサインのバランス
- 受託をやっているメンバーに負担をかけない
- 受託を安定して回すための取り組み
- まとめ
経営方針
ヴェルクは受託開発の会社としてスタートして、2017年11月で7期目が終わりました。
現在自分を入れて6名の小さな会社なのですが、人数をどんどんと増やして拡大していくつもりはなく、10人前後を一つの目安と考えています。
元々、何か特定の技術を扱いたいとか、サービスを立ち上げたいとかで起業したのではなく、「この業界の変化は早いので、それに対応していけるチームや環境を作って、自分含め、エンジニアが継続的・安定的に技術に取り組める環境を作りたい」というのが起業のきっかけです。
そのため、当初から上場やバイアウトといったものは全く考えていません。というか、そういう感じでやっているので、投資対象として向かないですね。
僕の経営者としての仕事は、上記を実現するために、
- 短期的には、きちんと利益を出せる受託案件を取ってくること
- 中期的には、経営を安定させる事業を作ること
- それを、社員にはオーバーワークさせず定時で帰ってもらい実現すること
だと思っています。
自分の感覚的には経営者というよりは事業責任者に近くて、経営者っぽいことはあまりやってません。社内で、経営理念とか方針とかそういう話をしたこともないですし・・・。
これらのことに取り組むにあたって、一つの重要なテーマとして考えているのが「労働集約型」からの脱却です。
受託開発は労働集約なので、人数を増やせばある程度それに比例して売上も上がりますが、拡大とともにクオリティの維持が難しく、利益率にも限界があります。
また、小さい会社にとって採用は本当に本当にハードルが高く、しかも人口は減少傾向なので、「人を増やすこと」に依存したモデルは厳しいと感じています。
社内で冗談半分で「10人で利益を10倍にする方法を考えるのが自分の仕事」と言ってたりします。数字は具体的な目標ではなくあくまでイメージですが、2倍とかだと「労働集約型のまま頑張る」という選択肢が残ってしまうので、根本的にビジネスモデルを別で考えないといけない「10倍」にしています。
そのため、ここ3〜4年の僕のミッションは、「中期的に経営を安定させる事業を作って、労働集約型のモデルから脱却すること」で、その一つがboardでした。
ストック売上を増やす
「中期的に経営を安定させる事業を作る」に関連して、僕がずっと社内で言い続けていたのが、「ストック売上を増やす」でした。
受託開発の場合、基本的には「納品」してから請求です。普通に数ヶ月単位で大きな納品がない時期があって、そうするとキャッシュフローが悪化します。
ちなみに、今までで一番預金残高が少なかったのは、起業4ヶ月目に20万という時がありました。その後すぐに入金の予定があったので大丈夫でしたが、キャッシュフローの計算を間違えていないかヒヤヒヤものでした・・・。
そういうリスクを減らすためにも、納品の有無に関わらず月額でお金が入ってきて、売上の座布団になるようなものを増やしていこうという方針です。
最近は、よく「サブスクリプション」という言葉を聞くようになりましたが、当時はそういうことは全然考えておらず、とにかく「売上の座布団を増やしたい」という意識でした。
＊「売上の座布団」という言い方が一般的かわかりませんが、僕はよく使っていて、保守のように、納品有無に関わらず毎月請求するタイプのものを指しています。
とは言え、すぐにそんな事業を作ることはできませんし、そこに賭けて社員にリスクを負わせるわけにはいかないので、まずは堅実に保守を増やしていくことから始めました。
ちなみに、「保守だけ受ける」ということはやらず、保守がある開発案件を優先するというスタンスです。
ただ、保守ばかり増やしていくと、そっちに手が取られて開発案件ができなくなってしまうし、開発者としては面白くないので、そこはバランスよく、また運用保守に手がかからない仕組みにするように気をつけていました。例えば、自動化できるものは自動化したり、運用回避な要件は避けたり、運用上定常的なオペレーションが発生しないようにしたり。
少しずつでも売上の座布団が増えてくれば、納品ベースで稼がないといけない売上は多少下がっていきます。その積み重ねが余力になってくるし、その余力が自社サービス開発の時間を捻出します。
その後は、知り合いの医学生とのコラボで医療系学生向けの解剖学のアプリをレベニューシェアで出したりしつつ、2013年（3期目）に初めての本格的自社製品「Patto」、2014年（4期目）に「board」をリリースと、自社サービスをリリースしていきました。
毎年期末にその期のまとめとして、売上や振り返り、来期の見込みや方針などを社内で話しているのですが、その時の資料を見返してみると、3期目（2013年11月）の終わりに初めて「ストック売上」という言葉を使っていて、4期目（2014年11月）の終わりに「3年後にはストック売上で50%」という目標を掲げていました。
普段具体的な数値目標を上げることはほとんどないのですが、今から思うと、だいぶ思い切った数字ですね。たぶん、全く具体的に考えていなくて漠然と上げた数字です・・・。
で、その3年後というの7期（2017年11月）なのですが、めでたくストック売上は無事50%を超えました。言ってみるもんですね。
ほどほどの売上に抑える
boardとは関係なく起業当初からの取り組みですが、それぞれの給与に応じて「このメンバーの受託での年間売上はこのくらい」みたいな目安が自分の中にあって、基本的にそのラインまでいったら、ある程度受託へのアサインを抑える、というスタンスでやっていました。
そのため、年間を通しての稼働率は平均7割程度で、空いた時間は、技術的な検証だったり、自社のスマホアプリを作ったりしてました。
各メンバーがもう1つ案件できるくらいの稼働率なわけで、その分も受託で埋めた方が利益を出せます。ただ、そうすると、「次」に繋がる取り組みができないので、稼働率は7割程度に抑えるようにしてきました。
例えば、boardの前に「Patto」というスマホアプリ関連の製品をリリースしているのですが、この時は、boardと違って僕ではなく社員がメイン開発者だったので、「最低限上げて欲しい売上を上げた後はそのメンバーは受託から外し、自社製品の開発に注力して、全体として売上が足りなかったら自分が稼ぐ」という形で進めました。
経営者として、もっと売上を上げられるのに抑えるというのは難しいところですが、リソースは有限なので、中期的に考えてどこに時間を割くべきか、ということを考えるようにしています。
ただ、「それほど多くはなくてもボーナスは出せるレベルの売上は維持する」というのも大事にしていて、「稼働率7割」というのは厳密なルールではなく、状況に応じてバランスも重要です。
社員にとっての受託と自社サービスの関係
僕含め、うちの会社はわりと受託が好きな人が多く、よく聞く「受託がツライから自社サービスを」みたいな思いでは全くやっていません。
2年ほど前に、うちの3人のエンジニアそれぞれに、「今後、受託とboardとどっちやりたい？」って聞いたところ、「boardより受託」「どっちでもいい」「boardやりたい」という形できれいに分かれました。
この前のBPStudyの資料のはてブコメントを見ていると、「受託と自社サービスのメンバーが仲悪くならないの？」「受託をやっているメンバーのモチベーションは？」といったコメントがちょいちょいありましたが、意外と社内ではboardの開発は人気ないのですw
そもそもうちの会社は自社サービスをやりたくて集まったメンバーではないですし、boardのような業務系サービスの場合、ほとんどのエンジニアにとっては直接関係しない業務を扱っています。
なので、あるメンバーが「boardで扱っている業務に縁がないので、業務を聞きながらやっていくことになるから受託と大きく変わらないと思ってる」って言ってたりしたのですが、エンジニアにとってはドッグフーディングできるものではないので、この壁は高い気がしています。
とある知り合いの会社で、B・C向けそれぞれのサービスを出しているところで、中のエンジニアには圧倒的にC向けサービスの方が人気あるという話を聞いて、業務系サービスあるあるな気がしています。
また、うちは、数ヶ月〜半年程度で終わる小規模な案件が多く、案件ごとに新しい試みを取り入れやすいので、それを理由に「受託の方が良い」と言っているメンバーもいます。
あと、受託案件で大変な状況になることはほぼないですし、みんなほぼ毎日定時に帰っているので、受託を積極的にやめる理由もないのかなと思います。
受託と自社サービスのアサインのバランス
現状、「受託チーム」「自社サービスチーム」という形ではっきり分かれているわけではなく、「boardも受託案件同様アサイン先の一つ」で、行ったり来たりしています。
もちろん人によって割合は異なり、例えば、「boardより受託が良い」というメンバーはほぼ受託をメインにしています。
唯一「boardをやりたい」と言っているメンバーは一番若手で、まだまだ多くの経験を積んでほしいので、年間を通して半々くらいになるようにしています。
受託でも自社サービスでも仕事の内容は開発なわけで、個人的には「受託」「自社サービス」といった区別ではなく、各個人が、モチベーション高くできる仕事だったり、足りないものを身につけられる仕事だったり、もしくはつまらないけどやらないといけない仕事かもしれないけど、そういったバランスを大事にしている感じです。
受託をやっているメンバーに負担をかけない
自社サービスを開発する上で、自分の中で決めているポリシーとして、「受託をやっているメンバーに負担をかけない」というものがあります。
「受託と自社サービスの両立」というと、どうも受託の利益を食いつぶしながらサービス開発をしている印象を持たれることが多いのですが、その方法をとると、受託側に負担がかかってしまうので長く続きません。
「サービスがリリースできるまで大変だけど頑張ろう！」みたいな感じでメンバーにオーバーワークしてもらうのは嫌だし、うちはそういうノリの会社ではないので、受託に食わせてもらいながらサービス開発をするというスタンスはとりませんでした。
余談ですが、起業直後に、昔からお世話になっているとある先輩経営者から、「テンション・勢い・イベントなどの"波"に依存した経営をしていると、次はもっと大きい波が必要になって、結果的に長続きしない組織になってしまう」と言われたのがとても心に残っています。
なので、「自社サービスを開発する」というのをイベントにはせず、淡々と進めていました。
boardの場合は、元々僕の個人プロジェクトから始まって、リリース後1年半ほどまでは、僕も普通に受託をやっていて、自分がいち受託メンバーとして上げなければいけない売上はあげつつ、boardを開発していました。
boardの売上が増えてきたら、徐々に僕が持っている受託案件を減らすという進め方で、boardに関わるコストをboard自体で賄えない時は僕が受託で稼ぐというスタンスでした。
これは、自分自身が経営者で、労働時間の概念があってないようなものなのでできたことですが、たっぷりお金がある状況でない以上、どこかで無理をして捻出しないといけなくて、それを社員にやらせるわけにはいかないので、そこは自分がやったという感じです。
受託を安定して回すための取り組み
受託をやりながら自社サービスを立ち上げるためには、これが基本だと思っています。
受託の会社である以上、受託を安定して回せることが前提になっていて、それができていないうちは、まずは受託の方に力を注いだほうが良いと思っています。
この話をすると「それができれば苦労しない」ってよく言われるのですが、「受託が大変」という状況を解決するための自社サービスではないと思っているので、自分としては、ずっとこの課題に取り組んできました。
まず一番大事なこととして、「適切な価格と適切なスケジュールで受けること」だと思っています。安すぎる受注額だったり、最初からスケジュールが厳しいと、安定して受託を回すのは無理です。
うちの会社は営業がいないので、仕事を取ってくるのは僕か取締役の津久井なのですが、二人ともバリバリ現場でやっていることもあり、見積もりやスケジュールを間違えにくかったり、悪い条件でも受注しようという考えはないので、まずここはクリアできています。
次に仕事の進め方についてです。
僕は、方法論や手法には全くこだわりがなく、うまくいけば何でも良いと思っているし、そもそもメンバ・お客さん・開発するシステムの種類などによって最適な方法は異なると思っています。
基本的には「個人の能力を上げること」が一番重要だと思っていて、そのため、前述した通り、アサインにあたっては「そのメンバーにどういう経験を積んでほしいか」を考えて、受託でもboardでもアサインするようにしています。
この前のBPStudyのはてブのコメントを引用させて頂くのですが、
「オレ」が受託開発にリソースを注ぎまくらなくてもボーナス払える状態っていうのが地味に強みなんじゃなかろうか
というものがあり、まさにこれだと思っています。
うちの会社には、定例も進捗報告も日報も週報もなく、「進捗報告はいらないから、リスクがある時だけ相談して」というスタンスを取っています。
リスクに対するアラートが適切であれば、そうそう大きなトラブルになることはないと思っています。相談する内容を間違えず、早すぎず遅すぎず。これを「リスク感覚の一致」と呼んでいます。
別に社内で「リスク感覚を一致させていこう」という話をしたわけではないのですが、2〜3年かけて、日々の仕事の中で、これを一致させるようにしてきました。
もちろん最初からうまくできたわけではなく、相談が早すぎたり、問題が大きくなってから相談に来たり。
なので、みんなに任せて放置するのではなく、最初は僕がみんなの動向・状況をかなり気にしつつ、危なそうだったらさりげなく軌道修正するようにしていました。
みんなからしても定例や進捗報告は面倒ですし、とはいえ、そういったものがないと、アラートのタイミングをミスると大変になるので、時間とともにその精度が向上していきました。
もちろん、これは一人ひとりの状況がよく見えている小さい組織だからこそできる方法だと思っています。また、最悪、自分がリカバリに入れば良いと思っていて、リカバリできるギリギリのところまでは任せておこうという感じです。
マネジメント手法は正解があるわけではなく、規模・メンバーの特性などに応じて、最適な方法を考えるべきだと思っているので、自分自身やメンバーの特性、会社の規模などを踏まえて、こういうスタンスに辿り着きました。
結果的に、この取り組みによって、マネジメントコスト・コミュニケーションコストが極めて低いチームになり、僕がそこに割く時間が非常に小さくなりました。
中途で入ってきたとあるメンバーが、「うちの会社のエンジニアって、みんなそれぞれの立場・レベルでの当たり前を当たり前にやっていて、それがすごいし、だから最低限のマネジメントでうまく回っている」という表現をしていたのですが、確かになあと思ったことがありました。
それが納品後の手離れの良さにも繋がっていて、結果的に「余裕」を生んでいます。
小さい受託の会社にとって、創業社長が現場にがっつり入らなくても回るようにするというのは一つの大きな壁で、最初の3年かけてそれができたのが、board開発の土台となっていると思っています。
まとめ
すごく高利益率の仕事をしているのであれば別ですが、普通に受託をやっていると、自社サービスを開発している時間はなかなか確保できないと思います。 うちの場合、決して安い単価で低利益の仕事をしているわけではありませんでしたが、ビジネス構造としては普通の受託の会社でしたので、時間的資金的に、自社サービスを開発するための十分な余裕があるわけではありませんでした。
そのため、「売上の座布団」を作っていって、少しずつ余裕を作るという取り組みを続けてきていたのは、ひとつの重要な取り組みだったなと思います。
急がば回れで時間をかけてやってきているので、「今すぐサービスを立ち上げたい、軌道に乗せたい」というケースにおいては不向きな進め方ですが、受託をやっていると直近の売上は立てられるので、特にtoBであれば、じっくり着実にやっていくという方法もありなんじゃないかなと思っています。
現在、boardがこれだけの規模になってきても、うちの会社では、どこか「案件の一つ」みたいな雰囲気があって、僕自身も、各メンバーのスキルや経験、受託の営業状況、boardの開発予定などを考えて、どういうアサインが良いかというのを考えています。
経営は「ヒト・モノ・カネ」といいますが、残念ながら「カネ」は潤沢にあるわけではないので、「ヒト・モノ」が重要になります。
ただ、小さい会社にとって、採用はほんとに難しく、ずっと課題です。なので、今いるメンバーを大事にしたいし、もっと成長するための機会・環境を継続的に用意したいと思っています。
そういうものの積み重ねが、受託をやりながらboardを生み出せる土台になったんじゃないかなあと思っています。
