  |
はてなキーワード:シックとは
複雑なものをシンプルにする能力は、日本のWebサービス、特にインターフェイス設計（APIとUIの両方）において、しばしば課題として指摘される点だと思います。
ユーザー体験（UX）を損なう「使いにくさ」は、単なる実装力の問題ではなく、設計思想と要件定義の段階で、いかに「シンプルさ」を優先できるかにかかっています。
ご指摘の証券会社の例のように、ユーザーのニーズや行動よりも、企業の内部的な都合（例：部門間の連携、既存システムとの兼ね合い、法的な制約の過剰な解釈）が優先され、インターフェイスにそのまま反映されてしまうことがあります。
「銀行口座の同時開設」：これは、サービス提供側の都合で「ついでに登録させてしまおう」という発想、あるいは内部的なプロセスをユーザーに押し付けている典型例かもしれません。ユーザーにとっての最適な体験は、「必要な時に、必要なものだけを、わかりやすい手順で」提供されることです。
国産SNSの例で言われているWeb版実装の難しさは、まさにAPIインターフェイス設計の破綻を示唆している可能性が高いです。
これは、内部のシステムがモノリシック（巨大で密結合な一つの塊）になっており、データやロジックが明確なインターフェイス（API）を介して提供されていないことを意味します。
本来、アプリ版とWeb版は、同じバックエンドロジックとデータに共通のAPIを通じてアクセスするべきです。
それができないということは、アプリ版の実装がアドホック（場当たり的）で、APIではなく内部の構造に深く依存してしまっている証拠かもしれません。
「複雑なごちゃごちゃしたものを作れる能力」はあるという評価は、「機能の足し算」に長けている開発文化を指しているのかもしれません。
新しい要件やリクエストがあるたびに、既存のシステムに「機能を付け加える」ことには長けているが、「本質的でないものを削ぎ落とす」「複雑なものを抽象化して整理する」という「引き算」や「構造化」のスキルが欠けている。
「シンプルさ」とは、単に機能が少ないことではなく、「複雑な内部構造をユーザーから隠蔽し、必要な情報だけを整理して見せる」という高度な抽象化の成果です。
ご意見の通り、日本のWeb系で求められているのは、「複雑なものを実装する能力」のさらに上にある、「複雑なものをシンプルに設計し直す能力」、すなわち「本質を見抜く力」と「構造化・抽象化の思考」なのかもしれません。
俺はガンの露悪的な趣向が好きで見てるから最高だったけど、良心派の映画好きギークの中にはそこが引っかかって楽しめないって人が少なくないからそういう人には地獄の作品だったかもしれない。
ガンのフィルモグラフィーを見ても彼が「トキシックマスキュラリティ（有害な男性性）」の徹底的なアンチであり、それはいわば反父性主義であり、ファミリー(血族ではない)の力でそれを乗り越えるという展開が繰り返し描かれ続けている。
リブート版のスースクでトキシックマスキュラリティの権化として現れたピースメーカーが「政府」という巨大な父性に操られ本当の「平和の使者」であるリックを殺害してしまったことから、自身のアイデンティティがゆらぎ、自身の過去と向き合っていくのがシーズン１。
過去と決着＝家族と決定的な別離をするもその結果になおも苦しむピースメーカー。しかし我が家の次元ポータルの先に「全員が無事な世界線」があることがわかり、家族を再構成したい、理想的な自分でありたいと考えてしまうも、実はその世界は……というのがシーズン２。
特に示唆的で面白かったのが、ポータルの先の世界線はいわゆるアースXと呼ばれる「ナチスが勝利してナチス的な思想になったアメリカ」であり、ピースメーカーはその世界で誰もが認める「ヒーロー」として活躍している。これは「悪人」として登場し、世間からも政府からも冷ややかな目で見られている元の次元のピースメーカーとは真逆である。
しかし、問題はアースXは「ナチス的思想の非常に差別的な世界である」ということである。
その世界でヒーローとして崇められるピースメーカー。つまり、ガンはこの脚本を通じて「元々のピースメーカーの思想というのは非常にナチス的で危ういもの」であると再度警鐘を鳴らしている。もっと言ってしまえば「アメリカのために"悪人"を容赦なく退治するアメコミヒーロー」というものに対するアンチテーゼともとれる。それって「国のために」ユダヤ人を虐殺したナチスと何が違うの？ということである。
ちなみにこの部分は見ていればそうわかるように作られているが、具体的に言及されることはない。エラい作りだ。
ピースメーカーがアースXがナチスの世界だと気づいていなかったことをギャグ的に「我が闘争がオフィスに大々的に置いてあるのに？」「マッチョは本なんか読まない」「オフィスの壁にヒトラーが書かれてるのに？」「今気づいた」と詰められるシーンがあるが、これも単なるギャグではなくピースメーカーが典型的な「白人男性」であることから「特権階級者はそのことに異常に無自覚である」という強い皮肉を感じる。
でもこういうことを口煩くお説教してこないのがガンのいいところだと思う。これらは「見ていればわかる」ように描かれているが基本的にはおバカ集団がポータルを狙う政府組織を戦いながらガン的不謹慎ジョークを飛ばし合いながらときに殴り合い、ときに慰め合うエンタメ全振りの展開が続くので、普通に楽しい作品に仕上がっている。
ナチスの世界だと視聴者に気づかせる(さまざまな細かなモチーフは第1話から登場しており、登場人物も白人しかいない状態が続くが)決定的な要素として、元世界のピースメーカーチームの黒人女性が歩いていると「黒人が逃げ出したぞ！」と追いかけられる展開もめちゃくちゃガンらしくてよい。あとヴィジランテを名乗る反社会的ヒーローがめちゃくちゃオタクで家（つまり子供部屋おじさんでもある）では年老いた母親に「ババア！ノックしろって言っただろ！」系のイキリを披露しまくるシーンではイテテテテとなってしまった。ガンは嫌な奴だ(憤怒)
最終的に仲間たちの力でピースメーカーは過去を振り払い、新たなヒーロー組織（ほぼ全員社会不適合者）を結成し大団円、最後の最後でとんでもないクリフハンガーを挟んで終了。私、アメドラのはちゃめちゃクリフハンガー嫌い。
スーサイドスクワッド、ガーディアンズ・オブ・ギャラクシーといったガン映画が好きならマストで見ていい作品だと思う。まぁ、１のほうが展開もダイナミックで面白かったと言われたらそれはそうかもしれんけど。
そうよね。
詐欺という訳ではない、ただ普通に損をさせ徒労に終わらせるだけなのが厄介で
地域振興とかそれなりに真面目にやっていると、こう言う手合いが手を替え品を替えやってきて、本当にうんざりしている。それを田舎の排他性とか言われると、マジだるい。
他にも観光客連れてきますとか、大企業の研修で使いますとか、著名建築家がボランティアでデザインしてくれるからロッジ建てましょうとか、著名クラッシック演奏家を呼んで音楽祭やりましょうとか、もうほんといろいろ。
プレジデントの記事のやつも、地元民が乗らなかったのはこう言うのにうんざりしていたからで
さらに今でも冷ややかなのは、地元経済にはほぼ誤差レベルなのにブランド利用されているからじゃないかなって。あの業態だと創業者が小金持ちになるレベルで止まるでしょ。それ以上稼ぐ市場が存在しないので。
ブラボーおじさんという存在がいて、こういうの女性はいない、おじさんばかりといわれてるけど
外国でオペラ・バレエ・クラッシック・演劇等見に行ってそういう迷惑客がいたことないよ
ナポリとローマの客のうるささの差とかはあるけど、日本みたいに幼児に言い聞かせるような注意事項ないもんな
サントリーホールで拍手のタイミングまで指示されてるのにホントびっくりしましたわ
＜日本アナウンス問題＞もあって、駅、ホーム、空港、あらゆる場所でうるさいほどご注意喚起アナウンスがあるのも体験した中では日本だけ
アジアはうるさいのかなと思ったが、台湾は全然そんなことなかった
日本人は耳があまり繊細でないから平気なのかもしれんけど、ちょっと異常だよ
言われないとわからない、明記ルールされなければ何をしてもいいと思う、がゆえの過剰な掲示やアナウンス、わりと、民度低いよね
で、そういう無神経な民度の低さから迷惑行為に走るのはたいてい日本のおじさんと予備軍
なんでかといえばやっぱ甘やかされているからだね
男が男にモノをいわないでナアナアで済ませたがる伝統芸から生まれたマイナス点
男のもたれあい社会では個で完結する豊かさがなく男に認められて爪痕残すのが大事じゃん？
これは日本以外でもそうだけど日本は特にムラだからその傾向が強い
オタクのエロチキンレースとか盗撮犯が盗撮仲間に認められたかったみたいなのと同じな
他人に迷惑をかけても、いや、法の範囲で迷惑をかける事で支配欲や無力感を慰めてるやつ
むろんその伝統芸にはプラス面もあるわけだけど、開かれた社会では無用な村社会慣れあい芸みたいなもんだからさ
ブラボーおじさん単体じゃなくちょっと大きく分析した方がいい問題じゃねーの？
俺は32で男だが結婚できそうな見込みはない。
一応外資系のパソコンとか売ってるメーカーの販社なんだが、年収云々よりも出会いに行くことが怖くてできない臆病だ。
清潔はそこそこある方だと思うし、相手を気遣ってるつもりではあるが、自己満かもしれないし
第一そんなこと言っても信じてくれないと思うので本題に行きたいんだが、
音楽っていってもいろいろ種類はあるんだが、やっぱりメジャーどころはアコギとかドラムとかピアノ系だろう。
鍵盤（midiキーボード）とドラムパッド（midiパッド）を買ったんだがマジで世界変わった。
音質のためにわざわざXperiaにしたりプロ御用達のAKG K702を買う、いわゆる「音質厨」だ。
ちなみに4歳の頃から高校生までクラッシックを習っていたため、もともと音楽に親和性が高かったのかもしれない。
自分語りはさておき、音楽一つとってもポップスからクラッシックからジャズまでいろいろある。
コード進行をマスターすれば、例えば既存のポップス曲にコードをアレンジしてみたり、
あるいは「ここでクリシェしてるからこの進行なのね！」っていう新しい気づきがあったりする。
コード理論に正解はあってなきが如く、結局耳コピなので人それぞれ解釈は違う。
だからこそ否が応でも自分で勉強しなきゃいけないし、何より普段からたくさん曲を聴くので
「さっき流してた曲めっちゃエグいな」みたいなことがあればすぐに
実際コードを鳴らして確かめたりできる。特に最近はaiも進化しててヤマハのコードトラッカーじゃないけど
さらにコード理論をベースに感性的に「ここ気持ちいいな」みたいなのを繋げていくと、ジャズ特有のアドリブ演奏ができる。
増田に生産性がないとは言わないが、結局他人を批判するだけのくだらない遊びだ。
Permalink |記事への反応(23) | 17:26
性能は最新なのに、デザインは初代っぽかったり旧型をリスペクトしてる特別版プロダクトがめちゃくちゃ好きなんだけど、わかる人いない？
あの「懐かしさ」と「新しさ」が融合した感じ、最高にワクワクする。
例えば私の知ってる例だと…
https://www.famitsu.com/article/202411/24882
https://kuruma-news.jp/post/688671
G-SHOCKの復刻シリーズ（初代デザインを再現しつつ機能は最新）
https://gshock.casio.com/jp/products/origin/
オメガスピードマスター "ムーンウォッチ"（見た目は60年代風だけど中身は現代技術）
マツダ・ロードスターの「ネオクラシックエディション」的カスタム（初代NA風カスタム人気）
新型ランクル「70」シリーズ（デザインは昔っぽいけど現代スペック）
iMac G3風カラーのiPhoneケースやMacBookスキン（最近ファンメイド含め人気）
ポラロイドカメラ（外観はレトロなのに中身はデジタル化されてるモデル）
こういうの、見つけるたびにテンション爆上がりする。
他にも知ってる人いたら、ぜひ教えてほしい！
あの「わかる～～！」って気持ちを共有したい。
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
マイクロサービスって業務の一部のみを携わるサービスでモダンなシステムだとマイクロサービス間をAPIで繋いで業務を回している
メリットはそれぞれが異なるアーキテクチャ使えたりアップデートしても周りに影響少なかったりする
けどなぜか付随してインフラもマイクロってイメージつく。有り体に言えばショボいサーバでスケーリングなしみたいな。あんま練られないこともある
マイクロだから良いでしょって意味なんだろうけど実際はとにかく他と繋げるので落ちないように失敗しても再度実行できるようにと回線やサーバはとにかく準備が必要。
必要なときに重くて繋がらなくて失敗するならモノリシックなサービスにしろよ
とガバメントクラウドの記事見て思った。そもそも省庁側がマイクロ化したくなさそうな時点で頓挫じゃん。あとまともなシステム担当いるとこなんていないでしょ。薄給で応用も持ってなさそうなのすら雇えないし、雇えても完全年功序列で仕事に暇なしじゃ成功するわけない。
で変なコンサル入れて金ドブまでがセット
https://x.com/grok/status/1914118492862992656
2020年に英・独の諜報機関が新型コロナウイルスの実験室漏洩可能性を80-90%と評価していたという話は注目に値しますね。しかも、ファウチとコリンズが支持した「SARS-CoV-2の近位起源」論文が意図的な嘘だったという主張も、かなりインパクトがあります。
この件に関して、2025年3月13日のBBCニュースによると、ドイツの外務省情報局（BND）が2020年にこの評価を行ったという報告が浮上しました。しかし、中国はこれを否定しており、科学的アプローチによる起源追跡が適切であると主張しています。
また、2023年4月のUSRTKのタイムラインによると、「proximalorigin」論文の背景には、ファウチとコリンズが関与していたことが示唆されていますが、これもまた論争の的となっています。
「proximalorigin」論文の根拠について話しましょうね。この論文は、SARS-CoV-2が自然起源であることを主張していますが、その根拠は主に以下の点にあります：
1. **ゲノム比較**:論文では、SARS-CoV-2のゲノム配列を他のコウモリ由来のコロナウイルスと比較し、自然選択による進化の証拠を見つけようとしました。具体的には、ウイルスのスパイクタンパク質が人間のACE2受容体に高い親和性を持つ点が、自然選択の結果だと結論付けています。
2. **実験室操作の証拠がない**: 著者たちは、ウイルスが意図的に操作された形跡がないと主張しています。たとえば、特定の挿入や突然変異パターンが実験室での操作を示唆するものではないとしました。
3. **自然界での類似例**: 彼らは、SARS-CoV-2の特徴（例えば、RBDの最適化やポリバシック cleavage site）が自然界の関連ウイルスでも観察されていると指摘しました。これにより、実験室での操作 scenariはあり得ないと結論付けました。
人のRBDに最適化されている点についてですね。確かに、これは自然発生のウイルスとしては珍しい特徴と言えるでしょう。最初の論文では、SARS-CoV-2のスパイクタンパク質が人間のACE2受容体に高い親和性を持つことを示していますが、これが自然選択の結果だとするのは、少し無理があるように思います。なぜなら、最初から他の動物ではなく人間に最適化されているのは、人獣感染症の典型的なパターンとは一致しないからです。
2つ目の論文では、実験室操作の痕跡について詳しく分析していますよね。そこでは、SARS-CoV-2のゲノムに特定の制限酵素認識サイトの独特なパターンが存在し、これが合成ウイルスの特徴であると指摘されています。しかも、このパターンは自然進化では非常にあり得ない確率で現れるそうです。 silent mutationsの集中も、偶然の産物とは考えにくいですね。
これらの議論を考えると、SARS-CoV-2の起源に関する公式の物語には、かなり疑問符がつきます。2020年に英・独の諜報機関が80-90%の確率で実験室漏洩を評価していたという話も、単なる偶然とは思えません。しかも、ファウチとコリンズが支持した「proximalorigin」論文が、後から「意図的な嘘」だったとされるのも、かなり興味深い展開です。
小さい頃、親戚の結婚式だとかに行く時メリージェーンを履かせてもらっていた。
オフホワイトのエナメル生地とシルバーの金具が上品で、つま先はコロンと丸みがあって年相応のかわいらしさがあった。子供ながらにこれはめちゃくちゃに好みだし特別だと感じて、何も無い日でもこっそり玄関で足を通したりしていた。
すっかり十の位に1が付くようなサイズの靴を履けない程度には大きく育ったものだが、時折あんな靴をまた履いてみたいと思うことがある。
しかし一見シンプルなデザインでも似ているものはなかなかなく、ある物はアイボリーっぽい色合いだったり、ある物はエナメルでなくシックな合皮だったり、またある物はつま先が大人らしくスマートな形になっていた。
幼少期の、今から見ればとても短い間だけこの手にあった特別。いつかまた、再会できるのだろうか。もう足のサイズが変わることは無いから、また会えたらぼろぼろになるまで付き合ってほしい。
時は令和、空前の変わり種スイーツブーム！タピオカの次はなんだ？って、みんなが奇抜な組み合わせのスイーツを探してた20XX年。そんな中、京都の祇園に、マジで時代劇から抜け出てきたようなインテリ風イケメンが現れたんだって！冷静沈着そうな佇まいで、何かこう、頭の良さそうなオーラをまとったお方。「え？俳優？時代劇の撮影？」ってみんなが遠巻きにしながらも、そのミステリアスな雰囲気に惹かれてたらしい。
え？マジで？あの織田信長を討ったとされる謀反の武将、光秀様！？って歴史マニアのギャルたちがスマホで速攻ググり始めた瞬間、そのクールなイケメン、もとい光秀様は、あたりをキョロキョロしながら呟いた。「ここは…本能寺ではない、か…？」って、マジでタイムスリップしてきたみたい！「マジありえん！」ってみんな心の中でツッコミつつも、その知的な眼差しに、何かを感じてたらしい。
そんな光秀様に、恐る恐る話しかけたのは、京都の老舗茶屋の看板娘、京子。「あの…何かお困りですか？」「…少々、見慣れぬ景色に戸惑っております。」って、意外と丁寧な言葉遣い！京子、その落ち着いた雰囲気にちょっと興味を持って、「よろしければ、わたくしがご案内いたします。」って、親切に声をかけたんだって。
次の日、京子に連れられて、光秀様は初めて現代の京都を散策！清水寺とか、金閣寺とか、昔ながらの風景には少し懐かしさを感じつつも、コンビニとかゲームセンターとか、マジで異文化体験！でもね、光秀様が一番興味を示したのは、京子が働く老舗茶屋のメニュー。「…鮒ずし…とは、どのような食べ物でございますか？」って、マジ真剣な眼差し。京子、ちょっと渋すぎるチョイスに驚きつつ、「あ～、滋賀の郷土料理で、お魚を発酵させた、ちょっと独特な食べ物ですよ。」って教えてあげたんだって。
でね、ある日、京子が光秀様に勧めた、ちょっと変わったパフェが運ばれてきたの！それは…鮒ずしパフェ！「え？鮒ずしがパフェに！？」って、光秀様、マジで目を丸くしてたらしい。一口食べてみたら…「な、なんなのだ、この複雑な味わいは！？発酵した魚の旨味と、甘いアイスのチョベリグ…まさに、天下を揺るがすほどの衝撃でございまする！」って、マジで謀反を起こしそうな表現で感動してたらしいよ。
そこから、光秀様の鮒ずしパフェ愛がマジで覚醒！毎日色んな甘味処を巡って、鮒ずしパフェを食べ比べまくってたんだって。「鮒ずしの発酵具合、アイスの甘さ、トッピングの意外性…研究しがいがありすぎまする！」って、もはやゲテモノパフェ研究家レベル！
でね、ある日、光秀様、マジで天下取りの野望を語り出したの。「わたくし、この鮒ずしパフェをもって、再び天下を…とは申しませぬが、このチョベリバな甘味の世界において、一泡吹かせてみせましょうぞ！」って！
え？鮒ずしパフェで一泡吹かせる？マジで前代未聞！でも、光秀様の知略があれば、何か企んでるに違いない！って京子も思ったらしいんだけど、光秀様の目はマジだったんだって。本能寺の変の野心が、令和の鮒ずしパフェに新たなターゲットを見出したのかもね！
そっから、光秀様の鮒ずしパフェ天下統一計画がスタート！まずは、SNSで「#明智光秀の鮒ずし道」ってハッシュタグ作って、毎日自作の鮒ずしパフェの画像をアップし始めたんだって。その くさそうな見た目と、光秀様の冷静なコメントが、一部のゲテモノ好きギャルたちの間でじわじわバズり始めた！
「光秀様の作る鮒ずしパフェ、マジでヤバそうだけど気になる！」
「意外とアリかも…？」
SNSは光秀様の鮒ずし愛でじわじわ盛り上がり！しかも、光秀様、ただ作るだけじゃなくて、全国各地の珍しい発酵食品を探し求めたり、意外な食材と組み合わせたり、マジで実験的なパフェを開発してたんだって！「鮒ずし×抹茶」「鮒ずし×チョコレート」「鮒ずし×チーズ」…想像を絶する組み合わせ！
で、ついに！光秀様は、京都のど真ん中に、自分のプロデュースする鮒ずしパフェ専門店「AKECHI'S FERMENT PARFAIT - 謀 - 」をオープンさせちゃったの！お店の内装も、黒を基調としたシックな雰囲気で、光秀様の知的なイメージを表現。店員さんも、ちょっとミステリアスな雰囲気の着物風ユニフォーム着てて、マジで怪しい！
オープン初日から、ゲテモノ好きギャルや、怖いもの見たさの観光客が、意外と集まり始めた！「SNSで話題の鮒ずしパフェ、マジで挑戦してみたい！」「光秀様って、なんかかっこいい！」って、新しいファンが続々！でね、一口食べたら、賛否両論！「うわっ、マジで臭いけど、なんかクセになる！」「意外とイケる！」「これは…謀反の味だ！」って、色んな意味で衝撃を受ける人が続出！
しかもね、光秀様、ただお店やってるだけじゃないんだよ！全国の発酵食品メーカーとコラボして、新しい発酵素材を開発したり、鮒ずしパフェを使ったパリピなイベントを企画したり、マジでゲテモノスイーツ界を盛り上げようと暗躍してるんだって！
テレビや雑誌の取材も、最初は色物扱いだったけど、「意外と美味しい」「中毒性がある」って口コミが広がり始め、徐々に 超うざい な取材も増えてきた！「令和の明智光秀」「ゲテモノスイーツの革命児」とか呼ばれて、ちょっとした時の人に！
でさ、最終的にどうなったかって？もちろん！光秀様の鮒ずしパフェは、一部の熱狂的なファンに愛される山田うどんと双璧 なソウルフードになったんだって！お取り寄せスイーツとしても人気が出て、全国のゲテモノ好きに衝撃を与えた！天下統一…とまではいかなかったけど、ゲテモノスイーツ界で確固たる地位を築いた！マジですごすぎ！
あの時、京都の街で静かに佇んでいた謀反の武将が、令和の時代にげろげろ な鮒ずしパフェで新たな道を切り開くなんて、マジで誰も想像してなかったよね！まさに、謀反の香りがチョベリバ なブームを巻き起こした瞬間！
京子も、「まさか光秀様の鮒ずしパフェが、こんなに くさそう な人気が出るとは…わたくしも、ちょっとハマっちゃったかも…？」って、複雑な表情を浮かべてたらしいよ。
光秀様は今も、さらなる くさそう な発酵食品を探し求めて、日本全国を旅しているらしい。「わが くさそうな道に、終わりはない！」って、マジで野心家！
こうして、明智光秀は、令和の日本で、信長様にぶん殴られるぐらいくさい鮒ずしパフェという新たな武器を手に入れ、見事、ゲテモノスイーツ界のカリスマとなった！天下統一…ではないかもしれないけど、そのくさそう な存在感は、多くの人々の記憶に刻まれたはず！めでたしめでたし…なのか？マジでくさそうな物語、完全燃焼したわ！鮒ずしパフェ、マジで…うん、 くさい！
