受託開発を軸にしながら自社開発を継続するために行っている工夫（時間・お金の話など）

ヴェルクでは、受託開発を軸にしながら、自社開発を行っていくスタンスで仕事をしています。その狙いや取り組みについては、以前書いた「起業して3年でやってきたこと」や「受託開発脳から自社開発脳へ切り替えの7つの壁」などに詳しく書いているので、ご参考までに。

今回は、この取り組みを維持するために行っている工夫について書きたいと思います。

受託開発できちんと収益を上げる体制を確立する

ヴェルクはVCから出資を受けているわけではないため、自社開発を行うための資金は自分たちで稼ぐ必要があります。非常にシンプルで、「稼げなければ好きはものは作れない。」基本的にこのスタンスです。

そのため、まずきちんと利益を確保できる体制を確立・維持に全力で取り組みます。

とは言え、受託開発は労働集約型なので、売上を上げるためには人数を増やさないといけないですし、人数を増やすとクオリティの維持が難しく、クオリティが下がればマネジメントコストがかさみます。また、よほど特殊な技術でない限り、相場感からかけ離れた単価設定は難しいので、一人があげられる売上にも限界があります。

元々拡大思考はないので、できるだけ少数のチームを維持しつつ、この課題に対して取り組んでいます。

受託開発のコストを分析する

受託開発において、人件費は削ることができないコストです。ここを削ろうとするべきではなく、むしろ価値があるアウトプットを出せる人材にはどんどん払うべきで、それ以外の無駄を削るべきと考えています。

例えば
・要件が膨らんでその分請求できないことによる利益圧迫（プロマネの問題）
・マネージャによる進捗管理などのルーチンなマネジメントコスト（マネージャの仕事のやり方の問題）
・納期がずれたりトラブルが収束しないなどによる利益圧迫（品質の問題）
・案件の間が空いてしまう（営業の問題）
などなど。

逆にこれらがなければ、安定して利益をあげられるのが受託開発だと思います。そのため、これらを発生させないことが安定した受託開発、そして、自社開発への時間・予算を作る大前提だと考えています。

マネージャーの仕事を見なおして無駄な管理コストを減らす

マネージャーによる管理工数を最大限に減らすようにしています。コストの高いマネージャーが、進捗管理など、何も生み出さないタスクをするのはもったいないと考えています。本来そこはマネージャーに求められる仕事ではないはずですし、そのコストはお客さまが負担していることになります。

そこで、以下のポイントに力を入れています。

・プロジェクト開始時に整地をしておく

お客さんとの関係や意思疎通、技術的な課題やネックになりそうな点、要件がぶれそう・膨らみそうな点を整理しておきます。ある程度、プロジェクトの状況を整地した状態でメンバーに引き渡します。あとは、各メンバーの力量がわかっていれば、おおよそどのタイミングで何を気にしないといけないのかが見えてくるはずです。

逆に、よく聞くケースで、プロジェクトの現場がわかっていない営業さんが受注最優先で取ってきてスタートしてしまうケースは、この整地ができていないケースだと思います。


・メンバーとのリスク感覚を一致させる

これは一朝一夕にできることではないですが、メンバーと長く仕事をしていく中で、リスク感覚を一致させるように取り組んできました。このリスク感覚が一致していると、アラートや相談のタイミングを大きく間違わなくなり、これが間違わなければ、リスクが大きくなる前に適切に対応ができます。

以上の2点がきちんとすることで、事細かに進捗管理せずとも、大きな問題なく進めることができています。

ちなみに、今のメンバーの大半は起業前も含め5年以上一緒に仕事をしており、毎年少しずつリスク感覚を合わせてきました。そういう下地があってこそできることだと思うので、例えば新しいメンバーが入ってきた場合は、当然また違うスタンスが必要です。

ただ、こういう取り組みを継続してやることで、エンジニアがマネージャーの真似事をすることもなく、マネージャーがルーチンな管理業務をすることもなく、チームとして上手く機能するようになると思います。

問題なく進む前提ではなく、問題に早く気づき潰す

受託開発において、最初から最後まで全く問題がなく進むということはなかなかないと思います。そのため、早めにリスクに気づき、適切なタイミングでアラートを上げられれば、問題が大きくなる前に潰すことができます。

リスク感覚の一致は、単にマネジメントコストを抑えるだけでなく、問題が大きくなる前に潰すこともでき、結果的に、プロジェクトの進行もスムーズになります。

忙しいプロジェクト後半にこそ次の案件の準備

順調にプロジェクトが進められている前提ですが、プロジェクトが後半に差し掛かった頃に、次の案件の獲得に動くようにしています。案件の間が空いてしまうと、その分のリカバリが非常に大変で、経営的には一番痛いです。そのため、僕の一番の仕事はここの調整です。

もちろんうまく次の仕事が取れるとは限らないので、そこは僕が調整弁の役割をして、何でもいいので細かい仕事を取ってきて、少しでも売上を上げるようにしています。自分で開発ができると便利な点ですが、力技なことは否めず、まだまだ改善が必要な点です。

受託での安定した利益の確保と進捗が自社開発の源泉

これらの取り組みの結果として、自社開発を行うことができる資金や時間の確保をしています。

なんだそんなことか、と思うかもしれませんが、大規模な資金調達をしていない以上、継続的・安定的に利益を上げる基盤づくりは不可欠です。

一見遠回りに見えますが、単に流行りの開発手法やプロジェクトマネジメント手法に乗っかるのではなく、プロジェクトの問題の本質を考え、メンバーがその問題に対応できるスキルを身につけることが、結果的に自社開発をするための余力を作っていくのではないかと思います。

もちろん、全てのプロジェクトで最初から最後まで問題ゼロかいうと、当然そういうケースばかりではありません。色々な外的要因も含め、受託開発の仕事は、そんなに簡単な仕事ではないと思っています。ただ、この取り組みを継続することで、確実に問題は減り、安定してきています。

ちなみに、ヴェルクでは、1〜2年目は主にiPhoneアプリなどの小粒なもの、3年目はスマホアプリCMS「Patto」、4年目は受託ビジネス特化型バックオフィス業務・経営管理システム「board」という形で、少しずつ自社開発の規模を大きくできています。

特に今年の「board」は、「受託ベンチャーのバックオフィス業務」を取り扱っているので、僕がメインでやる必要がありました。これができたのは、これまでの3年間で、僕ががっつりと他の案件に入らなくても、問題なく進められるようになったことが非常に大きかったです。

急がばまわれですね。


幸い、うちのメンバーはずっと一緒に仕事をしてくれているので出来たことですが、資金調達せずに受託開発をやりながら自社開発をするのであれば、このくらいじっくり取り組んでもいいのではないかなと思います。

今後取り組もうと思っていること

「何でも自前主義」をやめようと思っています。少ない人数で受託開発も自社開発も回すことを考えた場合、メインでない業務に時間を取られるのを極力避けるべきだと思っています。

例えば、社内で管理するシステムを極力減らすため、外部のサービスを積極的に使う方針に切り替えました。例えば、これまで自分たちでEC2上に立てていたredmineやgitは、backlogとgithubへ切り替えています。

また、自分たちとしてノウハウが足りていないインフラ周りの自動化などはサポートをお願いすることにしました。

いずれも会社の規模がもう少し大きければ社内でやってもいいと思いますが、少ない人数で片手間でやるのは時間がもったいないですし中途半端になるので、自分たちの時間の使い方をもっと明確に選択すべきかなと考えています。

もちろんキャッシュアウトは増えるので、1年目に同じことは出来ませんでしたが、やはりこれも受託開発での安定的な基盤をベースに今はできるようになりました。

ですので、やっぱり急がばまわれですね。