AI・LLM事業部の紹介
皆さん、こんにちは。LayerXの篠塚です。
では、LayerX NOW!を始めていきたいと思います。
LayerX NOW!は、組織・文化・プロダクトの セキュララな話をつないでいく番組です。
今回は、AI・LLM事業部のエンジニア組織について 伺っていきたいと思います。
まず最初は、私の自己紹介させていただければと思いますが、
今日ファシリテーターを務めさせていただきます篠塚と申します。
現在、AI・LLM事業部でエンジニアリングマネジャーを 務めております。本日はよろしくお願いします。
さて、今日はAI・LLM事業部の エンジニア組織に長らくご活躍いただいている
ゆでたまごさん、おすけさんといった 2名にお越しいただいておりますので、
その2人に、AI・LLM事業部の働く魅力であったり、 こんな組織だよといったところを
紹介いただければと思っております。
ゆでたまごの経歴
それでは、まずゆでたまごさんから 自己紹介をお願いいただければと思っています。
ゆでたまごさんはいつも言って ゆでさんと呼ばせていただきますけど、
ゆでさん、かなりLayerX歴に長いと思いますけど、
どんなきっかけでLayerXに ジョインされたんでしょうか。
ゆでたまごと申します。よろしくお願いします。
とも、もう5年以上前なんですけれども、
LayerXが創業してから1か月目ぐらいに ジョインしました。
当時は、もともとブロックチェーンを やっていたんですけれども、
当時はLayerXがやっていた勉強会へ登壇して、
そこで話したことがきっかけで 導入させました。
ブロックチェーンがピボットした後は、
しばらくFintech事業部でも 開発をしているんですけれども、
早く1年前ぐらいにこちらのAL事業部に 移動してきて、今になっております。
ブロックチェーンの時代に入られて、 そしてFintechをやられて、
現在、AL事業部にいらっしゃるということで、
すべての事業部をコンプリートされた 方といったところですかね。
僕らからだけやってないんですよね。
なるほど。かなり役割を変遷しながら、
今もご活躍いただいているといったところで、
現在のALM事業部においては、
どういったことをやられているのでしょうか。
そうですね。AL事業部では主に ブロック開発周りを全般的にやっています。
フロントエンドとバックエンド、 どちらもやっていて、
大きめの機能開発もやっているし、
最近だとリバクタリングとか 改善系とかもやっています。
今日の収録が9月24日で、いわゆる シルバーウィーク明けなんですけれども、
ゆでさん、シルバーウィーク10連休を取られて、
その今日連休明けで、
最近お仕事されていたか、
思い出すところからかもしれないですけど、
ありがとうございます。
では次に大助さんについて、
自己紹介いただければと思っております。
同じようにLayerXにジョインしたきっかけだったり、
いつ頃からジョインされたのか、
そのところからお聞きできればと思います。
よろしくお願いします。
本名は須藤大助。
LayerXでは大助と呼ばれています。
よろしくお願いします。
自分もゆでさんと同じで、
6年前ですかね、
LayerXの創業期のブロックチェーンからやっています。
結構元々は個人でブロックチェーン分野を 持っていたんですけども、
その会社に入って、
より大きなことが挑戦したくて、
LayerXにジョインしました。
LayerXに入ってからだと、
創業期から技術ドリブンで、
今後重要になりそうな次世代技術の 研究開発をしてきて、
ブロックチェーンから始まって、
暗号技術周りのゼロ知識証明とか、
サーブプライバシーとか、
関連のプライバシー保護技術をやりながら、
そういったゼロイチのバットを振ってきて、
ピボッとしながら、
現在LLMという技術のターンが来ていて、
AI LLM事業部で、
Ai Workforceのプロダクト開発を 進めているという形になっています。
Ai Workforceの開発
よろしくお願いします。
よろしくお願いします。
大輔さんもブロックチェーンの頃から入られて、
その後プライバシーテック、
今、生成AI、AI LLMに関わっているといったところで、
それぞれの時代の思い出とか、
大変だったところと、
今の生成AIと比較して、
今の生成AIってどういうふうに見られています?
大輔さんとしては。
もともとブロックチェーンだったんですけど、
ブロックチェーンだと、
ブロックチェーンという技術を使って、
社会に貢献できるんだろうとか、
どう使われるんだろうみたいな問題が、
まず一番最初にあがっていたんですけど、
LLMっていうのは、
明らかにデモもしやすいですし、
インプット入れたら、
このようにアップデートが出てきますし、
デモとしても華やかだし、
使われ方としてもかなり想像できるし、
いろんなユースケースがあるなというところは、
結構、正直技術の差として感じるかなと思っています。
ありがとうございます。
結構、ほすけさんと最初の頃お話ししてて、
プライバシーテック時代は、
世の中になかなか情報が出ていなくて、
基本的に論文誌かデータソースがなかったみたいな、
そういったお話を聞いていて、
それに比べると生成AIはすごい扱いやすいです、
といったような印象に覚えています。
そうですね。
一時的にソースをわざわざ深掘って探しに行かないと、
情報にたどり着けないみたいなところが、
すごいやっぱり技術分野として結構ニッチだったというのが、
結構でかいところかなと思うんですけども、
LLMはそれに比べたらすごいやりやすいというか、
いろんなところにいろんな方が情報を発信されているし、
我々も取り組みやすい環境になってきているのかなと思っています。
世の中の情報を公開してくれている人にも感謝ですね。
現在、おつけさんAI LLM事業部で
招われている役割についてお話をお願いします。
そうですね。自分もゆでやさんと同じで、
結構プロダクト開発全般という形で、
フロントとバックエンドとインフラ側、
それぞれやるという形なんですけど、
結構大きな機能開発とかを先陣切ってやることが
多いのかなと思っておりまして、
やっぱり大きな機能というのは不確実性が高いので、
PDMの方とかと連携しつつ、
お客様にデリバリーするタイミングよりも
かなり前倒ししながら進めたりとかして、
開発を進めているという状況になっております。
そうですね。プロダクトを、
本当に例明記というか、今ゼロイチのタイミングで
かなり大きいものを作っていかなければいけなくて、
結構過去の経験からこれ1ヶ月ぐらいかかるかなといったものを
結構おつけさんだと3日ぐらいで仕上げてくれたりして、
本当にいつも頼りになっている存在だなと思っております。
そんなAI LLM事業部なんですけれども、
現在のエンジニア組織の現状について、
チームの規模感であったり、どういったチームなのか
おつけさんからちょっとご説明いただけますでしょうか。
はい。チームで言いますと、
チームというか結構役割で言いますと、
一つの目の役割っていうのは結構、
プロンプトを改善したりとか、LLMにインペットする前の
前処理のリズムを改善したりとかっていうする役割があるチームと、
あとは自分が主に担当している
Ai Workforceというプロダクトの
機能開発をするチームがあるかなと思います。
後者に関しては結構LLMに直接関係することと、
しないこと両方含めてプロダクトとしての体験を
よくするというチームになっていて、
エンジニア組織で言うとそれぞれ合計して
10人いるかいないかとか、そのぐらいの
割とまだまだ小さなチームの規模感なのかなと感じています。
ありがとうございます。
そういったチームの中で大介さんは
現在どういった課題に向き合って、
どんな開発をしているんでしょうか。
そうですね。まずAi Workforceとか
なんぞやみたいなところの話からしないといけないのかなと
思うんですけど、Ai Workforce一言で言うと
文章処理の業務の効率化をするプロダクトとなっています。
例えば銀行とかの有識業務で
お金を貸すために決算書とか事業計画書とか
その業務の専門家が実際に読み込んで
それを読んでお金を貸していいかどうか判断したりとか
倫理書として出したりとかみたいな業務があるんですけど
そういったところをいかにLLMにやってもらえるか
みたいなところが我々のプロダクトになっています。
こういった専門家でなければなかなかできないみたいな
大変なドキュメントワークっていうのを
社内では知的単純作業とか
呼んでるんですけど
結構知識としては膨大なものが必要なんですけど
作業自体は繰り返し作業が多いとか
そういったところは結構LLMと親和性が高いので
そういったところをLLMにやってもらう
プロダクトにいかにできるかっていうところに向き合って
開発をしています。
課題で言うとそのAi Workforceっていうものが
既存の業務のお客様がやっている業務に
どれだけLLMとしてフィットさせられるか
みたいなところが課題となってまして
できればその仕事っていうものを
全部LLMにやってもらいたいんですよね。
100%パイルアップロードしたら
業務が全部LLMにやってもらいたいんですけど
やっぱりそこはギャップがありますので
そのギャップをいかに埋めるかっていうところが
我々の仕事で
実際の業務に即した程度改善だったりとか
人間がやるのとできるだけ近しい制度まで
理想的には持っていきたいので
そこの改善であったりとか
あとは後処理的にそのLLMが出力した結果を
実際の業務で使えるように
人間がレビューしやすくしたりであったりとか
あとは結果を見つけやすくしたりとか
検索体験とかを含めて
そのLLMが出した結果というものを
より見つけやすくしたりとか
そういったそのLLMをネイティブになく
組み込んだパースとして
いかにユーザー体験を高められるかみたいな
そういったところの課題に取り組んでおります
すごいAi Workforceとは何かみたいなところから
分かりやすく説明していただきありがとうございます
そうですね
LLMプロンプトとして使いますというだけじゃなくって
LLMネイティブに組み込んだプロダクト開発といったところで
かなり全般的に開発していただいているといったことが
理解できたかなと思います
ゆでさんも同じように
どういった課題に向き合って
どういった開発をしているのか
お聞かせいただいてもよいでしょうか
はい
そうですね
自分も結構おすけさんと同じ課題感かなというところは結構あって
まず1点目の頃は
これは結構初期の頃のSaaSの開発で
よくあることかもしれないんですけれども
どこまで個別のお客さんの要望を取り入れるのかとか
どこまで汎用的に作るのかみたいな
行き止めは結構難しいなと思っています
この機能はどのお客さんも思って作ったものが
実はあんまり使われなかったみたいなこと
結構よくあると思うんですよね
開発の難しさと課題
そういうところが難しいなと思っているのと
あと2点目は
先ほどのおすけさんと結構近いところで
さらに自分たちのプラットフォームって
LAMを組み込んでいるプラットフォームなんで
まだ類似のプラットフォームがなかなかなくて
ゆでさん体験自体が新しいものになっていて
何がありそうなのかとか
何が正解なのかっていうのが
作りながら分かってくることがすごい多いので
いかに作り込みすぎずごたやく作って
実際に業務を想定して触ってみて
それをどう改善していくかみたいな
っていうところに焦点があるのかなと思っています
最初からやっぱり焦点見えてないんで
最初に作り込んじゃうと
やっぱりこれじゃなかったっていうのが出てきちゃうので
いかにどんどん触っていって
これじゃないこれじゃないこれだみたいなところを
サイクルで回していくみたいなところは結構
課題感でもあり面白みでもなんかあるのかなと
個人的には思っています
エンタープライズ向け開発の特性
そうですよね
世の中にこういった正解があるとか
比較できるものがないっていうのは
結構難しくなるところの一つなのかなというふうに
理解しました
一手目は本当にアジャイルじゃないですけれども
ちゃんと小さく作って仮説検証して
これでいけるいけないっていうのを
判断しながら進めていっているっていう
ことなのかなと理解しました
その中でゆでさん的に
印象に残っている開発の経験とかってありますか
そうですね
結構全体的に相対するんで難しいんですけど
結構いろんなところで
個別のお客様の要望なのか
本当にプロダクトとして汎用的なのか
っていうのを結構見極めながらやられている
って感じですかね
そうですね
あの
LAMが処理した結果検索するみたいな
そういった機能があったりしてて結構ゆでさん
そこの基盤作られていたなと思っていて
結構検索を取っても
結構難しいところあるなと思ってて
汎用的な基盤として検索エンジン作っていくと
こういったユースケースだと
精度高くとかお客様にフィットするけど
それが本当に汎用的なのかっていうのが
分からないっていう中で
精度上げていくっていうのは結構難しかったんじゃないかな
と思っております
検索の開発に関して何かゆでさん的に
印象的に残っていることとか
難しかったところとかってあります
そうですね
今の精度の話でいうと
精度っていう単語自体はすごい
言うのが簡単なんですけど
それって分解していくと
じゃあキックなんなのっていうところが
結構未だに分からないところが多くて
もちろん正解のデータを作って
実際あっているかどうか確かめて
数字を出すみたいなところは全然できると思うんですけど
じゃあその正解データって本当に
お客様が使いたいものなんだっけっていうのって
最終的にお客様が開けてみないと
分からないところがすごい多くて
精度のチューニングも
個別のお客様ごとに最適化する
どこまでするのかとか
それも結構あるのかなとは
個人的には思っていますね
ありがとうございます
結構そうですね
ゆでさんもともと2Cサービスとかの
経験とかがある中で転職されてきて
僕ももともと2Cのサービス作っていたんですけれども
結構その辺が
いわゆるエンタープライズ向けの
サービスの作り方と発想が違ったりするところの
難しさの一つかなと思っていて
結構2Cだとデータ取って
全体的にユーザーがこれで喜んでいるから
これが正解になりそうっていうのがあると思うんですけど
エンタープライズと結構一社一社のユースケースが大きくて
そこに対してこれが本当に正解なのかとか
そういったのを確認しながら進めていって
それで一方でちゃんと汎用性があるのか
っていうのを確認していくのが
難しくも面白いところとしての違いがあるかなというふうに
個人的には思っていたりもします
そうですね
今一部課題だったり
どんな開発しているのかみたいなところを
話していただいたと思うんですけど
よりここのAI LLM事業部ならではの
開発の面白さみたいなところについて
深掘っていきたいなと思っております
特に我々のプロダクト
エンタープライズ
日本の本当にすごい大きい
メガエンプラみたいな企業さん向けに
プロダクト提供していったりしているんですけれども
そういったエンタープライズ企業向けだからこその難しさであったり
そこの難しさに向け合うことの楽しさだったり
そういったところとか何かあれば
ゆずさんからお話聞かせてくださいますでしょうか
はい
多分ですね
エンプラ企業様だと
この機能がないと絶対に導入できないっていうような
ノックアウトバクターみたいなのが
企業様のほうが結構違うなと思っています
例えばセキュリティ要件がすごい厳しいとか
一例としてあると思うんですけれども
それがあると
全体的に60パーセントのものを作るみたいな
というイメージよりは
絶対外さないものを見極めて
そこを作りこうみたいな作り方になるのかなと思っています
結構全体的に平均点を取るっていうよりは
この部分は絶対外さないからここはちゃんと作り込んで
他のところは最適に使わずにしようみたいな
結構割り切りといいますか
そういうところに結構焦点が当たるのかなと思っています
実装のほうもそれに合わせて
開発人の線度もすごく柔軟に調整するし
そういうところが結構固くなって
面白いところでもあるのかなと思っています
なるほど 結構開発においても
全体的にとりあえず機能を揃えますよりも
結構ちゃんとメリハリ付けながら
ノックアウトファクター避けつつ
ちゃんと提供していくってところがあって
そこが難しくもあり楽しいみたいな
ふうに感じているってことですね
そうですね
ありがとうございます
じゃあ次に大助さんはどういったところが
開発文化とコミュニケーション
このエンター
すみません AI LM 事業部ならではの
開発の面白さと感じておりますでしょうか
そうですね
先ほどエンプラ企業向けの開発みたいな話も
出たんですけど
結構我々スタートアップなんで
スタートアップらしい開発文化ってものは
できるだけいい意味で絶やさないように
しているかなと思っています
具体的に言うと結構2週間でスプリント回して
1週間単位でリリースしてみたいに
スタートアップなんでスピードが命で
変化に迅速に対応できるようにっていう
開発サイクルで進めているので
結構ターゲットがエンタープライズ様なので
すごい開発スピード落として
慎重に開発するとかの文化ではないように
しています
仕様を策定するとかっていうところが
別の難易度があるのかなと思いつつ
開発自体に大きな差異は作らないように
していると思っています
ただ先ほど井田さんもおっしゃったように
運用とかセキュリティ面で考慮するところは
多くてお客様はそれぞれに
様々なセキュリティ規約があったりとか
それを達成するために運用面の
構成が増加したりとかそういったところは
いなめないんですけども
Ai Workforceに価値を感じて導入して
くださっているお客様がいらっしゃるので
そういったところは我々の方でカバーしつつ
そういったセキュリティ面への考慮とか
っていうところが結構開発の難易度というか
運用の難易度が高いところでありつつ
普通の開発ではなかなか体験できないところであるので
新しさを感じているところです
そうですね
セキュリティ要件みたいなのを
エンプラー企業様向けに届けるので
かなり我々としても守りながらやっているけど
かなり言ってみれば
アジャイル開発だったり
スクラムちゃんと回していくみたいなので
スピーディーに開発していくっていうのは
すごい大事にしているところかなという風に
思っております
どういった開発プロセスなのかみたいな
話も出たと思うんですけれども
このAIレイルム事業部のプロダクトチームの
カルチャーを言語化したりすると
どういう風になりますでしょうか
大助さんから聞いてもいいですか
どんなカルチャーの組織っていう風に
大助さん見てます
そうですね
結構CMワークを大事にしているんじゃないかなと
思っています
機能開発を進める場合
基本的に1人開発オーナーを置いて
あとは頼んだっていうよりも
開発を進める過程で
事前に設計を壁打ちしたりとか
実装の方針を事前に相談して決めたりとか
チームとしてのアウトプットを出すために
協力して進めることが多いかなと感じています
あとは相談事項が少ないケースとか
あるいは事前に相談するよりも
先に作ってしまって
アウトプットベースで相談した方が
分かりやすいケースとかっていうのは
逆に最初に個人がゴリゴリ進めてしまう
ってことはあるんですけど
いずれにせよチーム内で協力して
アウトプットすることが多いのかなと
感じています
結構こういう相談しやすい雰囲気っていうのは
言うのは簡単なんですけど
行うのは難しいのかなと思ってまして
こういって自分も相談するのが下手なんですけど
例えば相談するっていうのは
チームの雰囲気で結構難しくて
自分に技術力がないと思われるんじゃないかな
とか感じてしまったりとか
そういった雰囲気だとチームで
そういった雰囲気じゃなくて
チームで知恵を集めて
ほうがより結果的にいいものが
早く出来上がるみたいな
そういったところを我々のチームでは
カルチャーとしてやって
むしろ積極的に相談したほうが
より良いみたいな
そういったカルチャーがあるのかなと感じています
ありがとうございます
結構コミュニケーション取りやすいというか
そういった相談しやすいような
カルチャーがあるって感じられていると
普段のコミュニケーションとかって
分かるような事例であったら
紹介いただければと思うんですけれども
どういった形でコミュニケーションを取っているような
組織というふうに見てますでしょうか
結構リモートが多いんですよね
コミュニケーションツールの中心としては
スラックでのチャットが
メインになるかなと思うんですけど
朝と夜
チーム内で朝会と夕会それぞれあるので
そこで我々が実際に行っているタスクを
共有したりとか
もしそのタイミングで相談事項があったら
その朝会の後
ちょっと時間いただけますかみたいな形で
設計とかリスト方針の相談をしたりとか
あとタイミングがずれていたら
そのスラックで
ちょっとこの後
後頭で30分ぐらい時間取って相談できますかとか
結構そういう
エンジニア文化の探求
スラックベースになるんですけど
後頭でより早く相談するみたいなところが
多いのかなと思っております
ありがとうございます
僕もレイアエックス入る前
レイアエックスのエンジニアの人って
いってみれば強強エンジニアが集まってて
相談しづらかったり
これ一人で作って当たり前でしょみたいな
そういったカルチャーなのかなって思いながら
ビクビクしながら
入ってきたところはあったんですけれども
結構スラックも賑やかだし
後頭での相談とか
ギャザーとか使ったりして
気軽に集まりましょうみたいなのも
割と気軽にできる組織なんだなっていうのが
ふた開けて感じたギャップとしては思ってますね
といったところで
ゆでさん的にじゃあ
このカルチャーを言語化すると
どういうふうに見えてますでしょうか
自分も結構大輔さんと同じところを感じていて
一言で言うと
怒られないであればやっちゃい
っていう感じのカルチャーかなと思ってます
もちろん全員頭走るとか
最低限のことはもちろん一言なんですけど
基本的には個人の想像とか工夫っていうのが
相当ある組織なのかなと思ってます
人数もだんだん最近増えてきてはいるんですけれども
まあまあ小人数なんで
逆にそういう個人個人のアイデアがないと
成り立たないんじゃないかと
個人的には思ってます
例えば
奥さんのとき言ってましたけど
先にある程度リフを作ってしまって
実際に触ってみてもらってから
これどうですかっていう感じで
仕事とかギャザー体験っていうのを
後から調整するっていうのも
全然あり得るかなと思ってます
あとこうした意味はあるんですけど
開発優先度の基本ってよくあると思うんですけど
そこにすごい時間がかかるみたいなケースだったら
じゃあ先に作ってみてから
ここ調整するみたいなことのほうが
早いことも全然あるんで
なんかがかっつり
仕事を先に全部決めてから作るというよりは
ある程度作っちゃってから
仕事を調整するみたいな
結構柔軟さみたいなところも
会社としては大きいのかなと思ってます
ありがとうございます
結構スタートアップならではな感じのところもあるし
結構テックドリブンな開発の進め方をしている
っていうところなのかなと思いました
本当に仕様がっちり決めないと
次に進めないっていうよりも
議論するよりも
とりあえず動くものを作っちゃって
それでミスったほうが分かるよねみたいなところで
進んでいくっていうのがあるかなと思ってます
なんかあれですね
AIレール事業部が
結構01でプロダクトを作っているから
といったところもありますし
そもそも生成AIのプロダクトって
何が正解なのか分からない
先ほどゆでさんがおっしゃられた通りではあるんですけれども
だからこそ目に見えるものを作ったほうが
提案の重要性
先に進むよねっていうので
そういった進め方をしているってところも
あるのかなと感じました
じゃあそんなエンジニア組織の今後の可能性とは
といったところでゆでさんに
そのままお聞きしてもらえるでしょうか
はい
そうですね
続きっていう観点とは若干ちょっと違うかもしれないんですけど
自分のエンジニアなんで
エンジニア視点からちょっと見てみると
さっきの話の続きになるかもしれないんですけれども
結構エンジニアが
仕様を提案するみたいなことがあったら
いいんじゃないかなっていうのを
個人的には思っていて
結構開発してると
実はこうしたほうが使いやすいんじゃないかみたいなことを
結構よく思い浮かぶんですよね
それを実際
Visioメンバーとかに提案してみると
そんなことできるんですかっていう
もらえることも結構あって
Visioメンバーからすると
これ開発のコースかかるからできないんじゃないか
って思っているのも結構あって
エンジニアからすると
こっちのほうが楽ですみたいなことって
全然あると思うんですよね
なので結果的に
提案してみたら
コース数も少ないし
ゆでさん体験としてもよくなるみたいなことって
全然あると思っていて
そういう方向に
発展できたらいいのかなっていうのがあります
エンジニアだからこそできることも
たくさんあるのかなと思っています
そうですよね
LLM 生成アイでどんなことができるのかだったり
開発でどんなことができるのかっていうのが
結構不透明だからこそ
どんどん提案していったり
先ほどあったような
目に見えるもの 動くものを作って提案していったり
しながら進めていくっていうのが
より加速していくというのかなというところですかね
じゃあ次は大助さんに
同じ質問させていただければと思います
はい
今後の話で言うと
実装よりの話をしようかなと思うんですけど
今後事業が拡大して
チームの規模が
我々のエンジニア組織としてのチームの規模の拡大が
予想されると思うんですけど
新しい方にジョインされた方に
パフォーマンス高くご活躍いただけるような
環境を準備していくところが
大切だなと感じています
その一環で
行動規約みたいなところっていうものを
ドキュメントとして自然言語で
用意するんじゃなくて
実装側で設計としてそのルールに沿って
形で実装しないと
そもそもCIでエールするとか
そういった
実装レベルでガードレールが
作られている状態みたいなところを
個人的には作っていきたいなと思っておりまして
具体例で言うと
マルチテナントな環境下で
RDD側で
テナントIDみたいな
テナントごとを論理的に分離していくための
IDみたいなところが
体として持っていて
開発者にクエリを実行するときは
テナントIDで必ずフィルターしてください
みたいなところを
コード規約として作ると
もしそれが巻き漏れていたら
重大なインシデントになっちゃいますし
そういった自然言語でのコード規約ではなくて
フィルターしていないと
CIがエールするとか
そもそもDBレイヤーで
テナントIDがないフィルターは
実行できなくなる
とかそういった
設計レベルのルール制約みたいなところを
今後
規模が拡大していく中で
そういったことを感じています
レイヤーXの
カルチャーや行動指針の中でも
別途テクノロジーであったり
型に投資する
そういった羅針盤があったりしますけど
まさにそれを大助さんが
体現してくれているなと思っていて
今後の開発スケーラビリティという観点でも
コーディング規約とかだったり
そういったものを用意していくのも
大事である一方
エンジニアらしくというか
ちゃんとルール
CIがちゃんとフェイルするみたいな
そういったルールを用意していくというのは
一人一人の意識とか
知識とかに頼らず
スケールしやすいような方法だなと思っているので
すごい
今後の開発組織のためにも
事業の魅力と成長
ありがたいことをやってくれたなと思っていますし
今後もそういったのを増やしていきたいなと思っております
今ちょっと組織観点で
お話を聞いたんですけれども
お二人がそれぞれ
今後個人としてAIレイルム事業部で
こんなことをやっていきたいといったところを
思っています
おすけさんから流れで聞いていいでしょうか
そうですね
ちょっと抽象的なのかもしれないんですけど
もっと
業務に溶け込んだプロダクトを
作りたいなと思っておりまして
やっぱ2Dのプロダクトになるので
その人たちが毎日
8時間仕事でやっていることの
業務自体を変革することになると思いますので
その変革を
1.5倍とか
2倍とかの
それだけ上げることでもすごいことではあるんですけど
今回AIレイルムというパワーを使って
もっと10倍ぐらい改善できるような
プロダクトを
エアワークフォースにしていきたいなと思っております
いいですね
50%とか
そういった改善じゃ面白くないと
100Xいくぞと
言ったところですね
ありがとうございます
ゆでさんも同様にお聞きさせてください
私も
モチベーションは今のお二人に近くて
急にガラッと違うことをしたいみたいなのは
実際あんまりないんですけれども
もっと開発スピードを上げるんじゃないか
というのを結構思っています
LMプロダクトに限らないかもしれないんですけど
結構なんか
開発スピード品質って
トレードオフで
スピード上げると品質落ちちゃうみたいなこと
よく言われていると思うんですけれども
自分は必ずしてもそうじゃないかなと思っていて
いったん機能を作り上げて
触ってもらうそれを改善するっていう
そのサイクルを
速度を速くすることによって
スピードと品質も同時に改善できるんじゃないか
っていうのを思っています
今社内で
そのスクリーンターで作ったものを
実際に触ってもらうっていう
意味でのレビュー会が
一週間に一回あるんですけれども
そこで実際に
作った機能を
他の皆さんの前で
デモしたりしてみせて
フィードバックをもらって改善するっていう
のが今やってるんですけれども
そのスピードを改善していくと
もっともっと開発スピードが実は
上がるんじゃないかなっていうのを思っていて
その開発スピードが上がっていくと
実際に業界で使ってもらえるものに
どんどん近づいていけると思うので
取り組むようなかもうちょっと
加速していきたいなっていう
抽象的なんですけれどもそういう思いはすごいあります
ありがとうございます
スクラムの結構大事な考え方の一つでもあるかな
と思うんですけどちゃんとフィードバックを
なるべく早く取り入れて
それで改善の速度を上げていくっていう
フィードバックループを何か作っていく
ってことなのかなというふうに思いました
ぜひゆでさんに
推進していただければと思っています
期待しております
はい
それでは結構よくある質問かもしれないですけど
ちょっとこの
AI LLM 事業部の魅力をちょっと
前面に次は押し出していきたいなと思っておりますが
今のフェーズで
ジョインスする面白さについて
っていうのを聞きできればと思っております
じゃあ大助さん
今のフェーズで
ジョインスする面白さについて
教えていただけますでしょうか
そうですね結構
チームの規模感とか
冒頭でお伝えしたようにまだまだ小さいですし
事業とかプロダクトもまさに
これから伸ばしていくっていうフェーズでは
AIとLLMの開発の挑戦
あるんですけども
そういった反面
LLM を中心としたプロダクトの体験を
一から考えて
実際に開発していくっていうところが
体験できるのはまさに
大事だと思っておりまして
我々のAi Workforceのプロダクトも
現在基本的なベースのところが
できているだけで
まだまだスクラッチから開発しなければならない
大きな機能がたくさんあったりとかしますので
そういったところを一から
作り上げることができる面白さを
試したところは
今のフェーズならではなのかなと思っております
あとは結構
LLM っていう技術も
マーケットのトレンドもあるんですけど
すごい個人的に
これまで研究開発ずっとしてきたからこそ感じる
技術トレンドの波みたいなものがあって
そういった
LLM とか大規模言語モデルとか
そういったトレンドの波とかを見ても
今まさにエンジニアとして
ジョインするのもすごい価値のある
ところなんじゃないかなと思っております
おっしゃる通りだなと思います
ゆでさんも同じように
今のフェーズでジョインする面白さについて
教えてください
そうですね
でもお客さんが
言っていただいたように
ベースの機能は一旦できてきて
これからその前に
作っていこうというフェーズになるかなと思っています
ただベースの機能は
できてきたんですけれども
個人的には
LLM の新しいモデル
定期的に発表されると思うんですけれども
結構そこでゲームチェンジみたいなのが
起こることってあるのかなと思っています
最近だと
オープンAIで
オーワンプレビューって発表されたと思うんですけれども
今のやっぱり自分たちで
LLM に話したいことを
自分たちでタスク分割として
プロンプトを作ってみたいなことも結構やってたと思うんですけど
そうじゃなくて
LLM のほうがライブでタスク分割としてくれて
もしかしたら自分たちで
頑張らなくてもよくなるかもしれないということが
多分やってはいると
思っています
そのときに自分たちのプロンプトの話して
どこにあるんだろうっていう
すごいたくさんあるのかなと思っていて
この今のプロンプトの
延長線上でただ作っていけばいい
っていうものでは全然なくて
今後もいろんな方向に発展していく可能性があるので
そこがすごい面白いのかなと思っています
求めるエンジニア像
ちょっとエモいよりの話になっちゃいましたけど
ありがとうございます
エモいよりの話が聞きたかったところでもあります
そうですよね
結構
2023年とかだと
GPT-4 が出て
結構
どちらかというと
悪いみたいなどんでん返しというか
これ出たら今まで開発してたらどうなるんだろう
みたいなことが多かったと思うんですけど
結構最近の
いろいろなプロダクトの発表とか見てると
ゲームチェンジみたいなのは
ありつつも
結構自分たちがやろうとしていたことが
よりエンハンスされるであったりとか
よりどちらかというと
プロダクトであったり
自分たちの本質みたいなところはどこなんだろう
っていうのを考えさせられるきっかけになったり
するような
結構そういった発表とかは多かったりするかな
と思ってます
One Preview とか One Minute とか発表とか
まさにそういったところなのかなと思ってますし
そういった技術の変革みたいなところと
足並みを揃えながら進めていけるところは
今のフェーズで上位して開発を進めていくところの
面白さなのかなというのは
すごい私としても
納得できるところだなと思っております
はい
ではありがとうございます
最後に宣伝といったコーナーで
こんな人と働きたいといったものを
それぞれゆでさんおすけさんの順で
宣伝させていただければと思います
ではゆでさんからお願いいたします
はい
そうですねやっぱり
かなりスピード感のある方として
マイノリのような人が向いてるなというのを
思います
ソフトウェアエンジニアでいうと
もちろん実装力があるというのはそうなんですけど
ユーザー体験的に
どういうのが一番いいんだっけというのを考えられて
そこに向けて
こういう設計だこういう実装だったら
効率よくできるよねっていうのを
考えられて最後まで
実装して動くものが
作れる人っていうのが結構
大きいのかなと思います
技術力がありつつ
前のめりに自分で企画して
設計して実装して
人に見せて改善も進めていくみたいな
そういった方と一緒に
働きたいということですね
じゃあおすけさんお願いします
はい
この短い時間の中で
この話を聞いて
自分もやってみたいと思った方が
ぜひ一緒に働きたいなと思っているんですけど
例えば
プロダクト開発を一通りやってきていて
大きな企業に
デリバリーするための開発とか
あとはLMをネイティブに組み込んだ
プロダクト開発とか
少しこれまでと違ったテイストの開発をしていきたい
みたいな方
そういった方も結構モチベーション高く
働きやすいのかなと思っておりますし
あるいはその既存の業務を
LMみたいな
新しい技術を使って
変革していきたいみたいな
強い野望とか野心を持っている方とかも
ぜひ一緒に働きたいなと思っております
既存の業務変革していって
仕事なくしていきたいですね
すみませんちょっと
僕は志が低かったかもしれない
そういった野心を持った人と一緒に働きたい
と思っております
それでは本日
レイアックスナウこれにて
終わりたいと思います
佑田さん大塚さんありがとうございました
では失礼します
ありがとうございます
ありがとうございました
