こんにちは、JOINTSPARKSの佐藤盛超です。
今日はちょっと、うるさいおじさんみたいな話をします。（先に謝っておきます）
「エンジニア」という言葉、最近は誤解されているんじゃないのかと思っています。
特にITエンジニアの意味合いが、AI時代によって大きく変わりましたね。
私はプログラマーと呼ばれていたITエンジニア、崇拝していました。
残念ながら今のAI時代、コードをイチから書く人なんていないし、そんなスキルは淘汰されてしまいました。
ですが、その超絶優秀（私から見れば、あんな複雑なコードを理解して書けるのは天才！）なITエンジニアがあって
今の生成AIがあるんだと、忘れてはならない事だと思っています。
頭の中でコードを組んでいたプログラマー
昔は、コードを書くというのは、本当に「書く」ことでした。
Basic言語、C言語、Pythonなどといったプログラム言語。それらの処理を回してました。
製造業ではスイッチを切り替えるリレー制御はPLCでラダーを書きます。ちなみに私もラダーを1000行くらい書いたことがあります。
ラダーというのは「はしご」で、名前の通りはしごのように上から順にリレー回路を図で表現したものです。
だから書いている最中は、頭の中でずっとリレーが動いています。
「この接点が入ったら、こっちのコイルが励磁して、そのタイミングでこのタイマーが走って・・・」と、頭の中はフル回転です。
これを頭の中だけで組み立てています。なので、いつもITエンジニアの方に用があっても容易に話しかけることもできませんでした。
彼らの頭の中では、ちゃんとシミュレーションが出来るような頭になっているんだと思います。
そしてデバッグ（実際に動かす作業）は、現場に行って、設備を実際に動かして確認します。
間違えていれば、目の前で機械が想定と違う動きをしますので、緊急停止ボタンをいつでも押せるようにして
お試しで動かしていました。
正直、しんどかったですね・・。しかし、あの感覚は今でも体に残っています。
「AIを使いこなすのがAIエンジニア」なのか？？
そして今、生成AIが出てきました。コードは書かなくても、何行でも自動で出てきます。ラダーも、条件を説明すれば形になります。
バグがあっても、わざわざ上から読まずに、生成AIで読ませれば良いわけです。
それ自体は素晴らしいことだと思います。私も毎日使っています。
しかし「AIを使いこなす人材」「プロンプトを書けるスキル」というものが、ものすごく高く評価されているのを見ると、正直、引っかかります。
だって、誰でもできませんか？？
日本語で書けばいいだけです。うまく指示を出すコツはあるでしょうが、それは技術と呼ぶほどのものなのか。そこに何年もの積み上げがあるのか？？一緒にするなと思ってしまう瞬間があります。
特にプログラマーの頭についていけなかった頃を思い出すと、例えば「if～then」「Do～Loop」をいくつも囲って、どうやって処理をさせるのか
必死になって作っていったのを思い出します。
よくITエンジニアの上司から「おまえの頭の中は”VOID”だ！」って言われて思い出し笑いをしたものです。
（C言語における void は、「何もない」「空の」「型がない」という意味を持つキーワード）
しかし、自分も同じことを言われた側でした
ここまで書いておいて何ですが、冷静になると思い出すことがあります。
私が現場でラダーを触り始めた頃、上の世代の方にこう言われました。
「今の若い奴はいいよな、図で書けるんだから」
その方たちは、リレーを実際に配線して制御を作ってきた世代でした。盤の中で線をつないで、動かないと線を追いかけて、体で覚えていました。
図面上でカチカチ組んでいる私は、楽をしているように見えたのでしょう。
つまり、私が今AIに対して感じている引っかかりは、当時の私が言われていたことと同じ構造なわけです。
ツールが変わるたびに、上の世代は同じことを言う。（自分がそっち側になったのかと思うと、なかなか複雑です）
本当のエンジニアの違いはどこにあるのか
だから道具の話をするのは、たぶん的外れです。
昔のコードを書いた人間が、実際に動かした結果を背負っていたからです。
私が書いた1行が間違っていれば、設備が想定外の動きをします。設備を制御した際にもしバグがあれば、最悪、人が挟まれます。
だから書いている間ずっと、インターロックはどうなるか、非常停止をかけたら何が残るかを考え続けていました。
これは、書く道具がAIになっても消えない部分です。
AIが出したコードでも、それを現場に入れると決めたのは誰か。動かないとき、原因まで降りていけるか。安全側に倒す判断ができるか。
そこを引き受けられる人が、エンジニアなのだと思います。
今と昔のプログラマーという表現についての引っかかりの正体
そう考えると、私が引っかかっていたものの正体がはっきりしました。
プロンプトが上手いこと自体は、別に悪くありません。むしろ生産性は上がります。
私が引っかかるのは、出てきたものの中身を分からないまま、成果だけを自分のものにしている場合です。
動いているうちはいいんです。問題は、動かなくなった時です。中身が分からなければ、そこで止まります。誰かが助けに来るまで、何もできません。
現場ではそれが通用しません。ラインは止まっているし、待ってくれません。
だから私は、AIを使うなとは一切思いません。使い倒すべきです。しかし、出てきたものを自分で読めるところまでは、やっぱり降りていくべきだと思っています。
師匠にはよく「分からなくなったら設備の前に立ってろ」と言われました。
道具がどれだけ変わっても、最後は現物の前に立てるかどうか。そこだけは変わらないと思っています。
製造現場を渡り歩いてきた人間として、そこは譲りたくないところです。
ちなみに余談ですが、ITエンジニアの上司が「バグって言葉は便利だよな。なんでもコードの失敗をバグで片付けられるから」
という冗談を思い出します（笑）何でも失敗を「バグでした」で片付けられる世界。
でもそれだけ長文のコードを書くって大変な作業だという事ではないでしょうか。
製造現場のDXや点検業務の課題について、お気軽にご相談ください。ヘルメットをかぶって、現場を見せていただくところから始めます。
#ものづくりをわくわくに #JOINTSPARKS
コメント