フリーランスに頼むか、会社に頼むか ── 個人が向く案件と、契約・請求・窓口で変わること

「知り合いにエンジニアがいるので、その人に個人で頼もうかと思っています」。あるいは「クラウドソーシングで出したら、会社の見積もりの3分の1が来ました」。どちらも、相談の場でよく聞く話です。

先に立場を書いておきます。私たちは会社ですが、少人数で分業していないので、体制としては個人に近い部分があります。個人を下げるつもりはなく、個人に頼んだほうがいい案件はあります。それも含めて書きます。

その開発会社が続けられなくなったときの備えはその開発会社が続けられなくなったらに書いたので、この記事は手前の、最初に選ぶときの話だけにします。

差が出るのは、法人格ではなく「何人で見ているか」

個人か会社かで、作る速さや質は決まりません。法人格の違いが効くのは、契約と請求の場面で、あとで書きます。

実際に差が出るのは、2つです。作っている人が止まったとき、代わりがいるか。リリースしたあと、誰が見続けるか。

この2つで見ると、世の中の開発の相手は3つに分かれます。個人。少人数で分業しない会社。営業・PM・エンジニアで分業する会社。私たちは2番目です。

個人に頼むと、収まりがいい案件

範囲が小さく、はっきりしている案件です。既存サイトの改修、いまあるシステムへの1〜3画面の追加、ランディングページ、社内ツールの1機能。こういうものは、会社に頼むと打ち合わせと見積もりのほうが作業より長くなります。

期限に幅があること。社内に、要件を決めて進行を見る人がいること。この2つが揃っているなら、個人に頼んで困ることは少ないです。

価格は、会社より安く出ることが多いです。営業やPMの人件費が乗らないからで、これは構造の話です。安い理由が説明できるなら、安いこと自体は問題ではありません。

こういう案件なら、うちに頼まなくていいです。私たちの初期費用には設計から導入レクチャーまでの一式が入っているので、1画面の追加だけを頼まれると割高になります。

個人だと、厳しくなる案件

社外の人が使っていて、障害が起きたら即日で対応が要るもの。展示会や法改正で期限が動かせないもの。アプリとWebとインフラのように、領域が複数にまたがるもの。数年単位で保守を続けてもらう前提のもの。

共通しているのは、本人が止まったときに代わりがいないことが、そのまま損失になる点です。病気、他の案件の繁忙、転職。個人に悪気がなくても起きます。

領域が複数にまたがる案件では、個人が得意でない部分を別の人に再委託することがあります。それ自体は悪くないのですが、発注側からは見えないところで人が増え、責任の所在が曖昧になります。「全部ご自身で作りますか」は、契約前に聞いておく質問です。

クラウドソーシング経由で、起きやすいこと

個人に頼む入口として、クラウドソーシングを使う会社は多いです。相談で聞いた範囲で、起きやすいことを挙げます。統計ではなく傾向です。

見積もりが範囲を読んでいない。 募集文だけで金額を出すので、会社の3分の1で来た見積もりが、業務の半分しか含んでいないことがあります。安い理由が「範囲を読み違えている」なら、あとから追加になります。

途中で連絡が途絶える。 他の案件が忙しくなると、返事が週単位で空きます。プラットフォームの仕組みで一部は守られますが、期限は守られません。

納品後の修正が、有償か、できない。 納品して検収したら関係が終わる前提の人が多いです。リリース後に直したいことは必ず出るので、その扱いを先に決めておかないと、直せる人がいなくなります。

コードとアカウントが個人名義。 ソースコードが本人のアカウントに、サーバーやドメインが本人の名義になっていて、関係が切れると取り出せない。これは会社に頼む場合と同じ確認で済みます。

プラットフォームの規約。 手数料と、直接契約への切り替えに関する制限があります。長く付き合うつもりなら、最初にどの形で契約するかを決めておいてください。

どれも、聞けば分かることです。「コードはどこに置きますか」「納品後の修正はどう扱いますか」「全部ご自身で作りますか」。会社に対して聞く質問と同じで、開発会社の選び方に書いた5つの質問は、個人にもそのまま使えます。

契約と請求で、変わること

ここが、法人格の違いが実際に効く場面です。

契約書は、個人だと雛形を持っていないことがあります。その場合、発注側で用意することになります。中身は会社に頼むときと変わらず、システム開発の契約書で、発注側が読むべき5つの場所に書いた5つが入っていれば足ります。相手が個人でも、秘密保持は別に結んでおいてください。

請求のほうは、個人への支払いだと、消費税の扱いや、源泉徴収の要否が会社への支払いと変わることがあります。インボイスの登録があるかどうかでも変わります。ここは会社の状況によって違うので断定できません。契約前に、請求書の形を税理士に確認してください。

会社に頼む場合は、契約の相手が法人なので、担当者が変わっても契約は続きます。個人の場合、その人が続けられなくなった時点で契約も止まります。差はここです。

会社に頼んだのに、窓口が変わるリスク

会社に頼めば安心か、というと、別の問題があります。相談した人と、作る人が違うことです。

営業が話を聞き、PMが仕様に落とし、エンジニアが作る。この間で、最初に話した内容が薄まります。そして担当が変わったとき、「それは前任から聞いていません」が起きます。分業する会社の弱いところは、人が抜けても続けられる代わりに、人が変わるたびに伝言が挟まることです。

聞く質問は2つで足ります。「打ち合わせに来る方が、作る方ですか」「担当が変わるとき、どう引き継ぎますか」。前者に「はい」なら少人数の会社、「いいえ」なら分業の会社です。どちらが悪いということではなく、自社の案件がどちらに向くかで決まります。

ニカゲツを、この比較の中に置くと

株式会社aleという会社で、契約と請求は法人として行います。体制は少人数で、分業していません。相談した相手がそのまま設計し、実装し、リリース後12ヶ月の運用まで担当します。下請けもいません。

個人に頼むときの速さと、法人と契約する形の、間に位置します。伝言が挟まらないので、初回の60分で話したことがそのまま画面になります。

弱いところも書きます。分業する会社のように、人が抜けても別の担当が続ける体制ではありません。担当者が動けなくなったときの影響は、個人に頼んだ場合に近い。だからソースコードとアカウントを自社側に置ける形にしていて、その確認の仕方は先ほどの記事に書いたとおりです。ここは選ぶときに天秤にかけていただく部分で、大きな案件や、分業の体制そのものが要る案件は、私たちには向きません。

観点	個人	少人数の会社	分業する会社
契約と請求の相手	本人	法人	法人
見積もりに乗る稼働	作る人だけ	作る人だけ	営業・PM・作る人
相談した人が作るか	本人が作る	相談した相手が作る	別の人が作ることが多い
止まったとき	代わりがいない	影響は大きい	別の担当が続ける
向く案件	小さく明確なもの	最初の1本、使いながら育てるもの	規模が大きく、期限が動かせないもの

常駐で手を借りるSESや、雇うという選択肢まで含めた比較は社内システムは内製か外注かに、1年の総額で並べてあります。

迷ったら、同じ質問を3者に投げてください。個人に1人、少人数の会社に1社、分業の会社に1社。「打ち合わせに来る方が作りますか」「止まったらどうなりますか」「コードはどこに置きますか」。答え方の差で、自社の案件がどこに向くかが見えます。比べた結果うちが合わない、という結論でも構いません。