  |
はてなキーワード:作業者とは
エンジニアとテクニカルアーティストの応募者に対して現場サイドからの面談に結構な回数出たことがあるので、特に業界外からの転職希望者の方に求めていた要素(1+)2つを書いてみようと思う。
当たり前だけれど一応。募集要項に書かれている言語やらツールやらのどれか一つくらいは精通してないと面談までいかない。
ゲームは動く絵を作るのでアーティストさんでも科学的思考が大事。時間/空間方向に変化する画面を破綻なく成立させるには理屈がないとしんどい。
嘘物理やセルルックのような非現実なら不要かというとそんなこともなくて、むしろこんなトリックでなら実現できますというマジシャンのような思考が必要でなおさら難しい。
といっても別に数式とかそういう話ではなく、例えばエンジニアならのシミュレーションの話、アーティストなら色の錯視の話など、それぞれの得意分野での理屈をスコープにあわせて説明できれば良い。
面談としては、ポートフォリオから技術的に苦労した点を聞いてその返答から測る事が多かったと思う。
日頃から分析グセがあったり、それを他人に説明するのが上手い人は貴重。天才がトップに居でもしないかぎりゲームは仕様書通りに作っても完成せず、下につく開発者が制作中からフィードバックを返したり企画書に書かれていない部分を補間しながら作る必要があるので。
わかりやすい例でいうとプレイヤーキャラクターのジャンプ。スピーディなゲームといっているのに丁寧な踏み切りモーションの指定が来たら作業開始前に発注側に確認したいし、ジャンプの細かな挙動に対する"ゲーム上での"気持ちよさを作業者が感じ取れないと何度も差し戻しになったりする。
幸いこのあたりの話は、桜井さんの動画のおかげで必要性がだいぶ伝わりやすくなった。
こちらは、最近遊んで面白くなかったゲーム、あるいは楽しんだけれど言いたいことがあるゲームを聞いてどう返すかで判断していた。
部落差別問題が一時期ネットで話題になってて気になっていたのだが、自分の中で消化しきれてなかったので完全に乗り遅れた。思ったことを忘れないために書き起こした。
いわく、関西以外の地域では部落問題を軽く扱いすぎているのでは、という話だ。
元のポストでは、言語差別・地域差別・職業差別が混在していたので議論がかみ合ってなかったように思う。
私はどちらかというと、うちの地域に部落差別なんてありません！と無邪気に投げつける数々のリプライにかなりギョッとさせられた。
そして体感８割くらいのリプが「部落」という単語に差別的な意識はありませんが？という的外れな内容ばかりでさらに愕然とした。
いやそうじゃねえだろ、と。
元々差別的な意味合いのない単語が差別的に使われる例なんていくらでもある。身体的特徴（つんぼ、かたわ）、地域名・国名（福島、朝鮮）、など言い始めれば枚挙にいとまがない。
構造でとらえるならば、部落差別のことの起こりは、職業で人を差別し、隔離することだ。
そうするとモヤモヤの正体が見えてきたような気がした。
歴史的経緯の話。
「穢多・非人」と呼ばれた人々は関西だけに存在したわけではなく、日本全国に見られた。江戸幕府の作り上げた身分制度から外れ差別された人々である。
関西の問題として認識されることが多いのは、その規模の問題である。近世以前、江戸より先に栄えていた関西地域は人口も多く、また文化の中心地であった。
自然と集落規模が大きくなったことで、明治以降の解放運動の中心地となっていく。
他地域においては規模が小さいゆえに「なかったこと」になった問題が、関西ではそうではなかった、というのが正しいだろう。
うちの地域にはありません、という人間は、はっきりいって不勉強もいいところである。
今回調べて初めて知ったが、特に一部地域においては、差別をなかったことにして解消しようとする動きがあるというのは90年代には指摘があるようだ。
「関西人は差別をする蛮族、自分の地域にはそんな差別ない」という趣旨の、自分で言ってておかしいと思わないのか？と思うようなリプが多く見受けられた。
どうにも関西人は殴ってもいいサンドバッグのように思っているらしい人間が少なからずいるっぽい。地域によって人をラベリングして貶めようとするのは差別以外の何物でもない。
現代の日本、とくに都心部においても、職業差別が無いなんてのも嘘だ。東京に居ればしばしば見かける、「勉強しないとあんな仕事しかできなくなるよ」と子供に声をかける母親、なんていうのはもはや典型的差別主義者だ。
私も作業服で公共の電車に乗ったとき、周りのサラリーマンたちが私を避けるように分散したのがとても印象的だった。綺麗にクリーニングされ、他の作業者に申し訳ないくらい綺麗で、そして良い匂いになってた作業でもこれだ。
普段よれよれの汗臭いスーツで電車に乗ってもこうはならない。大なり小なり他人を見下して生きているのだろう。
いけしゃあしゃあと差別なんてありませんなどよく言えたものだと思うが
かくいう私も恐らく危険を避けるという名目のもとで誰かを見た目で判断して意図的に避けたりしているのだから同じ穴の狢である。
他地域の人間が関西に行った時に、部落という言葉を使うことの是非というのも話題に出てきたが、答えとしては、気にしろという他ないだろう。
気に食わないという人は、アトランタに来てニガー！と叫んでみればいい。その代わり生きて帰れると思わないことだ。
言葉というのは生き物であり、本来の意味がどうであれ、現在の用法やその集団における意味に注意して使わなければ大きな誤解を招く。
日本はともすれば単一民族・単一言語の国家と思われがちだが、少数民族も多く、方言というにはあまりにも異なる複数の言葉が混在する、非常に複雑な社会だ。
共通語での意味がどうであれ、その地域における文脈で異なる意味を持ち、誤解を招く表現であればそれは避けるのが理性的だろう。決して、自分の所属集団では問題ないから！などと押し通すものではない。
間違えてはいけないのは、方言を禁止しようという話ではなく、自分の話す言葉の暴力性を指摘されたら次から気を付けようね、という程度の話なのだと思う。決して難しいことではない。
自分は我慢して標準語を話しているのに、あいつら関西人は自由に方言を話していて気に食わないと主張している人間もいて、さすがにもはや元ポスト関係ねえけどこれも何かの本質だろうと思った。
5匹の猿の実験でググって欲しい。いまだに方言札を首から下げて、意味も分からず方言を叩くルールに従っている人間もいるのだろう。
どれだけ書いても文章の読めない人間はいるが念のために書いておくと、関西が先進的とかいう話をしているのではない。日本全国どこでも発生している問題の一部を取り上げて、いち地域の差別性をことさらに取り上げるのは間違ってるのではないかと言いたい。
そもそも恐らく人間は本質的に差別的な生き物なのだから、そこを否定しても仕方ないと私は思っている。
私は東京周辺の関東地域にしか住んだことがないので関東の人間には申し訳ないがやり玉に挙げさせていただく。又聞きではその他地域においてもいろんな例を聞いている。これは自分自身に対する戒めでもある。
「部落差別は関西特有の問題」というのではなく、人間社会全体に根を下ろす差別意識の一形態にすぎないのだと思う。
身近な例を出すと、派遣社員を区別して休憩室を使わせないようにする正社員、というのも、差別のスタート地点だろう。
自身の差別性と嗜虐性に少し自覚的になり向き合うことで、昨日よりはマシな人間性を得られるのではないかと私は期待している。
愉快な作業ではないが、差別意識をなかったことにして綺麗に見せかける人生よりはよほど有益だろう。
歳を取るにつれ日々考えるのが億劫になる一方なのだが、隣同士ちょっと気を遣う丁寧な生き方を心掛けたいと思ってここに記す。
・・・もしかするとこれもXで見かけたポストの投稿者を見下し言葉で責めその愚かさを指摘してあざ笑いたいというサディズムの発露なのかもしれないが。
「一生作業者やります！」で会社からOK貰ってそれで本当に死ぬまで「オッス！オラ作業長！オラは作業の長だから言われたことしかしねえし、作業の出来についての責任しか取らねえぞ！」で飯食って終われてる（か、ずっとそれで済ませられると夢見てる）っぽくて羨ましい限りだ。
組織内の都合やら社会の仕組みやらである程度出世してしまうとどうしても自分のよく知らない分野についても知る必要が出てくる。
経営的目線、各種法令への理解、他所の部署との調整も増えれば相手の人柄や人間関係の把握も重要になる。
扱う情報量が増えていくと曖昧さを許容したままだと処理能力の限界を超えてくる。
ダンパー数（人間が安定的な社会関係を維持できるのは１５０人前後が限界という研究成果に基づく数字）というものがあるが、つまる所人間の能力には限界があるわけだ。
曖昧なままの情報がいくつも重なると情報量が爆発的に増えていく。
なぜなら曖昧な情報はいくつものパターン分岐を引き起こし、それが相互に絡み合うことでさらなる分岐が連鎖的に起き続けるからである。
たとえばボードゲームで１手先を読むだけなら「自分がこう打ったら相手がこう返すかも」で終わるが、３手先を読もうとすれば「自分がこう打ったら相手がこう返すわけで、それについて自分がこう返したら相手は・・・」となり処理すべきパターンがおよそ２乗に膨らむわけだ。もしもここで、「自分が王手をかけでもしない限り、次の相手番は絶対にこれで来る。連続した手順を前提とした動きをしているのだから絶対にそうだ」と決めつけることが出来るなら、パターンが膨らむことはなく、自分の連続した２手分の動きに対して相手がどういう回答をするのかを想定するだけでいいわけである。
偉くなって処理する情報量が増えた人間が「曖昧な情報はいい。確定した情報をくれ」と口にする理由はこれだ。
曖昧なままの情報を渡されても自分の処理能力の限界を超えることを経験的に自覚しているのだ。
結局のところ、「情報の曖昧さに耐えられない人は頭が悪い雑魚なんだよ」と言ってるやつこそが、自分の処理してる世界の狭さに自覚がない雑魚でしかないのだ。
「３７度以上ならコロナの疑いがあるから検診を受けてください」というルールに対して「いや、単に基礎体温が高いだけの人かも知れない。曖昧さに耐えろ」とケチをつけるのは賢いやり方ではない。もしもそれをすれば３８度を出しているような人間さえも「俺はそもそも基礎体温が高いだけだ。今日の地球は重力が強いだけで俺はデブじゃないんだ」と言いだしかねないリスクに世界がさらされる。それならば余計な曖昧さは許容せず「とにかく３７度を超えたら医者に行け」とする方が皆のためになるわけである。
自分の小さな世界の自己満足のために「曖昧さを許容しろ！」と叫び続ける行為の幼さに築けない人達、彼らこそが「広い世界の持つ曖昧さに怯え、自分がよく知っている範囲の世界に閉じこもることを選んだ臆病者」なのである。
企業以外にない。
2024年10月末の統計では、外国人労働者数は約230万人。
https://www.mhlw.go.jp/stf/newpage_50256.html
| *業種 | *人数 |
| 農業林業 | 6万 |
| 建設業 | 17万 |
| 製造業 | 60万 |
| 情報通信業 | 9万 |
| 運輸業 | 7.5万 |
| 卸売小売業 | 30万 |
| 宿泊・飲食サービス業 | 27万 |
| 医療業 | 3万 |
| 社会保険・社会福祉・介護事業 | 8.5万 |
| サービス業（谷分類されないもの） | 35万 |
各業種の総就業者数に対しては大体2-8%の割合になるが、現場作業者として広く浸透していることを考えれば数字以上のインパクトがあることは説明するまでもない。
建設現場、工場労働において外国人労働者ははるか昔から当たり前の存在だった。
ファミレスやファストフード店、コンビニの店員も、ホテルの清掃・ベッドメーキングも、今や外国人なしに成り立たない。
はてな人口の多そうなIT業界でも、同僚や取引先に外国人はいくらでもいることだろう。
こうした状況から最も利益を得ているのは誰かといえば、企業以外にない。
仮に外国人去るべしと言う意見が大勢となり、外国人労働者をすべて排されたとしたら、日本の商活動は大きく停滞する。
ビルは建たず、工場は稼働できず、コンビニの開店時間は9時5時になり、ファミレスの料理は1時間たっても配膳されない。
日本ファーストのためならそれも良しという者もいるだろうが、今の日本で最も力を持っている勢力は誰か。これも企業以外にない。
いまや企業が自らの経済活動の少なからぬ部分を外国人労働者に依存している以上、それを排除するような言説が最終的に企業にダメージを及ぼすことは明らかだ。
経団連の加盟企業のうち100社近くが外資系企業であり、その他国内企業であっても海外進出・外国人雇用を行っていないところはごく僅かだろう。
外国人労働者に支えられた経済活動の恩恵を享受してきたのは、まぎれもなく企業自身だ。
情報格差《インフォメーション・クレバス≫の広がりを感じるよね。
ネットで驚き屋やってるだけの人や、本当にただ仕事を受注してるだけの人の中には、「AIが仕事を奪う時代」が「いつか来るもの」としてしか認識してない人が大勢いる。
でも発注する側にいるとAIによって仕事を奪われている人はもう「目に見えて存在している」のが現状だよね。
厳密に言えば「AIを上手く活用してる人が３人分の仕事を１．３倍程度の報酬で受けてくれるから、無能な２人の存在が選択肢から静かに消えていく」みたいな感じだけど。
IT業界では昔からあったことなんだけどさ、能力のある人に仕事が集中して、能力がない人には「上流がわざわざ噛み砕いてから渡すのも面倒になった単価の安い仕事を力技で解決すること」しか流れてこないなんてのは。
まあ全ての仕事が今のAIと相性が良いわけじゃないから、AIと相性がいい仕事限定になってる部分はある。
でも確実に「一部の仕事において、AI（を使える人間との競争に負けた結果）によって職（発注されるはずだった仕事）を奪われてしまった人は存在する」ってのが俺の目から見えてる近状かなと。
たまたまAIと相性の悪い業界に居た一作業者が「AIで仕事減るとか全然ないよ！俺には関係ないよ！」と言ってるのはまだいいんだけど、その場合の主語はあくまで「俺が今受けてる仕事」でしかないことを自覚して欲しいな。
ウィイイイイイッス！ どうも〜、█████で〜す。
えー、今日はですねぇ…まぁ、ちょっと難しい話、しよっかなぁと思って。えー、まぁ最近よく聞くじゃないですか、AI？ あのねぇ、AI。
ほんで〜、なんかプログラマーっていう仕事？ が、まぁ、なくなるとかなくならないとか、色々言われてますけどもぉ。
今日はね、その辺について、この僕が、えー、ちょっとね、語っていこうかなぁと、思いますぅ。
えー、まぁソフトウェア…なんですか、開発の世界は、まぁ生成AIの登場で、なんか根本的な、えー、パラダイムシフト？ の、渦にあると。まぁ、僕はずっと前から言ってたんですけどもね。
えぇ。これはね、ただの道具が変わったとか、そういう話じゃないんですよ。プログラマーっていう、まぁ職業そのものの、役割が、えー、再定義される、っていうことですねぇ。
スゥゥゥ…今までね、人間が一行一行、こ、こう、書いてたコードがね、今やAIと、まぁともしらべ作業で、生み出されるようになったと。
ほんで〜、GitHubとか見てもね、AIツールの導入率？ とか、なんかプルリクエスト？ の数が、まぁ急増してると。
でもねぇ、でもね、これ、良いことばっかりじゃないんですよ、えぇ。
なんか、えらい学者さんとかも言ってるけど、生成AIに、こ、こう、かたむきとうしすぎるとね？ 基礎的なスキルがないまんまやと、IT産業全体が、まぁ停滞するんじゃないか、っていう懸念も、えー、表明されてますねぇ。
僕が、こ、今回言いたいのはね、AIが、コンピュータサイエンス…CSの知識を、時代遅れにするんじゃなくて、むしろ、その重要性を、こ、これまで以上に高めるっていう、そういう話ですねぇ。
AIツールってね、えー、まぁ強力なんですけども、欠陥をうちづつみしたアシスタントなんですよ。えぇ。
だからね、その能力を最大限に引き出して、安全で、こ、効率的なシステムを構築するためにはね、AIの生成物を、ちゃんと指導して、検証して、修正できる、深い専門知識を持った、えー、人間のパートナーが、まぁ不可欠であると。
未来はね、AIにただ指示できる人間じゃなくて、強固なCSの基礎を土台にして、AIを、こ、巧みに操って、かたろうで、効率的で、安全なシステムを設計できる、「AI拡張型エンジニア」…まぁ僕みたいな人のものですね、はい。
えー、まぁね、えーその、色んなツールがあるんですけども。今日はね、僕が、えー、主要な4つのツールを、えー、比較分析してやろうかなと。
まずね、ギットハブコパイロット。これはね、まぁ、開発者の「才能はあるけど視野が狭い後輩」みたいなもんですねぇ。
定型的なコード…まぁ、ボイラープレート？とか、そういうのを生成するのは得意なんですけども。
ただね、こいつの視野は、今開いてるファイルぐらいにしか、限定されてないんですよ。レポジトリ全体とか、そういう大きな話は、まぁ、分かってないですねぇ。
あと、知識もね、2023年の10月とかで止まってるんで、最先端の開発には、まぁ、対応しきれないかなと。えぇ。
だから、こいつが出してきたコードは、ちゃんと人間…まぁ、僕みたいなシニアなエンジニアが、レビューせんとあかん、ということですねぇ。
次はね、チャットジーピーティーの、えー、コードインタープレター。
これはねぇ、コード生成だけじゃなくて、データ分析とか、可視化とか、色々できるんですよ。
ただね、こいつの一番の、こ、制約は、インターネットに繋がってないことですねぇ。セキュリティのためらしいけども。
ほんで〜、使える言語もPythonだけやし、ライブラリも、まぁ、決められたやつしか使えないと。
たまにね、幻覚を見て、なんか変なコード出してきたりするんで、まぁ、全面的に信用するのは、ちょっと危ないかなぁと、思いますね。
えー、アマゾンのコードウィ？す…ぱ…ぁあですねぇ。これはね、まぁエンタープライズ…大企業向けですね。
一番の特徴は、セキュリティですねぇ。もろじゃくせいを、こ、検出してくれたり、オープンソースのコードと似てたら、ちゃんとライセンスを提示してくれると。
知的財産権？IPリスクを、まぁ、減免してくれるんで、大企業は助かるんじゃないですかねぇ。
ただね、まぁ、設定がちょっとめんどくさいかなぁと。AWSのエコシステムに、まぁ、依存してる感じはありますね。
こいつはね、コードのレビューとか、修正を、差分…ディフフ形式で、提案してきたりすると。
ただねぇ、まぁ、出たばっかりやからか、動作が遅いとか、バグが多いっていう報告が、まぁ、ありますねぇ。
「本物のエージェントじゃなくて、ただのチャットだ」とか言われてて、まぁ、競合に比べると、使い勝手はまだまだかなぁと。グーグルも、まだまだですねぇ、ほんまに。
えー、AIがコード作る時代にね、「もうコンピュータサイエンスの知識なんていらんのちゃうか」って言う人がおるんですけども。
それはね、大きな間違いですねぇ。断言しますけども。
現実は逆で、AIが生成したコードの品質を評価して、最適化するためには、CSの基礎原理への深い理解が、これまで以上に、まぁ、不可欠になるんですよ。
昔、僕がバイトでちょっとプログラム組んでた時もねぇ、やっぱり基礎が分かってないと、もう、話にならんかったですねぇ。
アルゴリズムとか、データ構造とか…この知識はね、AIが出したコードが、効率的かどうかを評価するための、まぁ、根幹をなすわけですよ。
AIはね、文法的には正しくても、アルゴリズム的に、こ、非効率なコードを平気で出してくるんで。
ビッグ・オー記法とかね、そういうのを理解してる開発者じゃないと、AIが出したもんが、本当に使えるかどうかの判断が、まぁ、できひんわけですね。
これが、ただの「プロンプター」と、真の「エンジニア」を分ける、境界線になると思いますぅ。
えー、これからの時代ね、ただツールを学ぶだけじゃ、まぁ、不十分ですねぇ。
人間とAIが、こ、協調するための、新しいスキルセットが、まぁ、必要になると。
まず、プロンプトエンジニアリング。これはね、ただAIに質問することとちゃいますよ。
AIを、こ、望ましい結果に導くための、技術的なスキルですねぇ。
AIに環境の前提を教えたりね、出力の形式を指定したり、そういう、こう、構造化された対話の技術が、まぁ、求められるわけです。
ほんで、コードレビュー。AIがね、一次レビューはやってくれるんですよ。しょうもないミスとか。
だから、人間はもっと高次の、アーキテクチャの妥当性とか、そういう、AIには分からんところに集中できると。
でも、そのためには、AIが作ったコードを、厳しい基準で、こ、批判的に評価するスキルが、まぁ、前提になるわけですね。セキュリティとか、パフォーマンスとか、保守性とか…ほかにも…あー…えぇ。
なんでかっていうと、自分が書いたコードじゃないから、そのロジックが、頭の中にないわけです。
だから、なんか、AIの思考プロセスを、こう、リバースエンジニアリングする、みたいな作業になるんですねぇ。
まぁ、こ、こういう話をね、教育現場にも、ちゃんと落とし込んでいかなあかんと思うんですよ。
僕がね、もし、えー、東京大学とかで教えるなら、こういう風にしますねぇ。
まず、学習者はね、AIを「松葉杖」じゃなくて「パートナー」として使わなあかんと。
AIの言うことを鵜呑みにせんと、常に、こ、検証して、その裏にあるロジックを理解する、そういう責任感が、まぁ、不可欠ですねぇ。
教育者側はね、AIを使って、生徒一人ひとりに合わせた、個別最適化学習を実現できると。
ほんで、カリキュラムの重点は、コードを書くことじゃなくて、批判的思考とか、問題設定能力とか、そういう高次のスキルに、まぁ、移行すべきですねぇ。
AIが作ったものを、どう評価して、改良していくか、そういう課題を、まぁ、出すべきかなぁと。
スキルが古臭くなることとか、認知能力の低下を、まぁ、おんわするためにもね、生徒が主体性を失わないように、導いていく必要があると思いますぅ。
AIはね、セキュリティの脅威を、大規模に生み出す可能性があるんですよ。
えー、「ジェネレーティブ・モノカルチャー」…まぁ、生成的単一栽培？ みんなが同じAIツール使うと、同じ欠陥を持ったコードが、まぁ、爆散しちゃうと。
これで、一つのもろじゃくせいで、何千ものアプリが、まぁ、やられる可能性があるわけですねぇ。
あと、データプライバシーとか、知的財産…IPの問題もありますねぇ。
AIが作ったコードの著作権って、どうなんの？っていう。まだ、まぁ、グレーゾーンですね。
まぁ、色々話してきましたけどもぉ。
要するにね、AIは、人間のエンジニアの終わりじゃなくて、その役割が、新たな高みに、か、昇華する、時代の幕開けやということですねぇ。
ほんで、コンピュータサイエンスの深い基礎知識が、これまで以上に重要になる。
プロンプトエンジニアリングみたいな、新しいスキルも、まぁ、不可欠になると。
未来の開発はね、人間とAIの競争じゃなくて、人間「と」AIの共生関係で、まぁ、定義されると思いますぅ。
AIが定型的な作業をやってくれるおかげで、人間は、創造性とか、複雑な問題解決とか、そういう、より価値の高いタスクに、まぁ、集中できるようになるわけですよ。
だからね、現代のコンピュータサイエンス教育の、まぁ、究極的な目標はね、ただコードを書ける人間を育てることじゃないんですよ。
AIアシスタントの有無にかかわらず、未来を設計できる、「コズミック・マインド」を、函館すること、なんですねぇ。
…はい。
というわけで、えー、今回は、まぁ、ちょっと難しい話でしたけども、ね。
えー、今後の、えー、AIとプログラミングの未来について、えー、この█████が、えー、お話しました。
まぁ、内容としてはー、濃い内容だったかもしれへんけど、俺としては精一杯、
えーーなんでしょう、ま、皆さんに、えー、分かりやすく、えー、お伝えしたつもりでございます。
2025年、私たちはソフトウェア開発の歴史的な転換点に立っている。大規模言語モデル（LLM）の進化は、GitHub Copilotのようなコード補完ツールに始まり、今や「何を作りたいか」を自然言語で伝えるだけで、アプリケーションの雛形が数分で生成される時代を現実のものとしつつある。この光景を目の当たりにした多くのプログラマが、漠然とした、しかし確かな不安を抱いているだろう。「私たちの仕事は、いずれAIに奪われるのではないか」と。
この問いに対する私の答えは、半分はYesであり、もう半分はNoだ。より正確に言えば、プログラマの仕事の本質が、歴史上かつてないレベルで抽象化され、その役割が再定義されるのだ。私たちは、コードを「書く」作業から解放される一方で、これまで以上に高度な思考を要求されることになる。
本稿では、プログラミングの歴史を「How（いかに作るか）」から「What（何を作るか）」への移行として捉え直し、LLMがこの流れをいかに加速させるかを論じる。そして、その先にある、AIには決して代替できない、人間ならではの競争優位性、すなわち「Why（なぜ作るのか）」を定義し、記述する能力の重要性について深く考察していく。これは、単なる未来予測ではない。今を生きるすべてのソフトウェアエンジニアにとっての、生存戦略の提示である。
LLMの登場を特異点として捉える前に、我々が立っている場所を正確に知る必要がある。ソフトウェア開発の歴史は、常に「抽象化」との戦いであった。そしてその歴史は、プログラマの関心が「How」から「What」へと徐々に移り変わっていくプロセスとして描くことができる。
コンピュータの黎明期、プログラミングとは、計算機が理解できる命令（How）を、一行一行、丹念に記述する作業そのものであった。アセンブリ言語や初期のFORTRAN、COBOLといった言語は、ハードウェアの制約を強く受けており、プログラマはメモリ管理やプロセッサの動作といった、極めて物理層に近いレベルでの「How」を意識する必要があった。
この時代のテストもまた、「How」に強く束縛されていた。書かれた手続きが、意図した通りに順番に実行されるか、特定の入力に対して期待された計算結果を返すか。テストの関心事は、あくまで「手続きの正しさ」の検証にあった。ビジネスロジックと実装の詳細が密結合し、コードは特定の処理手順を記述した、硬直的な塊となっていた。
風向きが変わり始めたのは、ソフトウェアの規模が拡大し、その複雑性が人間の認知能力を超え始めた頃だ。1990年代後半から2000年代にかけて提唱されたエクストリーム・プログラミング（XP）の中で、テスト駆動開発（TDD）という考え方が登場する。
TDDの本質は、単なるテスト手法の改善ではない。それは、プログラミングのパラダイムを根底から覆す思想だった。TDDは、「まずテストを書く」ことを強制することで、プログラマの意識を「これから実装するコード（How）」から「そのコードが満たすべき振る舞い（What）」へと強制的に転換させたのだ。
テストはもはや、書かれたコードの後追いで正しさを検証する作業ではない。それは、これから作られるべきソフトウェアの「仕様書」であり、「振る舞いの宣言」となった。例えば、「ユーザーがログインボタンをクリックしたら、ダッシュボード画面に遷移する」というテストコードは、具体的な実装方法（`onClick`イベントハンドラの中で`window.location.href`を書き換える、など）には一切言及しない。それはただ、達成されるべき「What」を記述しているだけだ。
この思想は、ビヘイビア駆動開発（BDD）へと発展し、`Given-When-Then`といった、より自然言語に近い形式でソフトウェアの振る舞いを記述するスタイルを生み出した。プログラマだけでなく、プロダクトマネージャーやビジネスアナリストといった非技術者をも巻き込み、「What」を共通言語として定義する試みが本格化したのである。
TDD/BDDによってプログラマの意識が「What」に向かい始めると、コードそのものもまた、宣言的なスタイルへと進化していく。この変化を劇的に加速させたのが、モダンなフレームワークの存在だ。
Reactを例に考えてみよう。Reactが登場する前、フロントエンド開発はjQueryに代表されるように、DOMを直接操作する命令的なコード（How）の連続だった。「このボタンがクリックされたら、この要素のテキストを書き換え、あちらの要素を非表示にする」といった具合だ。
しかし、Reactは「UIとは、ある状態（state）に対する純粋な写像である」という宣言的なモデルを提示した。プログラマがやるべきことは、UIの状態（`state`）と、その状態がどのように見えるか（JSXによるコンポーネント）を宣言することだけだ。状態が変更された際に、DOMをどのように効率的に更新するかという面倒な「How」の部分は、Reactの仮想DOMと差分検出アルゴリズムがすべて隠蔽してくれる。プログラマは「What（UIのあるべき姿）」を記述するだけでよくなったのだ。
この「WhatからHowへの変換」は、様々な領域で見られる。
これらのフレームワークやツールは、いわば「特定の制約下における、WhatからHowへの高性能な変換器」として機能してきた。プログラマは、フレームワークが課す「お作法」や「制約」を受け入れることで、退屈で間違いの多い「How」の記述から解放され、より本質的な「What」の定義に集中できるようになった。我々が「生産性が高い」と感じる開発体験は、この優れた変換器の恩恵に他ならない。
現状は、この歴史的変遷の延長線上にある。プログラマの仕事は、手続きを記述する職人から、振る舞いを定義し、それを実現するための最適な「変換器（フレームワーク）」を選択・設定するアーキテクトへと、その重心を移してきたのだ。
フレームワークがもたらした「WhatからHowへ」の潮流は、LLMの登場によって、未曾有のスケールで加速されようとしている。フレームワークが「特定の領域に特化した変換器」であったのに対し、LLMは「あらゆる領域に対応可能な、究極の汎用変換器」としてのポテンシャルを秘めているからだ。
前章で述べたように、ReactやTerraformといったフレームワークは、その恩恵と引き換えに、私たちに特定の「制約」を課してきた。Reactを使うならコンポーネントベースで思考し、状態管理の作法に従う必要がある。Terraformを使うなら、そのエコシステムとHCLの流儀を受け入れなければならない。これらの制約は、WhatからHowへの変換を自動化するための「レール」であり、私たちはそのレールの上を走ることで効率を得てきた。
しかし、LLMはこの前提を覆す。LLMは、特定のフレームワークや言語の知識を事前に学習しているが、その利用において絶対的な制約を課すわけではない。私たちは、より自由な形式で「What」を伝えることができる。
例えば、こうだ。
ユーザー認証機能付きのシンプルなブログアプリを作ってほしい。フロントエンドはReactとTypeScript、UIコンポーネントはMUIを使う。バックエンドはNode.jsとExpressで、データベースはPostgreSQL。ユーザーはGoogleアカウントでログインでき、新しい記事を作成、編集、削除できる。記事にはマークダウン記法が使えて、画像もアップロードできるようにしてほしい。
この要求（What）は、特定のフレームワークの流儀に則ったものではない。複数の技術スタックを横断し、機能要求を自然言語で並べただけのものである。しかし、現在のLLM、特にGPT-4oやそれに類するモデルは、このレベルの要求から、ディレクトリ構造、設定ファイル、APIエンドポイント、フロントエンドコンポーネントに至るまで、驚くほど具体的なコード（How）を生成することができる。
これは、フレームワークが担ってきた「WhatからHowへの変換」が、特定のレールから解き放たれ、より広範で柔軟な領域へと拡張されたことを意味する。これまで自動化が難しかった、あるいは特定のフレームワークが存在しなかったニッチな領域や、複数の技術を組み合わせる複雑なシステム構築においても、AIによる宣言的プログラミングの恩恵を受けられる時代が始まろうとしているのだ。
LLMという汎用変換器の登場により、プログラマの生産性は、「いかに質の高いWhatをLLMに伝えられるか」に直結するようになる。これは、俗に「プロンプトエンジニアリング」と呼ばれるスキルだが、その本質は、ソフトウェア開発における「要求定義」そのものである。
質の高い「What」とは何か。それは、曖昧性がなく、網羅的で、矛盾のない要求である。
これらは、優秀なソフトウェアエンジニアが、プロダクトマネージャーやデザイナーとの対話を通じて、日常的に行ってきた思考プロセスそのものではないだろうか。LLMの登場は、この思考プロセスを、より明確に、よりテキストベースで「記述」する能力を求める。私たちの頭の中にあった暗黙的な仕様が、LLMへの入力（プロンプト）という形で、明示的に言語化されることを要求するのだ。
やがて、ほとんどのプログラミング作業は、この「Whatの記述」に収束していくだろう。TDDがテストコードという形式で「What」を記述したように、私たちは自然言語や、より構造化された要求記述言語を用いて、AIに対して「What」を宣言することになる。コード（How）は、その宣言から自動生成される中間生成物に過ぎなくなる。まさに、コードが蒸発していく未来である。
「What」を伝えれば「How」が手に入る。この魔法のような世界の到来を前に、私たちは一つの重大な問いに直面する。それは、「そのWhatからHowへの変換は、本当に一意に決まるのか？」という問いだ。
答えは、明確にNoである。
ある「What（要求）」を実現するための「How（実装）」は、無数に存在する。そして、どの「How」を選択すべきかを決定するためには、単純な機能要求（What）だけでは情報が全く足りない。そこには、必ず「Why（なぜそう作るのか）」という、背景、文脈、そしてトレードオフの考慮が必要不可欠となる。
簡単な例を考えてみよう。「1億件のユーザーデータを格納し、ユーザーIDで高速に検索できるシステム」という「What」をLLMに与えたとする。LLMは、どのような「How」を提案するだろうか。
これらの選択肢は、どれも「What」を満たしている。しかし、その特性は全く異なる。案Aは多くのエンジニアにとって馴染み深く開発が容易だが、10億、100億件へのスケールは難しいかもしれない。案Bはスケール性に優れるが、厳密なトランザクション管理は苦手だ。案Cは高速だが、運用コストとシステムの複雑性が増す。案Dは安価だが、検索速度は他に劣る。
LLMは、これらの選択肢をリストアップすることはできるだろう。しかし、このプロジェクトにとって最適な選択肢はどれかを、自信を持って決定することはできない。なぜなら、その決定には、LLMが与えられていない「Why」の情報が必要だからだ。
これらの「Why」こそが、無数に存在する「How」の中から、ただ一つの「正解」を選び出すための羅針盤なのである。そしてこの「Why」は、ビジネスの目標、組織の文化、ユーザーの期待、技術的な制約といった、極めて人間的で、文脈依存的な情報の中にしか存在しない。
ここで重要なのは、これまでもエンジニアは、この「Why」に基づく意思決定を、意識的あるいは無意識的に行ってきたという事実だ。
私たちが技術選定を行うとき、単に「流行っているから」という理由だけでReactを選ぶわけではない。「SPA（Single PageApplication）にすることでユーザー体験を向上させたい（Why）」、「コンポーネント指向の開発によって長期的な保守性を確保したい（Why）」、「Reactエンジニアの採用市場が活発だから（Why）」といった、様々な「Permalink |記事への反応(0) | 17:09
2025年、私たちはソフトウェア開発の歴史的な転換点に立っている。大規模言語モデル（LLM）の進化は、GitHub Copilotのようなコード補完ツールに始まり、今や「何を作りたいか」を自然言語で伝えるだけで、アプリケーションの雛形が数分で生成される時代を現実のものとしつつある。この光景を目の当たりにした多くのプログラマが、漠然とした、しかし確かな不安を抱いているだろう。「私たちの仕事は、いずれAIに奪われるのではないか」と。
この問いに対する私の答えは、半分はYesであり、もう半分はNoだ。より正確に言えば、プログラマの仕事の本質が、歴史上かつてないレベルで抽象化され、その役割が再定義されるのだ。私たちは、コードを「書く」作業から解放される一方で、これまで以上に高度な思考を要求されることになる。
本稿では、プログラミングの歴史を「How（いかに作るか）」から「What（何を作るか）」への移行として捉え直し、LLMがこの流れをいかに加速させるかを論じる。そして、その先にある、AIには決して代替できない、人間ならではの競争優位性、すなわち「Why（なぜ作るのか）」を定義し、記述する能力の重要性について深く考察していく。これは、単なる未来予測ではない。今を生きるすべてのソフトウェアエンジニアにとっての、生存戦略の提示である。
LLMの登場を特異点として捉える前に、我々が立っている場所を正確に知る必要がある。ソフトウェア開発の歴史は、常に「抽象化」との戦いであった。そしてその歴史は、プログラマの関心が「How」から「What」へと徐々に移り変わっていくプロセスとして描くことができる。
コンピュータの黎明期、プログラミングとは、計算機が理解できる命令（How）を、一行一行、丹念に記述する作業そのものであった。アセンブリ言語や初期のFORTRAN、COBOLといった言語は、ハードウェアの制約を強く受けており、プログラマはメモリ管理やプロセッサの動作といった、極めて物理層に近いレベルでの「How」を意識する必要があった。
この時代のテストもまた、「How」に強く束縛されていた。書かれた手続きが、意図した通りに順番に実行されるか、特定の入力に対して期待された計算結果を返すか。テストの関心事は、あくまで「手続きの正しさ」の検証にあった。ビジネスロジックと実装の詳細が密結合し、コードは特定の処理手順を記述した、硬直的な塊となっていた。
風向きが変わり始めたのは、ソフトウェアの規模が拡大し、その複雑性が人間の認知能力を超え始めた頃だ。1990年代後半から2000年代にかけて提唱されたエクストリーム・プログラミング（XP）の中で、テスト駆動開発（TDD）という考え方が登場する。
TDDの本質は、単なるテスト手法の改善ではない。それは、プログラミングのパラダイムを根底から覆す思想だった。TDDは、「まずテストを書く」ことを強制することで、プログラマの意識を「これから実装するコード（How）」から「そのコードが満たすべき振る舞い（What）」へと強制的に転換させたのだ。
テストはもはや、書かれたコードの後追いで正しさを検証する作業ではない。それは、これから作られるべきソフトウェアの「仕様書」であり、「振る舞いの宣言」となった。例えば、「ユーザーがログインボタンをクリックしたら、ダッシュボード画面に遷移する」というテストコードは、具体的な実装方法（`onClick`イベントハンドラの中で`window.location.href`を書き換える、など）には一切言及しない。それはただ、達成されるべき「What」を記述しているだけだ。
この思想は、ビヘイビア駆動開発（BDD）へと発展し、`Given-When-Then`といった、より自然言語に近い形式でソフトウェアの振る舞いを記述するスタイルを生み出した。プログラマだけでなく、プロダクトマネージャーやビジネスアナリストといった非技術者をも巻き込み、「What」を共通言語として定義する試みが本格化したのである。
TDD/BDDによってプログラマの意識が「What」に向かい始めると、コードそのものもまた、宣言的なスタイルへと進化していく。この変化を劇的に加速させたのが、モダンなフレームワークの存在だ。
Reactを例に考えてみよう。Reactが登場する前、フロントエンド開発はjQueryに代表されるように、DOMを直接操作する命令的なコード（How）の連続だった。「このボタンがクリックされたら、この要素のテキストを書き換え、あちらの要素を非表示にする」といった具合だ。
しかし、Reactは「UIとは、ある状態（state）に対する純粋な写像である」という宣言的なモデルを提示した。プログラマがやるべきことは、UIの状態（`state`）と、その状態がどのように見えるか（JSXによるコンポーネント）を宣言することだけだ。状態が変更された際に、DOMをどのように効率的に更新するかという面倒な「How」の部分は、Reactの仮想DOMと差分検出アルゴリズムがすべて隠蔽してくれる。プログラマは「What（UIのあるべき姿）」を記述するだけでよくなったのだ。
この「WhatからHowへの変換」は、様々な領域で見られる。
これらのフレームワークやツールは、いわば「特定の制約下における、WhatからHowへの高性能な変換器」として機能してきた。プログラマは、フレームワークが課す「お作法」や「制約」を受け入れることで、退屈で間違いの多い「How」の記述から解放され、より本質的な「What」の定義に集中できるようになった。我々が「生産性が高い」と感じる開発体験は、この優れた変換器の恩恵に他ならない。
現状は、この歴史的変遷の延長線上にある。プログラマの仕事は、手続きを記述する職人から、振る舞いを定義し、それを実現するための最適な「変換器（フレームワーク）」を選択・設定するアーキテクトへと、その重心を移してきたのだ。
フレームワークがもたらした「WhatからHowへ」の潮流は、LLMの登場によって、未曾有のスケールで加速されようとしている。フレームワークが「特定の領域に特化した変換器」であったのに対し、LLMは「あらゆる領域に対応可能な、究極の汎用変換器」としてのポテンシャルを秘めているからだ。
前章で述べたように、ReactやTerraformといったフレームワークは、その恩恵と引き換えに、私たちに特定の「制約」を課してきた。Reactを使うならコンポーネントベースで思考し、状態管理の作法に従う必要がある。Terraformを使うなら、そのエコシステムとHCLの流儀を受け入れなければならない。これらの制約は、WhatからHowへの変換を自動化するための「レール」であり、私たちはそのレールの上を走ることで効率を得てきた。
しかし、LLMはこの前提を覆す。LLMは、特定のフレームワークや言語の知識を事前に学習しているが、その利用において絶対的な制約を課すわけではない。私たちは、より自由な形式で「What」を伝えることができる。
例えば、こうだ。
ユーザー認証機能付きのシンプルなブログアプリを作ってほしい。フロントエンドはReactとTypeScript、UIコンポーネントはMUIを使う。バックエンドはNode.jsとExpressで、データベースはPostgreSQL。ユーザーはGoogleアカウントでログインでき、新しい記事を作成、編集、削除できる。記事にはマークダウン記法が使えて、画像もアップロードできるようにしてほしい。
この要求（What）は、特定のフレームワークの流儀に則ったものではない。複数の技術スタックを横断し、機能要求を自然言語で並べただけのものである。しかし、現在のLLM、特にGPT-4oやそれに類するモデルは、このレベルの要求から、ディレクトリ構造、設定ファイル、APIエンドポイント、フロントエンドコンポーネントに至るまで、驚くほど具体的なコード（How）を生成することができる。
これは、フレームワークが担ってきた「WhatからHowへの変換」が、特定のレールから解き放たれ、より広範で柔軟な領域へと拡張されたことを意味する。これまで自動化が難しかった、あるいは特定のフレームワークが存在しなかったニッチな領域や、複数の技術を組み合わせる複雑なシステム構築においても、AIによる宣言的プログラミングの恩恵を受けられる時代が始まろうとしているのだ。
LLMという汎用変換器の登場により、プログラマの生産性は、「いかに質の高いWhatをLLMに伝えられるか」に直結するようになる。これは、俗に「プロンプトエンジニアリング」と呼ばれるスキルだが、その本質は、ソフトウェア開発における「要求定義」そのものである。
質の高い「What」とは何か。それは、曖昧性がなく、網羅的で、矛盾のない要求である。
これらは、優秀なソフトウェアエンジニアが、プロダクトマネージャーやデザイナーとの対話を通じて、日常的に行ってきた思考プロセスそのものではないだろうか。LLMの登場は、この思考プロセスを、より明確に、よりテキストベースで「記述」する能力を求める。私たちの頭の中にあった暗黙的な仕様が、LLMへの入力（プロンプト）という形で、明示的に言語化されることを要求するのだ。
やがて、ほとんどのプログラミング作業は、この「Whatの記述」に収束していくだろう。TDDがテストコードという形式で「What」を記述したように、私たちは自然言語や、より構造化された要求記述言語を用いて、AIに対して「What」を宣言することになる。コード（How）は、その宣言から自動生成される中間生成物に過ぎなくなる。まさに、コードが蒸発していく未来である。
「What」を伝えれば「How」が手に入る。この魔法のような世界の到来を前に、私たちは一つの重大な問いに直面する。それは、「そのWhatからHowへの変換は、本当に一意に決まるのか？」という問いだ。
答えは、明確にNoである。
ある「What（要求）」を実現するための「How（実装）」は、無数に存在する。そして、どの「How」を選択すべきかを決定するためには、単純な機能要求（What）だけでは情報が全く足りない。そこには、必ず「Why（なぜそう作るのか）」という、背景、文脈、そしてトレードオフの考慮が必要不可欠となる。
簡単な例を考えてみよう。「1億件のユーザーデータを格納し、ユーザーIDで高速に検索できるシステム」という「What」をLLMに与えたとする。LLMは、どのような「How」を提案するだろうか。
これらの選択肢は、どれも「What」を満たしている。しかし、その特性は全く異なる。案Aは多くのエンジニアにとって馴染み深く開発が容易だが、10億、100億件へのスケールは難しいかもしれない。案Bはスケール性に優れるが、厳密なトランザクション管理は苦手だ。案Cは高速だが、運用コストとシステムの複雑性が増す。案Dは安価だが、検索速度は他に劣る。
LLMは、これらの選択肢をリストアップすることはできるだろう。しかし、このプロジェクトにとって最適な選択肢はどれかを、自信を持って決定することはできない。なぜなら、その決定には、LLMが与えられていない「Why」の情報が必要だからだ。
これらの「Why」こそが、無数に存在する「How」の中から、ただ一つの「正解」を選び出すための羅針盤なのである。そしてこの「Why」は、ビジネスの目標、組織の文化、ユーザーの期待、技術的な制約といった、極めて人間的で、文脈依存的な情報の中にしか存在しない。
ここで重要なのは、これまでもエンジニアは、この「Why」に基づく意思決定を、意識的あるいは無意識的に行ってきたという事実だ。
私たちが技術選定を行うとき、単に「流行っているから」という理由だけでReactを選ぶわけではない。「SPA（Single PageApplication）にすることでユーザー体験を向上させたい（Why）」、「コンポーネント指向の開発によって長期的な保守性を確保したい（Why）」、「Reactエンジニアの採用市場が活発だから（Why）」といった、様々な「Permalink |記事への反応(0) | 17:09
半導体工場進出に伴い昨年ホーム拡張工事が行われた。幅2m、大人が両手を伸ばしてちょい、
狭い、危ない、通勤時間にはホームは人で溢れる、ホーム柵などない。てか無人駅だし。屋根は一部にしかなく4人ほど座れる待合室があるだけでホームにはベンチもない、空調などあるわけない、ラッシュですら20分に1本。満員電車。
そこからさらにバスで現場に向かう。バスも常に満員。乗り溢しが出ないギリギリのオペレーション。とはいえ都会の通勤に比べれば天国だが、その分運賃が高い。鉄道もバスも田舎は高いのだ。
さてこの菊陽町、半導体企業の進出、セミコンパークの成功で税収がエグい。2025年からは不交付団体になる、国からの予算補助が不要になった、日本の全ての自治体でこれを成してる地方自治体は4％しかない。
さて半導体工場の真横に畑があり、人参なんぞを作っている。日本の農家の平均経営面積は２haなのだが、2haで人参を作っても農業所得は300万円にしかならない。
人参畑の真向かいの半導体工場は年間推定で3000億円の売り上げ（生産）がある。ちなみに工場敷地は20ヘクタールである。そんな矛盾だらけでシュールな光景を眺めながらバスに揺られて出勤する。
さて半導体工場からの税収で潤った菊陽町は様々な住民サービスを拡充する。している。
車社会ゆえに地元住民はほぼ利用しない原水駅では半導体工場で働く俺たち奴隷が風雨に耐えながら20分に一本の電車を待ちながら、一方で車でしか利用できない場所にそれはそれは荘厳な体育館を建てた。
「菊陽町総合体育館」でググれ。できたばかりでピカピカの設備で、公共施設の分際で22時まで営業している。ライザップなんぞ霞むような最新のトレーニング機器がずらりと並び使い放題になってる。
町運営の銭湯が併設されており利用料450円なのだがスーパー銭湯レベルに立派、そして予算じゃぶじゃぶなのだろう清潔に維持されている、スタッフ大勢、どう考えても利用料で採算が取れる事業ではない。なおこちらも民間委託で22時まで開いている。
さて、農業統計を見ると日本の稲作農家は年間平均22日も働いているのだそうだ。人参農家は知らんが、人参畑の横を毎日通っているが百姓が労働している様子を見かけることはほぼないが。
ともかく365日の内22日も労働しているのだから大変な仕事である（嫌味）。
このように思う人がいるだろう。
なるほど
日本、12kg/ha
これあまり知られていないんですけどね。
先に答えておくと使い方や成分で一番ヌルいのも日本だったりする。
例えば欧米では農業認証（農家版ISO）を取得している農家、農作物でなければ市場に流通されない。
認証は厳しい、農薬の成分、希釈方法や散布方法、作業者まで全て記録されトレースできる書類を残さなきゃならない。ウソがバレたら認証取り消しとなり出荷できず詰む。
ちなみに日本の農作物は諸外国から見れば信頼性ゼロの得体の知れない毒物という扱いであり、例えばオリンピック協会は選手村で提供される食事に厳しいレギュレーションが設けられており、これを満たす食材を日本国内では調達できなかったため東京オリンピックの選手村食堂では日本の食材は使われていない。
というとこのような反論があるだろう。
ちなみに、わーくに最高の米と言えば魚沼産コシヒカリだが
意味わかんないよねw
だけどそれが現実。
こんな出鱈目な市場、流通で検査なんぞしても機能するわけがない。実際していない。
何十年も前から問題が指摘されているが関係省庁、農水省は動かず。農業票ってのは強いのです。
さてそんなファックな世の中だが、生きていくには働くしかねぇ、不満を垂れても世の中は変わらん、諦めて明日も頑張って働こう。選挙など無駄だ。
ちなみに俺の時給は6500円である。
と作文終わるかのように見せかけてもう少し、
先日テレビでボリビアの児童労働が放送されていた。死の山の鉱山でトロッコを押している13歳。
御涙頂戴の画面に流れた彼の日当は
「3000円」
俺は目をゴシゴシした、何度見直しても300円ではなく明瞭に三千円と表示されており、念入りにファクトチェックしてもその金額だった
週休2日の8時間労働なのだそうだ、その賃金で家族を養っているのだそうだ、映像では100円とやらのスープを食うてるシーンも流れてた。
あとその現場で40年働き続けてるおじいさんも出演していた。。。全然危険ちゃうやん
世の中には2種類のエンジニアがいる。
具象思考しかできないエンジニアと、抽象思考ができるエンジニアだ。
プロダクトがごくごく小さければ、例えば0->1の初期実装の段階では、「動作する」という点だけから見れば、どちらも大した差はない。
皿回しで例えると、初期段階、皿を4つくらい回す程度なら、大した違いがない。
が、16、32と増えていくとどうなるか。
具象思考は、1つ1つを回す。
64、128と増えていったら？
破綻する。
抽象思考は、ある程度の皿のグループをまとめて、回し続けるための仕組みを作る。
皿が追加されるまで棒を立てないとしても、どういう皿が用意されているかあらかじめ確認をして、配置などの準備をしておく(本来は、これをDDDのドメイン分析という) 。
64、128と増えていったら？
まとめたグループをさらにまとめて回す仕組みを「予定通り」作る。
作っておいてもいいが。
どのレベルのグループの数も、8を超えないように調整しつつ(だいたい5を超えないようにしている。平均的な認知能力を超えないように)。
256、512、1024……。
具象思考のエンジニアは、「今の段階でそこまで実装する必要はない」という。
が、設計もしない。
なぜなら考えられないから。
棒を立て(実装)なくても、配置や仕組みなどを「設計」し、区画を分ける。
プログラマ上がりの中には、手が早いだけで具象思考しかできないエンジニアが大量に混じってる。
ググって、今目の前にある皿を最適に回せる棒を探して、空いた場所に立てて、回し始める。
その一連の「処理」は早い。
けど、それぞれ思い思いの棒を立てるから、それぞれの皿の回転状態をメンテし続けるのは大変だ。
この棒はこうやって操作する。
その棒はこうやって操作する。
そういう、何種類もある「処理」からパターンにマッチした処理を手早く行う。
そのパターンの数を誇って「優秀なエンジニアでござい」と鼻をおっ広げる。
バカ言え w
数が増えれば限界が来る。
皿が落ち、割れ始める。
逃げる。
https://anond.hatelabo.jp/20250610135143
これ読んで思い出したけど、逆に圧倒的にIQ高そうな人と話が通じすぎてビビった経験ならある。
相手はディレクションするポジション、こっちは下っ端の作業者って立ち位置だったけど、たまたまその人と直接やり取りしなきゃいけなくて
本来なら間に何個も会社なり人なりが入るはずなんだがとにかくその案件は直接俺がやり取りする必要があった。
相手は分かりやすく東大卒でMITがどうのこうのとも言ってた。
まず衝撃だったのがこっちが1言うと即座に10くらい汲み取ってくる。
こっちも一応頭の中で（ああ、前提の説明も入れないとこれじゃ分かんないよな）と思って追加情報足そうとするんだけど、その前にもう「ああ、じゃあ～ってことね」って深堀りできてしまってる。
俺の中の頭良すぎるやつのイメージはこっちが言うことに対して「要点をちゃんと絞って話してください」みたいなツッコミが入りがちだったんだが、
その人の場合はそれすらせずに無駄な部分は勝手に省いて、かつ足らない部分も予測だかして、「～ですね？」という推論を立ててくる、し、それが合ってる。
あとIQの差を感じるあるあるで、向こうの言ってることを理解するのにこっちは時間がかかってしまうっていうのもあると思うんだけど、
ガチで頭いい、IQ高い人っていうのは「頭悪いこっちにも分かるような分かりやすく、シンプルで的確な言い方をしてくる」という事もその人と話してて思ったことだ。
正直その人も言い方は口が悪かったんだが、こっちが迷いようがない実直な言葉だし、とにかく話をシンプルにするのが上手かった。
一般的なあるあるだとIQ低いやつには話通じないわ、とか言う人いるけど、ガチでIQ高い人は俺みたいなだいぶ頭の出来が違う人にも分かりやすく話を通じさせる能力もあるんだなって。
なので「IQ低いから話通じなくて困る」みたいなこと言ってる人ってのは、実はそれほど頭いいわけじゃないんだろうなあって、まあ自分を棚上げして思っちゃいますね。
うちの会社の技術職の人間は一定以上の高学歴が多く、今私と2人でチームを組んで仕事をしている後輩も世間的によく名の知れた大学を出ている。
その子は真面目で仕事をさぼったりとかはしないし、こちらの指示に対しても分かりましたと言って黙々と仕事をしてくれる。
ただ・・・ただ、それなりの期間一緒に仕事をしてきたが、どうも中々成長しないというか、いつまでも1人に仕事を任せることが出来そうにならない。
技術的な面に関しては、まだ入社して年次も浅いから分からない、出来ないことが多いのは仕方ないと思う。
専門職とはいえやることは結構幅広いしプロジェクトごとに必要なスキルも異なるので、それらを身に付けるのに時間がかかるのは分かっている。
その面に関してはこの後輩も年次相応ぐらいなんじゃないかなと思う。優秀という程ではないけど全然出来ないわけでもないし、分からないことも自分で調べて何とかする力は持っている。
だからそういう点で未熟であることに関しては特に何とも思わないし、今の年次のレベルでも出来そうなタスクをお願いしている。
しかし、この仕事はただただ淡々と決まりきった作業をすればよいわけではない。
今やっている作業は一体何の目的があってやっているのかを考えなければいけないし、何かトラブルがあればその原因を素早く切り分けて特定していく必要もある。
要は目の前にある具体のタスクのやり方だけではなく、もっとメタ的な視点で物事を見なければならない。
お客さんからの依頼や問い合わせなんて当然曖昧なものなんだから、まずざっくりと全体を俯瞰してから細かいタスクに落とし込むということがどうしても必要不可欠だ。
だけど後輩はどうもそういう事を考えるのが苦手というか、あんまりそういう思考をしてきた経験が無いんじゃないかなと感じている。
高学歴だし技術的なことは学べることからも、すでに体系化された物事を真面目にコツコツと勉強するということに関しては出来るのだろう。
しかし漠然としている物事から素早く本質を見出してざっくりと切り分けてみて必要な要素を抽出したり問題点を洗い出したりするということに思考の方向性が向いていないように思われる。
例えばあるタスクについてその後輩を主担当者として割り振ってしばらく任せてみているのだが、先日お客さんから不具合について問い合わせがあって対応してもらったらよく分からないことを延々とやり取りし始めてしまった。
とりあえずそのやり取りを中断させて一旦後輩と私の二人で話すことにしたのだが、やっぱり後輩の言っていることが中々要領を得ない。
私が頑張って色々誘導しながら30分かけて聞き出した結果、実は起こっていることは物凄くシンプルでかつ特例的に起こることだったのでひとまず今回だけ手作業で対処すればOKというだけの話だった。正直言って、私が後輩の立場だったら問い合わせの30秒後には解決している事だった。
別に高度な技術的な知識の問題とかでもない。というより聞き出して行ったらその部分の技術的なことは後輩もちゃんと分っていて問題の発生原因まで理解していたのに、それをシンプルに抽出してこう対処すれば良いという結論にたどり着くのにこれだけの時間と手助けが必要だった。
お客さんにとっては意味の分からない技術的なことを話し始めたり、全然本質的ではない発生原因について語り始めたりして、全く意味が分からなかったと思う。私ですらこれだけ理解に時間がかかったのだから。
上記は一例だが、何のタスクをお願いしても細部にばかり目が行ってしまって全く全体が見えておらず、何が必要でどこが本質なのかというのをどうも理解する力が無いらしいのだ。
この部分に関しては正直、その後輩の同期たちの中でもかなり劣ってしまっているように思われる。ここまで理解能力が無いというのはちょっと想定外だった。
今2人チームで働いている通り、うちの会社は大抵1人か、多くても数人までのチームで仕事をする。割と若い年次でもどんどん1人で仕事をしたりチームリーダーになったりしなければならない。
しかし今の後輩の状態ではとてもじゃないが1人に任せることはできない。降ってきた依頼を理解してタスクに分解して具体的な指示まで落とし込んでくれるリーダーがいないと働けないだろう。
こんな後輩を、今後どうしてあげれば良いのか本当に悩ましいと思っている。
技術的な面ならいくらでも教えられるし、実際にこの本を読むと良いよと勧めたりとか、仕事に余裕がある時にちょっとチャレンジングなことをやってみてもらったりもしていて、それは頑張ってくれている。
またマインドセット的な部分も例えば研修を受けさせたり私が指導すれば学ばせることもできるだろう。
しかし、そもそもとしての思考力とか理解力とかを身に付けさせるってどうしたらいいんだ。君は頭が良くないから鍛えなさい、と言われても後輩だって困るだろう。そもそもパワハラだろうし。
ましてや「真面目」というのが難しい所で、仕事を休んだりもしないし頼んだタスクをすっぽかしたりとかもしないし人柄としてはしっかりしているからちゃんと育ててあげたいんだけども、そうは言っても恐らくこの職に必要な才能が欠けてしまっているのは私にはいかんともしがたい。。。
ストレートに、真正面からちゃんと話してあげるのが筋なのだろうか。それとももうそういう子だと諦めて、単純な作業者と割り切って考える方にシフトした方が良いのだろうか。本当に後輩の育成というのは難しい。。。
