  |
はてなキーワード: 非エンジニアとは
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 Page Application）にすることでユーザー体験を向上させたい（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 Page Application）にすることでユーザー体験を向上させたい（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では、Tailwind CSSってのを採用しているので、チャレンジしようかなと。ただ、VS Codeで標準で使えるGitHub Copilotでは、「4.x系はまだリリースされていません。」と言ってくる。通常のインストール方法でTailwind CSSをインストールするとバージョンは4.1.8。せっかく勉強するなら最新がいい。他に方法はないかと思い、最近すごいはやっているCursorを試すことに。Astroの構築からTailwind CSSをインストールまで、チャットで指示するだけで、かなり自動でやってくれる。で、早速インストールしたTailwind CSSのバージョンを確認してもらったところ、
package.jsonを確認して、Tailwind CSSのバージョンを確認させていただきます。
package.jsonを確認したところ、Tailwind CSSのバージョンは^4.1.8であることがわかりました。
ただし、これは少し気になる点があります。現在のTailwind CSSの最新の安定版は3.x系です。4.x系はまだリリースされていません。このバージョン指定は誤りの可能性が高いです。
って！ さっきそのコマンドで自分でインストールしたじゃねえか！
そして、ふと思ったのですが、AIコーディングで最新のものを勉強しようとするのは間違えなのではないかと。課金すると最新のバージョンも扱えるようになるのでしょうか？
使用目的としては、仕事で読む論文を読み込ませて質問したり、自分が書いたメールやちょっとした文章を校正してもらったり、趣味的な自然科学や歴史の質問をしてるくらい。画像生成も使ってない。
ゴマすりが最近話題になってたが、ノリがいい。正確に網羅するというよりも分かりやすさ重視という感じ。自分は後輩キャラに設定して雑に質問してる。太鼓持ちみたいな言動も可愛いやつだな、って感じで素直に受け取れるし、質問を褒められるとそれはそれでうれしい。「先輩、それめっちゃいい質問ですね。語らせてください！」みたいな感じ。あと一通り解説したあとに、「後期青銅器文明が滅びたのは今で言うポストアポカリプスだった、とか語れるけど、もっと詳しく掘り下げますか？」のように次のテーマにうまく誘導してくれる。この辺はGeminiやClaudeでは出てこない味。
一番メインで使用。有料登録してる。応答が一番ニュートラルかつこちらの意図を汲みつつ回答してくれる（ように感じる）。仕事関連の論文や校正で主に使用。特に論文は10ページ以上読み込ませて、逐語訳させて、内容のよくわからない点を聞いて、関連情報を聞いて、自分なりの理解を書いて校正させて、と活用している。開発者のAnthoropicの思想も結構好き。Anthoroって人類だよね。
Google driveの容量のためにGoogle oneを登録しているので有料プラン。なんだけど、正直一番出力が肌に合わない。聞かれたことにしか答えないし、内容も肌にしっくりこない。Personalizationも「検索しましたね」とか言われてほっとけと言いたくなる。個人的などうこうではなく人類普遍の知識が知りたいのこっちは。
R18方面で一部から大人気（？）。倫理的ガードがゆるい。イーロンは好きじゃないけど世話になってます。ありがとうイーロン。いや真面目な話、自分の性癖を書き連ねると作品になるってすごいよ。マイナー性癖の人とか結構救われると思う。
ブコメ見てて見つけたものに、エンジニアと営業で評価基準が違うのが一つの原因と言ってるのがあった
それを見て思い出したけど、エンジニアの会社で、それ以外の事務とかの部署は評価基準はエンジニアの成果がそのまま反映されるようなってた
エンジニアが中心の会社だからそれ以外の人はエンジニアをサポートするのが目的みたいな考えだったのだと思う
たしかにそうしとけば、エンジニアの人が成果上げてくれるのが自分の給料アップにつながるんだから、エンジニア側に合わせようとするだろうし、こういう問題は減りそうではある
もちろんいくら給料良くてもこいつとは働きたくないというのもあるだろうが
意思疎通がうまくいかない＝エンジニア（IT）がわからない非エンジニア/カスエンジニアのせいという理論から誰ともうまくコミュニケーションがとれないエンジニアがいる
無茶苦茶な理論でゴネ、周りが議論を諦めて受け入れるしかない状態にしたことを論理的に思考できる僕が非エンジニアを論破し、カスエンジニアを導いたと勘違いしているので厄介
この無茶苦茶な理論というのがエンジニアリングとは直接関係がないことが多い
例えば、五千万の発注するのに稟議書を作らないといけないので資料作りを手伝って欲しいという要望に対して、そういう稟議書を出す文化がエンジニアリングを停滞させる！なんて古い会社なんだ！今すぐ発注！とキレられたことがある
会社のルール上それはできない、納得がいかないならやらなくていいと引き上げると僕が確認してない内容で稟議通すつもりですか？！他のエンジニアのレベルじゃできない仕事だ！とさらにキレた
エンジニアの論理的思考＝ビジネスにおける論理的思考と同等のものなので非エンジニアよりもビジネススキルがあると考えている節があり、エンジニアファーストな環境を作るために非エンジニアも導いてやると考えているようで、職責の範囲を超えた口出しをすることもしばしば
地方で一軒家建てられる金額を稟議なしで通せとキレてる時点でビジネススキルどころの問題ではない
その発言は経験の浅い若手のみが許されることであって、30後半の社会人が言うことではないと俺は思う
プロジェクトから外れてほしいがエンジニア人材が枯渇しすぎててこれ以上贅沢を言えない状況
つらい
非エンジニアフリーランスでもローンで買わせてくれた銀行はネ申。
（でも友人の漫画家は三井住友でローンを通した。ただし２年間も地獄のような保険料で苦しめられたとのこと）
今売っぱらえば最低3000万円ぐらい儲かるが、生活空間＋生活環境のために買ったんだから資産上昇なんかどうでもいい。
3LDKだがやや狭い（70㎡）。23区内・山手線なんだから我慢の範疇。
今は大体一馬力1000万。18年の最悪の時期だと700万ぐらい。でも維持はできるし、生活もできる。妻もいる。子供はいらん。犬も猫もいる。うさぎもいる。
もう買いたくて買ったんじゃなくて「買えるなら買わせてみろよ。買えたら両親引き取るから（笑）」と営業に来た不動産ディベロッパーと銀行と協議しながら買った。
まじでボトムで買えたので良かったね。
父を看取った後、母と妻の折り合いが悪くなって母を施設に。その母も去年亡くなった。両親を引き取らなければもっともっと余裕のある生活はあったが、買うと決めた前提が両親の引き取りなんだからそこまでだよ。
まぁ、オマエラの参考にならない買い方してるので、単に「自慢にならない自慢」なんだよね。
いやずっといるだろ。ツッコミきれないけど
とりあえず、下記の意味がわかっていただけたら幸い(でも謎理論で拒否するんだろうな)
ネタ抜きに社内で生成AI使ってもいですよ！ってやってるとこ入ればいいんじゃないですかね
大企業はだいたい入ってると思うけど、地方の場合はまだ社内生成AI無いかもだから、やはり在宅勤務をする
別の増田(ワイじゃない) ↓
非エンジニアだけどClaude3に増田ミュート作ってもらったよ
これを改善してってお願いした。何書いてあるかわからないけど動いたよ。
https://anond.hatelabo.jp/20240125203115
// ==UserScript== // @name 増田ミュート（白塗り版） // @namespace http://tampermonkey.net/ // @version 2024-06-26 // @description ミュートワードを含む最小限の範囲を白塗りにする // @author You // @match https://anond.hatelabo.jp/* // @icon https://www.google.com/s2/favicons?sz=64&domain=hatelabo.jp // @grant none // ==/UserScript== (function() { 'use strict'; const muteWords = [ "弱者男性", "弱男", "弱者", "婚活", "男", "女", "年収", "下方婚", "発達障害", "発達", "ハッタツ", "ハッタショ", "ﾊｯﾀｼｮ", "競プロ", "競技プログラミング", "AtCoder", ]; function whiteoutElement(element) { element.style.backgroundColor = 'white'; element.style.color = 'white'; element.style.textShadow = 'none'; element.style.cursor = 'default'; element.style.userSelect = 'none'; // テキスト選択を防止 element.style.borderBottom = '1px dashed #ccc'; // 枠線を追加してテキストがあることを示す // リンクの場合、クリックを無効化 if (element.tagName === 'A') { element.style.pointerEvents = 'none'; element.removeAttribute('href'); } // 子要素にも適用 Array.from(element.children).forEach(child => { child.style.backgroundColor = 'white'; child.style.color = 'white'; child.style.textShadow = 'none'; }); // ツールチップを追加 element.title = 'この内容にはミュートワードが含まれています'; } function shouldMute(text) { return muteWords.some(word => { const parts = word.split(''); const regex = new RegExp(parts.map(char => `${char}92;92;s*`).join(''), 'i'); return regex.test(text); }); } function findSmallestMuteableElement(element) { if (element.nodeType === Node.TEXT_NODE) { return shouldMute(element.textContent) ? element.parentElement : null; } if (element.tagName === 'PRE' || element.tagName === 'CODE') { return shouldMute(element.textContent) ? element : null; } for (let child of element.childNodes) { const result = findSmallestMuteableElement(child); if (result) return result; } return shouldMute(element.textContent) ? element : null; } function processElement(element) { const muteableElement = findSmallestMuteableElement(element); if (muteableElement) { whiteoutElement(muteableElement); } } function processAllElements(root = document.body) { const walker = document.createTreeWalker( root, NodeFilter.SHOW_ELEMENT | NodeFilter.SHOW_TEXT, null, false ); let node; while (node = walker.nextNode()) { if (node.nodeType === Node.ELEMENT_NODE) { processElement(node); } else if (node.nodeType === Node.TEXT_NODE && node.parentElement) { processElement(node.parentElement); } } } function handleClickEvent(event) { setTimeout(() => { processAllElements(event.target); }, 100); } // 初回実行 processAllElements(); // クリックイベントの監視 document.body.addEventListener('click', handleClickEvent); // DOM変更の監視 const observer = new MutationObserver(mutations => { mutations.forEach(mutation => { if (mutation.type === 'childList') { mutation.addedNodes.forEach(node => { if (node.nodeType === Node.ELEMENT_NODE) { processAllElements(node); } }); } else if (mutation.type === 'characterData') { processElement(mutation.target.parentNode); } }); }); observer.observe(document.body, { childList: true, subtree: true, characterData: true }); })();
