こんにちわ。稲井田です。今回は自社事業と受託事業の相乗効果のお話です。
いきなりですが、皆さんの会社では「自社事業」と「受託事業」の間に、見えない境界線を引いていないでしょうか。「受託はあくまで収益のため、自社事業こそが本丸」といった空気感です。あるいはその逆で、受託開発で忙殺され、自社プロダクトが常に後回しになっているケースもよく聞きます。
自社事業を育てる資金を受託事業で確保する構造は合理的です。ただし、両者を別々の仕事として扱うと、自社で得た運用知識が提案へ戻らず、受託で見つけた課題も自社の改善へ生かされません。経験を行き来させる仕組みがあって初めて、二つの事業が互いを強くします。
今日は、私が経営と現場の検証を通じてたどり着いた、「事業をつくる側と支援する側を分けない」という働き方と、そこから生まれる実践知についてお話しします。
なぜ「分け隔てる」と損をするのか
受託事業を「下請け」や「作業」と捉えてしまうと、どうしても視点が短期的になります。納期を守り、要件通りに納品する。これは大事ですが、それだけでは「言われたことをやる」という思考停止に陥りやすい。
一方で、自社事業ばかりに没頭すると、市場の厳しいフィードバックから遠ざかり、独りよがりなプロダクトを作ってしまうリスクがあります。いわゆる「良いものを作れば売れる」という、経営者にとって一番危険な罠です。
私たちがWeb制作やEC、業務システム構築といった現場でAIを組み込む際、あえて自社・受託の垣根をなくした理由もここにあります。支援先で得た「現場のリアルな課題」は、そのまま自社プロダクトの改善ヒントになります。逆に、自社で苦労してAIを組み込んだノウハウは、受託の現場でクライアントのコスト削減や効率化として即座に還元できます。
これらは別の仕事ではなく、同じ「価値を生む」というプロセスの表裏なのです。
循環を生むための「判断基準」
では、この循環を現場でどう回せばよいのでしょうか。明日から使える判断基準として、私は「その悩みは、他でも使えるか？」を常に自問するようにしています。
例えば、あるクライアントの業務システムでAIを用いたデータ分析機能を実装したとします。ここで「納品して終わり」にするのはもったいない。その実装過程でつまずいたエラーや、うまく動いたプロンプトの構成、あるいは業務フローの設計自体を、自分たちの「事業開発のライブラリ」としてストックします。
この時の判断基準は明確です。
- 個別特化しすぎていないか？
- 汎用的な解決策に抽象化できるか？
- 自分たちの「次の一手」に使える材料が含まれているか？
この視点を持つだけで、単なる作業が「知の蓄積」に変わります。現場でAI活用を検証する際も、社内ツールで成功した手法をすぐにクライアントの課題解決に当てはめる、あるいはその逆を試みる。この試行錯誤の往復運動こそが、私たちのような小さな組織が、大きな変化に追いつくための唯一の武器だと感じています。
理想と現実の狭間で
もちろん、綺麗事ばかりではありません。正直、自社事業と受託事業を並行させるのは物理的にも精神的にもハードです。時には「今月は受託案件に追われて、自社開発のコードが全く進まなかった」と落ち込むこともあります。
でも、それでいいのだと今は思っています。完璧にバランスを取ろうとするから疲れるのです。大切なのは、両方を「別の箱」として管理せず、一つの大きな「事業検証エンジン」として捉えること。そうすれば、受託で稼いだお金と経験が、そのまま自社事業の燃料になります。
もし今、皆さんが「受託の仕事ばかりで自分の武器が磨けていない」と感じているなら、まずはその受託の現場で使っているツールや手法を、少しだけ「自分たちの事業にどう転用できるか？」という視点で眺めてみてください。
結論：境界線を引くのをやめる
「事業をつくる側」と「支援する側」。この二つを分断する壁を取り払うと、驚くほど視界が広がります。
支援先での成功体験は、自分たちの事業の信頼性になります。自社での失敗経験は、クライアントに「ここは危ないですよ」と教えられる、かけがえのない助言になります。私たちはこれからも、Web制作や各種システム開発の現場で、AIを工程全体に組み込みながら、この循環を愚直に試し続けます。
もし今、手元の業務が単調に感じているなら、それは境界線を引いてしまっているサインかもしれません。今日から、その業務の中に「自分の事業への種」を探してみてください。案外、すぐ足元に転がっているはずです。
