別にAIは万能じゃない
イーロン・マスク率いるDOGEが6000万行ものCOBOLコードを含む社会保障局のシステムをコード生成AIでわずか数カ月の内に移行させようとしており危険性が指摘されている
何か一見見ると「AIすげー」って思う内容だけど、いやこの内容を見てる限り、そもそも「古いプログラムコードの移行対応」ってのは、別の問題が多いよねって思うわけで、この上の記事の内容だと「全く解決できない」大きな問題があるんですよね。
ってのが以下内容。
- そもそも古いシステムの移行が難しいのは「仕様が現物のソースコード＝誰も仕様内容を把握していない」から
つまり「システムが経年経過」の結果、今その「システムの運用管理」している人たちは、そのシステムの中身の仕様が「誰も理解できていない」わけで、なので「これをプログラムが仕様化」と言うもので、なので「これら動いてるものの仕様自身」を「誰も理解していない＝だから答えがわかっていない」状態なわけなんですよね。
なので、これら「誰も理解していない仕様をソースコードの移行対応を行いながら、仕様を少しずつ理解しながら、新しいシステムに移行」していくので、それに「莫大な時間」が必要になるわけなんですよね。
そもそもAI以前から、COBOL-> Javaコンバート技術は存在した
あともう１つ、これら「COBOLからJavaへコード変換」するってのは「AI以前から話が普通に聞いたことある」わけだけど、これら「プログラムの変換」して「実行することができる」状況になったとしても、はっきり言って「これをそのまま使おう」とはならないわけなんですよね。
その理由こそ
- コンバートされたプログラムの内容や実行結果が「正しい」と「誰も分からない判断できない」と言う事
結局の所「移行元のプログラム全般の仕様を把握できてない」のに、じゃあ「そのコンバートされたプログラム内容が正しく動いてる」って「誰が判断できるのか？」って言えば「出来ない」わけで、なので「部分的には移行プログラムは使える」が「全体として、変換結果をそのまま使えない」わけで、結局これ「AI」だろうが「同じ課題」に「ぶつかる」わけなんですよね。
プログラムは「正常系」を組むだけなら「ハッピーな仕事」だよね！！
それ以外にも、そもそも「プログラム組んで終わり」なんて「お仕事」が「プログラマの仕事」なら、きっと「プログラマーって職業は超ハッピーな職業」であり、プログラマーの苦行と言うか「大変な事」ってのは
- デバッグ対応
- 例外処理の対応
であり、デバッグ対応を行う事で、そのプログラムが「仕様通り」なのかを「担保」するものだし、また「プログラムを組んでる中」で「発生する例外に対する対応等」は「それなりのプログラムを書く必要」があり、これら「例外処理のデバッグ対応」もあり、これらを経て「仕様通りに動作」して「例外時の対応でも一定範囲リカバリーして正常動作とできる形」が担保できるわけで、この辺が「ある意味正常系プログラムより大変」だったりします。
この辺の「システム開発の本質」が「全く端折られてるなあ＝プログラムだけじゃない」ってのが「上のAIすげー記事」なのかなって感じました。
AIでノーコードって...ｗ
AIがすべてのプログラミングコードを生成するようになるので「コーディングを学ぶのは時間の無駄」とReplitのCEOが答える
これも「先程のAIでCOBOL移行が短期間でできる」的な感じの内容と同じですが、この内容も「何かAIでバラ色化＝プログラマー不要」と「誤認する記事」だなあって思ったので、突っ込みたいと思います。
システムやツール作るのに、難しいのが「仕様」や要件定義だよね
そもそも「プログラマーがプログラムを書く」って要素で「一番大事」な事は
- 仕様
だけど、これ「AIに対してどうやって理解してもらうのか」って思いました。
ってのも、これ「システム作れるプログラマ」に対して「要件定義」をしても、ここに「業務仕様」がある場合、これらの内容ってのは「伝えるのが難しい」もので、これが「うまく伝わってない」場合は「全く使えないシステム」となってしまう危険があります。
実際に筆者が体験して強く思った事
たとえば社内で「使うツール的」なものに対して「利用者が経理とか事務関連」の場合「その会社の業務仕様」ってのがあり、そのやり方を主体として「ツールを作成」して、業務効率化を図る等のためのツール作成を行う事がありました。
そこで以前実際に筆者が対応した「業務効率化の一環的な、社内ツール」これの「要件定義」の中で「用意された情報」これらは「手作業で対応する時に使ってる「Excelファイル群」ですが
- 「提示された情報」の内容を精査
- 「マスター系情報」や「足りない情報」を精査
- 相手がやりたいことに対して「現行安価で収めたいが、それが難しい事」の「代替え手段」の模索やあきらめ等
これらを「打ち合わせして」仕様をまとめた時間ってのが、仮に累計で１週間かかったとします。
次にこれを実際にコーディングする時間が、この時は大体１日で、その後テスト等動作確認を行ったので、大体２日ぐらいで作成完了ってのが大体の「コーディング時間」でした。
結局この程度のものでも「相手が納得する仕様を聞き出して固める」時間に対して、実装する時間ってのは「大したこと無い時間」でしかないわけなんですよね。
で、ここで「ノープログラム」を「使う側」は
- 当然筆者じゃなく、業務最適化を行う側（今回だと業務効率化を求める経理とか事務関連の人）
になると思うし、その方が「インパクトがある」し「ノーコード＝プログラマーは不要」と「上の記事で書いてる」わけなので、そうすると
- 仕様をプログラム作成にまで落とし込む＝AIのお仕事
になるけど、いやあ「ノーコード」と「仕様を固める」ってのは「全く別次元の話」でしかなく、これ「AIでできるんですか？って言えば多分できないと言うか、ノーコード＝プログラムを書くだけ」ですよねって話であり、じゃあこれ「誰が仕様に落とし込む」ですかねえってことなんですよね。
プログラム以外のたとえば既存のマスターデータ等、これらもAIが見てわかるものなの？
あと、今回の場合はExcelが主体で「Excelに入力された内容」を元として「プログラムをそれに合わせて実装」するけど、これってそもそも「どうやってAIが理解できるのか？」と言う場面、これこそ「先ほどの仕様」に該当して、この「セルの内容はこれとして利用する」とかだけど、これら「どうやってAIに理解してもらうの？」ってわけなんですよね。
で、これら「Excelマスターデータ等の利用」ってのを「人に伝える場合」って「共通で理解できる形の仕様書」とか書くわけで、これらを通じて「他人に仕様の理解」をしてもらう必要があるけど、これって「仕様を見ても理解してくれないケース」ってのは「多々ある」わけで、これらを「口頭で説明」をして「仕様の理解」を図る事が「普通のやり方」だと言えます。
だからシステムやツールはプログラムが面倒じゃない！！仕様を考える、伝えるが難しいもの
結局システムやツールを作るにおいて、プログラムを書くのが大変じゃなく
- 他の人に仕様をかいて理解してもらう事
- システム詳しくない人が、プログラマに仕様を伝える事がそもそも難しい事
これらのハードルがあるのに、これらを「無視」して「AIだとノーコード」ってのは、いやあ「勘違いさせる」ものでしかなく、これこそ
- システムやツールを作る事が難しいのは「プログラムが弊害じゃない」
- 仕様化と仕様の理解
であり、いやあ「これどうするの？」ってのが上の「AIでノーコード」の記事見ていて思った次第です。
そもそもAIに仕様を理解してもらうための「プログラムみたいな定義」が必要になり「本末転倒感」が...
あと結局これら「仕様をAIに司令」するために、何か「専用のプログラムライクな形」のものが、存在する事になり「それを学ばないとAIでノーコードシステム構築が行えない」とかの「本末転倒」になる感じがしました。
そうすると「別に既存のプログラム」で「仕様を理解して作れば良いレベル」なのか？ってわけで、何か「システム改悪」的なものでしかないって思いましたね。
あとAI＝GPUぶん回す＝電気代やコストが高い問題とAIのバランスを考えるべきかと
あと「AI=GPUぶん回す＝電気代高すぎ＝地球温暖化ガー」的な要素があるわけで、何か「無理やりAI技術を使うための新たな取り組み」で、これ自身も「アンチパターン」でしかなく、なので「この辺非常に違和感」があるなあって上の２記事を見ていてそう思った次第です。
AIで要件定義から仕様を作ってもらうのがまず必要なのでは？
って言うか「筆者」として「AIでこれができたら良いな」って思うこそ
- システム要件を提示すれば、熟練ITエンジニアがこさえるレベルの仕様を作ってくれる
まあこれが「作れる」方が「重要」なのかって思いました。
結局AIは、今は便利なツール機能や狭い部分に特化したものなのかと
結局「AIって便利」な「あくまでツール」でしかなく、ただ「費用対効果」が「実証できるレベル」なのか？って言えば、そうでもないが「以前使ってみた FasterWhisper」とか、普通に「会議の文字起こし」とかで「資料化できる」レベルで「実用化」できそうで、普通に「N100CPUでも可能」なので「利用用途に応じて使えるものか」ってレベルかと思いました。