受託開発というビジネスの構造的限界
「これ、結局のところ人件費を売上に変換しているだけじゃないか？」
受託開発を経営している人なら、たぶん一度は通る違和感です。
表面だけ見れば、よくできた仕組みなんですよ。お客さんに予算があり、こちらに作る人間がいて、要件をすり合わせて納める。フェアトレード的で、双方が納得しやすい。
ところがしばらく経営をやっていると、損益計算書の上では順調なのに、会社に何かが「積み上がっていない」感覚がやってくる。これが冒頭の違和感の正体です。
私自身は受託を主業としているわけではないですが、関わっている会社や周りの経営者の話を総合すると、これはかなり広く共有された違和感らしい。本稿はそれを構造として整理する試みです。受託をやめろ、と言いたいわけではなくて、長く生き残っている受託会社が「どこ」に引きこもっているか、それがなぜ生き残る位置なのか、を見たい。
ハードウェアでもソフトウェアでも、見える範囲の構造はほぼ同じなので、ここではあえて区別しません。
受託は実は4階建てのビル
「受託開発」と一口に言いますが、中身は連続的なスペクトラムを持っています。粗く4階建てに分けてみます。
- 工数販売：人月で値段を切る。要件はお客さん任せ、こちらは指示通り作る
- 成果物販売：成果物の形は決まっているけれど、要件は都度ヒアリング
- テンプレ＋カスタマイズ：既存の社内ライブラリを、お客さんの要望に合わせて少し変える
- ライセンス／SaaS：自社の製品やサービスをライセンス販売する
階段を上がるほど、再利用できる資産が積み上がる。下に行くほど、毎回ゼロから組み直す。
ちなみに「IPだけで食っていく会社」というのもあるんですが、あれは戦略がそもそも別ジャンルなのでこの階層には載せません。受託からのスペクトラムでは到達しないところに最初から居る、というのが正確です。
ここがミソなんですが、長く生き残っている受託会社は、ほぼ全員、3階の「テンプレ＋カスタマイズ」のフロアに引きこもっています。表向きは新規開発に見えても、実態は内部ライブラリの再組み合わせ、過去案件の差分実装。
逆に、1階や2階に居続ける受託会社は、構造的にスケールしない。理由は身も蓋もなくシンプルです。
1〜2階の住人が苦しい3つの理由
① 粗利の上限が人件費単価で決まる
売上は「人月単価 × 人数 × 期間」で頭打ちになります。利益を倍にしたければ、人を倍にする以外にない。
ぶっちゃけ、これは事業として致命傷です。利益と人数増加が直結している会社は、人件費高騰や採用難でいきなり詰みます。
② 稼働の上下動を経営側が一身に吸収する
案件が止まれば、人件費だけが残ります。固定費なのに売上は変動費、という最悪の組み合わせ。
そして案件が忙しい時期に限って、優秀なエンジニアが「もう少し落ち着いた環境で働きたい」と言って辞めていったりするんですよね。経験ある人は身に覚えがあるはず。
③ 知的資産が積み上がらない
毎回違う要件で毎回違う実装をしていると、再利用できるライブラリが太らない。10年やっても累積効果が小さいんです。
これ、数字で見ると意外と残酷で、10年経って残っているのが「人と現金」だけ、という会社が珍しくない。設備産業なら工場が残る、メーカーなら金型と図面が残る。受託は——気をつけないと——何も残らないんですよね、、、
つまり、儲からなさは偶然じゃなくて、設計通りに儲からないようになっている。
経営から見ると「ありがたい」に化ける罠
ここで話がややこしくなるんですが、受託をやめろ、という話の難しさは、実はこの先にあるんです。
複数の事業を束ねている経営者の目線で見ると、受託開発は意外と「優等生」に見えるんですよね。プロダクト事業は当たれば大きいけど外せば赤字、新規開発は数年単位の投資、研究開発はリターンが見えにくい——こういう中で、受託は「毎年だいたい何億円の粗利が上がる事業」として、ポートフォリオの安定枠に置かれる。
「受託があるおかげで新規事業の投資余力が作れている」という説明、けっこうあちこちで耳にする話で、事実として正しい年もあるんですよ。だから止めにくい。
ところが、です。
受託の「安定して見える粗利」は、本質的には全然安定じゃないんですよね。
なぜかというと、案件はパイプライン依存だから。今年たまたま大きな案件が3つ重なれば、表面上の粗利は出ます。来年その3つが終わって新規が決まらなければ、ゼロです。固定費だけが残る。「毎年だいたい」に見えていたのは、たまたま波が均されて見えていただけ、というケースが多い。
しかももう一つ、粗利率は案件ごとに大きく振れる。テンプレ＋カスタマイズで8割再利用できる案件なら粗利40%、フルスクラッチで毎週要件変更が入る——いわゆる事故案件——だと粗利5%、下手すると赤字。同じ「受託1億円」でも、構成によって会社に残る金額は10倍違うんです。
それでも経営層には「受託は粗利30%」みたいな前年実績の数字で説明されがち。これは平均化のマジックです。
そしてここからが残酷で——
調子のいい年は、受託は会社のなかで一定の評価を得ます。粗利が読めて、新規事業の投資余力を作ってくれているように見えるから。
ところが、案件が薄い年——理由は景気でも、市場の予算サイクルでも、何でもいい——その瞬間、評価軸が反転します。粗利の落ち込み、失注、事故案件の損失、こうした問いが一斉に向けられる。
ついこの間まで「ありがたい」と言われていた事業が、急に説明責任を問われる立場に化けるんですね。
この振れ幅は、たぶん受託事業のもう一つの構造的な問題なんですよね。プロダクト事業や研究開発は、最初から「投資」として位置づけられているので、不調な年があっても評価が反転しにくい。一方、受託は「安定収益源」として組み込まれた瞬間、不調が即座に評価変動につながる。
期待値が高いから、外れると痛い。プロスペクト理論的なやつです。
このジレンマに完全な正解はないんですが、運用上のコツはあります。それは、受託の粗利を、保守的な水準（過去5年の最低値くらい）でしか経営計画に織り込まないこと。それを超える年は「ボーナス」として扱う。これだけで戦犯化のリスクはかなり下がります。
じゃあ、どこに居場所を作るか
ここまでの話を踏まえて、問いを立て直してみます。「受託をやめるか／続けるか」の二択じゃないんですよね。
4階建てビルの、どの位置に引きこもると、積み上げが効いて、かつ戦犯化されにくい位置取りになるか——これが筋のいい問いです。
観察できる範囲では、長く生き残っている受託会社には、いくつか共通点があります。
ひとつ、特定領域にライブラリ・設計資産を貯める。汎用受託じゃなくて領域特化。医療でも金融でも製造でも組み込みでも、何でもいい。そのドメインの社内資産が太っていて、新規案件の8割を埋める。残り2割を都度実装する。テンプレ＋カスタマイズの本体はこれです。
ふたつ、自社で実際に使う製品を作る。自分たちの業務改善のために作ったツールが、お客さんの業務にも刺さる、というやつ。Dogfoodingが効いている領域は、外注で作るプロダクトより明確に競争力が出ます。「半分プロダクト、半分受託」というグラデーション領域。
みっつ、品質保証と関係資本で値段を維持する。競合と同じ実装を、競合より高く売る。理由は、過去案件の積み上げから来る信用と、何かあったときの対応能力。コストリーダーシップ戦略は受託では原理的に不可能なので、差別化はここしかありません。
逆に言うと、これらが積み上がらない案件——毎回新規・毎回ゼロから・毎回別領域——というポートフォリオは、構造的に苦しい。やればやるほど資産が積まれず、稼働の上下動だけが経営に跳ね返ってくる。
3階を「終着駅」ではなく「中継駅」として使う
ここまで読むと「3階に引きこもれ」と聞こえてしまうかもしれませんが、実は3階は終着駅としても機能するし、中継駅としても機能するんですよね。テンプレ＋カスタマイズのフロアでアセットを貯めて、それを土台に4階の「ライセンス／SaaS」に登っていく道が、ちゃんと実在する。
例えば、私の知人で、サウジアラビアでスイッチサイエンスに近い領域の会社をやっている人がいます。イタリアで知り合った縁なんですが、彼は「カメラ」というドメインに意識的に絞って受託を取り続けたんですよね。汎用的な雑多な案件には目もくれず、カメラ周りのハードウェア・画像処理・組み込みに集中する。
数年経って、社内にはカメラ関連のライブラリ、回路設計、画像処理のノウハウが太く積み上がった。そのアセットを使って自社製品を立ち上げ、それを引っ提げて資金調達に成功した、という話を本人から聞いています。
「受託で食いつなぎながらアセットを貯めて、貯まったアセットで上の階に登る」というルートを、彼は意図的に設計していたわけです。受託のドメインを絞り込むという最初の判断が、そのまま後の自社製品の競争優位を決めていた。
もう一つ、私が顧問をしているhacomonoという会社も、似た構造を辿っています。元々はWeb系の受託からスタートした会社なんですが、複数の顧客の案件を見ていく中で「ある業種の会社が共通して欲しがっているもの」を見抜いた。そこに自社SaaSをぶつけたらハマって、累計で数十億円規模の資金調達まで進んでいます。まだ上場前なので結論を出すには早いですが、受託で得た「市場の手触り」をSaaSに変換した、という構造としては綺麗に刺さった例です。
両方に共通するのは、受託を「ずっと受託でいるための受託」ではなく、「上の階に登るためのアセット蓄積期間」として位置づけていたことです。3階に引きこもるのも一つの戦略、3階を踏み台にして登るのもまた一つの戦略。後者を取れる会社は、最初から領域を絞っているケースが多いんですよね。
逆に、領域を絞らずに何でも受ける受託会社は、3階に登ることはできても、そこから上の階に行く道が見えにくい。汎用ライブラリは積み上がるけれど、特定領域の深い手触りは積み上がらないからです。
エンジニアの楽しさと、経営の合理性は、別物
ここからが、たぶん一番伝えたいことなんですよね。
エンジニア視点で言えば、受託は楽しいんです。案件ごとに違う技術が触れる、いろんな業界が見える、納期というハードコンストレイントの下で技術力が磨かれる。この楽しさは本物です。
私自身、エンジニア気質の部分は強い方なので、毎回違う案件で違う技術を触る方が好きなのは間違いない。
ただ、この楽しさを「経営の合理性」と取り違えると、長く続けるほど苦しくなるんですよね。
エンジニアとしての楽しさは、経営者としての楽しさを保証しない。これは別物です。経営者として楽しいのは——たぶん——会社に何かが「積み上がっていく」のを見ることなんだと思います。
冒頭の違和感、つまり「人件費を売上に変換しているだけじゃないか」という感覚は、たぶんこの「積み上がっていない」感覚の言い換えなんですよね。
到達可能な善
業界全体の構造を変える力は、もちろん自分にはありません。ただ、関わる会社の中で、
- 工数販売の比率を下げて、テンプレ＋カスタマイズの比率を上げる
- 受ける領域を絞って、ドメイン特化の社内資産を蓄積する
- アセットが太ってきたら、上の階（自社製品／SaaS）への移行を本気で検討する
- 受託の粗利は、保守的な水準でしか経営計画に織り込まない
このあたりは、経営判断として実装可能です。一気にSaaSに転換しろ、と言っているわけじゃない。スペクトラムの上での位置を、半段でも上げていく、という運用上の話。
数人の経営判断と、数年の積み上げで、会社の構造はゆっくり変わります。受託開発が「人件費を売上に変換するだけ」の商売から距離を取るには、たぶんそれくらいの時間軸が要るのだと思います。
この文章は原案・ディレクション：九頭龍、作文：AIで書いています。
