AIの導入と組織の変化
村島
こんにちは、primeNumberです。この番組は、データ活用支援を行うデータテクノロジーカンパニー株式会社primeNumberで働く人や社外のゲストを迎えて、業界や働き方といったビジネスの話はもちろん、
その人のプロフィールや趣味についてもカジュアルにお話しするポッドキャストです。後編も鈴木健太会ということで、CARTA HOLDINGS CTOの鈴木健太さんと
primeNumber CTOの鈴木健太さんをお招きして、AIであったりデータ活用といったところに焦点を当てながらお二人の話を聞いていければと思います。
CARTA HOLDINGSさんでは、どんなふうにプロダクト開発でAIを取り入れてらっしゃるんですか。
CARTA HOLDINGS 鈴木健太
いわゆるAIの各種ツールというところは、本当にマーケットにリリースされたタイミングでですね、社内にどんどん入れるということはやっています。
なので具体的に言うと、それこそクラウドコードもそうですし、デビンとかGitHubのコーパイロットとかはもう2年前ですよね、とかから使い始めていて、
出たタイミングでエンジニア陣からのフィードバックを受けて、よりそのツールの使者選択をしていくということは日常的にやっています。
今年に入ってからいわゆるエージェンティックコーディング、自律的にタスクを行うエージェントというのが選択肢が増えてきたので、
これはですね、社内のエンジニアの関心が高くて、僕自身もですね、使いながら仕事をしているというのが現状になっています。
パルタの社内で言うと、ジェネレイティブAIラボという、生成AIを中心としたラボ組織がありまして、そこにも知識を集めて、
1個のチームに知見が溜まってはいくんですけど、それをなるべく社内に共有できるような枠組みを作ったりというところも、組織としてアプローチしてやっています。
村島
やっぱり組織として取り組んでいくということが、これからの時代には非常に重要になってきそうではありますよね。
AIコーディングの進化
CARTA HOLDINGS 鈴木健太
やっていて思ったのが、組織構造に知識ってこう、修練していくということが。構造がないと、やっぱり知識自体が伝播していかないというのがあるなと思っています。
なので、エンジニアだけじゃなくて、全社でAI推進という、いわゆるいろんな業務のプロセスの中に、AIを前提に設計して入れていこうということも併せてやっているんですけれども、
ホールディングスの中にAI推進の組織を作って、それを各事業の中に伝播させていくと。
そのためにAIに詳しい人たちが中に実際に入って作っていく、ちょっとエンベディング的なアプローチをすると、やっぱりうまく進むので、
それやっぱりなんか、これは1個やっぱり組織パターンなんだなっていうのは、やりながら感じているところですね。
鈴木健太
各組織でAIを進める責任者じゃないんですけど、それがイネーブルメントの立場の人でもいいですし、今の人というかこの元々の組織の人でもいいですし、
なんかそういった進め方ってAIこそ一番重要になってくるんだろうなというところは、自分自身も3ヶ月間AIを適用させるかみたいなところをやっていて、
思った感じでした。これなんか本で見た組織パターンだなみたいなところは思います。
CARTAさんの中で、でも明らかに最近なんかAIコーディングの流れ変わってるな。
うちの会社的にはクロードコードマックスが出たあたりから、こんなにAI使いまくって試せるんだみたいなところですごいマインド変わってきたなって思うんですけど、
CARTAさんの会社だと実際どんな感じですか?
CARTA HOLDINGS 鈴木健太
本当に使い放題で人が変わるっていうのはまさにおっしゃる通りで、コストを気にせずトライできるようになるっていうことが多くのエンジニアのコードパターンを変えたとおっしゃる通りだと思います。
あとはですね、自立性っていうのが大きいかなと思ってまして、GitHub Copilotでいわゆるエディターにインテグレーションされたコード補完の形でっていうのが初期で使ってたもんですけど、
ChatGPTで会話的に作るとかもそうなんですけど、やっぱりそれがよりこう指示すればタスクをお願いすればやってくれるとか、タスク分解までやってくれるっていうのが大きくパラダイムを変えたなっていうのは実感としてはありますね。
鈴木健太
うちの会社も多分クロードコードマックスが出てくる前は、グラインとかいうのってドロップのAPIかませてやってたんですけど、毎回コストが出てくるじゃないですか、あるタスクをやって2ドルかかりましたとか、ドキュメントいっぱい読ませたら10ドルかかったみたいな。
コストが出ると失敗しないようにしようって意識がすごい高まっちゃうなって思っていて、なかなかこういろんなケース試すのにも、じゃあこれやったら100ドルぐらいかかっちゃいそうだからそれ試す価値あるんだっけみたいな。
AIって不確実なのに、ある程度そこで予算を考えなくちゃいけないみたいな話がボトルネックになってたんだろうなと思っていて、それがクロードコードマックスによってガラッと変わったなっていうのはすごい体感してる部分としては。
CARTA HOLDINGS 鈴木健太
プランさせるだけで弁当台飛んでったみたいな話するのがそんぐらいか、容易に飛んできますもんね。
鈴木健太
散々やり取りした、逆にすいません、最初のコードに戻りますみたいなことで10ドルかかりましたみたいな。
CARTA HOLDINGS 鈴木健太
コードを捨てるっていうことがすごいやりやすくなって大きい進歩だなと思ってまして、AIまあ失敗してもいいやって感じで使えるっていう風になったのが大きいなと。
設計判断っていう上でも機能を追加しようって試しに実装しようと思っても、じゃあ1週間かかったものがやっぱりすぐ終わるんで、設計の方針転換っていうものがやりやすくなったって、これは結構多くのエンジニアが感じてる部分かなと思うので。
結構ですね、僕らのプロダクションのコードにそのままマージするっていうものもまあもちろんあるんですけど、設計するときに何がいいかっていうのを試すって自分で最終的なコードを自分で書くんだけれども、使い捨てで使うっていう人は結構増えてきた。
鈴木健太
そうなるとやっぱり別に完璧なコードである必要なくて概念の検証だけできれば良いから、比較するのに十分なコードを書いてくれるってなると別にAIでも十分そこまでたどり着けるみたいな。
CARTA HOLDINGS 鈴木健太
そうですそうです。
AIネイティブ化の取り組み
鈴木健太
自分ももともとは設計じゃ分からない部分ってめちゃくちゃ多いから、そういうところをちゃんとコードを書いていろんなパターンで検証しようみたいな。
とはいえなんだかんだ1週間とかそういうところにかかっちゃって、そこを目に見える形でパワッとコードを書けるようになっているのはすごいパラダイムの変化だなっていうのはちょっと話聞いてて思いました。
村島
primeNumberの鈴木健太さんとして、primeNumberのAIの取り組みでこれを特にアピールしておきたいみたいなものはありますか?
鈴木健太
primeNumberはですね、ちょうど今年の6月ぐらいからプロダクト開発のAIネイティブ化をやっていこうという宣言をしてやり始めました。
初めに何をやったかというと、AIネイティブのレベル表を作るってことを最初にやりました。
自動運転のレベル表、レベル4だと完全に自動運転でできる。
レベル1だと今の状態か、何かちょっと一定人間化改ざんが必要かとか段階をちゃんと定義して、今自分たちがここにいてレベル4としてここを目指していこうみたいなのを定義したところから始めました。
定義したのが実際には4月末とかだったんですね。
そのタイミングだとAIが自律的に開発して、エンジニアの人はそれをレビューするのが中心とか、コードの80%以上はAIが書くみたいなレベル4を定義して2年後ぐらいをダイエットに、2年後にはそうなってるだろうみたいなことでやり始めた感じでした。
ちょうどそのタイミングぐらいからクロードコード、6月ぐらいからクロードコードMAXがどんどんエンジニア界隈で流行り始めて、実際にやってみたらあれ、レベル4思ったより早くいけそうだなみたいな。
それが今の段階かなって思います。
エンジニア組織をお話ししていくと、ソフトエンジニアは大体15名ぐらいいるような組織です。
いくつかの開発のチームに分かれていて、もともと最初にAIネイティブやっていこうってなった時に、自分とかCTオフィスのメンバーが他に2人いるので、そこで中心にやっていこうっていう考えもあったんですけど、
いかに多くの人たちがAIに触って、エンジニアがAIに触って、そこを体験して、チームごとにやってる開発の内容とかもバラバラなんで、適応するのも多分バラバラになるから、各チームからAIチャンピオンっていう形で立ててもらって、じゃあこのレベル4をみんなで一緒に目指していこうみたいなところでやり始めた感じでした。
CARTA HOLDINGS 鈴木健太
AIネイティブレベルっていうのは個人なんですか?それとも組織に対するレベルなんですか?
鈴木健太
両方かもしれないですね。開発の状態を定義したみたいな感じですね。
このレベル4だったらほぼエンジニアはボードを書かなくて、基本的にはAIが手動で開発していって、我々は複数のAIをマネジメントするのが仕事みたいな、そんな風に定義してました。
違っていると個人寄りみたいな感じですか?
CARTA HOLDINGS 鈴木健太
結構僕らもやってて、プロダクトごと、チームなんですけど、ひもつくプロダクトごとに結構差が出るなと感じていて、
というのは、例えばGitHub上でも結構ネイティブにインテグレーションされた機能が例えば増えていったりするので、
リポジトリ単位の特徴が見えやすいなと。でも当然それが複数重なり合っているプロダクトになるんですけど、
鈴木健太
レベリングと指標があるとやっぱりみんなそこに向かえすぎるなとは思いつつ、僕らもどうやって設計したらいいかなというのはちょっと関心を落としちゃったので聞いてみました。
多分完璧な指標では全然ないって、ある程度なんとなくの方向性を示しているだけみたいな感じかもしれないです。
とはいえ、多分言語化するのが一番大切だなと思っていて、社内でレベル4、AIネイティブのレベル4っていったらだいたい全てのエンジニアの人がそういう状態かみたいなのを想像できるぐらいにあったかなと思っていて、
厳密に定義することが目的というよりはゴールを示すのが目的みたいな感じで考えています。
CARTA HOLDINGS 鈴木健太
AIが出てきて仕事は楽になったのかみたいな、結構僕らだと確かにある面では楽になったんだけど、
そもそもコーディングする時間って実は仕事の中で一部8割とかにはいかなくて、1割ぐらいとかで、結構多くの時間をサーベイだとかいろんなことに費やしていたとか、
意外とそのコーディングそのものよりも他の考えるプロセスとかを削減するっていうのはすごく効果があったよねって。
一方で楽になったかどうかで言うと結果的に仕事はどんどん増えて、密度が上がって、すごい強度が求められるようになってるっていう、これも同時に起きてる気がしてて、
AIとエンジニアリングの変化
CARTA HOLDINGS 鈴木健太
なんかその辺って話題に出たりしますか、チームと。
鈴木健太
コーディングが早くなってるのは多分事実で、とはいえ多分80%ぐらいの完成度を持っていくのはAIめちゃくちゃ得意なんですけど、
結局それをプルリクエストとして出せるかって言われたら多分全然そんなことはなくて、結局人間が多分書いてやらなくちゃいけないとか修正しないといけなくて、
AIが出したコードですって言ってレビュー出すのって絶対ダメだと思って、なんかその人が自分が書いたコードとしてAIを使ったものでレビュー出せるみたいなところにどう持っていくかみたいなところはやっぱりまだまだAIだけじゃ難しいし、
もともとコード書くって自分が理解して書いてアウトプットしてPR持っていくタイミングで自分の中でコードの構成とか理解してると思うんですけど、
そこが多分いきなり吸っ飛ばされて、なんか今まで存在しなかった自分が書いたコードをレビューするみたいなところに時間が増えちゃってるんだろうなっていうのはちょっと感じる部分としてはあります。
CARTA HOLDINGS 鈴木健太
そうですよね。だから書きながら理解するみたいなのもすごく重要なプロセスで、それが吸っ飛びますもんね。
僕らは感情的に結構起きる問題として、若手のエンジニアがグロードコードとかでパッチ書いてプルリクエストあげて、
元からチームにいるエンジニアから、いやこれ自分で書いてないでしょ、めちゃくちゃAIじゃんみたいな、そこでこうちょっと、え?なるっていう。
鈴木健太
AIに出力させてるコストとレビューするコストで言うと、レビューする方がやっぱりすごく、しかも単にやる場合はすごく大変で、ここがコンテキストが飛んじゃうっていう。
CARTA HOLDINGS 鈴木健太
なんか今まさにそのレビュー負荷が高まるみたいなことがやっぱりすごく起きてて、もちろんその変更自体をAIがまたさらに補助してくれるはずあるんですけど、
なんかそれはチームの中での摩擦的な部分で言うと結構起きやすいんです。なのでおっしゃってたコード自体のオーナーシップを、結局パッチ出した人が責任を持って出してない。
AIの出力を自分がちゃんとレビューしないってなると、それが起きやすいんで、短期的には起きましたね。
エンジニアの仕事全体の中で、仕事が楽になったのかっていうところで言うと、もともとのコードを書く時間じゃなくて、サービスしたりとかする時間が多かったよねっていう中で、
そこもAIがかなり圧縮してるなと思うんですけど、そもそもAIができて僕らの仕事は楽になったのかで言うと、僕らの結構アンサーとしては結局密度が上がってて、
あんまり楽って、スループット出てる、シャートプットも出てるし、場合によってはアウトカムに繋がるけど、でもある意味マーケットで見ると競合もそういう状況でみんな早くなってる。
なので、結局仕事密度が上がって大変っていうのが起きてる気がしますね。
鈴木健太
そうですね。すごい単純な部分とかはもうAIで書けるようになっちゃってたりするんで、本当に自分の中で難しい部分しか仕事をやらないみたいな、そういう感じで圧縮されちゃってるってことですよね。
でも楽にはなってないけど楽しくはなってるかもしれないと思うかもしれないですね。
エンジニアの自立的学び
鈴木健太
難しいことだけやってた方が目覚めるし。
CARTA HOLDINGS 鈴木健太
やっぱり人間に残されたのは一番難しくて複雑なことをやるっていう訳が残ったっていう感じがします。
鈴木健太
疲労度は上がってるかもしれない。
村島
じゃあそんな時代に活躍するエンジニア像ってどうなんですかねっていうところを鈴木健太さんなんですけれども、primeNumberの鈴木健太さんにお伺いできればと思うんですけれども。
鈴木健太
到達する山の高さ、コードとかアーキテクチャー設計によって到達する山の高さは別に変わってないんですよ。
そこに対して8合目ぐらいまだAIが楽にいけるようになったけど、後の2合は自分で上げていかなくちゃいけない。
山の高さ、いただきの高さは変わってないんで、そこに求められるレベル感っていうのは全然変わってないみたいなのがあるかもしれないです。
なので結局いろんなことを学習して、新しい技術を学んでとかってところは、これまでのエンジニアリングで求められたところと全く変わらない状態になり続けるんだろうなっていうのは、
よく言われてる話な気がするんですけど、そこは確実な部分かなって思うんですけど、鈴木健太さん。
CARTA HOLDINGS 鈴木健太
本当そうですよね。山の高さっていうのはおっしゃった通りだなと思って、多分これ3年前と比べて自身の仕事を振り返ったときに、
当時掲げた山より同じ、あるいは低いとかだと多分全然AIのパラディナシフトの影響を受けれてないってことだと思ってて、
多分活躍してるエンジニアってもっと山高くなってるはずなんですよね。それは仕事量もそうですし、クオリティーが上がってると思うんです。
解いてる課題っていうのはまさにおっしゃった通りだなと。もう1個このエンジニア像っていう観点で言うと、すごい学びやすくなったなと思っていて、
僕もともとGoが好きで書いてたんですけど、Goだと書けるけどラストだとどうやって書くんだろうとか、同じ仕組みを別の言語で作ったりとか、
Webだとこうだけどアプリだとどうなんだろうとか、別のパラダイムで物を考えるときにすごくやりやすくなったなと思ってて、
こういう学びやすさみたいな環境が上がった結果ですね、特に新卒のエンジニアとかと話してると感じるんですけど、地の高速道路って言われてたものが、
高速道路どころかもう1人1人飛ぶ飛行機で飛んで最短距離で行ってるみたいな、ある領域だってめっちゃ詳しいみたいな人がすごい出やすくなってるんですよね。
なんでこの学ぶ吸収力っていうか、これまではこれを失敗していかないとダメだったでしょみたいなところがショートカットされてできるようになっちゃうっていうのが起きるんですけど、
多分これは今起きてることなんで、そういう尖りというかアンラウンというか課題できる人っていうのがやっぱり今すごくアウトプットしやすくなってるなっていうのを感じるんですよね。
鈴木健太
学びのスピードが上がってるのはすごい感じていて、AIの使い方次第だと思うんですけど、
データ分析とAIの活用
鈴木健太
自分本とか読んだときに、エンジニア組織論の本を読んだときに、結局自分のとこに当てはめて考えるとどうなるんだろうってところって、
結構今まで推測で考えなくちゃいけない部分だったなと思ってるんですけど、AIってそこ埋めてくれるのめちゃくちゃ上手いなと思ってて、
本の内容の抽象的な話とうちの会社の具体的なところに対してどうマッピングするのかみたいなところとかすごい得意だし、
他の言語を学ぶみたいなのも全く同じような話で、他の言語にマッピングしたらどういう感じになるのかみたいなところは自分の理解度に合わせて説明してくれるみたいなところを、
学習のスピードめちゃくちゃ上がってるなっていうのは直近自分もいろいろやってて感じる部分としてはありますね。
CARTA HOLDINGS 鈴木健太
社内でよく言ってるのは、誰かに伝える前に一回地味に、もうちょっとGoogleワークスペースが標準なので地味に、一回地味に聞いてと、
地味に聞いてブラッシュアップしてから送ってくださいと、これやっぱりマストで入れるとクオリティ上がってくるんですよね。
それはやっぱり自分に寄り添ってフィードバックを入れるって今までなかったもんだって。
仕事の仕方が変わっているし、それから学べる人が結局伸びるっていうのが起きるなと思いますね。
鈴木健太
もう最近自分データ分析をすごい好きでやってるんですよ。
具体的にいくと、なんかJupyter Notebookとか使って、うちのプロダクトであるTROCCOとかCOMETA使って引っ張ってきたデータをJupyter Notebookでいろいろこうデータ分析したりとか。
やってることってあれって、分析の軸を決め、どういう風に分析しようかを決定して、
最終的にはPandasとかPythonのコードが書かれて、それで分析の結果が出来上がります。
どういう分析すればいいかって、あんまり自分自身知識なかったんですけど、そこってAIですごい学べるんですよ。
こういう分析したいみたいになると、AIが学習したものにおそらく含まれてるはず。
そんな特別な分析ってそんな大きくない。
AIに含まれてるんで、それに対してどういう風に分析すればいいかを聞くとある程度返ってくるし、そこに対して気になったところをどんどん深掘っていくと、
このケースにおいてマッチするデータ分析のやり方が一定程度提示されて返ってきます。
そこって今まで自分だったら学習できなかった、到達するのにすごい時間かかった部分だなと思っていて、
具体的に自分のユースケースに対してAIがマッピングして答えを返してくれるみたいなところで、すごいスピード上がってるなっていうのは感じます。
どういう分析をやるかを決めて、Pythonのコードが、AIもそれもクロードコードに作らせていますと。
結局そこまでいくと、もうエンジニアリングなんですよね。
Pythonのコードが正しいかどうかみたいなところを判断さえできれば、
かつあと分析の正しさ、分析方針の正しささえ判断できれば、アウトプットとして成り立つなと思っていて、
そういうところを学習して、かつ今までやってこなかった部分も、
ある程度エンジニアリングとかソフトエンジニアリングでカバーできるところがどんどん増えていて、
そこをサポートしてくれるのが意外だなっていうのが感じる部分です。
CARTA HOLDINGS 鈴木健太
すごい分かりますね。グルーコードというか、
この振る舞いを自然言語で問題を解こうとして、じゃあ分類をしましょうとか分析をしましょうって言った時に、
生成されたPythonコードが出てきた時に、ちょっと惜しいんだけど、本当はラスト1マイルこういう風に動いてくれたらいいっていうところをエンジニアって書けるじゃないですか、自分。
鈴木健太
そうですね。
CARTA HOLDINGS 鈴木健太
この乗り付けするみたいな部分が地味に効いていて、
エンジニアじゃなくて他のメンバーも、結構ジェミンのキャンバスとか、
いろんなところでコード生成して使ってもらうものを生み出したりっていうのをやってるんですけど、
なんか生成されたんですけど動かなくてどうしたらいいですかって言って、すごい起きるんですよ。
これは分析とかでもそうで。
なんで動かないかが分かるっていうか、むしろそのデバッグをし続けてる人たちなんで、エンジニアの場合は。
だから、じゃあそれもっとこうすればできますよ。ちょっとアリにすればこういう風にできます。
見えるっていうのは、僕らが思っていた以上に価値があるんだなっていうか、すごく感じるようになりましたね。
鈴木健太
僕もそこって今まで全く見えてなかった視点で、
データ分析とAIの影響
鈴木健太
データ分析のところに自分のソフトウェアエンジニアのスキル生きるんだみたいなところってあんまり意識したことなかったんですけど、
なんでかって分析についての色波を知らないとそこに到達できないからだったと思うんですけど、
なんかその部分がAIによって学習のスピードがめちゃくちゃ上がってて、
エンジニアリングの世界に落とし込めるみたいなところは、データ分析やっててめちゃくちゃ楽しいなって思う理由の一つかもしれないですね。
村島
primeNumberの鈴木健太さんからデータ分析みたいな方が話が出てきたかなと思うんですけれども、
ちょっとデータと経営っていうところについてもちょっとお話聞ければというふうに思うんですけれども。
鈴木健太
なんか経営って何かみたいな話でいくと、結局数値とか会社のフレームワークを定義して、
経営が考えないといけないことをいかに減らしていくかみたいなのがすごい重要なんだろうなと思っていて、
そういった点でやっぱりデータってちゃんと定義できるとスケールすると思っているんですよ。
そこはなんか自分の現体験としてもあって、前職の時とかもデータをもっと、
1ヶ月間でこの数値だけを上げてくれみたいな話のプロジェクトがあって、
みんながそこに向いて上げることによって結果的に会社の売り上げもすごい伸びたみたいな話があったりしていて、
いかにちゃんとKPIであったりとか数値に落とし込むかみたいなところは、
経営においてすごい重要なポイントなんだろうなというふうに思って、
最初の方で話もしたんですけども、うちの会社ってあらゆるデータをビジネスの力に変えるっていう、
会社のビジョンを掲げているのに対して、うちの会社はどうなんだろうっていうところをやっぱり考えるわけなんですよね。
もちろんすごいやれてる部分もあると思ってますし、
いろんなデータがうちの場合だとビッグフェリーとかに溜まってて、
分析しようと思えばすぐに取り出せるところはありますし、
それをもとに実際意思決定してやってる部分もあります。
一方でやりたい部分もまだまだいっぱいあるなっていうところが思っていて、
改めて自分のCTOのミッション何かって考えると、
この会社をあらゆるデータビジネスの力に変えるっていうのを、
どの会社よりも実現してるところにしていきたいし、行かないといけないって思って。
2Dのプロダクトってデータをもとに意思決定するのがめちゃくちゃ難しいなって思ってるんですよね。
契約も、例えば1年契約だったりとか、
経営におけるデータの活用
鈴木健太
開発してるロードマップの機能によって契約とかLTVがどんだけ変わるかみたいなところ、
複合的すぎるところが多いなと思ってるんですよね。
例えば2Cだったらユーザー当たりのPBフィアスとか、
すぐ聞く指標が見えやすいなと思うんですけども、
2Bのプロダクトってすぐに聞かないで、売り上げをKPIにしちゃうと、
それをもとに実際意思決定するのがすごい難しいなと思っていて、
ここら辺、かるたさんどうやられてるとか。
CARTA HOLDINGS 鈴木健太
かるたの場合、2Bの事業っていうのは非常に多いんですが、
僕らだとセールスがフロントに立って、
いろんなお客様に対して、エンタープライズセールスっていう点でやるってことが多いです。
特に広告の領域が多いので、実際の契約もそうですし、
実は案件といわれる、どういうくらいトラフィック自体が結局流れてくるかってことをモデルすることが多いです。
利用料みたいなものもよく見てます。
実際におっしゃる通り、特にプロダクト開発の現場で、
どのフィーチャーが結局この契約まで至ったかとかも至ったかって、
分かりづらくて分解しづらいっていうのは本当におっしゃる通りで、
いろんな複合的な要素ですっていうのは本当に起きます。
なので、測れないものって多分測れないので、
測れるところは自明な事実として測るけど、
無理やり分解しないほうが結局ハッピーかなと思います。
というのは、今回この機能あったからだよ、うまくいったよね、
セールスのおかげじゃないよねって、
多分誰かが思うとすごく不幸せなことが起きるんですよね。
チームとしてこのクオータで何が進んだのかってことはすごく重要だと思うんですけど、
要因を分解すればするほど犯人者の逆みたいなことが起きるというか、
なのでそれがうまく作用するならいいと思うんですけど、
うまく作用しないならそうしないほうがいいと思います。
一方で経営管理という観点でいくと、
何が結局リリースできたのかとか、
どんなお客様の課題が解決できたのかってことはすごく重要なので、
どんな課題を解消したかっていうことは、
ファクトとしてちゃんと認識したほうがうまくいくんじゃないかなっていうのは思います。
鈴木健太
通知化できない部分はもう一旦諦めて、
どういう課題を解決してその大きさがどうだったかみたいなところで繋いでいくみたいな感じですか。
CARTA HOLDINGS 鈴木健太
そうです。例えば分かりやすく言うと、
エンジニアがプレリクエストを100個出したから成功した、
そんなはずじゃないじゃないですかみたいな。
だから測りすぎるとおかしいことが起きるんで、
変に紐づけないっていうことも大事だと思いますね。
鈴木健太
なるほど。
僕今ちょうどいろんなKPIを作ったりとかデータ分析元に意思決定していこうみたいなところを、
今のミッションなんでやってるんですけど、
さっきのお話でこの数値上げたけど、それセルスのおかげじゃないよねみたいな。
そういうのはまさしくそうだなと思いつつ、
共通として追うべき指標をちゃんと設定して、
組織を越えてそこにちゃんと繋いでいくみたいなところって一番重要だなと思っているし、
そういうことをちょっとやっていきたいなみたいなので直近やってなりました。
非決定性の管理
CARTA HOLDINGS 鈴木健太
大変ですよね。本当測りたくなるんですけど、
ある程度セパレートでも健全にやっぱりプロダクト資産に対する投資が進んで、
その資産に対するリターンがどうだったかっていう観点で経営管理としては見るのが一番いいと思うので、
ここまでそれを密結合するかっていうのはプロダクトのフェーズだったりとか、
販路にもよると思っているので。
鈴木健太
データを下手に決めすぎるとというか、
堅かしてしまうとそれによって組織が動かなくなるみたいな。
CARTA HOLDINGS 鈴木健太
今のプロダクトでも多分エンタープライズでアカウント開けていろんな制約条件のもとにやってるケースと、
本当にそのままウェブから入ってきて申し込んでくれたケースとは全然シナリオが違うと思うので、
というところがあるとは思いますね。
鈴木健太
これから活躍するエンジニアというか、AIにおいておく一番大切な要素の1個として、
AIをちゃんと理解して、AIが非決定的であるってことを理解して、
いかに決定的なところに落とし込むかみたいな、
そういうセンスってすごい大事だなと思っていて、
具体的にいくと、さっきデータ分析をパンダスとかノートブック使ってやってますって話をしたんですけど、
例えばあれをAIにCSVの内容を投げて、インサイトを教えてくださいって言うとするじゃないですか。
それってでも毎回絶対違う答えが返ってくるんですよね。
AIがCSVの内容をその場で理解してそれに対してアンサーを出すみたいなところで、
すごい100%非決定的なものにやっていて、
それを基に意思決定するって絶対やってはいけないことだと思ってるんですね。
一方でやっぱり、いかに非決定的なところから決定的な部分に、
具体的にいくとパンダスとかそういうPythonのコードっていうところにアートブットを落とし込んで、
そこをちゃんとレビューして決定的なものに変えていくみたいな切り分けというかセンスみたいなところって、
AI活用とかAIエージェントを作るみたいなところでも全部当てはめる話なんだろうなと思って。
CARTA HOLDINGS 鈴木健太
非決定性、確率的に動くっていう部分をどう捉えて組み込むかって本当に僕らが今まで一部のシステムでやってたけれども、
それが多くのシステムに今後関わってくるってすごく大きいパターンのシステムだと思っていますと。
一つ、じゃあLREMを使ったから必ずしも確率的になるかどうかというと、
例えばパターンを限定的にする、出力のパターンを限定的にすることは多分できます。
選択肢をABCで選挙して、ABCからLREMにしてくださいってやればほぼほぼ選んでくれたりとか、
温度設定、テンパレーシャー設定をすることによってある程度同じ回答に寄せるってことがあると思うんですけど、
とはいえその入出力が特に入力が何なのかによって全然これって変わるっていう世界だと思うので、
じゃあそれをいかにコントロールするかっていうのは本当に新しい世界が来てるなっていうのは感想論ですけどすごく思うし、
いろんなエンジニアが苦労しています。
僕らでいうと結構アドバイスとしてよくやっているのが、
評価のデータセットをちゃんと作った方がいいよっていうので、
どんな入力が予想されてどんな出力を得たいかをちゃんとその今までの機械学者のシステムもそうですけど、
やっぱりどういうふうなものが期待された振る舞いなのかをやっぱりある程度のパターンで決め打ちしてでもいいから、
そこのユニット単位でちゃんと振る舞いの挙動を把握できるようにして、
それに基づいてアップデートも行っていくっていうことをしないと間違える。
なのでこれはもう本当に今までソフトエンジニアがやってきたオプスの世界かなり近いんですけど、
そういったことをやっぱりやるのが王道だよねって話はよくしてますね。
鈴木健太
AIが出した答えが正しいかどうかを評価するようなCIを作ろうみたいなそういう。
CARTA HOLDINGS 鈴木健太
それ自体もそうです。
本当にフリーフォーマットである場合にはよくLLMでLLMを評価するというのもありますし、
あと肯定的に人間側で決めたデータセットに対してCIで当てて、
鈴木健太
本当にそのアウトプットになるかっていうのを見ていったりとかっていうこともやってますね。
僕ちょうど先々日ぐらいにAIのレビューを強化しようみたいな記事を書いたんですけど、
何かっていうと過去のいろんなインシデントとかヒアリーハットみたいなログがうちにすごいいっぱい溜まってて、
ポストモーテムっていう文化でちゃんとドキュメントで何で起こったのかとか、
AIによるレビューの改善
鈴木健太
その時のレビューがどうだったのかみたいなのをいろいろ残していて、
それを元にAIに一回レビューさせて、レビューで何か気づけなければメモリファイルとかクロードマークダウンみたいなやつをどう回収すればいいかをAIに考えさせて、
レビューのガイドラインをどんどん補強していこうみたいな、そういうことをやってるんですよね。
できるだけでもそれも場合によっては結構複雑な条件になっちゃうんで間違ったりしてる可能性があって、
じゃあどうするかってなったらエージェントとかを作って定期的にその内容をレビューさせ、問題のPRをレビューさせて、
それが正しく検出できるかをまた別のエージェントでレビューするみたいな、そういうことをやりたいなというか、
一回やってた時は一個のセッション、クロードのセッションの中でレビューさせて、
レビューした結果を自分で評価させてみたいなのをやったんですけど、
多分AIは自分の出した答えは正しいと信じちゃうんで、それあんまり機能しなかったりしたんですけど、
最近だとエージェントを作るみたいなところが結構簡単にできるようになってきたので、
そういうところをちょっとやってみたいな。
サブエージェントで分けてるっていうことですかね。
ごめんなさい、サブエージェントですね。
他はちょっとチャレンジしてみたいなって思って。
CARTA HOLDINGS 鈴木健太
僕らが思ってるよりコンテキストを分けてエージェントを作るとちゃんと動いてくれるんですよね。
だからそこはそう思いますね、分けた方が。
鈴木健太
いかにコンテキストを減らした方が正しい答えでいるかみたいな、
エンジニアの人は持ってるけど他の職種の人は持ってない考えだなと思ってて、
そこら辺をどう他の組織にデプロイメントしていくとかは、
他の組織のAI活用みたいなところですごい重要になってくるんだなって。
CARTA HOLDINGS 鈴木健太
なんか状態をプログラミングするっていうことってソフトエンジニアだとすごくよく、
リアクトのステートもそうだし、いろいろなサーバーサイトの状態を含めて、
その何の状態を持ってるのかっていうのは直感的にはたぶん理解しづらくて、
それにかなり近いと思うんで、
やっぱり単発のプロンプトだとあくまで奇発的でも、
エージェントになると状態を持つんで、
すごく想像しやすにつながってるのかなとは思いますね、やってて。
鈴木健太の集い
村島
最後にお二方からリスナーの方へのメッセージとかってございます?
CARTA HOLDINGS 鈴木健太
もし聞いている中で鈴木健太さんがいらっしゃれば、
次回でもまた一緒にね、次は3人で話したいと思います。
村島
そうですね、それは本当にこの世にいる鈴木健太を全員集めて、
鈴木健太会をやるっていうのが私たちの目指すところかもしれないので、
ぜひお便りお待ちしてます。
鈴木健太
鈴木健太でよかったのっていうのは今日改めて、
鈴木健太さんとお会いして思いました。
ぜひ次は3人、4人でAIの話とかできればなと。
村島
そうですね、CT妖怪にはまだまだ鈴木健太がいるというようなところは、
私たちのリサーチ上でもキャッチはしているので、
ぜひ集めていきたいですね。
二人の鈴木健太さんありがとうございました。
鈴木健太
ありがとうございました。
