「kubellが目指す未来」は本当に現場で役に立つのか？を実際に試してみた
自己紹介
株式会社 kubell でデータアナリストをしている平野 翔斗です。
親や友人など、自分の身近には中小企業の経営者が多く業務が特定の人に依存していて、退職や休職のタイミングで一気に混乱してしまうケースを何度も見てきました。
そうした課題を見ている中で、BPaaSの戦略は、実際の課題にそのまま刺さっているという感覚があり、その戦略に惹かれ、2024年11月にkubellへジョインしました。
それ以来、会社の業務と並行して「個人の活動」として中小企業の現場に入り込み、BPaaSの実装に向き合ってきました。
BPaaSとは？
BPaaS とは「Business Process as a Service」の略であり、ソフトウェアの提供ではなく、業務プロセスそのものを提供するクラウドサービスです。
ツール導入だけではなく、業務全体の仕組み化と運用支援まで含めて提供することで、中小企業のDX推進を支えるという考え方です。
詳しくは下記noteをご覧ください
kubell は「SaaS だけでは SMB の DX は頭打ちになる」という課題意識から、この BPaaS を次の事業の柱として掲げています。
なぜBPaaSを現場で試してみようと思ったのか
データで改善できることは多いけれど、データの力を最大限に引き出すには現場の解像度が不可欠だと感じてきました。
加えて、「BPaaSは本当に中小企業の課題を解決できるのだろうか？」という問いも心に残っていました。
だからこそ、理屈ではなく「現場での実効性」を肌で確かめたい。
そう考え、会社の業務としてではなくあえて「個人の活動」として中小企業の現場に入り込み、BPaaSを試してみることにしました。
BPaaSで属人化は本当に解消できるのか
中小企業では、人手が限られているぶん、1人が複数の業務を担当していることがよくあります。
さらにその業務の進め方が、マニュアルや仕組みではなくその人にしか分からないやり方になってしまっているケースも多いです。
この2つが重なると、退職・休職・異動といったタイミングで現場が一気に揺れてしまいます。
今回取り組んだ現場もまさにそうでした。
長く支えてきた担当者が抜けたタイミングで、受注 → 工事 → 請求・入金 → 支払いの流れが一気に不透明になり、誰がどのボールを持っているのか分からなくなっていました。
本来はプロセスが一本の線で進むはずなのに、情報と責任の所在が断片化し、業務の停止リスクが常に潜む状態になっていたのです。
だから今回は、ノンコア業務を型化して誰でもできる状態にできるのかを検証軸に据え、BPaaSが機能するかを確かめてみました。
業務が止まらないフローを実装する
今回の現場では、受注から支払いまでのプロセスが分断されていました。
契約書は現場で手書きされる
営業担当が個人で保管しており、チームに共有されない
仮に共有されたとしても紙なので進捗管理ができない
ステータス管理ができないため、原価や粗利の振り返りができない
請求漏れ・入金漏れ・重複請求のリスクが常に存在する
つまり、情報が一貫してないことが、業務停止・判断遅れ・収支の不透明化につながっていました。
理想は下記が担保されている状態です。
受注が発生した瞬間に案件の存在と必要な情報がチーム全体で共有される
工事の進捗が可視化される
工事完了から入金・支払いまでが途切れない
すべてが一貫したデータとして残るので、事業状況の振り返りができる
完全自動化をするよりも、情報・進捗・責任の所在が分断されない仕組みの方が、圧倒的に事業の耐久力を高めると考えています。
全部を変えるのではなく、業務が滞らない状態に最短距離で近づくための「最小構成」を探りました。 そのうえで、最小構成で何ができるかを考え、実際の現場運用へ落とし込んでいきました。
ここからは実際に行った設計と運用フローを紹介します。
実際にやったこと
現場にいきなり新システムを導入してもまず定着しません。 そこで今回は、安定稼働に必要なものだけに絞って仕組みを組み上げました。
① 「Chatwork」で受注情報の一本化
■ なぜそうしたのか
情報が散らばると、業務は必ず止まってしまいます。 まず受注の起点が一箇所に統一されない限り、止まらない運用は成立しません。
■ 実装内容
1.契約を取った瞬間に、専用グループチャットへ契約書画像を投稿
2.工事費/材料費の情報も別途専用グループチャットへ投稿
3.「情報がどこにあるか？」を探す時間・認知負荷をゼロに
② 画像データのAPI取得
■ なぜそうしたのか
チャットに画像があるだけでは「管理できている」とは言えません。
既読/未読・端末依存・検索性の低さが、後工程の停滞を生んでしまいます。
■ 実装内容
1.グルチャ単位で投稿画像をAPIで自動取得
2.ローカル端末ではなくストレージ管理に
3.人が見なくても「証跡が残っている」状態を担保
③ OCRで文字起こし
■ なぜそうしたのか
手入力に戻った瞬間に、ミスと属人化が復活してしまいます。
データ化を自動化しないと止まらない運用は維持できません。
自動化はどこまでやるかが重要です。
例外処理を全部AIに押し込むと破綻する。
だから“自動化 9割 × 最後の1割だけ人”がもっとも止まらない。
■ 実装内容
1.金額/契約日/顧客名/工事日/住所をOCRで自動抽出
2.抽出した名前は社員名簿と自動照合し、表記ゆれや誤字を補正
3.「項目別の構造化データ」を生成し、手入力をゼロに近づける
④ 最終チェックは「人間」が担保
■ なぜそうしたのか
完全自動にこだわると例外処理が爆発し、逆に運用が崩壊しかねません。
人間が判断すべきポイントを1ヶ所に集約した方が、運用の耐久性が高くなります。
■ 実装内容
1.OCR結果を整形し、人は「OK or NG」だけを判定
2.NG時は差分のみ修正 → 再確定
3.判断の余白を一点に集めることで、担当者変更でも品質が揺れない
⑤ CRMへ確定情報を登録
■ なぜそうしたのか
CRMに登録する時点で確定した情報にすると正しいデータだけが蓄積できます。その上でステータスの管理だけをする場所にすることで、運用と振り返りの両方が強くなります。
■ 実装内容
1.確定情報のみCRMへ登録
2.スプレッドシート/チャット/紙などとの重複管理を排除
3.過去データの信頼性を担保し、分析にも使える状態へ
⑥ ステータス管理を“流れの中で”行う
■ なぜそうしたのか
「今どこか」「誰が持っている」「次は何か」が曖昧になると、業務は必ず止まってしまいます。
■ 実装内容
1.受注 → 工事 → 入金 → 支払い の進捗をCRM側で1ビュー化
2.担当者変更に影響されず、ボールの所在と次のアクションが常に明確
⑦ 工事完了 → 請求の自動連絡
■ なぜそうしたのか
請求漏れは意識の問題ではなく仕組みの問題です。
トリガー（完工）に紐づけて自動化する方が安定します。
■ 実装内容
1.ステータスが「完工」になったら、自動で「Chatwork」に請求書画像付きで通知
2.現場で手渡し運用にも自然に接続（デジタルとアナログの橋渡し）
⑧ 支払いの完了を確認
■ なぜそうしたのか
支払い名義の揺れ・例外が多く、AIに完全委任すると逆にミスの温床になってしまいます。
「最後だけ人」が最小コストで最大の事故防止になります。
■ 実装内容
1.入金/現金/カード（分割・一括）を一覧で管理
2.カード以外は名義揺れ確認のため目視チェックを残す
（例：契約者は息子/支払い者は父/緊急対応で妻が署名、など）
ポイント：完全自動にしないのは諦めではなく事故を防ぐ設計。
最終判断ポイントを限定し、そこだけ人が担保することで運用の耐久性が最大化される。
結果
今回の取り組みは、劇的な効率化に成功したわけではありません。
ただし、ひとつの大きな変化がありました。
「入金まで漏れなく業務が完了」するようになったことです。
■ 良かったこと
案件管理・進捗管理が適切にできるようになり、請求漏れ・入金漏れ・重複請求がほぼゼロに
「誰が今どこまで作業しているのか」が曖昧にならなくなった
担当交代／引き継ぎによるストップが発生しなくなった
派手ではないが、抜け漏れなく、止まる不安もなくなるという安心が現場に生まれました。
■ 一方で悪かったこと（課題として見えたこと）
入力作業に慣れるまでは、効率が上がったとは言い難い
そもそも業務量が多くないため、削減効果を大きく体感しづらい
例外が多く、完全自動化を目指すほど開発コストが膨らむ
→ 開発/維持コストに対して得られる効率化が釣り合わない場合もある
今回の現場では「劇的な生産性向上」には繋がらなかった一方で、「経営の安全性（＝止まらない・漏れない）」は劇的に向上しました。
この取り組みから分かったこと
今回の実践を通して強く感じたことがあります。
BPaaSは“銀の弾丸”ではない
BPaaSを導入すれば何でも効率化できるわけではありませんでした変更・改善にもコストはかかる
開発コスト/習熟コスト/組織の力学などは必ず存在しますその特定の業務量が少ない現場では、効率化の成果が見えづらい
そもそものボリュームがない&エッジケースが多いと割に合わない開発が多いたとえ大きな時短に繋がらなくても、会社が止まらないという大きな安心を得ることができる
ギリギリのリソースで回している中小企業にとって、実は「速くなること」と同じくらい「事故らないこと」も経営上の価値が高い
kubellへの確信
今回の現場での経験は個人がBPaaSの解像度を上げる上で非常に役立ちました。
理解していたが、ひとつ大きく確信に変わったことがあります。
「小さすぎる現場」では成果が小さく見えることもあります。
しかし「同じ課題を抱える SMB が多数存在する」なら話は別です。
今回の取り組みは たった1社・1現場の事例でした。
しかし、もし同じ課題を持つ SMB に横展開されていけば──
「止まる不安がない」という安心が何百・何千の現場に広がる
現場で働く人の心理的負担が減る
事業データの信頼性が上がり、経営判断が強くなる
属人運用から仕組み化へ、スムーズに移行できる
1つの現場では小さな改善でもSMBという面で見れば、それは大きな価値になります。
今回の取り組みで、BPaaSが持つポテンシャルを改めて実感するとともに、kubellが掲げる方向性への確信はより強くなりました。
それと同時に、個社ごとのオペレーションを一定変更する必要がある点は、既存のSaaSと共通する部分でもあると分かりました。
この記事を読んで、もし少しでもkubellに興味を持った方がいれば、ぜひこちらを覗いてみてください。
