中小企業向けの「BPaaS」という難題をkubellが本気でクリアしにいく話

この記事は何か？

kubellが主催するBPaaSアドカレの一環で、CPO・CSOのコンテンツへのつなぎとして書いています。これまでの社外・社内の投稿は、現場解像度の高い視点から技術的観点までハイレベルな内容が続いているので、少し視点を変えて「なぜ我々がこの難題を成立させ得るのか」を、これまでの経緯と合わせてまとめてみます。

なお、BPaaSに対する我々のスタンスは、ちょうどCSOの桐谷がPivotへ出演しているので、時間のある方はそちらも見てもらえると前提が揃うはずです。

中小企業の状況

最近出したレポートから、BPaaS事業の前提となる中小企業の状況を先に整理します。

ここで見えてくるのは、中小企業のデジタル化は、意欲の問題というより“構造”の問題という点です。日々の業務の中でデジタルツールを使っていない企業が約5割で、システム担当者（兼務・社外含む）がいない企業も3割弱という状態です。さらに、導入されているITの内訳を見ても、生成AI 15.5%、SaaS 10.3%、BPO 6.8%、BPaaS 1.8%と、話題性の割に“実装”の層が薄い状況です。

つまり「何を入れるか」以前に、「誰が選び、誰が運用し、誰が社内で定着させるのか」が不在になりがちで、その結果、“紙・口頭・メール”が合理的な最適解として残り続けています（実際に46%がアナログ継続です）。

そして、デジタル化が進まない理由がまたリアルで、「人手不足・採用難」が41%、「デジタルを使いこなせる人材・スキル不足」が30.9%という“人”側の制約が上位に来ます。ここに「予算」「従業員教育・利用定着」「既存ツールの整理・最適化」が重なると、SaaSが前提にする“導入したら勝手に回る”世界観は簡単に崩れます。1社あたりの規模が小さいほど、導入プロジェクトに割ける時間も権限も薄く、PoCや要件整理の時点で止まりやすいです。止まるだけならまだしも、いったん入れても運用が回らず、「結局、元のやり方に戻る」が頻発します。

これが市場全体で積み上がると、“広いのに深くない”状態になって、参入する側から見ると獲得コストが重く、継続率も読みづらい領域になります。

ちょうど、前職時代からのお付き合いのある北海道で介護事業を経営されている方と食事をさせていただいている中で出てきた言葉が、
「とにかく人の採用が大変。現場はまだしも、経理やバックオフィス系の人材は採用が大変。まだ、頑張れば何とかなる可能性もあるけど、将来を考えると北海道で優秀なバックオフィス人材を採用するのは限界が来る。早めに外部に出す必要があり、福田さんのところのBPaaSが本当にありがたい。」という言葉をいただきました。地方・日本全体を見渡すと、労働人口の減少が非常に早いスピードで進行していて、それに対応するサービスの整備が急務だと肌で感じる経験でした。

そもそも、一般的に中小企業の領域がビジネスとして難易度が高いと言われる理由

中小企業市場は「企業数が多くて大きい」ので、一見すると魅力的に見えます。でも実態は、広いというより“深い”。難しさの本質は、プロダクトの良し悪し以前に、事業成立の前提がいくつも同時に崩れやすい点にあります。

まず、中小企業は業種・規模・業務プロセス・ITリテラシー・意思決定の型がバラバラで、同じ形で売りづらいです。メッセージも導入手順も運用支援も、きれいに型化しにくいため、提供側が人手で吸収しがちになります。ここで起きるのは、「標準プロダクトで取りにいっているのに、現場は準委任っぽくなる」という問題で、気づくとサービス側の労務集約度が上がっていきます。

次に致命的なのが、導入・定着の“受け皿”問題です。担当者不在やスキル不足が起きやすいため、SaaSが暗黙に置く前提（選定→導入→運用→改善）が崩れやすいです。価値があっても届かず、届かないから継続せず、継続しないからLTVが伸びません。しかも、解約理由が「機能が悪い」ではなく「運用が回らない」になりがちで、プロダクト改善だけでは回収しづらいのも厄介です。

さらに、ユニットエコノミクスも割れやすいです。単価は上げにくい一方で、オンボーディング、例外処理、問い合わせ対応などが重くなりがちです。その結果、「単価は中小企業向け、オペレーションはエンプラ並み」になり、スケールするほど現場負荷が増える構造になりやすいです。だから中小企業領域は「薄利多売」ではなく、「薄利・高タッチ」になりやすいです。ここを設計で解けないと、成長が疲弊に直結します。

加えて、獲得も地味に難しいです。そもそも課題が言語化されていなかったり、「忙しいので探さない」という状態が起きやすかったりします。比較検討のテーブルに乗る前に失注するケースも多く、獲得コストが上がる一方で、前述のとおり定着で落ちやすいので、CACは上がるのにLTVは伸びにくい、という嫌な形になりやすい。

最後に、価値の粒度がズレやすい。中小企業が本当に欲しいのは「DX」よりも「今日の業務が終わること」「人手不足の穴が埋まること」。提供側が効率化や高度化を語っても、顧客は“今月を乗り切れるか”の文脈で判断しているので、価値の等価交換が成立しにくい。ここを取り違えると、どれだけ正しい提案でも刺さらないまま終わります。

要するに、中小企業領域は市場が大きいから難しいのではなく、価値を“届け切る”までの摩擦が大きい。だから「道具を売る」だけでは勝ちにくく、「業務が終わった状態を渡す」設計——つまりBPaaSのような“完了”の提供が、構造的にハマりやすい、という話に繋がります。

クリアするためのCapabilityや変数の捉え方

中小企業領域で勝つための変数は、プロダクトの機能も重要ではあるものの、「構造」の理解と打ち手が重要です。

ここで重要なのは、AI・BPO・BPaaSというラベルに過度にこだわることではなく、本質的に「何を実現したいのか」という“コト”に向き合うことだと思っています。AIというテクノロジーを前提にするのであれば、それが適用されやすい構造のものを扱えばよいですし、顧客の業務プロセスを広く捉えるなら、その背景にあるコンテクストまで含めて、複数の仕組みやツール（人や多様なテクノロジー）を組み合わせる必要があります。

定義の仕方にもよりますが、よくAI-BPOと言われる領域はC・D（人の作業が中心→テクノロジー活用が中心）の二つに寄りがちです。一方、我々が提供したいものは、一部Aも含みながら、結局はA〜Dを全部扱うサービスになる。BとCの間には少し大きめの壁があるけれど、右側の比率がテクノロジーの進化で高まっていく構造が理想です。

手島さんが出されていたnoteの「配置」の概念にも通ずるところがありますね。ちなみにこのnoteは本当に名作だと思うのでおすすめです。

Chatworkという「最強の基盤」がもたらす構造的優位性

我々がBPaaSという新たな領域へ挑戦し、産業構造を変革しうる最大の根拠。それは、Chatworkという強固な「基盤（プラットフォーム）」の存在に他なりません。この基盤は、顧客、収益、日常性、そして将来は受発注という4つの側面において、容易に模倣できない競争優位性を形成しています。

• 95万社の顧客を擁する「顧客基盤」とB2B2Eへの拡張
  まず、国内最大級となる95万社以上の顧客基盤を既に保有している事実は、揺るぎない資産です。ただし、真の価値は“深さ”にある。法人との契約を通じ、その先にいる従業員という個人へも解像度高くリーチできる。これにより、法人向けサービスにとどまらず、働く個人へ直接価値を届けるB2B2Eの展開が成立します。BPaaS事業における、一連の業務プロセスを改革する視点においても「E」との繋がりは非常に重要なポイントとなります。

• 圧倒的な「日常性」が生むマーケティング効率
  ビジネスチャットは、朝から晩まで常に開かれている。ユーザーの業務フローのど真ん中にいるので、新たなサービスを提案する際のマーケティングコストが極小化されます。外から高コストで集客する必要がなく、日常のコミュニケーション動線の中で自然に認知・利用を促せる。これは収益性を底上げする強い武器です。これは、直近の決算説明資料でも言及されていますが、時間をかけて積み上げてきた結果、BPaaS事業の受注経路の約6割がChatworkの顧客という結果を産んでいます。

• 挑戦を支える盤石な「収益基盤」
  BPaaSは短距離走ではないので、投資と時間が必要です。既存SaaS事業の収益基盤があるからこそ、安定したキャッシュフローを原資に、次の成長領域へ継続的に張れる。ここは、BPaaSに対する投資を継続するためにも非常に重要な要素となっています。

• 業務の粒度変化に対応する「発注基盤」としての介在価値
  将来的にテクノロジーの進化と合わせ、企業の業務プロセスは細分化され、外部へ切り出されるタスクの規模は小さくなる（マイクロタスク化）と見ています。こうなると、重厚な契約システムよりも、日常の会話の中で「これお願い」と依頼できる軽やかさが重要になる。チャットで依頼し、チャットで納品される。最も摩擦の少ないコミュニケーションが、そのまま受発注のインターフェースになる世界です。

「生存本能」と「進化論」のギャップ

中小企業の経営者は「今月の資金と人手」という生存本能（Level 1）で動いており、SaaSベンダーが説く「将来のためのDX/AX」という進化論（Level 3）には耳を貸す余裕がない。ここに巨大な断絶（死の谷）があります。

SaaSは「道具を渡すから、あなたが進化して使いこなしなさい」というアプローチですが、これはITリテラシーの低い層には酷な要求です。kubellのBPaaS戦略の本質は、この断絶の解消にあります。

BPaaSは「道具（SaaS）」ではなく「結果（業務の完了）」を提供する。「経理ソフトを導入して効率化しましょう」ではなく、「チャットで投げれば経理が終わっています」という体験に寄せます。顧客は自らを進化させる必要はなく、生存本能に従って“面倒な業務”を投げるだけ。裏側ではkubellがAX（AI変革）を駆使して処理を進めます。要するに、

• 中小企業の顧客：人手を提供してもらえるサービス

• kubell：テクノロジーを駆使したAXサービス

という価値の見え方の差分を作れる。この差分は中小企業領域以外では小さくなりやすいので、ここの感度が勝ち筋です。

UXの差分：リテラシー格差が生む「介入」の価値転換

UX設計の違いが出るのは、ターゲット層のリテラシーによって、「親切」と「ノイズ」の境界が変わる点にあります。これはUIの好みの話というより、「業務が前に進むか」を左右する運用設計の話です。中小企業領域では、導入そのものよりも、導入後に“回る状態”を作れるかが重要です。

一定のリテラシーがある層にとって、理想のUXはセルフサービスに近づきます。必要な情報や機能に自分で辿り着けるので、UIは簡潔で、選択肢は整理されていて、余計なガイドや提案が少ない方がよいです。求めていないタイミングでの通知や提案、人の介在は、思考や作業の流れを途切れさせる要因にもなりがちです。ここでは「分かる人が自走できる」ことが価値で、介入を薄くするほど体験は良くなります。

一方で、DX途上の企業にとっては、同じ設計がそのまま機能しないことがあります。担当者が不在だったり、導入・運用の手順を組み立てる余力がなかったりして、選定→導入→運用→定着のどこかで止まりやすいからです。このとき必要なのは、機能の網羅性や洗練された画面よりも、「次に何をすれば前に進むか」が分かることです。だから、システム側からのガイドや提案、入力情報の揃え方の提示、運用の型の提供など、一定の“介入”がある方が前に進みます。

ここで強調したいのは、「中小企業にはシンプルなUIが合う」という事実は変わらない、ということです。日々の業務は同時多発で、ツールの学習や設定に割ける時間が限られる以上、「迷わず使える」こと自体が価値になります。シンプルさは、機能が少ないという意味ではなく、普段の動線が短く、意図せず複雑さに踏み込まない設計です。

そのうえで、シンプルなUIだけで“回る状態”まで到達できるかは別問題です。中小企業で詰まりやすいのは、UI操作の難しさよりも、運用が迷子になることに出やすいです。役割分担が曖昧なまま始まり、必要情報が揃わず、例外が起きたときに処理が止まる。こうなると、入口がどれだけ軽くても、途中で止まってしまいます。

だから必要なのは、「シンプルなUI」と「迷わない運用」を一体で設計することです。前者は入口の摩擦を減らし、後者は途中で止まるポイントを潰していきます。その後者を支えるのが“介入”で、押し付けの提案ではなく、進め方のガイド、型、テンプレ、必要な確認を適切なタイミングで差し込むことです。UIをむやみに賢くするのではなく、業務が前に進むために必要な接点だけを、設計として用意する。

要するに、リテラシーが高い層では「摩擦を減らす」ことが価値になりやすく、DX途上の層では「前に進むための接点を用意する」ことが価値になりやすい、ということです。結果として、『我々が許容できるUX』と『顧客が許容できるUX』に差分が生まれます。この差分の解像度が、勝負を分けます。

Missionドリブンな事業展開による使命感と温かみ

我々が「Chatwork」という長年親しまれた社名を変更し、「kubell（クベル）」へと生まれ変わった理由は、このMissionとVisionを、日本の企業の99.7%を占める中小企業の現場で“本当の意味で”実現するためです。中小企業の現場は、正論や最新ツールだけで前に進むほど単純ではありません。だからこそ、こちら側が“現場で回る形”に合わせて、価値の届け方そのものを再設計する必要があります。

BPaaSは、その再設計の一つの答えです。顧客に「使いこなしてください」と求めるのではなく、「任せてください」に寄せます。表側のUXはチャットで依頼するだけ、裏側ではSaaSやAIで標準化・下処理を進めつつ、最後の例外や不安は人が受け止める。つまりBPaaSは、テクノロジーで全てを解決し切る発想ではなく、テクノロジーと人の役割分担まで含めて“業務完了”を提供するモデルです。

ここに、kubellが大事にしたい「温かみ」が宿ると思っています。温かみというのは、気持ちの話ではなく設計の話で、BPaaSがテクノロジーのみを思考していないことの現れです。AIやSaaSは強力だけど、中小企業の現場には必ずテクノロジーだけでは解決できない問題が残る。状況が揺れたり、例外が出たり、誰かが不安になったりする。その瞬間に、冷たい自動化で押し切るのではなく、ちゃんと人が受け止めて前に進める。ここまで含めて初めて、「任せてよかった」が成立する。

その具体が「クルー」という仲間の存在です。業務をタスク単位に分解し、AIで下処理し、標準化された手順の上でクルーがリモートで支える。中小企業の社長が本来やりたい仕事に集中できるように、止まりやすいバックオフィスをこちらが引き受ける。その裏側で、働きたい意欲はあるのに条件が合わず機会がなかった人たちが、AIと協働して活躍できる場が生まれる。AIが人の仕事を奪うのではなく、AIが人の働く選択肢を増やし、人が現場の最後を支える。この循環こそが、Missionの「働くをもっと楽しく、創造的に」を“理念”から“実装”へ落とす一つの方法だと思っています。

誰もやりたがらなかったブラックオーシャンに、テクノロジーだけでなく、人の手触りも一緒に持ち込む。そこまでやり切って初めて、日本の中小企業の現場は変わる。だから我々は、この領域に本気で取り組みます。

我々が創り上げるBPaaSの未来・中小企業の未来

人口減少は、景気や流行と違って“戻る前提”が持てない。働き手が減り続ける以上、中小企業は「採用できない」「回らない」を前提に、事業の回し方そのものを変えざるを得なくなります。これは努力の問題ではなく、構造の問題です。

だからこれから問われるのは、個社が頑張ってAXやDXを完遂できるかではなく、「業務が止まらない状態」を社会側でどれだけ当たり前にできるかだと思っています。外に出せるところは出す、減らせるところは減らす、簡単にできるところは簡単にする。全部を劇的に変えるというより、“出せるところから確実に”進む。その積み重ねが、10年後の生産性の差になります。

重要なのは、ツールが揃っていることではなく、仕事が前に進むことです。手順が重くなるほど、現場は固まります。だから入口は軽く、日常の動線にそのまま乗ることが重要です。チャットが単なる連絡手段ではなく、依頼・実行・完了・証跡まで飲み込む基盤になった瞬間、働き方は“思想”ではなく“実装”として変わります。

BPaaSは、その実装を現実に寄せるための形です。顧客に“新しいテクノロジーを使いこなすこと”を要求しません。AIが強力であればあるほど、価値は「使える人だけが得をする」ことではなく、「意識しないまま恩恵だけ受け取れる」ことに移っていきます。AIは前面に出すのではなく、業務プロセスの裏側に溶かして、成果として返す。顧客が受け取るのはAIではなく、「前より早く、正しく、安く回るようになった」という事実です。

BPaaSが目指すのは、そのためのインフラです。人口減少という現実を前提に、「今日が回る」を確実に積み上げる仕組みを渡し、派手な魔法ではなく、現場が前に進むための当たり前をつくります。

ブラックオーシャンに潜る理由は、そこにしか未来がないからです。kubellは、この難題を“事業”として成立させることで、AIの恩恵が一部の企業だけのものにならない世界を、静かに、でも確実に実装していきます。