00:03
Product AI Talks。この番組は、ITスタートアップで事業づくり、プロダクトづくりに取り組まれている経営者の方をゲストにお招きし、
昨今のAI大統領も踏まえた、AI時代のプロダクト戦略を深掘りする番組です。
番組へのコメントや感想は、Xでハッシュタグ、PAunderbarTalksをつけてお寄せください。
今回は株式会社kubellの執行役員CSO兼ビジネスリビジョン長の桐谷豪さんをゲストにお迎えしました。
前編では、BPaaS事業盛り上がりの裏にある時代背景・技術的背景や、kubellにおけるBPaaSの設計思想、
さらにこれまで苦労した点やkubellならではの工夫をお伺いしています。
ポストは私グロービスキャピタルパートナーズプリンシパリ工藤真由と、テクタッチCFO兼CPO中田雅也さんでお届けします。
それでは今回は株式会社kubell、旧チャット株式会社の執行役員CSO兼ビジネスリビジョン長の桐谷豪さんにお越しいただいています。
桐谷さんよろしくお願いします。
はい、よろしくお願いします。
改めて最初にkubellがどういう会社なのか、特に最近強化されているBPaaS事業とはどういう事業なのか、
オーディエンスの方にお伝えいただいてもよろしいでしょうか。
改めてよろしくお願いします。株式会社kubellのCSO桐谷と申します。
kubellという会社は元々旧チャットワークという社名でビジネスチャットを運営している会社になっています。
ビジネスチャットの方は国内で最大急濃という形で主に中小企業、非ITの方たちにお使いいただいているようなサービスとなっております。
先ほど頭渡しいただきましたけど、BPaaSという事業が今大きな2本目の柱というところで、この数年思い切りグロースをしているところとチャレンジ中の会社になっています。
その他細かいいくつかサースだったりとかあったりするんですが、チャットワークとBPaaSというものを主軸として運営している会社になります。
BPaaSに関しては、これちょっといろんな定義があると思うんですけど、弊社では型化されたプロセスと人材を含むオペレーションをクラウド上で購入ができるビジネスモデルという形で定義をさせていただいています。
なのでまた細かくなると思うんですけど、これまでBPOという形で大手の会社さんが仕事、農家業務を外部の業者の方で出して処理をしていくみたいな概念があったと思うんですけど、
これが中小企業の方とかはお使いいただく場面とかっていろんな要因があるんですがなかったというところに目をつけておりまして、
チャット系でそういったBPO業務みたいなものとかを受け取って、弊社の方で人と歯とAIアジェントみたいなものとかを駆使しながら超効率的にオペレーションを回して成果を返していくというようなそういった事業を営んでおりますというところでございます。
ありがとうございます。この後、ぜひBPaaSのところもよりどういう風に設計されているのかとか詳しく伺っていきたいなと思っているんですが、
03:05
まずは桐谷さんが2020年にKubelに入社された後のことなんですが、
Kubel入社前にどういったことをなさってきたのかとか、これまでのご経験も教えてもらってよろしいですか。
そうですね。ファーストキャリアは株式会社パネイルっていう会社の従業員第1号でして、
大学時代ですね、あまり学校にそんなに真面目には通ってなかったので、一生懸命スタートアップの立ち上げみたいなところを経験させてもらいましたというところです。
ここは主に電力とかガスとかインフラ周りの当時2016年、電力自由化って法令改正があったんですけど、
そこで参入したIT系のスタートアップだったんですけど、ものすごい自流に乗って成長した会社ではありましたというところで、
そこで本当に何でもかんでもやってましたというところで、最初は自分の自宅のアパートと社長の家とそれこそチャットワークつないでですね、
お仕事始めたみたいなところから営業だったりとかオペレーション作ったりとか、
そこからプロダクトマネージャーとまでは言い切れないかもしれないですけど、
そういったものとかを何でもかんでもやってたっていうのがファーストキャリアではありますというところですね。
そこはすごくうまくいって売上も数年で数百億ぐらいまで伸びてですね、ユニコーンみたいな感じになってたんですけど、
そこの中でジョイントベンチャーを東京電力さんと一緒にやりましょうというところで、大手の会社さんと一緒にまた電力協会とガスとかも含めてなんですけど、
事業立ち上げをバババッとやってきたみたいなところが最初のファーストキャリアですというところですね。
なのでめちゃくちゃスタートアップで主にひたすらエグゼキューションをやり続けるみたいなところが一番最初だったかなというところに起点がありますというところです。
その次が前職になるんですけど、2018年、19年に株式会社アベジャーですね、3年ぐらい前ですかね、上場した英系のベンチャーであったんですけど、
当時はおそらく社員50人ちょっとぐらいだったんじゃないかなと思うんですが、
ちょうどGoogleさんとかから調達をしたようなタイミングで上場目指しましょうみたいなタイミングのところで、
他AIの絵の字もあんまりわかってなかったんですけど、
それこそ今のLMの起点になるようなトランスフォーマーの仕組みとかが言われてザワザワし始めたっていうタイミングだったかなと思うんですが、
当時はディープラーニングとかで画像とか結構主流だったと思うんですけど、
自然言語とかも面白いかもねっていうふうな雰囲気感が漂ってる時代にアベジャーに入って、
そこでは一番最初ビーズデブとして入社して、3ヶ月4ヶ月ぐらいだったと思うんですけど、
事業持ちをやってくれというとこで、1年半ぐらいかな事業持ちをやってましたというキャリアになってます。
ありがとうございます。そういう中からKubelに入社したのってどういったきっかけとか経緯だったんですか?
そうですね、結構自分キャリアを決める中ですごく大事にしてることがあって、
いつもゴールデンタイムみたいな話をするんですけど、
ある領域で前提になっているルールが一気に変わる瞬間ってあると思っていますというところで、
そのタイミングにやっぱりすごい優秀な人とかってめちゃくちゃ集まってくると思うんですよね。
06:04
結局そこにいたかどうかで、ほぼほぼポテンシャルもあると思うんですけど、
キャリアって規定されると思ってますというところなので、
1社目のファーストキャリアの時の電力自由化っていう法律が一気に変わって、
戦後ずっと国営の会社が運営してたところに、
なんかウィンドウが開いたっていう瞬間だと思ってますというところなので、
あの当時の電力業界ってお金もそうかもしれないし、テクノロジーもそうかもしれないし、
人がすごく集まってたっていうところがあったんですね。
なので、そういう選び稼働してますって前提なんですけど、
その次にアメジャを選んだところで言うと、
当時はAIとブロックチェーンとARVR、ここの3つを2週間くらいひたすら調べまくったんですよ。
それこそGoogleのバートの大元になっているAttention Isolatorによった論文を読めるやつだと思うんですけど、
その辺たどり着いて、正直何を言ってるかわかりませんでしたっていう感じなんですけど、
みんな騒いでたので、その辺でいろんな人に話を聞くと、
多分AIだなと思ったので、AI飛び込まないといけないと思って話を聞いてみたら、
やっぱりすごそうっていうところで思い切って飛び込んだっていうのが、
アメジャに入ったという経緯ですと。
そこからいろんなプロジェクトとかご一緒させていただくと、やっぱり間違いないなと思ったんですよね。
当時はGPTとかも出てましたけど、なかなか世の中には広くあまり広がってなかったっていうのが実態かなと思うんですけど、
近いうちのOpenAIとかGoogleとか、どこかわからないですし、いつって明確にはわからなかったんですけど、
このすごいモデルが絶対にイノベーションを起こすっていうところはわかってはいたんですよね。
なのでそうなったときに、テキストを持ってるとか、
そういう業務の指示を出せるみたいな、自然言語のインターフェースを持ってるところとか、
あるいは、当時はAIアジェットって呼ばれ方はしてなかったですけど、
言語を起点としてタスクを処理をしていくみたいなものとか、
思考が回っていくよねみたいな、そんな概念が出始めてたので、
これは面白いかもしれないなっていうところで当時、
テキストを持ってるとあと音声を持ってる会社さんとかプラットフォーマーがめちゃくちゃ興味があって、
うちの会社の決算資料とかめちゃくちゃ読んでたんですけど、
これ間違いなく面白いと思って、2020年の10月ですかね、入社をしましたというところですかね。
JPTリリースされたときによかったって思いましたみたいな、そんな感じですね。
すごい、この選び方だけでもすごい、もっと深く伺いたいぐらいなんですけれど、
ちょっと話を先に進めて。
その後、2025年7月に今の執行役員、CSOっていうポジションに就かれて、
今はビジネスディビジョン長、みんな追われてるってことだと思うんですけど、
今のキリタリストのミッションだったり、注力事項っていうところはどのあたりになってきてるんでしょうか。
まだロールは2つでして、CSOって形でストラテジーなので、
チャットワークリバースに限らず、グループウォールの中長期の戦略、
経営戦略的なところも含めて書きますというところが1つかなというふうに思ってますというところですね。
これはなんで、いろんな社会背景とか世の中どう変わっていくんだろうっていうこと、
自分たちのアセットみたいなものを活かしながらどういうポジショニングを作っていくかみたいな、
そんなことをやってるお仕事が1つあるかなと思ってますというところです。
09:02
もう1つのビジネスディビジョン長というところに関してで言うと、
いわゆる組織としては、ざっくり言うとビジネスサイトの人たちが所属をしている、
いわゆる一般的な本部だと思うんですけど、そこのトップとして事業鑑賞をしてるっていう、
そんな形になってますというところですかね。
なので、一応書く部分も、戦略書く部分もあるんですけど、
ここの実行の部分とは切り離さずに、実行をしながら戦略にフィードバックを返していくみたいな、
そんな概念でお仕事させてもらってます。
ありがとうございます。
早速ここからBPaaSっていうところ、特にAI時代のBPaaSの作り方みたいなところをどんどん深く伺っていきたいと思うんですが、
まず最初に、先日年末にもBPaaS AIBPOカオスマップ2025年版みたいなものも公表されていて、
すごくたくさんの会社さんが掲載されてると思うんですけれど、
改めて、なんで今BPaaSだったりAIBPOっていうところが盛り上がってるのか、
その時代背景も技術背景とか、さらにクベルとしてもここに取り組もうと思った背景にある、
経時に今考えてることなどから伺っていきたいなと思うんですが、この辺りいかがでしょうか。
そうですね。ちょっといろんな観点から語れるかなというふうに思うんですけど、
まず、サース企業として、事業をやってる身としてっていうところは結構あったのかなというふうに思っておりまして、
一般的に10年前と比べると国内のサースの市場感って割と埋まり始めてるんじゃないかなというふうに思ってますというところなので、
この辺がエンタープライズに登ったりとかマルチプロダクト化していったりっていうところで、
ワンプロダクトから横にどうやってタムを拡張していくかみたいなものは、
すごく大きなケアアジェンダとしてはあるのかなというふうに思っていますというところで、
そこは各社どうしようかなって思ってたっていうタイミングは、
すごくこの数年あったんじゃないかなっていうふうに思ってますというところです。
まずそれが一つと、
もう一つはやっぱりAIの話がめちゃくちゃ大きいなというふうに思っておりまして、
俺らの認識だとBPaaSって呼び方してるんですけど、
ソフトウェアの市場からそれを扱う人材の市場に入っていったっていうような認識をしてたりするんですよね。
なので結構大きなタムの拡張ができたなっていうふうに思ってたりしますというところで、
これはシンプルに人材紹介とか人材派遣みたいなモデルではなくて、
やっぱりそこをAIが代替をしていくっていう形にすることで、
事業としてもこれは利益も出るしスケーラビリティも拡張ができるんじゃないかっていう技術が追いついてきたっていうのが、
この2つが細かいところとあるんですけど、大きく2つなんじゃないかなって気がしてます。
なるほど。
BPaaSといってもいろんな広い領域がある中で、
今、クベルさんとしては経理ロームみたいなところが中心になってるんですかね。
そうですね。ボリュームゾーンで言うとその2つですね。
ついで直近とかだとRPO採用の領域とかも立ち上げ始めてますというところだったりするので、
その辺が多いかなというところではあります。
一方でそこだけに絞ってるかっていうと、
実は営業事務的なものとかクリエイティブ政策みたいなものとか、
割と幅広くやらせてはいただいてるかなというところですね。
ここもかなり議論をしましたというところで、
12:03
経理だけにドメイン特化してまず立ち上げるべきか、
全方位的に始めるべきかみたいなものとかは、
割と大きな議論ではあったかなというふうに思ってるんですが、
一応弊社としてはBPOっていうところで、
最初は人も抱えながらやっていくというところで、
これを子会社作って、
自分たちの社内で全部オペレーションも人も抱えてやってるっていうところなので、
稼働率って概念がすごく重要だったりするんですね。
なので経理とかロームとかだけだと、
月末とか月初とかだけめちゃくちゃ忙しくって、
月の半ばがちょっと余っちゃうみたいなものとかがあるんで、
この辺の最適化をしようとすると、
いろんな領域をやって利益も担保しながら、
ちゃんとマッピングをしていくっていうことをやるっていうのが、
ビジネスはすごく重要だったりするので、
そういう意味合いでちょっと幅広にやらせていただいてますっていうのが、
うちが選んでいる選択肢かなというふうに考えてます。
今のところ結構面白いなと思ってて、
稼働率っていう概念でいくと、
多分いろいろやった方がバランスよく埋まるよねってあります。
ただ一方でBPOの方が扱うシステムだったりだとか、
ワークフローを組むという意味では、
特化させていった方が尖らせて、
Go-to-marketとかも含めてやりやすいのかなと思ったりもしていて、
そこのトレードオフのオフになってしまうところに関しては、
どんなふうにベルで工夫されてるんですか?
そうですね。おっしゃる通りなんですよ。
そんなに魔法はないかなっていうふうには思ってますというところなので、
やっぱり一番Aが効きやすいところだったりとか、
カタカナしやすいところとかに、
とはいえ注力はしてたりしますというところで、
それが結果的に経理とかローズとかが、
一定をオペレーショナルシステマティックに動かせるような業務フローだったりするので、
そこをボリュームゾーンとして圧縮をしながら、
全体としての総量も担保し、可動率を担保していくっていう、
こういう全体のバランスの中でやってますというところですかね。
なので実は言うと、外には出してないんですけど、
うちは実際一人でヒューマニザルグ的に作業とかもしてたりするんですけど、
この方たちをクルーさんって呼んでるんですけど、
クルーの方たちにアサイメントをしたりとか、
プロジェクト管理をしたりとか、
それこそこのツール使ってね、みたいなものとかで振り分ける、
いわゆるルーティングをするような、
そういうシステムを裏側で持ってたりして、
これ実運用でやったりするんですけど、
これが実は言うと、表に出ないんですけど、
最自由だったりするので、
得意な方とかにこれをやってもらったりとか、
そういったものとかも運用しながらやってますというところですかね。
なるほど、ありがとうございます。
ここからさらに、
ビーパースの設計思想みたいなところも改めて伺いたいんですけれど、
年末、桐谷さんもビーパースのアドベンツカレンダーの一環として、
ノートで2回ほど執筆されていて、
その中でもこのビーパースの体制づくりだったり、
アーキテクチャの設計を考える上で、
1つ目のオプションとして、
AIツールを良い感じに使ったオンラインBPOとしたときに行く。
2つ目のオプションとして、
エージェンティックなアーキテクチャをベースに考えられたオペレーションと、
それに準じた体制を量産した組み合わせ問題としたときに、
この2つがあって、
で、Kubelではこの2つ目を選択しています、
といった記載があったと思っています。
まずこの部分に関して、
15:00
ビーパースに普段取り組まれていない方でも分かるような感じで、
Kubelのビーパースの設計思想みたいなところ、
ここまでの話と繋がるところもあるかなと思いつつ、
教えていただいてもよろしいですか。
はい、ちょっと道半ばなので、
半分理想論も含んでますっていう前提にはなったりはするんですが、
個社ごとに微妙に異なるBPO業務をAツールをいい感じに使ったっていうところは、
本当に読んで順法得だったりするんですけど、
ある担当者がA社の例えば給与計算とかでもいいんですけど、
給与計算の業務を受け取って、
その一連のフローを全部その個社ごとのルールを理解をしながらずっと回していく、
これをA社、B社、C社、3社ぐらいまでいけるかな、いけないかなみたいな感じでやっていくので、
ツールをうまくその人が使いこなせるか、
あるいはその会社独自のオペレーションとかコンテキストを人が覚えていきながらやっていくというところに、
スケーラビリティ化を規定されますというところになっています。
これはこれで別に全然定期も出ると思いますというところですし、
いいことかなというふうには思ってますというところです。
一方で、シンプルに言うと、
人の採用困っている人材市場に対して、
僕らオペレーションって形で切り取って入り込んでるんですけど、
我々も絶対人取るの難しくなってくるはずなんですよね。
ツールとかサースをめちゃくちゃうまく使いこなしながらやっていく人って、
そんなに世の中にたくさんいるわけではなかったりしますというところなので、
これをいかに細かくフローを切った上で、
適切な人にアサインをしていくかっていうところがすごく重要かなというふうに思ってます。
なので、一連のワークフローをどの流され解くかっていうのを、
前者の方は最初から最後まで全部一人が担当しますというところなんですが、
一方でエージェント的に解きに行きましょうみたいなところとかで言うと、
それをちょっと長さの概念いろいろあるんですけど、
細かく分断をすることによって、ここはAIでやりましょう、
ここはこの人たちの人でやりましょうみたいなこととかを、
この細かい単位で分断をしながら作っていくというのは、
組織的にオペレーションのトスアップの仕方みたいなのとかでも、
全くこの中で外伝かなというふうに思います。
これで全然スケーラビリティとか利益率とかも変わってくるなというふうに考えてます。
これなんかイメージ持ちやすいように、
例えば経費申請みたいな、これに事例を取った時に、
これどれくらいの単位とかで切り取ってアサインされてるんですか?
給与計算とかでも大丈夫ですか?
もちろんもちろん。
給与計算でビバスでカタカって概念がすごく重要なんですけど、
何をカタカするかっていうのが、大きさが全然異なっていてですね、
うちの社内では3つに分けてます。
一番小さい最小単位まで分解された処理のことを、
一旦コンポーネントと呼んでますというところです。
このコンポーネントをつなぎ合わせたシーケンスというか、
一連の流れのことをワークフローと呼んでますというところですね。
このワークフローを組み合わせて商品化されてるメニューのことを、
パッケージと呼んでますというところなので、
この大きさがすごく概念としてはまず重要です。
一番小さいところからいくんですけど、
例えば給与計算をしようとすると、
18:02
一番最初に従業員ごとの勤務形態みたいなものとか、
絶対分かってないといけないので、
このデータベースの更新をしますみたいな、
最小単位の処理みたいなものがあったりとか、
勤態実績の一時集計をするために、
これ押してねみたいな通知をチャットでするみたいな話とか、
これが一旦集まってくると、
もう一回データベース更新をして、
魅力の人に対して、ここ押せてないけど休んでましたか、
出勤してましたかみたいなこの再通知をするとか、
細かい処理があるんですよね。
なので、極論はこのコンポーネント単位で割り振ってますと、
例えばチャットの通知みたいなものとかって、
そのチャットワークとつなぎ込むと、
全然いろんなところに使えますというところだったり、
これも完全に自動化しましょうみたいなものがあったりとか、
勤務形態のデータベースの更新みたいなものとかは、
ちょっと一人で目視確認しないといけないですよね、
みたいなものとかがあったりしますというところですね。
これがこのコンポーネントの組み合わせで、
勤態実績の収集っていう一連の流れのワークフローが完成をするので、
この辺ぐらいから各社によってちょっと例外処理が出たりとか、
そういったものとかがありますというところですね。
ここでさらにこの勤態実績の収集みたいなものとかが、
できるとチェックがあって、確認があって、
給与データの作成がされて、
給与の支払いの処理が続いていくみたいなパッケージになっていくみたいな、
そんな形になって、この大きさが3つあるっていうのが
すごい重要かなというふうに思ってます。
かつ、一番小さい単位でできる限りやったほうが、
人の処理はより簡単になるし、
それこそ組み合わせ問題で解きやすくなるので、
スケーラビティが出るみたいな、そんな概念ですね。
お客様向けには給与計算とか給与支払いみたいなパッケージで売られているけれど、
実はその最小単位としては、
勤務形態確認とか再通知みたいなコンポーネントがあって、
ここまではどのお客様も割と共通性がある。
そこからワークフローで勤態実績の収集とかになってくると、
少しずつ個社ごとのカスタマイズとかバラエティーは少し出てくるけれど、
とはいえ8割がと一緒だよね、みたいな世界観を作っていくっていう、
そういう思想っていう理解であっても。
おしゃれ通りですね、まさしくコンポーネントで販売しようとしても絶対売れないので、
ワークフロー、もしくは正直パッケージのほうが一番売りやすかったりするんですよね。
なのでお客さんからするとパッケージとして提供されているという形ではあるんですけど、
裏側ではコンポーネント組み合わせとワークフローをどういう形で設計していきましょうかっていうのをガチャガチャやっているっていう、
そんな形ですね。
でもこれあれですね、BPOに限らずこのコンポーネントをどう区切っていくのか、
どこの部分をエージェントに任せて、どこを人間がやるのかっていうのが、
AI自体のプロダクト作り全般においてかなり重要。
ここに各社の味噌が出てきそうな。
全部ここだと思いますね。
ルーティングというか、どこをどこまでAIでやってどういう処理にするのかとか、
例外処理を認める認めないみたいな、この辺が本当にコアかなっていうふうに思っているので、
すごく面白いですね、ここは。
まさにこの人とツール、そのツールの中でもAIどこまで使いますかみたいなところ。
で、その人も関わり方として作業者になるのか監督者になるのかみたいなところの、
多分コンポーネントごとに異なって、それを組み合わせていくっていう話だと今のところも思ってるんですけれど、
21:07
この辺り結構、桐谷さんもXの方でその人の関わり方とか、
AIの関わり方っていろいろなパターンあるよねみたいな投稿をされていたと思っていて、
今現時点でこのKubelとしてそこを考える上での軸となる考え方とか、
こだわってるポイントみたいなところって、どんなところがありますか。
そうですね、まず現時点でお話しさせていただくと、
Humanism Loopもいくつかのパターンがあると思って、
まさしく人が主体になっていて、人が監督者だったりとか、
ディレクターみたいな感じのさっきの組み合わせ問題を設計をするっていう、
そういう概念の人もいれば、
その中のコンポーネントの一つの処理を正しく実行していくとか、
間違ってないか、制度を担保するような耳合いの方とかもいらっしゃったりしますというところなので、
これはまだ入り混じっています。
ただし、そもそもこの組み合わせ問題ができるような形に、
組織の設計を変えておくとか、
さっきちょっと言ってた、社内のシステムをどういうふうに作っていくかっていうところで言うと、
未来は必ずこの設計をしていくっていうところも、
AIがやっていく、本当にピュアなエージェンティックAIの形になっていくので、
この思想でシステム設計もしてるし、組織設計もしています。
ただし、システムでやらないところもあったりするので、
今の時点で言うと、このワークフローの設計自体を、
ここを一気に全部AIで作りましょう、難しいので、
人が型を作って、まず正解っぽいものを作る、
また別のパターンとか出てきたら、また新しいものを作って、
これとこれって同じだよね、みたいなものとかって出てきたりするので、
再利用可能な形で残しておくっていうような、
そんな形の概念で、システム的にも組織的にもアーキテクチャの設計をしてるって感じですね。
ここはめちゃくちゃこだわってます。
ちなみに最近思うのが、AIエージェントとかって歌われるけれど、
ある種、ちゃんとAIがコンポーネント単位でもいいけれど、
一気通貫で行動ができて、かつそこの評価がある種、
ちゃんと俗人的じゃなくって一定の基準でできると、
その挙動評価みたいなところがちゃんと蓄積されて、
すごいAIがどんどん強くなっていくなと思ってて、
逆に言うと、人のアシスタントっぽい動き方とか、
コンポーネントも一部しかいないとかになると、
あんまりエージェントかませるのって、
なかなかそこをエージェント強くしていくというのは難しいな。
だからそれが一個、エージェント化するか否かとか、
AIに任せるか否かの基準になるのかなって、
個人的には思ったりもするんですけど、
その辺り、桐谷さんの今のお考えとかも含めて、
どんなふうにそこをごまかせ方とかも含めて考えてます?
そうですね、本当におっしゃる通りで、
ループが回らないと学習していかないので、
ちょっと遠いですけど、利益列の向上につながらないんですよね。
ここはすごく意識をしています。
例えば、OCRとか結構わかりやすかったりするんですよね。
シンプルに言うと、評価者としての人のチェックを
入れていくっていうところは、
いろんな領域であったりするんですけど、
書類選考みたいなものとか、経緯生産みたいなものとか、
これも書類を読み込むっていう、
24:00
OCRのこのコンポーネントは違うワークフローであったとしても、
実は再利用可能だったりするんですよね。
そういったところにブワーッといろんな書類がプロードされて、
ここ間違ってる間違ってないみたいなものとかを
人がチェックをしていく。
チェックをしてNGだった場合のデータが溜まっていって、
そういうループ構造を作ってたりはします。
というところなので、これがなくて、
ただただフローとして精度を担保しましょうねっていうものと、
ループとして評価が回ってるかっていうのは、
全く意味合い異なるかなというふうには思ってます。
ここはもう本当に投資と思ってやってますっていう感じですね。
なるほど、ありがとうございます。
たぶんお聞きしてたことって、
PDMとしてはかなりど真ん中だなと思っていて、
ワークフローを見て、
ABCDEって分けて、
ここを人でやる、
ここをこの機能でやって、
こういうふうにワークフローを流してこうするっていうのを、
基本システムを作るときって絶対考えていて、
もちろんBPOでも同じっていうことだと理解をしました。
その中で、たぶん一番ど真ん中の質問って、
この2つだなと思っている質問を2つしてみたいんですけど、
まず1つが、
このワークフロー全体を100っていうふうにしたときに、
これ完全個別だよねっていうのが例えばありますねと、
例えばこの形成さんで、
これは交代費に入れるのか、
これは図書費に入れるのかとか、
いろいろな仕分けの差がありますねみたいな、
超個別っていうものと、
これってめちゃくちゃ同じワークフローで、
それはもう仕分けで、
左と右にそれを分けるものですか、
仕方仮り方で分けますみたいな、
絶対みんな同じみたいな、
だからあと承認プロセスがあって、
最終的に見たって確認をしたら、
確定版ができますみたいな、
もう誰がやっても同じものと、
あと意外に、
全く完全カスタマイズではないものの、
AIにある程度推論させると、
プロンプトとかで、
左右っていうふうに、
ちょっとコシャコシャで違うものの、
ある程度共通コンポーネントがあるみたいな、
3があると思っていて、
1、2、3を、
この3番が解けなかったものが、
急にAIで解けましたっていうのが、
多分この密度だと思っていて、
だいたい今、何対何対何ですかっていうのは、
業務によって違うんですけど、
どんな感覚だったりしてますか、
そうですね、難しい質問ですね、
対応可能なものは、
5割ぐらいなんじゃないかな、
って気がしてます、
中間がどのぐらいあるかっていうのが、
すごい定義が難しいんですけど、
それはAIも含めて、
2番、3番が、
そうです、そうです、
完全個別のものは、
絶対発生しますっていう感じですね、
これがゼロになることはないな、
というふうに思っていて、
ここがどこまでビジネス的に許容するか、
っていう話になってくるかな、
というふうに思っているので、
この辺のバランス感とかは、
すごく重要だな、
というふうに捉えています、
そういうことなんですね、
なるほど、
なのでイメージは、
マックスいったら5割ぐらい、
6割ぐらいは本当に、
いわゆるAI BPOでできて、
4割ぐらいは、
人のいわゆるBPOが残る、
みたいなのが最終局地で、
いろいろと業務によって違ったり、
それを頑張って6割を増やしたり、
みたいなことを今やられている、
27:05
1割、9割いけるとこも全然あるだろうな、
というふうに思っているので、
冒頭お伝えしたように、
われわれ結構今、
広めに取りに行ってたりはするんですよ、
なるほど、
このぐらいの割合になっているかな、
というふうに捉えてはいるんですけど、
本当にドメイン特化で、
めっちゃユースケース絞ると、
全然ほぼ裁量可能なものだけでやれますよね、
みたいなものは存在するかな、
というふうに思っています、
なるほど、
この新しい領域に行くときに、
どっちがやっているのか、
もうちょっと1回受けて、
別に1人ぐらいの人口で裁けば別に損もない、
別に利益出やすいじゃないですか、
利益出るから、
とりあえずやらせて、
やりながらワークプロを作って、
ここはやった上で、
ここはこういうふうにやろうよ、
というふうに定義しているのか、
ミックスだと思うんですけど、
どんなような進め方を最初はしているんですか、
絶対後者です、
やらないとわからない、
あんまり作業者にインタビューをするとか、
一応概念として、
後から本を読んで整理をしに行くとか、
それこそLMで何となくのワークプロを
バーッと眺めてみるみたいなものは、
効率的にやろうとすると、
ポイントポイントでは発生するかな、
というふうには思うんですけど、
どちらかというと、
自分が作業者になっちゃったほうが一番早いので、
これは結構大きな変化だと思っていて、
やっぱりうちで活躍されていらっしゃる方とかは、
正直インタビューはいらないです、
自分でやったほうが早いし、
自分でワークプロを組んだほうが早いです、
って全部言うんですよね、
業務をやりながら、
強くChapter GPTとかGeminiとか使いながら、
っていうところから始めたんですけど、
その後にDeFiでやってみたらどこまでいけんだっけ、
Nethernetどこまでやるんだっけ、
っていうところをスタートして、
それをプロダクションに落としていくっていう、
そんなやり方をしてたりするので、
これも作業をやったほうが早いですし、
ケーリングとかをやってる人とかも
死負け死ぬほどやってたりとかしますっていう、
この領域においてのスタンスとして正しいのかな、
っていうふうに思ってます。
なるほど、分かりました。
もう1個あるんですけど、
そういうスタンスで取るってなったときに、
いわゆるここをAI化しましょうとか、
このフローって今、
例えばプロの方だと
仕分けめっちゃ早いんで、
そこって本当は外から見たら
効率化できるよね、
みたいなところもあれば、
これ人でやんなくていいじゃんっていうところって、
意外にプロダクトマネージャーっぽい目線でいくと、
プロダクトマネージャーの人って
意外にそういうとこ気づける、
第三者だからみたいなところもあると思うんですけど、
そこはそういう社内のBPOの
プロダクトマネージャーみたいな人がいるのか、
なんかそうじゃなくて、
本当にBPOの人たちが
いろんな意見出して、
これでもすごい、これやったら早くなるのに、
みたいなベストプラを集積させながら、
現場から集まる声で
プロダクトでか、
AIの社内のプロダクト作ってるのかって、
どっちのスタンスなんですか?
そうですね、ちょっとカッコつけてきれいに言いたいんですけど、
ごちゃ混ぜでやってますっていうのが
時代かなと思います。
PDMというかビジネスというか、
もはやちょっと職種の定義難しいんですけど、
30:02
の方が、
一番今のところはいいかなっていうふうに思ってます。
というところなので、
さっき言った経理の作業みたいなものとかは、
クルーの方が、
例えば5人ぐらいのチームがいると、
自分でも作業をしながら、
隣で画面を見てどこで詰まってんの?
みたいな話とかを、
本当に近い距離でやっていくので、
自分が感じていることと、
周りの人を集めてっていうところは、
両方やってるかなっていうのが濁った回答ですけど、
それが実態かなというところですかね。
そういう感じなんですね。
最終的にはどっちに持って行きたいとか、
どういう感じなのかっていうと、
今決まってないですっていうのが回答になります。
理想論としてはそうですね、
そのワークローグを作っていくとか、
どこから時に行くかっていうものすらも、
やっぱり法則性みたいなのが出てくるとは思っているので、
そこは、
ずっと自分たちでっていうところは、
膨大に作りに行かないといけないものがあるので、
ずっとやるのはあんまりさせてもらえたら
ないなっていう感覚ではあったりします。
そういうことですね。
あとは、
とはいえ最上段で、
この辺、この辺、この辺、
この辺だよねっていうのは、
決めてはいったりはするんですよね。
すごいシンプルな話ですけど、
ずっと繰り返される業務化みたいな話とか、
あと重要な観点で抜けがちなんですけど、
実を言うと、
これAIでできるけど、
人でもできて、
人とAIのコストとのバランスを見てて、
人がやった方が正直安いよねっていうこととかも
あったりはするので、
この専門性とか、
市場感みたいなものとかも当然見ながらですね、
この辺、この辺、この辺かなっていうのも
一定プロットしてリプライをしてるっていうのは、
すごい面白いなと思いました。
すみません、ありがとうございます。
ちなみに、
今の桐谷さんのプロダクトの作り方みたいなのって、
BPOだから、
自分たちもアクション取れるから、
最初の走り出しは早いのかなと思ったりしました。
実際、プロダクトを作って提供するとなると、
もっと最初のヒアリングとか評依のところに
時間かかるのかなと思ったりもしたんですけど、
中谷さん、今の話を聞いて、
自分たちのプロダクト作りとの違いだったりだとか、
面白いポイントって、
どんなふうに思ったんですか?
意外に近いなと思いましたね。
ただ、
僕たちも基本的には、
新しいプロダクト作るときに、
めちゃくちゃインタビューして、
ワークフローある程度作りに行って、
僕たちが急にやるってなると、
時間かかっちゃうので、
BPOとちょっと違って、
ある程度理解した上で、
ポンポンと当てに行くんで、
若干準備はこっちの方が重たいというか、
しっかりやってる気がするものの、
やっぱりある程度お客さんに当てないと、
正直正解わかんないっていうのがあるんで、
やっぱり自社で作るものなんで、
なんでそれを、
PDCA感はすごい早いんだろうなっていうのは、
ちょっと思った気がしましたけどね。
なるほど。面白いですね、この違いも。
違いと似てるところとかも含めて、
面白いなと思いながら、
お話し聞いてました。
ありがとうございます。
それでは前編では、
クメルにおけるビーパースの根底にある
設計思想だったり、
それを実際どういうふうに作っているのか、
っていうところを伺っていきました。
桐谷さん、ありがとうございました。
33:08
業作りに取り組む経営層の方をゲストにお招きし、
AI時代のプロダクト戦略を深掘りしていきます。
後編は来週金曜日、配信予定です。
ぜひご視聴ください。