新年の開発具合
ふてはなDM。この番組は全国の悩める若きビジネスマンに向けて、わたくしシマートルが本音で語る直球メッセージをお送りします。
はい、新年一括目ですね。2026年ですね。始まりましたね。
今年の年末年始はどうでしたかね。非常に天気がなんか良かった気がしますね。
といっても異常な暖かさというよりもピリッと寒いんだけど晴れてるといった感じだった気がしますね。
相変わらず私の方は1月の1日2日はね、家の親戚の集まりとかあったんで、それは行くんですけど、その後長い休みがあったので、
相変わらず仕事、やっぱり開発を進めていたわけですね。去年はずっとクライアントワークの開発が多かったので、
それはそれでやらなきゃいけなかったんですけど、毎回やりたいなと思っていたアプリの開発があったんで、それをお正月休みにしっかりやったという感じですね。
またゼロからアプリを作っていくと思うんですけど、AIを使えば使うほどコツがわかってくるというか、
だんだん使い方が上手くなってきた感じがしますね。
業務アプリで作っていってるんですけど、画面のレイアウトとかデザインなんかも専用のAIがあってですね。
そこを使うとかなり綺麗なデザインができてくると。レイアウトもプロ中のプロを作ったみたいなね。
日の打ち所のないようなものができてくるし、すごいなっていう時代ですね。
AIの導入と開発現場の変化
今日のテーマとしてはですね、良いも悪いもなく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を使って作るというふうにしてますね。
そんな感じです。でね、まだちょっと時間ありますかね。
技術力の向上とAIコードの理解
Xの投稿を見たらですね、こんなのがあってですね、どういう話があったかというと、生成AIを使ってですね、うちの会社も開発するようになって、コードがですね、2倍の速さで書けるようになったと。
2倍ってことはないと思うんですよね。5倍ぐらい速いんですけどね。なんですけども、開発全体の速度は遅くなっているというのがありましたね。
で、書くのは書くけども、どうもそれがみんな理解できないと。内容がね。コードの中身が理解できないので直そうと思ってもなかなか直せないと。
自分で書いたはずのコードがですね、理解できなくて、それで修正する箇所がわからないという風があったときにですね。
なのでね、みんな頑張ってちゃんとコードを理解できるように頑張りましょうと。レビューの人も疲弊してすると思いますけども、頑張りましょうみたいなね。
そんな結論になっていたんですよね。要はあれですね、もうちょっと技術力をしっかり高めて、AIにしか理解できないコードを許すなみたいなことを言ったんですけど。
気持ちはわからなくもないんですけど、私としては途中まではすごい賛成なんですけど、最後の結論はそうじゃないだろうなという風には思いますね。
あれですよ、我々もほら、もともとのC言語とかで画面から書いた時代に比べてどんどんプログラムは難しくなっていって、内部で何やってるかわからないという状況になってきましたし。
だんだんコードはですね、フレームワークとか使ってもそうですけども、だんだんコードは理解できなくなっていくんですよね。理解しなくても良くなっていくんですよ。
このAIが発達してこの開発現場に登場したことによってですね、また大きくそれが1ランク上のレベルで難しくなってしまったと。
仕様書作成の重要性
読めますよ読めばね。読めば読めるんですけど、読んだとてですよ。それよりもですね、やるべき方向性はそうじゃなくて、仕様書をしっかり出させるってことですね。
今までの開発スタイルって仕様書をミニマムにしようっていうのがね、うちの会社もそうですよ。
それは当たり前だったんですけど、それをしないと、仕様書はAIが勝手に書いてくれるんで、こちらは要件をしっかり伝えて、要件はさすがに書いてあるしかないんですけども、
それもAIに手伝ってもらうんですけど、要件をしっかり伝えて、それを理解してできたかどうかをですね、ちゃんと仕様書という形でAIに吐き出させて、
それを開発者全体、あるいは営業とかですね、あるいは場合によってはですね、お客さんの担当者も含めて仕様書を読み合わせして、理解すると。間違いがないからチェックするというのが大事ですね。
実際にそれを元にして実装させて、動きを見て、これなんかおかしいんじゃない?というときは、その仕様書に立ち替えると。
仕様書と矛盾してこれ不具合じゃん?これが実現できてないじゃん?みたいなね、言えばいいわけで、仕様なのかどうなのかちょっとわかんないなみたいなね、パターンがよくわかんないなみたいな感じのときは、
今の実装の仕様ですね、実装仕様をまた出させて、ドキュメントに出させてですね、それをやっぱりみんなでチェックすると。
当初の仕様書と実装されたものの仕様がこれ違うじゃん?っていう、自然言語でチェックすると。
これが矛盾してるよということがあれば、またAIに言って直させると。そういうフローですね。
これまでと大きく違うのはですね、これまでの開発と大きく違うのは、AIのコインスピードというのはもちろんあるんですけども、それよりも我々の方が変わらなきゃいけないのは、仕様書を出すというフローですね。
仕様書を出させてはチェックするということをやっていかないと、いいシステム、ちゃんとまともなシステムできないという気がしますよ。
開発者の役割の変化
もう一個ですね、もう一個、もう一個、大事なことは、AIを描いたソースを勝手に触らないと、人間ごときが、と思いますね。
設定値を変えるのはいいですよ。画面見ながらですね、ここのパッキングを広げたいなとか、そういうのはいいと思うんですけど、ロジック部分をですね、こてこて書かれる部分があるんで、そこを人間が触るとAIが困りますので、触ってはいけません。
人間が関与するのは、AIが書いてきた仕様書を読んでチェックして、ここ違うという、そういう話ですよ。その部分だけですね。
そうなってくると、これからの開発者ってどういう人がですね、向いてるかっていうと、理系の大学を卒業した人というよりもですね、法学部とかですね、そっち系ですね、政策とかですね、そういうロジックで考えられる人、そっちの方が向いてる気がしますね。
その仕様書もすごい大変なんで、何百行も出してこられるんで、それをレビューしなきゃいけないんで結構大変ですね。
それを、その仕様書を別のAIに加わせて、会話しながらね、矛盾ってないか聞いていくっていう手もありますけどね。事前に言っても、何らかの方法で書いてある内容をよく理解して、お客さんが言っていることに対して矛盾がないかというのをですね、抜けはないか、抜け漏れですね。
それをチェックするって大変ですよ。ステータス一つにしてもですね、AIはこうだろうって感じで言ってきますけど、我々が見逃している、要件定義で見逃している、暗黙のパターンがあったりしますから、それをですね、指摘するのはなかなか大変です。
そういうことですね。と思います。だから開発会社のですね、いろいろと言っていることを見ますけども、この仕様書を出させてレビューするっていうフローに言及している会社は今のところ私は見たことがないですね。
それこそが一番大事だと私は今4件くらいシステムを作ってきて学んだことですね。
ということで、また今年もですね、AI使った開発が進めていって、これをですね、やっぱり一つチームをちゃんと作って、私が一人でやっているわけじゃないですか、今も何人か4人くらいでやってますけど、これを同じことができるような人間をですね、がんがん増やしていって開発力を上げていこうというふうに思っている次第ですね。
また今年もいろいろやっていこうと思っていますが、たまにはですね、ちょっと今日技術的な話になりましたけども、たまにはこんな話もしてみたいなというふうに思いました。
はい、いかがでしたでしょうか。ご意見、ご感想、ご質問等ありましたら、Xまで送ってください。それではまた来週の木曜日、このチャンネルでお会いしましょう。
