[ Management ]

少人数で受託と自社開発を同時に走らせることの難しさ

少人数チームで受託と自社プロダクト開発を並走できているのは、AI が定型的な前段の作業を吸収するからであり、人間は判断・関係構築・設計に集中できる構造になっている。

Author: 森本拓見
#case-study #業務自動化

少人数で受託と自社開発を同時に走らせることの難しさ

「受託案件をこなしながら自社プロダクトを育てる」——経営者や事業責任者なら、この両立がどれほど難しいか肌で感じているはずです。

受託は納期と品質に責任を持つ仕事です。クライアントの要件を聞き、提案を作り、実装をチェックし、課題が出れば対応する。これだけで人手が必要です。一方、自社プロダクトは長期的な価値構築を担います。市場調査、プロダクト設計、継続的な改善——どれも受託の緊急性に負けやすい仕事です。

多くの小規模開発チームが直面する現実は、「受託で食いながら、隙を見つけて自社開発に当たる」という綱渡りです。結果として自社プロダクトは進度が落ちる。外部からは「本当に実力のあるチームなのか」判断しにくくなります。外注先選びで実績を重視するのは、このためです——「誰が、何を作ったか」が見える方が信頼しやすいからです。

八雲も同じ課題を抱えていました。

AI による定型業務の吸収

私たちが選んだ方法は、「定型的な前段の仕事を AI に任せる」ことでした。

受託でも自社開発でも、実は定型的な作業が意外と多い。受託のプロセスなら、営業資料の作成、見積書や提案書の生成、案件進捗の記録・報告です。コンテンツ制作でも、テンプレートに従う書類やデータ整理、動画・ブログのラフスクリプト作成などです。

HUMAN_INPUT: 以下の具体的な時間削減数字が必要です(例:営業書類作成が月 30 時間 → 5 時間に削減など)

これらの仕事を 100% 自動化することはできません。しかし 70~80% は AI に任せて、人間は最終チェックと判断に集中することはできます。営業なら、提案内容が顧客にふさわしいか、競合とのポジショニングは正しいか。コンテンツなら、データの解釈が正確か、読者に伝わる表現になっているか——こうした判断を人間が担うわけです。

具体的には以下のような業務を自動化・支援しています:

  • 営業・提案業務:案件情報をまとめると、提案書や見積書のドラフトが自動生成される
  • ブログ・記事制作:企画から初稿まで、仕様に基づいたドキュメント作成を支援する
  • データ管理:決算短信や市場データを毎日自動取得し、スプレッドシートに蓄積する

データ取得は特に顕著です。人間が毎朝ニュースサイトや企業 IR を巡回し、必要なデータを手で入力する——こうした作業は完全に自動化できます。結果として担当者は「取得されたデータを見て、事業判断をする」という本来の仕事に戻ってきます。

人間と AI の役割分担で実現したビフォー/アフター

この構造の効果は、人的資源の使い方が劇的に変わることです。

導入前:

  • HUMAN_INPUT: チーム人数、受託件数、自社プロダクト数の具体値が必要

少人数で複数のプロジェクトを回すと、個人が複数の役割を抱えます。営業を担当する人も、ブログを書き、データを整理する。切り替え負荷が高く、深い思考が必要な設計や関係構築が後回しになります。

導入後:

  • 定型業務に充てていた時間が 50~70% 削減される
  • その時間を「判断」と「関係構築」と「設計」に使える
  • 受託品質が向上し、自社プロダクトも並行して進む

具体的な例を挙げれば、営業提案にかかる時間が従来月 30 時間だったとすると、今は 8~10 時間で済みます。HUMAN_INPUT: 実際の削減時間を確認してください。その浮いた時間を、クライアントとの本質的な相談に当てたり、新しいプロダクト企画に当てたりできます。

受託の案件品質は、営業資料の丁寧さではなく、「顧客の真の課題を理解し、最適な提案をできるかどうか」で決まります。AI が初期書類を作れば、営業担当者は顧客との対話に時間を使えます。

同様に、ブログやメディア発信も、「何を書くか」という企画が一番大事です。骨組みや初稿の生成を支援すれば、編集者は戦略的な判断——どのテーマが読者にとって価値があるか、どのタイミングで公開するか——に集中できます。

予想外の副次効果

並走してみると、受託と自社開発が互いに学びをもたらすことに気づきました。

受託プロジェクトで顧客の課題を深掘りするプロセスで得た知見が、自社プロダクトの設計に反映される。逆に自社プロダクトで確立した仕組みが、受託案件の提案内容になる。小規模チームだからこそ、この循環が速く回ります。

HUMAN_INPUT: 具体的な相互学習の事例があれば記載(例:受託案件で得た課題解決法が自社プロダクト X の機能になった、など)

また、チームとしてのプロセスが透明化されました。「何をどのツールで、誰がチェックして、どう保存するか」が明確に記録される。人が増えたときの教育材料になりますし、顧客からも「どういう体制で進めるのか」という質問に具体的に答えられます。外注先の実力を判断する際に、実績だけでなく「プロセスの丁寧さ」を見る発注者は多い。その点での信頼が生まれました。

小規模チームへのメッセージ

「少人数では受託一本に絞るしかない」「自社プロダクトを育てるなら受託は諦めるしかない」——こういう二者択一の考え方は、もう古いかもしれません。

AI を活用することで、受託と自社開発の並走は現実的になります。ただし前提条件があります。

ひとつは、「AI は完全自動化ではなく、人間の判断を支援する」というマインドセットです。自動化できる部分は徹底的に自動化しつつ、最終的な判断責任は人間が持つ。この緊張関係を保つことで、品質と効率の両立が生まれます。

もうひとつは、プロセスの設計です。「何をどこに保存するか」「誰が判断するか」を明確にしておかないと、AI の出力がバラバラになります。HUMAN_INPUT: チーム内での役割分担や意思決定フロー、ドキュメント管理の具体的なルールがあれば記載。

小規模チームは、大規模組織より身軽です。AI との協働モデルを試行錯誤して、自分たちのスタイルを作れる。実装で語る——私たちはそれを意識的にやっています。営業資料や提案内容でプロセスを説明するのではなく、「実際にこう進めています」という具体的な成果物で示す。その方が説得力がある。

HUMAN_INPUT: 最後に、読者向けのメッセージ(並走を検討している経営者・事業責任者向け)を強化する内容があれば。例:八雲への相談のきっかけになる問い かけ

受託と自社開発の両立で悩んでいるなら、まずは「どの業務が定型的か」を棚卸ししてみてください。営業書類・ブログ・データ整理など、フォーマットが決まっている仕事はAIの得意分野です。そこから始めれば、チームの可処分時間が増え、本来やりたかった仕事に集中できるようになります。


注記:本文には以下の HUMAN_INPUT マーカーがあります。公開前に確認が必要です。

  • NUMBERS:チーム規模、受託件数/月、自社プロダクト数、AI による時間削減の具体値(削減前後の時間)
  • BEFORE_AFTER:具体的なビフォー/アフター数字(例:営業提案月 30h → 10h)
  • BUSINESS_CONTEXT:受託と自社開発の相互学習事例、内部ルール
  • SIDE_EFFECT:予想外の効果や学び(必要に応じて追加)
  • REFERENCE:最後の読者へのメッセージを強化する内容
ShareShare on X