開発会社がAIを試し始めた時期
HOW!HOW!HOW!です。この番組は、地方の開発会社とコンサル会社が協力して作ったAI企業で、AI駆動開発とAI駆動系のワクワク、ドキドキな経験談、実践談をお届けする番組です。
お届けするのは、株式会社Method Hub共同創業の鶴と、りょうです。二人でお届けします。よろしくお願いします。
よろしくお願いします。
我々、疲れております。
ちょっと疲れてましたよ、さっき。
Aのトーン二段階。
何か思った?
いやー、ちょっとね、我々お互い過境で、まず40オーバー、抱えてる仕事が今日、金曜日夜。
やっぱ気づきました?さっき気合い緩かったよね。
頭一生懸命回しながら聞こうと思いながら言ったんですけど、なんかかかんなかったよね、さっき。かかってなかったよね。
ダメダメ。ダメですよ。
いや、まあそうね。まだまだ僕ら慣れておりませんので、ポッドキャスト。
そうですね。
それからね、面白くなっていければいいなと。
さて、今日はどんな話をしましょうかということで。
今度は僕がですね、先週はどっちかというとりょうさんが僕に、どんどんAIが進化する中でエンジニアリング始めたけど、お前はどうしてたんだっていう話を、ゆるふわにやらせていただきました。
ゆるふわにね。
今日は逆で、もともとずっと開発会社として、人が開発するっていうことをずっとやってたパロスが、どんどんAIが出ていく中で、
仕事の仕方ってどう変わっていったのとか、あるいは社内で反発があったとか、危なくねえかみたいな。
いやいや、ポテンシャルあるでしょって推進派がいたりとか。
その辺のリアルみたいなのをインタビュー形式でお伺いするということをお届けしたい。
ぜひぜひ。よろしくお願いします。これ熱いですよ、俺は。
ジム予約システムで見えたAIの可能性
ということで、さっき言ったやつ。
1回目か2回目くらいの配信で言いましたけども、2年前の6月にソネット3.5が出て、前後忘れましたけどVZeroでフロントエンドもAIで書けるようになった。
僕はりょうさんと喋ってて、りょうさんが興奮してて、りょうさんが自分でフロントをAI使って書いてる、みたいなのは見てましたけど。
当時、社員さんたちはどれくらいAI使ってた?
その当時は、僕とあと一人かな、一人か二人くらいでしたね。
実際業務に使ってた?
業務はゼロですよ。ゼロゼロ。
触ってみてるって感じ?
ですね。まだポテンシャルどんなもんかなっていうところを試してる段階で、業務はまだゼロでしたね。
それは、試そうぜっていう号令をその二人に出して、一緒にやった?
そうですね。それこそ推進してほしい人がいて、AIというよりは技術で先客チームみたいなのをもともと作ってたんですよ。
やっぱ新しい技術に我々エンジニアなんでチャレンジしないといけないっていうのがあって。
AIのそれこそソネットが来た時に、ちょっとこれ一緒使ってっていうので試させてたのがもう一人いたかなぐらいの時でした。
まだ全然その業務に当てれるかどうか、それがそのポテンシャルがどんなものかどうかっていうのも試してた感じでしたね。
なるほどね。それが数ヶ月?
そうですね。
ポケットで実際うちのジムの仕組み作ったんですよ。
そう、あれがだから2年ぐらい前ですよね。確かその時は。
1年半ぐらい前かな。
僕V-ZEROで、それこそシステム、自分の中でどんなもんかって試してるのが2年前の正月だったんですよ。
大変。
インスフルエンザになりながらV-ZERO叩きまくってたんで、そう覚えてるんですよ。
それである程度ポテンシャルが分かって、多分ジムのシステムに行ったんで、2年、2020、4年の初頭ぐらい。
じゃあ、あの時はバックエンドは手で描いた?
手で描いた。
あとね、ジムのシステムはほぼバックエンドなかったんですよ、あの時は。
ほぼフロントと連携だけだったから、カレンダーとかの連携だけだったんで、まだ全然そんなバックエンドはっていう感じだったんですよね。
だから、ちょっと今リスナーさんを置いて聞かせたんですけど。
大丈夫、またやってもらって。
AIをシステム開発会社が日常の業務に使えるのかっていう、
ポテンシャルはめちゃくちゃありそうなんだが、いきなり実案件でやるの怖いっていうのはあって、仲いいから。
僕ジムもやっていて、そのジムの体験予約をしてくださいお客様に、
うちのジムのスタッフのGoogleカレンダーの空きを連動させた予約システムみたいなのを、
AIドリブンで作ってみようというのをやってくださったんですよね。
いいのできましたよね、いきなり。
割りかしいいのができて。
結構瞬殺だった。
あれはたぶん2週間くらいで作ったんですよね。
そもそもなんとかシステムとつくものって月単位なんですよ、できるとしても。
何週間とかじゃできるなんて、僕らは思ってなかった。
常識的にはないね。
ちっちゃくてもなかなかこの、例えば1ヶ月で作るみたいなものって、
ツールとかだったらあるけど、システムを何週間で作るっていう感覚はその当時はまだ僕の中。
やっぱり結構自分の中でもいい経験だったし。
その時は何を使ったんですか、クロードの?
クロードだったと思うんですけど、その時何を?モデルってことよね。
モデルとかブラウザ型なのかとか。
僕は少なくともブラウザでコードを出させてアーキファクトを移植してたんだけど、
美容師が何を使ってたのかな、クロードコードでも使ってたのかな、ちょっとそこは覚えてないけども。
出してもらったソースを、覚えてるのは、ちょっと話変わっちゃうんですけど、
クロードとかが出したソースを、今のうちのソースと当てたんですよ。
どのくらい当てたって言ってるのは、我々の品質レベル、出してもいいっていう品質レベルと、
クロードが出してるソースの品質レベルってどうなん?っていう検証の仕方をして、
どういう分け方をしてとか、ソース上の分け方をしてとか、どういうふうに組まれてるかっていうのを、
そのちっちゃいシステムで試してみたんですよね。
要は、例えば本があったとして、小説があったとして、中身は全然違う物語なんだけど、
その書き方の遠まなとして、いつも手で書いてた小説と、今回は絵を描いた小説が、
開業ってちゃんと見やすい形でできてるよねとか、デスマス調と大言止めが混じっちゃってないよねとか。
そういうのを検証して、その時にそのメンバーが、
いやこれいけますよっていうふうに、ちゃんと育てれば大丈夫だと思いますって言って、
これやっぱそこまで来てるんだっていうのが衝撃でしたね。
なるほどね。
AI開発の品質とテストの壁
で、そっからは、そのAIドリブンのSI的なことを、システム開発の受託を進めてったんですか?
そうですね。まず、そういうことができると分かりました。
最初僕らがやったのは、そのAI使って開発するよということを認めてくれるお客さんに対して、
価格をだいぶ抑えていったんです。要するに両者リスクは許容して、
かつあんまりリスクじゃないシステムに対して検証しよう。
検証っていうか、実際はお客さんに物を貯めるのでちゃんと作るんですけども、
要するにWin-Winの環境でAIと付き合っていこうというお客さんが、たまたま理解してくださるお客さんがいて、
ちゃんと今の率直なディスクとか、我々今こういうことしてこういうことしてますみたいなのもちゃんと話した上でやらせてもらって、
で、やっぱりですね、勉強とか検証と業務って違うんですもんね、そこは。
で、そこの差はさっき80点まで取れるかの世界と僕らも同じようにぶつかったんです。
で、やっぱそれなりのものができるんですよ、ローカルでは。
ローカルって言ってるのは、パソコンの最初の我々システムを試すときに、一番最初からサーバーにアップするんじゃなくて、
ある程度の強度でローカルで確認。
ローカルサーバーで動かす。
そうそう、時間までかけてバーってやるんですけど、そこではそれなりに動くから、なんかできたふうに僕らも思ってるんですよね。
でも実際にサーバー上げるときだったり、その手前の本当にこれが正しいかってやっぱりテストは人でしないといけないと思ってたので、
要するにテストで救おうと思ったんですよ、僕らは結構。
コードは書けるし、ソースもそれなりに見るんだが、ちゃんとした挙動をするかテストで拾う。
そこはもう今まで通りにテストしてるっていうのでやっててやったんですけど、やっぱりそこでだいぶ、その当時のモデルでは、
動いが見つかる。
そうそうそうそう。この辺実装できてないじゃんとか、みたいなものがやっぱりあって、それなりに動いてはいるんだが、
細かいとことか、イレギュラーケースとかをやっていくと、やっぱりまだまだ考慮しないといけないことがあったし、
お互いですね、AIのモデル的に追いついてないところもあったし、
僕らの知りみたいなものもやっぱり悪いというか、足りてないなというふうに思いましたね、その当時は。
ウォーターフォールとアジャイルの違い
テストってどうやってやってるんですか、開発大臣。
テストね、テストって実言うと何パターンかのテストがあるんですよ。
ウェブシステムとかだとなかなか難しいところはあるんですけど。
僕が知ってる限りで言うと単体テスト。
そうそうそうそう。
E2Eテスト、あるじゃないですか、モンキーテストとか。
基本的には僕らって単体テストっていう機能レベルのテストをやっていって、
その次に結合テストっていって、その機能感が正しくつながるかっていうテストをやっていって、
その次にシステムテストっていう、システム全体として正しく動作するかみたいなものを細かいところから徐々に膨らましていってやっていくんですよ。
僕ら開発会社って開発手法っていうものがあるんですよ。
最近よく聞くのはアジャイル開発みたいなものがあって、
それってどっちかって言ったら、作ってその場でテストして渡していく、細かい細工でやっていくような感じのもので。
もう一つそのウォーターフォールっていうものがあって、それはどっちかっていうと要件をきちっと決めて、
ウォーターフォールってこういう曲線を描くんですよ。
要件があったらその要件に対して運用テストがあって、このテストとか紐づくんですよ。
詳細設計があったらこのテストとか紐づくみたいな。
だからある程度ここが決まったらテストのパターンが決まるぐらい最初にきっちり決めてやり方があるんですけど、
今回のAI開発はやっぱりそこは合わないんですよね。
そのやり方はなかなか合わない。
ものができるじゃないですか。要件どおりに作ってものができるじゃないですか。
どっちかっていうとトライアンドエラーに向いてるんですよね。
作って、動かして、あ、違う違う、みたいなものが向いてて。
AIのポテンシャルを生かすには、ある程度やりたいことをインプットした、それをちゃんと渡して、
出たものを見せて、そしてまた戻してっていう。
このサイクルを作るほうが、AIって作るの早いから。
結果早い。
結果早いから。
ウォーターフォール型でもできなくはないんですか。
できなくはない。
スピードがそんなに上がらない。
そうですね。やっぱりウォーターフォールってどっちかっていうと最初に要件を詰めるところにものすごく力をかけるんで、
製造はどっちかっていうとその要件が固まったら、そこから先の製造が動かないことが多いんですよ。
ウォーターフォール型の開発って。
動かない。
動かないっていうのは、なんて言えばいいかな。
基本的に要件定義で決まったものを開発は作りますという考え方なんですよね。
要件定義からそれったり、
なんていうか、要件定義で決めます。
開発します。
開発してものを収めます。
お客さんが見るのは本当に最終的に決めた要件と全部作った後にテストまで全部した後にお客さん見ることが多いんですよ。
一度要件を決めると動かないっていうのは、要件が変わんないってことですか?
そうそう。そっから先に進んでお客さんに届くまでにそれなりに時間がかかるから、
お客さんが蓋を開けた時には、あれ?イメージと違うみたいなことが結構多かったりする。
結構長いレンジがかけるんですよ。
でもAIってそんなことせずに、今ここで決めたものを見せれるというこのポテンシャルを生かすんだったら、
アジャイルとか、そっちの開発の方が適してるっていう感じですね。
だからウォーターホール型の運用上の弱点を補いながらやるやり方がアジャイル。
でもアジャイルはアジャイルで弱点があったんだから、
AIによってそれも解消できるよっていうか。
そうですね。
アジャイルはアジャイルで、僕がしたてるっていうファッションテックでクラウドサービス作ってた時は、
ゴールポストが動き続ける辛さがあって。
なるほどね。これ難しいとこですね。
だからウォーターホールのいいところは用件が最初にちゃんと握れることだよね。
アジャイルは正直コストが見えない時がありますよね、アジャイルってね。
ゴールポストが低いっちゃうからね。
それは確かにあるっす。
結果なんか改造されたエクセルみたいな、結局こんなはずじゃなかったみたいなのが出来上がるという意味ではウォーターホールと一緒かもしれない。
身も蓋もないことを言うと、それを管理する人がちゃんとしてればどっちも上手くいくんですけど。
なるほどね。
そうそう。どっちが悪いという話ではなくて、あくまでも開発手法とお客さんとか、
例えばAIだったらこっちの方が向いてそうだなぐらいの感覚で聞いてもらえればいいと思うんですけど。
で、それはテストしてみたら、いっぱい人間が開在しないとリリースまで持っていけなかった。
そうですね。
やっぱそのデスマス調が細かいところで結構ダメだったとかですか?
うーん、えっと、何でしょうね。細かいパターンとか、何て言えばいいんだろうな。
なんかこう、正常ケースはそれなりに動くんですよ。
先週の話と一緒。
そうそう。正常ケースはそれなりに動いて、細いこと言うとOKみたいなものを作ってくるんですよね。
けど、やっぱり実際にお客さんの運用に耐えうるような、このケースはあのケースだみたいなところまでは、やっぱりその当時はできてなかったって感じかな。
AIが悪いというよりかは、指示の仕方が悪かったんですよ。
結構ポーンとボールを投げちゃってたから。
抽象度高めなボールだけ投げちゃってた。
そうそうそうそうそうそう。
だからどっちかって言ったら、指示丸投げ状態でやってた感じ。
で、AI自体がそれをいいように訳して作ってるというものなんで、ある程度に似たりなものは作るんだが、細かくやっていくと、いやそういう動きは違うけどな、みたいなものがたくさんあったって感じですかね。
AIを丸投げしないための開発の型
結果そのプロジェクトは、パロス的には黒字でいけた?
実際に自分たちが開発するのとは変わらないぐらい。
あ、そうなんだ。
やっぱり高難で拾ったし、最後のテストで拾ったのと、テストの微妙な修正は手でした方が早かった、その当時は。
その細かな修正をやった時に、結局一個一個テストを潰していく時に、そのテストの潰し方をAIにまだ任せきれなかったんですよ。
どこまでこれ、波及することになる、みたいな。
この揺れが解消できなかった、その時は。
で、結果、自分らで最初からやるのとは変わらない。
あんまり変わらないやつ。そうそう。
手間かけたな、みたいな。
手間かけましたね。
それがだから一年前ぐらい、一年半前ぐらい。
一年半ぐらい前ですかね。
そっからまた、どういう振り返りで、どういうPDCAもあって、次のアンケートがあるんですか。
ありますあります。
やっぱりですね、無邪気にAIに丸投げしちゃダメだなっていう風になったんですよ。
で、それは何かというと、ある程度、その当時はXとか、その辺のもやっぱりありましたけど、
AI駆動型開発っていう単語が出始めた時期。
それはちゃんとAIにやっちゃダメなこととか、
AI側もやっちゃダメなことがあったり、
我々が支持する時もちゃんとステップをやって支持するやり方があったり、
各社各々の型を作り始めたんですね。
で、僕らは最初にフォルダ構成とか、
この場合はこういう構成でソースを当て込んでいくみたいな型を作って、
その型に合わせてソースを埋め込んでいくっていうような基本スタイルがあって、
その中で今度はクロードコードの使い方で、
フックがあったり、クロードのMDがあったり、
ガードレール設計みたいなのをやっぱりだいぶ進めましたね。
なるほど。だから、プロンプトエンジニアリングからハーネスエンジニアリングで、
そうですね。
トレンドが映ってた頃にハーネスを作ってた。
そうそうそうそう。
AIエージェントの役割分担とレビュー
やっぱりね、ちょっと話戻るとですね、
僕最初、AIに一回プロジェクト大変でしたっていう風になった後に、
最初何をしようとしたかって言ったら、再現性を高めようと思ったんですよ。
再現性って何かって言ったら、
2回支持して2回とも同じ結果が得られるぐらいの精度を絞りたかった。
ソースコードがある程度、同じようなソースが出せるようにするにはどうすればいいの?
なるほどね。LLMって揺れますもんね。
そうそうそうそう。
同じこと言ってもね。
だからその再現性を取るにはというので型を追い込もうとしたんですよ。
なるほどなるほど。
でもやっぱりそれってどうしても無理だっていうことが分かって、
どんなに指示文を細かく書いていっても、
こういうことしてこうこうこうって書いてたとしても、
やっぱりそこからアウトプットされるものは揺れるんですよ。
へー。
し、プロジェクトが大きくなればなるほど、そんなのセールできんなという風に思って。
だからもうそこは再現性ではなく、
AIに組ませる前提の何をしていい、何をしちゃダメみたいなトータルの設計がいるなっていうふうに、
僕自身も体感したし、その当時のトレンドもそうだった。
なのでさっき言ったハーネスのように、
例えばAPIキーっていうクロードのキーとかですね、
その出しちゃいけない情報みたいなものを簡単に出したらフックで止めるとか、
あとは個人情報を出さないようにするとか、みたいなガードレールもそうだし、
さっき言ったテスト駆動型開発ってあるじゃないですか。
あれも結構実際に奥が深くて。
何かといったらですね、
AIってこのテストを通すために開発してって言うとするじゃないですか。
そしたらAIはテストを通すことをゴールにするんですよ。
ってことは何が起こるかって言ったら、
機能ではなくテストを通すことができるプログラムを買ったんですよ。
なるほどね。
分かります?
はい、分かります。
ということは期待値通りにならないんですよ。
なのでそこは何を分けないといけないかっていうと、
ちょっと俺も今思い出したから喋ってるんだけど。
中学校の時の中間テストと同じだね。
本質的には世の中の理を理解し、
イケてる大人になるということが勉強の目的なんだが、
中間テストで良い点数を取るための位置預けみたいな。
そうそうそうそう。
ここさえ通せば人間もOKって言うだろうみたいなことをやっぱりあいつら使用するんですよ。
同じだよね。
そうそうそうそう。
だからそこはちゃんと、
AIの中でも単純にテストを見て実装する人と、
要件を見る人っていうのをちゃんと役割を分けてやることによって、
情報を全部見せないんですよ、エージェントに。
という分け方をすることによって、
両者からちゃんと、この人はテストをちゃんと通すということにコミットする人、
この人は要件通りに組むということにコミットする人、みたいなレビューをちゃんと通すことによって、
ある程度品質を高めたりみたいなことをすることが大事。
なるほどね。
そう、だし、ちゃんとこう、なんだろうな、
型を組みます、AIが組みますってなったら、
その組んだ結果のソースレビューをちゃんと必ず入れるようにする。
そのソースレビューを入れるときに、
セキュリティ的な脆弱性がないかみたいなのを別途定義するんですよ。
こういうことが勝手に書かれてないよね、みたいなこととかを別に定義して、
あるAIが組んだものに対して、
そのセキュリティのレビューをするAIがそのチェックをする。
要するにもうAIのエージェントの中で分けて、役割を分けて、
その役割に対してそのAIがコミットすることによって、
品質を高めていくみたいな型をちゃんと作っていくと、
再現性というよりかは、ある程度信頼できる行動が吐き出せるんですね。
なので、どちらかがそういうことに時間をかけるようになりましたね、僕らは。
なるほど。
そこの型をどう作っていくかと、どう育てていくか。
一回失敗というと、結局人がやるのと同じくらいコースをかけちゃったねっていうのがあるから、
余計大事だなと思ってそれに。
そうそうそうそう。
結局コントロールできないから。
なかなか大変だった。
それが1年前ぐらい?
そうですね、1年前ぐらいかな。
既存案件とAI受注の現在地
で、そこからまたAI受注とかはしてるんですか?
今は結構お話いただいて、受注するようになりましたね。
なるほど。
で、やっぱり当時の人がやるのと同じくらいだったなみたいなのはもう起きず?
いや、もうだいぶ減りました。
品質もやっぱり上がるし、
ここの要件漏れてます?みたいなことはやっぱりだいぶ減りましたね。
言ってもまだなくはないんですよ。
なので今時点では、人間がちゃんと見てテストするっていうのはまだ置いてはいるんだが、
そもそも論にはもう今なってないです。
だいぶやっぱり構成的にも短縮できるぐらいAIの精度は上がってきてると思います。
僕らの精度も上がってきてる。その使い方の精度として。
なるほど。
素晴らしいですね。
で、とはいえ既存のクライアントさん、もともとあったクライアントワーク系もいっぱいあるじゃないですか。
そこもAI使うようになってるんですか?
僕らはそこは使ってないです。
それはクライアントがもう禁止してるとか?
そうですね。クライアント作品の性質ももちろんよるんですけども、
やっぱり僕らって最終的に収めるのってソースコード、お客さんのものになるので、
これまでの既存のやり方を勝手になかなか変えられないのと、
脈々と受け継がれてきたソースコードがあるわけですよ。
僕らが起こす新しいソースだったら、それに対して適応はしやすいんだが、
これまでのいろんなプロジェクトの考え方で作られたソースコードに対して適応するってなったら、
まあそれはそれでいろんなハーフが出てくるんで。
現時点では我々から使うことはないんですけども、
でもやっぱりクライアントさん先でもAIをすることを前提とした話がどんどん出てきてますね。
AI時代のシステム会社の役割
じゃあ追加で聞きたいんですけど、今後の開発会社はどうなっていきそうですか?
もう新規のお客さんからどんどんAI前提の感じで受注していくわけですか?
まずもう一個言いづらいかもしれないけど、お客さんへの恩恵はやっぱりあるんですか?
価格という面とか後期という面って。
あります。
じゃあやっぱり今まで高くて手出せなかった企業さんでもSIができる。
できますね。
オリジナルシャッフルが作れるように。
今僕はやっぱり今までそれこそおっしゃってたように、
これまでシステム投資ができなかったお客さんとかに、
そういうお客さんってやっぱりね、既存のパッケージとかそういうものを使って、
どっちかって言ったらシステムに運用を合わせるということをやってきた。
やらざるを得なかった。
やらざるを得なかった。でもそれ結構大変なんですよ。
しかもずっとそれこそ紙とかでやってきた方々が、
そのシステムに合わせるって相当現場ハレーションも大きいし、
っていうところがあられるけどシステム投資ができないみたいな会社さんも、
今は本当にシステム作れる時代になったんで、
そこはですね僕らやりたいんですよ。
そういうお客さんに対してもできるだけそのお客さんの運用に合ったシステムが作れる。
実際おいしいんですか?
やってる仕事、これまでやってきた仕事って一発何千万とか下手すると億とか、
5年掛かりとか、そういうでかい金額動く仕事がSIで多かったわけじゃないですか。
そこに対して3ヶ月の後期で500万みたいな、3桁万円の仕事っていうのは、
入り口の要件と出口の畳むところはあんまり変わらないくらい手間がかかったら、
間が早いっていうだけで。
まあそうですね。
結構おいしいのかな?どうなんだろうあれ。
どうなんやろうな。
もっとそれぐらいの粒金のやつガンガン増やしたいぜって感じなのか。
迷ってですね、そこは。
これってやっぱどっちかっつったら我々がどういうビジネスをしていくかみたいなことにはなると思うんですけど、
やっぱ3ヶ月で何百万みたいな世界って、どうしてもやっぱ我々からしても剥離、多倍になるわけじゃないですか。
でかつ、入れてるプロジェクトが多い分、見る責任範囲が広がるっていう。
なんかプレッシャーは同じぐらいあるじゃないか。
そうそうそうそう。
だから一つはやっぱこのやり方って正解なんかなっていう。
この話が使えるかどうかわかんないけど、
このやり方が正解なんかなというふうな思いは半分あれど。
一旦チックコンベに出るって感じ。
自分の中ではどっちかって言ったら、今までシステムが届かなかったところにシステムを届けるということに、
自分自身の喜びもやっぱある。
だから四方よしのビジョンがあられますよね。
ポリシーがあられますよね。
やっぱですね、本当に現場さん、現場現場のコアの課題みたいなものが我々からしても見えてくるんですよ。
だから価格としてはそんなにね、これまでのシステム開発に比べたらそんなにないかもしれないが、
僕らとしてはアプローチは二つで、できるだけそのシステムに係る僕らの費用をどんだけ落とせるかという勝負をしていくのと、
やっぱりもう一個はちゃんと現場現場の困っていることのコンテクストをちゃんと正しく持ち帰れるか。
そこの持ち帰ったところを我々のプロダクトとか、次のサービスの方に落とし込めるかみたいなものが一つのテーマだと思っています。
あとは、どうしても地方のシステム会社というのは、これまではどちらかというと、
ベンダーさんとかと一緒に仕事をさせてもらうことが多くて、今でもやっぱりそういうのは多いんですけど、
一重系の会社から仕事を。
こういうものを作りたいからって言って、大工的な仕事がやっぱりまだまだ多いと思うんですよ、いろんなシステム会社さんって。
そうなった時に、やっぱりそこのこういうものを作ってっていうのは、ある種もうAIでできるようになってきてるわけですよ。
なので僕らはいかにお客さんの近く、お客さんが本当に困っているそのペインポイントが生まれる場所に存在するかが、
僕はシステム会社の次のテーマだと思ってて、そこからいろんな課題解決をその場でやっていくみたいなものにものすごく価値があると思うんですよ。
それがもしかしたらソリューションなのかもしれないし、オーダーメイドの開発なのかもしれないけど、
そのAIエージェントを実装してあげることなのかもしれないし、いろんな解決方法があると思うんですよね。
なるほどね。その目的、お客さんが持っている課題とか目的に対しての手段って開発だけじゃないのね。
そうですそうですそうです。やっぱりそういうところにこれまでなかなか携わる機械って、
大手ベンダーさんとかは違うんでしょうけど、システム会社ってなかなかないんですよね。
だから僕らやっぱりそういうところにちゃんとリーチできるようにはなっていきたいし、そういうふうにリーチできるものだと思ってます。
なので今はそういうふうにそこをやってる。
確かに。そこが一番いいわ。
なんかちっこい案件たくさんやるって大変やなというよりは、これをきっかけに入り込んでいって、
より高い課題とか別のアプローチとかで新しい生涯作っていくとかっていうほうが楽しいですね。
楽しいですね。
そしてあれなんですよね。正直言って、僕らみたいな業態、システムを作るということだけを先輩特許にするのは、
やっぱりもう経験されてると思いますけど、通用しなくなると思うんですよ。
みんな分かってきてることだから。
だからやっぱり僕ら自身も、何かチャレンジだったり変えていくというところに持っていかないといけない。
と思うので、やっぱり一歩目としてはお客さんの近くに近づいていく。
できれば我々のほうは、ビジネスを生み出せる側、作る側のほうにやっていかないといけないなって。
確かに。だからお互いの領域が被ってる領域が増えてきてる感覚はあるかもね。
そうですね。それは大事かなと思います。
そういう意味では楽しみってことじゃない?
うん。楽しいと思いますね。
疲れてるだけの今日。
今日はたまたま疲れてるだけで、本当はもっとワクワクして語れるテーマなんだけど、
たまたま疲れてるだけで、前半のことちゃんと正しいこと言ってたのかなって。
いろんなところから引き出し出して、と思いながら話してましたけど、そんな感じですかね。
でもリアルな追体験でしたね。AIがどんどん進化してくる中で、開発会社としてどう立ち回ってきたのかっていう。
実は俺、もう1時間くらいから掘りたいんだけど、ちょっともう今飽きてきてると思う。
確かにね。
このテーマは確かに。
終わりましょうか。
ということで、今週も良きハウハウハウでございました。
お後がよろしいようで、ということでお届けしたのは、
メソッドアップ、共同代表の鶴と、りょうでした。
ありがとうございました。