受託開発の罠

資金調達していない零細 IT 企業を経営していると抜け出せなくなる受託開発の罠ですが、罠にはまるパターンと、そして自分がどんな方法で罠にはまらないように経営しているのか書いていきます。

前提

そもそも受託開発が目的の会社であれば、罠にどっぷりハマって問題はないので、ここでは自社サービスなり自社製品をメインとする会社を前提とします。

経営者が全力で稼いで、社員が自社製品やるパターンや、その逆あったりはここに当てはまりません。当てはまるのは自社製品やりたいけどお金を稼がないといけないといってずるずる行くパターンを受託開発の罠としています。

自転車操業

調達していない零細 IT 企業は基本的に自転車操業になります。会社にお金がないと当たり前ですがキャッシュフローが苦しくなるため、受託開発を行いお金を稼ぐようになります。

受託開発は毎月契約でお金をもらって開発リソースを提供するタイプと、いくらでお願いしますといわれて受けるパターンの2つがあると思います。自社では後者の「いくらでお願いします」が多いですが、両方行っています。

受託開発の罠に一番おちいりやすいのがこの毎月契約で開発リソースを提供するタイプです。なんていったって仕事が終わらない限り毎月お金が淡々と入ってきます。

一度毎月お金が入ってくる経営に慣れてしまうとそこから抜け出すことはできなくなります。

素敵なオフィス、素敵な福利厚生

受託開発は人売に限りなく近いパターンが多いため、人を増やしたりすることで利益を上げることが多いです。

そのため、素敵なオフィスや素敵な福利厚生を見せて人を採用を頑張らなければいけません。当たり前ですがお金かかります。

複数案件の同時平行

最大の罠がこれです。複数案件の同時並行です。受託では 1 人が 1 案件を担当すると当たり前ですがお金が入ってくるのは 1 人分です。であれば2つの案件を受けてリソースを 50% ずつ割り振るという方法で売上を2倍にするという方法があります。

つまり多くの案件を受けてそれらをできるだけ頑張らない方が稼げます。複数案件を受けてできるだけ頑張らないという戦略です。

最悪の戦略ですが、相手が技術に明るくなければ明るくないほどこの技術戦略が取れます。

お金を稼ぐという戦略としては良いですが、一緒に働いている人や顧客にとっては最悪な戦略です。

営業力がありすぎる、またはなさすぎる

営業力がありすぎるとバンバン仕事が取れてしまうので罠から抜けられません。

ただ、実は営業力がなさすぎてもお金を稼ぐためにどんな仕事でも受けることになってしまい、罠にハマります。

自社製品カスタムという受託

説明不要だと思うので省略します。

自社の解決策

零細企業だからこそできている解決策だと思いますし、社員の理解があって成り立っています。

会社に蓄えず社員に蓄える

社員に蓄える事で、会社が儲かっていないときでも耐えられる仕組みを作っています。儲かったら還元を前提としている仕組みです。

1 人 1 案件にできるだけ抑える

難しい場合は曜日を固定するようにしています。A 案件は 月火金、B 案件は水木という感じです。顧客にもオープンにしています。

毎月の給与を少なく抑え、儲かったら還元する

毎月の給与はキャッシュフローを考え低くして、稼げたら賞与でガッツリ還元します。

受託をするときは稼ぐに注力する

稼ぐときは徹底的に稼ぐモードで頑張るという方式です。その分社員にもリターンを与える前提です。

受託をしない時期を作る

自社製品に注力する時期を作ります。最低限の売上だけを上げて稼がない時期です。自社では冬の時代と呼んでいます。 4 年に 1 回くらいのペースでやっています。

自社製品で稼ぐため手を動かし続ける

稼げるかは運ですが、まずは作って世に出さないとダメなので、そこは頑張っています。むしろここがメインなので最大限の労力を投資すべきです。

質素なオフィス、質素な福利厚生

そもそも社員へ還元するべきです。

自分が受託に不向き

これは蛇足ですが、自分が人の欲しいものを作るというのが苦手なので自分自身が積極的に受託開発ができないというのは大きいかもしれません。

Erlang/OTP / 時雨堂 / WebRTC / E2EE

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store