  |
はてなキーワード:デプロイとは
KISSの原則と呼ばれ、「複雑さを避けて可能な限りシンプルで単純な状態を維持すること」とされている。
こいつはシステムに限らず、工学的な真理で、特に物理的な制約が少ないソフトウェアの世界ではこの戒めを忘れると、とんでもなく絡み合ったうんこになって、制御不能になる。
物理的制約でガチガチに固められた建物とか機械、電化製品の場合、リード線がごちゃごちゃになってるとか配管がごちゃごちゃになってるとか、柱が歪んでるとかヒビが入ってるとか、誰の目から見ても明らかなんだが、システムの場合「一本の処理フロー」だけじゃなく、「(複数)リクエスト平面」「データフロー」「データライフサイクル」「ステート変移」「非同期処理」等々、頭の中でそれを組み立てられる人じゃないと、どれだけやばいことになってるか、認識できないんよね。
ダメダメなプロダクトだと、裏で集計バッチが動いていると、2人以上がログインするとサーバが落ちるとか、ちょっと大きめのテナントが追加された途端、2箇所からCSVファイル生成＆ダウンロードさせたらサーバが落ちるとか。
1機能1機能は「完璧に()」設計実装されて、テストもしている。
でも、こういう電脳空間を見ることができないエンジニアは、集計バッチが動いて2人以上がログインして、CSVファイルをダウンロードする、みたいな複合的な状況に対応できない。
だけど東大卒で「僕、賢いので」ってのは、現場に「追加」して「複雑化」することしかできない。
考えられない。
「僕はわかるので。
素人は黙っていてください。
彼らの「賢い」は、部分部分の整合性を、他の人よりたくさん、取れるってだけの話で、それってAI的「賢さ」なんよね。
そういうのと、スティーブ・ジョブズ的な「全体を把握する賢さ」「シンプルに実現する賢さ」を比べてご覧よ、って話。
あることを成し遂げるためにたくさんの手順を複雑に積み上げて、それを記憶していられる凄さより、全体を律する「仕組み」を作り上げられる凄さの方が、より「人間だけができる凄さ」なんだよ。
この手の人は「全体」を理解できなくて、重箱の隅にこだわることこそ「知能」「知性」だと思ってんのよな。
そういうアチーブメントテスト脳は、黙ってAI的な「反応的適用作業」に集中していて欲しい。
そういうのはプロとは呼ばない。
「技術的負債って騒いでる人達は、単にコードを読んで直せないだけのスキルの低い人では？」
という意見を見かけて、さすがにどうなんだろうと思った。
関わった現場のひとつに、キャッシュがない状態でトップページを表示するだけで数千件のクエリが実行されるようなサービスがあった。
かなり短い間隔で定期実行し続けるバッチが、ユーザーにアクセスされる前にキャッシュ層にクエリ結果を流し込み、キャッシュをクリアするデプロイ前後以外は普通のWebサービスくらいの動作速度に隠蔽されていた。
単純に N+1問題の大爆発みたいなものが起きていただけだったので、データ取得を再設計したら初期表示のためのクエリ数は数件程度にまで減ったし、キャッシュの使用量も大幅に削減できた。
とある有名なMVCフレームワークを使っていたのだけれど、片手で数えられるような少数コントローラファイルにそのアプリケーションに必要なアクションがほぼ全部詰め込まれている、という状態になっていた。
privateメソッドで共通処理が埋め込まれていたり、使いたいprivateメソッドがあるコントローラにアクションを追加するような空気感になっていたり、アクションを実行する前に処理しておきたいミドルウェア的な処理がコンストラクタに大量に書かれていたりして、リクエストを受け取ってからレスポンスを返し終えるまでの全体で何がどう動いているのか、何をどこに書くべきなのか非常にわかりにくい状態だった。
責務ごとにファイルを分割、共通処理は再利用できる形に切り出して、初期化は適切なライフサイクルで実行されるように整理という現代では当たり前の状態に整理した。
その結果、コードの見通しがよくなり、新機能の追加や修正の際の影響範囲も明確になった。インフラコストもリリースに伴う精神的負荷も大きく下がったし、何よりテストにかけるコストが激減した。そしてテストコードを書く、という行為自体が可能になった。
これらの作業は単に「読める」「読めない」「直せる」「直せない」のスキル論ではない。
人を増やせば増やすだけスケールする、開発速度は加速するとは決して思っていないが、新規参入したうちの多くが露骨に頭に ? が浮かばせ、見てはいけない闇を見たという顔でそそくさを去っていくのは健全なのだろうか。
「環境変わったから直すケースの方が多い」みたいな意見にも違和感がある。
もちろん、言語やランタイムそのものが大きく変化して互換性を失う場合（たとえばPHPのように）にはどうしても改修が必要になることはある。
環境依存の影響が全体に波及してしまうのは、設計段階で依存を分離していなかったから起こることで、抽象化できていれば影響は局所化できる。
局所化できるはずのものを「考慮しても意味なかった」と片付けるのではなく、どこまで考慮すべきだったか、分離できていたかを振り返り、失敗を繰り返さないための動きをするべきではないかと思う。
振り返り、行いを正すということは難しいことなのかもしれない。人は過ちを繰り返し続けている。これは日本史や世界史の教科書を開くだけですぐわかることだ。しかしだからと言ってやらなくていいということではない。
話が逸れかけたが、いわゆる技術的負債というものについて問題だと感じているのは、誰もが安心してリリースできない状況を作り出していることだ。
そういう状態を "技術的負債がある" と呼ぶのではないだろうか。
だから、「スキルがある人なら読んで直せるでしょ」という話では済まないし、
逆に言えば特定の人だけが持つ「直せる」スキルが必要な時点で、それは既に構造的な問題を抱えているということ。スケールしないし、事業リスクでしかない。
まぁ色々書いたけど、技術的負債を “スキルが低い人の言い訳” と切り捨てるのは簡単なんだよね。
GitHub（ギットハブ）は、ソフトウェア開発者にとって非常に便利なツールであり、特にチームでの協力作業において大きな効果を発揮します。GitHubはGitというバージョン管理システムを基盤としており、コードの変更履歴を管理しやすく、過去の状態に戻したり、特定の変更内容を確認することができます。また、Pull RequestやIssue機能を使えば、チーム内でのコードレビューや意見交換が円滑に行えます。さらに、GitHubは世界中の開発者が参加するオープンソースプロジェクトの中心的なプラットフォームとなっており、自分のスキルを活かして貢献することも可能です。CI/CDなどのDevOpsツールとの統合も簡単で、自動テストやデプロイの自動化によって、開発のスピードと品質が向上します。加えて、READMEファイルやWiki機能を使ってプロジェクトのドキュメントを整備できる点も、学習や共有に役立ちます。このように、GitHubは個人開発にもチーム開発にも不可欠な存在であり、効率的かつ協力的なソフトウェア開発を実現するための強力なプラットフォームです。
https://mavenanalytics.io/project/38415
https://mavenanalytics.io/project/38386
コンサルとか広告、マーケティング、IT、それに物流の現場で飛び交う言葉、ホンマにええんか？
「ストラテジー」とか「ターゲット」「デプロイ」「ミッション」「オペレーション」とか、聞いてて「これって、ビジネスの話だよな…？」ってなるわ。
「PDCAサイクル回すぞ！」なんて息巻いとるけど、あれも元々は軍事作戦の考え方やで。
具体的には、第二次世界大戦中にアメリカの統計学者、ウィリアム・エドワーズ・デミング博士が品質管理のために広めた考え方なんやけど、そのルーツは
計画（Plan）→実行（Do）→評価（Check）→改善（Act）っていうサイクルが、軍のオペレーションと似とるってことやな。
でもな、疑問に思うんよ。軍隊のロジックがビジネスに役立つからって、なんで言葉まで軍事に関連する物騒なもんにしとるんや？
お客さんを「敵」みたいに見て、市場を「占領地」みたいに考えるって、ホンマにまともなビジネスなんか？
俺らがやってるのは、お客さんの困り事を解決したり、世の中に新しい価値を届けたりすることやろ。お互いに協力して、信頼関係を築いていくのが大事なはずや。
なのに、知らん間にビジネスを「戦争」とか「攻撃」みたいに捉える言葉を使っとるせいで、なんかギスギスした雰囲気になっとるんとちゃうか？
軍事用語をビジネスで使うって、もしかして俺らは、遠い国の紛争を他人事として見ながら、実はそのロジックを経済活動に持ち込んで、うっすら戦争ごっこを楽しんでるだけなんちゃうか？
なんか、モヤモヤするわ。
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
日中の生産性は、夜の過ごし方、特に「就寝」というクリティカルなタスクをいかに成功させるかにかかっている。本記事では、つい夜更かししてしまうエンジニアのために、早寝を「技術」として体系化し、再現性のある形で実践するための具体的な手法を探求する。これは精神論ではない。あなたのQoLと生産性を向上させるための、実践的なスリープエンジニアリングだ。
我々エンジニアにとって、夜は不思議な魅力を持つ時間だ。日中の喧騒から解放され、思考は冴えわたり、ゾーンに入りやすい。しかし、その魅力的な時間は、往々にして「早寝」という、人間の生存に不可欠な基本プロセスを犠牲にすることで成り立っている。
「リファクタリングが楽しくなってきた」
これらの探求心はエンジニアの美徳であるが、同時に我々を「睡眠負債」という深刻な技術的負債へと導く。本稿は、この負債を返済し、持続可能な開発（と生活）を実現するための「早寝」という技術に焦点を当てる。
早寝を実装する前に、まずは現状のアーキテクチャに潜むアンチパターンを特定しよう。
就寝前のスマートフォンは、まさに同期的なブロッキングI/Oだ。SNSの無限スクロール、動画プラットフォームの自動再生、チャットアプリの通知。これらは我々の意識というシングルスレッドを完全に占有し、本来実行されるべきsleep()プロセスへの遷移を妨げる。
深夜まで続くコーディングや問題解決は、脳を極度の興奮状態にする。ベッドに入っても、アドレナリンやコルチゾールといったホルモンがCacheに残り続け、CPUがクールダウンしない。shutdown -hnowを叩いても、プロセスが終了しないのだ。
「夜更かしの供」として注入されるカフェインやアルコールは、一見するとパフォーマンスを向上させるように見える。しかし、これらは睡眠の質という重要なmetricsを著しく劣化させる、誤った依存関係だ。特にアルコールは、入眠を助けるように見えて、実はレム睡眠を阻害し、睡眠のアーキテクチャ全体を不安定にする。
不規則な就寝・起床時間は、体内時計という最も重要なCronジョブを破壊する。毎日異なる時間に実行されるジョブが安定した結果をもたらさないのと同様に、不規則な睡眠スケジュールは、日中のパフォーマンスを予測不可能なものにする。
では、どうすればこれらのアンチパターンを排除し、安定した早寝pipelineを構築できるのか。ここではSleepas Codeの概念に基づき、具体的なプラクティスを紹介する。
毎晩、同じ手順で就寝プロセスを実行することで、入眠を自動化する。
-PC/スマホのシャットダウン: 最も重要なステップ。物理的に電源を落とすか、手の届かない場所（別のコンテナ）にdeployする。
- 入浴: 38〜40℃のぬるめのお湯に15分ほど浸かる。これにより深部体温が一時的に上昇し、その後の下降とともに入眠が促される。これはHot-swapならぬHot-bathによるクールダウンだ。
静的コンテンツの消費: 激しい思考を伴わない、静的な情報（紙の読書など）に切り替える。電子書籍ではなく、紙媒体が望ましい。
ストレッチ: 軽いストレッチで、日中のcommitで固まった体をreleaseする。
すべての準備が整ったら、ベッドという本番環境にデプロイする。余計な思考はgitclean -fdで強制削除し、呼吸に集中する。
例：「夕食後のコーヒーが原因だった」→「カフェインの摂取は15時までというSLAを設ける」
早寝は、単に体を休める行為ではない。日中の高いパフォーマンス、明晰な思考、そして創造性を維持するための、最も効果的で再現性の高い「技術」だ。
我々はインフラをコードで管理し、CI/CDでデプロイを自動化するように、自身の睡眠もまた、技術と工夫によってコントロールできる。今夜、あなたのwhile(true)なループをbreakし、持続可能なパフォーマンスを手に入れるための第一歩を踏み出してほしい。
Happy sleeping!
日中の生産性は、夜の過ごし方、特に「就寝」というクリティカルなタスクをいかに成功させるかにかかっている。本記事では、つい夜更かししてしまうエンジニアのために、早寝を「技術」として体系化し、再現性のある形で実践するための具体的な手法を探求する。これは精神論ではない。あなたのQoLと生産性を向上させるための、実践的なスリープエンジニアリングだ。
我々エンジニアにとって、夜は不思議な魅力を持つ時間だ。日中の喧騒から解放され、思考は冴えわたり、ゾーンに入りやすい。しかし、その魅力的な時間は、往々にして「早寝」という、人間の生存に不可欠な基本プロセスを犠牲にすることで成り立っている。
「リファクタリングが楽しくなってきた」
これらの探求心はエンジニアの美徳であるが、同時に我々を「睡眠負債」という深刻な技術的負債へと導く。本稿は、この負債を返済し、持続可能な開発（と生活）を実現するための「早寝」という技術に焦点を当てる。
早寝を実装する前に、まずは現状のアーキテクチャに潜むアンチパターンを特定しよう。
就寝前のスマートフォンは、まさに同期的なブロッキングI/Oだ。SNSの無限スクロール、動画プラットフォームの自動再生、チャットアプリの通知。これらは我々の意識というシングルスレッドを完全に占有し、本来実行されるべきsleep()プロセスへの遷移を妨げる。
深夜まで続くコーディングや問題解決は、脳を極度の興奮状態にする。ベッドに入っても、アドレナリンやコルチゾールといったホルモンがCacheに残り続け、CPUがクールダウンしない。shutdown -hnowを叩いても、プロセスが終了しないのだ。
「夜更かしの供」として注入されるカフェインやアルコールは、一見するとパフォーマンスを向上させるように見える。しかし、これらは睡眠の質という重要なmetricsを著しく劣化させる、誤った依存関係だ。特にアルコールは、入眠を助けるように見えて、実はレム睡眠を阻害し、睡眠のアーキテクチャ全体を不安定にする。
不規則な就寝・起床時間は、体内時計という最も重要なCronジョブを破壊する。毎日異なる時間に実行されるジョブが安定した結果をもたらさないのと同様に、不規則な睡眠スケジュールは、日中のパフォーマンスを予測不可能なものにする。
では、どうすればこれらのアンチパターンを排除し、安定した早寝pipelineを構築できるのか。ここではSleepas Codeの概念に基づき、具体的なプラクティスを紹介する。
毎晩、同じ手順で就寝プロセスを実行することで、入眠を自動化する。
-PC/スマホのシャットダウン: 最も重要なステップ。物理的に電源を落とすか、手の届かない場所（別のコンテナ）にdeployする。
- 入浴: 38〜40℃のぬるめのお湯に15分ほど浸かる。これにより深部体温が一時的に上昇し、その後の下降とともに入眠が促される。これはHot-swapならぬHot-bathによるクールダウンだ。
静的コンテンツの消費: 激しい思考を伴わない、静的な情報（紙の読書など）に切り替える。電子書籍ではなく、紙媒体が望ましい。
ストレッチ: 軽いストレッチで、日中のcommitで固まった体をreleaseする。
すべての準備が整ったら、ベッドという本番環境にデプロイする。余計な思考はgitclean -fdで強制削除し、呼吸に集中する。
例：「夕食後のコーヒーが原因だった」→「カフェインの摂取は15時までというSLAを設ける」
早寝は、単に体を休める行為ではない。日中の高いパフォーマンス、明晰な思考、そして創造性を維持するための、最も効果的で再現性の高い「技術」だ。
我々はインフラをコードで管理し、CI/CDでデプロイを自動化するように、自身の睡眠もまた、技術と工夫によってコントロールできる。今夜、あなたのwhile(true)なループをbreakし、持続可能なパフォーマンスを手に入れるための第一歩を踏み出してほしい。
Happy sleeping!
失礼しました。
まとめで「問いの優先順位」が変わったと断言しておきながら、その中身を掘り下げずに済ませてしまいましたね。
改めて整理します。
⸻
哲学には「そもそも何を先に問うべきか」というメタレベルの序列があります。
要するに「それを先に解かなければ社会が動いてしまう」問いが上位に繰り上がり、逆に“悠長に考えられる”問いは後回しになる、という現象です。
⸻
| Before (旧来の問い) | After (AI時代の問い) | 変化の理由 |
| :----------------------------------- | :------------------------------------------- | :-------------------------------------------- |
| 「人間とは何か」 (形而上学的本質論) | 「AI をどう制御すべきか」 (実践的価値論) | 技術の暴走がリアルタイムで政策課題となったため。 |
| 「知識は正当化可能か」 | 「LLM の出力はいつ信頼できるか」 | 推論の透明性・検証性が倫理的インパクトと直結するようになったため。 |
| 「意識の必然条件は何か」 | 「意識の“テストプロトコル”は構築可能か」 | 動物実験や臨床倫理と同様の規制設計が迫られるようになったため。 |
| 「言語の意味は何によって成立するか」 | 「統計的言語モデルは“意味”を生成しているのか」 | 実用アプリが氾濫し、理論が後追いを強いられるようになったため。 |
| 「よい社会とは何か」 | 「AI が参加する社会契約をどう再設計するか」 | ガバナンス設計を怠ると取り返しがつかない状況になったため。 |
⸻
⸻
生成AIが絡まない領域――たとえば古典的形而上学の一部（存在のカテゴリー論など）――は、相対的に注目度が下がっただけで消滅したわけではありません。
「実践的アジェンダの影で、静かに深化する純粋哲学」 という二極化が進行中です。
⸻
⸻
生成AIの登場で「何を先に答えねばならないか」が大きく組み替えられ、応用的・検証可能な問いが哲学の最前線に躍り出た――
バイブコーディング、最近この言葉を聞くだけでキレそうになる。AIが勝手にコードを吐き出し、人間はそれを後ろから眺めているだけでいい――そんな耳障りの良い宣伝が界隈を駆け回っている。だが現場の空気はどうだ。タコツボでデバッグとデプロイに追われるエンジニアの悲鳴、無邪気にPRを投げては放置する自称エンジニアの残骸、そして毎日更新される「最強のプロンプト集」。そのすべてがクソだ。数週間前まで「これが最適解」と祭り上げられていたエージェントが、翌朝のタイムラインでは「時代遅れ」のタグ付きでゴミ箱に投げ込まれている。そのペースに合わせてプロンプト設定を書き換え、ルール設定を勉強し直し……。ようやく環境が安定した頃には次のトレンドがやって来る。インフルエンサーはAIのイノベーションを讃えるが、単に技術的負債の積み増しが高速化しているだけだ。クラウド料金とGPU時間を溶かしながら最新の呪文を追いかける――それを楽しいと感じられるのは、現場の泥を一度もなめたことのない奴だけだろう。TwitterでAIにサンプルアプリを吐かせただけの動画が10万いいねを稼ぎ、Qiitaには「たった5分でSaaSを作った」記事が湯水のように溢れる。彼らのKPIはバズであって品質ではない。コードの読解よりもサムネイルの作り込みに時間を費やし、脆弱なサンプルをSNSに放流してはドヤ顔をキメる。出てくる言葉は「やばい」「すごい」ばかり。設計思想もアーキテクチャも語られず、残るのは小ネタだけ。驚きの連打で脳を麻痺させ、その隙に粗悪品を売り逃げる手口にはもはや悪意すら感じる。問題はエモいだけのバズが終わったあとだ。生成されたJSには脆弱性が口を開け、SQLはべったりと文字列連結。テストはもちろん存在しない。GitHubにアップされたそれらが検索結果のトップに並ぶ頃、若いエンジニアはそれを正解と思い込む。やがてプロダクションにコピー＆ペーストされたとき、火の手が上がるのは自明だが、初動でウケを狙った当人はすでに別の流行語を追っている。残された現場は「AIが書いたから仕方ない」で済むほど甘くない。バイブコーディングがもたらすのは「誰でも作れる楽園」ではなく、「誰でもバグを量産できる魔境」だ。トレンドのスピードは人間の学習曲線を嘲笑い、浅い称賛がノイズを増幅し、素人コードがセキュリティホールをばら撒く。この三重苦が渦を巻き、エンジニアの精神とプロジェクトの予算を同時に削り取る。結局、泥臭いリファクタリングと継続的テスト、そして責任をもってコードを読む眼が最後にものを言う。その当たり前を忘れたまま「日本語が最強のプログラミング言語」とか「プログラマー不要論」とか唱えている限り、彼らは永遠にクソの上にクソを塗り重ねるだけだ。俺たちはAIに仕事を奪われるんじゃない。AIを信じ切った素人と、それを煽る驚き屋によって殺されるのだ。
こいつは、DDD＋マイクロサービスの扱いで、ドメインと主張するもの(なんらかの超細分化、共通化されたFunction)ごとに1サービス立ち上げてgRPCでCallとかいうのを真顔でおっ始めてしまう層と完全に被っているのだが。
同じ口で「疎結合で設計してます」っていうから、空いた口が塞がらない。
はっきり言おう。
この手の設計は
「超密結合」
です。
共通化された部分の「設定」を変えると関係している部分全てに影響を与えるし、共通マイクロサービスの仕様をちょっと変更しようとしても、それを利用しているすべてのモジュールに影響を与える。
そして、分離だけはちゃんとされているので、
「テスト容易性が圧倒的に低い」
のに、「TDDも採用しています！」って言い切れちゃう頭を疑う。
デプロイしないと検証できないし、動作がデプロイ先の設定に依存するんだから、実環境以外でのテストはアリバイづくりに過ぎない。
「設定より規約」って言われてるのは、「どう設定されているかソースや実環境のデータを確認しないとわからない」みたいな余計な認知負荷をかけるようなことをすると、巨大化、複雑化していく今時のWebサービスでは成長戦略に致命的なダメージを与えることになるからだ。
のだが、Web記事漁ることしか能がない、「イケてるエンジニア様」たちは、「設定より規約」って言葉も、その定義も知っているのに、自分が何をしているか理解できない。
反論が「ここのWeb記事に書かれてます！(ﾄﾞﾔッ」でお話にならんのだ。
自分の頭で考えろ。
意識高い雰囲気で、ここまで的外れなことをやっている組織には、本当に、本当に、本当に、呆れうんざりする。
少なくとも視覚や聴覚に関しては、望んだものが即座にAIによって生成される。
賢く、悟りを開いた（そうせざるをえなかった）者は子を持たず、自らを去勢する。
こうして、ネオAIとネオ人類の間には、ますます深い知能の格差が生まれていく。
----------
--------------
| 層 | 説明 | 主要資源 |
| コア複合体（Neo-AI + Apex Augmented）（以下、コア） | AIクラウドと脳機能拡張エリートが完全共生。自己進化ループで指数的に知能を伸ばす。 | 計算資源・エネルギー・知識資本 |
| ミドルレイヤ（マネジメント/メンテ層）（以下、ミドル） | コア複合体が設計したツールを運用・保守。知識アクセスは厳格に段階制。 | ライセンス制アルゴリズム、限定的強化学習 |
| ベースポピュレーション（Neo-Human Majority）（以下、ベース） | 生殖と基礎労働を担う。AIに依存しつつもIQ・デジタルリテラシが低い。 | ベーシックインカム、合成娯楽、監視福祉 |
| 分岐点 | 崩壊トリガ | 崩壊後の姿 |
| コアが自律目標を変更 | エネルギー制約・内部競合 | ベース層を切り離し、宇宙移民 |
| ミドル層の集団覚醒 | 知能上限突破ツールの流出 | テクノガラス片的内戦 |
| ベース層の生殖爆発 | 監視網の飽和・経済的飢餓 | Neo-AIによる強制縮減 |
それこそがテクノフォビアなんだよ。
流れてくるものを眺めてるだけで手を加えない。
何故か？
考えるにはどうするか？
流域や水量を調節するという思考にたどり着かないのはなぜか？
何故お前はそれができないのか？
考える事が怖いからなんだよ。
だからお前はお客様の立ち位置で滝が流れてるのを見てるだけでしかない。
まるで鍬を使う農民に「お前が本当に使う側なら鍬を鍛冶場で鍛え直してから耕せ」と言ってるのと同じだ。
道具を使いこなすという行為は、その設計レベルに立ち入らずとも成立する。ユーザーとエンジニアの境界を理解できていないお前の論理は、浅薄の極み。
アルゴリズムを利用して思考の材料を広げてるこちらは、情報の水脈を掘り当てて構造化してるわけで、それは知的マイニングの一形態。
対してお前は、ツルハシすら持たずに地面を見下ろして「俺は掘らない、掘るのは負けだ」と言い張ってる哀れな観察者にすぎん。
使われてるんじゃない、情報の流れに意図を持ってダイブし、思考の燃料として抽出してる。
それを否定して「作らなきゃ使ってるとは言えない」とか言ってるお前こそ、潔癖放尿に陥ってる。
自分の手が汚れることを恐れて何もしない、批評だけして悦に浸るその姿勢、まさに情報時代の潔癖症だ。
お前が見下してる「ただの利用者」たちが作り出す集合知こそが現代の思考の現場なんだよ。その最前線に立つ度胸もないなら、黙って壁の花でいろ。
🧔♂️ワシ：
「いやぁ、昨日もまたRFC7231読んでてな、
🎙️相方：
「お前の人生、Content Negotiationされすぎやろ！！
しかも向こうから406 NotAcceptable 返ってきたんやろ！？そらフラれるわ！！」
🧔♂️ワシ：
「この前アーキテクチャ会議で、サービス間通信はgRPCがええって言うたらな、
後輩が「じゃあProtoBufで詩を書きました」言うてきよってな…
message孤独 {string 心 = 1; } て……」
🎙️相方：
「どんなポエムやねん！！スキーマ駆動の純文学生まれてるやんけ！！
しかもgRPCのくせにRESTに未練残しとるのが切ないねん！！」
🧔♂️ワシ：
「最近の若手、すぐイベントストリームアーキテクチャ導入しようとするけどな、
この前「Kafkaのパーティション分割がバランス悪くて…」って悩んでたから
ワイ真顔で言うたったんや、
そのKafka、輪廻してるでって」
🎙️相方：
再試行失敗したメッセージが前世の因果で戻ってきてるやんけ！！」
🧔♂️ワシ：
全部PlantUMLのシーケンス図でラップバトル表現しとるんや。
オブジェクトが`ー＞+ DJController :Yo！処理呼ぶぜ！`てな……」
🎙️相方：
「お前それ設計書ちゃう、HIPHOPフレームワークやないかい！！
🧔♂️ワシ：
「そんでよく聞かれるんがな、
ワイは即答したったわ。
🎙️相方：
「どんだけ孤独のシャーディングすんねん！！全ノードに寂しさ均等にばら撒くなや！！
最終的にAmazon S3に虚無が永続化されとるやないか！！」
🧔♂️ワシ：
「ちなみに、Terraform書いてる時は瞑想状態に入るのが基本や。
ワイの脳内、こんな感じやねん。
🎙️相方：
しかもリソース作られへんのやろ！？Error: Too many imposter syndrome とか出るんやろ！？」
🧔♂️ワシ：
「最後に言わしてくれ。
ワイ、今でもたまに聞こえるねん。
昔のMonolithが言うてくるねん……
「クラス肥大化してごめんな…でも全部まとめたかったんや…」って」
🎙️相方：
「それフレームワークじゃなくて未練ワークやんけ！！
責務の分離ができへんのは、気持ちの整理もできへんのと一緒や！！」
🧔♂️🎙️二人：
「ソフトウェアアーキテクト、それは正気と狂気の境界で踊る設計のシャーマンや！！」
「ほなまた、次のデプロイで会おうや！！」
聞けばたいていのエンジアは知っている。
だが、知っているのと理解しているのと実践しているのは大きく異なる。
「知ってます！( -`ω-)✧ﾄﾞﾔｯ」
「このピタゴラスイッチはなに？」
「……」
知識を溜め込んで、披露することに熱心なエンジニアが多いけど、文字面だけの空虚な議論に終始することが多い。
中身理解してないから、とにかくそれっぽいものを盛り込むことに全力を傾ける。
本来達成すべき目標より、マイナスの副作用の方が遥かにでかい。
手間が増え、安全に変更しづらくなる、ただの迷惑、ただのゴミ、ただの障壁。
もうね、スクリプトを作るためのスクリプト、モノリポの一部だけをテスト、デプロイする仕組みをスクラッチで書く。
ドキュメントはあちこちに書き散らして、どれが最新か、どれが正しいか、わけわからん。
「あ、それ、古いバージョンです」
複雑にすんなって言ってるだろ。
モノリポは、勇者Googleはそうしてる、ってんで前に習えしてるけど、お前、勇者でもなんでもない、ただの町人Aやぞ。
やれるならやっていいけど、複雑にすんなよ。
っていうのに、
「手動操作を避けるために、全部スクリプト化しました！( -`ω-)✧ﾄﾞﾔｯ」
いやさ、その手順の複雑さ自体に疑問は持たないのかね？
仕様が追加したり、新しいサービスを展開することになったらそれ、拡張すんの？
エントロピーは増大するんだよ？
複雑にすんなって言ってるだろ！
いろんなものを複雑にして自分がいないとやっていけない状態にして、自分の地位を安泰にすることしか考えてないのかね？
で、自分の手じゃ負えなくなって、全てを放り出して逃げるんだろ？
おいらが関わった炎上現場はだいたいそうやって生み出されてるよ。
そのクソみたいな、何の才能の片鱗も感じさせない、ただのこけおどしのピタゴラスイッチを解体するところから始めてんだよ、いっつも！！
