  |
はてなキーワード:設定ファイルとは
例.
質問：
「firebaseの使い方を知りたいんやけど」
ChatGPT回答：
Firebaseとは、Googleが生み出した「バックエンドいらずの全能実験装置」だ。君がコードを書けば書くほど、知らぬ間にクラウドが裏で息をしている。
データベース、認証、ホスティング、ストレージ、全部詰め合わせ。便利すぎて逆に怖い。
まずはnpm install -g firebase-toolsで召喚だ。
ターミナルでfirebaseloginを叩くと、ブラウザが勝手に開く。そう、Firebaseは君の“人間的アイデンティティ”を確認しないと力を貸してくれない。まるで神のくせに書類主義だ。
ログインが済んだら、firebase initでプロジェクトを構築する。ここが楽しい部分だ。
「Hosting？」「Functions？」「Firestore？」——次々と聞かれるだろう。まるで契約書の小さい文字を全部読み上げてくる悪魔みたいだ。
迷ったらHostingだけ選べばいい。HTMLを置く用の神殿ができる。
あとはfirebase deploy。それだけで、君のHTMLは空に放たれ、URLが授かる。
たとえばhttps://君のプロジェクト名.web.app だ。誰でもアクセスできる。つまり、失敗も世界に晒される。実験とは常にリスクを伴うのだよ、君。
Firebaseの裏には“Realtime Database”や“Cloud Firestore”といった可愛い怪物たちが棲んでいる。彼らはJSONで話す、気難しい連中だが、使いこなせば強い味方になる。データを瞬時に共有し、アプリを“生きている”ように動かす。
ただし、一度でも構成を間違えると——全世界の閲覧者にリアルタイムで恥を晒す。それもまた芸術的だと思わないか？
というわけで、君がやることは四つだけだ。
召喚：npm install -g firebase-tools
構築：firebase init
解放：firebase deploy
君のプロジェクトが光るか燃えるかは、たった一行の設定ファイルにかかっている。ふふ、実にロマンチックだろう？
今まで、たくさんの設定ファイルが考案されてきた。
.iniレジストリxmlluajsonyaml ..etc...
どれも一長一短だった。
例えば.iniはコメントもかけるし、シンプルなkey=value形式だった。だがしかしarrayを表現できなかった。
レジストリはarrayを表現できたがすべての設定を集約したため巨大な密林になった。
xmlは冗長なフォーマットになり、書き手とパーサーの負担が増えた。
スクリプト言語のluaやjsを設定ファイルに使おうぜという動きもあったが、セキュリティリスクもあり普及しなかった。
yamlはコメントはかけるが、これはこれで面倒な形式であり欠点ある。
いろいろ考えた末に俺様がたどり着いたのは、設定ファイルという概念の消滅だ。
設定のスキーマーを定義する共通言語で記述するか、またはYAMLでもなんでもいいから強力なディファクトスタンダートができる。
利用者はやりたいことを"自然言語"で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
認知負荷を考慮に入れているエンジニアの少ないこと少ないこと。
少なくともおいらは会ったことがない。
むしろ、ドキュメントを増やし、設定ファイルを増やし、スクリプトを増やし、手順を増やし、密接な関係にあるソースを切り刻んであちこちのファイルにぶちまけて、その増やした量に比例してエンジニアの腕が評価されるとか考えてる節が見受けられる。
んなわけねーだろ！
SIerみたいに、納品したら終わりじゃねぇんだ。
日に日に巨大化、複雑化するサービス相手に、そういう「フジツボ」を増殖させんなよ、と。
「将来的には全部設定ファイル化して……」
同じ口で「オリジナルのDSLを作るのは……」とか言う、お前の頭の構造を疑う。
Twitterの「the-algorithm」リポジトリをもとに、推薦アルゴリズムを数学的に極限まで抽象化すると、以下のように表現できます。
ユーザー u ∈ U に対して、一連の候補アイテム（ツイート） i ∈ I をスコア付けし、降順に並べて上位 K を表示します。
要するに、以下を最大化する推薦問題です：
argmax{i∈C(u)} S(u,i)
ここで C(u) は候補集合、S(u, i) はスコア関数。
数千万から億単位のツイート全体 Iから、まず候補集合 C(u) ⊂ I を生成。
グラフ構造（フォロー関係）や「SimClusters」「TwHIN」など埋め込みから近似。
検索インデックス（Lucene/Earlybird）による検索スコアによる絞り込み 。
数理的には、潜在空間中でユーザーとアイテムの距離または類似度sim(u, i) が上位のものを選ぶ操作。
候補数をさらに削減。特徴量 xᵤ,ᵢ を簡易学習モデル（線形モデルなど）に入力し出力スコア：
Slight(u,i) = wᵀxᵤ,ᵢ
多層ニューラルネット＋マルチタスク学習で、複数のユーザー行動（いいね、リプライ、リツイートなど）確率 Pₖ(u, i) を予測。
S(u,i) = Σₖ αₖPₖ(u,i)
例：リプライ Pᵣₑₚₗᵧ に重み 27、著者返信あり Pᵣₑₚₗᵧ_ₐᵤₜₕₒᵣ に 75 など。
投稿者がBlue Verifiedなどでスコアを×4または×2倍。
同一投稿者続出の抑制、逆風バイアス（negativefeedback）などが入る。
これは以下のような修正：
S̃(u,i) =mS(u,i)
この構成は一般的なレコメンダシステムの「Retrieval → Ranking → Filtering」の標準パイプラインと整合。
学習モデル fᶿ は特徴量集合・ニューラル構造・訓練データによって依存し、ブラックボックス的。
特徴量 xᵤ,ᵢ は埋め込み、行動履歴、文脈、信頼性指標（tweepcred）等多次元で複雑。
スコア重み αₖ は明示されるが、最適化は A/Bテスト・実システムでの評価に基づく。
信頼性・安全性のルール はフィルタとして明示されるが、その詳細（具体的しきい値など）は省略・秘匿されている。
S̃(u,i) = m(u,i) Σₖ αₖ fᶿₖ(u,i)
ここで、
という、レコメンドパイプラインの抽象テンプレートに帰着します。
Twitterの「the-algorithm」は、コード構造の多くを公開しているものの、モデルパラメータ・学習データ・設定ファイルは秘匿されており、上述パイプラインの数学的な枠組みは把握できても、実際の挙動はまだブラックボックスです。
とはいえ、レコメンデーション理論の観点からは、上記の抽象モデルで十分に説明可能であり、汎用の数学モデルとして整合しています。
超大手IT企業で働き、さまざまな業界のお客様相手にシステム開発を行っているが、その全てでゴミを作って売っている
ここでのゴミとは、システム本体のことではない。システム本体もゴミだが、そのゴミは下請け会社が作るので、関係はない
思えばいろんなゴミを作ってきた
決して読まれない説明書、抜け漏れだらけの管理書なんてものはもう何十回も作った
作った記憶すらない資料がプロジェクト最終盤で全てを破壊し尽くす特大のゴミとなって舞い戻ってくるなんてこともあった
そもそもシステムの設定は大体の場合jsonやらyamlやらの「設定ファイル」の形で存在することが多い。
本来は設定ファイルを、その設定項目と値に関する参考資料を読みながらエディタで編集すれば終わる話だが、これではいけない
とりあえずGUIにしよう
お客様や運用担当者が触る可能性のある場合、これは当たり前のことである
お客様は適当なエディタをインストールすることは規則上できないだろう
また、docx,xlsx,pdf以外の拡張子は「怖い」と感じるように訓練を受けている
問題は、主に触れるのが開発者である場合だが、このパターンでも対処は別に難しくない
ほとんど全てのお客様は不確定事象に対する特殊な訓練を受けているため、「開発者以外が触る可能性がある」と言えば、それで通してくれる
GUIにするという方向で話が進んだら、一件落着、見積書に大量の工数とバッファを積んで、あとは適当に開発者に任せよう
普通の神経をしている開発者であれば、宣言的に設定できるように作るはずだが、この業界の平均的な技術水準を考えると、ひょっとしたら手続き的に設定するようなものを作ってくれるかもしれない
まあどちらでも問題はない
それがこのゴミの非常に素晴らしい点である、どっちでもいいのだ
一般にn個のbooleanな設定項目があり、それらがお互いに相互に依存しながら存在しているとき、最高(最低の意味)の場合、n!通りの設定方法が存在する
設定項目全てが2値ってことはないだろうから、ちょっと多くなったり、一部のグループ項目はそれらだけで独立してたりで少なくなったりはするだろう
ゴミを作るツールはエクセル、ワード、パワポから選択しよう、印刷まで考えると、それが最も困難であるエクセルがベストだ
ツールに大量のスクショを貼っていこう(赤枠を使って適宜強調するのを忘れずに)
そのまま説明をセルに直接書いてはいけない、ふきだしを使ってその中に説明を入れよう
罫線をいい感じに入れよう
目指すのは、ありえる設定と1:1になるような資料だ。普通は網羅できないから、適宜省略して作れるところまで作ろう
このゴミの素晴らしいところは組合せ爆発を利用して、ほぼ無限の工数を消費できる点にある
後々に、1つ設定項目を増やすことになったとき、この資料のメンテナンスがどれほど工数を消費するかは、状態の数から明らかである
宣言的に設定画面が作られている場合は、ちょっとした工夫が必要である
そのまま、それぞれの設定項目と値の意味を書いてはいけない、組合せ爆発が起きないからだ
私の好きなやり方はユースケースに分解することだ
関数もどきを資料内に独自に実装してはいけない、全部コピペで行うのがベストだ
そもそも手順が記載された資料というのはお客様の脳みそというインタープリタに解釈されるプログラムであるが、それが解釈できる構文は非常に限られており、actionの実行と、ifとgotoくらいであるから、関数なんて理解できない
もし、GUI作成の許可が降りずファイルで行う場合でも、このゴミは同様に作れる
設定ファイルをスクショし、赤枠をつけて、ふきだしでコメントを入れるのだ
世の中的には生成AIに要件伝えて生成させたコードをコピペして動かして「はい！生産性爆増！」っぽいけど、生成AIが吐き出したコード読むだけじゃ全然分からん。
Clineで使い慣れた言語・フレームワークのコードを生成させたら見たことがないエラーが出て面食らった。
原因はフレームワークのnewコマンドで自動生成される設定ファイルが全然違う書式で書かれてた。
(どうやら遥か昔のバージョンだとその書式だった模様)
GitHub CopilotやCursorだったら確認しながらtab押してくからこれなら予測変換みたいなものだし大丈夫だろう、おお便利便利……
と思って使ってたのだが、テストするとデータ作成時にフィールドに抜けがある…。
確認したらPOSTするJSONに存在しないkeyが含まれてた。それっぽい名前がサジェストされてそのままtabを押してしまったらしい。
手動でテストしてたから助かったが、この手の外部API使って更新する系はテストをモックしてたりするので危うく本番障害になるところだった。
それこそ特にこれまで触ったことない言語・フレームワーク・ツールを使ったコードを生成AIに吐き出させてもさっぱり分からん。
読むだけだとさっぱり分からないので結局生成されたコードを写経しながら、分からないところをググったり生成AIに質問したりでやってるんだが、まあコピペ勢が40秒でPR上げてるところを、2時間・3時間とかけてるからまあ生産性が悪い悪い。
昔から書かないと覚えられなくて、学生時代もテスト前は過去問解く前にまずは授業中に取ってたノートをとにかく写経してた。
友人からは「過去問だけやって、よく分からなかったとこだけ該当部分をノート見れば分かるじゃん」と言われたが分からないのでしょうがない。
あとプログラミングだけじゃなくて、議事録も最近はZoomとかが自動生成してくれるようになった。
が、こいつがとにかく俺と相性が悪い。
これまでは自分で会議中に議事メモを書いて、終わった後に手直しして論点やToDoをまとめてたので会議の流れややるべきことが頭というか体に入ってきてた感じだった。
それが自動生成されるようになって、確かに時間はかからなくなったかもしれないが、流れとかやることとかが全然頭にも体にも入ってこなくなってしまった。
議事録については結局自分用にメモを取って、あとで自分用に論点やToDoをまとめるというのをやってるが、正直会社から見ると「生産性が低い奴」なんだろう。
おそらく元々読めば理解できるタイプ、それこそ教科書を何回か読めばテストで点を取れるタイプはコード生成AI時代に大活躍できるのだろう。
あるいは今後出てくるコード生成AIネイティブ世代は書かなくても理解できるのが当たり前になったりするのだろう。
……いやそんなことあるか？
これそもそも生成AI以前から「手を動かさなくても公式のREADME読めばすぐ使える」みたいな能力で、そんな奴ごく一部だろう。
教科書何回か読めばテストで点が取れるのも塾行かなくても東大合格できるみたいな特異点みたいな人間だろう。
これまでは結局のところ人海戦術で各言語・フレームワークなどを理解して、大量に書く必要があったから書かないと理解できない俺のようなオールドタイプもプログラマーになれた。
しかし今後はコード生成AIが言語・フレームワークは理解しててすごい勢いでコードを生成してで生産性は爆上がりするから、読めば理解できるニュータイプしか生き残れないのかもしれん。
それこそビル・ゲイツ氏はExcelのレビュー時に仕様書500ページを読み込んで1900年閏日問題について的確に指摘したり、岩田聡氏は任天堂取締役室長時代に週末でNINTENDO64のグラフィックスチップの制御命令コードを完成させたりしたそうだ。
そういった人ならコード生成AIが出したコードについても目grepで瞬時にバグを見つけて直して爆速リリースとかできるのだろう。
……凡人には無理ゲーすぎるな。
なんてか、最初は教訓的に
「良い子の諸君！書かないと覚えられないと詰むから、読んで覚える力を強化したほうが良いぞ」
的なことを着地点で考えてたけど、これもはや地頭が良いとか先天的にニュータイプしか生き残れないやつや。
生成AIがコードを産むなら、みんな死ぬしかないじゃない！(読んで覚えられる)あなたも、(書いてしか覚えられない)私も…（錯乱）
中古で買ったネットブック（AcerAspire One ZG5 2008年の製品）をアップグレードし、Linuxディストリビューションをインストールし、軽作業ができるようにしていた。
本体キーボードが壊れることも含めて、あらゆるトラブルに遭い続けている。
直近ではDebian11 32bitをインストールして一通りの作業はできるようになっている。
CPU:Atom N270 (single core 1.6Ghz)
RAM: 1.5GB
ディスプレイ: 8.9インチ, 1024x600TFTLCD
OS:Debian GNU/Linux11 (bullseye)i686
前の現場ではそれで採用されてた。あと、型定義とかをフロント、バックで共通化できるから開発効率も上がるだろうと。（上がんなかったけど。）
正直、
みたいなことが多くて、言うほど使いやすく無いよな…、とは思った。
というか言語合わせたけど、フロント担当はバックエンドに謎の苦手意識持ってて触ろうとしなかった（逆も然り）ので、全く意味なかったよな。
いきなり本格的な広告管理ツールを作るためにデータベース設計するのではなく、最初は簡易的なプレーンテキスト形式の設定ファイルで管理するところから始める。
そうすれば当面の間はその簡易機能で対応できるし、対応の速度も早い。
広告管理のスケールが大きくなってきたと感じたところで広告管理のCRUDを設計するのでも遅くはない。
ただし、このアプローチを採用する際には、将来的にデータベースに移行することを見越した設計をすることが重要。
具体的には、設定ファイルの形式を選択する際には、データベースに容易にインポートできる形式を選ぶこと、また、データの整合性を保つための適切なバリデーションルールを設けることなど。
「ソースコードに間違いが見つからないのに想定される出力をしない。あるいはソースコードに修正を加えていないのにいきなり想定出力を返すようになった。」
こういう経験がある人はいるはずだ。なぜこれが起こるのか。一つの原因を見つけた。
それは環境変数や設定ファイルに存在する。デプロイ時には設定ファイルを特定の値に修正してから、ということがあるだろう。
開発環境でコーディングする人が、デプロイ時の設定ファイルには関与せず、デプロイの担当者がそれを把握している。
開発者はセキュリティ上の理由でデプロイ時の設定ファイルの内容を見ることができない。
この場合、設定ファイルの内容が間違っていても、開発者が原因が正しく特定できないケースがあるのである。
対処方法は以下である。まず事前にやっているであろう対処は以下である。
追記:
他に遭遇したケースは、環境のアップグレードによってphpが特定の関数を廃止したというケースだ。
ブログやIT技術者向けSNS等は利用しておらず、はてブやTwitterでやるにはやや長いので、増田に投稿
Windows 10 (22H2 19045.4170) 上のEdgeを、数十のタブを開いたまま新バージョン (123.0.2420.53) に更新したらハングアップしたため、タスクマネージャーで強制終了させた
その後Edgeを起動させようとすると、更新時に閉じたセッションを復帰させる段階で強制終了するようになり、使用不能になった
Edgeに導入していた拡張機能には、Session Budy (4.0.2。GoogleのManifestV3に対応するため、最近大規模改修を実施(1。増田の最終節の同番号を参照。以下同)) やuBlockOrigin (1.56.0。新規のマイフィルターを多数追加中だった) 等があった
「Edgeが起動しない」と直截な語句で検索していくつかの解説ページにたどり着いた
いくつかの解決策(2・3)を実行したところ、有効ではなかったが次の知見が得られた
数日程度では修復できないだろうと判断し、別のChromiumブラウザを使いつつ、片手間で修復方法を調べることにした
Windowsの設定画面等にあるリンクが有効になるよう、デフォルトのwebブラウザをEdgeから変更した
パスワードは別ツールで管理してたため無くてもそんなに困らなかったが、uBlockの設定とSession Budyで雑に保存してた閲覧履歴は必要だったので、Chrome拡張の復旧作業をした
"Default\Local Extension Settings"以下のフォルダと、念のために"Default\IndexedDB""Default\Local Storage\leveldb"の中身を移植(8)して作業完了
アイテムの履歴データ破損が問題の原因ではと考えてその修復や初期化方法を検索したが、これは徒労に終わった（ただし、このアプローチが完全に無効だとは言い切れない。参考ページ5は、復旧作業完了後に見つけた情報で、今回の問題に活用できずに終わった）
「コントロールパネル→システムとセキュリティ→セキュリティとメンテナンス→信頼性履歴の表示→問題レポートをすべて表示」で確認できた、Edgeの問題の要約やイベント名等で検索したところ、再インストールを勧めるページが数点引っかかった
既に何日も経ちWindowsの再インストールかユーザーアカウントの作り直しをしようかと考えかけていたが、もう少し努力してみることにした
Edgeを (アプリファイルを手動で削除したりするのではなく) なるべく安全にアンインストールすれば、正常に再インストールできるのではと考え、検索結果通り(11・12)に作業してみた
それでも「アプリ」のアンインストールメニューは無効なままで操作できなかったが、他に事例が無いか、"IntegratedServicesRegionPolicySet.json"等の関連語句で再検索した
コマンドラインでアンインストールを試みた事例(13)が見つかり、実行したらEdgeが削除された (ただし、コマンドプロンプトでもポップアップウィンドウでも実行結果の表示がされなかった)
そして参考ページ4のインストーラを実行し、念のために修復とOSの再起動をかけ、Edgeの起動を確認した
Microsoftアカウントにログインしていたため、パスワードは簡単に復旧できた
拡張機能は全て死んでいたが、仮に使っていたChromiumブラウザからコピペしたりエクスポートしたりして終了
利用していた拡張が少なかったので、プロファイルフォルダの内容の移植よりもその方が簡単だった
1. SESSION BUDDYV3 END OFLIFE |Googleグループ
https://groups.google.com/g/sessionbuddy-discuss/c/HQPcLOq3-Ik
2.MicrosoftEdgeが直ぐ閉じてしまう。 |Microsoftコミュニティ
https://answers.microsoft.com/ja-jp/microsoftedge/forum/all/microsoft/c414d2f9-b685-471c-8e78-2054c2e26c6c
3. ある日突然「MicrosoftEdge」が開かなくなった、さあどうしましょう：山市良のうぃんどうず日記（224） |＠IT
https://atmarkit.itmedia.co.jp/ait/articles/2202/02/news009.html
https://www.microsoft.com/ja-jp/edge/download?form=MA13FJ
5.Windows10の「タスクバーにピン留めしているアプリ」の、「最近使ったもの」と「固定済み(いつも表示)」の設定ファイルとレジストリはここにある #Windows10 |Qiita
https://qiita.com/RyoIchimura/items/7e33980358f07e57a715
6.msconfig（システム構成）で解除してよいのは？使用場面と起動方法 |ドスパラ通販【公式】
https://www.dospara.co.jp/5info/cts_str_pc_msconfig.html
7.WindowsHello の概要とセットアップ |Microsoftサポート
https://support.microsoft.com/ja-jp/windows/windows-hello-%E3%81%AE%E6%A6%82%E8%A6%81%E3%81%A8%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97-dae28983-8242-bb2a-d3d1-87c9d265a5f0
8.chrome.storageの実体の場所 #Chrome |Qiita
https://qiita.com/k7a/items/cf644471d34d31f398e9
9. 第2回 グループ・ポリシーとは何か：グループ・ポリシーのしくみ（3/5 ページ） |＠IT
https://atmarkit.itmedia.co.jp/ait/articles/0602/23/news119_3.html
10.MicrosoftEdgeブラウザーポリシーに関するドキュメント |Microsoft Learn
https://learn.microsoft.com/ja-jp/deployedge/microsoft-edge-policies
11.Windows11/10からMicrosoftEdgeをアンインストールするシンプルな方法が見つかる |ソフトアンテナ
https://softantenna.com/blog/windows-11-10-uninstall-edge/
12. Releases · thebookisclosed/ViVe |GitHub
https://github.com/thebookisclosed/ViVe/releases
13. 各チャネルごとのEdge 削除状況 | 内気なもんた君
稟議書を作成して外部ファイル名の採番をライブラリアンに依頼する。稟議にはPL、PM、CIOの承認印が必要
本番サーバーに新規ファイルを作成する必要がある。ファイル作成バッチを作成しレビューを受ける必要がある。
本番サーバーは高セキュリティエリアにあるため入室申請が必要。
外部ファイルのメンテナンスはサバ管部門が行うため、消えてしまった場合、不正な値が設定された場合のリカバリ手順を作成し、サバ管部門の承認を受ける必要がある。
上記すべての手順について、役員の最終認証を得るためにレビュー会を実施するひつようがある。
この業務の処理手順は、数年ごとに多少の変更が入り、今回も、その対応が彼の仕事だった。
彼が、前任者が作ったソースを開いてみると、それはごく単純に業務手順書をプログラムに置き換えたようなもので、
固定値がそのまま文中に記述(マジックナンバー)されていたり、お世辞にも格好いいとは言えないものだった。
彼は考えた。「数年ごとに変更があるのがわかってるんだから、もっと変更に柔軟に対応できるようにしておくべきだ！」
そこで彼は、様々な決まり事や数値を一切固定で埋め込まず、あらゆる項目を外部の設定ファイルで変更できるようにした。
プログラムは完成し、彼は運用者と次の後任者に自信満々で言った。
「今後は、業務手順に変更があっても、プログラムをビルドし直す必要はありませんよ！設定ファイルで設定を変えるだけでOKです！」
さて、その数年後、実際に業務手順に変更があった。
運用者は設定ファイルを変更したが、うまく正しい結果が出ない。
バグが出てしまったか？と、後任者はソースを開いてみて愕然とした。
そこにあったのは、様々な設定項目に対応するための、膨大なif文ブロックの塊だった。
ソースの大半は、「将来的にこの設定が変更されたら」に対応するための、使われていない行。
設定の組み合わせパターンは膨大になり、全ての分岐カバーテストはされてはいなかったのだ。
再び、現在の業務手順だけを、そのまんまプログラムに落とし込んでいった。
確かにこの方法では、業務手順変更がある度に、プログラムを直してビルドする必要があるが、
そもそもプログラム言語というものは、「手順を明快に記述できる」ように発達してきたものなので、
手順書そのもののようなその新しいプログラムは、誰でも簡単に理解して修正できるものになっていた。
【教訓】将来の変更に対応するための「汎用性」「柔軟性」を上げようとするのは間違っていないが、
実際に来るかもわからない将来に備えてプログラムを複雑化するのは間違い。
PC・スマホ・タブレット等のIT機器のヘルプ対応をしているけど、このうち対応が最も面倒なのがLinux。
Windowsやmacよりも件数はかなり少ない代わりに、対応の難易度の高さは飛び抜けている。
それもうオンサイト対応じゃなきゃ解決できねーよみたいな内容が極端に多い。
どういう使い方で、どんなソフトウェアをどのように入れたかにより、OSの奥深くにある基本的な設定が書き換わるケースもあるし、もちろんディストリビューションやバージョンごとの違いもあるしで、
設定ファイルの修正方法やコマンドを送ったくらいでは解決せず、挙げ句
「このコマンドを実行してください」
というやりとりが延々続くだけになり、手に負えなくなってサポート打ち切りになるケースがほとんど。
というかサーバじゃなくデスクトップで使っているなら、そしてそんなとこまでこっちにやらせるなら今すぐフォーマットしてWindows入れろやボケ！！！
と言ってやりたくなる。
なんでこう、Linuxのトラブルはどいつもこいつもやたらややこしいんだか。
正直Linuxのヘルプ対応をするたび、Linuxがどんどん嫌いになっていく。
(追記)
サポートってどんなサポート？という質問があったけど、本当にごく普通のクライアントPCのトラブル対応を、いわゆる情シスのスタッフとしてやっている。
ちな会社は社員数1万人くらいで、自分はそこの情シスの中の、本社の社員のIT機器をサポートするチームのメンバー。
とはいえ対応時に見ているのは社員のPCだけじゃなく、場合によってはその社員が接続した際のDHCPやDNS、FWのログはもちろん、L2・L3スイッチやRADIUSだって見に行く。
それでもトラブルの原因がわからないときがあるので、ネットワークのチームやサーバのチームに相談することもしょっちゅう。
なお自分はもともと、開発・構築・運用と使い回されてきたタイプで、開発一つ取ってもWindowsアプリにiPadアプリにWeb系にとこなしてきた。
あとデスクトップLinuxは大学いた頃に慣れ親しんでいた(レポートや論文を書くくらいには使っていた)。
で、そんな君みたいな人を待っていたんだ！と言われ引き抜かれたのが今の仕事というわけ。
ただLinuxのサポートにここまで手こずるのは想定外だったわ。
やはり専門知識という意味ではLPICくらいは取ったほうがいいのか？と思っていたり。
(追追記)
ウチの会社でデスクトップLinuxを使っているのは(macもだけど)主にR＆D部門と、そこから転属or昇進した人達。
(一方でバックオフィス系は、サポートが最も楽なリース契約のWindowsPCだったりする)
このうち問い合わせてくるのは、大体が
のどちらかで、このうち後者については部門のガバナンスどうなってんだと思わなくもない。
「それもう試した」
→どこまで何を確認したか要点だけでも教えてくださいよ…このやり取り、普通に時間の無駄ですよね？
「ありませんでした」
→「ありませんでした」じゃねえ探すんだよ！ログがなきゃ原因特定できないんだが？そんなこともわからないでLinux使ってるのかよ…。
こういうやり取りが延々繰り返されるので、目に見えてMPが削られるという愚痴でした。
Permalink |記事への反応(13) | 15:47
