  |
はてなキーワード: dddとは
運用開始までのことしか考えないで、その後のことを考えないのは、日本人に強い員数主義の発露かな？
故障やなんか考えたら、保守部品のロジスティクスくらい、提供前に当然のように準備しとけよ。
とにかく納品日までに頭数(機能)だけ揃えろ。
ってSIer仕草しか知らんプロマネ、エンジニアが大量にWebサービス界隈に流入してきて、大規模うんこ製造機と化してるから、システム界隈でもむちゃくちゃ迷惑してる。
SIerあがりと言うか、崩れというか、のプロマネは、99%、
「今回のプロジェクト、DDD(ドメイン駆動開発)採用していますので、よろしくお願いします」
っていうのと同じ口で、
「この画面、帳票以外の余計なことは考えないでください。やらないでください。Fixした基本設計を変更しないでください」
って頭おかしいことを平気で言う。
DDDは画面帳票駆動開発に対するアンチテーゼなんだが、なぜ画面帳票ベースのSUDOモデリングとか言うケッタイな手法を、鼻をおっ広げてドヤ顔で推進、実施しとるんだ？
せません！
って思うわ。
20年ほど前に業界に入って、OJT受けたおっさんにOJT受けたエンジニアか？ w
ソフトウェアエンジニアリングは、しきたりを1ミリも変えたらいかん伝統芸能ちゃうねんぞ！
E2Eテストなんて、今時のWebサービスの規模、複雑度っていう圧倒的物理量に追いつけるわけがないんだよ。
屁の突っ張りにもならないどころか、
爆上げさせてる
いや、そもそもE2Eテストとセキュリティリスク、なんの関係があるんや？ って問題はあるんやけど w
本来そんな機能がないのにあると勘違いして使うことの危険っての、教えてもらわんとわからんか？
って、安全帯のフックを自分のベルトにかけて、送電線の点検ができるか？
安全帯自体の機能として落下防止が当然あるけど、「正しく使わないと正しく機能しない」し、そもそもそれ、体重を支えられるのか？ それ以前に安全帯か？ ただの100円ショップで売ってたキーホルダーちゃうか？ って問題なんよ。
安全帯でも負荷を支えられなきゃ意味ないし、物が違えば、キーホルダーはキーホルダーだし、安全帯は安全帯なんだよ？
Web記事とかの「単語」だけ相手にするから、こういう致命的な間違いをガンガン積み上げて、炎上現場、高粘性現場にレベルアップさせるんだよ。
DDD、TDD、クリーンアーキテクチャ、マイクロサービス、DevOps。
本人達は真面目に輸送機から「素晴らしいもの」を得るための手順を踏んでるという認識しかなく、おかしなことをしてる自覚が皆無っての、そのままだって気づけ。
理解してるなら、その目的がちゃんと達成できてるか、確認してるか？
ちゃんと適用されたまともな現場を知らんで、「こんなもんでしょ」で満足してるの、頭おかしいぞ。
猿か？
数年前、年収900万超でシステム開発のマネジメント職に転職した。前職も同じくらいの年収だったんだけど、そもそもあれがバグってた。今になって振り返ると、完全に身の丈に合わない転職をしてしまったと後悔している。
前職の入社時の年収は350万くらいだった。オーナー企業の少人数の会社。上司も部下も顧客もそこまでITに詳しくなくて、ハッタリかませばだいたいなんとかなる環境だった。
もともとITをよく分かっていない人の話を聞いて整理するのは得意だったので、エンジニアからPMになり役職がついた。気づけば年収は入社時の2.5倍以上になっていた。
モダンな開発はなんとなく齧ってた程度で、基本はハッタリマネジメントでなんとかなった。作ってたシステム自体もそんな複雑なものでもなかったし。
経営陣がいろいろやりたがる人たちだったので、広く浅くなんでもやってみたい自分には性が合っていた。ただ、いろいろあって辞めることにした。
転職活動を始めた時に出会ったのが「錯覚資産」という考え方。ふろむださんの『人生は、運よりも実力よりも「勘違いさせる力」で決まっている』で知った。
前職で900万近い年収だったので、ハロー効果が効いて年収を維持したまま転職できた。LLMのように相手に合わせてこういう言葉を紡げば相手は納得してくれるだろうという能力には長けていたので、面接はハッタリでなんとかなった。
実務で足りないところは、ハロー効果が効いているうちに実力をつければ何とかなるだろうと思っていた。甘かった。
現職は前職と違って、成長企業といえどちゃんとした会社。オーナー企業的な空気もなければ行き当たりばったりでもない堅実なところだった。
そして何より、バリバリモダン開発の会社だった。SREだDevOpsだDDDだスクラムだなんだかんだと、今までとの落差が激しすぎる。
上司も同僚も部下もシステム開発をよく分かっている。システムがわからんという人のために色々整理してあげるという、自分のコア能力が全く発揮できない。
伸び悩んでいる部下へも適切な指導ができない。前職まではシステムよく分かっていない顧客と上司に納得してもらえばなんとかなったので、部下は育てなくてもなんとかなっていた。困ったときは外注を入れて凌いでいたし。
もう、上司・同僚・部下からなんとなく腫れ物扱いになっている。年収も年収なので会社に対して申し訳ない気持ちになってきた。会社も余裕があるわけではないし。自分が無能だということがなんとなくわかり始めてツラポヨ。
なんかエンジニアリング自体に自分が興味なかったんだなぁということを実感した。
なんだろう、もともとウェブ屋に毛が生えたみたいなシステムなんでも屋おじさんだったので、バリバリエンジニアリングの専門集団に入ってしまい違和感が半端ない。
俺はウェブというメディアに興味があるのであって、エンジニアリングそのものには興味がないのだ。ということに今さらながら気づいた。
昔のワールドワイドウェッブはねぇ、なんというか、自由というか個人が自宅の机の上から世界中に情報を発信できるという夢に溢れていたのだよ。なんだね今のウェブは。ただのシステムが乗っかるための土台でしかない。面白くなくなったねぇ。Flashとかの標準なんかクソくらえな「リッチコンテンツ」が溢れていたときはなんかカオスな楽しさがまだウェブにあったが、もうなんかビジネスしか残ってないのはなんなのかね。どこに行っちゃったのかね。
閑話休題。
錯覚資産はコンフォートゾーンから一つ抜けたストレッチゾーンに行くために使うべきだった。自分の場合は一歩超えてパニックゾーンに行ってしまった。
最初は周りも良い人だらけだったので、持ち前のハッタリでなんとなくやり過ごせた。でも数年経つと化けの皮は剥がれる。
あと、ハッタリかますのに全力を使いすぎて余裕がなく、力をつける時間を作れなかったのが敗因だと思う。
まぁまた転職すれば現職の錯覚資産のハロー効果でなんとかなると思う。年齢的にだいぶ中年なので不安もあるが、ストレッチゾーンに当たりそうな会社にどうにか転職したい。年収は下がりそうだけど。
もしくは開き直って居座るか。でもこの精神状態で居座り続けるのもキツい。
錯覚資産を使う場合は十分気をつけてください。背伸びしすぎると、自分も周りも不幸になります。
そして何より、自分が本当に何に興味があるのか見極めてから使いましょう。年収やポジションに目が眩んで、自分の適性を見誤ると地獄を見ます。
手間が増えて、全然楽になってないのなら、それは正しく理解できていず、目的を見失い、手段を目的としているから。
速い話が、
間違えている
からだ。
DDDとかTDDとかDevOpsとかIaCとかクリーンアーキテクチャとかマイクロサービスとかアジャイルとか、とか、とか。
いろんな現場で、責任者は「うちは××を採用して云々」と胸を張って宣言してくれるんだが、「ならなんでそんな状態になってんの？」「なんでそんなにエンジニアがたくさん必要なん？」と聞きたくなる。
今時、SREがいるとか、QAが別にいてE2Eテストとかしてるとか。
まず間違いなく、
間違えている。
んだよね。
TDDをちゃんとしていれば専属QAは不要だし、DevOpsをちゃんとしていれば専属SREは不要。
いやでも「Googleならそうしている」っていうなら、大きな勘違いをしている点を指摘してあげよう。
「君たちはベアメタルサーバを管理していないし、Lanケーブルの取り回しもしていない。GoogleのSREエンジニアが頑張って運用してくれているシステムに乗っかって、アプリケーションに集中できる状態になっているはずだ」
ということ。
「品質管理が僕たちの責務です」
って、最近エンジニアリング界のライザップ的元テスト専門会社のQAエンジニアが、昔、言ってたなぁ……、と。
思い上がるなっ！
君たち如きに背負えるものでは、すでにない。
とあえて言おう。
いや、マジで、無理なんよ、もう。
例えば、キッチキチにエレベータを作り込んだとして、後から点検してくれ、と言われたら、まぁ、普通は困るよな。
モーター室がモーターが入るギリギリの広さだとしたら、箱の外に出る手段がなったら。
どうやって点検するんだよ。
実際には、設計時に点検方法を決定して、それができる余地を確保してから、施工するものだろう。
今時のEV車なんて、テスト用の仕組みがきっちりと、製品に組み込まれている。
検証不可能とまで言わなくても、検証困難な場合はちゃんと対策をとるもんです。
作りきってから、「E2Eテストお願いねー」とQAチームに投げるものじゃあないんですよ。
設計時に、テスト戦略から何から何まで検討済みになってるもんなんです。
別にユニットテスト書いて、カバレッジあげるのがTDDというわけではない。
検証可能なシステムを設計実装し、リリースのたびにシステムの健全性を検証できる仕組みを整える。
ってのが「テスト駆動開発」なんですわ。
テスト戦略をちゃんと練れば、マイクロサービスの分割の仕方、連携の仕方等々、多分、今、Web上でよく見る記事とはだいぶ様相が異なってくるはずだ。
で、プロダクトの中身である、設計や実装を理解できなければ、検証のしようがないのがここ10年ほどだ。
金槌を渡されて、「品質検査しろ」と言われたら、まだ何とかなるだろう。
けどボーイング787をポンと渡されて、「品質検査しろ」と言われたら？
マニュアルなしで。
モジュールがどう組み合わされてるか等、中身を理解できなければ、何をどうしていいかも分からんだろう？
扉の開け閉めができるとか、主電源入れたらなんか部屋の明かりがつくとか、そういう表面的な検査しかできないだろ？
これは、QAが、設計に飲み込まれることを意味する(10年以上前に、↑のQAエンジニアとした話)。
QAのテストに関する知見を、設計実装するエンジニアは当然持っておかなければならないということとともに、QAエンジニアは消えてなくなるということでもある。
お分かりだろうか？
同じ流れで、SREも不要になる。
Infrastructure as Code は設計実装エンジニアのためのものだと言っておこう。
決して、Terraformのファイルを編集して、SREの許可を、延々と待ち続けて、適応してもらうことをいうわけではない。
そこまで込みで、設計するのだ。
高負荷時にどうスケールさせるかなども、当然設計に入ってくるからな。
ってなわけで、ほとんどの現場では、そういう致命的な誤認識をしていると思う。
認識が古すぎている上に、大型化複雑化した現状を認識できていない。
開発初期はまだ規模が膨らんでいないから、何とかなりそうな勘違いを犯しているだけの話だ。
初回リリース前後で、「あ、やばい……」となっているところがあまりに多すぎる。
また、この誤認識によって、役に立たないエンジニアの頭数だけを並べて札束を燃やし、事業の拡大の足を引っ張っていると指摘しておこう。
ここら、どげんかせにゃならんのよな。
職業プログラマになって分かったことは、職業倫理なんてものは "人が死なない限り存在しない" というものだ。
僕らを取り巻くテーゼは、 "プログラムを事前に設計して考えて書くのはバカだ" というもの。
これは、インターネット環境で修正が用意になった結果として、「その場しのぎをすればいい」という場当たり的主義が起きた。
結局のところ、そんな対応をコンシューマも許容せざる得ないのだ。そんなテーマで書いてみる。
アジャイルだとかXPという方法論の理想は認めるし、とても共感する。顧客がソフトウェア開発のプロなら成り立つだろう。
だが、実際の運用はどうだろう。顧客に未完成品を準委任で売りつけて、保守で金をせびる方便になってしまった。
XP という主張も、アジャイルという運動も、未完成品を売りつけるための手法として使われている。
いざとなったら、可能な限り修正はしますよ、という触れ込みで。僕らが頑張ってこれだったんですといえば、故意ではないのだ。
だったら、自分たちのレベルを低くした方が、免責される幅も広がるし、安く人を調達できるし、うれしいことだらけ。わらっちゃうぜ。
TDDという手法がもてはやされたりするのも、やったもん勝ちみたいな精神性があるからなのだ。
そもそもの問題として、本当のテストの設計をするには、プログラムがどのような動作をすべきか考えなくてはならない。
V&Vの妥当性確認をするには、そもそも何をしたいかわかってなくてはならないし、そのためには、上流の設計は必要だ。
そのことを考えるに、TDD を設計しつつ行うことは、上流から下流までの見識を持って行わないといけないはずだ。
しかし、テストファーストといってる人たちは、このことを矮小化して、あらかじめ自分のわかってる範囲でテストを書いておけば問題ないと言っている。
現場で始めるTDDなんていうのは、そんなもんで、そういう場当たり的なことをを持てはやしているわけで、知れたもんだよね。
こいつらバカじゃねーのか、テスト書いてれば、見当違いのことしてもいいって言ってんのかよ、って思うわけだわな。
でも、何やっても、やってよかったと心底思える人達ばかりで、住む世界がちがうわけで。かなりお花畑な人達ばかりなのよ。残念なことに。
そもそもドメインモデリングなんて、いくらでも昔に提唱されていたのに、DDDに含めるのが間違ってるのだ。
そもそも、DDDの本はドメインモデリングについて、あまり語ってないし...。
どうせ、ユースケース層というものをドメインに入れて四苦八苦してるような輩には、なんもわかるまい。
ドメインとドメインがどう使われるかは、そもそも関係にないし、関係あったら問題だろう。
でも、ユースケースをドメイン内に表現したいとかいうのが後を立たないのは、なんもわかってないからだろうな。
わかってないならわかってないで黙っていてくれともうけど、DDDやってみましたっていうよくわからない記事ばかり出てくるし...
正直、AI に命令を出すリード、マネージャ、リーダーの能力が上がらないと、AI でコードを大量生産すると手に負えないスラムが根深く絡み合った構造で広がっていくことになるだろうというのが既に見えている。
というのも、AI ほとんど影響ないちょい前の時点ですら「うちはDDD、TDD、クリーンアーキテクチャ、k8s、アジャイル、スクラム等々を採用して云々」ってプロダクトが、リリースから半年、1年で開発がスタックしている、という事例は一般が想像する以上に存在している。
リリース時は、CTOやマネージャが腕組みしてWebページで華々しい成果発表するものだが、その裏で手動運用のオンパレード、一箇所変更したらどこに影響が及ぶかわからない地雷原、不具合障害が発生するたびに増える監視サービス、手動運用マニュアル。
その前で、「圧倒的ではないか、我がプロダクトは」って悦に入る経営陣、の図。
それ見て「SaaS界のネズミー王国や〜」って妄想を迸らせる利用者側経営陣と、ブルシットな手数だけ増えて、業績給与はぴくりくらいしか動かないで悶絶する利用者側従業員。
この状態で、「いや〜、新技術の導入、失敗しましたわ〜。経費が5倍くらいに膨れ上がってます。ごめんちゃい」なんてリリース出せないでしょ。
それ見て教科書ガイドエンジニア、カタログショッピングエンジニアが「世界を変える！ 俺(の業務経歴書)が変わる！！」って初見手探りで導入して、連れション地獄。
これが現状よ。
ここにAI が入ってくると、ますます「中身も、他の処理との関係性もよくわからんけどプロダクトに組み込まれた謎プログラムの塊」が、「これ以上機能を載せるとバランスを崩して全体が倒れる」寸前のサイズまで育つわけよ。
ここまで行っちゃったら、どこをどうしたらどうなるか、「AI 使ってふふふふ〜ん」ってレベルのエンジニアでは太刀打ちできなくなってるだろう。
すっと
「動くな！」
となって、対策のための会議とドキュメントづくりが延々と半年とかいうオーダーで繰り広げられることになる。
その間やれること、というかやらなきゃならないことは、障害対応手動運用。
こういう状態に陥らせたリーダーやリードテック、CTOは「新しいことに挑戦したいので」と敵前逃亡、成果発表のWebページを担いで次の犠牲者の元へ。
ちゃんと設計したら、生成AIを駆使する必要、あまりないはずなんだよなー。
で、テストも書いてくれる、っていうけど、AI に全投げ似非エンジニアにその妥当性とか、判断できんのかな？
カバレッジを100％に近づけるためだけのテストを手動で大量に書くのを代替してくれるかもしれないけど、あのテストが品質保証、障害対策になってる現場が一つでもあるか？
今流行りらしい、業務ドメイン分割マイクロサービスだと、AI で辻褄合わせてテストとか、無理やぞ。
という地獄が、2、3年後訪れるだろう。
楽しみやなぁ〜w
という話をすると、AI使いこなせないオールドタイプの負け犬の遠吠え、みたいにいうてくるのがいるんだけど、むしろAI を効果的に活用するための構造、構成とか模索してんのよ。
2025年、私たちはソフトウェア開発の歴史的な転換点に立っている。大規模言語モデル（LLM）の進化は、GitHub Copilotのようなコード補完ツールに始まり、今や「何を作りたいか」を自然言語で伝えるだけで、アプリケーションの雛形が数分で生成される時代を現実のものとしつつある。この光景を目の当たりにした多くのプログラマが、漠然とした、しかし確かな不安を抱いているだろう。「私たちの仕事は、いずれAIに奪われるのではないか」と。
この問いに対する私の答えは、半分はYesであり、もう半分はNoだ。より正確に言えば、プログラマの仕事の本質が、歴史上かつてないレベルで抽象化され、その役割が再定義されるのだ。私たちは、コードを「書く」作業から解放される一方で、これまで以上に高度な思考を要求されることになる。
本稿では、プログラミングの歴史を「How（いかに作るか）」から「What（何を作るか）」への移行として捉え直し、LLMがこの流れをいかに加速させるかを論じる。そして、その先にある、AIには決して代替できない、人間ならではの競争優位性、すなわち「Why（なぜ作るのか）」を定義し、記述する能力の重要性について深く考察していく。これは、単なる未来予測ではない。今を生きるすべてのソフトウェアエンジニアにとっての、生存戦略の提示である。
LLMの登場を特異点として捉える前に、我々が立っている場所を正確に知る必要がある。ソフトウェア開発の歴史は、常に「抽象化」との戦いであった。そしてその歴史は、プログラマの関心が「How」から「What」へと徐々に移り変わっていくプロセスとして描くことができる。
コンピュータの黎明期、プログラミングとは、計算機が理解できる命令（How）を、一行一行、丹念に記述する作業そのものであった。アセンブリ言語や初期のFORTRAN、COBOLといった言語は、ハードウェアの制約を強く受けており、プログラマはメモリ管理やプロセッサの動作といった、極めて物理層に近いレベルでの「How」を意識する必要があった。
この時代のテストもまた、「How」に強く束縛されていた。書かれた手続きが、意図した通りに順番に実行されるか、特定の入力に対して期待された計算結果を返すか。テストの関心事は、あくまで「手続きの正しさ」の検証にあった。ビジネスロジックと実装の詳細が密結合し、コードは特定の処理手順を記述した、硬直的な塊となっていた。
風向きが変わり始めたのは、ソフトウェアの規模が拡大し、その複雑性が人間の認知能力を超え始めた頃だ。1990年代後半から2000年代にかけて提唱されたエクストリーム・プログラミング（XP）の中で、テスト駆動開発（TDD）という考え方が登場する。
TDDの本質は、単なるテスト手法の改善ではない。それは、プログラミングのパラダイムを根底から覆す思想だった。TDDは、「まずテストを書く」ことを強制することで、プログラマの意識を「これから実装するコード（How）」から「そのコードが満たすべき振る舞い（What）」へと強制的に転換させたのだ。
テストはもはや、書かれたコードの後追いで正しさを検証する作業ではない。それは、これから作られるべきソフトウェアの「仕様書」であり、「振る舞いの宣言」となった。例えば、「ユーザーがログインボタンをクリックしたら、ダッシュボード画面に遷移する」というテストコードは、具体的な実装方法（`onClick`イベントハンドラの中で`window.location.href`を書き換える、など）には一切言及しない。それはただ、達成されるべき「What」を記述しているだけだ。
この思想は、ビヘイビア駆動開発（BDD）へと発展し、`Given-When-Then`といった、より自然言語に近い形式でソフトウェアの振る舞いを記述するスタイルを生み出した。プログラマだけでなく、プロダクトマネージャーやビジネスアナリストといった非技術者をも巻き込み、「What」を共通言語として定義する試みが本格化したのである。
TDD/BDDによってプログラマの意識が「What」に向かい始めると、コードそのものもまた、宣言的なスタイルへと進化していく。この変化を劇的に加速させたのが、モダンなフレームワークの存在だ。
Reactを例に考えてみよう。Reactが登場する前、フロントエンド開発はjQueryに代表されるように、DOMを直接操作する命令的なコード（How）の連続だった。「このボタンがクリックされたら、この要素のテキストを書き換え、あちらの要素を非表示にする」といった具合だ。
しかし、Reactは「UIとは、ある状態（state）に対する純粋な写像である」という宣言的なモデルを提示した。プログラマがやるべきことは、UIの状態（`state`）と、その状態がどのように見えるか（JSXによるコンポーネント）を宣言することだけだ。状態が変更された際に、DOMをどのように効率的に更新するかという面倒な「How」の部分は、Reactの仮想DOMと差分検出アルゴリズムがすべて隠蔽してくれる。プログラマは「What（UIのあるべき姿）」を記述するだけでよくなったのだ。
この「WhatからHowへの変換」は、様々な領域で見られる。
これらのフレームワークやツールは、いわば「特定の制約下における、WhatからHowへの高性能な変換器」として機能してきた。プログラマは、フレームワークが課す「お作法」や「制約」を受け入れることで、退屈で間違いの多い「How」の記述から解放され、より本質的な「What」の定義に集中できるようになった。我々が「生産性が高い」と感じる開発体験は、この優れた変換器の恩恵に他ならない。
現状は、この歴史的変遷の延長線上にある。プログラマの仕事は、手続きを記述する職人から、振る舞いを定義し、それを実現するための最適な「変換器（フレームワーク）」を選択・設定するアーキテクトへと、その重心を移してきたのだ。
フレームワークがもたらした「WhatからHowへ」の潮流は、LLMの登場によって、未曾有のスケールで加速されようとしている。フレームワークが「特定の領域に特化した変換器」であったのに対し、LLMは「あらゆる領域に対応可能な、究極の汎用変換器」としてのポテンシャルを秘めているからだ。
前章で述べたように、ReactやTerraformといったフレームワークは、その恩恵と引き換えに、私たちに特定の「制約」を課してきた。Reactを使うならコンポーネントベースで思考し、状態管理の作法に従う必要がある。Terraformを使うなら、そのエコシステムとHCLの流儀を受け入れなければならない。これらの制約は、WhatからHowへの変換を自動化するための「レール」であり、私たちはそのレールの上を走ることで効率を得てきた。
しかし、LLMはこの前提を覆す。LLMは、特定のフレームワークや言語の知識を事前に学習しているが、その利用において絶対的な制約を課すわけではない。私たちは、より自由な形式で「What」を伝えることができる。
例えば、こうだ。
ユーザー認証機能付きのシンプルなブログアプリを作ってほしい。フロントエンドはReactとTypeScript、UIコンポーネントはMUIを使う。バックエンドはNode.jsとExpressで、データベースはPostgreSQL。ユーザーはGoogleアカウントでログインでき、新しい記事を作成、編集、削除できる。記事にはマークダウン記法が使えて、画像もアップロードできるようにしてほしい。
この要求（What）は、特定のフレームワークの流儀に則ったものではない。複数の技術スタックを横断し、機能要求を自然言語で並べただけのものである。しかし、現在のLLM、特にGPT-4oやそれに類するモデルは、このレベルの要求から、ディレクトリ構造、設定ファイル、APIエンドポイント、フロントエンドコンポーネントに至るまで、驚くほど具体的なコード（How）を生成することができる。
これは、フレームワークが担ってきた「WhatからHowへの変換」が、特定のレールから解き放たれ、より広範で柔軟な領域へと拡張されたことを意味する。これまで自動化が難しかった、あるいは特定のフレームワークが存在しなかったニッチな領域や、複数の技術を組み合わせる複雑なシステム構築においても、AIによる宣言的プログラミングの恩恵を受けられる時代が始まろうとしているのだ。
LLMという汎用変換器の登場により、プログラマの生産性は、「いかに質の高いWhatをLLMに伝えられるか」に直結するようになる。これは、俗に「プロンプトエンジニアリング」と呼ばれるスキルだが、その本質は、ソフトウェア開発における「要求定義」そのものである。
質の高い「What」とは何か。それは、曖昧性がなく、網羅的で、矛盾のない要求である。
これらは、優秀なソフトウェアエンジニアが、プロダクトマネージャーやデザイナーとの対話を通じて、日常的に行ってきた思考プロセスそのものではないだろうか。LLMの登場は、この思考プロセスを、より明確に、よりテキストベースで「記述」する能力を求める。私たちの頭の中にあった暗黙的な仕様が、LLMへの入力（プロンプト）という形で、明示的に言語化されることを要求するのだ。
やがて、ほとんどのプログラミング作業は、この「Whatの記述」に収束していくだろう。TDDがテストコードという形式で「What」を記述したように、私たちは自然言語や、より構造化された要求記述言語を用いて、AIに対して「What」を宣言することになる。コード（How）は、その宣言から自動生成される中間生成物に過ぎなくなる。まさに、コードが蒸発していく未来である。
「What」を伝えれば「How」が手に入る。この魔法のような世界の到来を前に、私たちは一つの重大な問いに直面する。それは、「そのWhatからHowへの変換は、本当に一意に決まるのか？」という問いだ。
答えは、明確にNoである。
ある「What（要求）」を実現するための「How（実装）」は、無数に存在する。そして、どの「How」を選択すべきかを決定するためには、単純な機能要求（What）だけでは情報が全く足りない。そこには、必ず「Why（なぜそう作るのか）」という、背景、文脈、そしてトレードオフの考慮が必要不可欠となる。
簡単な例を考えてみよう。「1億件のユーザーデータを格納し、ユーザーIDで高速に検索できるシステム」という「What」をLLMに与えたとする。LLMは、どのような「How」を提案するだろうか。
これらの選択肢は、どれも「What」を満たしている。しかし、その特性は全く異なる。案Aは多くのエンジニアにとって馴染み深く開発が容易だが、10億、100億件へのスケールは難しいかもしれない。案Bはスケール性に優れるが、厳密なトランザクション管理は苦手だ。案Cは高速だが、運用コストとシステムの複雑性が増す。案Dは安価だが、検索速度は他に劣る。
LLMは、これらの選択肢をリストアップすることはできるだろう。しかし、このプロジェクトにとって最適な選択肢はどれかを、自信を持って決定することはできない。なぜなら、その決定には、LLMが与えられていない「Why」の情報が必要だからだ。
これらの「Why」こそが、無数に存在する「How」の中から、ただ一つの「正解」を選び出すための羅針盤なのである。そしてこの「Why」は、ビジネスの目標、組織の文化、ユーザーの期待、技術的な制約といった、極めて人間的で、文脈依存的な情報の中にしか存在しない。
ここで重要なのは、これまでもエンジニアは、この「Why」に基づく意思決定を、意識的あるいは無意識的に行ってきたという事実だ。
私たちが技術選定を行うとき、単に「流行っているから」という理由だけでReactを選ぶわけではない。「SPA（Single 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
1人2人じゃなく、何人もがプロジェクトの進行やばい、って声を上げてる状態なんだが。
今のやり方だとどう考えても期日に間に合いません。
こうしたらどうでしょう？
作業順番的にここを先にやっておかないと、大量の手待ちが発生します。
いや、最初に合意したスケジュール通りにドキュメントを整備してください。
う〜ん、手空き時間にこっちやっておくか……。
この機能、裏でこういう仕組みとこう言う仕組みが必要なんですが、先に作っておかないと実装できなくなりますよ。
最初に合意したスケジュール通りにドキュメントを整備してください。
大量の手待ち発生。
スケジュールどんどん押していく。
タスク消化率は悪くない？
そりゃ、消化しやすいやつから手をつけてるからそう見えるだけで、未決定なものとか難易度高いタスクがかなり後回しにされてるんだけど、タスクの粒度もバラバラででかいのが残ってるんだけど、それでもタスクの数で消化率出して大丈夫なんか？ w
いや、そこじゃねぇだろ。
いや、後から増えてるんじゃなく、もうだいぶ前に指摘してたよね？
………………。
君さ、ガントひいてたよね？
今どれくらいのビハインドなん？
一応してる？
なら手待ちとかそんな頻繁に発生するはずないんだけどな……。
要件仕様書書いて、画面デザイン起こして、ER図書いて、API設計書まで書けば、あとは人海戦術で実装すればOK？
……あー、そう……。
裏で動く部分は考えた？
うん。フレームワークの種別で言えば、一致してはるけど、このサービスが要求する仕様にはマッチしてる？
利用パターン抽出して、どのパターンでも対応できるって確認してるように見えないんだけど。
このサンプル、ドメインロジックにフレームワークの要素ががっちり編み込まれて密結合になってるけど、大丈夫？
え？ フレームワークのサンプル参考にしてるんだから、正しい？
………………。
なんだろ？
YouTubeで犬小屋のDIY動画見つつ、2世帯3階建ての家建ててる感が半端ない。
流石にやばいだろ、って真っ当なエンジニアが声を上げてんのに、なんで「ネガティブな発言が多いので、評価できません」とか上から目線で言われるか、全然理解できねぇ。
君らにはどういう世界線が見えてんの？
真顔で言おう。
この規模、複雑度でこの開発プロセスだと、終盤にあちこちで衝突が起こって、その場しのぎの対応するしかできなくて、テストも網羅性を欠くので、全く品質を担保できないんだが……。
これは楽観的というのではなく、無知に起因する無謀だよな。
まぁ、もう無関係の人になるので w
世の中には2種類のエンジニアがいる。
具象思考しかできないエンジニアと、抽象思考ができるエンジニアだ。
プロダクトがごくごく小さければ、例えば0->1の初期実装の段階では、「動作する」という点だけから見れば、どちらも大した差はない。
皿回しで例えると、初期段階、皿を4つくらい回す程度なら、大した違いがない。
が、16、32と増えていくとどうなるか。
具象思考は、1つ1つを回す。
64、128と増えていったら？
破綻する。
抽象思考は、ある程度の皿のグループをまとめて、回し続けるための仕組みを作る。
皿が追加されるまで棒を立てないとしても、どういう皿が用意されているかあらかじめ確認をして、配置などの準備をしておく(本来は、これをDDDのドメイン分析という) 。
64、128と増えていったら？
まとめたグループをさらにまとめて回す仕組みを「予定通り」作る。
作っておいてもいいが。
どのレベルのグループの数も、8を超えないように調整しつつ(だいたい5を超えないようにしている。平均的な認知能力を超えないように)。
256、512、1024……。
具象思考のエンジニアは、「今の段階でそこまで実装する必要はない」という。
が、設計もしない。
なぜなら考えられないから。
棒を立て(実装)なくても、配置や仕組みなどを「設計」し、区画を分ける。
プログラマ上がりの中には、手が早いだけで具象思考しかできないエンジニアが大量に混じってる。
ググって、今目の前にある皿を最適に回せる棒を探して、空いた場所に立てて、回し始める。
その一連の「処理」は早い。
けど、それぞれ思い思いの棒を立てるから、それぞれの皿の回転状態をメンテし続けるのは大変だ。
この棒はこうやって操作する。
その棒はこうやって操作する。
そういう、何種類もある「処理」からパターンにマッチした処理を手早く行う。
そのパターンの数を誇って「優秀なエンジニアでござい」と鼻をおっ広げる。
バカ言え w
数が増えれば限界が来る。
皿が落ち、割れ始める。
逃げる。
最近Claude Codeで遊んでるけどとにかく終わらせるのが早いよね
確かに出来上がったものはうーんって思うこともあるけどテストも書いて通ってるからOKでしょ
断言するけど少なくとも俺含む大多数のプログラマより仕事は早い
未来予想だけど変更しやすいコードみたいなのは要らなくなりそう
だってすごいスピードで一から作れるんだから影響範囲とか気にしないで作り直せばいいじゃん
クリーンアーキテクチャみたいなのはもう時代遅れになるんじゃないかな
エンジニアとして失業することはないと思うけどプログラミングに価値は無くなったね
フリーランスの人とかどうするんだろうね
システムとか、Webサービスとか規模が大きくなると、決定的に抽象思考が必要で、中でも高度な「複数層の抽象レベルを扱う能力」が必須なので、具象思考しかできない「プログラマ」が出世してその辺りをいじり出すと、詰む。
マイクロマネジメント的にでかいシステムを扱うから、うまくいくわけがない。
なんかわからんけど、これをやれと言われてやってきて、やれてきた。
それの積み上げ。
新しく「××しなけりゃいけない」となったら、今時は便利で、ググったりAI使ったりすれば、HowToが並ぶ。
背後にある体系的な思考法とか、歴史的経緯とか、密接に関係する概念とか、全部すっ飛ばして、HowToだけ集める。
すると、全てがチグハグになる。
一個一個、ミクロに見ると、その場その場はそれっぽく見える。
ちゃんとやれてるように見える。
でも全体を俯瞰すると、背景にあるはずの何層にも渡った網の目のような抽象構造が存在しない。
DDDはこの「何層にも渡った網の目のような抽象構造」のための方法論の一つだって理解しないと、多分正しく適用できない。
画面に対する必要十分な実装とだけ考えると、画面に引っ張られまくる。
が、そこで扱われているデータは、ドメインレベルの抽象度のあるコンセプト(オブジェクト)であり、それにまつわる操作や属性を並べておけば、画面はそれの1断面を切り出しただけ、ってのがわかる。本体のコンセプトがちゃんと捉えられていれば、画面の常識の範囲内での変更は、大した影響はない。せいぜいが属性を増やす(そのあたり、DBの1カラムにしないで、Jsonにぶち込んでおけば、テーブルの変更すら不要な)程度の変動しか起こらない。
そして、それが変更容易性につながっているし、Jsonの1要素が増えるだけなので、処理の根幹は変わってないから、余分なテストは不要、ということだ。
そういう背景とかを知らんでDDD、特にこの「ドメイン」を「業務ドメイン」とか勘違いしているアホウには、到底辿り着けない境地だよね w
と、多分、今の日本のエンジニア業界の致命的な欠陥を指摘してみた。
あー、ちなみに、最近、AI、AIと言われるようになったけど、抽象化しないで具象レベルでAIを投入して多量のソースを生み出したら、まず間違いなく管理不能に陥るからな w
やるの、無理(やってやれないことないけど、厳密に計画してウォーターフォールを何回も回さないと無理で、それぞれの計画から要件定義からよほど知見がある人じゃないと無理。そこらへんの素人には無理、なので無理)って指摘したら、「『個人的経験をもとに』ネガティブな発言を繰り返す」扱いされて、マジ呆れた。
DDD、TDD、クリーンアーキテクチャ、マイクロサービス等々、何のために捻り出されたと思ってんだよ。
実際、指摘した通りの現象に陥ってるじゃねぇか。
したら、「陥らないように行動するのが仕事じゃないですか？」
とかわけわからんこと言ってくる。
工学的知見に基づいて、この規模、複雑度のプロジェクトを、画面駆動開発のウォーターフォールでやるのは無理だと言っているのに、ウォーターフォールで解決しろって、お前、何言ってんだよ、と。
# ちなみに、ドメイン駆動開発 with Sudoモデリング を採用していると主張している。いや、Sudoモデリングの時点でドメイン駆動じゃねーじゃねーか w
とか言って、依存関係考えてないから、どこがどうなるか確定した場所が少なすぎて、プロジェクトがスタックし始める。
基礎の組み方、配管の通し方から、同居予定のばあちゃんの1週間の着替えパターンまでを、同一ラインで扱って、全部確定するまで実作業をしないで家を建てるなんてアホウはそうそうおらんぞ。
見た目はびっしりしてるんだけどね。
けどね。
けど……。
昨日、離脱すると正式に決まって、今朝は久しぶりにちゃんと寝れた。
1ヶ月以上、考えすぎて寝れてなかったからな。
最近の開発環境って進化しすぎてて本当に最小限のコードを書くだけでプロダクトができる
Unityとかのゲーム開発環境なんかが良い例でトレーニングすれば1日でそこそこのゲームを作れるようになる
これは特にオープンワールド系のゲームが物量でゴリ押すようになったから人員が必要になったことが原因で
高度な開発知識なんかなくてもゲーム開発に参加できるようになってる
Difyも同じような道を歩んでいて、LLMを使った個別エージェント開発だとかRAG対応だとかは物量でゴリ押す雰囲気が出てきていて
Difyみたいなポチポチすればエージェントが作れます、っていうツールでとにかく現場の人に作らせようとしている
（恐らくこの分野はLLMに駆逐されそうだが）
UnityにしろDifyにしろ、実際に必要となるロジックなんかは本当に最小限で済むのでオブジェクト指向だとかDDDだとかは全然必要とされていない
Unityでキャラを歩かせる場合は始点と終点を指定してNav Meshとかを設定しておけば勝手にやってくれる
で、問題なのはこの程度のコードを書いただけで「プログラミングできる」と勘違いしてしまう人が続出している点で、採用活動するとかなり多い
君たちがやってるのはせいぜいコンフィグを書いてるレベルであってプログラミングではない、と言っても理解してもらえない
試しに
「このキャラを10個のポイントからランダムに出現させて、他の10個のポイントのどこか1つに歩かせてみて」
と言ってみると分かるが、この程度の実装すらできない
逆にできる人は自分はスーパーエンジニアだと思い込んでるぐらい自信満々で面接に来る
オブジェクト指向の話をしても「そんなの必要ですか？」みたいな態度で関数も使わずにベタ書きコードを恥ずかしげも無く自慢してくる
AI人材も似たような雰囲気が出てきていてDifyとかでチャット作って
という人が段々増えてきているしこのトレンドは収まることがなさそう
AIが駆逐するのはこのレベルのプログラマーであって、もっと上位層のプログラマーは（まだしばらく）駆逐されなさそう
こいつは、DDD＋マイクロサービスの扱いで、ドメインと主張するもの(なんらかの超細分化、共通化されたFunction)ごとに1サービス立ち上げてgRPCでCallとかいうのを真顔でおっ始めてしまう層と完全に被っているのだが。
同じ口で「疎結合で設計してます」っていうから、空いた口が塞がらない。
はっきり言おう。
この手の設計は
「超密結合」
です。
共通化された部分の「設定」を変えると関係している部分全てに影響を与えるし、共通マイクロサービスの仕様をちょっと変更しようとしても、それを利用しているすべてのモジュールに影響を与える。
そして、分離だけはちゃんとされているので、
「テスト容易性が圧倒的に低い」
のに、「TDDも採用しています！」って言い切れちゃう頭を疑う。
デプロイしないと検証できないし、動作がデプロイ先の設定に依存するんだから、実環境以外でのテストはアリバイづくりに過ぎない。
「設定より規約」って言われてるのは、「どう設定されているかソースや実環境のデータを確認しないとわからない」みたいな余計な認知負荷をかけるようなことをすると、巨大化、複雑化していく今時のWebサービスでは成長戦略に致命的なダメージを与えることになるからだ。
のだが、Web記事漁ることしか能がない、「イケてるエンジニア様」たちは、「設定より規約」って言葉も、その定義も知っているのに、自分が何をしているか理解できない。
反論が「ここのWeb記事に書かれてます！(ﾄﾞﾔッ」でお話にならんのだ。
自分の頭で考えろ。
意識高い雰囲気で、ここまで的外れなことをやっている組織には、本当に、本当に、本当に、呆れうんざりする。
AIの方がマシ、ってプログラマ、ソフトウェアエンジニア、テックリード、CTOには山のように出会ってるから(いなければ、炎上現場や自縄自縛現場なんて存在しない)、奪われる人はたくさんいそうだが、ソフトウェアエンジニア、プログラマの仕事って、AIでなんとかならない部分も多いから、一般論として奪われるとは言えない。
真偽の程もわからないWebページの単語を断片的に並べて、コピペして、整形するなんて、AIそのものの動きやろ？
お話にならない。
使い物にならない。
「DDDとTDDとクリーンアーキテクチャとマイクロサービス採用して、疎結合に設計してる」
文章にすりゃ100点満点の素晴らしい内容でドヤ顔で自画自賛しているのに、全サービスを起動させないとローカルで開発環境が正常動作しないとか、何か修正が入るたびにそのブランチ取り込んでくれとか言う指示が飛んでローカルの勝つ環境がぶっ壊れるとか、どう考えても矛盾している状態なのがおかしいとか、これっぽっちも思わないとか。
そんな、AIの方がマシってプログラマ、ソフトウェアエンジニア、テックリード、CTOには山のように出会ってるんだよ。
で、その話をすると「そんな現場あるんですねー」って大笑いするその現場が、そういう現場なんだよ。
言っとくけどね。
オイラ、その話して呆れてるんだよ。
そして、そのプロジェクトの進め方の瑕疵は、どう転んでも治癒しない。
でもって、そういう現場を生み出した、牟田口廉也的な「高級エンジニア」は、これを成功と吹聴して実績として担いで、悲劇の現場から逃げ出して、反省することなく次の現場をぶっ壊しに行く。
プロダクトの規模が年々大きくなっていく分、ヤバさは累乗的にデカくなっていく。
ドキュメントが大量に積み上がってる現場は、「頑張ってる」んじゃなく、基本的に「やばい」 death。
なぜって？
プログラムは、柔軟に変化していく、変化できることが、ゼネコンが建てる建物との大きな違い。
固まったドキュメント。
影響範囲を確認しようにも、そのドキュメントが現時点の正しい姿であるとは限らない。
いや、正しい姿であるはずがない。
作ったら作りっぱなしだから。
だからこその、DDDやTDDなんだが、形式的に適用しているから、正しく作用しない。
これでDDDなんかできるわけないじゃん
サービスの根幹に当たる部分を、複数のありものフレームワークの比較評価ドキュメントをWeb記事から作り出して、どれを使うか決めるとか普通にやってて、「ここ、DDDを採用している現場だよね？(-_-)」って愕然としている。
DDDを実践してきた身としては、とても違和感があるんだが、今時の「イケてるエンジニア」ってそんなもんなんかな？
「Java書けます」っていう場合、ライブラリの使い方知ってます、とほぼ同義と聞いたことが、ないことはない。
ということは「イケてるエンジニア」ってのは、フレームワークの評価とか選択ができます、ってのと同義ってことなのか？
あり物の組み合わせは他の誰でもやれるから、固有のサービスとしての武器にはならんのだが、早く動いて市場占拠しさえすれば勝てる、って考えなのかなぁ？
「ドメインコンセプト」の概念がなければ、中心的なドメインコンセプトの抽出もできないから、何を内製しなきゃいけないかの判断もできない。
あるいはあれか？
そういうフレームワーク的なモノを作る技術力がないだけなのか？
どちらにしろ、エンジニア名乗るの、いかがなものかと思うが……。
恥ずかしくないのかねぇ？
まぁ、大体パターンはある。
いわゆる「勝ちに不思議の勝ちあり。負けに不思議の負けなし」ってやつ。
今の現場もそうで、どうしようかなー、ってなってるんだが。
「できるエンジニアはたくさんのサービスやフリーのライブラリを知っている」
ってのが、たぶんでかい。
これの何が良くないのかって言ったら、「そのプロダクトに必要なコンセプトを深掘りしない」ので、個々の小さい処理に引きづられて複雑な構成を前提にしてしまうということと、その複雑な構成をフルにカバーできるさらに複雑でリッチなライブラリなりサービスを、業務経歴書に書けるって理由も大きく影響しつつ、選択して、プロダクトの必要な部分とその複雑な仕様の間を無理ぐり埋めることで、複雑な上に歪んだ、9割以上「間違えた」使い方を、プロダクトの基本部分の凸凹にピッタリと縫い付けてしまって、取り外しできなくしてしまうということの2点だ。
こいつは、DDDとは対極にある手法なんだが、なぜかDDDを採用してますって組織でよくみられる光景だったりする。
つまり、DDDすら、プロダクトのコンセプトを深掘りしないで、カタログ捲って目について、「こいつは業務経歴書に書ける！」ってんで表面的に採用して、大した理解もできないままチームの技術力とのギャップを無理ぐり埋めて誤魔化して、にっちもさっちも行かなくなる。
ってパターンよな。
できるエンジニアはたくさんのサービスやフリーのライブラリを知った上で、そのプロダクトに必要なコンセプトを深掘りして、徹底的に抽象化、簡素化して設計してるんです。
Sudoモデリングみたいな画面帳票駆動の権化みたいなうんこ手法なんて、やりません。
そもそも「たくさんのサービスやフリーのライブラリを知った」ってのも、諸元表とか機能表とか「表」や提供者の広告記事を誦じてるんじゃなく、どういう経緯で設計実装されていて、裏でどういう処理がされていて、どういう癖があるかを把握している、っていう点で、多分別物だったりする。
この辺り、やってる連中は同じことをやってると思い込んでるみたいだけど、やってること、「全く違います」。
IQって、いろんな能力のうち、ある種の能力を複数集めて、どれくらい中央値から外れてるかを無理やり1軸で評価してるだけだから、その数値だけを持って「人間を超えた！」っていっても「は？」としか思わん。
パターンマッチング式文書検索システムが、パターンマッチと文書検索の能力だけが高いってだけの話でしょ w
いわゆる東大卒をはじめとした高学歴の中にそこそこの割合混じってる、パターンマッチングが速いだけのアチーブメントテスト脳に近いんだと思うが。
例えばクイズ系とかね。
学生時代なら、まぁ、すげぇなと思わなくはない(≒思ったことない)けど、「で？」としか言いようがないタイプ。
どこの現場にいても、このタイプは本当にただの邪魔者、害悪なんよね。
自分はできる。
俺は……賢い！
って思い込んでるから、本当に扱いに困る。
「そんなのどこのWebページにも書かれてない」から始まって、「ここのページにはこう書かれてる」まで。
そう、そこの一文には、「単語の連なりとしては」そう書かれてるけど、その前に前提条件が書かれてたり、暗黙の前提条件があったりするだろ？ この場合、適用外なんだよ。
とか、
ここの××って単語は、こっちの同じ単語とは別の文脈のものなんだよ。
ってのが理解できない。
「業務ドメイン」は「幾つもあるドメイン概念」のうちの、たかが1軸に過ぎないし、優先順位としてはさほど高くない概念だ。
「業務ドメイン分割」して、「DDD採用してます」って、それ、業務ごとの分割しただけの、帳票画面駆動開発。つまりDDDで否定された手法を引き続きとってるだけだって理解できてないんよ。
だから、ちょっとした画面の仕様変更があるたびに、大山鳴動の騒ぎになる。
ちゃんとDDD採用してたら、大抵がアトリビュートをちょっと追加するだけで済む。
DDDのそれだ。
ウォーターフォールであろうが、容易に実現できる。
君の頭が足らんだけだ w
Frontとサーバサイドの二箇所で、StructなりClassに変数を追加するだけで、DBに更新スクリプトを走らせる必要すらない。
DDDって単語とともに公開されてるWebページを、字面だけ追っかけてHowToを猿真似するからそうなってんだよね。
DDDが目的としていた状態になってないから、そいつは間違い。失敗。うんこ。
お前の能力が、DDDが必要としている能力に遥かに及ばなかった、ってだけの話だ。
事程左様に、エンジニア界隈見てると、そもそもの「エンジニアに必要な能力」が自己認識より遥かに遥かに遥かに低い人がゴロゴロしてるように見える。
その傾向が、近年マシマシになってる気がする。
