  |
はてなキーワード:非エンジニアとは
SIerにいた頃、酷い時は一週間の勤務時間のうち37.5時間全てが会議だった。
自チーム内の進捗確認のmtg、自チームの進捗を課長と部長に伝えるためのmtg、そこででてきた新たな情報をまた自チームに下ろすためのmtg、それが終わったらSESと下請け合計3社との進捗確認mtg。下請けから「仕様が定まってないシステムを作ることはできない」と怒られる。◯務省に「いつ仕様決まりますか」と質問票をぶん投げる。一週間音沙汰がない。残り時間は社内の営業とコールセンターとCSとの会議。なんかもうとにかく怒られる。四方八方から好き勝手にめちゃくちゃなことを言われる。もうリリースしてしまった物に対して「これじゃ我々非エンジニアには扱えない」とか言われる。仕方ないから空き時間で大急ぎで作って渡したツールのソースコードを見て「このif間違ってるよ」とか言われる。でも直してくれるわけではない。
そうこうしているうちに何ヶ月も何年も過ぎていく。
teamsとexcelをマウスが往復するためだけに存在しているノートPC。
システムエンジニアリングにおいて、コーディングやテストをAIに丸投げした後で待っているのはこういう生活である。
あなたたちはプログラミングがしたくてエンジニアになったのに、なぜわざわざ会議とエクセルだけで埋まる生活を送りたいと思うのか。
「誰でもできるコーディングはAIに任せて人間しかできない素晴らしい仕事を」という考えは夢を見すぎている。
自分で手を動かさないで人に命令しているだけでお金が欲しいなら起業でもしたほうがまだマシだ。
AIにやらせるAIにやらせるとそればかり言っている人が一体どこを目指しているのかわからない。
ずっと寝っ転がってお菓子を食べながら「ヘイAI、なんか楽なシステム作って」と指示するだけの暮らしではないよね？
でもあなたたちが漠然と思い描いているゴールはどうもそっち寄りに見える。
SIerの古株にはしばしば実際に客にお出ししているプロダクトの中身を全く理解しないまま何年も積み重なった複雑な仕様を自然言語だけで暗記しているやつがいる。そいつらはすごい偉そうにふんぞり返っている。
そいつらがいなくなったら誰も仕様がわからなくなるからだ。生き字引としての確固たる地位に縋り付いて生きている。
AIにコーディングを任せた結果残された人間は必ずこうやって知識にあぐらをかいてブクブク太っていくと思う。
AIによって属人化を解消して新時代を築くはずが、気づけばAIによって技術を更新する権利は奪われ、残ったカスみたいな仕事に縋り付いて無駄金をチューチューするだけの無能集団に成り下がるのである。本当にそれでいいですか。
ふと姉のことを思い出した
姉は国文学科卒だ
小学生の頃から百人一首の大会に出て上位成績を取ることもあった彼女は、古典の勉強をしたいと浪人してまで私大に入った
しかしその後は大学生活が楽しすぎて留年、一応教免も取ったが、卒業後は国文学のコの字もない、中小企業の営業部に就職した
そして結婚、出産を機に退職し、子どもが保育園に入れる年になりまた別の中小企業の営業職へ
売っている物は前の仕事とは全然ジャンルが違うが、体力があり口がうまいのでそれなりにやれているようだ
小学生の頃から熱中するものがあり、大学進学の段階でやりたい事を見つけていたとしても、それが仕事になるわけではない
一般人の人生の一貫性なんて、みんなこんなものなのかもしれない
子どもの頃から野球、野球、野球でメジャーへまで登り詰める大谷翔平のようなストーリーはどこにでもあるわけではないのだ
かくいう私も、高校卒業時点でやりたいことがなくフリーターになり、一年無駄にして専門学校に進学したが、就職後勉強した分野が全然自分の肌に合わない事に気づき、転職エージェントによりIT系企業にねじ込まれて非エンジニアとして働いていたが、本当は全然興味もないし効果があるとも思ってない事を嘘八百並べて売り込むことに病んでしまい、しばらく無職をやって現在は肉体を割と酷使する仕事をしている
ホワイトカラー、デスクワーク以外はできないと思っていたが、むしろ働いた実感は今の方がある
一日働くと疲れてぐっすりと眠れる
私が子どもの頃に夢中になっていたのは児童向けの本、ピアノ、お絵かき、犬の散歩、部活でやっていたトランペットくらいだったが、音楽が趣味として残るわけでもなく、私の人生にもまた一貫性などないのだった
おそらくこれからもないだろう
みんなはどう？
非エンジニアだが、これはかなりいいよ
https://qiita.com/advent-calendar/2025/kuso-app
今までの一番のお気に入りはこれ
「教育虐待ガー」とか言ってる層って、マジで日本の教育システムを単なるブラックボックスとして捉えてるんだよね。
でも実際は、日本の教育は競争アルゴリズムに基づく階層ソートシステム なんだよ。
入力パラメータ（学習量）を下げれば、アウトプット（進学・所得・婚姻市場ポジション）が劣化するのは仕様 であって感情論じゃない。
だから「可哀想だから詰め込みやめろ」と言うのは、システムの根幹ロジックを理解せずに設定値を勝手に下げる危険なパラメータ変更なんだよ。
日本社会は
つまり教育を削るという行為は、スコアリング関数の入力値を意図的に下げるのと同義。
当然、最終アウトプットは弱者男性という低スコア領域に落ち込む可能性が跳ね上がる。
これを下げた瞬間、
進学機会が減少（選択肢のサブセット化）
という 不可逆なデグレードが発生する。
これを回避するには、インプットを削らないのが最も効率的なんだよ。
まるで、性能要件を理解しない非エンジニアが、「その処理重くない？」とだけ言ってくる感じ。
それは 数千万〜数億円規模の長期的機会損失 という隠れたデフォルト・リスク。
でも外野はただの**無責任ノイズ（noise）**を発してるだけで、何ひとつ責任領域を持たない。
損失補償者（compensator）
意思決定権者（decision owner）
が一致している必要がある。
しかし「教育虐待ガー派」は意思決定に関わるくせに、リスクも損失も負わない。
これ、システム開発なら完全にアンチパターン（責任分離の破綻） なんだよ。
「サラリーマンの平均生涯年収3億円」はよく語られるけど、教育量の削減によって階層ダウンした場合、これは普通に大きく失われる期待値なんだよ。
つまり外野が無責任に発する「可哀想」って言葉は、他人の将来資産を数億単位で毀損するトリガーになり得る。
そのリスクを認識していない時点で、教育議論に参加する資格がない。
最終的に問うべきなのはこれ。
当然、誰も取らないし、払わない。
remonoilあいつら出社したらコミュニケーション捗ると思ってるけどコミュ障＆ネット弁慶だから逆効果なんだよ。そもそもコロナ前から隣にいる人とすらチャットだったし
https://b.hatena.ne.jp/entry/s/www.itmedia.co.jp/news/articles/2508/14/news072.html
まあ「実力」だけの世界だから、口八丁手八丁でどうにかなる仕事じゃないからな・・・
逆に言うと口八丁でどうにかならん仕事、それがITエンジニアなわけだ
つまり非エンジニアが持っていない責任を背負ってるわけで、ノイズは少ないほうがいい
エンジニアの責任が見えない・理解できないやつはほぼ土人ルートに行くことになる
GPT-5
普通にちょっと読みたい。なんならProにすれば全部書いてくれたりするのか。
だがAIが入ってないあたり書かれたのは2022年以前と予測される。
書きたい人いたらパクって書いていいですよ。
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
仕事でも使ってるけどここでは普通に趣味の調べものでchatGPTがどのように回答したかを参考にリンク張ってみる
deep research機能を使ってる場合が多いので有料版が前提かも
https://chatgpt.com/s/t_685d53dc9f6c81919e10092187f3de07
https://chatgpt.com/s/dr_685d549cbfc08191aadfc8f704ce2de4
https://chatgpt.com/s/dr_685d553568e48191a3a2a9e56ea77831
https://chatgpt.com/s/t_685d5669f394819183469b29c45ccad7
https://chatgpt.com/s/t_685d570b95b08191ac2e1c1ae8614978
https://chatgpt.com/s/t_685d5885eb10819198129b259216feb1
https://chatgpt.com/s/dr_685d59a83928819189d91c7e33dd37ca
https://chatgpt.com/s/t_685d5b0a10e48191944565d3ba17b162
私は非エンジニアですが、飽きては放置を繰り返しながら、WEBページやブログを10年以上やっている。WordPressは2.7ぐらいから触ったことがあるし、オリジナルのテーマを3回は作っている。昨年もWordPressでWEBページを作ったが、そのときは大分ChatGPTさんにお世話になった。まあ、そのWEBページも飽きてしまって、新たに作りたい意欲が出てきたのですが、今回はデータベース系なので、WordPressでやるにはちょっと大変かなと思いいろいろ調べ、Astroってのをやってみることに。
ChatGPTに言われるがまま、Macのターミナルでコマンドを打ってAstroを構築してみたが、はっきり言って何をしているのかサッパリ分らない。改めて、いろいろ調べていくとVS Codeというものに出会うのですが、まあこれも基本はターミナル。ファイルとかインストールしたものなどが見やすくなっているだけとも言えるので非エンジニアの私では、なかなかとっつきにくかった。しかし、Astroをインストールを10回近く繰り返しようやくVS Codeになれてきた。CSVデータから数十ページを構築することもできるようになりました。
データベース的なWEBページの構築メドがたったので、そろそろデザイン的なものに取りかかろうと思ったとき、Astroでは、TailwindCSSってのを採用しているので、チャレンジしようかなと。ただ、VS Codeで標準で使えるGitHub Copilotでは、「4.x系はまだリリースされていません。」と言ってくる。通常のインストール方法でTailwindCSSをインストールするとバージョンは4.1.8。せっかく勉強するなら最新がいい。他に方法はないかと思い、最近すごいはやっているCursorを試すことに。Astroの構築からTailwindCSSをインストールまで、チャットで指示するだけで、かなり自動でやってくれる。で、早速インストールしたTailwindCSSのバージョンを確認してもらったところ、
package.jsonを確認して、TailwindCSSのバージョンを確認させていただきます。
package.jsonを確認したところ、TailwindCSSのバージョンは^4.1.8であることがわかりました。
ただし、これは少し気になる点があります。現在のTailwindCSSの最新の安定版は3.x系です。4.x系はまだリリースされていません。このバージョン指定は誤りの可能性が高いです。
って！ さっきそのコマンドで自分でインストールしたじゃねえか！
そして、ふと思ったのですが、AIコーディングで最新のものを勉強しようとするのは間違えなのではないかと。課金すると最新のバージョンも扱えるようになるのでしょうか？
使用目的としては、仕事で読む論文を読み込ませて質問したり、自分が書いたメールやちょっとした文章を校正してもらったり、趣味的な自然科学や歴史の質問をしてるくらい。画像生成も使ってない。
ゴマすりが最近話題になってたが、ノリがいい。正確に網羅するというよりも分かりやすさ重視という感じ。自分は後輩キャラに設定して雑に質問してる。太鼓持ちみたいな言動も可愛いやつだな、って感じで素直に受け取れるし、質問を褒められるとそれはそれでうれしい。「先輩、それめっちゃいい質問ですね。語らせてください！」みたいな感じ。あと一通り解説したあとに、「後期青銅器文明が滅びたのは今で言うポストアポカリプスだった、とか語れるけど、もっと詳しく掘り下げますか？」のように次のテーマにうまく誘導してくれる。この辺はGeminiやClaudeでは出てこない味。
一番メインで使用。有料登録してる。応答が一番ニュートラルかつこちらの意図を汲みつつ回答してくれる（ように感じる）。仕事関連の論文や校正で主に使用。特に論文は10ページ以上読み込ませて、逐語訳させて、内容のよくわからない点を聞いて、関連情報を聞いて、自分なりの理解を書いて校正させて、と活用している。開発者のAnthoropicの思想も結構好き。Anthoroって人類だよね。
Google driveの容量のためにGoogleoneを登録しているので有料プラン。なんだけど、正直一番出力が肌に合わない。聞かれたことにしか答えないし、内容も肌にしっくりこない。Personalizationも「検索しましたね」とか言われてほっとけと言いたくなる。個人的などうこうではなく人類普遍の知識が知りたいのこっちは。
R18方面で一部から大人気（？）。倫理的ガードがゆるい。イーロンは好きじゃないけど世話になってます。ありがとうイーロン。いや真面目な話、自分の性癖を書き連ねると作品になるってすごいよ。マイナー性癖の人とか結構救われると思う。
ブコメ見てて見つけたものに、エンジニアと営業で評価基準が違うのが一つの原因と言ってるのがあった
それを見て思い出したけど、エンジニアの会社で、それ以外の事務とかの部署は評価基準はエンジニアの成果がそのまま反映されるようなってた
エンジニアが中心の会社だからそれ以外の人はエンジニアをサポートするのが目的みたいな考えだったのだと思う
たしかにそうしとけば、エンジニアの人が成果上げてくれるのが自分の給料アップにつながるんだから、エンジニア側に合わせようとするだろうし、こういう問題は減りそうではある
もちろんいくら給料良くてもこいつとは働きたくないというのもあるだろうが
意思疎通がうまくいかない＝エンジニア（IT）がわからない非エンジニア/カスエンジニアのせいという理論から誰ともうまくコミュニケーションがとれないエンジニアがいる
無茶苦茶な理論でゴネ、周りが議論を諦めて受け入れるしかない状態にしたことを論理的に思考できる僕が非エンジニアを論破し、カスエンジニアを導いたと勘違いしているので厄介
この無茶苦茶な理論というのがエンジニアリングとは直接関係がないことが多い
例えば、五千万の発注するのに稟議書を作らないといけないので資料作りを手伝って欲しいという要望に対して、そういう稟議書を出す文化がエンジニアリングを停滞させる！なんて古い会社なんだ！今すぐ発注！とキレられたことがある
会社のルール上それはできない、納得がいかないならやらなくていいと引き上げると僕が確認してない内容で稟議通すつもりですか？！他のエンジニアのレベルじゃできない仕事だ！とさらにキレた
エンジニアの論理的思考＝ビジネスにおける論理的思考と同等のものなので非エンジニアよりもビジネススキルがあると考えている節があり、エンジニアファーストな環境を作るために非エンジニアも導いてやると考えているようで、職責の範囲を超えた口出しをすることもしばしば
地方で一軒家建てられる金額を稟議なしで通せとキレてる時点でビジネススキルどころの問題ではない
その発言は経験の浅い若手のみが許されることであって、30後半の社会人が言うことではないと俺は思う
プロジェクトから外れてほしいがエンジニア人材が枯渇しすぎててこれ以上贅沢を言えない状況
つらい
非エンジニアフリーランスでもローンで買わせてくれた銀行はネ申。
（でも友人の漫画家は三井住友でローンを通した。ただし２年間も地獄のような保険料で苦しめられたとのこと）
今売っぱらえば最低3000万円ぐらい儲かるが、生活空間＋生活環境のために買ったんだから資産上昇なんかどうでもいい。
3LDKだがやや狭い（70㎡）。23区内・山手線なんだから我慢の範疇。
今は大体一馬力1000万。18年の最悪の時期だと700万ぐらい。でも維持はできるし、生活もできる。妻もいる。子供はいらん。犬も猫もいる。うさぎもいる。
もう買いたくて買ったんじゃなくて「買えるなら買わせてみろよ。買えたら両親引き取るから（笑）」と営業に来た不動産ディベロッパーと銀行と協議しながら買った。
まじでボトムで買えたので良かったね。
父を看取った後、母と妻の折り合いが悪くなって母を施設に。その母も去年亡くなった。両親を引き取らなければもっともっと余裕のある生活はあったが、買うと決めた前提が両親の引き取りなんだからそこまでだよ。
まぁ、オマエラの参考にならない買い方してるので、単に「自慢にならない自慢」なんだよね。
