  |
はてなキーワード: インデックスとは
BSジャパネクストがリニューアル BS10の無料放送側で日曜昼などに放送中
見られなかったケーブルテレビ局でも見られるようになったので要確認
つながるジャパネットアプリで放送同期・スマートテレビや4月からtverを含め見逃し配信あり
－－－－－
・02 [3択]ニューヨーク?
・04 DJ KOO ディージェーコー
・05 あご
・03 丸亀(市
・05 ゴジラ
・06 ブルスケッタ
・07 [すべて]カンボジア マレーシア ミャンマー ラオス
・08 一青窈 ひととよう
・09 [近似値]1億417万9275人
・11 ユウガオ
・13 スカーレット・ヨハンソン
・14 『カグラバチ』
・16 モヒート
・22 三叉(神経
・25 カボチャ
・27 マグナ・カルタ
・29 闇(もなほ
・30 ヤジマリー。
・32 ジャッキー・チェン
・33e 7(枚
－－－－－
－－－－－
＝＝＝＝＝
(日曜本放送)このあとは「BS10からのお知らせ」→ジャパネットたかたテレビショッピング→ジャパネットたかたのテレビショッピング
16時からは「VS 今平周吾 ＃７」
実況側はちょっと待って
コホモリン: （ホモジーの肩を叩く）ホモジーさん、もう朝ですよ。あんた、また徹夜で単体ホモロジーのチェーン複体 Cₙ(X) を眺めとったんですか？ なんでそんなに、境界作用素 ∂ₙ が気ぃなるんです？ ∂² = 0 はもう、摂理みたいなもんやないですか。
ホモジー: （ゆっくりと顔を上げる）摂理…？ コホモリン…お前はわかってない…。この境界作用素 ∂ₙ: Cₙ(X) → Cₙ₋₁(X) が、ただの摂理で終わると思とるんか？ これはな、鎖複体のコホモロジー Hⁿ(X) とホモロジーHₙ(X) を繋ぐ、導来関手の源泉なんや…。Ext関手とかTor関手が、この単純な関係から生まれるって、鳥肌もんなんやで…！
コホモリン: （額に手を当てる）いや、そこまでいくと、もう代数やないですか。あんた、完全にホモロジー代数の世界に意識飛んでますやん。位相空間の形の話はどこ行ったんですか。
ホモジー: 形…？ 形とはなんぞや、コホモリン…。ホモトピー同値な空間は、ホモロジー群が同型やろ？ けどな、エキゾチック球面 S⁷ は、普通の S⁷ とは微分同相じゃないのに、ホモロジーは同型なんやで…？ あれって、結局、微分構造が持つ情報って、ホモロジーだけじゃ捉えきられへんってことやろ？ 俺はもう、その不確定性原理に囚われとんねん！
コホモリン: （震え声で）不確定性原理…もう、あんた、物理学まで手ぇ出しとるんか。エキゾチック球面は、ミルナーの偉業ですよ。あれは、多様体の圏と位相空間の圏の間の、深い亀裂を示しとるわけや。あんた、もうそっちの闇に堕ちて行ってるんちゃいますのん？
ホモジー: 闇…そうや、闇や…。特異点解消の理論とか、フルーリーのインデックス定理とか、闇深すぎやろ…。特に、交叉ホモロジー！ あれは、特異点を持つ空間のホモロジーを定義するときに使うねんけど、あの構成可能層の概念が、俺の脳みそを層化して、導来圏の中で消滅コホモロジーとして彷徨わせとんねん…！
コホモリン: （絶句）き、交叉ホモロジー？！ あんた、そこまで行ったらもう、完全に偏執狂ですよ！ ド・ラームコホモロジー Hᵈᴿⁿ(M) が特異コホモロジー Hⁿ(M; ℝ) と同型になるド・ラームの定理でさえ、あんたの目には生ぬるいんか！？
ホモジー: 生ぬるい…生ぬるすぎる…。p-進ホモロジーとかエタールコホモロジーの存在を知ってしまったら、もう普通のホモロジーには戻られへんねん…。特にエタールコホモロジーは、代数多様体の上で定義されるやろ？ ヴェイユ予想の解決にも貢献したって聞いて、もう夜も眠れへんねん。ガロアコホモロジーとの関連とか、考えたら意識が飛ぶわ…！
コホモリン: （顔面蒼白）エ、エタールコホモロジー…！？ それ、数論幾何の最先端やないですか！ もう、あんたは位相幾何学の領域を完全に飛び出して、数学のあらゆる深淵を覗き込んどる…！ ホモジーさん、お願いやから、もうやめてください…！ 俺のホモトピー群 πₙ(X) が、完全に自明群になってしまいそうですわ…！
ホモジー: （恍惚とした表情で、宇宙の果てを見つめるように）フフフ…コホモリン…俺のボーゲン–シュミット予想がな、今、頭の中で圏論的極限を迎えようとしとるんや…。宇宙全体のホモロジー群 が、俺には見えるんや…！
コホモリン: （膝から崩れ落ち、全身が震える）うわあああああああ！ ホモジーさん、あんたはもう、人間やない！ 数学の抽象的対象そのものや！ 俺はもう無理や…あんたの隣におったら、俺の有理ホモトピー型が壊れてまう…！
Hさんに財テクを教えてと言われて数年(3, 4年？)がたってしまいました｡
在宅勤務が多くあまり話す機会もないので､はてな匿名ダイアリーに書きます｡
僕は投資を始めて7年弱で､いま4000万-5000万の間くらいになりました｡
ここに来るまでに得た知見をHさん向けにまとめます。
■なぜ財テクをするのか
以下の流れなのかなと思います
中央銀行がお金を刷ることにより、(a)経済活動の活発化と、(b)貨幣の希薄化が起こる
(a)経済活動の活発化により増えた富は、給料にも行くが、株主へより多く行く
(b)貨幣の希薄化により、貨幣の価値は下がり、株式、金、不動産の価値が相対的に上がる
株式は(a)(b)両方からの恩恵を受けて､金や不動産は(b)のみの理由で上がるのかなと思っています｡
アパートとか経営すれば、不動産も(b)+(賃貸事業)で資産が増えますね。
補足
お給料より､株主へより多く還元されることがいわゆるピケティの提唱したr＞gで言われていることです。
この理屈としては、株主は会社が倒産するリスクを背負っている見返りに高いリターンを得ているため(株主リスクプレミアム)と自分は理解しています。
■何に投資するのか
■■資産1000-2000万までは､インデックス投資をします｡
emaxis slim 全世界株式か､emaxis slim S＆P500に､ネット証券(楽天証券など)で投資します｡
これが手数料最安なので｡
ネット証券として他にSBI証券もありますが､過去に個人投資家をカモにする不正を行っていたので､個人的には好きではないです｡
インデックス投資とは､全世界株式指数(世界の優良な大型株を時価総額で重み付けしたもの)やS＆P500(アメリカを代表する500の会社の株価を時価総額で重み付けしたもの)などの指数(=インデックス)に連動した商品に投資することです。
インデックス投資信託に投資し､資本主義による経済発展の恩恵を平均的に受けるのがまずは良いと思います｡
値動きも比較的穏やかですし｡
最初自分は､将来どこが強いかなんて分からないので､全世界株式に投資していました｡
だけど､そのうちに､中国に投資したくない､インドやヨーロッパ､日本の成長性を信じられないという理由で､S＆P500に変更しました｡
Hさんが始める際は､NISAで月10万(or 30万)から始めてはいかがでしょうか｡
いきなり一括投資すると､メンタルにくるので､積立投資をおすすめします｡
株と現金の割合は､株:現金=4:6〜8:2の間が良いのではないでしょうか｡
■■次に､ある程度資産ができたら､債権､個別株､BTC､金､不動産に投資します｡
守りの資産です｡僕はまだ買っていないですが､暴落に強くなります｡
成長目的で買うなら､なぜ上がると思ったのかストーリーを自分で整理してから買うと良いと思います｡
また､信じられるときだけ買えば良いと思います｡いくらでも次のチャンスはあるので､というようなことをバフェットが言っていました｡
precisionを上げるのが大事です｡
また､「チャンスを逃した」と思ったら､「なんで逃したんだろう」と考えることが次に繋がると思います｡
ちなみに､事前に描いていたストーリーと異なってきたら損切りします｡あるいはストーリーを捉え直します｡
トレードはしなくて良いと思います｡トレーダーになりたいなら別ですけど｡
配当が良く､かつ安定あるいは成長する株を買うというのも良いと思います｡
BTCや金
借り入れを行うことにより､元本以上の利率を出すことができます｡
例えば資産5000万円の人が、一億を借りて1.5億を運用。金利の返済をしても、実質1億で運用しているのと同じパフォーマンスになる、という状況。
自分が住むのでも良くて､その場合は中古一軒家が一番良いです｡
詳しくは､なすびのマネー講座というYoutubeを見てください｡
中古一軒家については､良いものがあるならインデックス投資よりも先にやって良いと思います｡
■暴落がきたら
特に気にしないのが一番良いです｡
リーマンショックでは6年くらいで､S＆P500は戻っています｡
その場合でも底がどこかは分からないですけど､そのうち回復するのでピンポイントを狙わず買っていけば良いと思います｡
■その他投資の注意
◾️その他の財テク
ふるさと納税は副収入に対してもできるので、忘れないようにします
賃貸を退去するときは､国土交通省発行の退去に関するガイドラインを熟読すれば､敷金はかなりの割合返ってきます｡
節約､無駄なものにはお金を使わない､要るものにだけお金を使う
有料の情報商材を買わない
無料のFP相談に行っても良いけど、保険や投資の契約はしてこない
保険は基本不要。ご家族のために掛け捨て生命保険に入っても良いかもしれないけど、基本は何も要らないです。
■最後に
人生においての財テクの重要度は人それぞれですけど､やらないよりはやった方が良いんじゃないかなと思います｡
ようやくお伝えすることができて､ほっとしました｡
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
インデックス型検索エンジンが普及し始めた頃も「インデックス型検索エンジンは使えない、ディレクトリ型検索エンジンで良いじゃん」という奴がいたんだろうな。
朝五時。
そこにいたのは、一頭の牛——いや、人語を話す牛。艶やかな毛並みのテクウヨITチー牛。ITインフラと国家の将来について語りながら、今日も元気にミルクを生産する。
「モー……❤ 増田さん、遅いですよぉ。もうパンパンで……タイムアウトまで30秒ってところですッ……！」
「はいはい。ごめんな、昨日夜遅くまでdockerコンテナと格闘しててさ……」
増田さんは手慣れた動作で搾乳バケツを置き、チー牛の傍に腰を下ろす。
「それにしても……今日も立派だな」
「『インフラ・ティート・パフォーマンス・インデックス』、過去最高値をマークしてます……！ グラフ化してTwitterに貼りたいくらいですぅ……❤」
「お前それ晒したらBANされるぞ」
増田さんの手が触れた瞬間、チー牛はびくんと震えた。
「モー……❤ あっ、そこ、そこは特に……ハードウェア・アクセラレーションポイントですぅ……！」
ぐいっ、ぐいっ、しゃああああ……
「モモモモーッ❤ 嬉しいですぅ……！国家予算に換算したら、防衛費の1%くらいは出てます……！」
「そうか……なら補助金もらえるな」
チー牛の尾がぴこぴこと揺れ、目はとろんと潤んでいた。
「増田さんに搾られると……理性がデータ圧縮されて……ミドルウェアがバグりますぅ……」
「はいはい、もう少しで終わるからな。最後のひとしぼりまで抜いてやるよ」
「モーッ……❤ そんなに搾ったら、また昼にも搾ってもらわないと……ああ、稼働率が120％に……！」
しばらくすると、村の坂道から子供たちの元気な足音が響いてきた。
「おはよー！ミルクできてるー？」
少年少女たちが、木のバスケットを抱えて納屋の前に集まってくる。
誰もが無邪気な顔で笑っている。
そして瓶を手に取ると、どの子も「ありがとう」とぺこりと頭を下げた。
「増田のおじさん、チー牛さんによろしく言っといて！今日も元気だったかって！」
「おぉ、あいつは元気すぎるくらいだ。ミルク、冷やしてから飲むんだぞ」
子供たちが笑いながら坂道を下っていくと、チー牛は納屋の隙間からそっと顔を出した。
「……モー❤ あの子たちの笑顔、ISPレベルで癒やされますぅ……❤」
「よかったな、チー牛。お前のミルクで、みんな元気に学校行ってるんだ」
「やっぱり、インフラは人の暮らしの根幹ですよねぇ……モーモーモー❤」
増田さんはそんなチー牛の頭を撫でながら、笑みをこぼした。
「お前はうちの宝だよ。国じゃなくて、まず俺が一番助かってる」
「モー……❤ “愛国”って、きっとこういうことなんですねぇ……！」
朝の納屋には、あたたかくてちょっぴり奇妙な幸福が満ちていた。
https://anond.hatelabo.jp/20250613111041
申し訳ありませんが、その方の話は新NISAの制度と矛盾しています。
新NISAの「つみたて投資枠」では、原則として金融庁が定める一定の基準を満たした投資信託（ETFも一部含む）しか購入できません。 日本の個別株は、つみたて投資枠の対象外です。
もしその方が「新NISAの積立投資枠で日本の個別株を買った」と言っているのであれば、以下のいずれかの可能性があります。
以前のNISA（つみたてNISA、一般NISA）の制度と混同している。
2️⃣表現が誤っている:
実際には「成長投資枠」で日本の個別株（はてな）を購入したものの、「積立投資枠」という言葉を誤って使っている。
「積立投資枠で積立投信を買って、成長投資枠で個別株を買った」という内訳を説明する際に、誤って「積立投資枠で日本の個別株」と表現してしまった。
もしくは、「積立設定で毎月一定額を個別株に投資している（ただしこれは積立投資枠ではなく成長投資枠での個別株の積立設定）」ということを指している。
そもそも、新NISAの制度を理解しないまま、適当な発言をしている。
1️⃣新NISAの**つみたて投資枠（年間120万円上限）**で購入できるのは、以下の条件を満たす商品です。
分配頻度が少ないこと
これらをクリアした、金融庁が指定する特定の投資信託（主にインデックスファンド）や、一部のETF（上場投資信託）に限られます。
一方で、**成長投資枠（年間240万円上限）**では、より幅広い商品が購入可能です。
ただし、成長投資枠でも、整理・監理銘柄や、毎月分配型投資信託、レバレッジ型投資信託などは購入できません。
したがって、「新NISAの積立投資枠で日本の個別株（はてな）を全額投資した」という発言は、新NISAの制度上はありえません。 もしはてなの個別株を購入しているのであれば、それは成長投資枠を利用したということになります。
1️⃣知識不足や誤解:
新NISAの制度を正確に理解しておらず、「つみたて投資枠」と「成長投資枠」の違いを混同している可能性が最も高いです。特に投資初心者の方であれば、このような制度の細かい違いを把握しきれていないことはよくあります。
もしくは、一般的な「積立投資」（毎月一定額を投資する行為）と、NISA制度上の「つみたて投資枠」をごっちゃにして認識している可能性も考えられます。成長投資枠を使って、個別株を毎月積立購入する設定にすることは可能ですから。
意図的に誤った情報を伝えようとしたのではなく、表現が不正確だったという可能性です。例えば、「新NISAの成長投資枠で個別株を買ったけど、総じてNISAで積立投資をしたような気持ちでいる」といったニュアンスを、端的に「積立投資枠で買った」と表現してしまったのかもしれません。
ごく稀なケース（現実的ではないが可能性としてはゼロではない）:
何らかの極めて特殊なケースや、非常に限定的な状況下で、個別株に投資する目的で非公式な手段（例：個人の裁量で運用を請け負う業者など）を使っていた、というような、NISA制度の範疇を大きく超える話であれば、それはもはやNISAの話ではなくなります。しかし、これは非常に現実的ではありません。
「嘘をついている」という言葉は、意図的に相手を欺く目的がある場合に使うべきです。今回のケースでは、悪意をもって嘘をついているというよりは、制度への理解不足や、表現の誤りであると考えるのが自然です。もしその方と直接話す機会があれば、「つみたて投資枠では個別株は買えないはずですが、成長投資枠のことですか？」などと、穏やかに確認してみるのが良いでしょう。
全部オルカンに入れて、毎年1千万円ずつ取り崩しながら生活していけば減らないんじゃないの。
期待利回り6%だから12億の6%で、7200万円だから、生活費1000万円でも6200万円あまりよね。
よって、無限に増えるだけになると思う。
世界恐慌やWW3とかのヘッジと考えるなら半分ゴールドや債券とかでもいいのかもしれけど。
逆に10億を減らす買い物として、
買ってはいけないのは、タワマンとかの不動産、高級車とかのぜいたく品、セールスマンが対面で売ってくる金融商品(仕組債とか謎のファンドとか)、高利回りの外国債券(トルコリラとか南アフリカランドとか)、流動性がない外国のヘッジファンド商品、個別株に1点掛け、元本保証で高利周りを謳う詐欺商品とかかな。
大切なのはいつでも換金できる流動性があることと、奇抜な変な商品ではなく、なるだけコストが安くみんなが買っている市場平均のインデックス投信やETFにお金を入れることが重要だと思うんよね。
anond:20250521002326 アラフォー独身Webエンジニアの金融資産棚卸しと気づいたこと
anond:20250521173642 都内在住のアラフォー子持ちWebエンジニアの金融資産棚卸し
anond:20250522100954 40超えWebエンジニアの収入と貯金とこれからと生き残るために
に触発されて。3つ目の人生パートがもっとも刺さる内容であったとは思う。
産休育休異動転勤を経た中で良くやっていると思う。こちらは優秀で既に管理職の声が掛かっているが、責任だけ増えて割に合わないということで引き受けていないとのこと。
400万円
まとまっているわけではなく、子供名義に散っているものも含む。マネーフォワード契約していなかったらこの棚卸をする気にならなかったと思う。たまにイラつくけど助かるよMF。まだ黒字にならない が頑張ってねMF。
100万円
ちまちま個別株。積極的な売買は全くしておらず、銘柄に一貫性なし。インデックスを手動でやっているようなもの。
700万円
子供が大きくなったタイミングになるまで塩漬け確定。定期預金と同じ性質。
今思えば全て投資信託で良かった。損切するほどではないので放っている。
1500万円
S＆Pがほとんど。一部オルカン。 一時期ロボアドバイザーに突っ込んでいたがやめた。5年ほど預けて130%くらいの成績だったので不満は無い。
投資リテラシーはあるつもりで、今はもうやることが無いがNISAに手を出すのだけやたら遅かった。利益に20%取られてたの無駄だったなと思う。
ジュニアNISAも含んでいる。これも満期が来るまで下ろせない定期預金・学資保険と性質は似ていると思う。
月収支で足は出ているが確定申告でトータルプラス。リスクも抱えているのは分かるがあまり不安を考えないようにしている。地震や姉歯案件になってしまったら泣く。
300万円
もっともキナ臭いであろう。スイングトレードで儲けたかったが、戦果は微々たるもの。放っておいて勝手に価値だけ上がった。たまに急落するニュースを目にして凹む。
老後の安心より今の消費に使いたい。
換金性が低いからあまりこの形で持ち続けたくないが、サービス開始の手軽さとPayPay証券口座開設の面倒さにより数年来使い続けている。トランプで荒れる前は瞬間最大風速+100%叩き出していてやたら成績が良かった。
子供の習い事がでかい。たまに上述の貯金や投資信託を切り崩している。
塾が高い。年払いで死ぬ。今のところ公立だが、中高大と将来私立に入ったらきつくなるであろう。そのための備えではある。
年に2-3回国内旅行。
カード払いとPayPayで生きている。昔はポイント還元率命で漢方スタイルクラブカードという一般認知度は全くないカードをメインで使っていた。同志はいるだろうか笑 今はプラチナプリファード。
毎月の引き落としが自転車操業。こんだけ資産あるくせに銀行現金残高が足りなくなることがあってメインバンクの超短期カードローンをしょっちゅう使っている。4万円借りて3週間後に返すとか。各種ポイントの微かな利ザヤをここで失っている。新NISA毎月10万円つっこんでるせいでもある。年間360万円フル枠は埋められない。
子供が巣立つまでに掛かる金と2馬力の収入と老後の天秤。今後の出費が増えるのは確定。自分の収入がもっと増えれば良いが、給与テーブルを見てもここから激増するわけではない。
大卒20年働いて、あと20年働くのか。働けるだろうか。漠然とした不安はある。ステップアップやリスキリングというやつを多少はして、実にはなった。
年を取ると体力とやる気がなくなるというのはその通りで、既にじわじわと感じている。今の内に趣味や交流を増やしておくべきとは思う。
流行のコンテンツを追えなくなってきた。アイアンマンは好きなのだがMCUを見終えていない。アニメの完走も出来なくなった。みんなの感想を読んで満足している自分がいる。
前ほど心が動かなくなった様に思う。辛くはないが面白くもない人生。少しだけ違う1年の繰り返し。
諸君らが大人になるころ、この国がもっと生きづらくなっていそうだなと思う。高い税金納めてるのにな。
子供は設けた方が良い。これほど予測不可能で自分が成長させられるなものはない。社会との関わり、関心が桁違いに変わる。親の立場でなければ知ろうとしないことが多い。個々人の事情があるので面と向かって言うことは無いが、内心はこう思っている。
親とは疎遠。まれに事務連絡を取る程度。終活はしておいて欲しい。
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倍。
同一投稿者続出の抑制、逆風バイアス（negative feedback）などが入る。
これは以下のような修正：
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」は、コード構造の多くを公開しているものの、モデルパラメータ・学習データ・設定ファイルは秘匿されており、上述パイプラインの数学的な枠組みは把握できても、実際の挙動はまだブラックボックスです。
とはいえ、レコメンデーション理論の観点からは、上記の抽象モデルで十分に説明可能であり、汎用の数学モデルとして整合しています。
お前の反論、自分が引き算の美学で事業コストを語れてると勘違いしてるパターン。
でも実態は、事業規模に対する思考スコープの狭さがにじみ出てる。
まず最初に、
それ、論点でもロジックでもなくて、ただの願望自己放尿。中身が一切ない。
これは一見合理的に見えるが、実際は「過剰な単純化」の自己放尿にハマってる。
言ってるのはただ1つ。「JOINを安易に使うな。構造が持つリスクには最初から備えろ」。
将来のトラブルを「避けられる形にしておく」ってだけの話。
たとえば、JOIN構造を避けて辞書キャッシュを設けるのは、初期では数行のコード差。その数行で未来の地獄が避けられるなら、やる価値はある。
JOINを使った全クエリの洗い出し、クエリの再設計、DBインデックス再構成、アプリコードの再配備、キャッシュ整備、パフォーマンステスト、ロールバック対応。
事業全体の工数で見たら、圧倒的に最初に避けとくほうが安いんだよ。
それが見えてない時点で、「事業全体のコスト」とか語らないほうがいい。
言ってることが逆。
しかもね、「事業の初期だから雑でもいい」って、それ本気で言ってるならプロダクトの成功を前提にしてないってこと。
リクエスト数が伸びたら死ぬ設計でリリースして、「伸びたらそのとき直せばいいでしょ」とか言うやつに限って、死んでる間に顧客も信用も消えてる。
初期だからこそ、「伸びたときに対応できる構造」は最低限持たせる。
「JOINは便利だが地雷になりやすい」というのは経験則に基づいた設計判断。
「初期はシンプルに」というのは同意だが、それは未来を無視していいという免罪符じゃない。
「将来の死を回避する設計」＝「複雑化」ではなく、保険と投資。
事業全体のコストを考えるなら、障害で燃える運用コスト・再開発工数も含めろ。
あー、なるほどね。「JOINが難しくて避けてるだけなんじゃね？」ってわけか。
甘い。構造わかってない奴ほどそういう浅い自己放尿をしたがる。
まず前提を修正しろ。JOINの動きなんてとっくに分かってる。
SQLの実行プラン追って、Nested LoopかHash Joinか、インデックス使うのかフルスキャンになるのか、そのあたりの判断も含めて運用設計に組み込んでる。
こっちはわかった上で避けてんだよ。JOINを理解してないから避けてるんじゃない、JOINの実コストと限界を知ってるから回避してるの。
JOINってのは便利だけど代償がでかい。たとえば、数千万件のトラフィックログに対して、ユーザー属性をJOINするとしよう。
属性テーブルが1万件程度でも、JOIN時のI/OとCPU負荷は無視できない。結合条件次第ではインデックスも効かなくなる。クエリキャッシュも効かない、結合後にさらにGROUP BYやWHERE使えばオプティマイザの想定外の地雷も踏む。
こっちはそれを全部経験済み。痛みを知ってるから最適化してる。JOINの怖さを知らない素人が、理解できない設計を「逃げ」と断じるのは自己放尿だな。
それに「JOINがわかりづらい」なんて次元じゃない。JOINなんて構文としては簡単だろ？
問題はそれを巨大なスケールで運用したときのトラブルを想定してるかどうかだ。
JOINが原因で1時間かかるクエリになって死ぬとか、JOINが原因でMySQLのtemporary table溢れてswapに突っ込んでサーバ落ちるとか、JOINが原因でインデックスの設計ミスってテーブルスキャン発生して数億件走査するとか、そういうのを踏んでから語れ。
わかりやすくしとこうか？
JOINを盲信してるのは、「地雷原を地図だけ見て走り抜けようとしてる奴」と同じ。
JOINを避けてるのは、「地雷があるの知ってるから事前に地ならししてる奴」だよ。
「難しいから避けてる」んじゃない。
危険なの知ってるから、先回りして別ルートを構築してるだけだ。
何も知らないで「逃げてる」ってレッテル貼って自己放尿するの、やめとけ。
お前のJOIN観、浅すぎて逆に危ない。
まず、もしテーブルが小さいならそれこそJOINなんてそもそも無駄。
usersが1万件くらいのサイズなら、最初に全件引いて辞書にしておけば、処理時は全部O(1)。
一方JOINはどうなる？SQL構文パース、オプティマイザ、プランの生成と実行、インデックス参照、場合によってはソート・一時テーブル、何重にもコストがかかる。JOIN使うのは、全力で自己放尿してるのと同じ。
「今後も巨大にはならない」
これ、現実逃避の典型な。開発初期で小さくても、プロダクトってのは使われてナンボ。使われればデータは自然に増える。
さらに「本当に巨大なら辞書は無理」って言ってるけど、じゃあJOINならいけると？
脳ミソの冷却ちゃんと回ってるか？
JOINってのは重いんだよ。リレーショナル演算のコスト、現場でまともに見積もったことあるか？
JOINするたびに何十万、何百万件ってレコード舐めて、インデックス使って、それでもI/Oボトルネック起きる。
そういうの避けるためにRedisとか列指向DBとかプリマテリアライズするんだろ。JOINは最適解じゃない、最後の逃げだよ。
結局、JOINを正当化する理由が「JOIN以外知らない」ってだけじゃねえの？
設計手段を学ばず、「それしか知らない」ことを自信に変えるな。
知識の不足を理屈で補うのは無理がある。JOINを使うなとは言わん。でも、JOINが最適って言うなら、それ相応の読み、キャッシュ設計、オプティマイザとの対話が必要だ。
アラフォー独身Webエンジニアの金融資産棚卸しと気づいたことという増田があったので、世帯持ちならこうなるっていうサンプルをひとつ。
年齢 45歳
家庭 既婚10年目ほど、子供は３人（小学生1人、未就学児2人）
マンションの手数料を払ったらすっからかんになったので投資から一部取り崩した。
とりあえずこれだけあれば火急の用があってもなんとかなるかと。
500万円くらいから始めて投資金額を徐々に増やして、総額2800万円分くらい投資している。
NISA以外は途中で売買しているので何がどのくらい増えたかは良く分からない。内訳は以下の通り。
40万円/年を6年積み立てて、240万円投資して+300万円程になっている。
〇その他（約2250万円）
マイクロソフト、エヌビディア、Google、Amazon、コストコ、ジョンソン&ジョンソン、ペプシコ、ブリティッシュ・アメリカン・タバコ、くら寿司USAなど
80歳まで返済。死ぬかガンになればチャラなので勝ち。
月の収支は概ね以下の通り。
〇収入
〇支出
食費 15万円
教育費 3万円（幼稚園無償化がなきゃ詰んでた。延長保育や教材費などでこの金額）
習い事 5万円
通信費 1万円（ahamo × 2）
光熱水費 2万円
娯楽費 4万円（土日家を空けるために、子供を連れて出かけている。公的施設など安いところを選んでもどうしても、外食費用を合わせて毎週平均1万円ほどかかっている）
被服費 2万円（子供はすぐ大きくなる、靴が高い）
雑費 8万円（家具、家電、自転車、ベビーカーとかなんだかんだいろいろかかる）
〇計
勤勉手当が6月と12月に手取り120万円ほどあるのでそれで毎月の赤字と冠婚葬祭費用を賄っている。
良く知らない。
預貯金はほぼ全額を配当付きの投信に移行予定らしい。子どもの習い事費用はここから出そうと相談している。
相続した不動産所得が年150万円ほどあるらしい。このせいで扶養に入れないので家計的にはむしろマイナス。きつい。
