00:05
この番組は、ITスタートアップで事業づくり・プロダクトづくりに取り組まれている経営層の方をゲストにお招きし、
昨今のAI大統領も踏まえた、AI時代のプロダクト戦略を深掘りする番組です。
番組へのご意見・ご感想は、Xでハッシュタグ、PA Underbar Talksを付けてお寄せください。
小林氏の自己紹介とDS部の役割定義
本日のゲストは、株式会社LayerX AIワークフォース事業部で、デプロイメントストラテジスト、いわゆるDS部の部長を務められている小林隆之さんです。
コメンテーターとして、デルタエクスパンド代表パートナーの山崎良平さんともにお届けします。
今回から2週にわたって、LayerXの取り組みを起点に、今話題に昇ることの多いFDE・DSを主軸に据えたビジネスモデルの実態を紐解いていきます。
その第1回となる今回は、FDE・DSモデルにおけるプロダクト、その価値と作り方に焦点を当てます。
さらに、FDE・DS、そしてアカウントエグゼクティブが、どのような役割分担でプロジェクトを推進し、プロダクトを築き上げているのか。
AIワークフォース事業部として、どのようなゴートゥーマーケット戦略を描いているのか。
これまでの編成も踏まえながら、解答度高くお話いただきました。
ホストは私、Globe's Capital Partners プリンシパルの工藤真由でお届けします。
本日は、Layer X デプロイメントストラテジスト、DSの部長、小林さんにお越しいただいております。
小林さん、よろしくお願いいたします。
よろしくお願いいたします。
まず簡単に、小林さんの自己紹介ですが、現在の役割について教えていただいてもよろしいでしょうか。
今、私はLayer XのAIワークフォース事業部という、AIプラットフォームを手掛ける事業部において、
デプロイメントストラテジスト、ちょっと長いので、これからDSと呼ばせていただきますけれども、
DSと、あと、顧客接点という意味ではCSも置いているんですけれども、
DS&CS部というところの部長を務めさせていただいております。
Layer X、今、事業を立ち上げから大体2年半ぐらい、AIワークフォース事業部をやっているんですけれども、
ちょうど事業を立ち上げのタイミングで入らせていただいて、
そこから長らくビジネスサイド、ビジネスデブしかなかったので、しばらくビジネスデブをやっていて、
その後、ビジネスサイドにおいて、AE、営業、コンサルティング部隊というのを分ける組織再編を行っていて、
その時からコンサルティングチームというのを率いております。
今日、ちょうど少しお話できればと思っているんですけれども、
当初はDSという組織名称ではなくて、コンサルティングチームみたいな形で1年ぐらいやっていたんですけれども、
そこから1年ぐらい経って、去年の10月、正式にDSという名前でDS部長となって、
今に至るというような形になっております。
私のキャリア自体、先にDSのメンバー構成みたいなところを軽く話すと、
だいたい7割ぐらいがコンサルティングファーム出身になっています。
ただ、私のキャリアとしては、実はコンサルティングファームは一瞬いたんですけれども、
いたというと先輩方に怒られるぐらい短い期間しかコンサルタントやってなくて、
どちらかというと新卒で入った日輪のアナリスト的なところとか、もしくは金融のドメインに強い部分だったり、
もしくは前職が弁護士.comというリーガルテックの会社ベンチャーにいましたけれども、
そこで職役に対して事業戦略とプロダクト全体を見ていたりもしたので、
そちらの方がどちらかというと、私自身のケイパビリティだったりとか、キャリアとしては色が濃いような感じになっております。
本日はよろしくお願いいたします。
よろしくお願いいたします。
まさに今回は小林さんをお招きして、FDE、DSって最近すごいよく聞くと思うんですよね。
ただそういう中でも、今もコンサルというチームから変わりましたとお話ありましたが、
コンサルってどう違うんですかっていうところですとか、
FDEモデルにおけるプロダクトってどういうもので、どういう価値を持つのかですとか、
あとそれによって何が変わるのかっていうところ。
そういうのが結構曖昧なまま今先行しているなと思っておりまして、
そのあたりを日本で先行的にパランティアとかも研究されながら、
FDEモデルを実行しているレイヤーXさんを2週にわたってお招きして、実例っていうところを深掘りしていきたいと思っております。
今回はそういう中でDSの部長になる小林さんにお越しいただいて、
特にFDEとDSの役割分担ですとか、プロダクトの価値っていうところを伺っていけたらなというふうに思っております。
そういう中でなんですけど、改めてこのDSって特定ドメイン、アカウントのCPOっていう形で小林さんのノート内ではご紹介いただいてましたが、
改めてどんな役割をしているのかっていうところからお話し始めてもよろしいでしょうか。
そうですね。こちらのCPOという表現を使った、去年の10月にこの名称というか、説明を付与して名前よりブランディングしたところに大きく2つ意味があって、
1つはFDE側が特定のお客様であったりとかドメインだったりのCTO、チーフテクノロジーオフィサー側として先に打ち出していたところもあって、
そこに対となる存在としてDSがありましたので、CTOと対なるものは何かっていうところを考えたときに、
やはりいろいろ選択肢はあったんですが、私の中ではプロダクトを育てるというところにすごく強く動きを置いて、
あえて一定本当にCPOなのかみたいなところの疑問だったりとかあるかもしれないなと思ったんですけれども、
あえてそこは行々しくCPOというふうに名乗らせていただいていたりします。
FDE/DSモデルにおけるプロダクト刷新の背景と課題
ここがこういった名称になったところの背景、先ほど自己紹介のところでも軽く触れましたが、
長らくコンサルティングチームみたいな名称でやってたんですけれども、私自身短いといえコンサルタントの経験があって、
また先輩とかもしくは同級生ですね、大学とかがコンサルタントやってるのを見ていて、
我々のビジネスにおけるコンサルタントは本質的なコンサルタントではないなっていうのはずっと悩んでいました。
一つはプロダクトを前提とした支援になりますので、そうなってくるとやはりコンサルタント、
当然DSとかFDと別にコンサルタントの定義にも人によってめちゃくちゃ長らく議論がありますけれども、
私個人としていろんな先輩とか見てて思うところで言うと、やはり特定のプロダクトとかソリューションから中立で、
顧客の課題のみに向き合うプロフェッショナルっていうイメージ、顧客課題を解決するためであれば手段は正直問わないみたいな、
そういったイメージが強くて、我々の当時のコンサルタントですね、今のDSはやはりプロダクトを育てるということがやはり一義的に、
それを通して顧客の課題を解決するっていうところがあるので、どうしてもコンサルタントという名称にはずっと違和感があって、
FDの尾田さんとかもしくは中村さんですね、このポッドキャストにも出させていただきましたが、中村さんと名前どうするか会議みたいなのをずっと延々と繰り返しやっていたっていう一年ぐらいがありました。
いろいろ考えていく中で、我々やはりDSはプロジェクト、デリバリー、コンサルティングをしながらやはりどういう機能に育っていくべきか、
顧客の要望だけではなくて、そもそもこういったお客さまの課題を解決するためとか、もしくはより敷衍して、
例えば金融業界のこういった領域とか業務を解決するためには、AI枠構造はこうあらねばならぬみたいな会話が、
DS側、当時のコンサル側からも結構出ていましたし、私自身が元々そういうバックグラウンドもあったのもあって、そういうのが好きだったみたいなところもあって、
やはり基本的にはデリバリーっていうのは大前提として、コンサルティングっていうのは大前提としてあるんですけど、
例えばプロマネとか、Aziz2B分析だったりとか、そういうコンサルタントの一般的な要素としては絶対あるんですが、
その上でやはりコンサルタントは違うプロダクトを育てる部分っていうところを基本的にミッションとしても置いてますし、
そこを名称にも込めているというような、そんな感じになりますね。
おだしょー ありがとうございます。今も何度も何度もプロダクトっていうワードが出てきたので、早速このプロダクトって実際何なのっていうところをどんどん伺っていきたいなと思ってるんですけれど、
そのノートの方でも、25年の紙機にバージョン2へ刷新されたっていうような記載があったと思っていて、こういう背景からちょっとプロダクトを深掘りさせていただきたいなと思っております。
外から見てると、結構モデル進化とかAIエージェント化っていうところを見据えた先回りになった投資にも見える一方で、
結構ノートの方でもバージョン1だとUI UXの表現力の制約だったりだとか、あとDSが顧客とか業務ごとに最適な体験を作り込むっていうことに限界があったみたいなことが出発点だったのかなというふうにも読み取れまして、
このあたり実際にどのような課題意識とかが最初にあって、それを解決するためにナレッジ、スキル、ツール、UIっていう4つの構想ですって話もあったと思うんですけど、
なんでこういう構造に至ったのかっていうところも伺ってみてもよろしいでしょうか。
はい、もちろんです。もともとのバージョン1と呼ばれていたものは基本的にDiffieであったりとか、各種ローコードツールに近いようなイメージでした。
言い換えると、アルゴリズムというかワークフローですね、AIのワークフローとかもしくはエージェントを構築する部分は一定柔軟性があった。
そこでそのDSとFD、当時の名称は別でしたけども、お客様の業務に合わせてですね、ワークフローを作るとかエージェントを作るみたいな部分は十分できるものだったんですけれども、
先ほどあったように、その範囲内で我々ってデリバリーをして終わるというよりも、お客様の課題を解決するためにどうあるべきかみたいなものを考えていたときに、
やはり大きく2つですね、データの持ち方にかなりの制約があって、単発の業務だったりとかをワークフローとかエージェントで自動化するという意味ではそんなに困らないんですけれども、
結構長い業務であったりとか、もしくは蓄積するような業務ですね、デイリーでとかマンスリーで回しながら、
どんどん過去の知見みたいなものをより生かしてエージェントを作っていくみたいなところになると、データの持ち方が1種類しかなかったんですね、当時のバージョンは。
本来ちょっと違った持ち方をしたいってなったときに対応ができないみたいなところがあったりとか、あとUIUXもそうですね、本来本当にシンプルな処理を回すとかですね、
エージェントを実行するみたいなことしかできなかったんですけれども、業務に照らし合わせるとワークフローを実行するとかエージェントを実行するっていう部分というよりは、
そこを意識させない体験というか、ユーザーにおいてはもう少し、例えばナレッジをシェアするのにもうちょっと使いやすい検索画面が欲しいであったりとか、
リース業界で見積書を処理するみたいなときにレビューをする画面が正直バージョン1だと使いづらすぎて、Excelの方がものすごく便利だよねみたいなところがあったりとか、
業務に本格的に入れようとなると、いろいろ制約があってちょっと厳しいよねって話は割と初期からプロジェクトをする中で出ていたんですけれども、
当面はモデル自体がいろいろ喧嘩があったりとか、我々が対応できるワークフローとかエージェントもそんなに良くなかったのもあって、そんなに問題なかったんですけれども、
どんどんエージェントが進化していくことが特にリーズニングモデルが出てきてからは予測ができたので、相番行き詰まるだろうなこれはというところでちゃっちゃとアーキテクチャーの刷新を決めてしまったというところがありますね。
じゃあある意味その課題意識っていうところが起点にはなりつつ、モデルの進化とかを見越した先回りの投資でもあったみたいなそこの組み合わせだったんですかね。
そうですね、やはりリーズニングの出現は大きかったです。
フォー以前はLLMにやれることが制約が大きすぎて、データの持ち方とかUIをどうするかっていうところを考えてもあんまり費用材が合わないというか、アーキテクチャー刷新するほどでもなかったなって今振り返っても思うんですけれども、
やはり先々これは結構そういうことできるかもってなったときはちょっと目をつぶってた課題をなんとかせなあかんという雰囲気が一気に強まった感じはありますね。
ありがとうございます。そういう中でやっぱりプロダクトを作っていくっていう風になっていくと、このプラットフォーム戦略っていうところが結構標準化とか効率化みたいなところを指向する一方で、結構AIワークフォースさんって発信とか拝見してると、
プロダクトの中核要素とナレッジの重要性
DS個々人の創造性とか、顧客ごとの最適化も重視してるようには拝見していて、それをプロダクトに落とし込む背景思想っていうんですかね、みたいなのをもうちょい聞いてみたいんですけどいかがですか?
そうですね、全職で経営してたときと比べても思うのが、このビジネス複雑性が高すぎるなって個人的には思っていて、お客様の課題をプラットフォームで解決しますって言うと聞こえはいいんですけど、
よくある何でもできれば何でもできないじゃないですけれども、お客様ドメインとか業務にディープダイブしないと本当にチャチなものができるなという感じがあって、最初はCEOの中村さんとか私とか、もしくはCPUとかが結構全案件細かく見ていこうみたいなふうに思ってたんですけど、無理だよねそれはというふうになってきて、
わからないんですよね、個々のお客様の業務が、全然わかりませんとなってくるので、やはりそのある程度いろんな人にあなたはこの領域に任せますとか、ここの領域で一番詳しくなってくださいっていう形で任せないと、やはり事業は難しいな、回らないなというふうに思っています。
その意味で、かなり各陣にお客様の言われたことを粛々とデリバリーするだけではなくて、まずデリバリーとか案件の成功をどうしたいかっていうのも当然そうですし、またそれを普遣するとか一般化するとどういう解決策があるのかとか、AIはコースとしてどう還元すべきかみたいなものは一人一人に考えてもらわないとスケールがしないというふうに思っています。
当然先ほど須藤さんからありました通り、そうするとバラバラになりがちなので、一定そのCPU、特定領域のCPUっていう意味のDSAがなくて、全体のCPUですね。うちでいうと小橋篤さんがいますけれども、彼と私とか全体を見るメンバーで各陣から上がってくる情報であったりとかを集約しつつ、フィードバックしつつっていう形で延伸力と休止力を同時に、なかなか難しい綱引きではあるんですけれども、働かせながらやってるっていう感じですね。
このあたり山崎さん結構パランティアも研究されて、先日もオントロジーをコアとしたプロダクトの記事出されてましたけど、そういうふうにいろいろ見てる中でご質問とかありますか。
ありがとうございます。プロダクトのバージョン2の設計思想と中核となるものがないなのかなっていうのをちょっと伺いたかったんですが、ナレッジスキルツールUIっていうふうに4つの要素があるっていうふうに歌ってらっしゃったんですけど、どの辺がそのプロダクトの中核に今なってるんですか。
これは正直悩みながらっていうところは率直なところですね。去年この構想を出した時とかは、なんだかんだスキルかなっていうところは思ってたところがあったりします。我々がお客さまに入り込んで、汎用的な基盤モデルだけでは対応が難しいところをスキル、我々で言うとスキルの表現形式としてワークフローの場合もあれば、また別の形で表現することもありますけれども、
まるっと広い意味でのスキルをお客さまと一緒に入り込んで作り込んでいくっていうところにかなりの優位性というか、特に日本ローカル、グローバルのプレイヤーがやってこれないローカルでかつニッチな領域とかに関しては、その辺りに優位性っていうのはあるかなというふうには強く思っていました。
が、やはり最近基盤モデルの進化がちょっと当初の想像以上で、かなりの程度基盤モデルでできるっていうふうになってきてるかなというふうに今見ておりまして、我々としてはってなってくると、そこ自体の優位性というのはそう長くは続かないというふうに見ておりまして、どちらかというとナレッジの部分、データをどう貯めるかだったり、先ほどアーキテクチャの冊子のときにデータの表現形式が持ち方の制約があるみたいな話をしておりましたけれども、そこをどう蓄積する、
いわゆるオペレーションの設計も含めてプロダクトに正しくナレッジを蓄積していく部分であったりが、なんだかんだ一番大事になってくるのかなと思っています。それとは別に、やはりUI、UXは特に大企業において多くのユーザーの方々に使っていただくためには、それ専用のもの、専用というかお客様ごとに個別に作り込むってほどまで我々やらない、ある程度業務レベルで最適なUXっていう形になると思うんですが、他社にも横手が可能なっていう意味ですね。
そういったUXっていうのも一定強みになるかなっていうところで、おそらく時代によって変わってくるかなと思っています。もしかしたらだんだんビッグテックのプレイヤーが実はUXとかもちょちょっと簡単に作れるようになるし、UIもどんどん作れるようになったりもするんで、そうなってくると世界は変わるかもしれないですが、現状のポイントとしてはその2つかなというふうに思っていますね。
ありがとうございます。
ナレッジの観点に1つ伺いたいんですけども、最近特にUSにおける理論なんか見てると、基盤モデルがいかに進化しても、やっぱり企業の中の固有のコンテキストを理解しないと結局ちゃんと答えを返せない問題というのが、売上が先週いくらだったかって聞いてもちゃんと答えられない問題というのが言われていて、
なのでコンテキストの構造化をしていくレイヤーっていうのが非常に重要というか、そこはただ基盤モデル入れるだけじゃできないねという議論がある中で、ナレッジとおっしゃってる部分っていうのがラグ検索的なものなのか、それともいわゆるパランティアのオントロジーのように構造化をしていくところがまず最初の仕事ですというような感じなのか、レイヤーXにおいてはどんなイメージなんですか?
イメージはパランティアの方が近いかなと思っています。シンプルなラグに関しては、やはりある程度ビッグテックのツールをそのまま使えばできる世界線になってくると思いますし、逆にそれでできないところをラグだけで解決していくというのは技術的にそもそも困難であるという可能性が高いなと思っていて、ちょっと1つデータのレイヤーみたいなものをもう1つかませるというか、そこを我々として作っていくと、
それが構造化データとして持たせるというよりは非構造化データを非構造化データのまま持たせるみたいなところも含めて、いろんなデータの持ち方というかレイヤーの持ち方はあると思うんですが、やはりそこを作っていくというのが、これまでは先ほどあった通りスキルを作っていく部分でしたけれども、
従来あまりパランティアに正直似てなかったビジネスモデルではあったんですが、だんだん似ていくのかなというふうには、これは組織としての方針見解ではないですけども、私個人としては思っているところでありますね。
ありがとうございます。今のナレッジをどう扱っていくかというところって、あまり御社の発信の内容ではそんなに触れられてないのかなと思ってるんですけど、
それってあえてそこは企業秘密というか競争の厳選だからということなのか、あるいは本当にどんどん日々変わっていってるんで、カチッとはかけないっていうところなのか、どんな感じですか?
日々変わってるからの方が強いです。先ほどのスキルの優位性みたいなものが落ちてくるよねって話、我々は組織AIみたいな表現を使ってたりしますけれども、出てきたのは今年になってからだと思っています。
この半年は本当に変化が大きくて、世の中的にもそうなんですけど、我々の社内的にも結構大きな、いろんな戦略的な転換みたいなものをしているところがあります。
その中で、我々のプロダクターが追いついてきたっていうのは、構想とかやりたいことがあっても、そこにプロダクターが追いついてないとできなかったんですけれども、
ようやくいろんなデータの持ち方に耐えられるようなプロダクターにだんだんなってきて、やりたいことを目指せるようになってきたというようなところもありますし、
競争優位の源泉というかポイントみたいなものが変わってきたっていう認識も、もともとのナレッジっていうのは大事だなと思ってたんですけれども、
どちらかというと大変なので、プロダクトを用意するのも大変ですし、DSFDがデリバリーをできる舞台を用意するっていうのもやはり難易度はより上がるかなと思っているので、難しいと思っていて、
どちらかというと後回ししてたっていうところが実態かもしれないなと思っているんですけれども、やはりもうそこが避けては通れないというか、我々としてもやれることも増えてきたし、
競争上の必要性みたいのも増えてきたしっていう形で一気にガッとそっちに降っているような側面があります。
なんとなく社内で今やりたいことというか、目指している方向性とかそれに向けた実案件みたいなものは出てきていて、私も何件か今直接見ているものがありますけれども、
トークンコストとプロダクト設計、汎用化と個別最適
まだまだ実際の形としてお見せできるというか、実例を持って発信できるっていうのはこれからっていうような本当に直近の変化ですね。
ありがとうございます。もう1個聞きたいんですけど、推論能力がとても向上してきたっていうこの半年ぐらいの1つのトピックスに加えて、
最近トークンマネジメント、福島さんからも記事出されてましたけど、すごく話題になってきているなと思っていて、
結局トークン原価が一定かかり続けると、どんだけ売り上げが増えてもあらりの増え方も一緒というか、
あるいは、むしろ原価が上がっていってしまうと、どれだけ売り上げ成長率が速くてもあらりの成長率は速くないというような状況が起きてしまうので、
トークン原価コントロールっていうのがすごく一種になってきているなと思っているんですけど、
その観点でいうと、エージェントだけを使うんじゃなくて、ワークフローとかツールとかいろいろ組み合わせたりとかも、
エージェントにツールを生成させるとか、そういう組み合わせがパランティアのビジネスモデルを見ているとすごくそれが秀逸だなというか、
毎市販機営業利益率が上がっていっているのが多分そういうところもあるのかなと感じているんですけど、
でもそのプロダクト設計において、トークンマネジメントということとプロダクト設計ということと、
両方の視点が最近出てきているんじゃないかなと思うんですけど、
リアXさんの中ではどういう議論されているんですか?
もうめちゃくちゃやっぱり出ますね、その話は。
単純に我々自身がコーディングエンジンとかめちゃくちゃ使いまくってたりもするので、
お金が大変なことになったりもするので、そこをカットするっていう中の効率性の向上もそうですし、
やはりお客様に対して事業初期とか昨年までに比べて、
より複雑な、いけるとよりお金がかかるユースケースというのが如実に増えてきています。
そうなってくると、それをそのまま、我々の場合はある意味、
原価をそのまま転化してお客様に請求するということもできなくはないですけど、選択肢としては。
それをやってしまうと高すぎて使えないっていうところが容易に想像できる世界だなと思っていて、
実際スケールしていろんな方に使っていただくためには、
もう全部クロードでいいじゃんっていう話が出たりとかして、
クロードコードとかそのまま使うのに比べて同じぐらいの金額だったりとかだと、
相番行き詰まるというか、エージェントは普及しない世の中になってくると思うので、
なるべく無駄な処理を減らすであったりとか、
探索、さっきのナレッジの部分ここにもかかってくると思うんですけれども、
ある程度きれいにナレッジを持っていくことによって、
探索の範囲を減らすことによってコストをカットするという側面もあるので、
そのあたりで我々が、変な言い方ですけど、
安く使えますよというか、エージェントをそのまま使うのはコスト的に無理なので、
我々がそこをコスト最適化もしますし、業務に満足度とか、
品質、精度っていう意味でも最適化しますっていう形で、
安くいいものを使っていただくためのプラットフォームっていう側面は、
今後どんどん迫ってくるかなというふうには思っています。
ありがとうございます。
プロダクト周りで最後に1点だけ私からもお伺いしたいんですけれど、
ちょっと分かりやすく、例えばリースソリューションみたいなところを例に挙げながら、
最初の一緒に向けて作った機能群の中で、
どれが他社も使える、ある種の範囲を生かせてプロダクトとして残るのか、
どれが個別実装として残るのかみたいな、
その分岐を最後に伺った上で、組織の話を聞きたいんですけれど、
このあたりっていかがですか?
2つありまして、リースは結構奇跡的なソリューションでして、
ほぼ最初の一社に提供したものが、他社にもそのまま使えるというような状況だったので、
範囲の部分と個別部分っていうのはほぼなかったですね、そこに関しては。
それはあれですか、リースの業務っていうところが結構、
全てが共通しているところがどの会社さんでも多かったってことですかね?
そうですね。リースは伝統的なリース業務と、航空機であったりとかプロジェクトファイナンスだったりとか、
最近強化している非伝統的といいますか、新しい領域があるんですけれども、
伝統的なところに関してはかなりの程度、これはリース業界の特徴で、
後で知ったんですけれども、共通部分はめちゃくちゃ多いなと思っていました。
なのでその部分はそのまま、もうほぼこういったリリースというか、
出したらもううちも欲しいって言ってくださるお客様がわらわらというと、
表現が良くないですけれども、出てきたのでそのまま使えたパターンですね。
もう1個が、やはり大半の業務はそうではないので、
もともとのご質問にあった通り、そこの区分けっていうのは出てきます。
我々で言うと、ストファイの領域、ストラクチャーとファイナンスだったりとか、
そういった領域はソリューションとして、やはり個社特化部分と、
そうではない汎用的な部分というのが分かれます。
最初の1つ目の案件というか、最初のお客様とやっているときに、
案件期間中に、例えば他社さんとかにある程度需要調査といいますか、
汎用性がどこまであるのかの調査は基本的にやっています。
その中で、おそらくここは汎用的であろうと、ここは個社特化であろうというところを、
当然、お客様の機密情報とか話せない中やるので、
ある程度の精度にしかならないんですが、当たりをつけておいて、
いける部分といけない部分で、ある程度だいたいざっくり、
汎用部分とそうじゃない部分を切り分けで作っていくようなイメージになります。
ただそうは言っても、1社目時間もない中でドガッと作っていくので、
ある程度汎用性は犠牲にしながら作っていって、
ただ2社目以降というか、先にこの辺りは後で回収しなきゃとか、
汎用化しないといけないよねっていうところを、
1件目をやる中で当たりをつけていって、
1件目が終わった後の段階で、ある意味積み残したタスクとして、
汎用化開発みたいなものを後からやっていくみたいな、
そんなイメージになってますね。
面白いですね。
結構、業界のヒアリングなんです。
お客様じゃないところに対しても、そこを伺った上で、
そのプロダクト作りに生かされてるってことですよね。
そうですね。
ただ基本的にはやはり本気で商談しに行かないと、
DS部の組織体制と役割分担、KPI
いいフィードバックというか、いいですねこれはって言って終わってしまうので、
実際にオンシャンに導入するんだったら、
やっぱりどの辺が気になりますかみたいなところは、
割と売りに行って確認しに行くようなところはありますね。
ありがとうございます。
話題を組織の方に移していきたいなと思っておりまして、
先ほどDSの役割分担みたいな、
前者のCPUと各DSがどういうふうに役割分担してるのかっていうのを、
ちょっと触れさせていただいたんですけれど、
改めてそこに深掘りさせていただいて、
DS部内にも特定の業界アカウントごとに、
ソリューション責任者っていう方を置かれている、
というような記載も拝見しまして、
実際、具体例とかを交えながら、
どういった意思決定の権限まで持たれているのかとか、
そういったDSの方の評価基準って、
実際どんな感じなんだろうっていうのも、
伺える範囲で伺ってみたいんですが、
この辺りいかがですか。
権限で言うと、予算とか人事みたいなところまでは、
ソリューション責任者のDSには持たせてないです。
特定の領域、あなたはここは任せますので、
どういった顧客をターゲットにしますかだったりとか、
そこにどういうふうに売りに行きますか、
必要な機能は何ですかみたいな、
結構営業のGTMみたいな部分と、
開発方針だったりとか、
そういったところを任せるようなイメージですね。
繰り返しになりますけれども、
一つ一つのドメインに関して、
我々で全体の戦略とか経営レイヤーが見切るのは、
難しかったりもするので、
ある程度、というかかなりの程度ですね、
各自に裁量を渡して、
勝手に営業してきてもいいし、
勝手にこういうものが必要だという企画も挙げてきていいしで、
最後にそこにリソースを張るかどうかというところの決定は、
経営だったりとか、
全体のCPUとか私がやるんですけれども、
それ以外のところは結構、
好き勝手にこう言って、
そんなざっくりしたバーチャルな概念ですね。
そうなってくると、
FDEの方とDSの方が、
プロジェクトを取った後に、
どういう役割分担になるのかですとか、
あと、GoToMarketのところも、
アカウントエグゼクティブの方も、
別で部署でいらっしゃると思うので、
そのあたりの住み分けって、
今どうなってるのかみたいな話とか、
もし今後、実はこうしてきたんだよね、
みたいなところもあれば、
伺ってみたいんですけれど、いかがですか?
ここは結構ハジーなところもあるんですが、
DSとFDは、
なんだかんだ同じペアで動くパターンが最近多いです。
そのDSとFDも特定のドメインに、
詳しくなってほしいっていう、
我々側の意図もあったりはするので、
例えばリースだったら、
リースはこのDSとFDのペアでよろしく。
AEも基本的にそこにつきますね。
AE、DS、FDで、
特定の業界、
これは業界なのかソリューションなのか、
カットの仕方はいくつかあるんですが、
丸っと渡して動いてもらうみたいな感じです。
最初のGTMというか、
提案活動の段階から、
DSもそうですし、FDも入っていくようなイメージで、
AE、DS、FDでセットで、
この業界とか、
このソリューションを、
より広げていくためにはどうすればいいかっていうのを、
その3人で一緒に考えてもらうみたいなイメージですね、
戦略から。
その後は実際にプロジェクトが始まれば、
なんとなくこのDSのほうが、
今でいうと、その要件定義だったりとか、
プロジェクトの設計、プロマネみたいなところをやって、
FDが実装みたいな形にはなっています。
もし、
伺えたらなんですけれど、
それぞれの方が持っているKPIとかって、
どんな感じなんですか、お三方。
これは結構迷っているところなんですが、
ビジネスサイドはシンプルです。
もう営業に関しては、
もちろんARLですね、
プロダクトビジネスとしてARLを伸ばしていく、
っていうようなところになっています。
DSのKPIをどうするかっていうのは、
結構悩んだんですけれども、
現状はARLは直接的には追ってなくて、
プロフェッショナルサービスの売り上げになっています。
なので、
リースだったらそのリースの領域から、
いくらのコンサルティングフィーをいただけるか、
というようなところですね。
FDに関しては、
本来的なそのFDといいますか、
似ていらっしゃいませると、
売り上げを追うっていう選択肢もあったんですが、
今はそういった評価ではなくて、
どちらかというとソフトウェアエンジニアに近いような
評価基準になっていますね。
なので、これは今すごい過渡期です。
これが正しいかどうかっていうのは、
あまり分かってないんですが、
ちょっと試行錯誤しながらっていうところでありますね。
なるほど。ありがとうございます。
コンサル思考からプロダクト思考への転換
あと、伺ってみたかったのが、
DSの方ってコンサルティング会社出身者が多い
っていう話も冒頭にあったと思いまして、
私自身もコンサル出身だったりするんですけれども、
結構もうお客様に個別最適で、
どういうふうにニーズに応えていくかっていうのを
日々考えていたなと思っていて、
それとやっぱりプロダクトを
作ってくって、より汎用的な
施行、プロダクトマネジメントの
施行って結構相反するだろうなって
思ったりするんですけれど、
そのあたりの真逆の施行を
戦略観点どういうふうに考えているのかとか、
その考え方をDS入られた方
一人一人にどういうふうにオンボードさせているのか
みたいに伺ってみたいので、このあたりいかがですか?
これは結構一人一人のDSが
結構悩んでいる、FDもそうですかね。
結構悩んでいるポイントかなと思っています。
組織としてやっていることとしては、
基本的に私とか
小林篤さんですね、CPUとかに
日々この案件をやるために
こういう機能が必要であるとか
こういう開発しなきゃいけないって
言われたときに本当にそれは必要なのかとか
それが他社に売れるのかとか
本当にAIワークフォースのプロダクトとしての
成長になるのかっていうのをひたすら問われる
みたいな形で
一般的な汎用的な
教育メニューとかインプットしていくっていうよりは
案件を通して
詰められるわけじゃないですけれども
ひたすらそういう形で
インプットしていくっていう
のが結果的に一番早いかなと思っています。
なので
私も小林篤さんも
一個一個の案件には
直接はなるべく入らないようにはしているんですけれども
個別のDSとかFDとかと
そういった議論をする時間自体は
かなり長いですね。
その中で全体の
考え方とかプロダクトロードマップだったり
さっきの我々の競争優位性
みたいなところに照らし合わせて
この機能って今開発する必要あるのかとか
これなくても本来こういう別のアプローチがあるんじゃないかとか
ひたすらそういう会話を
続けるっていう形です。ある意味
SaaSのプロダクトマネジメントに近い発想
かなとは思っています。
そこはある種コンサル出身者だから
個別最適にとか元々強みとして持たれてる
ところをある種OJT的に
日々やり取りしながら鍛錬されてる
ってことなんですかね。
なかなか大変だと思います。お客様のためにどうしても
この機能が欲しいって思いはそれぞれある中で
それいるのみたいなことを
私とかに言われて
それに対して説得力のある反論が返ってこないと
お客様に対して謝る判明になる
というような
ある意味お客様のためにも我々
打ち負かすロジックを組んでもらうというか
それだけ真剣にお客様のために
立ち上げたって考えればきっと何かいいアイディアが
生まれるだろうということで
厳しく言ってるような感じですね。
ありがとうございます。そしたら最後の
AIワークフォース事業部のGTM戦略と注力セクター
セクションとしてAIワークフォース事業部の
GTMっていうところもまた
伺ってみたいんですけれど
1点目として究極すべての
顧客システムっていうところを
AIXさんとしては手掛けることを目指されているのか
または戦略ステップとして
何か明確に定めて
Go to Marketされているのかとか
その後のGo to Market 戦略って今どんなふうに
お考えですか?
全てというのが
ユースケースだったり業界みたいな意味だと
次第にやっていきたいな
と思ってるんですけれども
例えばCRM自体をやるのかとか
ERPを究極やるのかみたいな
世界性になってくると
さすがにそこはやらないかなっていうふうには
言い切れると思っています
工藤さんのシエラの記事にもありましたが
既存のシステムは
特に我々大企業のお客様なので
早々簡単に変えていくっていうのは
難しい現状もあるので
既存のシステムを残したまま
そこをよりうまく活用していくというか
データをどううまく生かしていくような
データ例を作るみたいなところも含めて
基本的には共存していく方針を
取ってるかなと思っています
そこに
競争の軸みたいなものも変わってくると思いますし
今後全部の領域を
我々が直接やるというよりは
パートナーシップだったりとかも含めて
我々やるべき領域っていうのは
端的に絞っていく形になるのかなというふうには
思っていますね
そういう中で特に
注力してるセクターとか業務
ドメインみたいなものって存在するのか
いなかっていう観点でいくといかがですか
セクターっていう意味では
今足元一番なんだかんだで
注力してるのは金融であることは間違いない
これはもう
グローバルの動向を見ていても
金融が本当に
AIエージェントの一挙目一番地というか
競争領域になってるのもありますし
また我々のバックランドですね
会社としてとかもしくは私個人とか
DSのメンバーのバックランド的に
金融にもともと強いっていう
ところも含めて
やはり市場の大きさもしくは先進的なことを
やっていくお客様の
そういった姿勢だったり
我々の得意不得意っていうところで
金融っていうのは今後も軸になり続けるのは
絶対間違いないと思っています
その上で我々としての課題というか
次にやるべきこととしては
金融以外でどう広げていくかっていうような
ところになりますけれども
そこはですねやはり日本である以上は製造業というのは
避けては絶対通れない領域であると思いますし
特に製造業も広いんで
ステップバイステップで特に自動車
みたいなところからだんだんいくのかなと思ってるんですが
製造業に入りつつ
あと最近で言うとコンサルティングファームさんとか
SIさんとかは一気にこう
DSFDを歌ってたりとかも
するところもありますが
我々が狙っていきたいところであったりとか
あと公共ですね
これは経営人の思いも強いっていうところもあって
この辺りはですね重点領域として最初にやって
いっている領域になるかなというふうに思っています
ありがとうございます
このFDAモデルの
FDEモデルの高いNRRと先行投資の本質
肝というか
特にそのパランティアの決算なんか見てると
そのNRR
既存顧客売上げの成長が
著しくてかつ利益率も
ものすごく高くて
やっぱりそういうビジネスモデルという
ある種ゴールの形があった中に
合わせにいくって
経営の観点で言うとあるんだろうなと思ってるんですけど
その既存顧客のバジェットが
広がるところの
基本的な戦略の組み立て方で
深さと広さがあるなと思ってるんです
重量課金とか成果報酬型みたいに
どんどん深さが
同じ部門同じ業務の
売上げが積み上がっていく
パターンと
部門とか業務で
横展開していくパターンと立体で
どういうふうに伸ばしていくのが
今のところのエクスパンドの戦略なんですか
今は完全に
重量だと思っています
これまでに関して
去年までの方に関しては
ユーザーとか部門なるべく多くの方に使っていただくための
それこそUXだったりも含めて
やっていくっていうのが
去年までの正解って言うとあれですけども
やりやすかった側面ではあるなと
それは重量ですごくそれと言うと
稼げる未来がそんなに見えてなかった
というところですね
基本的にそのLLのコストは安くなっていきますし
またエージェントにできる範囲っていうのも
限界がある中で
そこですごく大きな
トークンでの売上げが立つような
ちょっと具体的な未来っていうのは正直描けなかった
のが去年までかなと思っています
ただ今年はやっぱり
逆に高すぎるみたいな話に
どんどんなってくるので
その領域をいかに我々が取れるかっていうところの
勝負で明らかにパラダイムは
変わっているかなと思っています
本当にこの半年で
イシューがガラッと変わったな
と思うんですが
深さを取りにいく戦略を
考えた時のどういうドメインを
狙っていくかというところで
フロント、ミドルオフィス、バックオフィスって
ざっくり金融で分けると
あるんですけれども
どのあたりが中力領域
競争領域というかだなと思ってらっしゃるんですか
フロントかなと思いますね
やはり
基本的にはミドルバックというのは
いかに語弊を恐れずに言うと
コストを安くかつ
オペレーション崩壊させずにやっていくかという
世界線だと思っているので
最初に入る分にはこのあたりからかなと思っているんですが
ここはやはり安く
なるべく多くの方に満足度を得ていただくと
そこからやはり
アップサイドを狙っていくのであれば
むしろ売り上げを上げていく
お客様の売り上げを上げて我々も
その分成功報酬
成果報酬型ではないですけれども
そこから追加で
いただいていくという形を目指さないと
厳しいかなというふうに思いますね
ありがとうございます
FDEモデルとこれまでのコンサルティングファームとの
違いの見方というのが
いくつか観点があるなと思っている
ですが
一つの観点として
やはり何かに投資をして
先行投資をしているということが
あるんだろうなと思って
コンサルティングファームとの違いって
AIワークフォース事業部で見たときに
PLの観点でも結構なんですけど
ある意味どこで赤字を掘っているのか
というところがお話しできる
ところまで
明確にプロダクトだと思っています
やはりいくつ
ありますね
プロダクトに投資をすることで後で回収できると思っている
点として一つは
より複雑な先ほどのトークンの
より大きなものを
取っていくにせよ
何か大きな難しいことをやるとなると
プロダクト側がプロジェクト機関地に
作っていくだけでは絶対足りないので
プラットフォームのほうですね
DSとかFDEがタッチするところではなく
プラットフォーム側で
相当強いものがない限りは
プロジェクト機関地にやれることって限られるので
そこは時間も1年も2年もかけて
しっかりと投資をしきらないと
売上がまず伸びていかないなというふうに
思っています
さらにもう一点で言うとプロジェクトのデリバリー期間も
プラットフォームが進化すればするほど
明らかに早くなります
そのプラットフォームで
DSFDの醍醐味でもあるんですけれども
やりながら必要なものを探索しながら
何だってやっていくってなると
時間もかかりますし
そこから必要なものを開発するってなったら
またそこも時間かかりますし
そこのプロジェクトのコントロールしなきゃいけない
変数が増える一方なので
難易度も上がれば時間もかかるんですけれども
そのあたりが特定のソリューションとかで
最初の案件2案件目とかで
先んじて投資的にやっておけば
やはり3案件目4案件目っていうのは
基本的に回収ができるので
お客様に与えるタイムツースピードも
圧倒的に短くなるので満足度も高いし
我々としても低コストで
十分なフィーをいただけるっていう形になるので
デリバリーって観点でも
やはりプロダクトっていうのは圧倒的に大事
これはある意味コンサルティングファームとも
違いかなと思っていて
あとはより人数が増えていったときに
やはりよりプロダクトが進化してくると
難易度が下がってくるので
より多くのメンバーで対応できるようになる
っていう意味でもスケーラビリティって観点でも
プロダクトの投資が後々かなり効いてくるな
というふうに思ってるので
最初かなり掘ってるっていうのが今実態ですね
ありがとうございます
DS部長としての現在の注力事項
今DSFDという前線部隊と
デブチームでいうと
ヘッドカウントの割合をざっくり言うと
だいたい何体なんですか
DSとFDがだいたい同じ
FDの方がちょっと多いですね
DSFDは1対1.5ぐらいで
SWEとかが
PDMとかQAとか諸々含めると
DSFD差した人数よりも多いはずですね
なのでプロダクトへの投資は
結構している感じになってます
ありがとうございます
最後になりますが
今ずっとお話を伺ってきましたが
小林さんが今DGS部長として
一番関心があったりリソースを
割かれてることって何なのかなっていうのを
伺って締めさせていただきたいと思うんですが
いかがですか
私は最近はその
DGSのFDも頼れるメンバーがかなり増えてきたので
一つ一つの
お客様だったりとか案件とかを
かなりいろんな人に任せています
今日中盤から
後半にかけて度々話に出てきた
競争環境の変化であったりとか
プロダクトが
肝となるポイントみたいなものが
随分変わってきたのもあって
私自身は今CPUの小林さんと一緒に
かなりプロダクトをどう作っていくか
っていうところにフォーカスを当てています
このプロダクトの製品自体が
需要とかもしくは
DSFDのプロサービスですね
クオリティにも大きく影響してくるところもあるので
この1年は本当にプロダクトを
どう育てられるかっていうところが
今後の我々の事業の
製品を握ってくるかなと思っているので
みんなに頼れるみんなに任せつつ
私はあれこれ
戦略を考えプロダクトを考え
っていうところに時間を使わせていただいている
というところですね
今年いっぱい開けて来年とかに
もう少しいろんな情報が出せるようになってきたら
AIワークコースの進化に
皆さんも楽しみにしていただけると
すごくありがたいなというふうに思っております
ありがとうございます
今日お話伺ってて
いかにプロダクトが大事なのかっていう
このモデルにおいてっていうところを
すごいひしひしと感じたので
今後も楽しみにさせていただきたいと思います
本日はレイアX AIワークコース事業部
DS部長の小林隆之さんを
お招きしてお届けしました
小林さんありがとうございました
ありがとうございました
これからもプロダクトAIトークでは
プロダクト事業づくりに取り組む経営層の方を
ゲストにお招きし
AI時代のプロダクト戦略を深掘りしていきます
毎週金曜日に配信中です
ぜひ番組フォローの上ご視聴ください
