AIに仕事を奪われるのか
書き込んでいて、話題性は今更となってしまった感は否めない。
しかし、せっかく書いたので後悔しようと思った。
AIが仕事を奪うのか
ChatGPTが出てきたから言われていたが、GPT-4が実装されて精度が上がってエンジニアがAIに仕事を奪われるという話が加速していると感じる。それについての個人的な意見を綴った。
結論を言うとエンジニアの仕事がなくなることはないと思っている。
奪われるという語弊
AIに仕事を奪われるという言葉自体は10年近く前から言われていた気がする。特に当時はAIに関して無知なネットワークビジネスやサロン等の少し怪しげな界隈の「AIに仕事を奪われるから奪われない仕事をしよう」みたいな文句を言っている人を比較的多く見かけたような記憶がある。
個人的には語弊があると思っていて、人間がやりたくないような作業をAIがやってくれるってのが本来の目的。奪われるんじゃなくて肩代わりしてもらうというのが、正しいのじゃないかと。
また私自身はエンジニアとしての仕事は楽しいと感じているが、多くの人にとって仕事は苦痛。苦痛を奪われるって言い方は違うのではないか。
奪われるではなく、奪ってもらえるかと。
という冗談はここまでにして、実際の意見を書いていく。
奪われるという論文
まず論文について。
ざっくり要約するとこうなる。
これをさらに意訳して、奪われると発信している人がいた。
さらに言えば、高賃金の人の方が奪われるといった内容で発信していた気がする。
しかし内容ちゃんと読むと、「影響がある」というもの。
更にここで書かれている影響というのはネガディブな意味ではなく、チャットAIを利用することによって大幅にタスクの完了時間を削減できるといった意味での影響である。
『高所得の職種ほどLLMの機能やLLMを搭載したソフトウェアに触れる機会が多くなる可能性がある』といった意味で書かれているため、仕事が奪われるとは一言も書いていない。
ChatGPTに仕事を奪うか?といった内容のことを聞くと、仕事を奪うことはなく、ChatGPTは人々がより多くの仕事を達成できるように支援することが目的みたいなことが返ってくる。
というものを書き溜めていたらGitHubがインドのエンジニアチームを解雇。GitHub Copilotのせいという書いてあるのを見かけた。記事は以下記事。
ただこれを読んでみると以下記述。
簡単に訳すと以下内容。
GitHubが2月に共有した組織再編計画として発表されたもの
LinkedInやBlindで、これがGitHub Copilotと関係しているのではないかと指摘するユーザーが多くいる
あくまでそう推測する人がいるだけで、実際インドの拠点は他に比べてタスクが少なく、優先度が低い、規模が小さいといったことがあったようです。
英語記事は意訳されるけど、英語読めないから意訳のままとらえる人が多い気がする。
ゴールドマンサックスの文章もあるが、ITの専門家じゃない点や、金融のことも大袈裟に言ったりして外すのであまり当てにしてない。
大規模言語モデルの仕様
仕様の面。
エンジニアも含めて多くの人が勘違いしているのが、ChatGPT含め多くのチャットAIで使われているGTPなどの大規模言語モデルの仕様に関して。
そんなの知っているといった人はスルーして問題ない。
ChatGPTの動きを見ると、内容を考えて受け答えしてくれるbotだったり、検索結果を要約して返してくれているbotといった風に感じるが、実際はそうじゃないということ。
ChatGPTは学習データをもとに条件付き確率分布に基づいてテキストを生成するもの。
簡単にいうと、それまでのテキストの内容から次に続く文字で確率の高いものを続けている。
人間でも過去の学習から補完したりとすると思う。
「吾輩は猫である。名前は」→「名前はまだない」
「トンネルを抜けると」→「そこは雪国だった」
次に来る単語や文書はこれが確率として最も高いというものを繋げて文章が出力される。
これをチューニングして、より「質問への回答、文章生成、要約、翻訳」といったタスクに適した出力をするようにしたものがChatGPTである。
また、出力は確率分布のため、普通に出力すると学習データに基づく最も確からしい表現が返ってきます。学習データの確率分布に基づいているため、出力内容は学習データに左右される。
人間は会話をする時、次の単語だけじゃなくて、さらに先の単語を考えつつ言葉を発している。しかしChatGPTは人間のように先の部分を考えている訳ではない。
今までの文章から次の単語を出力という仕組みをとっている為、文章としてはまとまっているが、それが本当かどうかというのは実知識が必要になることが多い。
システムの複雑性
こういうことをChatGPTに頼んだらすぐに出力された!というのはChatGPTリリース当時から現在の5月時点まで多数ある。
ただそのほとんどが簡単なものな気がする。
テトリスを作ったみたいな一見複雑なものもあるが、そういったものに関しては、GitHubにテトリスを作成しているリポジトリはいくつかあるため、そこから学習されている結果だと思う。
他の例としてはスプレッドシートとかエクセルVBAで業務の自動化のためのコードを出力してもらい、それをコピペで動かせたといったようなもの。
ただスプレッドシートとかエクセルでの業務の自動化とか、そのレベルのものってエンジニアが作成する場合、対して時間がかからない。
もちろんAIみたいに数秒で完成できるといったことはないので時短になるのは時短になる。
ただ実際に多くのエンジニアが作っているような規模が大きなシステムは、年単位の計画、億単位の開発費といったものが多い。
そのようなシステムは仕様が複雑で、正直人間相手に理解できるように使用を説明できる人の方が少ないと思う。
ChatGPTは与えられた情報をもとにする為、実際の業務や解決したい問題をしっかりと言語化する必要があるが、それがうまく出来るのは少数。
さらに言語化をするとなると、アプリケーション開発の経験や設計の経験といったものが重要になると思う。
プログラミング知識が皆無でも、ChatGPTの回答だけでアプリケーションの開発を行うということが可能になっていることはひしひしと感じる。
しかし現状の業務システムやWebサイト(システム)は、既存パッケージなどを購入したり、制作からカスタマイズを依頼したりして使用しているのが大多数。
そのサポートなどを含めてChatGPTに一任するということができるのか?という点が重要な点になってくるのではないか。
ChatGPTのみを使っての開発って、要は開発スピードと情報の取捨選択効率が非常に上がった「コピペプログラマー」だと考えられる。
そうなるとシニアやテックリードといった技術レベルが高い人のサポートが必要ではないか。
個人開発であればいいが、それを販売や、納品する際に、ChatGPTでの開発は現実的でない気がする。
またChatGPTで作成していると意外とうまくいかない。
ChatGPTで少し複雑なプログラムを組もうとやってみましたが、コンパイルエラーは簡単に解消できるが、うまく修正をやってくれないという状況になって結局自分でコードを読むことになった。
修正がうまくいくかは言語と仕様の学習量によると思うが。
技術の成熟度が高い人は回答を修正して整合性を取るよりも、仕様を元にプログラムを組んだほうが、完成させるのが早い。修正もコードの理解がある分コードリーディングに時間が取られず早い。といったことはあるのではというのが個人的な意見。
情報の更新の面
周知の事実だがChatGPTの情報は最新のものじゃない。
2023年5月現在だと2021年9月までの情報の学習データに基づいている。
学習データの日付がいつ更新されるかわかりませんが、情報としては1年半ほど乖離している。
1年半という期間できっかけがあればあっという間に情報が更新されていくのが、ITの世界。
2021年9月前のリリースで大きな変更があった部分や、その後のリリースでの大きな変更部分などが反映されていないので、間違っていないけど推奨ではないよねみたいな内容が返ってくることが多々ある。
例えばGo言語は2021年の6月にモジュール関係の変更があった。
複数モジュール入れるならgo get繰り返すよりgo mod tidyが楽になった。
以前:
# commandを実行
$ go get github.com/a/a
$ go get github.com/b/b
$ go get github.com/c/c
$ go get github.com/d/d
// プログラムでインポート
[main.go]
import
(
"github.com/a/a"
"github.com/b/b"
"github.com/c/c"
"github.com/d/d"
)
func main() {
//略
}
現在:
// プログラムでインポート
[main.go]
import
(
"github.com/a/a"
"github.com/b/b"
"github.com/c/c"
"github.com/d/d"
)
func main() {
//略
}
# commandを実行
$ go mod tidy
modの使用変わったの比較的新しかったなと思ってChatGPTに投げたらgo getを繰り返す方を進めてきた。
docker composeもV2が2022年の4月頃だったため、V1のEOLが2023年6月と差し迫っているがいまだにV1の内容が返ってくる。
AWSも機能追加削除が多いため、AWSのIaCだと役に立たないことが多いと思う。
go、docekr、AWSと比較的新しいもので更新が早いからという印象かもしれないが、比較的歴史のあるC#(.NET)もmain関数の省略可能になったり、.NET 6 SDKが勝手にglobal using作るようになって省略可能だったりと変更があります。
下位互換性がないバージョンアップは十分考えられる。
また上記は言語仕様の話だったが、パッケージなどの方が破壊的変更あるかなと思う。
バージョン指定すれば解決する可能性は高いが、エンジニアじゃなかった人だとイタチごっこになりそう…。
セキュリティ面
情報の更新が遅いという点で、LLMの学習時点では表面化していなかったセキュリティリスクが見つかり非推奨になったことなどが考慮されていない状態で実装されるということが往々にして考えられる。
エンジニアであれば情報キャッチアップしたり、人から聞いたりなどでわかってる場合はあるだろうが。
責任性
日本の話に限るが、日本は失敗が許されないという意識が根強く残っている。
失敗したら責任取る必要があったり、業種によっては出世コースから外れる左遷されるといったように。
昔の風潮のため、ベンチャーだったり外資だったりというところでそういったものはなかったり薄かったりするだろう。特にテック系の有名企業だとチャレンジが出来ている印象が強い。
ただ、多くの企業は失敗が許されない。というよりも失敗したときに責任を取らせたがる。責任をとって何かをしたところで過去は変わらないのにも関わらず。特に役員クラスの年齢の方は意識が強いと思う。
そんな中、AIに開発させて失敗したとき誰が責任を取るのか。
そういうことを考えると完全に開発をさせるという導入は進みにくいのではないかなと。
まとめ
いくつかの見出しで仕事は奪われないと言ってきた。
経験上、大きな声で騒ぎ立てる人は、大体裏があると思うのであまり当てにしない方がいい気がする。(情報商材屋とかスクールとかサロンとか)
ただ現状のAIだと非エンジニアのみで開発を全てAIに任せて、プロダクトを作っていくというのは難しいと思う。
やれたとして非エンジニアのスタートアップの社長がプロトタイプを作成するのに使うとかじゃないかなと。
そのためエンジニアの仕事が全てなくなると言うことはない。
エンジニアを支えるツールとして優秀で上手く使えば作業効率化して仕事がうまく回るようになると思う。事業会社なら2人日のものが1人日になるから結果として1人辞めてもらうとするよりも新規事業の人員にすることや事業改善の人員にする方がいいと思うので仕事はなくなりにくいと思っている。
SESやフリーランスのような業務委託契約になるとわからないが、少なくなる可能性はある。ただ需要が0になることはない。
よくそれで開発しているなあ…と思うような人にも開発の仕事はあるので、いくらAIが発展しても現段階では難しい。
日本語という言語のせいかもしれないが、やりたいことの言語化がうまくいっていない場合が多いのでその状態ではAIに任せてもうまくいかないだろう。
あくまで一意見なので見解が違う人は多くいると思います。
ただエンジニアの仕事が奪われるという言葉を聞いてエンジニアから転職を考える人は、こういうことがなくても長く続いてないんじゃないかなと。
周りに技術好きって人が多いからかもしれないから思ってるだけかもだけど…。
この記事が気に入ったらサポートをしてみませんか?