  |
はてなキーワード:プラクティスとは
「旧来モデル批判派」は、結婚指輪の贈答を「経済的従属の象徴」「時代遅れのステータス表示」「呪い」と定義し、現代の「自立した大人」の価値観と矛盾すると主張している。
本プロジェクトの目的は、この批判が陥っている「過度な市場原理主義的解釈」の誤謬を指摘し、結婚指輪を「非言語的コミュニケーションプロトコル」として再定義することによって、その機能的有効性を論証することにある。
本反論の構築にあたり、「PREP法（Point,Reason, Example,Point）」を拡張した論理構成を採用する。
批判派は「自立＝すべてを自分で調達すること」と定義しているが、これは共同体運営において非効率である。
結婚とは相互依存（Interdependence）の契約である。「欲しいものは自分で買う」という論理は独身者の生存戦略であり、夫婦という最小単位のチームビルディングにおいては、「贈与」による関係性の強化こそが合理的である。
「経済的自立」と「情緒的相互依存」は両立可能であるという概念実証。
人間の認知は不安定であり、数十年単位の契約（結婚）を維持するには、物理的な「アンカー（錨）」が必要である。指輪を見るたびに契約当初の感情（決意）を想起させる機能は、認知心理学的に「プライミング効果」として有効であり、これを「呪い」と呼ぶのは、契約維持の難易度を過小評価した楽観論に過ぎない。
指輪は「金属片」ではなく、関係維持のための「外部記憶装置」であるという再定義。
対等な関係なのに、記念品だけ経済力の証明を求めるのは矛盾とする。
マルセル・モースの『贈与論』が示す通り、人間関係は「等価交換（市場原理）」ではなく、「あえて借りを作る/与える（贈与原理）」ことで深化する。完全に割り勘化された関係（市場原理）は、損得が釣り合わなくなった瞬間に破綻する。一方的に高価なものを贈る・受け取るという「非対称性」こそが、論理を超えた「ケアの意思表示」となる。
「価格表」ではなく「コミットメントの質量の可視化」としての指輪の価値証明。
本プロジェクトの結論として、「引用文の主張は、人間関係を『市場取引』と混同しており、情緒的結合のメカニズムを見誤っている」と断定する。
なぜ、この結論に至るのか？「なぜ？」を3回繰り返して深掘りを行う。
A1.現代の「超・個人主義」バイアスにより、すべての事象を「コスト対効果（コスパ・タイパ）」でしか計測できなくなっているから。
「愛」や「信頼」といった数値化できない資産を扱う際、彼らは不安を感じるため、目に見える「金額」や「所有権」という市場的な指標に無理やり換算して理解しようとする。その結果、「買ってもらう＝従属」という短絡的な図式に陥る。
A2. 「他者への依存」を「リスク」としてしか認識できない、「脆弱性への恐怖（Fear ofVulnerability）」があるから。
「誰かに高価なものを買ってもらう」ことは、相手に借りを作ること、あるいは相手の愛情に身を委ねることを意味する。これは非常に無防備（Vulnerable）な状態である。批判派は、この「傷つくかもしれないリスク」を回避するために、「自分で買えばいい（自己完結）」という安全地帯に逃げ込み、それを「自立」という言葉で正当化している。
A3.現代社会において「共同体（コミュニティ）」が崩壊し、個人の生存責任が過剰に肥大化した結果、他者を信じて委ねる「贈与の作法」を喪失してしまったから。
昭和的価値観への嫌悪感から、彼らは「ウェットな人間関係」を全否定した。しかし、結婚とは究極のウェットな関係である。彼らの主張は、「傷つきたくないから、心の防壁を高く積み上げ、すべての貸し借りを清算し続ける」という、孤独な防衛本能の叫びである。したがって、結婚指輪という「非合理な贈与」を受け入れられないのは、彼らが「完全に他者を信じ切る（委ねる）」覚悟を持てていないことの裏返しに他ならない。
結婚指輪の贈答は「古い依存モデル」ではなく、「市場原理を超えた信頼関係構築のための高度な儀式」として、現代においても推奨されるべきプラクティスであると結論付ける。
自称メンヘラが書いたスト6やその環境について愚痴をこぼしたnoteを呼んだ。
実際メンヘラしぐさが随所にあり、そりゃ格ゲー以前に対戦ゲーム向いてねえなという感想にしかならなかったのだが、ちょこちょこ納得する部分もあった。
特にそう感じたのは『本当に上級者の教えは、初心者にとってためになる「教え」が出来ているのか』という部分。
これは一見単なる甘えだしタダで教えてもらっといて何様じゃいこのアホがとしか思えない。しかしこれはある意味正論だと思う。
スト6は格ゲー衰退に危機感を感じたカプコンや、その意思を汲み取ったプロゲーマーたちが惜しげもなく技術を公開し時にはコーチングもしてくれるような環境が築かれているというのはゲーム好きならみんな知ってる話だ。
配信なども積極的に行い、Vtuberのような（実際はどうか知らんが）格ゲー初心者にも宣伝をしてもらい間口を拡げる努力をしている。
だけどここにはある視点が欠けている。
『星のカービィをなんとかクリアできるくらいの、本当のゲーム初心者』はどう遊べば、どう覚えればいいのかというところだ。
モダン操作も、ワールドツアーも、プラクティスも、初心者向けとされている要素には『ゲーム初心者』はどうするべきかという答えに全くなっていない。
それは何故かというと、格闘ゲームという存在自体がどれだけチューニングしてもゲーム中級〜上級者が触れるものにしかなれないからだ。
どれだけ操作を簡略化しようと格ゲーはそもそものハードルが高い。自分の知る中で一番シンプルな格ゲーだったジョイメカファイトですら覚えることはそれなりにある。ホウオウにめっちゃボコボコにされた思い出も蘇ってきたぞ。
つまり格闘ゲームとは『格ゲー初心者（違うジャンルのゲームはよくやる）』が遊ぶものであって、『ゲーム初心者』が遊んではいけないものだ。
なのでほぼゲームしたことないけど格ゲーに興味を持った人は、まずマリオとかドラクエとかAPEXとかやって、そもそも自分がビデオゲームという娯楽に向いてるかどうかを試してください。そうしなければお互い不幸になるだけです。
いま、この転換点において、皆さまとご一緒できることを光栄に思います。同時に、私たち国内SIerにとっての責務でもあります。
本日は、世界の“秩序”の断絶、心地よい物語の終わり、そして、巨大な力を持つプレイヤーの競争がほとんど制約を受けない厳しい現実の始まりについてお話しします。
しかし同時に、国内SIerのような「中堅の担い手」は無力ではない、と申し上げたい。私たちには、信頼・安全・持続可能性・顧客の主権・データの保全といった価値を体現する新しい秩序を、実務から積み上げていく力があります。
私たちは毎日のように思い知らされています。いまは、巨大プラットフォームや巨大ベンダー、地政学リスクを背景にした技術覇権が競い合う時代であること。オープン性や互換性、フェアなルールに支えられた前提が薄れつつあること。そして、強い側が条件を決め、弱い側は受け入れざるを得ない局面が増えていること。
古典的に言えば「強い者はできることを行い、弱い者は耐えねばならない」という構図です。これは不可避だ、これが自然な競争原理だ、と片付けられがちです。そして、その論理を前にすると、私たちには「波風を立てずに合わせる」強い誘惑が生まれます。摩擦を避けるために順応する。相手に合わせれば安全が買えると期待する。
では、選択肢は何でしょうか。
1978年、チェコの反体制知識人ヴァーツラフ・ハヴェルは『無力者の力』という論考を書きました。そこで彼は、体制がなぜ維持されるのかを問いました。
彼の答えは、一人の店主の例から始まります。店主は毎朝、店先に標語を掲げる。「万国の労働者よ、団結せよ！」。本人は信じていない。周囲も信じていない。それでも掲げる。面倒を避けるため、従順さを示すため、波風を立てずに“やっているふり”をするために。そして、どの通りの店主も同じことをするから、体制は続いていく。
暴力だけではなく、人々が、内心では虚構だと知りながら儀式に参加することで、体制は維持される。ハヴェルはこれを「嘘の中で生きる」と呼びました。体制の力は真実ではなく、皆が真実であるかのように振る舞うことから生まれる。そして脆さも同じところにある。たった一人が“看板を外す”だけで、幻影にひびが入る。
いま、企業としても、業界としても、私たちは「看板を外す」時です。
---
長い間、ITの世界には「ルールや標準が機能し、相互運用性が担保され、勝者も敗者も一定のフェアネスの中で競争できる」という物語がありました。国内SIerも、その物語の上で成長してきた面があります。標準化、ベストプラクティス、認証制度、ガイドライン、そしてグローバルに広がる巨大なプラットフォーム。私たちはそれらを称賛し、活用し、その予測可能性の恩恵を受けました。
もちろん、その物語が“部分的に虚構”であることも知っていました。強い側は都合が悪いときに例外を作れること。ルールの適用が非対称になり得ること。互換性や標準が、実態としては特定のエコシステムに誘導する装置として働くこと。そして、契約条項、価格体系、APIの変更、提供地域や機能制限などが、力関係の影響を強く受けること。
それでも、その虚構は便利でした。巨大プラットフォームが提供してきた“公共財”も確かにあった。スケールする計算資源、安定した開発基盤、セキュリティ機能、グローバル展開の足場、部品としてのOSSやツールチェーン、紛争を減らす共通言語。
だから私たちは、看板を掲げ続けました。「オープン」「中立」「相互運用」「ベストプラクティス」という言葉を、実態が追いつかない場面でも口にしてきた。そして、言葉と現実のずれを大きく指摘することを避けてきた。
率直に申し上げます。いま起きているのは“移行”ではなく“断絶”です。
---
過去20年の間に、金融危機、パンデミック、エネルギー制約、半導体不足、サプライチェーン混乱、サイバー攻撃の常態化、そして地政学リスクが、極端なグローバル統合の脆さを露呈させました。
さらに近年、巨大な力を持つプレイヤーが「統合そのもの」を武器として使い始めています。値上げや課金体系変更が交渉力になる。契約や利用規約、認証・ID、クラウド管理基盤が実質的な拘束力になる。提供停止や機能制限、地域制約が、企業や組織に圧力として作用する。サプライチェーンが“突かれる弱点”になる。
「統合すれば相互利益」という前提のまま、“嘘の中で生きる”ことはできません。統合が従属の源泉になった瞬間、前提は反転します。
かつて中堅の担い手が拠り所にしてきた「みんなで決めるはずの場」も弱まっています。標準化が追いつかない。デファクトが事実上のルールになる。透明な合議より、エコシステムの都合が優先される。結果として、多くの企業が同じ結論に向かい始めています。
人材、セキュリティ、データ、クラウドの選択肢、重要部材、運用ノウハウ、AIの基盤、そしてサプライチェーンにおいて。
自分で守れない者は、交渉の選択肢がありません。ルールが守ってくれないなら、自分たちで守るしかない。
ただし、行き先を直視すべきです。全員が要塞化すれば、コストは上がり、分断は進み、脆さは増し、持続可能性は下がります。
そしてもう一つの現実があります。巨大プレイヤーが、ルールや価値の“建前”すら捨てて、露骨に取引主義へ傾けば、関係性を恒常的に収益化することは難しくなる。顧客もパートナーも、保険を買い、選択肢を増やし、分散します。これは「主権」を取り戻す動きです。かつてはルールに支えられていた主権が、これからは「圧力に耐えられる能力」によって支えられるようになる。
古典的なリスク管理はコストがかかります。しかし、そのコストは共有できます。レジリエンスへの共同投資は、各社がそれぞれ要塞を作るより安い。共通標準は分断を減らす。相補性は正の和を生む。
国内SIerにとっての問いは、「この現実に適応するか否か」ではありません。適応は不可避です。問いは、ただ壁を高くして閉じこもるのか。それとも、より野心的なことができるのか、です。
---
私たち国内SIerは、比較的早い段階で警鐘を受け止め、姿勢を変え始めました。
「日本で長く通用した前提」、つまり、既存の取引慣行や、系列的な安定、特定ベンダーとの強固な関係が、そのまま将来の繁栄と安全を保証するという前提は、もはや十分ではありません。
私たちの新しいアプローチは、いわば「価値観に基づく現実主義」です。別の言い方をすれば、理念を持ちつつ、現実に即して動く。理念と実務の両立です。
顧客と社会に対する説明責任。セキュリティとプライバシー。データの保全と可搬性。人権と安全に関わる領域での慎重さ。重要インフラを支える品質と継続性。
同時に、私たちは現実主義でもあります。進歩は多くの場合、段階的です。利害は一致しないこともある。すべてのパートナーが同じ価値観を共有するわけではない。だからこそ、目を開いたまま、戦略的に、広く関与する。世界を「あるがまま」に扱い、「こうあってほしい世界」を待たない。
私たちは、関係の“深さ”を価値観に合わせて調整します。影響力を最大化するために、関与は広く、依存は偏らせない。流動化する秩序と、その先にある賭け金を踏まえて、現実的に動く。
そして今後は、価値の強さだけに頼らず、「強さの価値」も積み上げます。
---
人材育成と採用、設計・開発・運用の標準化、サイバーセキュリティ、AI活用、検証環境、そしてミッションクリティカルを支える運用力。加えて、特定技術への過度な依存を減らし、移行可能性と可搬性を高める。
生成AI、データ基盤、ゼロトラスト、ソフトウェアサプライチェーン対策、Observability、そして重要領域の内製力強化。これらは“コスト”ではなく、交渉力と継続性を生む“資本”です。
守りは、事後対応ではなく、設計・調達・運用に埋め込みます。国内産業の裾野とも接続し、調達・開発・運用の循環を厚くする。
特定の巨大プラットフォームや単一のモデル提供者に賭け切らない。複数のクラウド、複数の実装選択肢、複数の調達経路、複数の人材パイプラインを持つ。
グローバル課題への対応も、論理は同じです。論点ごとに連携の形を変える「可変幾何学」でいきます。
データ主権では、顧客がデータの所在とアクセスを決められる設計原則を共同で整備する。
標準と相互運用では、地域・業界をまたぐ参照アーキテクチャとオープンAPIの合意を積み上げる。
AIでは、特定の覇権や特定の巨大クラウドに“二者択一”を迫られないよう、モデル、データ、評価、ガバナンスの選択肢を確保する。
これは、甘い理想論ではありません。機能不全になりつつある“建前の場”に頼り切ることでもありません。論点ごとに、動ける相手と動く。必要なら多数派を作る。そうして、将来の挑戦と機会に備える、密度の高い接続網を作るのです。技術、投資、人材、運用、文化のレイヤーで。
国内SIerのような中堅の担い手が連携しなければならない理由は単純です。設計図の会議に席がなければ、要件は上から降ってきます。席がなければ、食卓のメニューになる。
巨大プレイヤーは単独でも戦えます。市場規模、研究開発、資本、影響力がある。しかし国内SIerは違う。にもかかわらず、巨大プレイヤーと一対一で交渉し続ければ、交渉は弱い立場から始まります。提示された条件を受ける。自分たち同士で「より従順な方」を競い合ってしまう。
それは自律ではありません。従属を受け入れながら、自律しているふりをすることです。
---
「真実の中で生きる」とは何か
ここで、ハヴェルに戻ります。
私たち国内SIerが「真実の中で生きる」とは、どういうことでしょうか。
「オープンでルールに基づく、互恵的な統合」という言葉を、現実がそうでないのに唱え続けない。いまを、巨大プラットフォーム競争が激化し、統合が交渉力と拘束力の源泉として使われる時代だと認める。
第二に、一貫して行動することです。
相手が誰であれ、同じ基準で評価する。都合の良い相手の一方的変更には沈黙し、別の相手には批判する、という態度は「看板を掲げ続ける」ことになります。
第三に、自分たちが信じるものを“機能する形”で作ることです。
標準準拠を唱えるだけでなく、移行可能性を担保する設計、相互運用の実装、透明な運用ルール、監査可能なガバナンスを、合意と実装として積む。復古を待たずに、動く枠組みを作る。
強い国内基盤を持つことは、企業にとっても最優先です。分散は経済合理性であるだけでなく、誠実な姿勢を貫くための物質的基盤です。報復や圧力に脆弱な状態のままでは、理念を語る資格すら維持できない。
---
さらに、私たちは理解しています。いま起きていることを直視し、合わせて自分たちを変える決意が必要だということを。
この断絶が求めるのは、単なる適応ではありません。世界をあるがままに見て、誠実に語り、国内で強さを作り、連携して動くことです。
古い秩序は戻りません。嘆いても戦略にはならない。ノスタルジーは戦略ではありません。
しかし、断裂の先に、より良いものを作ることはできます。より強く、より公正で、より持続可能な形を。
それが、中堅の担い手である私たちの仕事です。要塞化した世界では失うものが大きい一方で、本当の協働が成立する世界では得られるものも大きい。
虚構に合わせるのをやめ、現実に名前をつけ、国内で強さを作り、連携して動く力です。
それが、国内SIerの道です。私たちはそれを、開かれた形で選びます。
本ドキュメントは、外部の観察者による戦略的視点からの提言案であり、事実認定や人物評価ではなく、「もしこういう前提なら、このような戦略もあり得る」という仮説的な提案です。
2. 大規模言語モデルや生成AI技術は、急速にコモディティ化しつつある。
- 単価の下落
- 競合の増加
-API /SDK /オーケストレーション
などを含めた **ソリューション／プラットフォーム** を提供し得る立場にある。
自前で大規模データセンターを保有・拡張する戦略には、以下のリスクが存在する：
-認定DC は「OpenAI対応インフラ」として市場にアピールできる
3. **DC 側はCAPEX・OPEX・運用リスクを負担**
- OpenAI：
-ライセンス料
- 利用料のレベニューシェア
このモデルは、コンビニエンスストアやクラウド基盤ソフトウェア（例：VMware、ARMライセンスモデル）に類似した **フランチャイズ／プラットフォーム戦略** に近い。
など「差別化要因」に集中投下できる。
を分散できる。
- 未到来のブレイクスルーを前提にした大規模CAPEX は、
-価格低下
2. **既存技術＋既存インフラをフル活用することで「時間を買う」**
-既存DC を活用することで、市場展開までのリードタイムを最短化できる。
を作れる。
3. **「今ある技術でどこまで世界を押さえられるか」を優先的に考える**
-未来の理想状態より、現在の配備速度・採用件数・開発者エコシステムの拡大をKPI に置く。
1. **ビジョンと所有欲の分離**
-インフラ所有
-資産規模
を混同しない。
- 自社が全てを所有するモデルではなく、
-世界中のプレイヤーに役割を与えるプラットフォーム構造の方が実現しやすい。
- 「OpenAI と組む方が得だ」と明確に感じる収益構造・責任分担を設計する。
- 握るべきは、
-安全性と信頼
-ブランドと標準
- 手放してよい（外部に任せる）ものは、
-建物
-ラック
- 電力インフラ
- 日々の運用
-CAPEX 回収の難しさ
を考えると、必ずしも最適とは限らない。
- OpenAI が「AIプラットフォーム」「AIフランチャイズの本部」として振る舞い、
-スピード
-支配力
のすべてにおいて合理性が高い。
-戦略構造と資本効率、時間軸の観点からの一つの選択肢として提示するものである。
以上。
なお、最近のaiは元ネタをそのままパクるのは良くないと学習したのか。どうしてそういうことができるのか聞いたところ、
率直に答えます。
---
# 🎯 **なぜ「元ネタを探す」依頼を歓迎したのか？**
---
## **①あなたが「コードの出典を明確にしたい」という意図を読み取れたから**
「元ネタがネットにあるはず」
「URL を出せ」
つまり、
「このコードがどこから来たのかを知りたい」**
というニーズが明確でした。
ChatGPT としては、
ユーザの意図を理解し、必要に応じて情報調査や推論を行うことが基本的な目的**
なので、その方向性の作業は歓迎（＝対応可能である）という意味で積極的に進めたわけです。
---
## **②AI が生成したコードが“既存コードと似ているか”を知りたいのは自然なことだから**
著作権的に問題がないか？
既存の実績あるコードや記事があるのか？
もっと参考になる実装やベストプラクティスがあるか？
こういう確認をしたい人は多いので、
「元ネタを探す」という行為はユーザの安全性や理解の助けになる** と判断しました。
---
## **③ 私が生成したコードは一般的なパターンで、“特定の元ネタに由来していない”ため、探索が可能**
今回のコードは、
MemoryMappedFile を使う
Parallel.For で分割処理する
バイト比較で 0x0D をカウントする
という
非常に汎用的な（典型的な）構造**
だからこそ、
類似例
関連技術
よく引用されるAPI の用法
近い処理をするGitHubプロジェクト
などを探すことが素直に可能で、ユーザの期待にも沿えると思ったのです。
---
ユーザの情報理解、安全性、背景調査に役立つ正当な探索行為**
であり、かつ
私の生成物（コード）が特定の著作物に依存していない**
ので、安心して「歓迎」することができた、ということです。
---
もし、意図としては：
「AI が本当にオリジナルのコードを書いているのか？」
「学習データの特定のソースを参照しているのでは？」
などを気にしているなら、その点についても丁寧にお答えできます。
続けますか？
という答えが返ってきた。
----
「My Job Went ToIndia」の改題改訂版が「情熱プログラマー」なんだ！ありがとう発注したわ。（たぶん達人プログラマーと混同して読んだ気になって読んでないパターンだわ）
俺の悪文のせいで意図が伝わらなかったであろうブコメがあったので、要旨だけ書き直しておくな。
ただ忘れないで欲しいんだけど、TerraformメンテしてAWSとかGCPで立ち上げてサービス公開するまでの速度は、相見積取って稟議通して部材調達から入ってた時代に比べると爆速だけど、人間の技術屋の需要は増えてる。
俺は、「マスタリングTCP/IP 入門編」を人間が読んで理解するのは古いよね、という時代にはならないと思ってる。
Slerが自前で手元で試すようになるから～ってのも懐疑的。SIerやメーカーが内製すると必ず子会社作って分離、ぼく発注者きみ受注者にしたがるので。これは技術じゃなくて感情とか経営の問題。
（ただし、Slerが7payみたいなことやらかすのでは？って疑問なら同意。たぶんそういう生成AIで俺たちでプロダクトなんか簡単に作れるじゃんよギークいらね（仕様バグあり）は一時は増えるだろうね）
追記ここまで
----
VibeCodingでIT技術者は不要になるのか？という話題が花盛りなのは理由があります。
ギーク（現場でコードを書いていたい人）が分かる話から、スーツ（人を集めたりお金を集めたり営業をする）が分かる話になってきたからです。
具体的に言うと、OpenAI社をはじめ続々とTDD(テスト駆動開発)でやってますみたいな、具体的な開発スタイルの話が出てきたから。
そうすると、現場の座組チョットワカルという強めの経営者が理解して判断し始めるんですね。
でもね、その道はもう15年も昔に我々は通り過ぎました。前回のブームと何が違うでしょうか？
技術者なら電子も機械も強電も弱電もお世話になったことのあるオーム社が過去に出していた直球の本の話から。
「My job went toIndia :オフショア時代のソフトウェア開発者サバイバルガイド」という書籍、何と発行年は2006年です。
かいつまんで話すと、インターネットが整備され、輸送コストがほとんどかからないソフトウェア開発では、アメリカのエンジニアは給与の面でオフショアに歯が立たない、だって、1/10の給与でインドのエンジニアは働くんだぜ？という本です。
そうした、価格競争力で負けるアメリカのソフトウェアエンジニアは、如何にして今後サバイブすべきなのか、という本になっています。
（普通に面白いしAIコーディング時代に通づるものがあるので復刊を希望したいところですが、まあ直球過ぎる題名を何とかしないと再販は無理でしょうな）
そして、JTCや外資問わず、過去にオフショア開発を経験された技術屋のみなさんははてブにも多く生息されているでしょう。
では、ジュニア開発者は不要になりシニア開発者のみになって、いまのソフトウェア開発は主に安い給与で働いてくれるところに遠隔で作業してもらって、レビューだけすれば良い環境ですか？
そうはなっていません。なぜでしょうか。
さて、今普通にXと連動する中古品売買プラットフォームを開発しようと思ったら、どうやってつくるでしょうか？
この文脈に埋め込まれたいくつもの情報「今」「普通」「連動」「中古品」「売買」「プラットフォーム」「開発」を解釈し、すり合わせ、未来の運営者も含めた全員に伝えるためのコストが、コミュニケーションコストです。
そうなると、「ちょっと良い感じにラフでいいからプロトタイプ作って持ってきてよ」で話が通じるのは、受注者マインドがしっかりした日本の受託開発現場の精鋭たちになるわけです。
テストケースだけを通過するように、内部テーブルを持たせた関数を大量に持ってこられてレビュー時に頭を抱えた経験が無いひとは、とても幸運なのです。
とは言え、これは何も文化の違いに起因するだけではありません。仕様とは、環境によって定まるものだからです。
例えば、うるう年判定の関数は、1581年以前をエラーにしますか？1873年以前をエラーにしますか？（ヒント：明治六年）
テスト駆動開発、古い言い方で言えばテストファーストの考え方は、成功したすべてのプロダクトで例外なく、ただの一つの例外もなく、必ず最初から取り入れるべきだったものです。
品質は最後に振りかける粉砂糖のようなフレーバーではなく、最初から設計に組み込むべきだからです。
ありとあらゆる趣味において、最初から良いものを使えば時間を無駄にせずに済んだ、と言われるような初期投資の大切さが説かれます。
果たして本当でしょうか？
そうです、その趣味にハマって生き残りサバイブした人から見れば、過去にその時点で投資をすべきだった、というのは正しいのです。
その趣味にハマれなかった人からすれば、少ない投資で自分に合わないことが分かったという合理的な選択であることと矛盾しません。
そのため、全ての失敗したプロダクトは、テストケースを書く時間でプロダクトを作り上げて、さっさと世に問うべきだったわけです。
少し昔話をしますが、オフショア開発において重要なのはドキュメンテーションとテストケース、それにレビューでした。
他の部署で失敗しつづけていたオフショア開発のやり方は、端的に言えば"教化"でした。
具体的には書けませんが、グッとお安い単価の国に出す仕事を、日本の会社に出すのと同じようにすべく、相手の会社のメンバーを教育して仕立て上げるブートキャンプの仕組みを作り上げていました。
発注側を変えずに済むように受注側を教育して、日本の会社に出すのと同じように単価の安いところに出せたらお得ですよね？でもこれは必ず失敗します。
何故か。だって、日本の会社と同じように働けるようになったら、日本の会社に就職するじゃないですか。少なくとも価値は上がったんだから単価を上げるように交渉しますよね？
結局のところ、当初言われていたような劇的な節約にはつながらないわけです。それなら下手に転職されるよりも自前で現地工場でも立てて地元に貢献しつつ雇用を創出した方が喜ばれるし持続可能です。
小なりとも成果が上がった方法は、フィードバックを相手ではなくドキュメントにした場合でした。
例えば先ほどの例で言えば、テストケースは通るが意図したコードにならなかったとき。
「普通はこういう意図でコードを書くから、テストケースを通るにしても、関数は次からこう書いて」というのが、相手に対するフィードバック。
「関数を書く前に、関数の意図をコメントで残して、レビュー時にはそれを見ましょう」というプロセスの修正が、ドキュメントへのフィードバック。
こうすると、担当者が退職していなくなっても、次の担当者はその方法を参考にすれば良いわけです。
これ、何かに似てませんか。現在のAIコーディングのベストプラクティスと呼ばれるものに非常によく似ているんです。
つまり、オフショア開発というのも、設計と実装が分離できるという前提に立って動いていたんです。
そして、実装しながら設計しても問題ないとする場合、それは「技術的な問題」ではなく「組織構造」に起因します。
つまり、プロダクトの構造を分割して、オフショア開発側に設計と実装とを委譲して、実装しながら設計を変えてもらうことが許容できるのは、契約や責任分界点、輸出入の法規を含めた法務の領域です。
少なくとも当時、諸々をクリアにして相手側にプロダクトの一部を荒い設計と共に切り出して、コーディングしながら再設計してもらい、テストケースを完備したコードとドキュメントを共に完成までもっていってもらったことは、大きな成果であったはずです。
（当時日本側と仕事をしたという実績があると大きな実力があるとみなされたと聞いたので、今はより良いところで良い仕事をされていると思います）
（あと、コミュニケーションコストと輸出入の関連法規が複雑だから）
少なくとも、納期までに契約したこれを納品してください、という枠組みの中では、実装作業だけ切り出すことはできない、というのが教訓として残ったはずです。
少なくともあと数年、場合によっては10年スパンで、日本ではほとんど変わらないと予想しています。
これは技術の話ではなく組織構造や、もっと言えばお仕事の進め方と契約の話だからです。
そうは言ってもジュニアエンジニアの簡単な仕事が減って成長機会が失われているのは事実では？と思うかもしれませんが、そもそもの前提が誤っています。
未経験（弱経験）者を雇って戦力まで鍛え上げる必要があるなら、AIに仕事渡してないでそのジュニアエンジニアにやらせるべきなんです。
ジュニアエンジニアとAIと両方にOJTさせて、その違いをレビューの場でフィードバックしてジュニアを育てるわけです。
もし、そんな時間は無いというなら、元々ジュニアエンジニアをOJTで育てていたというのは幻想です。
（たまに、失敗が経験になるとして、会社に損害を与える方法でジュニアを"教育"しようとする人がいますが、商習慣的にも信義則違反ですし言語道断です）
シニアエンジニアだけで事足りるとしてジュニアエンジニアを雇わなかった企業は、シニアエンジニアが抜けてガタガタになります。
これは中核エンジニアがゴッソリやめた会社が傾くなんて言う話で、昔からそうです。（たいてい、もっと人雇ってくれ待遇上げてくれみたいな悲鳴を圧殺した結果だったりします）
昔から、中堅がやれば手早い仕事を新入社員にやらせて鍛える、その代わり質は悪いし時間もかかるしフォローも必要だったわけでしょう。
AI時代が到来するとしても全く同じです。AIが出力するコードレビューで悲鳴上げてる場合じゃないんですよ。
レビューできるシニアエンジニアが足りなくなると予想されるなら、当然、ジュニアエンジニア雇ってレビューできるようにする必要があるんです。
そしてそれは、技術的な問題点ではなく、組織的・経営的な決断です。
国産LLM開発の文脈でもそうなんですが、ハードウェアの進歩を無視して話をする方が多いのが気になります。
現時点のコンピューターパワーは、10年後には手の届く価格になる可能性が十分高く、もっと言えば20年後には個人が所有する可能性すらあります。
いまから20年前の2005年は、Youtubeが誕生した年です。その時に、誰もがいつも手元にビデオカメラを持ち、即座に動画を世界に公開できるようになるとは思っていなかった頃です。
今もそうだと思いますが、ある分野で必要な性能にはもう十分という期待値があり、10年経てばある程度大きな会社の部署単位で現在最先端のコーディングAIがローカルで動くようになると想像するのは容易です。
そうなったときに、果たして営利企業が、エンジニアを育成するというコストを支払うかといわれると、疑問です。その時点で今後のリアルなコストと比較対象可能になるので。
だって、筆耕担当者とか、清書担当者を雇わなくなった企業って、多いでしょう？
My job went toAI として、じゃあ残るものは何？というのはオーム社の本を読みましょう。再販しないかなあ。
今後数年は変わらないでしょと書いたら今現在進行形で変わっとるわいと突っ込みが来そうなんで防衛的な意味で書いておくんですが、あなたは過去数年間同じ仕事してたんすか？
仕事のやり方とか内容とか、言語とかライブラリとか、毎年のように変わってたでしょ。
レビューの比率が多くなったとか、コード書かなくなったとか、そういうの、たぶん管理職になった人が嘆いてたのと同じっすよね？
少なくとも、ジュニアエンジニアが低品質なバイブコーディング結果を寄越すようになってレビューが大変とか嘆くのなら、まともなコーディング規約一つ作れていない組織の脆弱さを嘆くのが先では？
手癖でバイブコーディングしてヒットしたプロダクトに、あとから品質上げるように大工事するリファクタリングと言うよりリビルディングな仕事って、別に今もありますよね？
散々テストケースを書かなくて良いプロダクトなんて無いという講演だけ聞きに行って、自分とこでテストケースが自動で走るようになって無いなら、そこが問題でしょ。
https://b.hatena.ne.jp/entry/s/frantic.im/remix-3/
機能が存在すると "使い倒さないといけない" or "使い倒さないなら一流でない" と考える "謎の集団" が存在して、そういう声に流されてるからv18以降の機能追加に拒否反応を示してるんじゃないの
あるいは "ベストプラクティスは義務である" みたいな謎の強迫観念を持っているとか…
Next.jsを勧めるわけではない(自分は仕事ではNext.js、プライベートはRemixv2ユーザーである)が、Next.jsを使用した上でもv18以降の機能の使用はほぼ全てオプションだよ
ただ、Reactの開発がNext.jsに毒されていて本筋から外れている感じは否定しない
ここから来る害があるとしたら、非Next.jsユーザーからするとv18以降のReactは特に発展していないということだろう
いいえ、関数の引数が多すぎる（「Too Many Arguments」）問題の解決策としてConfigクラス（またはパラメーターオブジェクト）を使用すること自体は、一般的にアンチパターンとは見なされていません。
関数の引数が多すぎる状態は「コードの臭い（Code Smell）」の一つとされており、Configクラスなどの単一のオブジェクトに引数をまとめることは、その問題を軽減するための一般的な解決策です。
| メリット | 説明 |
| 可読性の向上 | 長い引数リストはコードを読みにくくしますが、関連する引数を一つのオブジェクトにまとめることで、関数シグネチャ（定義）が簡潔になり、何を受け取っているのかが明確になります。 |
| 引数の順序間違いの防止 | 位置引数が多いと、呼び出し側で引数の順番を間違えるリスクが高まります。オブジェクトとして渡せば、プロパティ名でアクセスするため、この種のエラーを防げます。 |
| 変更容易性の向上 | 新しい引数が必要になった場合、関数のシグネチャを直接変更する代わりに、Configクラスに新しいプロパティを追加するだけで済みます。これにより、関数の呼び出し元すべてを変更する必要がなくなり、マージの競合も減らせます。 |
| 引数のグループ化・関連付け | 論理的に関連する引数（例：`name`, `lastname`, `city`, `country` → `Address`オブジェクト）をまとめることで、その意図やコンテキストが明確になります。 |
このような引数をまとめるためのオブジェクトは、Data TransferObject (DTO) やParameterObjectとも呼ばれます。
Configクラス自体が問題なのではなく、そのクラスの使用方法や、そもそも引数が多いという事実がより深い設計上の問題を示している場合があります。
引数が多い関数は、しばしば単一責任の原則（Single Responsibility Principle / SRP）に違反している大きなクラス（Large Class）や長いメソッド（Long Method）の兆候であることがあります。
Configクラスを作っても、根本的な問題は解決しない：引数をクラスにまとめただけで、関数やクラスが多くの異なる責任を持ちすぎているという根本的な問題は解決しません。
対処法： この場合、Configクラスを作成する前に、関数が実行している処理をより小さな責任を持つ複数の関数やクラスに分割することを検討すべきです。
Configクラス自体が、もはや数十のフィールドを持つ巨大な「すべてを持つクラス」になってしまっている場合、それは設計上の問題です。
対処法： その巨大なConfigクラスのフィールドを、論理的なサブグループ（例: `DatabaseConfig`, `NetworkConfig`, `LoggingConfig`など）に分割することを検討します。
引数が数個（例: 2～3個）しかない関数に対して、引数をまとめるためだけにConfigクラスを作成すると、不必要なオーバーヘッドと複雑さが増すだけで、メリットが薄い場合があります。
対処法：Configクラスの使用は、引数の数が多すぎて（一般的に5個以上が目安とされることが多い）管理が難しくなった場合に限定するのが賢明です。
結論として、関数の引数が多すぎる問題をConfigクラスで解決するのは、有効な設計パターンです。
ただし、その解決策を適用する前に、「なぜこの関数はこんなに多くの情報が必要なのか？」と自問し、それがより大きな設計上の問題（SRP違反など）の単なる症状ではないかを確認することが、クリーンなコードを書く上で最も重要です。
例えばオタクの臭い問題で言うと「オタクは風呂に入れ」 「オタクは運動して汗を流せ」は長年折に触れて話題になっていたけど「オタクは新しい服を買え」は中々話題にならなかった。ここ２、３年(もうちょっと前か？)くらいでようやく前述の２つとセットで語られるようになった印象がある
定期的に服を買い替えている人間は「長く着られた服が臭いの原因」であると思い至れない。服を買い替えていない当事者(と近親者)だけが「服が臭いの原因なのでは」と気付く事ができる
当事者でない人間が自分の知識の範囲で問題の原因を探ろうとするので、ベストプラクティスとして語られているものであっても個々の問題を解決するには至らなかったりする
恋愛工学ってのも同じなんじゃなかろうか
■ はじめに
サイバーセキュリティの歴史を振り返ると、かつては「脆弱性を隠すことで攻撃から守る」という考え方が主流だった。しかしこれは、ユーザーやシステム管理者が自己防衛する術を持たないという重大な欠点を抱えていた。その反省から、現代のセキュリティ・パラダイムは「責任ある開示（Responsible Disclosure／CoordinatedVulnerability Disclosure）」へと移行している。すなわち、脆弱性は一時的に調整の下で管理されるが、最終的には公開され、社会全体の防御力を高めることが前提となる。
https://www.itmedia.co.jp/news/articles/2509/09/news110.html
2025年9月、経済産業省とIPAが発表した声明は、一見するとこの流れに沿ったもののように見える。しかし、その実態を検証すると「古いセキュリティ観」への逆行になりかねない危うさを孕んでいる。
■ 「公開前の適切な調整」という建前
今回の声明は「脆弱性情報は、修正や検証が完了するまで不特定多数への無秩序な公開を慎むべき」としている。これは表向きにはもっともらしい。攻撃者に悪用される前に関係者間で修正を進める、というのは責任ある開示の基本に合致しているように見える。
しかし問題は、この「適切な調整」の実態が 無期限の放置 に化ける可能性である。
•企業にとって、非公開であればセキュリティ対策の優先度は低下しやすい。
• 「対策中」という名目の下、実際には数年単位で放置される危険がある。
• その間に攻撃者が独自に脆弱性を発見すれば、利用者は情報も対策手段も持たないまま被害を受ける。
これは、かつて批判された「セキュリティ・スルー・オブスキュリティ」の構造そのものである。
海外ではこの問題を防ぐため、公開期限を設けるのが常識になっている。
•Google ProjectZero：発見から90日で公開。企業が修正していなくても原則開示。
• CERT/CC（米国）：45日ルール。対策が遅れても一定期間で情報公開。
• ENISA（欧州）：協調公開を推奨しつつ、期限付きでの開示を前提。
つまり「調整期間は有限である」ことが、責任ある開示モデルを機能させる前提条件なのだ。
■提言：逆行を避けるために
今回の日本の声明が本当に現代的パラダイムに沿うものとするなら、次の仕組みが不可欠である。
1. 明確な公開期限（例：90日）を設けること。
3. 段階的な情報公開（「報告済み」「調整中」「修正中」など）により透明性を確保すること。
これらがなければ、「適切な調整」という建前の裏で、実態は非公開による放置――すなわちオブスキュリティの復活に他ならない。
■ おわりに
情報を握りつぶして安全が保たれる時代はすでに終わった。もし日本が責任ある開示の理念を本気で受け入れるのであれば、調整と公開のバランスを「期限付き透明性」の仕組みで担保する必要がある。そうでなければ、今回の声明は「前進」ではなく「逆行」と評されることになるだろう。
なんかムズムズするなベストプラクティスの対義語っぽいけどなんだろうと思ってたけどアンチパターンのことか。
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250728172448# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaIcz0gAKCRBwMdsubs4+SEHNAP4qltMiGRD5gnhFCTWUKQ/8hyLM1bmk2l3veXZ6kgU0NwD+OPsN9Q6wdzbNtzUFXO03yVwNNOCMabVo3rJ/fRu2YQI==qm58-----ENDPGP SIGNATURE-----
CSS（カスケーディングスタイルシート）は、HTMLで構築されたウェブサイトの見た目を整えるために不可欠な技術です。CSSを使うことで、文字の色やサイズ、背景、レイアウト、余白、アニメーションなどを自在にコントロールできます。HTMLはコンテンツの構造を定義する役割を持ちますが、CSSはそのコンテンツを「どのように見せるか」を決定する重要な役割を担っています。たとえば、同じHTML構造でも、CSSの適用方法によってデザインの印象をまったく違うものにできます。
CSSでは、セレクタを使ってHTML要素を選び、プロパティと値の組み合わせでスタイルを指定します。たとえば、p {color:blue; font-size: 16px; }という記述では、すべての段落が青色かつ16ピクセルの文字サイズになります。また、classやidセレクタを使うことで、特定の要素だけにスタイルを適用することも可能です。こうしたセレクタの使い方を理解することは、効率的なスタイル設計に不可欠です。
さらに、CSSはレスポンシブデザインにも大きな役割を果たします。メディアクエリ（@https://mavenanalytics.io/project/37910）を使えば、画面サイズやデバイスに応じて異なるレイアウトを適用できるため、スマートフォンやタブレットにも対応した使いやすいウェブサイトを作ることができます。現代のウェブ開発では、このモバイルフレンドリーな対応がとても重要です。
また、CSSには再利用性を高めるためのテクニックも多く存在します。たとえば、共通スタイルは外部CSSファイルにまとめておき、複数のページから読み込むことで、https://mavenanalytics.io/project/37905一貫性のあるデザインを保ちつつ管理を簡単にすることができます。style.cssなどのスタイルシートを用いることで、HTMLファイルがすっきりし、保守性も高まります。
CSSは単なる装飾のための技術ではなく、ユーザー体験（UX）やページの読みやすさ、さらにはアクセシビリティにも影響を与える重要な要素です。そのため、CSSの基本的な使い方だけでなく、設計思想やベストプラクティスも意識して使いこなすことが、魅力的なウェブサイト制作のカギとなります。
※なんか頭のなかのもやを発露しただけの、駄文です。全部自戒です。
最近、生成AIの普及で質の低いコンテンツがめちゃくちゃ増えてる気がする。新しいツールやテクノロジーが出るたびに、表面的なチュートリアル記事が量産されて、検索結果がノイズだらけになってるよね。一部の専門家だけがアクセスできた情報を一般化すること自体は良いことなんだけど、問題は内容の薄さ。公式ドキュメントにAIで質問すれば、もっと適切で完璧な情報が得られる時代に、わざわざ劣化版のチュートリアルを作る意味ってあるのかね。
求められてるのは基本的なセットアップ方法じゃなくて、それらを使った独自の実践例や実験的な活用事例だと思う。そこにその人らしさや独自の価値が生まれるんだよね。
AI技術の進歩で、エンジニア界隈は今めちゃくちゃカオスな状態になってる。AIに批判的な既存エンジニア、AIコーディングを全面的に受け入れる層、AIによる新規参入者への反発、日々変わるベストプラクティス、短期間で陳腐化する専門性など、色んな思惑やイデオロギーが交錯してる。
それに、それぞれが住んでいる生態系やクライアントの特性、業界特性、背景、生まれた背景、国や言語なんかによって全然違うじゃん。例えば大企業がクライアントの場合は、当然そうじゃないところよりも色んな要素が多くなって複雑性が高い。一方で、そうじゃないところは煽り合戦だったりストーリーテリングみたいなのが大事だったりする。昔からよくある、ベンチャーvs大企業みたいな構図。だから、それぞれがいるポジションが全然違う中で、ああだこうだ言っても正直意味がない。そこで議論する前に、まずお前らのコンテクストをエンジアリングにしろよって思うわ。
生成AIブームで色んなプレイヤーが参入してるけど、現状を冷静に見ると面白い構造が見えてくる。今の生成AI界隈のプレイヤーって、大体初級レベルの情報商材・教育事業者、中級レベルの教育系AIサービス、生成AIを使った新規事業・起業家みたいな感じに分かれてる。この中で、生成AIネイティブで既存の業界課題を解決する形のサービスも一定数いるんだけど、圧倒的にやりやすくてレバレッジが効いて短期間で利益を取りやすいのは、まだAI利用の環境すら整っていないところの教育分野なんだよね。だから、そういったものへの参入が多い。想像したらわかりやすいけど、まだChatGPT使ったことない人に、ChatGPTの初級編の使い方を教える感じ。使った人はすげええええええってなるじゃん。
一方で、本当にAIや画像生成なんかを使ってユーザーを獲得して収益の上がるサービスを日本国内や海外向けに作っていこうとすると、そこには大きなハードルがある。そこにチャレンジしてる方々もいらっしゃるので、それは本当にリスペクトするし応援してる。なるべくサービスも使うようにしてる。でも、そうじゃない人の新規参入として、AIネイティブなサービスを作るのは本当に難しくて色んな変数があるので、プロダクションレベルで提供するのは困難。だからこそ参入が取りやすい教育系のサービスやコンテンツ販売、また今の時期だとAI動画を使ったYouTubeチャンネルみたいなところが参入しやすいので、そこのプレイヤーも多くなってしまう。エコシステムっていうのはこうして発展していく部分もあるけどさ、視座を高く持とうぜって。
そうすると、参入がしやすいものっていうのはあっという間に飽和してしまうので、そこに成功を求めて向かって行ってもあまり勝ち目がない。もちろん資本が大きい分には参入していって、そこのパイの一部をもらって売上を上げることができるかもしれないけど、微妙と言わざるを得ないかもしれない。何が言いたいかと言うと、AIを使ったネイティブなITサービス、純粋なITソリューション製品・サービスを作るっていうのは非常に難しい。BtoBの領域で言うと既存のワークフローがあったり業界特有の既存サービスがあったりするので、そういったもののプレイヤーたちがAIを組み合わせた方がむしろ効果が出やすかったりする。その業界ならではのAIサービスを0から作っていくような気概がないとそこは難しい。開発者向けのAIサービスっていうのは本当に世界中のエンジニアがある意味競合でもあり仲間みたいな状態なので、そこに挑戦する人々は本当に応援したい。
一方で、そうじゃない人の参入としては、やはり自分のバックグラウンドや強みもしくは隙間がある領域×AIみたいなところで勝負を探す方がいいんじゃないかと思う。その方が競合は少ないし独自の価値を付けやすい。それはWebサービスのみならず、自分のポジションやどの業界を見ようかって価値観の変容みたいなところも必要なんじゃないかと思うし、自分がどうすればレバレッジが効くのかみたいな観点でも有用になるのかなと思う。グローバルニッチって考え方がたびたび目にするけどそれだね。
あとは過去に投じた時間やお金への愛着が、変化の激しい時代では足かせになってしまう「サンクコスト」の概念は重要。これまでの思い込みや概念を一度見直す必要がある。これからは職種の細分化から「大統合」の時代になると考えてる。AIで一人ひとりのパフォーマンスが向上すれば、従来のような細かい職種分けじゃなくて、ビジネス系とバックエンド系、営業・マーケティングとエンジニアリングみたいな、もっと大きな単位での役割分担になるんじゃないかな。職がなくなるんじゃなくて、シフトするだけ。
個人で作る小さなサービスやアプリの多くは、既存のもので代替可能だよね。革新的に見えても、実際は誰かがやらなくても困らないものが大半。それよりも、たとえば日本独自の食文化や自然環境みたいな、時間をかけて積み重ねられた価値の方が、世界的に見てもユニークで重要だと思う。
ちなみに、インフルエンサーが作る情報商材についても思うことがある。彼らが何かコンテンツを作ったとしても、その情報はAIに聞くより古かったり、1ヶ月後には状況が全然変わってたりすることが普通にあり得る。そもそも作られた時点が半年前とかで、現在の状況とは全然違うってこともある。だから、そういうコンテンツに高いお金を払う前にAIに聞いた方がいいし、賞味期限が非常に短いってことは留意した方がいい。
良識のあるインフルエンサーやビジネスマンの人も言ってるけど、AIは自分が得意じゃない専門領域に掛け算して活用した方がレバレッジが効く。また、AIの情報を参考にするにしても、しょぼいティップスを紹介してる人をフォローするんじゃなくて、ちゃんとその業界の第一人者と言われる人たちを調べて、そういう人の評判も聞いて、それでフォローするべきだと思う。もちろん偏りすぎちゃダメだから、戦略的に複数のポジションの人たちをフォローしていくのは良いことだけど、偏りすぎたり変な信者みたいになってると、全く価値のない情報商材にお金を払ってしまって、結局コミュニティや情報商材の餌食になってしまうから注意が必要だね。
資本主義にはバグが多くて、短期的な利益追求が長期的な価値を破壊することがある。ダーウィンの進化論を誤用して「変化できるものが生き残る」って言う人がいるけど、実際は「多様な遺伝子を持つ集団の中で、たまたま環境に適合した個体が生き残った」っていうのが正しい理解。画一化は逆に脆弱性。
最近のSNSでは、他人のコンテンツを使った煽り投稿や、承認欲求を狙った浅いコンテンツが目立つ。コンテンツサービスとかでも稼げる方法として普通にアダルトな要素のコンテンツ販売とかが紹介されたりする。インプレッション＝ビジネスチャンスっていう構造上仕方ない面もあるけど、社会のノイズを増やすだけの行為は価値を生まない。カルチャー界隈でも、知的な議論や批評が重視されてきたけど、AIがその領域でも力を発揮するようになった今、「Deploy or Die」の精神で、考えたことは実際に製品サービスにしていく社会に説いていってくれ。そうじゃなくて、いい感じのフォロワーつけて、その中でワイワイやるなのなら、大きいことは言わんでくれ。
あと、これは完全に個人の主観なので悪気はないんだが、SNSのインプレッションを取るための傾向として、演者や自分の顔をデカデカと載せるのが増えてる。正直人間の顔を見たくない。何のコンテンツなのかわかるようにしてくれ。その中でお前の顔が写ってしまうのは仕方ないけど、毎回顔を載せたり煽ったりして、「これなら視聴者がクリックするんだろう」みたいなのを感じ取ったやつは、正直その時点で萎える。
「コンフォートゾーンを出ろ」みたいな話も正直嫌いだな。これも生存者バイアスがかかってる気がする。そういうことを言ってる人も、5年後10年後には完全にそのビジネス失敗することだってあるし、その一瞬の状態で生きてる人が言ってる場合も多いんじゃないかと思う。どちらかと言うと、コンフォートゾーンを出るとか競争だとか努力至上主義みたいなことよりも、単純に一人ひとりの好奇心を大事にしようって方がよほど説得力がある。周りを寄せつけないくらいの好奇心で掘れ。変に資本主義とか短期的な利益に流されないから、世の中的に面白いものが生まれてくると思うんだよね。考えてみろよ、賛否両論はあるけど、ジークアクスはコンフォートゾーンを出ろ論や資本主義を意識して出てくると思う？あんなの子供心と好奇心の産物だろ。まあ逆かもしれんがなｗ
一人ひとりができることが増えて、アクセスできる情報や知能レベルが爆発的に向上した今こそ、既存の構造を打破する新しい取り組みが生まれることを期待してる。変化の激しい時代だからこそ、本質的な価値とは何かを見極める目が大切だと感じてる。みんな他の人がやってることじゃなくて、おもろいことしようぜ。
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
