SES・受託開発・自社サービスのどれを選ぶべきか


こんにちは。@yohira_devです。

今回はテスト運用も兼ねてnoteで記事を書いてみることにしました。

なぜこの記事を書こうと思ったのか?

TwitterなどのSNSでよくIT業界の闇について語られることがあります。特にSESという形態は槍玉に挙げられがちなのですが、見ていると個人的な善悪論というか感情論というか、イメージだけで語られているな、と思うことが多々あるわけです。

ビジネスでやっているわけですからSESをやることで儲かる人がいるし、受託をやることで儲かる人がいるし、自社サービスをやることで儲かる人がいるわけです。

しかし、そういったところの構造に踏み込まずに感情論で「IT業界の闇がどうのこうの」「この現場は糞だった、なぜならSESだったから」とか書かれていて、しかもそれが共感を集めてしまっている傾向に違和感を感じました、

なんというか、エンジニア名乗るならもうちょっと物事を構造化して考える癖をつけてほしいと思うことがありましたので、自分の思考の整理を兼ねてこの記事を書きました。

前提

やや大雑把なくくりだと思う人もいるかもしれませんが、IT業界におけるビジネスモデルを

・SES

・受託開発

・自社サービス

に大別して進めていきたいと思います。

SESは準委任契約と呼ばれる時間あたりの稼働に対してお金をいただく形、受託開発は請負契約と呼ばれる成果物に対してお金をいただく形、自社サービスは文字通り自社のサービスもしくは商品を売ることによってお金を頂く形を想定します。

ちなみに、「請負契約なのに常駐させられてるんだが?」みたいなのは普通にアウトなのでSNSで愚痴るのではなく然るべきところに報告をあげてください。

はじめに。事業を継続させる条件とは

まぁ、いろいろあるのですがざっくりまとめてしまうと以下の2つの数式が成り立つかどうかです。これはSES・受託・自社サービスといった事業形態に依存しない普遍的な式です。

(売上 - 経費) * (税率) - (生活費) > 0

(口座残高) - (その月に支払うべき債務) > 0

1つ目の式はどんな事業形態を選択するにしても、「最終的には(※)」この式が成り立つようにしなければなりません。飯食わないと生きていけないです。人を雇っている場合、人数分この数式を成立させる必要があります。

2つ目の式は「不渡りしない条件」です。一年後に1000万入ってくるとしても、今口座に100万しかなくて来月に200万の支払いがあったら支払うことができなくなってしまいます。この条件を守るために、いつ売上が確定していつ売上が入金されるのか、「入金スパン」というのは非常に大事になってきます。

※厳密には、経費を「必要経費」と「未来に対する投資」に分解したり、未来の売上や未来の生活費などはインフレ率を考慮した割引計算をしないといけないのですが、本記事の趣旨とはズレてしまうので解説は省きます。

SESのメリット1.ゼロからでも即売上を立てられる

自分で仕事が取れるに越したことはないですが、最近だとフリーランスの仕事を仲介してくれる登録制のエージェントが多数出てきています。

彼らもビジネスでやっているのでマージンは抜かれますし「それ多重下請けじゃん!」みたいなことを周りから言われるかもしれませんが、とにかく使ってしまえばゼロからでも即まとまった売上を得ることができます。

また、最近のエンジニアの単価相場ですと、マージンを抜かれることを前提にしても会社に雇用契約で雇われるよりも金額は高くなります。

もちろん手元に残る金額だけでフリーランスを選ぶのは短絡的思考であって、サラリーマンとフリーランスの雇用の安定性や保険・信用・諸制度の違いについて各個人が自分なりに検討を重ねた上で意思決定をすべきものですが、これらに関しては今回言及しません。

※再度申し上げますが、自分の力で仕事が取れるに越したことはないです。

SESのメリット2.入金サイクルが早い

準委任契約の場合、「当月の稼働報告を提出後、一ヶ月後に払い込み」という契約が多いです。(※契約により変動はあります)

後述する納品・検品後に支払いが発生する請負契約や、サービスが軌道に乗るまで時間がかかる自社開発と比べると入金サイクルが圧倒的に早く、資金繰りは3つのやり方の中で一番簡単です。

SESのメリット3.瑕疵担保責任がない

準委任契約は、仕事の完成ではなく、一定の事務処理行為を行うことを約する契約です。なので法的には仕事の完成義務(瑕疵担保責任)はないです。

「SESのエンジニアは成果にコミットしないのか」という的はずれな批判を受けることがありますがそういう問題ではないです。

「自分のせいでサーバー落としたから残業して復旧させた」とかそういうレベルの話ではないんですよ。

瑕疵担保責任とは、「バグったら自分の口座から賠償する」というレベルに重い責任のことを指します。(個人と法人では口座の扱いも違うのですが、それは本記事の趣旨ではないので省略します)

「あの現場稼働多すぎだから辞めた!」「一ヶ月での機能改修を頼まれたけど、渡されたソースコードがバグだらけで、こんなん3ヶ月かかっても終わらんし辞めた」こういう事情で現場から抜けた話をよく聞きますが、瑕疵担保付きの請負契約を結んでいた場合、追って訴状が届くことを覚悟しなければなりません。それは理不尽じゃないんです。だって債務不履行じゃん。

システム開発のような「技術もユーザーが求める要件もハイスピードで変わっていって、手探りで、ときには失敗もしながら改善を重ねていく業務」において瑕疵担保責任があると何もできなくなります。失敗も前提に仕事を進めないといけないのに、失敗すると訴えられるんです。誰がそういう仕事をしたいと思うでしょうか。

もちろん現場に入るエンジニアとして自身の持つ技術倫理にかなった仕事を進めることは大前提ですが、瑕疵担保責任がないことでできるようになることはたくさんあります。

ダウンサイドのリスクを減らすことによってリスクのある、けれどリターンも期待できるような仕事のやり方を採用できるようになるんです。

まとめると、「ゼロからでも売上を立てられ」「入金スパンが早く経営が安定し」「瑕疵担保責任がない」これがSESというビジネスを選択するメリットです。

SESのデメリット1.売上が頭打ちになりやすい

特に仲介を通すとありがちですが、単価が業界平均に引きずられてしまったり、マージンが大きくなったりするので単価が頭打ちになりやすいです。

個人事業主でも売上1000万以上からは消費税の課税対象になってしまうので「それじゃあ980万くらいで止めて稼働浮かせて残り遊ぶかw」みたいな感じになりがちです。

SESのデメリット2.現場の環境に左右される

特に常駐で入る場合、開発スタイルや開発フロー、人間関係などが行く先の会社に大きく依存します。

最悪のケースだと人間関係も悪い、スキルアップもできない、単金もそれほど高くないみたいな現場を引いてしまうこともあります。(※そういう現場を引いたときにどう行動するかはあなた次第です)

やはり実際に入ってみないとその仕事・現場の本質はなかなか見えてきづらいものがあるので、事前に調べていても不確定要素がどうしても残ってしまいます。

SESのデメリット3.事業拡大しづらい

人の一日は24時間しかありませんし、一日12時間働くと身体を壊します。

なので一人あたりに出せる売上に限界がありますし、人を雇って規模を拡大しても一人あたりの売上が増大するわけではありません。(もちろん、実績を積んだから値上げしてくれ、という交渉はありえますが)

これはSESだけでなく、コンサルティングなどの業務でも同様のビジネス構造上の問題です。

また、「人の確保」「営業先の確保」といった、エンジニアがあまり専門ではない領域に規模拡大のボトルネックが存在することが多いです。

SESのデメリット4.マウントを取られやすい

はい。「人貸し」「時給労働者」とかインターネットでめちゃめちゃマウント取られます。このあたりの論調については皆さんよくおわかりのようですので詳しく述べません。

受託開発のメリット1.時間精算でないので、早く作れば早く作るほど自分の時給が高くなる

時間精算ではなく予め合意した納品物に対価を支払う契約なので、早く作れば作るほど自分の時給は高くなります

「このタイプのシステムを作るときはこういったことに気をつければいい」といった勘所を抑えておくと、さらに自分の作業時間が短縮できるので時間あたりの生産性が高くなります。

納品要件を満たしたものさえ作ってしまえれば、1時間で作って後はスプラトゥーンやっていても大丈夫です。

受託開発のメリット2.再委託可能な案件が多いので、マネジメントスキルがあれば他人に働かせてもOK

個々の契約によって一概には言えませんが、準委任契約より再委託OKになる傾向が強いです。

もちろん瑕疵担保責任がついてくるので、再委託先から上がってきたものをちゃんと精査する必要はあります。

受託開発のデメリット1.瑕疵担保責任が発生する

請負契約には成果物を完成させる責任が発生します。

受託開発のメリットの裏返しであり、納品するまで仕事が終わりません。

これは、単に自分のエンジニアリングスキルがヘボだったということで片付けられない問題で、「そもそも何を作るか細部まで合意できてなかったよね」という問題に起因する場合もあります。

契約段階で相場観を握っていないと瑕疵担保期間5年とかえげつない契約書を出されたという話を聞いたこともあります。

腕に自信があれば「瑕疵担保期間は一ヶ月だけど年間○○万円の準委任契約でメンテ・障害対応やるで」という契約にしても良いと思います。

受託開発のデメリット2.開発する前に仕様を確定しなければならない

瑕疵担保責任が発生する以上、成果物を事前に文書でもって合意してから開発を行うことになります。

そうしておかないと、「〇〇の機能がないとユーザーが使ってくれないことがわかった。これはバグだから無償で機能追加して」みたいなことになりかねません。

必然的に開発スタイルは仕様の合意を先に取ってそこに向かって開発する「ウォーターフォール開発」に限られます。

Excelや紙ベースの既存の業務をWebでも回せるようにするための管理画面を開発する、など仕様の変動が起こりにくいような領域に限定してこの契約形態を検討するべきです。

「世の中に変わらない仕様などない」というお題目が掲げられることが多いですが、現実的にどの機能が仕様変化しやすく、どの機能が仕様変化しにくいのか、その濃淡を見極めるのもエンジニアのスキルの一種だと思います。

「まずリリースして顧客の反応を見つつ改善していく」アジャイル開発がしたいなら準委任契約を選択するべきです。

受託開発のデメリット3.入金スパンが遅い

受託開発の入金は検品完了後1~2ヶ月必要なので、手元にお金を多めに残しておかないと資金ショートで死にます。

3ヶ月以上を要するような規模の受託開発であれば、着手金を請求したり、やることのスコープを細かく、1ヶ月×3の開発に分割するなど契約を工夫したほうがリスクが少なくなります。

人間に完全未来予知能力はなく、人間の予測は時間軸が大きくなればなるほど大きく外すようになります。

一ヶ月後に完成するシステムがエンドユーザーのニーズを満たすかどうかを検討するほうが、一年後に完成するシステムがエンドユーザーのニーズを満たすかどうかを検討するよりブレが少なくなるので発注側としてもリスクが少なくなります。

なので、期間が長過ぎる開発に関してはお互いのリスクが大きくなることを認識してそれを埋める努力をしましょう。(逆にリスク取って単価積み増しするのもアリです)

自社サービスのメリット1.事業の資産性が高くスケールしやすい

SESや受託で必要な資産というのは何をさておき「人」です。腕次第で稼げると言うと聞こえはいいですが、同時にSESのデメリット項で挙げたような事業拡大上の弱点を抱えてしまいます。

自社サービス開発ではプロダクト自体に価値を積み重ねていくので資産性が高く、うまく仕組みを構築すれば倍々ゲームのように会社の売上を上げていくことができます。

インターネットには「楽して儲かる方法あなたに教えます」というキャッチコピーが蔓延していますが、個人的には自社サービスを軌道に乗せるのが一番現実的な「楽して儲かる方法」だと思っています。

ただし、「デメリット」の項で述べますが、軌道に乗せるまで超キツイです。最初から楽して稼げるなのではなく、結果的に楽になるかもね、くらいの肌感です。

自社サービスのメリット2.自社の評価額が高くなりやすく、エクイティでの資金調達を受けやすい

SES、受託開発、自社サービスでは一番出資による資金調達をやりやすい事業形態です。

貸付ではなく出資を行う人は、「今赤字か黒字かはどうでもよく、会社が10年後に10倍、100倍の価値になっているか」に重点を置いて出資をします。

ビジネスの仕組みを構築・自動化できれば売上が倍々ゲームになることが期待できる自社サービスは投資対象として適しているといえます。

SES、受託開発は良くも悪くも労働集約的ビジネスです。人を増やしたり事業規模を拡大させるメリットが薄いので、出資する側としてもお金が出しにくいです。

自社サービスのメリット3.開発環境は自分がベストと思ったものを選んで良い

自社開発なので誰の指図も受けずに自分が作りたいと思った環境で自分が作りたいと思うものを作ることができます。

それがユーザーに受け入れられて収益を発生させるか?という問題は別途に検討するべきですが。

自社サービスのデメリット1.考えるべき要素が多すぎる

自社開発を行う場合、エンジニアリングスキルだけでなくマーケティング・会計・法律・事業ドメインの知識など多面的な知識が必要となります。

良いものを作っても認知されなければ使ってもらえませんし、良いものを作っても開発費をかけすぎてコストを回収できないかもしれませんし、良いものだと思って作ったものが実は法律に抵触しているかもしれませんし、そもそも良いものだと自分だけが思い込んでいる可能性もあります。

自分でできない領域は人に任せるしかありませんが、収益化が遅いこともあり「人を入れないと回せないが、人を雇う金はない」といった事態も起こりえます。

自社サービスのデメリット2.収益化までめちゃめちゃ遅く資金繰りで死にかねない

入金のスパンは3種類の開発形態の中で最悪です。マーケティング施策打って固定費用を先に発生させ、サービス開発費をかけてサービスを完成させ、それをローンチしてユーザーが課金し、それが実際に振り込まれるまで口座残高が増えません。

SESや受託開発に比べると

(口座残高) - (その月に支払うべき債務) < 0

になる確率が非常に高く、資金繰りをちゃんと計算しないと簡単に手元の現金がなくなってしまいます。

自社サービスのデメリット3.事業を外すと大赤字のリスク

SES・受託ならば売上はほぼ固定で計算できるので、経費をそれ以下に抑えればまぁとりあえず破綻はしないよね、みたいなそろばんを弾くことができますが、自社サービスの場合は一ヶ月後にどれだけの売上が入ってくるかの予測がつきません。(正確にはユーザー数やアクセス数などから確率論で概算の売上を出すのですが、大きくブレます

課金形態をサブスクリプション(月額課金)にするなどビジネス上の工夫をもたらすことによってある程度安定化することができますが、それでもSESや受託に比べて立ち上げ初期は不安定になります。

3つの開発を組み合わせて事業を作るのもアリ

別に準委任とか請負やる会社が自社サービスやったらダメとかいう制約はないので、これらの組み合わせで事業を回していく、という選択肢もあります。

例えばSESで短期的な資金を回しつつ利益を自社サービスに投下する、といった経営スタイルです。

とにかく、なんでもいいから

(売上 - 経費) * (税率) - (生活費) > 0

(口座残高) - (その月に支払うべき債務) > 0

この条件を満たすようにリソースを組み合わせれば事業は継続できます。

さいごに

この記事では、

・SESのメリット・デメリット

・受託開発のメリット・デメリット

・自社サービス開発のメリット・デメリット

について解説しました。もちろん個々の会社間契約の違いなどによってすべてがこの記事を読む皆さんの周辺環境に合致しているとは思いませんが、個々のビジネスにおける特性などを俯瞰して立ち回ることで自分の求めているフィールドに行きやすくなるのではないかと思いますし、もしひとつでも参考になることがあれば、ぜひこれからの皆さんの意思決定の材料の一つにしていただけたらと思っています。

さて、ここまで一気に書いてきていささか疲れてしまいましたし、ちょっとくらい自分のブログの宣伝をしてもよいだろうということで貼っておきます。触ってみた技術に関するメモとか自分で運営しているサービスとか気ままに書いています。


この記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。

68

yukito ohira

#エンジニア 系記事まとめ

noteに投稿されたエンジニア系の記事のまとめ。コーディングTIPSよりは、考察や意見などを中心に。

コメント1件

エンジニアとして全て経験してきました。
SESの闇は、会社の母数が圧倒的に多いので声も多くなるかなぁと思ってます。
SESは営業がとってきた仕事をただ回すだけなら、よく言われる業界の闇に巻き込まれる可能性高いです。
ただ、営業に同行して案件見定められるなら避ける事もできますね。
IT業界新人でもベテランとセットで経験積めたり、様々な業種の企業文化学べたりと色んな経験値積めるメリットはありますが、得るお金に限界あるので給料の上がり幅は少ないです。

受託は請負か持ち帰り型の委任かで変わるところありますが、請負だと大なり小なり中の人に負担掛かる事多いです。
ただ、作る物が決まってからのどうやって作るか、は割と自由が効くのでやりがいはあります。
ご参考までに。
コメントを投稿するには、 ログイン または 会員登録 をする必要があります。