ふてはなDM。この番組は、全国の悩める若きビジネスマンに向けて、私島田徹が本音で語る直球メッセージをお送りします。
はい、今日のタイトルはですね、AIがあるんだからもっと安く早く作れるでしょうと非エンジニアに言われた時に読む(読んでもらう)記事を読んで、というですね、タイトルになってますね。
ちょっと前にですね、自分はQiitaのメールマガをずっと撮ってるんですけども、Qiitaってのはあれですね、エンジニアがですね、皆集まって自分のプログラムを公開したりですね、
情報交換するみたいな、そういうSNSっていうんですかね、そういうところがあるんですよね。そこのですね、一応自分もエンジニアの端くれのつもりでいるので登録してあってですね、
メールマガを配信してもらったんですけども、そうしたらですね、先週ですかね、に結構読まれてる記事ということで、この記事に載ってたんですよね。もう一回言いますか?長いんですよ。
AIがあるんだからもっと安く早く作れるでしょうと非エンジニアに言われた時に読む(読んでもらう)記事というのがあってですね、
今日はそれを読んだ感想を話したいと思います。非常にこの記事ですね、よくできててですね、ほぼほぼ私が言ってることとほぼ同じですね。
基本的にですね、AI使うとコーディングがめっちゃ早くなるというのは本当にまさにその通りで、下手するとですね、3日4日かかってるのが、そういう作業がですね、数分で終わってしまうということになってしまうわけですね。
当然ですね、これはすごいと我々は思うんですけども、当然これはですね、ユーザーからの価格にですね、シビアにプレッシャーがかかってくるわけですよね、価格面ですね。
もっと早くできるでしょうと、思っちゃうもんですね。で、この方が言うのはですね、そうなんですけども、なかなか難しいところもありますよということを言ってますね。
結論の方に書いてあったんですけど、まとめるとというところで、簡単なものですね、簡単なシステムとかゼロから作っていくシステムは、それはAIが作ったらですね、非常に楽だと。
それからのPOC、ポック開発とかって言って試作品を作っていくとかですね、過去のですね、いろいろとレガシーなですね、束縛のない状態でゼロから作っていくのは人間も楽ですし、
あれはですね、AIはもっと楽ということですね。人間も全然束縛のないところで作っていくのは非常に楽で、それで3日で作れるものがですね、AIが作ったらもう1時間以内で作れてしまうという話ですね。
あとですね、逆に言うと既存のですね、何年もメンテされてきたですね、複雑怪奇な迷宮操作ですね、そういうのは人間も大変ですけどもAIもできないと。
私も常々最近やってて思いますけど、すごく複雑になったものをですね、ちょっと直してもらうとですね、やっぱり変なところでバグが出たりするんですよね。
だから相当慎重になってAIに手伝ってもらわないと、勝手にこのCursor(カーソル)とかですね、使って勝手に書き換えてもらうとですね、まあろくなことにならないですね。
結構こまめにセーブポイント作っておいてですね、ぶっ壊れたら元に戻すと、躊躇なく元に戻すという事をしないとですね、いけないという感じがしますね。
それは私が作っているゲームアプリなんですけども、既存のですね、ものすごいデカい業務システムなんかはですね、とてもやっぱり簡単に直せないですね。
言語もですね、ちょっと古かったりですね、きれいに整理されていなかったりしますので、そういうのはですね、もうやっぱりAIとはいえども、どこに影響するのかわからないので、テストプログラムがなかったりしますんでね。
直してもらっては結構慎重にテストして、また次のステップに入っていくみたいな、そんなことをする必要があるのかなって思って、そうなるとあんまりですね、AIだから速いってこともなくなってくるという気がしますね。
あとまあですね、ドキュメントですね。ドキュメントに関しては非常に効率的にできるんですよね。
この人も言ってますけども、私もその通りですね、開発する時にですね、いろいろとドキュメントを作る仕事とかですね、いろいろありますんで、議事録書いたりですね。
そういうのはもうどんどんAIに任せていって、効率化していったらいいんじゃないかというふうに思いますね。
まあそこで言うと、私なんかの考えでは、ドキュメントをですね、なるべく少なくしていくべきっていう発想がこれまであったんですよね。
で、この話はちょっと長いんですけど、ドキュメントっていうのはですね、どうしても作らなきゃいけないものなんですよ。
これあの、ドキュメント絶対作らないっていうですね、エンジニアがいるんですけども、それは絶対ダメでですね、そのエンジニアとシステムがですね、一連卓上で墓場まで一緒に行くんだったら別ですけども、
会社から発注されたシステムっていうのは会社のものですんで、エンジニアと侵入するわけにはいかないですよね。
なので後続のですね、後任のエンジニアが分かるようにですね、ドキュメントを残しておかなきゃいけないということもありますし、
エンジニアが思っていることとお客様が思っていることがちゃんと一致しているのかということで、意識合わせのためにですね、各仕様書ですね、そういうのを残しとく必要があるんですよね。
そういう意味で言うと、ドキュメントっていうのはエンジニアだけが分かればいいんじゃなくて、お客様を見て読めると、ある程度ですね、分かるものでなければいけないと。
エンジニアしか分からないドキュメントはどうでもいいんですけど、その読書とかテキストでもいいんですけど、ちゃんと公式に残しておくドキュメントっていうのは、綺麗に整形してですね、お客様が読んでも意味が分かるというようなものを作って、
これが一番大事なんですけど、ずっとメンテしていかなきゃいけないんですよね。これがですね、はじめは気合が入ってですね、10種類も20種類も仕様書を作っていこうって話になるんですけど、
やがてですね、だんだんもうコーディングがですね、進んでいくとですね、ドキュメントのメンテがですね、おざなりになってですね、
ほぼ意味がない、もう現実とかけ離れてしまっているものが残っているんですよね。
そうならないようにするんですけども、一番そうならないようにするためにはですね、本当に大事なドキュメントしか残さないというふうにしておかないと、
これも一応残しといた方がいいんじゃない?みたいなレベルのものをですね、書いていくと、大抵は全然使えないドキュメントがあって、むしろ引き継ぎの時にノイズになるみたいなね、
そんなことになりますので、私は昔からですね、ドキュメント類は必要最低限にして、それはユーザーの方もですね、ユーザー企業の方も意味が分かるものにして、
そして丁寧にメンテしておく必要があるというポリシーでやってきたんですが、ちょっと長いですけどね、これね、お話ね。