編集部注
本稿は、CodeZineに掲載された、ソフトウェア開発者向けカンファレンス「Developers Summit 2025（デブサミ2025）」のセッションレポートを転載したものです。プロダクトづくり、プロダクトマネジメントに近しいテーマを選りすぐってお届けします。
なぜBPaaSを目指すのか、中小企業の課題とkubellの戦略
平本氏によれば、kubellがBPaaSに取り組み始めたきっかけは、ビジネスチャット「Chatwork」の主な顧客である中小企業ユーザーの声だったという。もともとkubellは、Chatwork事業と並行して、中小企業のDX推進のために最適なソリューションを提案する「Chatwork DX相談窓口」で他社SaaSの導入も提案してきた。その過程で見えてきた課題は、中小企業の人手不足だった。例えば、多くの中小企業は、大企業とは異なり経理や労務などのバックオフィス担当者がIT担当者を兼任している。そのため、SaaS導入に興味があっても、導入や運用管理、社内オンボーディングに十分な時間やコストを割くことができないのだ。
そこでkubellは発想を転換した。SaaS導入のための人手が足りないなら、kubellが中小企業のバックオフィス業務を丸ごと担えば良い。しかし、単に人手を提供するだけなら、従来の業務アウトソースと変わらない。そこで、テクノロジーと人材をセットにしてDXされた業務プロセスをサービスとして提供する、BPaaSのコンセプトにたどり着いたのだという。
平本氏は「顧客が、必要な時に必要な分だけ、ビジネスプロセスを調達できる世界観を作りたい」と意気込みを語る。
BPaaS事業への挑戦は、AsIs／ToBe分析から始まった。AsIs（現状）は、「Chatwork」を通じた中小企業との多数の接点と、チャットインターフェースが強みである。ToBe（目標）は、人とテクノロジーを融合させ、チャットで簡単に業務をアウトソースできる世界観を実現することだ。両者のギャップを分析して見えてきた課題は、「対応すべき顧客数が非常に多いこと」「BPaaSに対するドメイン知識の不足」、そして「プロダクト組織の人員不足」だった。そこでkubellは、可能な限り早くギャップを埋めるため、事業戦略、プロダクト戦略、技術戦略、組織戦略、それぞれのアクションプランを検討した。
まずBPaaSプロダクトの目指す姿を、チャットによる業務発注プラットフォームと定義した。そしてBPaaSは、以下の3つのプロダクトから構成される。
- BPaaS窓口：顧客がBPaaSを契約・発注する窓口であり、BPaaSにとっての基幹システムでもある。顧客数が多いため、膨大な契約を効率的に処理する必要がある
- 自動化エンジン：AIやワークフローを組み合わせ、業務効率化と、人手によるオペレーションの最小化を担う
- 業務関連SaaS：経費精算や勤怠管理など、実際のバックオフィス業務を担うSaaS。既存のサービスとのアライアンスや、M&Aを通じて拡充する
プロダクトの具体像に合わせ、プロダクト組織のあるべき姿も策定した。迅速な意思決定を目指して、各プロダクトに独立したチームを編成し、同時に横断的な連携も可能な体制を構想した。採用については、社内異動に依存せず、外部から積極的に人材を採用することにした。BPaaSの実現には、Chatwork事業の非連続な成長も必要だからだ。またBPaaSプロダクトは仕様が複雑で、具体的な実装は手探りで進める必要がある。そこで専門性の高いプロダクト人材を集約し、プロダクトマネージャー、デザイナー、エンジニアがシームレスにコミュニケーションができる垂直立ち上げを目指した。
将来的にはプロダクトごとのチーム構築を目指すものの、プロダクト組織の現状の最優先目標は、基幹システムとなるBPaaS窓口をローンチすることだという。
事業開発に伴走する、プロダクト作りの方法論と技術戦略
現在、BPaaS事業は、実際にサービスを提供しながら経験を積むフェーズに入っている。すでに「Chatwork アシスタント」という業務プロセス代行サービスを提供しており、並行してBPaaS窓口のWebアプリ開発も進めている。
BPaaS窓口の開発では、段階的なアプローチを採用した。つまり、いきなり内製のWebアプリを開発するのではなく、まず既存ツールや人手のオペレーションを組み合わせてサービスを構築するということだ。
例えば、「Chatwork アシスタント」の裏側では、顧客情報や契約内容の管理、決済システムなど、複雑な業務が動いている。また業務を代行する人材（クルー）が、どの仕事に割り当てられているか、誰が現在アサイン可能かといったクルー管理も必要だ。加えて、BPaaSは時間課金制なので、システム上で作業時間を管理し、最終的に事業の売り上げとして計上する必要がある。
BPaaS窓口の開発にあたって重視しているのは、単にこれらの業務フローをアプリ化することではない。サービス運用の過程で課題を発見しながら、サービスの磨き込みと並行してWebアプリの実装を進める。そうすることで、新機能の実現や業務のさらなる効率化を目指していると、平本氏は言う。まもなくリリースされるBPaaS窓口のWebアプリでは、顧客向けUI・社内向けUIを整備し、システム上でこれらの複雑な業務を一気通貫で管理できるようになる。
続いて、BPaaSを支える技術について紹介する。技術戦略の前提として平本氏が強調したのが、BPaaSプロダクトの概念も定まっていない中で、ゼロから事業と組織を立ち上げねばならなかった点だ。
「いわば0→1（ゼロイチ）フェーズなので、探索しながらプロダクト開発を進めねばならず、フロントエンドエンジニアやバックエンドエンジニアが何人必要かといった見積もりも難しかった。そのため、技術スタックや開発プロセスは、走りながら決めていった」（平本氏）
そこでkubellは、技術戦略の策定にあたり、小人数で幅広く適切なスピード感で開発できること、既存メンバーの技術スタックを考慮することを重視した。具体的な方針としては、コモディティ化した技術は、マネージドサービスを積極的に選択すること。認証・認可基盤など全社共通基盤が整備されているものは、既存のものを活用すること。また「Chatwork」をはじめ、多様なプロダクトとの連携が必要なので、将来の外部連携を想定したAPI設計を進めることなどが挙げられる。
その結果、現在の技術スタックは以下の構成を取っている。まずフロントエンド、バックエンド、IaCすべてにおいて開発言語をTypeScriptに統一することで、エンジニアがフルスタックで活動しやすくした。インフラ環境はAWSを軸に、AWS AmplifyやAWS Fargateなどのマネージドサービスを積極採用している。他社SaaSについては、認証基盤には既にChatwork IDや社内システムでも利用実績があるAuth0とOktaを、決済には将来的な商品ラインナップの変化に柔軟に対応できるStripeを採用した。UIデザインにはStorybookやFigma、CI/CDにはAWS CDK、GitHub Actions、Playwrightなどを活用しているという。
組織の成長痛と喜び、そして市場志向のチームへ
こうして動き出したBPaaSプロダクト組織は、この1年の間に3倍に急成長した。その過程ではさまざまな苦労があったと、平本氏は振り返る。
まずは意思決定の難しさだ。平本氏自身のリソースを、目先の課題解決に割くか、それとも将来のために使うべきか。現場の意思決定にコミットするか、それとも採用活動に時間を割くべきかといった具合だ。また採用の不確実性やBPaaSプロダクトの具体像が不明確な中で、QCDS（品質・コスト・納期・スコープ）、いわゆるトレードオフスライダーの管理も難題だった。また平本氏にとって意外だったのは、開発プロセスを確立する難しさだ。社外からメンバーを集めたので、それぞれの常識や言語が微妙に異なっていたという。そこで、BPaaSとして目指すべき姿を念頭に置きながら、都度すり合わせを通して共通言語を確立する必要があった。
一方で、平本氏がうれしかったこととして挙げたのが、0→1フェーズならではの面白さだ。新しいスキルを持ったメンバーの活躍により、チームの役割分担がスムーズに変化していったことや、予想を超えたメンバーの成長が大きな喜びだったと、平本氏は語る。例えば、あるUIデザイナーは、エンジニアの業務を理解しようと自主的に基本情報技術者試験を勉強し、見事合格。チームでの業務に活かしているという。
「メンバーが急成長する瞬間を目の当たりにして、とてもうれしかった。全体的に熱量の高いメンバーがそろっていると実感する。このような良い状況を、今後も継続していくことが大切だ」（平本氏）
今後の展望として平本氏は、BPaaSという新規性の高いプロダクト開発にあたり、市場や顧客のニーズにフォーカスした、市場志向のプロダクト開発チームを構築したいと述べる。またチームが大きくなっても、多変数な要素を考慮しながら、幅広いスキルをもつジェネラリストなチームを維持していきたいと抱負を語った。
最後に平本氏は、「BPaaS開発の最前線から戦略設計まで、オーナーシップを発揮しながら一緒にプロダクトを作り上げる仲間を求めている」と参加者にラブコールを送り、講演を締めくくった。
BPaaSプロダクト組織について詳しく知りたい方はこちら
kubellのBPaaSプロダクト組織では一緒に働く仲間を募集しています！
