BPaaSとは
この記事は何か
最近話題の「BPaaS」という事業モデルについて，そしてBPaaSモデルの可能性について解説したものです。
また，どうやってkubell（旧Chatwork社）がBPaaSモデルに辿り着き事業化に至ったのかについてもBizDev視点からも記載しています。
なぜ公開するのか
最近，BPaaSというワードが世の中に広まりつつあるという実感値があります。Googleトレンドでも2011年頃にBPaaSという言葉が誕生(?)してから少しずつ認知されてきており，特に直近で検索数も増えており「なんか最近，BPaaSって流行ってきてるの？」という方もいらっしゃるのではないでしょうか？
kubellは22年12月期の本決算説明資料にて初めて「BPaaS」というコンセプトを発表しました。SMBをメインターゲットとしてビジネスチャットを中心とするDXソリューションを展開してきた弊社がどのようにしてBPaaSモデルに辿り着いたのかも含めて公開します。
詳細は後述しますが，ソフトウェアの提供だけではSMBのDX推進は今後頭打ちになるのではという壁に当たり，新たなアプローチを模索し続けた結果辿り着いたコンセプトです。裏を返すと，SaaS企業にとって新たな競争戦略（SaaSの次の潮流）になると考えています。
また，我々のようなSaaSモデルを主軸として展開していた会社を中心に各社このBPaaSモデルに可能性を感じているようで，この領域に進出されている会社もよく耳にするようになってきました。
この1年ぐらいで急激に増えていて「なんかBPaaS盛り上がってるっぽい」ようです。（BPaaSを一緒に盛り上げていけると嬉しいです！）
とは言え，まだまだ新しいモデルということもあり「そもそもBPaaSって何？」「BPOとは違うの？」「SaaSの会社がそこに進出すると利益率下がるんじゃないの？」などなどたくさん疑問もあるかと思うので，我々も道半ば（というかまだスタート切ったばかり）ながらも，簡単に解説できればと思います。
これからのソフトウェア企業の競争戦略について
LLMをはじめとするAIの劇的な進化，金利上昇の影響によるSaaSのマルチプルと売上成長率の相関関係の変化など，ここ数年で劇的にソフトウェア業界を取り巻く環境が急激に変容しています。
前提
事実（とその解釈）と仮説によって構成されるもので、戦略体系全体に大きな影響を及ぼす最重要要素。
ウチのCOOが言ってる「前提」のことを指します。戦略の構成要素としては最重要です。
前提が変わったことにより，ソフトウェア企業はこれまでの「何としてでも成長モード」から「効率的に成長するモード」へと舵を切る必要があり，また，テクノロジーの進化をいかに自社のプロダクトやビジネスに取り込むかを思案する必要があります。
その中でソフトウェア企業の競争戦略の潮流として
①コンパウンドスタートアップ化
②M&Aの増加
③FinTechとの接続
④BPaaSモデルの登場
などが挙げられるのではないかと思います。
それぞれを話すと長くなるので，今回①~③は割愛しますが，この数年の環境の劇的な変化により，ソフトウェア企業はこれまでよりもかなり難易度の高い舵取りを求められる状況になりつつあります。一方で，このような潮目が変わる瞬間をうまく乗り切った企業が大成功しやすい時代に突入しているのではないかと思います。
BPOについて
BPOとは「Business Process Outsourcing」の略称で、企業の業務を外部の専門業者に委託することを指します。具体的には、人事・経理・総務・カスタマーサポートなどの業務を外部のBPO企業に委託します。その結果、コスト削減や業務効率の向上を図れるでしょう。
大企業のバックオフィス業務やコールセンターやヘルプデスク業務のような，一定規模以上の業務ボリュームがあり，且つ，ノンコア業務と言われる外部に委託したとしてもその企業の競争力の源泉ではない領域における活用が2000年代ごろから急速に進んできました。
企業は業務の効率化・コスト削減・コア業務へのリソース集中を目的として，積極的に外部に業務の一部を委託しています。
テクノロジーの進化に伴い，BPO業界も激戦化しており，ITシステムの活用を伴った効率化された業務フローを構築し業務遂行をすることが求めらています。
近年では，大企業向けに総合コンサルが上流で戦略設計を行い，システム設計〜導入，そしてBPOとして業務運用まで支援をしています。
中小企業のBPO活用状況
一方で，中小企業のBPO活用は進んでいません。
企業規模が小さければ小さいほど利用割合が少ないのが現状です。
理由は様々ですが，一番大きな要因としては，業務ボリュームが少ない為，1社に対してオーダーメイド型で，システム設計〜導入，運用支援をしようとするとBPOベンダーからするとビジネスとして成立しない（裏を返すとユーザーからは料金設定が高く手が出ない）という構造になっていることです。
一方で，企業規模の大小にかかわらず，利用意向は同程度となっています。
また，外部人材の活用について従業員数が少ない企業ほど人手不足の解消を目的としています。
大企業と比較して人手不足がより深刻な中小企業が業務の一部を外部に委託することにより，コスト削減が可能なのであれば，利用が拡大していくことは容易にイメージできます。
つまり，中小企業におけるBPO市場には，ニーズはあるものの，業務ボリュームの大きさによる価格の不均衡という構造的な負が存在しており，現在の日本にはこの負を解消できるソリューションが存在していないのです。
海外事例から見る日本の現状
米国ではPEOというスキームが存在しています。
この仕組みを使って以下のような会社がSMBのアウトソーシングを受けています。（特にPaychexの事業展開や戦略は非常に面白いのでこれはこれでぜひ気になる方は調べてみてください）
Paychex
Insperity
ADP
一方，日本では2024年現在,共同雇用＝元企業・PEO会社双方との二重の雇用関係を維持する米国版PEOをそのまま実施すると，職業安定法第44条で禁止される労働者供給事業に該当し，違法となる理解です。
また，本人の同意のもとPEOサービス提供企業に転籍をさせ（つまり元企業との雇用関係は切断させ）た上で,特定労働者派遣に切り替えるスキームで元企業に派遣労働者として派遣する手法ならば適法となるのでは？という点についても，2012年の労働者派遣法改正で導入された第35条の５と第40条の９により,原則禁止されるに至っています。
（離職した労働者についての労働者派遣の禁止）
第三十五条の五 派遣元事業主は、労働者派遣をしようとする場合において、派遣先が当該労働者派遣の役務の提供を受けたならば第四十条の九第一項の規定に抵触することとなるときは、当該労働者派遣を行つてはならない。
（離職した労働者についての労働者派遣の役務の提供の受入れの禁止）
第四十条の九 派遣先は、労働者派遣の役務の提供を受けようとする場合において、当該労働者派遣に係る派遣労働者が当該派遣先を離職した者であるときは、当該離職の日から起算して一年を経過する日までの間は、当該派遣労働者（雇用の機会の確保が特に困難であり、その雇用の継続等を図る必要があると認められる者として厚生労働省令で定める者を除く。）に係る労働者派遣の役務の提供を受けてはならない。
つまり，今後も日本版PEOの実現は難しいと考えるのが自然だと思います。法規制の観点においても，日本の中小企業はBPOを活用することが難しい構造的な負が存在しています。
中小企業の現状
外部に委託するのが難しい企業は自社でシステム導入を進めて業務効率化を進めて，自社内で完結するしか方法はありません。
①あるべき姿を描き
②課題を特定し
③最適なシステムを選定し
④そのシステムを導入し
⑤効率的な運用フローを構築し
⑥社員に正しく使ってもらい
⑦運用改善していく
これらすべてを自走する必要があります。
7つのフェーズに単純化しましたが,これを見ただけでいかにハードル高いか想像出来るかと思います。そもそも人材も資金も豊富な大企業であっても社内で完結できないから,外部に丸投げをする選択をしている中で,全てを社内で完結し自走できる中小企業は相当レアケースです。
自社でシステム開発をすることも難しく，システム開発から運用設計を外部に委託する資金が潤沢にある訳ではない為，SaaSの活用が鍵になります。
しかし，SaaSの活用にも一定のハードルがあることもわかってきました。
kubellでは2021年4月からDX相談窓口として，さまざまなパートナー様とのアライアンスを通じ，幅広くSaaSの活用に関するご提案を続けています。
顧客課題とツールのマッチングを前提としてモデルで，主にChatworkの既存ユーザーに対して，「最適なシステムを選定」の価値提供をしてきました。累計で数万件の相談を受ける中でわかってきたこととして，この取り組みに一定の手応えもある一方で，
①あるべき姿を描き
②課題を特定し
③最適なシステムを選定し
④そのシステムを導入し
⑤効率的な運用フローを構築し
⑥社員に正しく使ってもらい
⑦運用改善していく
のうち③しか提供できていないのではないかという結論に至りました。
実際に相談をいただくお客様からも「社員が使えるイメージが湧かない」「良いプロダクトだとは思うが現状で満足している」「DXを推進しようとしてツールを入れたが使いこなせずコストが増えただけ」「ウチにはまだ早い」といったお声をいただくことも非常に多くあります。
事業としては順調に拡大できているものの，このままでは中小企業のDX推進にはかなりの時間を要する（さらに大企業との差がついてしまう）ということで③以外の部分をどうすれば提供できるのか模索していました。
構造理解
中小企業の直近のDXの取り組み内容です。
1位はホームページの作成となっており，我々が想像をするDXとはかなり距離があるように感じます。
また，DXに期待することの上位2つは業務の効率化とコストの削減となっています。
DXは手段であり，真に顧客が困っていることは
・生産性が高い人材の獲得が難しいこと
・現状のオペレーション業務のコストが高いこと
であり，「DXに資するツールを導入するのが難しいこと」ではありません。DX相談窓口で実際に顧客から聞く声とも合致していました。
多くの顧客からすると，DXが進んだか否か，どんなツールを使っているかに関してはあまり興味がなく，人が足りておらず面倒な業務がコストが安く回っていれば良いのではないかという仮説を持ちました。
解決策
解決策の検討を進める中で，これはやはり，課題とツールのマッチングだけではやはり不十分で，いっそのこと我々が③以外のオペレーションも含めて巻き取ってしまえば良いのではないかという結論に至りました。
①あるべき姿を描き
②課題を特定し
③最適なシステムを選定し
④そのシステムを導入し
⑤効率的な運用フローを構築し
⑥社員に正しく使ってもらい
⑦運用改善していく
乗り越えないといけない壁
しかし，どうしても業務ボリュームが小さく採算が合いません。また，米国のようにPEOスキームとして事業展開することもできません。（本当に困った。。）
ヒントになったのは，
・総合コンサルの戦略
・シェアードサービスの構造
・クラウドサービスのアーキテクチャ
・⚪︎⚪︎⚪︎社の事業展開
の4つでした。（すいません。4つ目は秘密です。別業界の企業様です）
総合コンサルの戦略
総合コンサルは戦略策定から，つまり上流から下層階にロックインし，システム導入とBPOをデリバリーしているのではないかと思います。（コンサル業界は詳しくないです。間違ってたらごめんなさい！）
「なるほど。上流での設計とシステム導入とBPOをパッケージとしてデリバリーすれば良いのか」これは良い気づきでした。
が，各社に対してオーダーメイド型でコンサルティングをしていく訳にはいきません。そもそも，戦略策定のコンサルティングには，中小企業にとってはかなりの規模の投資金額になるため，一歩目が踏み出せないからです。
シェアードサービスの構造
シェアードサービスとは複数のグループ企業からなる企業が，ノンコア業務を1カ所に集約させる企業改革のことを指します。
グループ会社にあるノンコア・バックオフィス業務の内容は基本的に共通するため業務プロセスを統合・標準化し，一箇所に集約することで，グループ企業全体の業務効率化やコスト削減に繋がります。
「なるほど。散らばっているけど，実は共通している業務を一箇所にまとめれば良いのか」「・・・ん？これを社会全体で実現できると凄いことできそう」これも良い気づきでした。
クラウドサービスのアーキテクチャ
なんとなくオンプレからSaaSへの移行の流れっぽいなということで，SaaSってなんだっけ？というのを再考していたところ，マルチテナンシーやパブリッククラウドからも着想を得ることができました。
パブリッククラウドとは、クラウドサービス提供事業者が構築した環境を、他の利用者と共同利用するタイプの利用形態のことです。使いたいクラウドサービスのみを、使う分だけ利用料を払って使用します。自社独自の環境を作るのではなく、既存のサービスから必要なものを選んで組み合わせるのが特徴です。
マルチテナント・ソフトウェア・アーキテクチャー（ ソフトウェア・マルチテナンシー とも呼ばれる）では、1つのソフトウェア・アプリケーション（およびその基盤となるデータベースとハードウェア）のインスタンスが、複数のテナント（またはユーザー・アカウント）にサービスを提供します。 テナントは個々のユーザーであることもありますが、より一般的には、アプリケーション・インスタンスへのアクセスと権限を共有する、顧客組織などのユーザー・グループです。 各テナントのデータは、アプリケーション・インスタンスを共有している他のテナントからは見えないように隔離されており、すべてのテナントのデータ・セキュリティーとプライバシーを確保しています
「なるほど。複数の会社でクラウド上に存在するリソースを共通利用できるようにすれば良いのか」「いつでもインターネットを介してアクセスできるようにプロセスそのものもクラウド化すれば良いのか」これは完全に良い気づきでした。
なんとなく見えてきた全体像
改めて，全体像を整理している図です。（このnoteで最重要です）
SMBに展開する為には，できる限り汎用的な形でサービス価値を提供し，低価格で展開していく必要があります。
したがって，図の右の方に寄っていく必要があります。
また，システムによる解決はツールを使いこなせるDX人材が不足していることから，オペレーションによる最適化を行うことによってハードルを下げる必要があります。
したがって，図の上の方に寄っていく必要があります。
お気づきの通り，右上に寄ることが展開可能性を最大化するうえで必要ですが，普通にやると右上に行けば行くほど利益率が低下します。
つまり，ビジネスとしての難易度が高くなる為，積極的にこの領域に進出する企業は存在していなかったのではないかと思います。
今，世の中に存在しているSaaSやBPO周りのビジネスモデルとのマッピングは以下のように整理しています。
上記の6象限はそれぞれ以下のような整理となります。
⑴Exclusive × Operation領域
⑵ Customize × Operation領域
⑶ General × Operation領域（※ここがBPaaSの領域です）
⑷ Exclusive × System
⑸ Customize × System
⑹ General × System
事業化の検討
Customer Problem Fit（Burning needsの発見）
⑶のGeneral × Operation領域が空いてるのではないかという仮説が出てきました。後々，営業する中で気づいたことですが，ここの一部を埋められている会社は契約社員や派遣社員の活用ができていました。ただ，作業マニュアルを作成するなどして汎用的な作業化（つまり型化）ができる企業に限られていることにも気づきました。
また，契約社員や派遣社員を雇用するほどボリュームがないということもユーザーアンケートにて明確に出てきました。
アンケートだけではなく，サービスの正式ローンチ前に，フィジビリとして実際に営業をする中で
・定期的に頼みたいことはないかもしれない
・仮に採用できたとしてもその人の業務が埋まらない
・どの業務をどのぐらいのボリュームで外部に出せるか特定するのが難しい
・ある時期だけ忙しいけどそんなに都合よく業務をしてくれる人は見つからない
・契約社員や派遣社員に任せても辞めてしまったら困る
などの声をいただきました。
つまり，
・忙しい時期に絞って0.X人月だけ稼働してくれて
・自分で業務の運用改善を回してくれる自走力があって
・辞めない社員を
・お金をかけずにすぐに採用して
・固定費を変動費化したい
という”わがままな”Burning needsがあることがわかりました。ここまででCustomer Problem Fitが確認できました。
（Burning needsについてはAutifyの代表の近澤さんのnoteを参照ください）
BtoBスタートアップでPMFを模索している方々は是非以下を実践してみてください。
・製品の開発をやめて、顧客のBurning needsの特定に全注力する
・特定したBurning needsを、これまでより何倍も良い方法で解決する解決策を定義する
・解決策のプロダクトアイデアをプレゼン資料に落とし込み、営業活動を行う
・開発前から契約を獲得する。複数社当たっても前述の反応をされて契約が獲得できなかったら1に戻る
・製品を急ピッチで開発する
「Burning needsの解決なしに、成功なし」
Solution Problem Fit（解決策とプライシングの検証）
また，有償のサービスとして事業検証を進める中で一定の金額を払っていただきそれに満足いただけるということも明らかになりました。（実際に正式ローンチ前に50社以上が有償契約をしていただいているところからのスタートとなった）
時給ベースで4000~5000円の作業単価であっても上記のニーズを満たせれば，喜んでいただけることもこの時期に確認でき（23年時点の最低賃金の全国の加重平均額は1,004円）Solution Problem Fitも達成できました。
ビジネスとしても十分成り立ち，スケールできるということが確認できた為，事業化を正式に進めることになりChatworkアシスタントとしてローンチしています。（本当に自信を持ってオススメできるので興味がある方とりあえずお話し聞いてみてください！）
また，株式会社ミナジンのグループインによりさらに労務領域への展開も加速しています。（勤怠管理・給与計算でお困りの方ぜひご連絡ください！）
思わぬ誤算
おそらく，一番の壁になるであろうポイントは支援する会社のオペレーションを変える部分だと想定していました。
DXコンサルを経験したことがある方はどなたでも共感いただけるポイントだと思いますが，既存のシステムや業務フローを変更する（既存のフローとの接続）ことが一番難しく，この摩擦がプロジェクトが進まなくなる一番の要因です。
しかし，実際に中小企業のオペレーションに入り込むと，
・既存のシステムがない
・業務フローも特に決まっていない
というケースが非常に多いということがわかりました。
つまり現状の環境が整っていないからこそ，我々が一定の正解として効率化・パッケージ化されたプロセスの型をはめることの難易度が低いということです。
大企業のDXであれば，既存のシステムや業務フローとの摩擦が発生する為，時間がかかりますが，中小企業に対しては摩擦がありません。
中小企業のDXはリープフロッグ的な発展ができる可能性を秘めています。
リープフロッグ型発展（リープフロッグがたはってん、英：Leapfrogging）とは、既存の社会インフラが整備されていない新興国において、新しいサービス等が先進国が歩んできた技術進展を飛び越えて一気に広まること[1]。リープフロッグ現象ともいう[2]。
一例として、多くの新興国において固定電話の普及を待たずに携帯電話およびスマートフォンが急速に普及したことが挙げられる。
大企業と比較してDXが進んでいないからこそ，中小企業がBPaaSを通して，一気に業務効率化をし，DXの進捗度において逆転できる日も近いかもしれません。
kubellのBPaaSの現在地
今まさにPMFを迎えつつあり，グロースフェーズを迎えています。
BPaaSはその名の通り，プロセスそのものをクラウド経由で提供するものであり，このプロセスの正解の型をいかに早くたくさん作って展開できるかが鍵になってきます。SaaS・AI等をオペレーションに組み込みながら，型化・汎用化を職種単位ではなく，タスク単位で細切れにして展開していく必要がある為，おそらく最終的には，何千個もの型化された正解のプロセスが完成することになると思います。
まだまだ，ユーザーのオペレーション改善をしながら正解の型を作っていく途中です。
kubellにしかできない事
顧客基盤を持っている（マーケティングの優位性）という観点
この構造を社会全体で実現するには，どの会社にも共通する業務を，大量に集める必要がありますが，これは非常に困難です。
非ITセグメントの中小企業に対してマーケティング・セールス活動を行うことは投資対効果が非常に悪く，大きなマーケティングをした瞬間，赤字になりやすい構造になっています。
一方で，kubellはすでに，44万社・685万ユーザーの顧客基盤があり，これが大きなアドバンテージとなっています。
また領域の特性上，閑散期にはノンアクティブなユーザーも出てくることもありますが，一度アクティブになったユーザーと一度チャットで繋がっている為，忙しくなった瞬間に再度依頼をいただくことができます。Chatworkというプロダクトは毎日お使いいただいているので，そのままグループチャットで依頼をするのみで非常にハードルが低いポジションを取れています。
チャットの面を持っている（オペレーション上の優位性）という観点
基本的に何かのタスクを依頼・受領・納品するコミュニケーションはチャット上で発生しています。実際に業務の依頼をする際に皆さんもチャットで依頼することが多いかと思います。
Chatworkにはタスクという機能がありますが，毎日膨大な量のタスクが処理されています。
チャットを通してタスクの依頼（つまりプロセスの購入）ができるようになると非常に効率的です。これは我々にしかできない価値提供だと考えています。
つまり，Chatworkというプロダクトは「ビジネスチャット」として価値を提供するSaaSでもあり，プロセスとアウトプットを購買できるECサイトのようなイメージとして捉えることもできます。
BPaaSの未来
型化されたプロセスの自動化にも取り組み始めています。これにより，圧倒的に効率が上がる為，原価率が低減しさらに安価にサービス提供を可能にします。
型化されたプロセスに対して,LLMに基づく半自律的なエージェントをユースケースごとに大量生成していく展開を想定しています。全領域で完全自動化は難しく正確性が求められる業務や人間が処理した方がコスト感が合うものも出てくる為，人間とシステムとAIがインタラクティブに混ざり合うワークフローを設計する必要があります。このワークフローを回す中で人間のチェック（＝モデルへのフィードバック）がさらなる精度向上を産むサイクルも同時に設計する必要があり，難易度は高いですが，非常に面白いチャレンジになると考えています。
また，LLMを活用する場合，ユーザーがプロンプトを入力する（実際にはユーザーからはプロンプトは意識しなくて良い方向性で考えていますが）場所，そしてタスクが実行された結果が帰ってくる場所は必ずチャットになります。
kubell社がいかにLLM活用において，非常に良いポジショニングに立っているかお分かりいただけましたでしょうか。
今年からLLM活用を検討〜実装していくR＆Dの部隊も立ち上げました。興味ある方ぜひ話しましょう！めちゃくちゃ面白いと思います！
AIエージェントについては以下のPodcastが非常に参考になります！めちゃくちゃ良いのでぜひ聞いてみてください。
BPaaS事業を検討している方は必ず聞くべき内容かと思います。
BPaaSについてよくある質問
あくまでkubellが志向しているBPaaSという回答になる為，一般的な定義や解釈とは異なる場合があります。
BPO＋SaaSのこと？
BPOをSaaSを使って効率化することは結果的にはあると思いますが，それではBPOベンダーが色んなツールを使って効率化しているのと大差ないかと思います。「ツールの利用による効率化されたBPO」ではなく，「型化されたプロセスと人材を含むオペレーションをクラウド上で購入できるビジネスモデル」のことを指しています。
あくまでSaaSの利用は結果としてそうなるケースが多いという話かと思います。
業務をアウトソースすると，自社でオペレーション改善を行えなくなるので空洞化するのでは？
基本的に，コア業務ではなくノンコア業務の改善をメインとしています。
例えば製造業であれば「煩雑な従業員の給与計算業務など」ではなく「ものを作ること」に（時間や人などの）経営資源を集中することが，他社との差別化要因になります。
したがって，コア業務は自社リソースで集中いただき，その他の「その会社にとって煩雑な業務」であるノンコア業務をアウトソースし，効率化していただきたいと考えています。
BPOは人工ビジネスなので，提供者側に工数削減のインセンティブが湧かない（工数削減すると売上が下がる）のでは？
1:1の関係性（つまり個社ごとにカスタマイズされたBPO）であれば，工数削減のインセンティブが湧かない構造になると思います。
一方でBPaaSの場合は，個別のカスタマイズは極力行わず，汎用的なオペレーションで提供していくので，工数削減をするメリットが提供者側にも発生する構造にあります。
BPOとは何が違うの？
プロセスが型化されている点，それをSaaSのように環境の準備が不要ですぐに始められる点，必要な分だけ必要な時に利用できる点，デメリットとしてはカスマイズ性が乏しい点などが挙げられます。SaaSとオンプレの比較表とほぼ同じになるかと思います。
大企業向けには展開しないの？
可能性として0ではないと思います。
ただし，大企業には本社機能があったり，一定BPOベンダーが入っている点，既存のシステムやオペレーションが存在する為オペレーション変更に摩擦が生じる点，その企業特有のルールが存在しておりカスタマイズ性が求められる点などがあり，中小企業の方が相性が良いと考えています。
BPaaSに進出するなら，特定の業務に絞った方が良い？
型化をするという観点では，ユースケースをイメージできるものが存在しているに越したことはありません。一方で，事業として進める場合は，将来的な自動化を見越したうえで，できる限り握っているオペレーションの総量が大きい会社の方が利益額が最大化される為，なるべく大きく展開する方が良いと考えています。また特定の業務に絞りすぎるとその業務は発生する瞬間は非常に高い利益率になりますが，閑散期に関しては，作業者の稼働率が下がる為，利益率が下がります。
相性が良い領域は？
Vertical SaaSの会社は非常に相性が良いと思います。例えば介護業界のレセプト業務など，その業界特有のオペレーションが存在している領域で，そのオペレーションに特化して型化していくとというアプローチは筋が良いと思います。
相性が悪い領域は？
コア業務です。当たり前の話ですが，企業はコア業務に関しては外部に委託することを嫌がるので，マーケティング・セールスに苦戦します。
また，オペレーションを設計できるスペシャリストがいないが，一度作ってしまえばなんとかなるという領域は必ずHappy Churnが起こります。（これはSaaSのプロフェッショナルサービスに当たります）SaaSを提供している会社がオンボーディングの為にやるということであれば，非常に意義があると考えていますが，BPaaSの事業としては相性が悪いです。
なぜスポットワークやクラウドソーシングのようなマッチングのモデルにしないのか？
確かに利益率だけ見るとマッチングモデルの方が，初期は高くなると思います。一方で，ホワイトカラーの業務を型化する（マニュアルを作り外部の業務委託の方や単発のアルバイトの方にお任せできる状態でまで持っていく）ことは非常に難しいです。このモデルでは，委託者・受託者ともに上積みの層しかマッチングしない為，スケールが難しいと判断しています。また，各社の業務を一箇所に集約し，共通化することによる規模の経済性が効きづらくなる為，将来的に利益率・利益額ともにマッチングモデルを上回ると考えています。
その為，当社では紆余曲折しましたが，結果的にマッチングモデル（業務委託やBPOパートナーとの提携含む）ではなく，完全に自社で人材を抱える形としています。
最後に
BPaaS事業を開始して一番良かったことは，地方でなかなか就職できなかったという方達がリモートワークでkubellの事業に参加いただけているということです。実際に子育て中のママさんなど，非常に優秀な方達が集まってこの事業を支えています。
我々がBPaaS事業を推進することによって人手不足の中小企業を救うと同時に雇用の創出にも貢献でき始めています。
日本を支える中小企業のDXを推進すると同時に，雇用の創出にも貢献できる，非常に社会的意義のある事業になってきました。
最後に（これで本当に最後です）
BPaaSについてもっと知りたいよという方，BPaaSやってる会社間で（あるいは検討している人達で）交流したいという方，いらっしゃると思いますので，近日中にイベントでもやろうかと思います。
このnoteは本当に一部なので，もっと深い話もたくさんする予定です。
おそらくオフラインでやることになります。
先着順で定員が埋まり次第，受付終了になる可能性もあるので，興味ある方は早めに登録してください。（今後BPaaSコミュニティもやりたいな！）
今回、BPaaS立ち上げを担った執行役員 桐谷豪とBPaaS事業の中核を担う株式会社kubellパートナーの代表取締役社長 岡田亮一が登壇するイベント開催を予定しています。
現在、イベントの開催日程や内容の検討を進めており、近日公開します。
当フォームより登録いただきました皆さまには、情報公開前にイベント開催に関する先行案内をお送りさせていただきます。
イベントは定員に達した時点で締め切らせていただきますので、先行案内後は、ぜひお早めにお申し込みください。
皆様のご登録をお待ちしております。
最後まで読んでいただきありがとうございました。↓❤️スキをクリックしていただけると継続する励みになります！
この記事が気に入ったらサポートをしてみませんか？