今日のテーマとしてはですね、良いも悪いもなくAIを取り入れていくしかないっていうテーマですね。
他の業界はいざしながらですね、このプログラム開発の会社であればですね、どうしてもAIを使わずにはいられないですよね。
ただ、他の会社の社長さんのFacebookとかNexとかの投稿を見たりすると、結構苦労してるところもあって。
とにかくですね、今ずっと刀とか弓矢で戦争してたところにですね、ボコッと大量の鉄砲を渡されたという感じなんですよね。
なのでこれも使っていくしかないっていう気がしますね。
やっぱり使わないと上手くならないし、否定するっていうね、武田信玄みたいなですね、牙剤を作ってですね、やっていくっていう方法もあるかもしれんですけども、
なかなか最後はやっぱり負けてしまいますよね。そうなんですよね。
私も今回で4つ目かな、アプリAIを使って作ったのは。そうするとですね、かなりもう分かってきてですね。
これでも絶対分かってないですよ。今の段階では結構分かってる気がしてですね。
あれあるじゃないですか、音楽のですね、AIのシステムがあって、SUNOっていうやつ、あれそこにたくさんすごい音楽が並んでるんですよね。
こんなのどうやって作るの?みたいな気がするんですけど、あれ相当だからプロの作曲家とかがですね、プロンプトをすごい工夫したりして、
それで途中で変化を入れたり、変調したりですね、やるわけですよね。本当に完全なアメリカのポップスみたいなのが出来上がるわけですよね。
すごい女性のボーカルが切なく歌ってるみたいなね。それと同じくらいのことを私も業務システムに関してはできてきたかなと思いますよ。
なのでね、この話どうなんですかね。皆さん開発者ばっかりじゃないと思うんですけど聞いてる人はですね、興味あるのかわからないですけども、
今日はそういう話にしますかね。開発者向きの話をしますと、基本的にはプロンプト自体はですね、人間が書くのは難しいっていう風に私は思ってきていて、
みんなプロンプトを書きたいみたいなね。このプロンプトを使うとできるよみたいなものが出回ったりしてますけども、そういうレベルではなくてですね、
やっぱりAIと話をして仕様をきっちり詰めて、それをですね、仕様紙にまとめさせて、こういう仕様書で作りましょうということ、この政策をですね、AIと詰めて、
それでそこをもとにしてAIにプロンプトを書かせると、かなりの長文になりますよ。600文字くらいになるんじゃないですかね。これを過不足なくですね、人間が書くのは多分不可能。
SQLとかですね、正規公文とかですね、ああいうのをですね、手で書いているようなものでして、それ無理だと思うんですよ。だからプロンプトはAIに書かせると、それを別の画像生成のシステムとかコーディングのCursor(カーソル)とかのIDに読ませると、
で生成されるみたいな。だから私は最近は常にChatGPTとお話しながら仕様をまとめさせて、それをドキュメントに落として、そのドキュメントをですね、Cursor(カーソル)の仕様書置き場があるのでそこに置いて、
もちろん仕様書はですね、Excelとかのスペードシートで作っちゃうともうどうしようもなくなっちゃうんで、マークダウンで作らせて、それで仕様書置き場にですね、開発のリソースと同じところにですね、仕様書置き場を置いて、常にCursor(カーソル)のAIにはそれを読ませると、読んでもらうと。
プロンプトも全部ですね、保存しておくわけですね。同じ開発のリソースの、プログラムのリソースと同じところに置いておいて、この画像、画面のですね、この画像はどういうプロンプトを食べさせてできたものなのかっていうのを保存しておかないといけないですね。
それを保存しておかないと再現性がなくなっちゃうんですよね、その画面にですね。やっぱり開発って一回できたら良かった嬉しいじゃなくて、毎回同じことが再現できないといけないですからね。
多少はずれちゃいますけど、AIが作るとですね。だけど、極力同じことが再現できるという状態を残しておかないといけないので、仕様書とプロンプトと、画面だったら画面に出てきた画面と、それも全部プログラムと同じところにですね、プログラムソフトと同じところに置いておいて、Gitで管理するという感じにしてますね。
そういうふうにしておかないと、後から入った人がこれどうやって作ったのか分からなくなってしまうということがあります。画面遷移とかもですね、全部AIに作らせて、それも全部マークラウンで作らせると。
あとDSLとか言うので、言葉で書かせると。ちょっと前まではね、私も必死でExcelで作ってましたけども、それで破綻しますからね。やっぱりバージョン管理できないし、解釈がですね、AIによって変わってしまうので、最近はDSLを使って作るというふうにしてますね。
そんな感じです。でね、まだちょっと時間ありますかね。
Xの投稿を見たらですね、こんなのがあってですね、どういう話があったかというと、生成AIを使ってですね、うちの会社も開発するようになって、コードがですね、2倍の速さで書けるようになったと。
2倍ってことはないと思うんですよね。5倍ぐらい速いんですけどね。なんですけども、開発全体の速度は遅くなっているというのがありましたね。
で、書くのは書くけども、どうもそれがみんな理解できないと。内容がね。コードの中身が理解できないので直そうと思ってもなかなか直せないと。
自分で書いたはずのコードがですね、理解できなくて、それで修正する箇所がわからないという風があったときにですね。
なのでね、みんな頑張ってちゃんとコードを理解できるように頑張りましょうと。レビューの人も疲弊してすると思いますけども、頑張りましょうみたいなね。
そんな結論になっていたんですよね。要はあれですね、もうちょっと技術力をしっかり高めて、AIにしか理解できないコードを許すなみたいなことを言ったんですけど。
気持ちはわからなくもないんですけど、私としては途中まではすごい賛成なんですけど、最後の結論はそうじゃないだろうなという風には思いますね。
あれですよ、我々もほら、もともとのC言語とかで画面から書いた時代に比べてどんどんプログラムは難しくなっていって、内部で何やってるかわからないという状況になってきましたし。
だんだんコードはですね、フレームワークとか使ってもそうですけども、だんだんコードは理解できなくなっていくんですよね。理解しなくても良くなっていくんですよ。
このAIが発達してこの開発現場に登場したことによってですね、また大きくそれが1ランク上のレベルで難しくなってしまったと。
読めますよ読めばね。読めば読めるんですけど、読んだとてですよ。それよりもですね、やるべき方向性はそうじゃなくて、仕様書をしっかり出させるってことですね。
今までの開発スタイルって仕様書をミニマムにしようっていうのがね、うちの会社もそうですよ。
それは当たり前だったんですけど、それをしないと、仕様書はAIが勝手に書いてくれるんで、こちらは要件をしっかり伝えて、要件はさすがに書いてあるしかないんですけども、
それもAIに手伝ってもらうんですけど、要件をしっかり伝えて、それを理解してできたかどうかをですね、ちゃんと仕様書という形でAIに吐き出させて、
それを開発者全体、あるいは営業とかですね、あるいは場合によってはですね、お客さんの担当者も含めて仕様書を読み合わせして、理解すると。間違いがないからチェックするというのが大事ですね。
実際にそれを元にして実装させて、動きを見て、これなんかおかしいんじゃない?というときは、その仕様書に立ち替えると。
仕様書と矛盾してこれ不具合じゃん?これが実現できてないじゃん?みたいなね、言えばいいわけで、仕様なのかどうなのかちょっとわかんないなみたいなね、パターンがよくわかんないなみたいな感じのときは、
今の実装の仕様ですね、実装仕様をまた出させて、ドキュメントに出させてですね、それをやっぱりみんなでチェックすると。
当初の仕様書と実装されたものの仕様がこれ違うじゃん?っていう、自然言語でチェックすると。
これが矛盾してるよということがあれば、またAIに言って直させると。そういうフローですね。
これまでと大きく違うのはですね、これまでの開発と大きく違うのは、AIのコインスピードというのはもちろんあるんですけども、それよりも我々の方が変わらなきゃいけないのは、仕様書を出すというフローですね。
仕様書を出させてはチェックするということをやっていかないと、いいシステム、ちゃんとまともなシステムできないという気がしますよ。