なぜBPaaSが中小企業にこそ刺さるのか？

こんにちは。kubellで事業開発をしている舩生です。kubellに入社してnoteを投稿するのは2本目になります。

こちらの記事は、AIやBPaaSをテーマとした、#kubellブログリレーの記事として執筆しています。

（前回はこちら）

最近の個人的な流行りは、AIエディタでドキュメント管理することです。私の場合はGoogleのAntigravityを使っていますが、ビジネスサイドでもがんがんAIエディタを使っていくべきだなと思いました。これについてはいつか書きたいと思います。
※本当に個人的な感覚ではありますが、仕事をする上での世界が変わりました。

さて、入社以来kubellの事業開発領域に関わり続けていますが、改めて、中小企業マーケットがどのような実態を抱えているのか、何が問題なのか、解決策としてのBPaaSとはつまりなにか？というのを整理し、noteにまとめてみました。

正直BPaaSに関するnoteは多数出ており、中でも弊社の桐谷、藤井が記載している以下のものを見るだけでも「BPaaSってなんだ？」という疑問は解決すると思います。

そのため、このnoteは自分の言葉でBPaaSを言語化することで、私自身の理解を深めることを目的に、筆を取らせていただきました。

1. 中小企業における「デジタル化の遅れ」と「労働力不足」の課題

「そんなの周知の事実」というご意見もありますが、改めて経済産業省の『中小企業白書』にどんなことが記載されているかからスタートしたいなと思います。端的に言えば、中小企業における「デジタル化の遅れ」は、中小企業だけではなく、社会全体の生産性に関わるテーマとして位置付けられています。

「そもそもなぜデジタル化すべきなんだっけ？」という当たり前な質問ですが、これが推進される背景として、「構造的な労働力不足」が挙げられます。

帝国データバンクの2024年の調査によれば、正社員の不足を感じている企業の割合は52.3%に上ります。多くの企業が人手確保に課題を抱えていることがわかります。人口減少に伴う採用難が継続する中、これまでのようなマンパワーや特定の社員の「長年の知見」に頼った業務運営は、徐々に維持が難しくなりつつあります。

そのため、同じく当たり前な着地点にはなりますが、ITを中心としたツールの活用により生産性を向上させることが、事業継続の重要な鍵となります。 しかし一方で、白書が示す中小企業のDXの取り組み状況を見ると、30.8%の企業が「紙や口頭による業務が中心」にとどまっており、データ活用やビジネスモデルの変革に至っている企業は6.9%というデータもあります。

つまり、「人手不足の課題」と「デジタル化の停滞」という事実が、多くの中小企業が直面している現状を示していると解釈できます。

本来であれば、こうした強烈な危機感から、「DXが一気に進む土壌が整っている」と見ることもできます。少なくともkubellに入社する前は私もそう思っていましたし、少し楽観的に捉えていたところはあります。

しかし、現場のリアルはそう単純ではないことが、kubellで顧客の皆様と相対する中で見えてきました。

2. そもそも「"今は"回っている」という現実

中小企業の現場に足を踏み入れると、一つの事実に行き当たります。それは、実は「現場は、顕在的には困っていない」ということです。

そもそもSaaSには、特定の業界に特化したバーティカルSaaSや、横断的な業務領域を支援するホリゾンタルSaaSなど、機能や用途に応じて多様なツールが存在します。しかし、それらに共通しているのは「ユーザーの業務を支援し効率化するためのソフトウェア機能を提供する」というアプローチです。本稿では、このアプローチ自体に着目し、これらを「機能提供型ツール」と呼びます。

給与計算や税務申告のような「法律上絶対にやらなければならない業務」を支えるシステムはいざ知らず、「より高度な管理」や「情報の可視化」を謳う機能提供型ツール、例えばSFAやタレントマネジメントツールなどの導入現場を想像してみてください。

これまで案件の進捗は、週に1回の会議とホワイトボード、そして共有のExcelファイル「顧客案件(最新版)202602.xlsx」で管理されていました。

社長「（Excelファイルを見ながら）A社さんのあの件どうなってる？」　　
↓
従業員　「先方と来週調整してきますよ。」

これで、社長も現場も必要な情報はざっくりと把握できましたね。少なくとも日々の商売は滞りなく「回っている」ように見えますし、実際に働いている現場の実態としても「回っている」と感じるかと思います。

そこに、突如として、「最新のSFAツール」の営業が意気揚々とやってきます。

SFA営業マン「これを使えば、案件状況がリアルタイムに可視化され、成約率の分析からネクストアクションの示唆まで自動化されます！」

SFA営業マン「タスクも自動で作成されます！」

SFA営業マン「AIが次のアクションも提案してくれます！」

「自動化」、「リアルタイム可視化」など、キラキラしたワードが散りばめられており、社長も「お、そうだな。時代はデジタル化だしExcelをいつまでも使ってられないな」と、なんだか良さそうに思えます。

さっそく社長が「どうこれ？」と現場に聞いてみました。すると以下の声が聞こえてきました。

従業員「直近の案件状況が可視化されると言っても、うちの主要顧客なんて数十社だし、社長は全員の顔も案件も暗記してるじゃないですか」

従業員「分析って、そもそも分析するほど膨大な案件数がいないんですが、、、」

従業員「全員にアカウントを発行して、営業担当に「電話した時刻」、「メールの内容」、「誰に訪問してなにを提案してどうだったか」を毎日細かくシステムに入力させるんですか？ それなら1件でも多くお客さんのところに行きたいんですけど。今のExcelで、誰も困ってなくないですか？」

社長「。。。お、そうだな」

このように、現状で商売が回っている以上、「今より便利になるかもしれない未来」のために、わざわざこれまでのやり方を変え、なんなら入力の手間を仕事を増やし、長年慣れ親しんだワークフローを根底から変えようとする導入インセンティブは、本質的に働きづらいのではないかと考えられます。

もちろん、こうした機能提供型ツールの価値そのものを否定しているわけではありません。もしそのツールを現場が完全に使いこなし、意図通りにデータが入力・蓄積されれば、某名刺会社のごとく「それさ、、、、早く言ってよぉ」という劇的な体験に変化する余地は十二分にあると思います。

主にSaaS業界、テックに携わる業界で働く人からしたら、実際にそうなる未来は想像に難くないなと思います。私自身も、「SaaS is Dead」と叫ばれて久しいですが、ポジショントークでもなんでもなく、純粋にまだまだ機能提供型ツールで生み出すAdd Valueは十分あると思っています。

しかし問題は、そこへ到達するまでの「学習」や「初期設定」といった切り替えコストを払う時間的・心理的な余裕が、中小企業には圧倒的に不足しているという点です。現状で商売が回っていて、誰も困っていないと現場が感じていることに対し、まだ見ぬ未来のための「ツールのための作業」の存在が、その真価が伝わる前に「新たな負債」として挫折してしまうのが実態ではないかと考えられます。

とは言えこの「今は回っている」状態は「何も問題がない」ということを意味しているわけではないこともその通りです。もうこれを読んでいる方はお分かりの通り、ワークフローの硬直化や属人化といったリスクが潜んでいる可能性がとても高く、特定の担当者のノウハウや個人の献身に依存する体制は、ビジネス環境の変化（主にキーマンの退職など）に対して脆弱になりがちです。

このようなリスクは、日々の業務の小さな綻びから顕在化していきます。 例えば、上記の通りワークフローを熟知しているキーマンが不在になった途端、最新のデータファイルの所在が分からなくなり関連業務が滞るケースです。入力ミスに誰も気づけず対応が遅れたり、社内からの問い合わせに適切に回答できなくなったりすることで、少しずつ業務に支障が出始めます。
一つ一つは「ちょっとした確認漏れ」や「数日の遅れ」かもしれません。すなわち「困っていない」が「ちょっとなんだかおかしいぞ?」と思い始める段階です。

それらが幾重にも重なると、少しずつ積もってきた「社内の対応」に追われる時間が増加します。結果として組織全体の疲弊を招き、「属人化に起因する負のスパイラル」が静かに、しかし着実に進行してしまうのです。

本来であれば、ITツールはそうしたリスクを解消する有効な手段です。ここで重要なのは、システムが「現場にどの程度の学習や適応を求めるか」という点です。

私たちが提供している「Chatwork」が多くの企業様にご活用いただいている背景の一つとして、このシステムの仕様に対する「現場への適応負荷」が少ない点が挙げられます。いきなりChatworkを導入したとしても、キャッチアップはおそらくそこまでかからず、学習コストを抑えながら日常の延長線上で使い始められることが、現場の円滑な導入に繋がっていると考えられます。

専任のIT担当者がいない組織では、高度な設計や設定、マニュアルの読み込みを必要とする機能提供型ツールの導入は、現場にとって「新たな学習コスト」という業務の追加になり得ます。

現状のフローで回っている中で、時間と労力を割いて新しいルールを学ぶメリットが感じにくいことが、高機能なツールが「管理業務の追加」として捉えられがちな理由の一つなのではないでしょうか。

※参考までに、中小企業むけDXの現場はこちらのnoteがより解像度高く、かつ、生々しく記載されてると思います。

3. 「インプット」し続けることの負荷

仮にこれらの初期ハードルを乗り越え、何らかのシステムを導入できたとしましょう。しかし、ツールを使い続ける限り、現場の担当者には静かに、そして着実に新たなペインが発生します。それは、システムを正しく稼働させ続けるための「正確かつ多岐にわたる日々の入力作業」と「カスタマイズ」です。

機能提供型ツールが提供する価値の中心は、情報の「デジタル化」や「記録・共有」です。

これまでの機能提供型ツールは、「正確かつ高品質なインプット」をして初めて、「高品質なアウトプット」が担保されるという前提で作られています。
導入したてのころは、その「正確かつ高品質なインプット=入力作業」はそんなに難しくもなく、大した量もなく、一定レベルの品質を保ちながら正確な入力を担保できているのではないでしょうか？

しかし、日々の改善が回ることで、「あれも入力しなきゃ」「これをモニタリングしなきゃ」など、経年とともに入力物が増えていきます。（中小企業では当たり前のように）日々複数の役割を兼務する担当者にとって、毎日細かく情報を入力し、整合性を保ち続ける作業は、それ自体が本業の時間を圧迫する巨大なタスクとなってしまいます。

本来、現場の要望を吸い上げて改善を繰り返し、仕組みを高速にアップデートしていくこと自体は、極めて前向きな取り組みであり、中小企業の強みでもあります。

しかし、機能提供型ツールという形態が「多くの企業が共通して利用できる汎用的なプロダクト」である以上、一社ごとの個別の要望に合わせて根幹の仕様を変更することは、構造的にできません。

そのため、現場の細やかなニーズに応えようとすればするほど、あらかじめ用意された設定項目や運用ルールを複雑に組み合わせて、自社のワークフローをなんとかシステム上で再現しようとするアプローチになります。

システムを現場に適合させようとするこの「設定の工夫」という名のカスタマイズが積み重なることで、次第に内部の依存関係は見えづらくなり、一つの変更が予期せぬ影響を及ぼすリスクが高まっていきます。

そしてある段階で設定の限界に達したとき、「自社に合わせてシステムを最適化する」ことから、「システムの仕様の範囲内で自社のワークフローを妥協・変更する」ことへの転換を余儀なくされる局面が訪れます。

結果として、中小企業の強みであったはずの「柔軟な業務改善」が、いつの間にか機能提供型ツールの仕様の範囲内に制約されてしまいます。これは決してツールの仕組みが悪意を持っているわけではなく、汎用性の高いツールを個別性の高い現場の運用に寄り添わせようとした結果生じる、構造的なジレンマです。

何度も書いてしまいますが、これは誰かのミスや過失によって発生しているわけではなく、ツール提供側も、それを使おうとする中小企業側も、それぞれが一生懸命に前向きに取り組んだ結果として生じてしまう、構造的な問題だと考えます。

4. インプットの負荷軽減と「業務成果」へのフォーカス

現場がITやシステムに求めている本質的な価値は、「業務プロセスの標準化」や「データの蓄積」そのものというよりは、「業務が円滑に完了し、ビジネスを前に進めること」にあるのは間違いありません。少なくとも上記のようにIT化する前でも「困っていない」理由は、少なくとも業務が完了し、ビジネスが前に進んでいるからに他なりません。

しかしながら、多くの機能提供型ツールは仕様に基づいた「正確なインプット」と「一定のワークフロー」を前提としています。そのため、現場での運用負荷が高まり、システム運用上の課題が生じやすい構造があります。
そこで視点を変えてみます。

それこそが、機能提供型ツールの「箱」を現場に渡して運用責任もセットとなる従来のモデルに代わる、全く新しいサービス提供の視点であり、我々がBPaaSにフォーカスする理由でもあります。

5. 実行をセットで届ける「BPaaS」

こうした背景から、ソフトウェア単体での解決が難しい領域に対して、サービス提供のあり方そのものを変えるというアプローチがAIを中心に議論されています。

従来のSaaSがソフトウェアを売るモデル「Sell Software」であったのに対し、今求められているのは業務成果そのものを売るモデルである「Sell Work」への転換です。

BPaaSはまさにこの「業務成果そのものを売る」を体現するアプローチであり、ソフトウェアを「機能」としてではなく、AIや専門家による「実行」とセットにして、最初から「完結した業務成果」として提供するモデルです。

例えば、「経費精算」でどうなるのかを記載してみます。

従来の機能提供型ツールのアプローチ

1. 新しい経費精算システムの操作方法・マニュアルの学習

2. 指定フォーマットでの証憑の撮影・アップロード、および勘定科目を選択

3. 入力規則外となる不鮮明な画像などのエラーがあれば差し戻し+コメント

4. 期限が過ぎそうな場合に申請者へリマインドを実施

BPaaSのアプローチ

1. 慣れ親しんだチャットなどのツールでデータを送付（そしてこれは一定不鮮明でも可能）

2. AIによる画像の読み取りと構造データ化

3. AIが対応できないイレギュラー部分について、専門オペレーターによる補完が必要と判断し、ルーティング

4. AIが仕訳を実施+オペレーターが人間的な判断を元にイレギュラーな仕訳を実施

5. 最終的な成果物となる仕訳データを作成し、納品

このように、BPaaSはインプットとアウトプットの間にある、ワークフローを含めて全て巻取ります。これにより「現場の多様なインプット」と「企業が求める正確なアウトプット」の間にあるギャップを吸収し、システムに合わせたワークフロー負担を軽減します。

結果として、テクノロジーの恩恵を運用の手間なしに享受するために非常に有効的かつ実用的な手段となり得ると我々は信じており、だからこそ事業としてBetしています。

6. BPaaSの心臓部：「AIオーケストレーション」とHuman in the Loop

前章の「AIと専門オペレーターの協調」という構造を、もう一歩踏み込んで記載してみます。

BPaaSが目指すべき世界は、決して「人を大量に投下して気合で入力代行をしている旧来のBPO」ではありませんし、「汎用AIが全てを魔法のようにミスなく処理している」わけでもありません。

その真髄は、現場から飛んでくる無数の「不完全なインプット」を受け止め、それをAIエージェントと専門のオペレーターに最適に振り分け、最終的に品質を担保したデータとして出力する「AIオーケストレーション」の構造にかかっています。

オーケストレーターとしてのAI、またはそれを含むシステム、あるいはその監視プロセスが、インプットされたデータをもとに実行すべきタスクを計画します。そしてそのタスクの性質を見極め、人やAIにタスクの処理を割り当てます。

AIは万能ではありません。しかし、「自分の限界を知っているAI」は最強です。具体的には以下のようなフローで行われます。

1. インプットの受付

   • データ受付（例: Chatworkなどのチャットを通じたデータのインプット）

   • ここでは完全なデータと不完全なデータが混在します

2. AIエージェントによる一次解釈と構造化

   • LLMやOCRなどのAIエージェントによる処理を走らせます

   • 画像やテキストからの構造化データへ変換します

3. 確信度スコアによるルーティング

   • AIエージェントによる処理の確信度を算出します

   • つまり、自分で処理できる自信がある場合、AIのみでのフローを実行し、基幹システム等へ連携します

   • 自分で処理できる自信が低い場合、そのタスクは専門オペレーターへパスします

4. 専門オペレーターの介入による例外処理と学習

   • AIが判断を保留した例外タスクは、人間が処理を実行します

   • 現場の「暗黙知」や「複雑な判断基準」の言語化の蓄積を同時に行います

   • 判断結果のデータベース反映と、AIの学習モデルおよびプロンプトへの反映を行い、精度を上げていきます

このHuman in the Loopフローが機能することで、一定レベル担保された精度でサービス提供を実現することができます。そして運用を続ければ続けるほど、AIが処理できる領域が拡大し、結果として人間の介入割合が減り、ユニットエコノミクスが改善していきます。

この強烈なスケールメリットこそが、BPaaSがビジネスモデルとして面白い理由です。

7. BPaaSをリードする組織構造と、新たなプロフェッショナル人材

BPaaSという全く新しい提供形態を成立させるためには、単に「進化したAI」や「使いやすいソフトウェア」を作るだけでは成り立ちません。

これまで記載した通り、BPaaSを成り立たせるための最大の障壁が「現場の混沌としたワークフロー」と「不完全なインプット」をいかに巻き取るかとすれば、それを成立させるBPaaSの組織体制や求められる人材要件も、従来型のSaaS企業とは根本的に異なってきます。

従来型のSaaS企業における主役は、最大公約数的な課題を抽出し、スケーラブルな機能を定義することでした。その設計思想とアウトプットは「汎用的で美しいソフトウェアを作り、顧客に正しく使ってもらう仕組みをどう作るか」に直結しています。

しかし、近年において脚光を集めているのは、「泥臭い現場の運用」を通して、ギャップを直接埋めに行くアプローチです。例えばPalantirのForward Deployed Engineer（FDE）やDeployment Strategist（DS）といった職種がまさにそのアプローチを行うための仕事として、確立しています。

実際にLayerXさんが中心に日本でも展開が早まっており、AIを主軸としたビジネスにおいて、こういった職種によるアプローチはおそらく正しいと思われますし、実際に私もこの職種における価値はとても高いと感じています。

しかし、これが中小企業向けにも同様に価値を発揮できるかで言えば、個人的には懐疑的と考えます。

※実際にBPaaSに挑戦した弊社平野の記事も必見です

8.中小企業向けBPaaSにおける新しい職種の誤解

Palantirモデルに代表されるエンタープライズ向けの職種は、数ヶ月〜年単位で顧客の現場に張り付き、個別のカスタムコードを書き、経営陣と戦略を練る「超ハイタッチなアプローチ」をとります。

しかし、このモデルをそのまま中小企業マーケットに持ち込むことは残念ながら不可能と考えます。数百万円〜数千万円の人件費がかかる人材を単一の中小企業にアサインすれば、ユニットエコノミクスが成り立ちません。

したがって、中小企業向けBPaaSにおいて真に求められるのは、特定の「職種名」にとらわれた人材配置ではないのでは？と今のところは考えています。

少なくとも求められえているのは、個別の顧客の現場で泥臭く立ち回り、発生している事象を抽象化し、自社の裏側にそびえる巨大なオペレーション工場を、テクノロジーの力で1対Nのスケールへ極限まで自動化・規格化することができるかどうかではないかなと。

具体的には、大きく以下の役割が求められている気がします。

① 例外処理エンジンの構築と自動化を担う役割

• 多様なインプットの引き受けと共通する例外パターンの抽出

• AI精度の向上やRPAなどの連携による汎用部品化の推進、まやは汎用部品の開発

② オペレーションの構造化とAIオーケストレーションを担う役割

• タスクの分解とAIや専門オペレーターへの最適配置の設計

• オペレーション全体の標準化、タスクルーティングの最適化

これらの役割を担うのが、中小企業マーケットにおける次世代のBizDev、PdM、PMMかなと、私の中では答えとして出しています。

現在、（もしかしたらあるかもしれないですが）これらの泥臭くも高度な領域を表すような、世の中に定着した職種名はまだ存在しないため、弊社の藤井が「人とAIの境界を設計し、業務プロセスを再構築する責任者」をAIオペレーションマネージャーと呼んでます。

どのような名前に落ち着くのかはまだわかりませんが、少なくとも上記のような役割で「Sell Work」の最前線をハックしていくことが求められると思います。

これまでのSaaS企業にあった「汎用的なソフトウェアを作り、どう売るか」という従来の枠組みから一歩はみ出し、「顧客の現場のビジネスアウトカムを、テクノロジーとオペレーションの力でどうハックするか」という、より広義的、かつ複雑な事業構築へとその主戦場を移していくことになるのではないかと。

9. BPaaSのコアに関わる人材が出すべき究極のアウトプット

求められるのは「洗練されたUI/UXを通じた機能提供」ではありません。それ自体が重要ではないということではないですが、それよりも「AI」と「人間のオペレーター」が協調し、どんな雑なインプットからでも品質を担保した結果を出力する「業務プロセスの確実な実行体制」を作り続けることだと思います。

すなわち、BPaaSを事業として成功させるための組織構築とは、以下の3者がサイロ化せず、重厚なハイブリッド体制を作ることではないかと思います。

• ソフトウェア開発エンジニア

• 実務をミスなく回す専門オペレーターのBPOチーム

• 上記両者を現場プロセスとシステムの間で泥臭く縫い合わせるエキスパート（残念ながら、名はまだ定着していない）

10. おわりに

テクノロジーはあくまで手段であり、その目的は現場で働く人々が、より付加価値の高い仕事に集中できる環境を作ることにあるはず。

「道具」をどのように提供し、どのように運用を支えるのか。その「サービス提供形態」の根本的な再設計こそが、日本の経済を支える中小企業にとっての新たなビジネスの鍵になると考えています。