  |
はてなキーワード:フロントエンドとは
WEBを検索したりその業界内部にいる人間にコンタクトを取ったりして情報を集める事が多いだろう。
内部の人間もかなり偏りがある。
本人の立場も大きいが、それ以上に内部の人間は”内部の人間からしか見えない情報”に偏り過ぎており、
そんな折に、俺は長期的にある情報源から動向を読み解く方法を見つけた。
求人情報だ。
求人情報にも色々ある。
例えば【特定の業界名 求人】等で検索をかければ何かしらの求人一覧が出てくる。
（補足しておくが俺は別に特定の求人サービスを売り込みたいわけでは無いからな）
ビズリーチは月5,000円であらゆる業界の求人情報を閲覧できる。
「表の情報」
と照らし合わせろ。
例えば、プレスリリースやニュースサイトの新サービスリリース情報などだ。
この表の情報がインパクトのあるものである程、そのサービスの運営元や開発元がどんな求人を出しているかが見どころだ。
新サービスの発信元が特に求人を出していない場合はスルーして構わない。
しかし、その新サービスの発信元…運営会社や開発会社がビズ○ーチに求人を出している場合は要注意だ。
それも、特定の職種だけでなく、営業、マネージャー、フロントエンド、バックエンド等多岐に渡る求人を出している場合は特に要注意だ。
その裏には何か問題が発生している。
例えば、
・そのサービスが炎上していて収拾の見込みが立てられず、取り急ぎ大量に人員が必要な場合
などが考えられる。
前者の場合でも、後者の場合でも、おそらく開発に問題を抱えている。
問題がある開発現場から良いプロダクトやサービスはリリースされない。
これは少し考えればわかるだろう。
この問題を軽視して例えば投資の類やあるいは本当に「求職」をしている場合は要注意だ。
易々とそこに乗っかってはならない。
待っているのは破滅だ。
結局、この世のサービスやプロダクトの類は「人」が作っている。
どんなツールを使っても、仮に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
先日の日曜、某IT系の勉強会に参加してきたんだけど、そこでも話題に上がったのが「AIによって人間のプログラマーは不要になるのか？」って話。
正直俺も含めてその場にいたほとんどの人間が、腹の底ではいやいや、それはないっしょって笑ってたわけ。
たとえばChatGPTとかGitHub Copilotとか、最近はTabnine、Amazon CodeWhispererなんかもあるけど、どれも便利ではある。
でも結局のところAIが書いたコードの品質をチェックするのは人間だし、プロンプト自体が難しいから結局基礎ができてないと無理だよねっていうある種の安心バイアスがあった。
でもその考え、甘かったっぽい。
聞いた話では今のAIでは分業化が進んでるらしい。
例えば、一般的な言語モデルであるGPT-4はもちろん優秀なんだけど、今はそこからさらに“ドメイン特化型”のAIが開発されていて、分野別に専門AIが配置されてる。
データベース設計ならこのAI、フロントエンドならこっち、セキュリティに関してはあっち、みたいな。
つまり何が起きてるかっていうと、素人が「こういうアプリ作りたいんだけど」ってざっくりした質問をしたとしても、AIの中で自動的に専門家AIにルーティングされて、実際にプロレベルの回答が返ってくるようになってきてる。
人間の経験とか判断力に頼っていた領域が、いよいよAIに侵食されはじめてる。
しかも進化スピードが異常でMistralやAnthropic Claude、MetaのLlama 3、Google Geminiあたりの最新モデルはすでに「構文の正しさ」や「コード全体の可読性」まで含めて自己チェックできるようになってきてるらしく、OpenAIが次に出すGPT-5では、おそらく「仕様の良し悪し」までも判断できるって噂まである。
もうこうなると、中堅レベルのプログラマーが真っ先にいらなくなる可能性が出てくる。いやマジで。
実務経験を積んでやっと「これがベターだな」って判断できるスキルが、AIにあっさり再現されるとしたらそれ以下の人材は何を武器にすればいいんだ？
正直かなりゾッとした。
俺も完全にその中堅側にいるから。
これまではいくらAIがすごくても使いこなせるのは人間だけって思ってた。
でも今後は違うかもしれない。
……たぶん、生き残るのは本当に一握りの設計思想まで含めて自分でAIを育てられるレベルのプログラマーだけになる。
言語でいうなら、RustやGo、TypeScript、Kotlinとかをベースに、フレームワークだけじゃなくて抽象化の設計思想まで一人で持てるような人。
おかげで週末はとっても陰鬱な気分で過ごす羽目になった。
45歳でフロントエンドもできるバックエンドのソフトウェアエンジニアです
ここ数年はフリーランスエージェントを使って現場に入っています
50歳になる前にそろそろ会社員に戻るかと思って転職活動をしてるけど渋い
1000万あるから会社員なら700万くらいまで下げないと思ってるけどそれでも高いらしい
600万希望でも高いみたいだけど500万まで下げたら今の半額じゃねえか
50歳過ぎて仕事がないとか、AIで仕事がなくなるとかのリスク考えたら500万も視野にいれるしかないのか？
あと5年で5000千万稼いで50歳でエンジニア引退の方がいいかもと思ってきた
もし仕事なくなったら清掃員とかして余生を過ごすか
会社員になっても60で定年なら10年余計に働くだけだしそっちの方がいいかもと思う
昼メシのUber EatsつつきながらSlack眺めてたら、非公開チャンネルに不穏ワードが爆誕してて笑った。
いや、笑えんわ。いよいよ “アクセに身売り” の噂、ほぼ確だって？
──は？ はぁ!? こちとら週イチLTで「世界ぶっ壊す！」って雄叫びあげてる最強ベンチャー様だぞ？
週末はReact＋Next.jsで自社プロダクトを夜な夜な爆速リリース、PRは秒でセルフマージ。
朝会は “OKR？知らん！” のテンションで「とりまKPIは宇宙！」とか言っときゃ許される──それがカルチャーだった。
なのに今日、CTOがAll-Handsで「合流シナジー」とかカタカナ並べ始めた瞬間、チームのZoomが凍りついた。
カメラ越しでも分かる、あの “終わった”空気。マイク切ってDiscord裏窓で叫ぶしかなかったわ。
ポモドーロが爆散した。
達成度は「クォータリー360レビュー」でランク付け？ 何それ、ブラック魔導書？
──はぁ？ 技術書1冊で超えるんだけど？ 草。枯れるわ。
オフィスだって、“カフェスペース”に鎮座してたレゴ・デロリアン撤去だと？
あのレゴが何百万の調達ミスを救ったか、シニア層は知らねぇんだよな。
Slackの新人チャンネルでは、案の定「これでもポジティブに行きましょ！」とか空元気のスタンプが飛び交ってる。
悪いけど無理ゲー。
そこに“PMOガバナンス”をねじ込むとか、自分のGitの履歴に「Fix governancebreach」ってコミット残す罰ゲームかよ。
夜、恒例の“深夜メトリクス祭り”でGrafana眺めながら、ふと思った。
でもそれ、オレたちが「自由にぶっ壊せる」から叩き出せた数字だ。
明日からアクセ式チェックリストで “承認フロー: 7-Step” とかついたら？
ま、とりあえず社外公開してないOSS支援botのトークンだけは今夜中にrevokeしとく。
次に会議室で名刺交換するころには、名刺のロゴが白黒の世界支配企業になってるかもしれんしな。
でも──絶対忘れんなよ。
“自由はForkできる”。
巨大コンサルのバグに巻き込まれても、オレのGitHubアカウントだけは、スタートアップ魂フルコミットでPushし続ける。
理数系の院卒クラスだと覚えが速い。そもそも大学などでプログラミングをやっていることも多く本当に業務として未経験なだけだったりする。3ヶ月ぐらいで平均を追い抜く。
東大京大や海外エリート大学あたり。彼らは知り合いに強いエンジニアがいるので情報収集力がレベチ。勉強慣れしているので短期間で猛成長する。入社前に平均を追い抜いていることも。
留学帰りクラスではなく、near nativeレベル。情報の獲得速度が速い。調べるときはすべて英語。読む速度が速いのでキャッチアップが速く、概念をつかむのが速い。フロントエンドなんかをやらせると強い。半年後あたりに平均を追い抜く。
学生のときにプロジェクトをやっていたり、趣味でひたすらコードを書いているようなやつ。プロジェクトを量産しているので、入ったばかりのときは慌てるがすぐに頭角を現す。最初から平均越え。
他業種のエースで人生安泰なのにわざわざピボットして業種転換する狂人。エースのプライドがあるのか人生かけて猛追してくる。非常に打たれ強く根性で学習し、休日も返上する。半年後ぐらいに平均を追い抜く
1年前：「かゆうま」みたいなノリで匿名日記を書くサイト作って4年が経った
世の中的にはすっかりコロナも日常のものとなった。むしろコロナ予防接種は65歳以上の人や60〜64歳で重症化リスクの高い人に案内が届く程度で、インフルエンザよりも軽い扱いとなってしまった感がある。
一方、我が家では昨年嫁も子もコロナに感染し、嫁は1ヶ月ほどブレインフォグ的な症状に悩まされていたりした。
昨年「オフィス回帰はなんだかなぁ」と書いたが、この1年も週5日出社義務が増えてきた。アクセンチュアが週5出社になったのは象徴的だった。
一方で、ChatGPT等の生成AIの進化が目覚ましく、「音声入力」による生産性革命が起きてるように思う。
骨しゃぶり氏やけんすう氏などは「生成AIにブツブツつぶやけば爆速でドキュメントができる」という話をしてたり、Zoomなどのビデオ会議の文字起こしの精度も上がってきて各自入れば誰が話したかも記録してくれるのはかなり便利だ。
自分もリモートワークの日は家でブツブツつぶやきながらドキュメントを作成したり、今後の仕事の進め方を生成AIと壁打ちしてるがめちゃめちゃいい。むしろ出社するとデスクでブツブツつぶやいてると変人なのでこれができないのがツライ。
おそらく今後フルリモートを維持した会社と出社義務にした会社の生産性が如実に開いて、出社義務にした会社は淘汰・駆逐されると予想してる。
あと単純にフルリモートできる超優秀層がどんどんフルリモート会社に転職していくだろう。採用戦略的にも今ならフルリモート押しするだけで、元アクセンチュアは採り放題だ。各社人事部には強くおすすめしたい。
去年「趣味のゲーム開発のためGodotを勉強中」と書いたが、これは結局時間が取れずに途中で止まってしまった。
最近は平日も子どもが23時過ぎまで寝ず、週末は10〜22時で外に遊んででマジで物理的に可処分時間が無くて大変弱っている。
去年は週1の療育が3時間あったので、その時間で勉強・開発をしていたのだが、今年から1時間に戻ってしまい自由時間が激減してしまった。
「DevinやReplitなどのAIエージェント使えば、スマホから開発できるかも!?」といろいろ試してる。先日Replitを使ってReact Router v7 + Supabase構成のサービス作成をAIエージェントにお願いしてみたところ、フロントエンドはいい感じに作ってくれたのだが、Supabaseのテーブル作成を試みて無限にエラーが返ってくるというのがあった。なかなか難しい。いろいろ試していきたい。
恩師は現役時代も本業とは別に県下の留学生向けの交流会を長年運営してたり、毎年マラソンを走ってたりとパワフルな人だった。
引退後は留学生寮の運営もはじめたり、コロナ前頃からは子ども食堂やったり、フードロス対策NPOの地方進出を手伝ってたりとますます活動の幅を広げていた。また70歳を過ぎてスペイン版お遍路巡りのサンティアゴ巡礼で800km歩いたりもしてた。
亡くなった日も留学生寮で新年会をしててめちゃめちゃ元気で本当に突然だったそうだ。
本人はまだ野望がたっぷりで無念だったかもしれないが、いろいろやってて楽しい人生だったんだろうなと思った。
よく死ぬ前に後悔することで「あんなに仕事しなければよかった」というのがあるが、恩師を見て「やりたい放題仕事するのはいい人生だな」と思った。
自分も引き続きサービスを作りつつ、引き続き「かゆうま」みたいなノリで匿名日記を書くサイトこと「COVID-19流行下の日々を集団で記録する日誌」をゆるゆる続けていきたいと思う。
■COVID-19流行下の日々を集団で記録する日誌https://enigmatic-brushlands-82725-herokuapp.com/
5年前：「かゆうま」みたいなノリで匿名日記を書くサイト作った
4年前：「かゆうま」みたいなノリで匿名日記を書くサイト作って1年が経った
3年前：「かゆうま」みたいなノリで匿名日記を書くサイト作って2年が経った
2年前：「かゆうま」みたいなノリで匿名日記を書くサイト作って3年が経った
夜は楽しみにしていた星街すいせいの「もうどうなってもいいや」のMV公開を楽しみに過ごしていた。
もうどうなってもいいやを聴きながら、急にやる気が出た自分は、
スーパーでスパークリングワインのボトルを買い、
飲んだ薬はよく覚えていないが、
・オランザピン
この辺りをおそらく合計200錠くらい、スパークリングワイン750mlと一緒に飲んだ。
ある程度飲んだ時点で一度お手洗いに行き、紙オムツを装着しようとしたが、
仕方ないので尿取りパットを2枚あて、パンツを履いてなんとかしようとした。
そしてベッドへ行き眠りに着いた。
もし自分が死に成功した際に、SNSで告知してもらう様に、PCのパスワードなんかを送った。
目が覚めたのは恐らく金曜日の夜だったと思う。
来るはずがない交際相手がなぜかその晩マンションを訪ねて来て、
自分は床に寝かされていた。
なぜ床に寝ていたのかその時はわからなかったが、
声も出せず、
相手に何か伝えたくても何も伝えられない状況だった。
しばらく身体が動かないまま、トイレに行きたくても行けない状況で、
トイレに行きたいとも言えない状況で、
恥ずかしい話だが床にそのまま放尿していた。
明日も同じ状態であれば病院に連れて行って欲しい旨を声にならない声で伝えたような気がする。
このまま月曜日を迎えても、一人では何も出来ず、相手が帰宅する事になることなどを考え、
そのまま救急搬送され、病院に辿りつくと、必死で状況を伝えようとかなり荒んだ口調で医師に話をしたと思う。
内科の診察にて、筋肉が溶ける病気か何かの症状が重いという判断で、
しばらくはブドウ糖か何かの成分が中心の点滴を数日間受け、
その後の検査で吐瀉物が肺に入ったせいで重度の肺炎に感染している事が分かり、
そうやって約2週間病院で過ごし、4月25日の金曜日、約2週間の入院を経て退院となり今に至る。
すっかり痩せ細り、入院費用約30万円の借金を抱えた自殺未遂者が一人この世に取り残された。
ODを楽しんでいる若い子、ODが命綱となっている依存症の子、
それによってなんとか縋りながら生き延びている子も居るわけだし、
それによって命を落とした子も、当人にとっては死ぬことが幸せなのかもしれないと思っている。
ただ、オーバードーズ老人会の自分のような人間がもし存在するのであれば、
ODを繰り返す事で薬の量や種類の工夫をし、
自分のように無様に生き残るケースもある事を知って欲しいと思った。
誰にも助けを求められないような年齢で、
貯金も職もなくただ借金と身体的不調を抱え、生きていく羽目になるケースがある。
生きるか死ぬかは本人の意思で決められる世の中になって欲しいとは思う。
ただ、今ここに存在しているのは、
借金と弱った身体で生き延びてしまったただの人間が一人いる、ということだ。
Permalink |記事への反応(11) | 17:39
ここ最近、ソフトウェアエンジニアが仕事にLLMを活用することが当たり前になった。
多くの一般的なエンジニアは個人の生産性向上を目的に利用している。VSCodeのGitHub Copilot拡張にはじまりClineやらCursorやら、個人の開発生産性をいかに上げるかにフォーカスしているもの言ってみればコードエディタや統合開発環境の延長としてのLLM活用。コパイロット的LLM活用とでも言おうか。
私のような下っ端エンジニアはコパイロット的LLM活用で十分満足してしまうのだが、テックリードやプラットフォームエンジニアなどレベルの高いエンジニアはDevinのようなAIエージェントを活用した開発も積極的にやるようになってきた。AIエージェントは指示出しが明確でタスクも細かくわけないと活用できない(かつコードレビューも必須)ので派遣社員さんを雇っているのに近い。これをコパイロット的LLM活用と比較して派遣社員的LLM活用とでも言えばいいかな。
ここからが本題、最近上記2つとは全く違う視点のLLM活用が増えてきたように思う。題名のようなLLM活用である
一つの業務をまるっとLLMで開発できないかとか、バックエンドだけ開発してフロントエンドは全部LLMに作らせようとか、まるっと開発全部お任せしちゃうLLM活用。
LLMに丸投げするのでこれを外注的LLM活用と呼んでいる。PdMやデザイナーから言われるならまだ理解はできるのだが、このとんでもないオーダーをエンジニアマネージャだったりCTOから指示される事例が増えてきたから困ったものである。
外注的LLM活用の何が怖いかというと大量のコードをLLMに生成させるのでコードの全容の把握ができない、なので当然コード品質の担保ができなくなる、品質担保ができないからセキュリティーリスクも爆上がりする。コードの全容の把握ができないサービスが障害を起こしたらどうなるのか、想像しただけで怖い。
外注的LLM活用を指向している人たちはコード品質やセキュリティーの問題はLLMが進化すれば無くなると考えているからタチが悪い(お前ら本当にエンジニアかと言いたくなる)。
最近仕事で外注的LLM活用に心酔したエンジニアマネージャとCTO(それぞれ別の企業)に遭遇してなんとなく危機感を覚えたのでここに記しておく。彼女彼らは技術力を軽視しプログラマをバカにする。ちなみに外注的LLM活用に心酔したCTOやEMがいる企業はソフトウェアエンジニアの採用を抑制する傾向がある(特にフロントエンドエンジニア)。あとCursorだったりCopilotのような個人の開発生産性をあげるようなLLM活用に予算を回すことはない。
ぜんぶVercelのv0が悪い、知らんけど。
最近、また「フロントエンドはフロントエンドチーム」「バックエンドはバックエンドチーム」みたいな構成のプロジェクトに当たった。
1つの機能を実装したいだけなのに、APIの仕様をフロントが考えて、バックエンドにお願いして、デザインをUIチームに渡して、みたいなことを延々とやっていると、「なんで俺、これ自分で実装しちゃいけないんだろう」って気持ちになる。もちろん、規模が大きくなれば専門性で分けるのはわかる。けど、それって「効率的に見えるだけ」で、実際はコミュニケーションコストという名の見えない地獄を生む。
そしてなぜかこの構成、めちゃくちゃ多い。SIerに多いの？この構成？アホなん？
お願いだから「◯◯機能チーム」とか「検索体験チーム」みたいに、機能でチームを割ってくれ。
フロントとバックエンドが同じ目的で動けたら、それだけで工数3割減だよ。
「あとはあっちのチーム次第です」って言わなくて済む。
自分の担当がプロダクトにどう効いてるか、もっとリアルに感じられる。
正直、「これがチーム開発ってやつか…」と毎回思ってる。
