個人法人・マイクロ法人に頼む、メリットとデメリット

個人法人やマイクロ法人に直接 Web・アプリ開発を頼むと、 制作会社の3分の1から半額くらいで作れる。 値段が下がる理由は別記事で書いたけれど、 ここでは「じゃあ全部の案件を個人法人に頼めばいいのか」という問いに答える。 実際には向いている案件と向いていない案件がはっきり分かれる。

メリット側

価格が構造的に安い

制作会社で200万の案件が、個人法人で60〜80万になる。 値引きじゃなくて、人件費階層や中間マージンが構造的に乗らないから出る差。 発注予算の上限が決まっているときに、これが直接効く。

意思決定が速い

営業 → プロデューサー → ディレクター → エンジニア、と何段階も経由する必要がない。 受注者本人と直接話して、要件の確認も追加変更もその場で決まる。 制作会社で「持ち帰って検討します」と言われていた内容が、 個人法人だと打ち合わせ中に判断が返ってくる。

全体像を1人が把握している

大人数の体制で進めると、デザイナーとエンジニアで認識が食い違う、 ディレクターが間に入って情報が劣化する、というのが普通に起きる。 個人法人やマイクロ法人だと、1人が全体を見ているので 「ここを変えるとあそこに影響が出る」という整合性を保ったまま動かしやすい。 小さい体制ほど共有漏れが起きにくい、というのは現場では実感としてある。

技術スタックが新しいことが多い

個人法人やマイクロ法人は、案件1本ごとに最適な技術を選びやすい。 Next.js + Vercel、Flutter + Firebase、Supabase、Cloudflare Workers のような 最新のスタックを使うことが多く、結果として運用コストも下がる。 制作会社は組織として既存のスタック（WordPress、Laravel など）に張り付くことが多いので、 同じ要件でも運用にお金がかかる構成になりやすい。

リリース後の追加対応がしやすい

受注者本人と直接やりとりできる関係だと、 リリース後に「ここちょっと直したい」を気軽に頼める。 制作会社経由だと、軽微な修正でも見積もりと発注書のラリーが発生するけれど、 個人法人なら slack や チャットで完結することが多い。

デメリット側

体制リスクがある

個人法人で1人が作っていると、本人の体調・家庭の事情・他案件の繁忙で、 進行が止まるリスクがある。これは制作会社の「複数人で見るから誰かが穴埋めできる」という構造とは違う。

マイクロ法人（2〜数名）でも、同じ案件を見ている人数が制作会社より少ないので、 体調を崩した人が出るとプロジェクトが遅れることがある。 納期が絶対に動かせない案件（イベント連動、決算期前のリリース等）には、この性質が向かない。

契約書・法務のレベルが薄い

個人法人やマイクロ法人は、法務担当を持っていないことが多い。 契約書は雛形ベース、損害賠償条項やSLA、知的財産権の細かい取り決めは 発注側が持ち込んだものをそのまま使うことになる。

大手企業の購買部が「うちの契約書じゃないと発注できません」と言うケースは多くて、 その場合は個人法人側で対応できないことがある。 逆に、契約書を相互レビューする体制が発注者側にあれば、ここは大きな問題にならない。

稼働可能な範囲に上限がある

1人が動かせる工数には物理的に限界がある。 月160時間が稼働の上限で、その中で複数案件を並走している場合、 新規案件に割ける時間は40〜80時間/月くらいになる。

「3ヶ月で大規模リリースしたい」「フルタイム並走で常駐対応してほしい」のような要件は、 個人法人やマイクロ法人では受けきれない。 制作会社が複数エンジニアをアサインできる構造のメリットが効くのはこの帯。

専門領域が偏ることがある

フルスタック開発者でも、得意領域は人によって違う。 フロント中心の人にバックエンドの重い処理を頼むと、可能ではあるけれど時間がかかる。 アプリ開発者にデザイン提案も求めると、デザインの精度が制作会社の専門デザイナーには及ばないことがある。

対策としては、案件の中心スキルと受注者の得意領域を合わせる、 もしくはマイクロ法人で複数スキルが揃っているところに頼む。 運営側でこのマッチングを補助するのが、mitsumon の役割でもある。

保守・運用契約の継続性

個人法人の事業が継続するかは、本人次第。 5年後、10年後の保守を約束できる体制ではない。 制作会社のように「会社として保守責任を持つ」構造はないので、 受注者が事業を畳んだ場合、コードの引き継ぎ先を別途探すことになる。

ただ、制作会社に頼んだ場合も、担当エンジニアの退職や会社の倒産で 実質的に同じ状況になることはあるので、構造的な絶対の差ではない。 重要なのは、コードと運用ドキュメントが発注者側に渡されていて、 別の業者が引き継げる形になっていること。これは契約段階で握っておく。

向いている案件・向いていない案件

ここまでのメリット・デメリットを踏まえると、案件ごとに向き不向きが分かれる。

向いている案件

• 予算100万以下で、自社専用の Web サイトやアプリを作りたい
• 要件がある程度固まっていて、ヒアリングから設計までを発注者側で持てる
• 納期に1〜2週間の余裕がある（体制リスクを吸収できる）
• リリース後の改善を、低単価で軽く続けたい
• 意思決定スピードを重視する（スタートアップ、店舗単位の事業 等）
• 技術スタックの選択を業者に任せたい（最新の組み合わせで作ってほしい）

向いていない案件

• 納期が絶対に動かせない（決算、イベント連動、上場対応）
• 業種規制（医療、金融、自治体）でコンプライアンス対応が中心
• SLA担保 / 24時間運用 / 障害対応の人数を確保する必要がある
• 大手企業の購買プロセスで、決まった契約書フォーマットが必須
• 同時並走で複数エンジニアをアサインしないと回らない大規模案件
• 長期（10年以上）の保守契約を会社として担保したい

判断の早道

個人法人・マイクロ法人に頼むかどうかの判断は、結局この3つの問いに集約される。

• 納期が動かせるか — 動かせない案件は不向き
• 業種規制・SLA・大規模体制が要件か — 必要なら不向き
• 要件を発注者側で握れるか — 握れるなら向いている

これが「YES, NO, YES」なら、個人法人・マイクロ法人で組むのが最も安く済む。 どこかに「不向き」が入るなら、制作会社・SIerを検討したほうがいい。

判断に迷う場合は、要件を整理する段階で運営に話してみてほしい。 どちらに振るべきかは、要件を聞けば30分でだいたい見える。 合わない案件を mitsumon の掲載企業に渡しても、両方が消耗するだけで誰も得をしない。 だから、振り分けは正直にやっている。