この記事の内容
受託開発会社を経営していると、自社プロダクトの話は何度も社内で出ては消えます。案件が詰まっているときは誰も手を付けられず、閑散期に始めても次の大型案件が来ると止まる。そうして「うちは受託の会社だから」と結論を出した経験がある代表も多いのではないでしょうか。
受託開発会社が自社プロダクトを持つ方法は、ゼロからSaaSを企画するだけではありません。自社の業務で使っている仕組みを外に出す、受託で作った仕組みを別の顧客に広げる、他社の事業を譲り受ける。入口が違えば、必要な時間もお金も、背負うリスクも変わります。
この記事では、ハコブネを運営する株式会社Walkersの例をもとに、受託開発会社の自社プロダクト戦略を3つの型に分けて整理します。自社に合う型を先に選べば、受託を止めずに自社プロダクトを持つ道筋が見えてきます。
この記事について
書いているのは、作る側です。ハコブネを運営する株式会社Walkersは、受託と自社事業で累計300件の開発に関わり、200社以上の事業づくりを支援してきました。監修は取締役の池田龍一です。
一般論ではなく、実際にやったことの中身で説明します。この記事に出てくる数字は、すべて公開済みの自社・支援先の事例から引いています。出典は記事の最後にまとめました。
受託開発会社が自社プロダクトを持つ理由
Walkersは、AI駆動開発・ノーコード開発のシステム開発会社です。累計開発実績300件、200社以上の支援、自社メディアの累計100万PVという受託の実績があります。そのうえで、受託開発という事業領域はAIで将来的に消えていく可能性が高いと考えています。
作業の値段は下がり、要件を決める仕事と顧客接点が残る
AIで実装が速くなると、作業時間に値段をつける受託は単価が下がりやすくなります。一方で、要件が決まっていない案件を整理する力、顧客の業務を知っていること、顧客との接点は価値が残ります。受託開発の将来性の見立ては、受託開発の将来性｜AIで何が減り、何が残るかを開発会社の現場からで詳しく書いています。
受託の経験は、自社プロダクトの材料になる
受託から自社プロダクトへ移るのは簡単ではありません。ただ、受託開発会社には、作る力、取引先との接点、何度も頼まれた作業という需要の証拠がそろっています。受託開発会社は、自社プロダクトに必要な材料をすでに社内に持っています。問題は、どの材料をどの型で使うかです。
型1：自社の業務で先に使ってから外に出すSaaS化
1つ目の型は、自社の業務を効率化するために作った仕組みを、自社で運用して手応えを確かめてから外部に提供する形です。
WalkersのFDE-NOAHは、自社の経営で先に運用している
WalkersのFDE-NOAHは、メール・営業・経理・議事録など会社の定常業務をAIが監視・自動処理し、判断が必要な場面だけ人に届ける仕組みです。1社ごとにデプロイする形をとり、外に出す前にWalkers自身の経営で先に運用しています。
この型の強みは、最初のユーザーが自社であることです。どこで止まるか、どの判断を人に戻すべきか、運用してみないと分からない点を、自社の業務で先に洗い出せます。自社が毎日使っている仕組みは、外部の顧客に説明するときの説得力が違います。
SaaS化の型が向く会社と注意点
この型が向くのは、社内に繰り返しの業務があり、それを自分たちで改善したいと思っている会社です。見積もり作成、進捗報告、請求、議事録など、受託開発会社の運営にも定常業務は多くあります。
注意したいのは、自社の業務に合わせすぎることです。自社の手順をそのまま固めると、他社では使えないものになります。外に出す前に、別の会社に試してもらい、どこを設定で変えられるようにするかを決めておきましょう。自社で運用している間は、止まった場面、人に戻した判断、手で直した作業を記録しておきます。その記録が、外部に提供するときの設定項目や導入手順の下書きになります。受託で顧客に納品するときの運用マニュアルと同じ考え方で、自社向けの説明書を先に作っておくイメージです。
業務知識をプロダクトにする考え方は、BPO・事務代行の自動化が進む前に、業務知識をプロダクトにする方法でも取り上げています。
型2：受託で作った仕組みを別の顧客に広げる横展開
2つ目の型は、受託で作った仕組みの型を、同じ課題を持つ別の顧客に広げる形です。受託開発会社にとって、いちばん自然に始めやすい型です。
受託の実績を並べると、同じ型が繰り返し出てくる
Walkersの公開している開発事例を並べると、似た型が何度も出てきます。京都大学の研究室の申込から外部業者への引き渡しまでを管理するシステム、語学学校の台湾トークの顧客と講師を一か所で管理するシステム、山本製作所から受けたエンドクライアント向けの予約アプリ、高福合同会社「ツナガル」のコミュニティ会員システム。業種は違っても、申込・予約・会員・管理という骨格は共通しています。
自社の受託実績でも、同じ整理ができます。過去の案件を業種ではなく機能の骨格で並べ直すと、3回以上作っている型が見つかることがあります。何度も作っている型は、それだけ需要があることの証拠です。どの自社事業を選ぶかの棚卸しの方法は、受託だけの会社がAI時代に始める自社事業の選び方で説明しています。
横展開の形は、受託の延長から選べる
横展開といっても、いきなり月額課金のSaaSにする必要はありません。共通部分を自社の型として持ち、導入のたびに顧客ごとの設定と調整を受託として請ける形もあります。受託の売上を保ちながら、1件ごとの作業時間を短くできるので、受託開発会社には始めやすい形です。
型の導入が増えてきたら、設定で変えられる範囲を広げ、月額の保守や利用料に移していきます。受託の見積もりに「型の利用料」と「調整の作業費」を分けて書くところから始めると、顧客も違いを理解しやすくなります。
横展開の前に、成果物の権利を確認する
横展開でいちばん気をつけたいのが、成果物の権利です。受託で作ったコードやデザインの権利が顧客にある場合、そのまま別の顧客に使うことはできません。秘密保持の範囲、競業を避ける約束、再利用してよい範囲も契約によって違います。
確認すべき点は、受託の成果物を自社製品に使ってよいか｜契約で確認する5つの点にまとめています。判断に迷う場合は、弁護士など専門家に確認してください。これから受ける案件では、汎用部分の権利を自社に残す条項を相談するのも一つの方法です。
最初の顧客は既存顧客と有料モニターで
横展開した仕組みの最初の顧客は、同じ課題を持つ既存顧客か、その紹介先が候補になります。受託の延長として試作を見せ、反応がよければ有料モニターとして使ってもらいます。ハコブネ式の原則「実績は有料モニターで」のとおり、少額でも払ってもらった実績をもとに正規リリースへ進みます。
型3：他社の事業を譲り受ける事業譲受
3つ目の型は、すでに動いている他社の事業を譲り受ける形です。ゼロから作るのではなく、ユーザーやサービスごと引き継ぎます。
WalkersはAivis Projectの事業譲受を発表した
Walkersは、JPchain株式会社が運営していたAI音声合成のAivis Projectについて、全事業を2025年5月31日付（予定）で譲り受けることに合意したと発表しました。AivisSpeechやAivisHubなどのサービスは継続して提供するとしています。
受託開発会社が事業譲受を検討できる理由の一つは、開発と運用の力を持っていることです。すでにあるサービスを保守し、改善を続ける仕事は、受託で日々やっている仕事と近いものです。
事業譲受は、引き継ぐ前の点検が多い
事業譲受は、ゼロから作るより早くユーザーを持てる一方で、確認することが多い型です。コードの状態、利用規約、ユーザーとの約束、運用にかかる費用、引き継ぐ人の有無などを、事前に確かめる必要があります。
契約や税務の判断は、必ず弁護士や税理士など専門家に相談してください。受託開発会社が単独で判断できる範囲を超えることが多いので、3つの型の中でいちばん準備に時間をかけるべき型です。事業譲受は「早く始められる型」ではなく、「引き継ぐ前の点検に時間を使う型」と考えておくと判断を誤りにくくなります。
3つの型をどう選ぶか
3つの型は、始めやすさと必要な準備が違います。自社の状況に合わせて選びましょう。
- SaaS化：社内に繰り返しの業務があり、自分たちで使いながら改善できる会社に向く
- 横展開：同じ骨格の案件を何度も受けていて、既存顧客に提案できる会社に向く
- 事業譲受：開発と運用の体制があり、引き継ぐ前の点検に時間とお金をかけられる会社に向く
どの型でも、受託と並行して進める
どの型を選んでも、受託を止める必要はありません。ハコブネ式の4段階では、受託ほぼ100%から始め、有料モニターの段階で9割、正規リリースで5〜7割、自社プロダクトの段階で5割以下が目安です。あくまで目安で、会社の固定費や人員によって変わります。
型ごとに、失ってよい時間とお金を先に決める
ハコブネ式の原則に「上限を決めて大胆に」があります。どの型を選ぶにしても、3か月で使う社内の工数と外部費用の上限を先に決めておきます。受託開発会社は、案件の見積もりでは工数を細かく管理していても、自社プロダクトの工数は管理していないことがあります。
自社プロダクトにも案件番号を振り、受託と同じように工数を記録すると、上限に近づいたことに気づけます。上限に届いた時点で、続けるか、型を変えるか、止めるかを判断します。
小さく出して、反応で方向を変える
Walkersは、AIプロンプト活用プラットフォームのPrompt Labを、MVPとして構想から3週間でベータ版リリースしたことがあります。また、事業開発ラボとして複数の新規事業を並行して進めています。最初から大きく作らず、小さく出して反応を見るほうが、受託と並行しやすくなります。
ハコブネ式の原則「売れなくても沈まない」も、受託開発会社に向いた考え方です。売れなかった試作も、受託の提案や実績、次の案件の部品として回収できます。
よくある質問5選
質問1受託開発会社が自社プロダクトを持つと、受託の顧客と競合しませんか？
顧客と同じ市場に出る場合は、契約上の競業の約束や関係への影響を確認する必要があります。顧客の業務を楽にする仕組みとして提案する形なら、競合ではなく受託の延長として受け取られやすくなります。
質問23つの型のうち、最初に試すならどれですか？
受託開発会社が始めやすいのは、横展開か自社業務のSaaS化です。どちらも、すでに持っている実績や業務から始められます。事業譲受は準備に時間がかかるので、体制が整ってから検討するのが現実的です。
質問3受託で作ったコードを横展開に使えますか？
契約によって変わります。成果物の権利の帰属、秘密保持、再利用の範囲を契約書で確認してください。判断に迷う場合は、弁護士など専門家に相談しましょう。
質問4自社プロダクトに回す人員がいません。
最初は専任を置かなくてもかまいません。週4時間など自社の枠を先に押さえ、AIで受託の作業を短くして時間を作る方法があります。手が回らない案件を信頼できる協力先に回すのも一つの方法です。
質問5事業譲受の相手はどうやって探せばよいですか？
まずは自社の開発と運用の力で、どんな領域のどんな規模の事業なら引き継げるかを書き出してください。条件がはっきりすると、取引先や知人に相談したときに話が具体的になります。契約や税務の確認は、必ず専門家と進めてください。
まず過去の案件を機能の骨格で並べ直す
最初の一歩として、過去1〜2年の受託案件を業種ではなく機能の骨格で並べ直してみてください。申込、予約、会員、管理、集計。何度も作っている型と、自社で毎日使っている仕組みが見えたら、それが横展開やSaaS化の候補です。
ハコブネは、受託と自社の新規事業を並行してきた株式会社Walkersが運営する、AI×事業開発のコミュニティです。並べ直した候補からどの型を選ぶか、既存顧客にどう提案するかを、Discordやオンライン交流会で会員同士で相談しながら進められます。入会を前提にしないオンラインの無料相談会もあるので、自社の状況を話すところから始めてみてください。
この記事について
池田は、ITとノーコードの事業開発・教育事業の立ち上げを経て2021年にWalkersを共同創業。100件以上のシステム開発に携わり、要件がまだ固まっていない案件や、他社から引き継いだ開発の立て直しを担当しています。
株式会社Walkersは、AI駆動開発・ノーコード開発のシステム開発会社です。累計開発実績300件、200社以上の支援、自社メディアの累計100万PV。受託開発と並行して、自社でも複数の新規事業を立ち上げています。
この記事で触れた事例の出典
最終更新：2026年10月21日