熱脳しゃちょのブログ -18ページ目

熱脳しゃちょのブログ

おせっかい焼SE兼プログラマ兼……の辛い日々と、思う事なぞ

ふむ。

これ、分類するのか。

AIで淘汰されるのはプログラマ、と。

 

でもさ、プログラマ飛ばしていきなりソフトウェア開発者になれるのか?

「プログラマより単価の高いSEを育てる。文系卒業生もいきなりSE」

とかいってた会社はどうなった?

少なくともオイラは、無茶苦茶迷惑を被ったぞ。

 

いきなりソフトウェア開発者になれる人もいるけど、大多数はそうじゃないよな?

 

「金がかかるから、うちでは育てたくない」

「どこかで育った出来上がった人間だけが必要」

 

ってさ。

部分最適ではあるけど、典型的な合成の誤謬だよな。

アメリカでは、就職するには数年の実務経験が必要とか言うアホな状況になってるし。

 

日本は……、多分ソフトウェア産業に従事しているエンジニアの7割近くは他業種で就職できなかった人で、マジで勉強も努力もしてないよなぁ、と。

してる、って人もいるだろうけど、勉強会とかの「意識高い系活動」でしょ?

 

でも、副業は「俺たちに対する侮辱だから」禁止。

 

 

 

舐めてんのか (-_-)

 

 

有能なら有能なほど、「お前んところの小さな鳥籠の中で満足できるわけねーだろ」。

 

A「倉庫機能はありますか?」

B「標準機能になってます」

A「それでこの金額ですか。じゃ、御社で」

からの、

B「店舗の裏の倉庫じゃないんですか? 1店舗1倉庫が前提なんですが」

A「うちの規模、業態でそんなわけないじゃないですか。実店舗でも複数の専用倉庫があるし、大物を入れる地域ごとの共有倉庫もある。問屋もやっているので、店舗がないところにも倉庫があるし、倉庫直送もあるし、それぞれの倉庫で店舗ごと拠点ごとに在庫管理してます、って現場に来ていただいて説明したじゃないですか」

B「私、その訪問に参加していなかったもので……」

おいら「あれれ〜?おかしいぞ〜。このエクセルの履歴に××地方の小規模薬局チェーン店の名前があるぞ〜。あ、こっちにも〜。他の企業名はなさそうだなぁ。あ、タイムスタンプは1年半前だ〜。十分な実績があるって聞いたような気がするけど、どう考えてもセカンドユーザーだよねー? しかも業種業態、全然マッチしてないぞ〜」

 

みたいなことが、駆け出しの頃あった。

この一点でもコレなので、当然プロジェクトはぐだぐだ。

これのせいだけではないけど、A社は倒産した w

AもBも「倉庫機能」ってとても一般的な同じ単語使ってるのに、それぞれが思い浮かべてるものが全然違うから地獄が始まった。
って経験から、どんなに間抜けに思われるかもという点でも、自分がよく見知っている単語であれば尚更、新しい業種業態どころか「企業単位で」念のために確認することを習慣にするようになった。

 

# A社も確認足りないんじゃないか? って思われるかもしれないけど、一通り説明済みだったので、「この業務に対応できる」倉庫機能を指していたのは言うまでもない。おいらはこのプロジェクトがきな臭くなってから投入されたわけだが、マジ酷かった。ファーストユーザーで大赤字を叩き出して、何としても受注、目の前のお金を確保する必要があった。全ては受注してから何とかすればいいしなんとかできると思ってた、とBの内部の人から聞き出し、うちの売上規模でこんな貧弱なDWHでそんなこと実現できるわけねーだろ、と突っ込んだもんだ。

 

「AIを使ったコーディング」も、話す人話す人、ちがうんだよね。
「××社では30%!」で、おたくと同じ方法、同じレベルのエンジニアによるレビューがされてると思ってる?

思い上がりも甚だしくねぇか?
しかもこれ、まず間違いなく、AIの生出力をマージしてるんじゃねーぞ。


「1△1=2」「1△2=3」「2△1=3」「1△3=4」「2△2=4」「3△1=4」……、という要求があったとして、

func triangle_1_1()
    return 2
}

func triangle_1_2(){
    return 3
}

func triangle_2_1(){
    return 3
}

……

じゃなく、

func triangle(x,y)
    return x+y
}

ってことだろ? ってやるのがプログラミングな訳で、深く考えることなく、リストの要求ごとに上からプロンプト突っ込で出力されたコードをマージしていくのを「AIで大量のコード生成して……」ってことだと勘違いしていたら、そう遠くなく破綻する。
「積み上げたコードは保守管理しなくてはいけない」
ってことを忘れてるエンジニアが多すぎる。
これで、「法律が変わったので、「1△1=2.1」「1△2=3.2」「2△1=3.1」「1△3=4.3」「2△2=4.2」「3△1=4.1」」になります、って仕様変更が入ったら、地獄だぞ。

func triangle(x,y)
    return x+y*1.1
}

で済む話が、全コードに修正かけて、テストも変更しなきゃいけない。 さらに「適用は2026/4/1 04:00以降」と言う条件があったら? 「2026/04/01 04:00に新バージョンをリリースします」 とかいうわけわからん運用してるところ、結構あるだろ?

func triangle(x,y,at)
    if at < "2026/04/01 04:00" then
        return x+y
    else
        return x+y*1.1 
    endif
}

で、対応した自動テストしておいて、リリースしておきゃゆっくり眠れる(if文使わないで、atをパラメータとしたfactoryパターン使ってルールパターンクラスをインスタンス化させるだろうけど)。 

こんな見え見えな事例みて「そんなことしねぇよ」って言うかもしれないけど、実務でほぼこれと同じこと絶対してないと言い切れるか?
おいらは山のように見てきてるぞ。

つい半年ほど前も、新サービス設計で。

考えなくても、とりあえずプロンプト入力したら何となく動くコードが出力される。
タスク、機能リストと1対1対応で可視性が高い。

で、triangle_1_1()みたいなPHPer風コードが大量生産されて「コード量が10倍になって、生産性が上がった!」ってなってる現場がたくさんあると、いろいろ話しして確信している。
コレさ、全部廃棄して作り直さないとどうしようもないクソコード、クソアーキテクチャだって、理解できてるか?

ってのに、複数社のCTOとかに「AIコーディングされてないんですか」ってここしばらく小馬鹿にされてきて、結構むかついてんねんけど、どいつどついたらええんやろ?


すでに評価済みじゃ!

いやいや、AIモデルのバージョンが上がれば……。
って、今の生成AIの原理、構造からすれば、triangle(x,y,at)みたいなのは絶対に作り出せない。

フレーム外の世界の認識という概念が存在しないから。
そもそも仕様書の機能リストの表記が「システム的に正しい、最適」であるとは限らない。
むしろうんこの山だと確信できるしな。