AIとSaaSカスタマイズの可能性
こんにちは、ゼロトピックです。 今回は、いろんなポッドキャストと聞いていて、
AIによって、ホリゾンタルサービスがどんどん カスタマイズされていくんじゃね、みたいな論調、
主にアメリカ、シリコンバレーのVCの方々が されているのを聞きまして、
それについて、自分が思ったことを 話していければなと思っています。
そもそも、どういう論調かっていうと、 いくつか、私が聞いたものを含めて、
ディープリサーチ、リサーチをさせて まとめたテーブルがあって、
それを見ながら少しお話しするんですが、 AIによって、SaaSのカスタマイズっていうのが、
いろんなやり方で起きるんじゃないか。 ただ、これによって、いわゆる
ホリゾンタルSaaSっていうのが、 バーティカルなSaaSの領域にまで
染み出していく、その領域を増やして いくんじゃないかっていうのが、
議論として一つあったので、 面白いなと思っていたわけです。
そのカスタマイズの方向性として、 例えば、大規模なパーソナライゼーション。
AIがユーザーの行動とか思考に合わせて、 今までだと、レコメンデーションで
商品を推薦するとか、そういうのは、 いわゆるLMじゃない世界でも
あったわけなんですが、それを 画面レベルで変えていったり、
みたいなユーザー個別のパーソナライゼーション があるんじゃないか。
これはレブテックキャピタルという 方の方が仰っていること。
他にも、AIエージェントが特定の業務とか ワークフローに自律的に入っていって、
従来のホリゾンタルSaaSを超えて、 より深いワークフローを賄うような
サービスになっていくんじゃないかと。 あるいは、そのAIエージェントの活躍によって、
その産業特有のワークフローみたいな ものにも対応ができるんじゃないか
ということをセクウェアの方が仰っていたり。
これ以外には、ホリゾンタルSaaS自体が、 これ今でもちょっとあり得る状態だと思うんですけど、
いろんなAIとかツールのハブ的なものに もっとなっていって、
このハブになった上で、企業全体のコンテキストを知るので、
カスタマイズっていうのが、より高度に できるようになっていくんじゃないか
というアンドリューセン・ホロビッツの方が 仰っていたりと。
こんな感じで、ホリゾンタルSaaSに対して、
AIによって、よりカスタマイズで柔軟性を与えることによって、
その領域が増えていく。
それによって、バーティカルSaaSでしか賄えなかったような、
特殊なもの産業と固有のワークフローみたいなものも、
賄えるようになるんじゃないかみたいな議論があって、
非常に面白いなと思ったわけです。
日本におけるカスタマイズ文化
僕ら10Xはどちらかというと、今の話の対立というか、
対抗軸でいうと、バーティカル側に位置しているわけなので、
これをどう捉えるかなっていうのを、
自分の経験をもとに少し考えてみました。
その話をちょっとできればと思うんですが、
まずそもそも、個社とか個別の産業ごとに、
完全にフルカスタマイズされたシステムっていう捉え方をすると、
別にAIかどうかっていうのは置いておいて、
日本ってそういう固有のシステムが、
すごく流行している国の1個だと思うんですよね。
それは、いわゆるSIERっていう方々が、
個社と個別の委任契約を結んで、
その会社のためのシステムを作るっていうことを、
招集官としてやってきた国だし、
日本のソフトウェア市場の、いまだに8割とかそのぐらいが、
いわゆるSIERの市場、事業によって占められているような状態なので、
これちょっと正確な最新の数値は、
そろそろ出る指揮法を見て、
もう一度アップデートしたいと思うんですが、
ただそのぐらい、体制っていうのはサースではなくて、
SIによって占められている国なので、
個社ごとのカスタマイズの効いたシステムっていうのは、
責任とSLAの重要性
簡単に言うと流行っている国ではあると思います。
なのでそのアナロジーとして、
いろんなことを受け取ることも可能だなというふうに思っています。
バーティカルサース、例えば僕らだったらネットスーパーとか、
小売のオペレーションを特にスーパーマーケットに特化して、
効率化するようなツールとか、そういうものを提供しているんですが、
自分たちもシステムソフトウェアの提供者として、
当然カスタマイズもありますし、
個別のワークフローとかを対応していく中で、
一番困ることというか、一番最後に、
最後まで人がやらなきゃいけないことって何だろうなっていうのを考えるんですよ。
ただこれ考えるまでもなく、結構ぶつかることがあって、
それはやっぱり責任を取るっていう仕事なんですよね。
何かあった時にケツが吹くとか、理由を説明するとか、謝罪をするとか、
本当責任を取るという言葉から連想されるような仕事。
これっていうのはやっぱり最後まで人が担うもので、
なかなかエージェントに渡していくようなことが難しいし、
何ならその個社の負荷価値を高めてくれている、
信頼を高めてくれているものの一つでもあるなっていうふうに思ってるんですね。
僕はここをすごく大事にしていて、
例えば何か障害を起こしてしまったとか、
その会社固有のカスタマイズによって起きてしまった、
他の会社に何か影響を与えることとか、
当然過去にも経験があるんですけども、
やっぱりそういう時に大事なのって、
会社の誠意、誠実さみたいなものだと思っていて、
やっぱり説明から逃げないとか、
原因がはっきりとするまでちゃんと究明をして、
しっかり対策を施して、
その対策に対してコミットメントを示していくとか、
あるいはちゃんとしかるべき人が出ていって謝罪をするとか、
そういうことに回り回って自分たちの信頼があって、
その信頼があるから、実はこのサービスも使ってみたいと思っているとか、
あるいはA社と付き合っている御社が大変なこともあるだろうけど、
信頼が持てるからということで紹介を受けましたという形で、
紹介を伝って導入が進んでいっているというところが背景にあります。
この話をさっきの話と結びつけると、
この謝罪をする、責任をするみたいなところの
責任の分解点というのが大事で、
それは何を提示されているかというと、
我々の場合は契約書の中に記述しているSLAというサービスレベルアグリメントなんですよね。
サービスレベルアグリメントはこれ記述されているのは契約書の内容ですけど、
社内的な運用上はそれをさらに1個手前で砕いたや、
SLAをサービスレベルオブジェクトという、
例えばこういう顧客体験とか、
こういう顧客のワークフローとかに対して、
このぐらいの実行率とかレイテンシーというのを担保しますというのを、
社内的に一応ガリッと整備をしていて、
それをモニタリングし続けて、
ちゃんとSLAで約束した、
例えば90何パーセントとかそういう数値、
いろんなサースを使うとあると思うんですけど、
それに準拠したというか、
その根拠となるSLAをちゃんと社内的に管理するという、
これをやっているんですよね。
なので何かあったときには、
この責任分解権のSLAを既存している、
あるいはSLAにまでは落ちていないけど、
契約書の中で自明と思われるような、
我々の責任というのを既存してしまっているから、
責任が発生する、謝罪をする、
こういうことになっていますと。
で、このサースみたいなものが、
無限にカスタマイズされたりしていくと、
この無限の境界線ができていくんですよね。
例えばある会社には、
この機能が個別に使われていますというのが、
先者だったら、
先者分だけそのサービスレベルを保証する必要があるので、
先パターンのSLAとか、
SaaSとサービスレベル管理
あるいはそれに紐づくSLOとか、
こういったものを管理する、
マネージする必要が出てきて、
これやっぱり僕機械だと全部無理だと思っているので、
最終的には人が、
社内の管理も、
あるいは社外に対する説明とかも、
どこかで関与し続ける必要があると思っています。
ここが一番のボトンネックになるんじゃないかなというか、
前に膨らみすぎた時に、
人がマネージ不可能な状態に陥るんじゃないかな、
というふうに思っています。
さっき日本は、
いわゆるSIみたいなものが、
市場のマジョリティを持っているんだ、
みたいな話があったと思うんですけど、
ゆえにこのSIの企業って、
やっぱり一社一社の単価が高いが、
取引者数が何万社ですというケースって、
ほとんどないと思うんです。
数千社ですというケースもあまりなくて、
やっぱり取引者数というのは、
それ以内に限られている。
もしかしたらもう全然あるのかもしれないですけど、
自分が知っている大手のSIさんというのは、
取引している企業というのはそんなに多くない。
一社単位の単価はものすごい高いという状態になっていて、
ゆえにSAとかSLOの管理だったり、
あるいはそこに紐づくナレッジとか、
人の知識とか経験みたいなものは、
溜めていきやすい状態になっているんですよね。
ただこれをホリゾンタルサースっていう、
本当に何千何万社っていう会社に導入することが、
ビジネス上の諸余、
当たり前であるっていうようなビジネスモデルで、
個社ごとのAIによるカスタマリゼーションみたいなものが
起きたときに、果たしてこのSA、SLOみたいな
サービスレベルとか信頼とか、
その責任の分解点みたいなものを、
実際に管理したり運用することができるんだろうかっていうのが、
自分的には今一番疑問に思っているポイントです。
例えばこれを管理、マネージできるようにしようとしたら、
例えば何らかの障害が起きたときには、
その影響範囲っていうのを、
やっぱりその一社、個社にしっかりとどめるような
実装設計が必要ですし、
一社一社ごとにどういう取り決めを交わしたいのかっていう
契約の管理も必要ですし、
その後ろで契約の元になっている社内の、
例えばモニタリングすべき指標とか、
あるいは訂正的な状態っていうのも、
それぞれ管理する必要があって、
それがずらっとN必要になってくるっていう感じなのかな
っていうふうに思っています。
それめっちゃ大変だろうなというふうには正直思ってますし、
一番そのカスタマイゼーションが無限に増殖していって、
顧客からしたら1個のツール使ってたら、
全部のワークフローも行えますっていうのは、
すごい便利な世界だとは思うんですけども、
それを実際に預け切れるような信頼を得るまでには、
そのSLへSLを責任の守れるかどうかっていうところの信頼が、
一番のボトネックになってくるんじゃないかなと思っています。
ただ一方でGoogle Cloudとかが障害を起こしたりしたときに、
いろいろ説明求めたりするんですけど、
使用対応で対応期間遅れたんで、
チケットクローズしましたみたいな反応もされたりすることもあったりしたので、
そういう意味で大手のいわゆるプラットフォーマーが、
どこまでそのSLAとかSLを頑張って運用としているかみたいな問題は、
別であるな。
そんなの無視したら無限にカスタマイズさっさと進めちゃうぜ、
みたいなのもありそうだなと思ってはいるんですが、
それはそれとして、
わびさびのある日本の取引だとちょっと難しいケースというか、
カスタマイゼーションの課題
超エンタープライズ向けに事業を展開していくケースだと、
それは難しいかなと思っています。
ので、自分の結論でいうと、
先ほどのVCの人たちの、
AIでどんどんHorizontal Sourceカスタマイズしていくぜ論みたいなのには、
ちょっとひいた目というか、アゲイストな立場を取っていて、
そう簡単ではないと思っている。
当然そこに対してブレイクスルーは起きていくとは思うんですけども、
私、責任を取るのが人間の仕事だと言っているのも、
どっかのタイミングで必ずスイッチしているんですよね。
エレベーターもね、昔はエレベーター交換子みたいな人が必ず乗って操作していたのが、
今そんな人、人にも百貨店でたまに見るぐらいで乗っていないので、
責任を取るという業務すら、最後はシステムが置き換えていくとは思っているんですけど、
そう簡単じゃねえぞと思っていまして、
そのタイムラインの問題に陥るのかなというふうには思っています。
私の結論は、製品というのは長期的に保守運用していく必要があって、
そのボトンネックが、このカスタマイゼーションの増殖という文脈ですと、
人間になるというところでした。
この辺りは実際にAIを使った開発をしたり、
AIを自分たちのプロダクトに組み込んでいく企業ほど、
改造度を持ちやすい部分でもあると思いますし、
自分も勉強したい部分でもあるので、
ご意見だったりコメントだったりあれば、ぜひ教えていただきたいな、
議論したいなというふうに思っています。
ということで、今回もお聞きいただきありがとうございました。
