今出川FMは株式会社ヘルプフィールの今をお届けするポッドキャストです。
というわけで、今日もスペシャルなゲストにお越しいただきました。
本日は、クロードコードのトークン利用料トップ2ということで、
いっぱいお金を使っているお二人にお越しいただきました。
しょうかいさんとそらちぃさんです。どうぞよろしくお願いいたします。
よろしくお願いします。
しょうかいさんとそらちぃさん、過去一回今出川FMご登場いただいてますけれども、
改めて自己紹介として普段どんなことをされているのか教えていただいてもよろしいですか。
まずしょうかいさんからお願いします。
しょうかいです。
社内ではCosenseというナレッジデータベースの開発をしたり運用したりしています。
クロードコード利用料トップ3に陥落してしまいました。
よろしくお願いします。
お願いします。今1位誰でしたっけ?1位、2位、3位でいくと。
1位はそらちぃさんで、2位はサーチンさんという、私が育ててしまったモンスターがですね、
私を追い抜いて、めちゃめちゃ強く使って、すごいことになっています。
じゃあバキバキ育った人がすごいことになっているということで。
じゃあトップ2と言ってトップ3にお越しいただいたということで今回は、
いずれサーチン界もぜひやれればと思いますけれども、
まず開発部内にお越しいただいたということで、今日はどうぞよろしくお願いします。
よろしくお願いします。
そしてもう1方、そらちぃさんですね、自己紹介をお願いします。
はい、そらちぃと言います。
仕事はヘルフフィールのデータ活用を広めにやっていて、
データ分析基盤というものがあるので、それをいい感じに、
社内にいっぱいステークホルダーがいるので、人々の話を聞いたりとか実装したりとか、
あとはデータの収集のところをもうちょっとよくやったりとか、
そんなことをやって人々の意思決定をよりよくやっていこうみたいな、
そういう感じのお仕事をやっています。
いいですね。
よろしくお願いします。
お願いします。
というわけでトップ1、トップ3の方にお越しいただいたんですけれども、
いきなり初手で微妙にテーマからずれるが、
一旦開発部内ではトップ2ということで話を伺えればと思います。
はい、どうぞどうぞ。
昨日MEに帰りたこうとしたんですけど、やっぱりちょっと無理でしたね。
一日で。
なるほど。
ちょっとそこのギャップも含めていろいろお話を伺えればと思うんですけども、
まずそもそも2人微妙にクロードコードの意思決定、また違うところもあるのかなと思うんですけども、
それぞれ普段の業務に対してどういうところでクロードコードを使ってるのか教えていただいてもよろしいですか。
じゃあせっかくなのにそらちぃさんから伺ってもよろしいでしょうか。
そうですね、僕はですね、呪術回線で五条悟るっていうキャラいるの分かりますか。
いきなりループなところからスタートしましたね。
彼って術式の発動をオートでやる仕組みとかを作ってて、
それを発動してて常に資本のリソースを減らしてるみたいなやり方をしてるの。
僕もそういう感じなんですよ。
要するにほぼ全ての仕事をクロードコードでやるっていう前提をまず置いて、
やれないものももちろんあるんでそういうところだけ自分でやるんですけど、
そういうことをやってて、もうちょっと具体的な話で言うと、
例えばSQLを書いたりとかもちろんやったりとか、その編集とかはもう全部AIで、
今のデータ基盤のレポジティブのコミットはほぼ100%クロードコードが書いてるので、
僕は手で書いていません。
あとはデータのクエリとかはクロードコードでできるんで、
そういうものをやって、このデータおかしいんだけどみたいな話がよく来るんで、
そういう調査をやったりとか、
あと実はスラックを最近AIで書かせるっていうのを試みでやってて、
それ半端はうまくいってないんですけど。
僕はですね、全ての仕事ですね。
何をやってるんですかって聞かれると全てです。
なるほど。
何をやっていないかで言うと、人の話をちゃんと聞いて、
あなたがやりたいのはこういうことですかってミーティングとかやって、
要件を聞いたりとか、人の要求をちゃんと見たりとか、
あとは上司にちゃんと報告をして、
政治的にうってならないようにとか。
なるほど。
こういう人間の価値があってそうなところに集中してやっていて、
そうじゃないところは全部AIでっていう感じの使い分けですね。
これ結構下手したらミーティングもリアルタイムを上映してきたら半分できそうな感じもしますよね。
それは確かにそうかもしれないですけど、文字起こしは文字を起こすだけじゃないですか。
ミーティングの目的って物を決めることとか意思決定をすることなので、
そうですね。
そのためには議事録を書いて、ちゃんと意思決定をしているかどうかっていうのをバッチリ見たりとか、
そういう政治的な話みたいなのが入ってきたりするんですよね。
そういうところで僕は人間の価値を。
ペンは政治なんでしたっけ。
政治から逃げない。
なるほど、これいいですね。
逆にAIに政治をやらせてもいいんだけど、それはそれでまた面白いんだけど、
とりあえず今はそういう価値の出し方を考えています。
なるほど。
あとちょっと先に深掘りして聞きたいんですけど、
QAでおかしいかどうかの調査とかも全然ロードコードでガシガシ回してるんですか。
そうですね、僕はしますし。
いいですね。
結構平行でいくつも同時に調査だったりも回してる感じなんですか、それでいくと。
そうですね、そうなんですよ。
よくWebアプリケーションとかだったらポート番号が衝突して面倒なことになったりとかで、
並列でやるっていうのはちょっと難しいケースがいっぱいあったりするかもしれない。
そういうこともあるかもしれないですけど、データに関してはむしろ並列のほうが割に合うというか、
いろいろスラックで平行でポンポンパンパン飛んでくるんで、そういうものを効率よくさばいていく。
ガンダムでファンデルってわかります?
すいません、今日はジュース海戦というガンダムという私の教養の無さを痛感しているところです。
小型のビットみたいなのをブンブンブンブン回して、大型の敵とかってそういうふうに切り刻んでやるみたいな。
なんかちょっとイメージすると。
スラックで来てるようなもの、来るような依頼って大体簡単、中には簡単ではない話も来たりするんですが、
大体のものは、
ちっちゃいのが材料みたいなのもありますもんね。
割と小粒なんですよね。難易度を10をMAXだとして、難易度3ぐらいのものがパンパンパンパンってすごい頻度で飛んできて、
たまにやばめの弾がウワッて来たりすることもあるけど。
そがちさんがクエリーを回すんですか?クロードコードが直接回してくれる?スラックで依頼が来たやつはどういう経路で実行されるんですか?
例えばですけど、スラックで、今日はできたてホヤホヤな事例で言うと、あんまり具体的なこと言うと怒られるんで、
ちょっとある程度抽象的にあるんですけど、
この先週作ったテーブルのところで、ちょっと想定してない感じの値が出てきて、これはどういうことですかってスラックが飛んでくるとするじゃないですか。
僕はそのスラックのリンクをコピーして、クロードコードに渡すんですよ、このスラックを読んで。
僕のクロードコードはスラックのメッセージと画像の画像とかスプレッドシートとかビックリもちろん、そういうものを色々読めるように仕込んであるんで、
クロードコードがそれを読んで、このユーザーの想定はこういうことで、でも実際のデータはこうなってるからここが変だねっていうのを調査をして、
その該当するSQLの部分はここです、ここパーティション倍の句が1個抜けてますねみたいな、そういうことを全部調べたら自律的にやれるように組んではあるという感じです。
なるほど、そういうことかって、じゃあSQL PRを出して、PRマッチして修正的を実際にSQL叩いてみて、
ちゃんと適用されてますねってスラックで報告みたいな、そういう感じの流れ。一番簡単なのはこういうケースです。
いいですね、じゃあ結構だいぶ活用がどんどん進んでいってるというところでいくと、ちょっと紹介さんの話も聞いてみたいんですけれども、
どんな仕事をクロードコードでやってますかっていうところでいくとどうでしょうか。
そうですね、やってないところはそらちさんと同じで、人と話したり状況を認識したり、方針を考えたりとか、
あとなんかやった後、もう一回見守って、みんな喜んでるかなって見るところは人間がやるんですけど、ちょっとファジーなところがあるので。
やってるところはそれ以外の調査して、検討して、設計して、実装して、バグを探して、修正して、リリースして、またバグを探して、修正してみたいなところは、
もう本当に全部クロードコードでやってますね。
うん、なるほど。
これ結構紹介さんこそむしろいろいろ並列でぶん回してるイメージもあるんですけども、実際普段の生活としてはどういう感じになってるんですか。
検察としては朝起きる。
あ、ごめんね、生活だと本当にそっちになっちゃうんですよね。
朝起きると、
朝起きるのはクロードコードでなかなか難しいことですよね。
クロードコードをまず見て、
朝食もね、クロードコードで作られてて。
朝食もちょっと食べながら、クロードコードにも食べさせたりとかしながら、朝食っていうのはアイディアを、アイディアっていうか、
あ、なるほど。
間に思いついたこととかを食べさせる。
で、食べさせるっていうのはですね、並列に食べさせてて、さっき調査、検討、設計、実装がどうのみたいなこと言ったんですけど、
クロードコードのセッションが5個とか、午前後ぐらい常にあって、
いろいろこういうことが現状困ってて、こういうふうに直したいけど難しいんだよね、みたいな世間話みたいな相談をやってるのがあってですね。
並列にいろいろ検討してるんですよ。
で、だんだん話がまとまってきて、こういう方向でいけそうだねってなったものから順次実装がされていくっていう感じなので、
並列して相談が行われていて、話がまとまったらクロードが吐き出されて、そこからはそいつに1個に集中するんですけど、
実装、もうちょっと手直ししていって、リリースして、みたいな感じですね。
じゃあ割と相談窓口が5個ぐらい並列動いてるって感じですね。
油断しないとこれは本当に10個とかになっちゃうんで、収集つけなきゃっていうことで頑張って解決方法を考えないと。
相談窓口が多くなりすぎて、3週間くらい開いててずっと悩んでるみたいな。
早く帰るよ、みたいな感じですね。
いいですね。役所と違って24時間営業ですからね、クロードコードは。
そうなんですよ。
開きっぱなしに窓口でいきますからね。窓で行くとTeamXか何かで並列に出してる感じなんですか?
そうですね。Item2にTeamXでセッションっていう単位なんでしたね。
セッションっていう単位の中にウィンドウって名前なんだけど、見た目はタブのやつがいっぱいあって、
セッションに名前をつけて管理してて、それが5個ぐらいあって、その中のウィンドウが1個がクロードコードで、
1つが普通のターミナルとして打つやつで、他がログとか見たりみたいなやつがあって。
そういう状況なんですね。そらちぃさんこの辺りはどうやって使ってますか?
僕はCMUXっていうやつを使っていて、おそらくこの概念が近いものだと思うんですけど、
CMUXはワークスペースっていうものが1個あって、その下にタブがひも付いてるみたいな、そういう感じの構成なんですよね。
1個ワークスペースを作って、その下にタブを3個ぐらい配置して、
これ全然文脈が違うなっていうものはワークスペース単位で切り替えてみたいな。
定期的にタブは業務時間またいで、今日仕事もういいやってなったら全部消すようにしてて。
人間の思考でゴミが残る方が僕はちょっと辛いんですよね。
CMUXって1回閉じた後、レジュームとかって簡単にできるんですか?前のスケールレポートとか。
レジュームは普通に。
すいません、というのは起動しっぱなしのセッションが増えてきて、Macを再起動できないみたいな状況に私はなってて、
セッションのIDのメモをちゃんと取ってからリブートして全部レジュームすればいいんだけど、
めんどくさいなと思ったら30日ぐらい起動しっぱなしになってるみたいな。
多分その問題で言うと恐らく同じだと思います構造的には。
セッションのIDをちゃんとメモっていれば復帰はできるけど、そのメモを吹っ飛ばすと難しい。
なるほど、わかりました。
元々CMUX自体はSSHで繋いでるシステムをリジュームできる、そういうユースケースが昔は多かったですもんね。
そうですね。
あとこれはちょっとお二人に聞いてみたいんですけれども、
結構私クロードコードでコーディング久々に参戦するプロジェクトでやってみたら、
割とホイホイかけてよかったわっていうのがアリスも。
そんなに待ち時間あんまりなかったなっていう感覚もあって、
だいたい長くても数分でレスポンス返ってくるんで、
実は並行で回すの難しいなっていう感覚があって、
お二人バンバン回したり相談したりってやってると思うんですけれども、
この辺り仕事の渡し方も結構影響してくるのかなと思うんですけれども、
そらちぃさんはどういう流度で何を渡してるのかちょっと聞いてみたいんですよ。
僕も最初は並列でやる前は普通に3セッションでやってたんですけど、
並列って頭持たないんじゃないのって正直やる前に思ってたんですよ。
実際にやってみると並列でバンバン実際にやってみると並列に合うように脳の構造が変わるみたいな。
なるほど。
慣れるんですよね。
なので実際にやっていくと慣れるって部分がまず1個あります。
もう1個重要なのはタスクの流度の話はそれはもちろんあって、
コツとしてはすごく近いものを一緒にはやらない方がいいんですよ。
人間側の脳がバグるから。
なるほど、面白い。
ある程度ベクトル原作みたいな脳内マッピングがちょっと離れてるものを並列で増すっていうのがまずある。
例えばセッション1個目でやっていて、
このエージェントスキルもうちょっと良くできるなみたいなのを思ったら別のセッションで開始したりとか、
あるいはカスタマーサクセスの人から飛んできた話と経営企画の人から飛んできた話って結構離れてるんで、
その2つを並列させたりとか、他の人とあえて話すっていうやり方で流度を取っていますね。
なるほど、それは面白いですね。紹介さんこの辺りどうですか?
逆ですね。
逆なんだ、それも面白いですね。
逆にしてるのはどうしてるんですか?
私は似たような、どっから話そうか。逆かなと思ったのは、
調査して検討したり設計しているときに、
例えば開発してる機能の運用ツールの部分も気になったりとかして、
これ運用ツールだけじゃなくて、デプロイのプロセスここ遅くないか、おかしくないかみたいなのが気になって、
どんどん並列になっていって、それらが同時に実行されていったりするんですね、私のYX。
こういうのは並列にやってるんだけど、1個の問題だと認識してやってるから、
ややこしい1個の問題だなと思ってやっている程度なので全然疲れないんですよ。
離れた範囲の問題をスイッチしながらやるのは面倒くさいなとは思っているんだけど、
よく考えたらクロードコードを導入する前から私は並行して複数の開発をしていたから、
並列数はあんま変わってなくて、単に速度が上がっただけみたいな。
なるほど。結構元々やってた業務に近い感覚もあるって感じですか、紹介さん的には。
そうですね。手がようやく動くようになった。
私の頭の動く速度に追いつく手がやっと生えてきたみたいな。
戦時観音的なメタファイになってるんですよね、脳内では。
最初から全部認識できてるんだけど、あとプログラミング能力が追いつかなくて、
やりたいことに追いついてなかったんだけど、ついに腕が速かったみたいな。
なるほど。それは面白いですね。
そろそろ結構その辺り感じることはありますか、手が増えたみたいな感覚というか。
思いますね。やっぱり人を取ってくるのって非常に面倒じゃないですか。
大事ではありますよね。
大事じゃないですか。人を投入するよりもだいぶスケールするようになったなって。
今まで成果を多く上げていく、アウトカムの量を増やしていく仕方ってやっぱり人を増やすって話だったと思うんですけど、
そこにもう一個選択肢が追加されたなっていうのを思っていて。
AIを速すって速すがまず1点で、もう1点重要なのはAIが活躍しやすいように環境を作ろうっていうのが2点目。
これら2つをやっていって成果を上げていこうっていう道ができたなっていうのが最近思ってるところ。
結構この辺り面白い議論で、最近だとAIマネージャーみたいな概念とかも社内外で結構議論盛り上がってる気がしてまして、
人間の部下使うのとAIエージェントの部下使うので、同じ出力だったらAIエージェントでもいいんじゃないかみたいなアプローチが結構議論にはなってると思うんですけど、
この辺りお二人はどう思いますか。
僕はAIの方が好きです、人間に。
これは好みの問題としてまずそこがあるんですよね。
好みの問題っていうとあれなんだけど、これはちゃんと理由があって、
まず人間を育てる潜在的なコストっていうのはちゃんと認識した方がいいかなと思うんですよ。
一つはそもそもCACみたいなアクリディションのコストがまずかかってくるっていうのがまず一個と、
あと育てる際に戦略化するまでは時間がかかるっていうのがまず2点目で、
3つ目はそもそもチームとして働く以上相性っていうのが絶対あるんですよ。
絶対あると思っててチームリーダーとの相性が悪いとか、
そもそも業務的に向いてないとかっていうのは絶対あり得るんです。
データエンジニアってすごく採用が難しいですよ。
非常に貴重なスキルではあるから。
専門性高いですしね。
他のエンジニアを、例えばプロダクターエンジニアとかを転身させるってのもなかなか難しい。
指向性が大幅に異なるんです。
求められるスキルセットも違うっていう状況を踏まえたときに、
こちらのマイオは人を育てて実際に活躍させていくっていう動作自体には不確実性がすごく高かったという現状としてはあるはずなんですよ。
あるとは思うんです。
AIって業務のフローとかっていうのは資産化できる仕事として使えるんですよ。
例えば技術のアーキテクチャを入れ替えてAIにとってより使いやすいものにして、
AIがバリバリにクエリを書いてくれるように。
技術の選定でも大分やれる範囲は違ってくるんですけど。
あるいはワークフローを手順化してAIが完全実行できるようになりました。
AI向けの手順書を作りました。
これってすごい資産なんですよ。
でも人が間に挟まるとそれは資産じゃなくて知識になるということを考えたときに、
資本としてできるゲームになったっていう、
ゲームチェンジが起こってホワイトカラーの仕事はもうすでにそうなってるわけじゃないですか。
っていうことを考えると、やっぱりゲームとして扱いやすいレイヤーになったな。
だから僕はAIの方が好きだっていうのがあるんです。
人間はこうはならないから、不確実性の生き物だから。
そういうことなんですよね。
僕は不確実性があるものよりも、より確実にコントロールできるものの方が好きであるから。
再現性も持てるし、
あと仮に人間が後から入ってきても、そこで資産化されているものを取り扱うのは大分やりやすいですからね。
そうですね。
リスナーも含めて。
なるほどね。
逆に障害者さんはこの辺りのAIマネージャー的な議論ってどう見てますか。
なんか、AIのこと同僚だと思ってなくて、自分の腕だと思ってて、
なのでAIで人間を代替するっていう考えが全然わかんなくて、
いやわかるんですよ、なんでそういう考えになったか。
でも現実、AIが事実的に人間の代わりに働いているかっていう訴訟ではなくて、
元からできる人をパワーを上げて、そいつがやってたことを拘束にやってるだけであって、
人間の株としてカウントするっていうのはそもそも間違ってるようなと思うんですよね。
昨日考えてたのが、
2025年の初頭ぐらいにデビンとかクラインみたいな、
何か自動交流されて人間みたいに振る舞うソフトウェアエンジニアっぽい存在が実装されて、
同僚になってとか、それを見て同僚になってとかみんな言ってたんだけど、
それって勘違いだと思うんですよね。
単にできる人がめちゃくちゃやってるだけなんですよ。
直接AIを創造して開発に関してはなんですけど。
で、なんでそういう関係がするかっていうと、
そいつらのインターフェースが人間に仕事を任せるようなアナロジーに作られているせいで、
スラック経由でとか、まさにそういうことですよね。
そうそう。デビンさんとチャットして、デビンさんが指導機に何か作業してくれるか、
たまに様子を伺ってどうですかとか、
ちょっと今これをやっててみたいな言ってくれるみたいなやつなんですけど、
でもそれ2025年の初頭ぐらいの感じで、
その後プロードコードとか出てきたら、
もっと細かいスパンでどんどんいろいろ言ってったり、
あるいは長文をお互いに送り合ったりとか、
AI同士で長文を送らせ合って、いろいろ議論した結果をフィードバック、
レポートを人間が読んで、
あんまり人間とやってるっていうより、あくまでツールになってて、
今のところソフトウェア開発において成果を上げてるのって、
そういう擬人化されたやつじゃなくて、
スクールの延長みたいなやつだと思うんですよね。
だからAIのこと人権意識とか、
人間扱いして同僚が増えるとか、
そういう感覚は1年遅れてる感じがします。
そうですよね、僕もそう思う。
SFの読みすぎか、
その感覚が遅れたりかは二択。
パンチライン出ましたね。
SFの読みすぎっていう。
僕も紹介さんと近い考えを持っていて、
僕はAIって、
パソコンとか、あるいは車とかと同じ、
資本だと思ってるんですよ。
業務の効率を加速させる。
工場機械とかって、
要は自律的に工場の機械が動いて、
全てを生産してくれるわけじゃないじゃないですか。
コントロールする人間が必ずいる。
AIも同じ枠の中だと思ってるんです。
我々はAIを使って、
時間とか労働力に対してレバレッジをかけて成果を上げてはいくけど、
AI自体はマルチプライヤー、
かけ算の定数であって、
AI自体が何かを生産して、
AI自体が自律的に全てを生産しているわけじゃない、
っていうのが現状としてはある。
なんかAI、
そうですね、車内でまあまあ使われているツールとして、
ライブラリの更新、
リペンダーボットとかリノベートとかが作ってくる、
ライブラリの更新のプロジェクトの内容を解析して、
まるで私が書いたのと同じようなレポートが出てきて、
ここを直さないといけないとか、
こういう理由の変更だとか、
いろいろ解説してくれるやつがあるんですけど、
ただのユーザー視点だと、
紹介さんが生えてきたみたいな、
床から紹介さんが入ってきたぐらいの感覚にあるってことですね。
私からすると不完全なんですよね、今。
こういう時にうまく動かないだろうなとか、
ちょっと想像できたりとか、
実際に動かなくて直すっていうことを、
どんどん直していくみたいなのを、
結構しょっちゅうやったりとかしていて、
そっち側の、
AIをマネジメントって言っていいのかな、
スキルとか作ってる側からすると、
全然人ではなくて、
自分が多用しまくってるだけみたいな感じではあるけど。
マネジメントというより、
資本投下の話に近いようなと思うんですよね。
資産形成とかで、
資産形成って金を使って金を生み出す仕組みを、
金を使って金を生み出すことを資産形成というわけじゃないですか。
それだと思うんですよ。
資産を形成する資本を貯めていく、
資本蓄積のゲームだなっていうのが、
僕はAIを使う上でのポイントだと思ってて。
すごい。
その話をちょうどしている社内のご先生も、
別のページになっちゃった。
すごい。
マジか。
本当にソフトウェア資産として積み上げていくもので、
最初に出てきたサーチンさんが書いていて、
その下にCFOの宮永さんも何かいろいろ論争が起きている。
いい議論ですね。
マネジメントというよりはどっちかって、
おエコノミア化成術みたいな、
経済的なお金の金銭のリターンの最大化みたいな話と
もっと構造は近いのかなとは思っている。
なるほど。
じゃあそこのいかに工作機械というか、
向上機械を我々は作って整備していくのかっていうところが、
結構気になってきそうっていう感じなんですかね。
そうですね。
具体的には例えばエージェントスキルとかは、
手順、普段仕事でやっていたワークフローを
AIにも実行可能な形にするっていう意味では資産ではあるんですけど、
もう一つあるのは、
AI向けに最適化されたアーキテクチャというのが
僕はあると思っているんですよ。
データエンジニアリングの世界だと、
例えばDBTと呼ばれるOSSは、
AIが利用するという観点では明らかにデータフォームよりも優れているし、
例えばタブローを使ったBIというのは明らかに
ルッカースタジオよりもAIにとっては使いやすいものではある。
とか、AIにとってのアクセスのしやすさ、
APIがあるかとか、
あるいはアズコードな書き方でできるかとか、
そういうものっていうのは絶対あるんですよね。
そういうAI向けに最適化された技術的な選定っていうのは間違いなく必要になる。
そのAIをちゃんと資産として使うのは、
例えば工場とかって、
その工場機械を使うために最適化された工場を持っているわけじゃないですか。
テスラの工場とか。
それと同じだと思うんです。
AIが全力を発揮するために必要な枠の設計っていうのは絶対ある。
それは資産だなって思うんですよね。
なるほど、そこの枠の設計をどれだけやっていけるかが
勝負になってくるっていうイメージなんですね、逆に言うと。
そうですね。
僕は現代の優れたデータエンジニアの定義に1個加わったなって思った。
なるほど、面白いですね。
ここらへん紹介されたときにプロダクトマネージャーとか
プロダクトエンジニアっていう観点も出てくると思うんですけども、
やっぱり近いものの感覚はありますか。
あるんですけど、
もともと結構AIに適した状況ではあったと思うんですよね、ソフトウェア開発って。
なるほど。
パルクMCPとかCLIとスキルとかをかぶせたら、
だいたい別に何でもAI対応できるから、
改めてそういうところは普通というか、どうにでもなるから、
なんて言いますかね、ちょっとモニュメントになってるとき。
なるほど。
確かにMCPとか整備されてればアクセサーしやすいよねってありつつも、
結構そらちさんの話面白いなって思ったのは、
MCPとかの前段階としてもAPIだったりもっていうと、
AIにとって操作しやすい、叩きやすいっていう窓口があるかどうかでだいぶ変わるよねみたいな話ですよね。
そうですね、だいぶ変わりますね。
あともう1個あるなって思ってるのが、
AIを使うことがインセンティブになるような組織構造と、そうじゃない構造、
あるいはAIの活用を妨げるような組織構造っていうのは絶対あると思っているんです。
これは社内でも別の方が議論してたんですけど、やっぱり一番ネックはレビューなんですよ。
僕と紹介さんは共通する点として、レビューのプロセス自体に時間はもちろん取られているんだけど、
そのレビューのプロセスを最良可能な範囲の中に置いているっていうのが1つある。
いや、全然レビュー時間かかんないですよ。
僕もレビューはそんなに時間かけてないんですよ。
なんだけど、Hellfield全体がそうというわけじゃないんですよ。
本体側の方はものすごい時間をかけてレビューをして、
それがやっぱりボトルネックになってるよねっていう話が出てきてる。
なるほど。
そういうふうに組織構造ってほぼほぼレビュー、
開発においては組織構造ってほぼほぼレビュー構造と近いものがあるんですよ。
ある程度プロダクトを分割してやっていくっていうのは、
レビューの構造を最適化することにつながるような話だし、
そういう面から今のアプローチのやり方はあるのかな、
いろいろ取れるオプションとかっていうのは考えられるものなのかなと考えています。
はいはい。
はい、しょうがいさん。
ありがとうございます。
最近、すさまじいサイズの変更をバンバンリリースしてるんですけど、
全然障害も起きないし、
その変更した箇所って他のプロダクトからもガンガン呼び出されたりする場所なんですよね。
でも全然大丈夫なんですよ。
なんで大丈夫かっていうと、
AI使ってこの変更があっちのリポジトリに影響ないみたいなのとか、
ガンガン調べれるんで、
どんどん問題ないってことを証明していったり、
問題ない理由はこうですっていう説明もどんどんかけるし、
レビューめっちゃ楽だし、影響範囲に考えるのもすごい楽だし、
あと私がいろいろ作ったレビュー系のスキルとかが、
あらゆるバグを叩き潰しまくってくれてるので、
サニティレビューでしたっけ。
そうですね。
その辺のおかげで楽ですね。
なんでもできるし、全然障害もないし。
ここの類型をいろんな社内に展開していくための枠組みをどれだけ作れるかで、
今後のAI活用って変わっていくんですかね。
もっといろいろみんな実行してみたらいいと思うんですよね。
例えば他のリポジトリをAIに見て回らせて、
自分のところのプロダクトに使えそうな概念とか、
チューニングとかやってるのあったら教えてみたいなのを定期的に動かしてみたりとかすると見つかったりとか、
他のプロダクトのコードを読むのに使ったりとかして、
ヘルプフィールでもベクトル検索使ってるけど、コセンスのやつとはどう違うのかなみたいなのを、
いろいろ一緒に読み解いていったりとかしてやると、楽しいですよね。
確かに。コードの読み解きは強いですよね。
強いですね。めちゃくちゃ勉強になるし、
その上でこの辺とかこうしたらいいかもみたいなフィードバックを、
無責任にないけど、
時々やるか知らないけど、
いろいろやったりとかしていけばいいんじゃないですかね。
実際にプロダクト間での知識の輸出入とかもできるといいですよね、さらに加速して。
だいぶいい話になってきたところで、実はお時間がだいぶ迫ってまいりましたので、
ちょっと未来の話も聞いてみたいんですけれども、
今お二人が社内トップ3の部内2トップっていうのが分かったところで、
よりクロードコードか、あるいは他のものに限らず使っていくぞって考えたときに、
今後やってみたいこととか、こういうところの取り組みがいいんじゃないかと思ってるところとか、
あれば聞いてみたいんですけれども、今の話の流れ、紹介さんいかがですか。
やってみたいことですか。
正直この半年間ぐらい、いろいろ試してベストな方法が固まってきたんで、
私は開発に専念して、ユーザーの期待に応えていくのが必要だと思ってますね。
ユーザーにCosenseの開発をしているんで、Cosenseは社内でも使っていて、
いろんな人が考え事とか調べたこととか、書いたりとか相談とかをしている場所なんで、
そこをちゃんとAIでもうまく扱えるようないろいろな機能を作っていったりってのをバンバンやっていったら、
もうみんなすごく嬉しいんじゃないかなと。
それを今やるべきだなと思います。
いいですね。そろしさんいかがですか。
そうですね。僕もこの半年間ぐらいもりもりゴリゴリやってきて、
だいぶ自分なりのやり方が見つかってきたんで、やり方のプロセスをどうするっていうよりは、
やっぱりもうちょっと大きな問題をちゃんと取り組むっていうのを、
今やってるんですけど、それをやりきりたいなと思ってはいて、
Helferoのデータ活用、いろいろとなかなかに問題があったりとか、
いろんなリーズはあるんだけど、その引きにすべて答えられているような状況ではないし、
事業上ちょっとやらなきゃいけないこととかっていうのも見えてきたりはしているんで、
もう少し上のれ、もう少し地道に問題を向き合って、
ちゃんとそれを解いて、事業上のインパクトをやっていくっていうのはやりたい。
抽象的ですけどね。
人々が抱えている問題をしっかり理解をしたいなっていうのはやっぱり思ってますね。
データ活用の話だと、社内中あらゆるところにセークホルダーがいて、
人々はいろいろな問題を抱えているわけですよ。
マーケティング部の方々とか、あるいはカスタマーサクセスの方々とか、
ソリューションデザイン部の方々とか、いろいろな方が全く異なる問題をそれぞれ抱えていて、
その問題は僕は全てを把握できているわけじゃないんですよ。
やっぱりちゃんと人の話を聞いて、問題を理解してできることをどんどん倒して、
事業上のKPIに効かせていくっていうのをやりたいですね。
ヘルフフィールがプロダクトとして成功するのが一番なので、
いろんなことなんです。
いいですね、ありがとうございます。
最後に聞いていただいている方に一言、もしかしたら入社を検討しているとか、
あるいは二人の話を聞いて入社したくなる人もいるかもしれないですし、
そういうの関係なく聞いていただいている人もいるかもしれないので、
ぜひ一言ずつメッセージをいただければと思います。
そらちぃさんからこの流れでいいですか、一言。
アンソロピックとかオープンAIがいろんな素晴らしいものを出してはくれてはいますが、
そういうプロバイダーが今我々が抱えている問題を直接解決してくれるわけじゃない。
目の前に抱えている問題に対応できるのは今現実に向かっている我々だけなので、
やっぱりベストを尽くしていきたいですね、という感じで。
ありがとうございます。
いろいろコメンテーターとか僕らが変なこと言ってますけど、
やっぱり現実の問題を変えられるのは今これを聞いているあなただけですというところ。
いい流れ来ましたね。分かりました、ありがとうございます。
ではしょうかいさんからもお願いします。
いい話で言われてしまった。
現実の問題を変えれますね。
実際会社のプロダクトとしてもたくさんデータを蓄積するようなプロダクトと、
あとそれを実社会で結構ですね、
ウェブサービス上だけじゃなくて最近はコールセンターだとか、
いろいろなインフラ系の会社とか、電力とか建設とか、
そういうところでも使われたりとかし始めているので、
いろいろ知識をマネジメントして、
現実社会を動かしていくようなプロダクトが作れる会社なので、
ぜひ応募してくださいというシーンですね。
そういうシーンです。
というわけで、
今日もスペシャルなゲストということで、
社内のクロードコード、トークン利用料トップ3、
部内トップ2のしょうかいさんとそらちさんにお越しいただきました。
お二人どうもありがとうございました。
ありがとうございました。
今出川FMは過去の全エピソードもSpotifyやApple Musicなどでお聴きいただけます。
ぜひ感想もお待ちしています。
Xでハッシュタグ、シャープ今出川FMで投稿してください。
ではまた次回もお楽しみに。