今後、AXのFDE部隊もどんどん拡大していくと思うんですよね。
3200人って拡大していくときに、何が一番リスクになりそうだとか、リスクを防ぐためにこういったところを今から仕組み作りしているよみたいなところがあれば、ぜひこのFDEモデルのスケーラビリティみたいな観点で伺ってみたいんですけれど、いかがでしょうか。
今の話にもあった通り、やっぱりFDEっていうのはかなり外面的なものというか、そこで通常のエンジニアとの差分を測っているみたいなものがあるので、課題に対する考え方だったりアプローチの仕方だったりみたいなものがついてまとっているようなロールなんですね。
なので、昨今ビジネス的な話というか、ROIというかが結構取り雑されたり、あとは耳障りの良さみたいな、ある種何でもできるエンジニアみたいなところで、みんなFDEって言ってるような嫌いがあるような気もするんですけれども、やっぱりそれが我々そこを踏み外しちゃいけないと思っていて、FDEがそもそもなんでFDEっていうラベルをつけなきゃいけなかったのかみたいなところですね。
手の思考回路だったり価値観だったり、そういったものが定着ちゃんとするように、組織大きくなるとやっぱりそういうのって薄れていくのが常だと思うので、そこを外さないようにっていうのはどうしたらいいのかというところをかなり強く意識してエネブラをしております。
ありがとうございます。次のテーマに移らせていただいて、実際に今FDEの概念というか哲学みたいなところを伺っていた中ですが、実際他の部署とどういうふうに役割分担しているのかとか、日々どんなふうに動かれているのかっていうのも伺ってみたいんですけれど、実際AIワークフォース事業部だと、AEアカウントエグゼクティブですとか、
先日小林さんが部長に狙われているデプロイメントストラテジストおよびCSという領域ですとか、プロダクト開発の方もいらして、FDEの方もいらっしゃるみたいな形で分かれていると思うんですけれど、例えばお客様のプロジェクトに当たっている中で、FDEはどういう役割を担っているのかとか、それを実際プラットフォーム、プロダクトに落とし込むときにFDEとしてはどういった視差出しというか役割を担うのかみたいなところって、実際どんな感じなんですか。
そうですね、実際のものとしてはやっぱりAIワークフォースのプラットフォームを使ってサポートするというものではあるので、実際具体的に個別案件に入ってですね、各FDEが様々な課題を解いていって、その中でプラットフォームに必要そうなものっていうのは作っているからこそ分かるというか、作っていることで解像度かなり高い状態で分かる。
何ならここまでは他の案件でも使えるような話で、ここから先はこの個別プロジェクトの話ですみたいなところはやっぱり手を動かしているとしっかり分かるんですね。
なのでそこで、これは他の案件でも使えそうだ、プラットフォームの話だっていう、もしくはニーズがありそうみたいなところですね。
これを開発チームというかプロダクトチームとすり合わせまして、そこで多くの場合はプロダクトチーム開発チームがそこから主導していく。場合によってはFDEが実際にコーディングしたりとか手を動かして実装に結びつけるようなこともあります。
これ実際先日小林さんにお話を伺ったときに、結構FDEとDSも2個一みたいな形で動いて、ある種ここはプロダクト化すべきだみたいなのをAIワークフォース事業部のCEO中村さんだったりとかにプレゼンするんですみたいなお話を伺ったりもしたんですけれど、ここは結構DSとFDEは明確な役割分担で結構協業しているような感じなんですか。
FDEとDSの組み方とか役割分担みたいなのを改めて伺ってみたいんですがいかがでしょう。
そうですね。FDEとDS自体かなり被る部分あると思ってまして、なので明確にここがLINEでFDEですDSですよりはかなりの部分ざっくり半分ぐらいは被っていて、その中で両方とも課題に対してっていうところは同じなので、そこで見えてきたものですね。
両名が認識しているものっていうのはかなり高い確率で、少なくともその案件においては課題であるし、そこで見えてきてプラットフォームの話なんじゃないみたいな、落とした方がいいんじゃないかっていう話があれば、それも結構高い確率でそういう話なので、そこである程度解像度を上げたりとか、いわゆる一時フィルターみたいなものですね。プロダクトに落とし込んでいくといった形になります。
ありがとうございます。
パランティアでFDEが最初にやることって、オントロジーを構築するっていうことなのかなと思ってるんですけど、結構そこが全ての起点になるような捉え方をしていて、まずその認識ってあってます?
半分合ってるという言い方になるのかなと思っていて、実際問題を具体的に作るというか、手を動かし始めるのはオントロジー、いわゆるデータをどうやって再構築というか蓄積というかまとめ上げるかっていうところに頭を使うんですけれども、あとはDSと話して、そもそも何ができるんだみたいなところが一番の最初のエントリーポイントですね。
そもそもパランティアの場合だとFoundryというプラットフォームを使って何が提供できるんだろうか、提供に値するものは何なんだろうかということを話すというか考えるというか、そこも入っているので、オントロジーも作るし、そういった部分っていうのも最初にかなり頭を悩ませるポイントであります。
ありがとうございます。僕も先ほど挙げた記事の中でAirbusの件を引用しているんですけれども、本当に製造のプロセスバリューチェーンがものすごく長くて、いろんな系列会社があってバロッパラになったデータを統合していき、ボトルネックを30%かな、解消してインパクトを出すみたいなですね。
本当にアベンジャーズみたいな話だなと思うんですけれども、まずパランティアにおけるFDEのバックグラウンドってじゃあ何なのかなって思ったときに、結構USのB2Bテックってセールスフォースがそうだったり、もともとオーラクル系のDB扱ってた人たちから始まり、
昨今のAIネイティブのファウンダーはセールスフォースとか、あとデータの観点だとSnowflakeとかDatabricksがあったり、あるいは機関システム系エンタープライズ向けのソフトウェアだとWorkdayとかサービスなどがあったりして、そこ出身のバックグラウンドのエンジニアだったらエンタープライズのいろんなデータの取扱いとか分かっている方多分たくさんいるんだろうなと思うんですけど、パランティアにいらっしゃるFDEのバックグラウンドってそういう人が多いんですか?
データに強いのは間違いないんですけれども、実際どこに例えば勤めていたかとか、どういったキャリアかっていうのはかなりまちまちな気はしますね。
それこそ新卒でもFDEで取りますし、逆にキャリアがあるからといって、例えばエンジニアとしてキャリアを積んできたけどもDSをやるみたいなケースもあるので、そこは逆もしっかりエンジニアでは厳密にないんだけどもFDEになるみたいなこともあったはずなので、結構バラバラですね。
ありがとうございます。本当にB2Bのエンタープライズソフトウェアにフィットするバックグラウンドの人材って日本に多分ほとんどいないんじゃないかなと思う中で、どういうふうに皆さんそのFDEの組織を日本で作っていくかだし、
この間中村さんも我々のイベントに出ておっしゃっていただいたんですけど、やっぱり取り合いじゃなくてみんなで育成していかないとねっておっしゃってて、まさにそうだなと思うんですが、じゃあFDEに共通して必要な要件を抽象化していくつか挙げるとおじさんから見るとどういうポイントだと思いますか?
そうですね。課題をまずは定義する能力みたいなのは必要ですね。というのは、お客様がもちろんこれ困ってますって来るんですけれども、お話を当然伺うんですけれども、やっぱり第三者として関与することで見える別の切り口というか角度というかはあるので、そうなった時にはじゃあお客様こう言ってるけれども、それだけが課題なのだろうかというか。
直接的にそれだけではなくて、実はAという要素に対してBもCもありましたみたいな。そこをガサッと持っていかないと結局Aだけ解決しても解決できないので終わっちゃうというか、ポイントでの解決で終わってしまうみたいなことになって、根本的に変わってないということになるので、そういった意味での課題の定義力というか見つける力というか。
あとは論理的思考というのもかなり重要ですね。FDEのEがエンジニアではありますけれども、やっぱりそうでない部分、人とのコミュニケーションもそうですし、お客様の業務に向けなので、そういったものをコンポーネントを組み合わせて何ができるのだろうかというのは、やっぱり論理的思考能力というのは必要なので、そこはかなり強く見ています。
なんかそう考えるとあれですね、本当に戦略コーサルタントが求められるような能力が結構要素として強いんですね。
そうですね、重複する部分は多分あると思います。
ありがとうございます。