  |
はてなキーワード:コーダーとは
でもいまだに「それ検索したら自分で解決できるで」って質問を毎日毎日打ち返す日々を送る社内SEワイ氏。
AIが多少コードを書けるようになったところで、ワイ氏が定年退職するまでにワイ氏の立場が奪われるとはとても思えん。
AIがコード書いてくれるようになったからコーダーは絶滅する！とかいう危機感を持てる奴は、それだけで社会全体においては割合がかなり少ない上位層だということを自覚した方がいい。
まぁ、ちょっとコード書けるだけで年収800万みたいな世界ではなくなるかもしれんが。てかそれはもう違うだろうし。
https://rextester.com/LQJV8936
https://glot.io/snippets/hbuw17vwhv
https://onlinegdb.com/52LU2Dvdy
https://codepen.io/tahu-acie/pen/XJXRZZd
堂々の１位である。コンサルだろうがコーダーだろうが技術を通して飯を食う人間なら絶対に読んでおいて欲しいものがコレ。
「正しい前提を共有できていなければ、間違った結論にたどり着くのを回避するのは難しい」と異口同音に多くの人間が語るが、正しい前提とはそもそもなんだろうか？
その一番土台部分にあるのは「正しい心の持ち方」や「仕事に対してのスタンス」であるのは間違いないだろう。
ジジババが武勇伝混じりにそんなものを若者に伝えても、きっと何も伝わらずお互い不満だけが残るに違いない。
だが、湾岸MIDNIGHTならばきっと伝わるはずだ。感じて欲しい。技術で飯を食う人間のあるべきメンタリティを。
１巻の範囲だけでいいので。イキった態度で他人を嘲笑うと人生がとんでもない方向に転がっていくことを漫画を通して感じてくれるだけでいい。
最近は学校教育でも転ばぬ先の杖で大人がフォローしまくってくれるからか、「イキりの因果応報の極地」を見たことがないまま成長してしまっているっぽい人を稀によくみかける。
ウシジマくんとかネットの失敗談とか色々考えたが、一番手っ取り早いのはこの辺かなと思った。とにかく「ヤバいことをしてしまった・・・」を主人公からの共感で感じてくれたら嬉しい。それが欠如した中高年と一緒に働くの本当に怖いから。
必要な部分だけ印刷して置いた奴だけは読んでおいてくれ。マジで頼む。たまに赤ペンとか引いてあるから。
データのほうが検索できて便利だけど、手元に起きながら作業しやすいようにわざわざ印刷してるので、最初の一ヶ月ぐらいはそれを片手に仕事してくれ。マジで頼む。
パピーなんてそんな言葉を知ってるかどうかは現場作業の出来には関係ないしお父さんも知らないだろうね
お父さん書類は太枠部分しか書かなくていいって常識も知らなかったしなんかの会議で挙手の意味がわからなくて聞いてあぜんとされたようだから。
取引先の関係がどういう構造になってるかなんてのも頭に入ってるのは社長の方だろうしお父さんはとにかく家を作ればいいんだろって感じでここまでやってきたんだよ。
んで取引先があるからなんだって？大工の仕事を見ただけでこれは自分にもできるとか思っちゃったわけかな？それって野球評論してる親父と変わらんと思うんだけどどうなんだろう。
職人同士ならその仕事を見てこれは素人だとか出来が杜撰だとかすぐわかるものだろう。プログラムのコードを見て素人かわかるように。
お前がバットを振るだけの簡単な仕事みたいな感覚で大工のやってることを実際やったら素人丸出しだし一生介護が必要ってレベルかもしれんのに、お前はただ言い逃れしてるだけよね
人手不足だからと妥協されてジュニアコーダーレベルでもクビにならないのが大工ってだけでお前がそのジュニアコーダー相当じゃないって言えるのか？
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250910144033# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaMEeLAAKCRBwMdsubs4+SAr7AQDXfykdqKISu/xqAjywiqw59T+T7rxWBzYJlZAIV8T5vQD/b+NmAJHvxYFwB3iDR0tNousADN3sVe865nSlCoTS7A4==8o3i-----ENDPGP SIGNATURE-----
dorawiiです日曜コーダーですぅ
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250825025846# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaKwbtwAKCRBwMdsubs4+SD4lAQDMo3XWjVsVmSjZPdv2RtFApCjMXHpjXqUuDVWMTbX18QEAhXFTTbeHWW44bllEFlv7iADF2amxXx/cdPXUF5mf8Q8==Opz0-----ENDPGP SIGNATURE-----
日曜コーダーにはジュニアにできなくてジュニアじゃないとできること（のぎりぎりのライン）がどんなものかもわかりません。
どんな処理が書けるかあるいは何万行クラスのコードが書けたらジュニア卒業なのかね。
ちなみにブクマのconfirmページで読み込まれるjavascriptも軽く一千万行超えてる感じで遠い世界の人が書いたコードなんだなと感じてしまうけど。
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250825024203# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaKwbrQAKCRBwMdsubs4+SKpiAP9i7fDQzeS/pkKQ/j0nND6q9PVpFJheotclJDeD4oURiAEA+5Ydaq0JG/XJ6VgJojJXLT7gn7Mz/sws5t7fU6RCogE==pOol-----ENDPGP SIGNATURE-----
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
ちーっす。
SES、お前らのことだよ、お前ら。
特に文系とか未経験とかいうフワッフワな連中を「エンジニア」として祭り上げてる構図、あれギャグだろ？
俺はな、大学院でゴリゴリにコンピュータサイエンスを専攻して、修士論文は分散システムにおけるコンセンサスアルゴリズムの最適化、とかいう誰も理解できないようなテーマで書いた生粋のエリートだ。
だからこそ言わせてもらうが、最近の「エンジニア」ってのはあまりにも安っぽくなりすぎた。
「プログラミングスクールで3ヶ月勉強して、Webアプリ作れるようになりました！」
とか、マジで笑わせんな。
しかも、そのコーディングも、はっきり言って俺らから見たら素人レベル。
ググって出てきたコードをコピペして、エラーが出たら「どうして動かないんですかー？」って泣きつくのが関の山だろ？
で、そんな連中をSES企業が「未経験でも月単価50万！」とか言って客先に送り込む。
客先も客先で、人手が足りないからって、そんなポンコツを平気で受け入れる。
結果どうなるか？
んで、尻拭いするのは誰かって？
そう、俺たち、ちゃんとコンピュータサイエンスを学んできた、まともなエンジニアだよ。
彼らは専門職として、プロフェッショナルとして、圧倒的な敬意と対価を得ている。
GoogleやMetaのエンジニアが、日本でいうところの「SESの駒」みたいな扱いを受けるか？バカにするな。
彼らは最先端の技術を研究し、世界を変えるプロダクトを生み出している。
それに比べて日本は？
「エンジニアは消耗品」「誰でもできる仕事」みたいな風潮が蔓延してる。
SES企業は人件費をケチるために、未経験者を安く買い叩き、使い潰す。
そして、その未熟な「エンジニア」どもは、自分の市場価値も分からずに、低い単価で働かされてることにすら気づかない。
挙げ句の果てには、「ブラック企業だけど、エンジニアになれたから嬉しい！」とか抜かす。
もう救いようがない。
コンピュータサイエンスの基礎も知らずに、フレームワークの使い方だけ覚えて「エンジニア」と名乗るな。
そんなんだから、いつまで経っても日本のIT業界は二流なんだよ。
まあ、せいぜい頑張れや。
いつか、俺たち本物のエンジニアが作ったシステムの上で、お前らが動かされてることに気づく日が来ることを願ってるぜ。
WP構築するからちょっとはphpも触れるけど、DBやサーバのことはさっぱりわからん。
平場はコーダー・デザイナー・ディレクターが全部で10人ちょっとくらいの小規模会社。
社長と副社長がいるけど、最近のあいつらが経理以外の何をしてるのかは不明。
長年社長のコネをメインにいろんな会社のオフィシャルサイトのリニューアルやリクルートサイトの新設で食い繋いできたけど、
もうレスポンシブ対応バブルもとっくに弾けたなあ。って感じ。受注は年々減っていて、去年は過去最大の赤字を計上した。
社長も営業活動に飽きたようで、最近はディレクターが営業を兼ねてるのか、クライアントの紹介を頼ったり、安く買い叩いてくる広告代理店の下請けをやったりしているが、売り上げはコロナ禍以降低迷している。
だけど個人的にはこんな安月給では仕様通りに動くコードを打つくらいのことしかやれないんだよな。
「中小企業だからこそ社員一人一人が企画力を持って自社の商品を作っていかないと今の時代戦えない」とか、
経営者のエゴとしてはわかるけど、誰が旨味もないのにお前に都合よく動くと思うか？という。
わざわざこんな安月給で開発しようと思うか？って話でしょ。
安月給で中小企業に来てくれる上に当たる企画のアイデアがあって開発力もある、そんな宝くじみたいな人材の応募をただ口開けて待ってるだけのクソ雑魚経営者のところにそんな人材来ないでしょ。
今時首都圏の大企業の案件も地方の個人が受けられる時代に、よくそんな能天気なこと言ってられるな、と。
DX化で受注も発注も納税もネットで完結する。個人事業主になってフリーランスとしてやってくことのハードルはどんどん下がってる。政治不信で社会保障も厚生年金も当てにならない時代。一般人にとって会社員をするメリットは逆に何だと思ってるの？
「成果を出したら給料上げるよ」ってそんな当たり前のことに釣られて熱意上がると思うか？どうせ当たらなきゃ上がりがないならフリーランスでやるのと同じじゃん。って誰でも思うんじゃないかな。
って気づかない経営者、終わってるだろ。
会社にできることは「先に給料を上げるから成果を出せ」なんじゃないの？
でも確かにもしディレクター陣がメチャクチャ優秀で有能なら、「自分の企画のディレクションはこの人たちに任せたいからこの会社でやろう」って思うかもな。
しかし弊社のディレクターたち吐き気を催すほど無能なんだよな。「当たる企画」があったとして、それが仮に「技術的に可能」でも、大規模な企画はそもそも進行ができないと思う。
Web制作会社なのにWebの知識が全くない、とか最新情報をキャッチアップできていない、なんてのは可愛い方で、
顧客が投げてきた改修指示書を１週間も手元に抱えて、結果クライアントがaunに書いて依頼してくれたことを、サイトの出力に赤ペンで丸写しして渡してきただけ。なんのために？？結局、確認しないと進まないことわんさか出てくるので着手ができず戻り。それを洗い出すのはコーダー。だったら最初からaunのデータを渡してよ。お前があっためてた1週間なんだったの？ディレクター要らねえよ。
小規模会社なのだから、もっとチームで連携したい！とほざくババアディレクター。
仲良しこよしでやれたらいいだろうけど。そもそも不信感がある。ディレクターは全員ババアなんだけど、みんな「女の悪いところ」を遺憾無く発揮してくるタイプなんだよな。
質問したら「責められている」と思いこんで、頼んでもない弁明や、ひどいと逆ギレ、他責をしてくる。
クライアントの動きが遅いがケツはずらせないということで見切り発車で開発スタートしたWebサイト、デザインが上がったところから構築していって、途中でガンガン機能追加されてイライラしていたのはそうなのだが、
終盤に上がってきた絵が最初の仕様じゃ対応しきれなさそうな具合だったので、
「今回のサイトはカスタムフィールドも多いし計算も多いので事前に要求定義→要求定義をしてデザインの前にDBだけは固めておけばよかったですね」って言ったら
「それは気づいたとき言って欲しかった！！なんで気づいてすぐ言わないのか！！スケジュールがまた戻っちゃう！！」とかほざき始めた。
今気づいたから今言ったんだよ。てかずっと言ってたわ。「この絵だけ見てできるかできないか判断しろというなら「できます」と言えますが、この通りにならない画面がでてきたらできません」って言ってただろ。何回も。絵だけで判断させようとするからそうなるんだよこんな解釈の余地しかない仕様があるか。っつってんだよ。なんでわたしが責められないといけないの？？？？
って感じで、自分が間違っていたとか、自分のやり方じゃ足りなかった、って気付かされるのがとにかくイヤみたいなんだよねこのババアたち。
まっっっっっっったくこの老害ババアたちとチームワークを取ろうと思えない。
あと、受注増やせ増やせ言ってるけど肝心のディレクターが「忙しい」を言い訳にしたら自分がボトルネックであることを正当化してるのよ常に。
実際デザイナーとコーダーは手が空きまくってるし、ここ数ヶ月、ディレクター以外で残業している人を見ていないから、ディレクター以外には確かにキャパが余ってるんだけど。
それでディレクターが言い始めたのは、「今後はサイトの構成や仕様の設定はデザイナーが担うように」らしい。
それはいいよ。でもさだったらお前らの給料下げてデザイナーの給料上げろよ。なにしれっと人に自分の仕事押し付けようとしてるんだアホか。
デザイナーたちは優秀だと思う。今まで弱小3社くらい渡り歩いたけど一緒にやってきたデザイナーの中ではかなり上澄みだと思う。
彼らとはまた仕事をしたいかもしれない。私が企画を出すなら彼らに絵を作って欲しいかもしれない。しかしディレクター陣が無能すぎる。
優秀なディレクターってどんな人だろ。作業していて「あれ？これどうすんだ？」って思わないで済む進行をしてくれるのがいいディレクターだろうか。
戻りがなくて、詰まりがなくて、遅れがない。そんなディレクターに私は出会いたい。クライアント次第なところがあるのはわかるけども。こちらでいくらでもフォローできたやろそれ・・・みたいなのが多すぎて辟易する。
まぁなんにせよとんでもない閉塞感の弊社。
他のところは、他の人は、どうしてるんだろって思う。売り上げってどうやったら上がるの？優秀な人材ってどこにいるの？企画って誰がするの？
安月給もらって、見合う程度に頑張って、これ以上は頑張れない。
これ以上頑張らせたいならせめてフルリモートにしてほしい。
じゃなきゃ、もっと頑張るなら、フリーランスになった方がマシだなって思う。馬鹿な役員とディレクター食わせるために頑張るのは本懐じゃない。
同業者の知人が1人、フリーランスになって独立した。賃貸の審査が通らない以外の不便はないってさ。わたしも持ち家だからそれはべつにいいんだよ。高い買い物する予定もないから、ローンもくまないし。
個人開発している人の話。
最近Claude 4Opusなどの優れたコードが書けるAIが出て来てから手でコードを書くのが辛くなった。
今まで10時間かけてコードを書いていても普通だった。（同じようなライブラリなどが見つからない時)
が、最近は「もしこれをAIで書けるなら自分は凄い時間を無駄にしているのではないか？」と考えてしまう。
自分は現状AIを使いこなせていない所もあり、AIでこのコードを書くことはできない。
しかし「AIに精通している他者はこのコードを10分で書いているのいるのでは？」と考えてしまう。
実際にはまだAIでは生成できないようなコードだとしても、このような考えが浮かんで、「コスパの悪い事をしているのでは？」と思ってしまう。
そうしてコードを書く気力が失われている時がある。
今後のAIの進化や、AI操作を習熟すると、考え方も変わるだろうとは思っている。
自分はAIが出てきた当初からAI肯定派で、どのようにコーダーから仕事を奪ってくれるのかと楽しみにしていたが、こんな感覚になるんだなと感慨深い。
想像できないのはお前個人の能力の問題だ。見えてないのは世界の進歩じゃなくてお前の視野の狭さ。理解できないものを否定するな。それは知性の死だ。
それはSIerの病理であって、技術の本質でも未来でもない。腐った体質を正当化して、新技術を嘲笑する態度が業界の衰退を招いてることにまだ気づかないのか。
それを誇るな。進化を拒む者は滅ぶ。技術の世界では変化を拒否することは敗北と同義だ。既得権と惰性で回してる現場を盾にするのは、ただの自己正当化にすぎない。
じゃあ聞くが、そのサポート切れの間に何がどれだけ陳腐化してるか理解してるか？その遅延のツケは全員が払わされる。もはやただの業務リスクでしかない。
古いものをなんとか使おうとする
まさにそれ、遺物への執着という名の自己放尿。進化できない恐怖心を合理化して、今あるものにしがみついてるだけだ。生産性でも安全性でもなく、単なる恐れで止まってる。
つまり現場が老害で腐ってることを認めてるわけだな。だったらその構造を前提にしてAIを否定するな。必要なのはAIの排除じゃなくて、その老害構造のアップデートだろう。
いや、それは「現実を見て行動してる人間」がやってることだ。君がそれをイキりとしか認識できないのは、自分にとって都合の悪い変化を全部見下して処理したいという幼稚な逃避だ。
現実はもう動いてる。AIはコードを書いているし、レビューして、テストして、設計補助までこなしてる。
現場を知らずに遠吠えする前に、少しは実物に触れてから口を開け。さもなくば、お前の言葉はそのまま時代錯誤の自己放尿でしかない。
俺は異業種転職組（異業種の資格職からエンジニアになった）だからいざとなったらそこに戻ればいいと思ってるけど
それより現実的なのはその業種のDXとか謳ってるスタートアップでPdMとかかなあと漠然と考えてる
日本の小さい会社のPdMは本人もバリバリコード書く（書かされている）人が多いので、ドメイン知識がありAIコーダーも人間のエンジニアも使いこなせて
かつ自分で最終調整でコード修正できるPdMとかになれればいいんじゃないかという希望的観測を持っている。
自分は、確かにものづくりが好きではあるけど１から１０まで自分で手作りしたいとは思っていないので、こんな感じの落とし所が将来あればいいと思っている。
今の風潮が気持ち悪いのは俺も同じで、年収は到底維持できないだろうが家具職人とか料理人とか目指した方がいいんじゃ無いかと思うこともある
