  |
はてなキーワード: TDDとは
せません！
って思うわ。
20年ほど前に業界に入って、OJT受けたおっさんにOJT受けたエンジニアか？ w
ソフトウェアエンジニアリングは、しきたりを1ミリも変えたらいかん伝統芸能ちゃうねんぞ！
E2Eテストなんて、今時のWebサービスの規模、複雑度っていう圧倒的物理量に追いつけるわけがないんだよ。
屁の突っ張りにもならないどころか、
爆上げさせてる
いや、そもそもE2Eテストとセキュリティリスク、なんの関係があるんや？ って問題はあるんやけど w
本来そんな機能がないのにあると勘違いして使うことの危険っての、教えてもらわんとわからんか？
って、安全帯のフックを自分のベルトにかけて、送電線の点検ができるか？
安全帯自体の機能として落下防止が当然あるけど、「正しく使わないと正しく機能しない」し、そもそもそれ、体重を支えられるのか？ それ以前に安全帯か？ ただの100円ショップで売ってたキーホルダーちゃうか？ って問題なんよ。
安全帯でも負荷を支えられなきゃ意味ないし、物が違えば、キーホルダーはキーホルダーだし、安全帯は安全帯なんだよ？
Web記事とかの「単語」だけ相手にするから、こういう致命的な間違いをガンガン積み上げて、炎上現場、高粘性現場にレベルアップさせるんだよ。
DDD、TDD、クリーンアーキテクチャ、マイクロサービス、DevOps。
本人達は真面目に輸送機から「素晴らしいもの」を得るための手順を踏んでるという認識しかなく、おかしなことをしてる自覚が皆無っての、そのままだって気づけ。
理解してるなら、その目的がちゃんと達成できてるか、確認してるか？
ちゃんと適用されたまともな現場を知らんで、「こんなもんでしょ」で満足してるの、頭おかしいぞ。
猿か？
才能がないと思ったら、早いうちに河岸を変えた方がいい。
早ければ早い方がいい。
可哀想だから(教え子が？ それとも自分が？ w)、って「がんばれ、がんばれ。才能なんて関係ない」みたいに騙すのは、むしろ害悪だよ。
10年後、気付いて路頭に迷わせるとして、その責任は取れるのか？
まぁ、本人自身が気づいて路頭に迷いつつあるけどどうしようもないのかもしれんが、地獄に道連れはやめてやれ w
それで生計を立てない、趣味の範囲で楽しむ分には好きにすればいいけど、エンジニアに限らず、それなりのお金をもらおうとしたら、才能、向き不向きは超えられない壁として現実に、強固に存在している。
球速120km出ないけど阪神の一軍のピッチャーに、ってのはどう逆立ちしても物理的に不可能だ。
でも草野球は楽しめる。
才能がなけりゃ、一人で永遠に「大いなる助走」を続けりゃいい。
誰にも迷惑かけないなら。
医師、看護師、会計士、経営者、etc.etc. にも、才能、向き不向きはある。
落ち着きないし。
同じことを何日も続けたら、爆発する。
「明日も同じことしなきゃならないのか……」って考えただけでも、死にたくなる。
こんな感じに、才能がものをいう分野って、意外に多い。
ソフトウェアエンジニアは、設計実装の抽象度が多層化していて、その巧拙によって安定度、運用や機動的な新機能追加の手間、リードタイム、金や何やら、数十倍、規模複雑度が爆上がりしている今なら下手すりゃ数百倍差が出る。
その差をちゃんと理解するには、巧の現場の「こういう世界があるんやー……」って実体験が必要だったり、巧レベルの才能が必要だったり、経営知識が必要だったり、経済知識も必要だったりして、「拙」の現場にぶら下がってるだけのエンジニアが「才能なんて幻想」って吠えたっても「マジ、迷惑だからやめてね」って思う。
どの炎上現場でも、高粘度現場(リーダーマネージャが理解できないからって邪魔ばっかりしてきたり、そもそもプロダクトがぐっちゃぐちゃになってたりして、どんな行為がサービスの息の根を止めるかわからなくて身動きが取れない「震える舌」みたいな現場。物事が全然進まない現場。通常、経費で札束ガンガン燃やしてるはずだから、ここも炎上現場っていう)でも、この手のエンジニアが腐るほどぶら下がってるんだよね。
たいてい、生み出されるソースコードとドキュメントの割合がおかしなことになってる。
いや、そういうの主催してる暇があったら、コード書けよ、って。
でも、Web記事引いてきて、「〇〇にはこう書いてある」とかドヤ顔で机上の空論で時間潰して「俺も一端の理論派エンジニアだぜ……」とか、いや、お前はただの受け売りを理解もせず垂れ流してるだけのそこらへんの AI と変わらんクズだよ。
おいらの師匠の一人は「TV出たり、本書いたりするやつは二流。一流は、自分の仕事に集中していて、他のことやる暇ないから」って言ってたけど、ほんとその通りだと思うよ。
シャバと違い、ソフトウェアの世界は驚くほどのスピードで巨大化、複雑化している。
30年、40年前なら、社会性の乏しい、プログラミングコンテスト受賞者みたいなエンジニアでも無双できたけど、今は無理なんだよね。
今だと玉拾いも任せられないくらいだったりする。
ちょい前も、PostgreSQLの中身いじれます！ って東大卒業生いたけど、視点が局所的すぎて全体感に欠けてて、プロジェクトがヤバい状態になってるのが理解できなかったりしてたからね。
そろそろリリースできる状態になってる予定だけど、おいらの読み通りα版完成が3ヶ月遅れ、そこで大量の不具合が発覚してベータ版完成がそこからさらに3ヶ月以上遅れ、不具合積み残したまま見切り発車、ってなるんじゃねーかな、と思ってるんだが w
才能の種類、方向性によっては、10年前も今もたぶん10年後も変わらず十分通用するものはあるんだけどねー。
そこに生活水準をあげてしまうと、自分はもう通用しないと気づいても、撤退できない。
マイカーガー。
マイホームガー。
子供ガー。
愛犬ガー。
んなもん知るかっ！
そういう「元エンジニア」がリーダーとかマネージャとかにクラスチェンジして、事業、プロダクトの足を引っ張る。
あそことか、そことか、具体的な企業名はあげられないけど、そういうエンジニアが漬物石のように重しになって、身動きが取れなくなってるところが多い。
VCとかから、もっと売り上げを上げろ。成長率を上げろ、というプレッシャーを与えられ、何かしなきゃいけない。ってなって、外付けの雰囲気だけのサービスをどんどん外付けしていく戦略を取る。
1年で10。
2年で30とか。
マジかよ w
思い思い行き当たりばったりに作ったら、手間だけ増えてそれを壊すわけにはいかなくなって、さらに身動きが取れなくなっていく悪循環しか見えないんだが、そんな経営方針で大丈夫か？
とか意味不明な決定して、認証認可v1、認証認可v2、認証認可v3とマイクロサービスが増殖して、さらにv4を企画してるとかいう会社だってある。
真っ当な声には、自分の存在感を示すためだけの反対を唱えて邪魔したりして、現場で手を動かしているエンジニアより高級を取ってんのに、事業、プロダクトへ与えるダメージは倍増する。
さらに、自分の地位を死守するために、それを脅かす腕利のエンジニアを陥れる、排除することに全力を傾ける。
これで3倍界王拳だ w
経営者はできるエンジニアたちに任せていると思い込んでいるかもしれないが、さて、どうかね？ w
大本営発表的にはうまくいっているとされているサービスが、その裏側はカーオブファイヤーみたいなところって、結構ある。
はっきりいう。
今はクラウド環境のプロダクトで、どのように自動テストで検証可能なシステムを構築するかの手法の研究を続けてる。
具体的には、今まで関わってきた炎上現場で安定稼働を達成させた手法(TDD)だな。
ワークライフバランス？ w
才能のない人は河岸変えろ。
業務経歴書にも今まで使ったことがあるサービスの名前をたくさんたくさん載せてます。
じゃねーよ。
ボルトに世界水泳、吉田沙保里にNBAに出場させるような使い方してて、どこが技術力だよ。
ってのが多い。
「どうしてこのAurora、リーダーがこんなにたくさんぶら下がってんの？」
「テナントが増えて、アクセスが増えたので、負荷分散のために増やしました。水平スケーリングってやつです」
うん。水平スケーリングは知ってんねん。この程度のテナント数、ユーザー数、アクセス数で、どうしてこんなにでかいインスタンスのリーダーがぶら下がってんのか？ って聞いてんねんけど……。
って現場、多い。
でも、今通常営業してるサービスでも、こういうところ多いんだよな。
それはともかく、
「マイクロサービス化していて、いま120を超えたところで、当面160になります」
「……は？」
「……デプロイの時、どうすんの？」
「変更があるサービス名を書いたファイルを一緒にコミットして、それ読み込んで、GitHubActionsでデプロイさせてます」
「Cloneして立ち上げます」
「これ……、モノリポ？」
「120個？」
「120個」
「なんか立ち上がらないんだけど……」
「あ、修正中なんで、〇〇と××のコミットをチェリーピックしてください」
「……動かないぞ」
「昨日の夕方、変更が入ったみたいなんで、△△のコミットもチェリーピック。いや、＋＋のブランチを……」
5日で立ち上げ切れるんか？
って現場がね、案外たくさんあるんだ。
「ほう……？」
どうして「自分が間違えてる」「自分が見当外れなことをしている」可能性ってのを考慮しないんだろう、この人らは？
っていつも思う。
マイクロサービスの目的も前提も理解しないで、HowToだけ猿のように繰り返してるって自覚ないんか…… (-_-)
ってマーカーで引いた一文見せつけられるんだが、その前に書かれてある前提とか目的とか、書かれてない暗黙のそれとか、いわゆるコンテキスト削ぎ落として、単語レベルの理解を開陳されても、「は？」としか反応できんのよな。
120のマイクロサービスとか、お前、認知科学の知識もないねんな……。
それマイクロサービスじゃなく、「粉砕されたモノリシックサービス」っていうんやで、と。
まーじで、技術本とかの恣意的なつまみ食いで訳分からん理論構築すんなよ。
それでプロダクトがうまく回ってなかったら、それが答えなんよ。
まぁ、「うまく回ってる状態」ってのを知らない、理解できないだろうから、正しい答えに行きつかんだろうけど。
その正しい答えに行きつかない、ってのを
「致命的な才能の欠如」
って呼ぶんよ。
----
「My Job Went To India」の改題改訂版が「情熱プログラマー」なんだ！ありがとう発注したわ。（たぶん達人プログラマーと混同して読んだ気になって読んでないパターンだわ）
俺の悪文のせいで意図が伝わらなかったであろうブコメがあったので、要旨だけ書き直しておくな。
ただ忘れないで欲しいんだけど、TerraformメンテしてAWSとかGCPで立ち上げてサービス公開するまでの速度は、相見積取って稟議通して部材調達から入ってた時代に比べると爆速だけど、人間の技術屋の需要は増えてる。
俺は、「マスタリングTCP/IP 入門編」を人間が読んで理解するのは古いよね、という時代にはならないと思ってる。
Slerが自前で手元で試すようになるから～ってのも懐疑的。SIerやメーカーが内製すると必ず子会社作って分離、ぼく発注者きみ受注者にしたがるので。これは技術じゃなくて感情とか経営の問題。
（ただし、Slerが7payみたいなことやらかすのでは？って疑問なら同意。たぶんそういう生成AIで俺たちでプロダクトなんか簡単に作れるじゃんよギークいらね（仕様バグあり）は一時は増えるだろうね）
追記ここまで
----
VibeCodingでIT技術者は不要になるのか？という話題が花盛りなのは理由があります。
ギーク（現場でコードを書いていたい人）が分かる話から、スーツ（人を集めたりお金を集めたり営業をする）が分かる話になってきたからです。
具体的に言うと、OpenAI社をはじめ続々とTDD(テスト駆動開発)でやってますみたいな、具体的な開発スタイルの話が出てきたから。
そうすると、現場の座組チョットワカルという強めの経営者が理解して判断し始めるんですね。
でもね、その道はもう15年も昔に我々は通り過ぎました。前回のブームと何が違うでしょうか？
技術者なら電子も機械も強電も弱電もお世話になったことのあるオーム社が過去に出していた直球の本の話から。
「My job went to India : オフショア時代のソフトウェア開発者サバイバルガイド」という書籍、何と発行年は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 to AI として、じゃあ残るものは何？というのはオーム社の本を読みましょう。再販しないかなあ。
今後数年は変わらないでしょと書いたら今現在進行形で変わっとるわいと突っ込みが来そうなんで防衛的な意味で書いておくんですが、あなたは過去数年間同じ仕事してたんすか？
仕事のやり方とか内容とか、言語とかライブラリとか、毎年のように変わってたでしょ。
レビューの比率が多くなったとか、コード書かなくなったとか、そういうの、たぶん管理職になった人が嘆いてたのと同じっすよね？
少なくとも、ジュニアエンジニアが低品質なバイブコーディング結果を寄越すようになってレビューが大変とか嘆くのなら、まともなコーディング規約一つ作れていない組織の脆弱さを嘆くのが先では？
手癖でバイブコーディングしてヒットしたプロダクトに、あとから品質上げるように大工事するリファクタリングと言うよりリビルディングな仕事って、別に今もありますよね？
散々テストケースを書かなくて良いプロダクトなんて無いという講演だけ聞きに行って、自分とこでテストケースが自動で走るようになって無いなら、そこが問題でしょ。
手間が増えて、全然楽になってないのなら、それは正しく理解できていず、目的を見失い、手段を目的としているから。
速い話が、
間違えている
からだ。
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
やるの、無理(やってやれないことないけど、厳密に計画してウォーターフォールを何回も回さないと無理で、それぞれの計画から要件定義からよほど知見がある人じゃないと無理。そこらへんの素人には無理、なので無理)って指摘したら、「『個人的経験をもとに』ネガティブな発言を繰り返す」扱いされて、マジ呆れた。
DDD、TDD、クリーンアーキテクチャ、マイクロサービス等々、何のために捻り出されたと思ってんだよ。
実際、指摘した通りの現象に陥ってるじゃねぇか。
したら、「陥らないように行動するのが仕事じゃないですか？」
とかわけわからんこと言ってくる。
工学的知見に基づいて、この規模、複雑度のプロジェクトを、画面駆動開発のウォーターフォールでやるのは無理だと言っているのに、ウォーターフォールで解決しろって、お前、何言ってんだよ、と。
# ちなみに、ドメイン駆動開発 with Sudoモデリング を採用していると主張している。いや、Sudoモデリングの時点でドメイン駆動じゃねーじゃねーか w
とか言って、依存関係考えてないから、どこがどうなるか確定した場所が少なすぎて、プロジェクトがスタックし始める。
基礎の組み方、配管の通し方から、同居予定のばあちゃんの1週間の着替えパターンまでを、同一ラインで扱って、全部確定するまで実作業をしないで家を建てるなんてアホウはそうそうおらんぞ。
見た目はびっしりしてるんだけどね。
けどね。
けど……。
昨日、離脱すると正式に決まって、今朝は久しぶりにちゃんと寝れた。
1ヶ月以上、考えすぎて寝れてなかったからな。
こいつは、DDD＋マイクロサービスの扱いで、ドメインと主張するもの(なんらかの超細分化、共通化されたFunction)ごとに1サービス立ち上げてgRPCでCallとかいうのを真顔でおっ始めてしまう層と完全に被っているのだが。
同じ口で「疎結合で設計してます」っていうから、空いた口が塞がらない。
はっきり言おう。
この手の設計は
「超密結合」
です。
共通化された部分の「設定」を変えると関係している部分全てに影響を与えるし、共通マイクロサービスの仕様をちょっと変更しようとしても、それを利用しているすべてのモジュールに影響を与える。
そして、分離だけはちゃんとされているので、
「テスト容易性が圧倒的に低い」
のに、「TDDも採用しています！」って言い切れちゃう頭を疑う。
デプロイしないと検証できないし、動作がデプロイ先の設定に依存するんだから、実環境以外でのテストはアリバイづくりに過ぎない。
「設定より規約」って言われてるのは、「どう設定されているかソースや実環境のデータを確認しないとわからない」みたいな余計な認知負荷をかけるようなことをすると、巨大化、複雑化していく今時のWebサービスでは成長戦略に致命的なダメージを与えることになるからだ。
のだが、Web記事漁ることしか能がない、「イケてるエンジニア様」たちは、「設定より規約」って言葉も、その定義も知っているのに、自分が何をしているか理解できない。
反論が「ここのWeb記事に書かれてます！(ﾄﾞﾔッ」でお話にならんのだ。
自分の頭で考えろ。
意識高い雰囲気で、ここまで的外れなことをやっている組織には、本当に、本当に、本当に、呆れうんざりする。
AIの方がマシ、ってプログラマ、ソフトウェアエンジニア、テックリード、CTOには山のように出会ってるから(いなければ、炎上現場や自縄自縛現場なんて存在しない)、奪われる人はたくさんいそうだが、ソフトウェアエンジニア、プログラマの仕事って、AIでなんとかならない部分も多いから、一般論として奪われるとは言えない。
真偽の程もわからないWebページの単語を断片的に並べて、コピペして、整形するなんて、AIそのものの動きやろ？
お話にならない。
使い物にならない。
「DDDとTDDとクリーンアーキテクチャとマイクロサービス採用して、疎結合に設計してる」
文章にすりゃ100点満点の素晴らしい内容でドヤ顔で自画自賛しているのに、全サービスを起動させないとローカルで開発環境が正常動作しないとか、何か修正が入るたびにそのブランチ取り込んでくれとか言う指示が飛んでローカルの勝つ環境がぶっ壊れるとか、どう考えても矛盾している状態なのがおかしいとか、これっぽっちも思わないとか。
そんな、AIの方がマシってプログラマ、ソフトウェアエンジニア、テックリード、CTOには山のように出会ってるんだよ。
で、その話をすると「そんな現場あるんですねー」って大笑いするその現場が、そういう現場なんだよ。
言っとくけどね。
オイラ、その話して呆れてるんだよ。
そして、そのプロジェクトの進め方の瑕疵は、どう転んでも治癒しない。
でもって、そういう現場を生み出した、牟田口廉也的な「高級エンジニア」は、これを成功と吹聴して実績として担いで、悲劇の現場から逃げ出して、反省することなく次の現場をぶっ壊しに行く。
プロダクトの規模が年々大きくなっていく分、ヤバさは累乗的にデカくなっていく。
ドキュメントが大量に積み上がってる現場は、「頑張ってる」んじゃなく、基本的に「やばい」 death。
なぜって？
プログラムは、柔軟に変化していく、変化できることが、ゼネコンが建てる建物との大きな違い。
固まったドキュメント。
影響範囲を確認しようにも、そのドキュメントが現時点の正しい姿であるとは限らない。
いや、正しい姿であるはずがない。
作ったら作りっぱなしだから。
だからこその、DDDやTDDなんだが、形式的に適用しているから、正しく作用しない。
今の現場で信奉されているんだが、おいおいおいおい、考える頭がねーな、AIに駆逐されてぇのか？ SIer仕草のままじゃねーか。
と呆れてものも言えん。
90年代の、箱庭的な単機能小規模完納プロダクトなら帳票・画面駆動開発で十分だったが、常に成長し続ける宿命を背負った多機能なWebサービスでは、帳票や画面遷移、デザインから立ち上げたら、絶対に発生する手戻り、仕様変更についていけなくなるだろ？ ってアンチテーゼとしてドメイン駆動開発が提案されたんだけどな。
手戻り、仕様変更はドメインのコンセプト、概念に沿って発生する。
というのが基本アイディアだ。
帳票・画面という具象はあえて捨象し、コンセプトという抽象に昇華することが本質ということだ。
抽象思考に不自由なエンジニアが、すぐに具象に飛びつきたくなるのはわからんではないが、それによって以前の帳票・画面駆動開発のマイナスが消せてるか？ w
画面、帳票のグルーピングをしてるだけじゃねーか w
本当のDDDの観点からすれば、帳票・画面は、ドメインコンセプトの一断面での切り出しに過ぎない。
如何様にも切り出せる。
足りなきゃアトリビュートを追加すれば済む。
手戻り、仕様変更なんて、道端の犬糞の向きを変えるほどの手間ですらない。
一旦ドメインコンセプトを実装したら、他の機能のほとんどは、それをどう適用するか、パラメータレベルの違いしかない。
ドメインコンセプトレベルで検証(テスト)すれば、いくら機能が増えようが、パラメータの検証だけで済む。
Do you understand ?
こちとら、オライリー本のつまみ食いとか三下が書くWeb記事をありがたがって鵜呑みしてやってるわけではない。
他のいろんなエンジニアが同じことに悩み始めていた20年以上前、クライアントの先輩エンジニアにヒントをもらって始めた内容だ。
当時、上司の設計で交渉を続けていたが、毎度毎度仕様変更が入り、何かずれているんでしょうか？ と聞いた。
「君は僕たちの業務を理解できてない。僕たちにとって〇〇がどういうものか。僕が足りないと感じるのは、君がその要素を理解できていないからだ」
とヒントをくれて、気がついた。
「僕たちにとって〇〇がどういうものか」
つまり、その業務(ドメイン)のコンセプトを無視したら、利用者が本当に欲しいものが実現できないし、手戻りが発生したら対応できないし、変更についていけない。
そりゃ当然だ。
そのドメインのコンセプトの集合体、「ドメイン世界」と一致してないから。
手戻り、仕様変更、いずれにおいても障害が生じるのは、そのねじれのせいだからだ。
コピペして無意味な消し忘れをしたジュニアのエンジニアをカーゴカルトプログラミングと笑う無能エンジニアをたくさん見てきたが、この手のWebの何の根拠もない言説を鵜呑みにして、検証することもなく、HowToの上っ面だけをなぞる猿こそ、何百倍も罪深いカーゴカルトエンジニアだと、自覚しろよ。
お前のことだよ。
お前の語るのはDDDじゃない？
「楽をしたければ自動化、スクリプト化。エンジニアの常識でしょう」
いや、若いのでも、誰に何を教わったかわからんけど、小ロートルがゴロゴロしている。
炎上現場に入ると、大抵「素人」ピタゴラスイッチ的な仕組みが、複雑に絡み合い、無秩序に山積みになり、手をつけられない状態で放置されてる。
はっきり言おう。
スクリプトで自動化なんて、2000年代前半の、単機能、売り切りシステムの時代までしか通用しない発想だぞ。
なんのためのアジャイル、DDD、TDD、クリーンアーキテクチャ等々だと思ってんだよ？
そういうガッチリと作り込んだ、場当たり的な仕組みが成長発展を損なう。
だ。
中途半端に学歴がある奴ほど、自分の「素晴らしい能力(w)」を発揮する「能ない鷹」なんだよな。
「俺はビールのジョッキを8つ持てる」
って自慢してても、10個、12個となったらどこかの時点で持てなくなる。
そのとき、ジョッキをまとめて運ぶ、単純な仕組みを作った方が効率がいいってのは、アホでもわかるだろ？
エンジニアに必要なのは、その単純な仕組みを、大量に作る発想なんだよ。
Do you understand ?
映像のない YouTube のような存在が ポッドキャストです。
YouTube のように、素人も投稿できる音声 メディアです。
※Googleポッドキャストは、YouTube musicに統合の話が出ている
他にSpotify、Amazon music、radikoからも聞けるらしい。
経済系の番組はおじさんがしゃべっていることが多いが、この番組は若い大学生～大学院生の女の子が最近の経済について 話しており、非常に聞きやすく、軽い気持ちで聞けるのが良い。ポッドキャスト的な流し聞きに向いてる。
日経トレンディ及び日経クロストレンドという雑誌の編集部が送るポッドキャストで、最近おすすめのサービスや商品の紹介など。
ボケとツッコミの激しい2人が、最近のサービスや商品、漫画、映画、ドラマなど、とにかく流行っているものについて面白おかしく語る。バルミューダ社長のいじりが好き。
世界や日本の歴史をデータベース化して収益を上げようとする会社が運営しており、歴史に関して何時間も熱く語り、勉強になる。田川をいじるネタが面白い。YouTube番組でもある。
茂木健一郎が、さまざまなゲストを迎えて話すラジオ番組。最近だと、鈴木おさむさんだとか、Pecoさんが出た。過去に ホリエモンやメンタリストDaiGoさん等、有名な人がめちゃくちゃ出ている。スポンサーは聖◎新聞な点が気になりますが、特にそっち系の話はない。
Dream Heartと同じくゲストを迎えて、大学の研究者などから色々な話を聞けるラジオ番組。残念なことに放送終了している。
初期の方は、笑い飯の哲夫さんが仏教に関してあれこれ教えてくれる番組でしたが、ネタが切れてきたのか、だんだんとお坊さんをゲストに迎え、 仏教に関するあれこれをトークする番組 に変わっている
ニュースを読んで、日本語と英語で雑談する番組。 私は英語のリスニング能力が低いので、英語は部分部分しか聞き取れないが、マミはだいたい日本語で話をしているため、文脈からなんとなく英語がわかる気になれる。マイケルは日本語を喋れるのに、かたくなに英語しか喋らない。
文法のあれこれに関して、うんちくを語り尽くす番組。YouTube番組でもある。 とにかく収録時間が長い。よくも文法や単語に関して長時間話せるものだとトークスキルの高さと教養に感心する。
栄養士と料理人とコンサルトの3人が日本の食文化の知識に関して語り尽くす番組で、普段何気なく食べている食事にも深い概念があると気づける。
中学生から知り合いらしい高槻市出身の2人の雑談番組で、以前はどうしようもない下ネタが多かったが、近年、配信者が結婚や子育てを重ね、人間としてまともになっていく感じが興味深い。初期の方から聞いていると、配信者の人生を覗き見している感じが良かったが、 現在、過去回は封印されている。
トヨタ vs ホンダ、任天堂 vs ソニー、ナイキ vs アディダスなど、業界内で有名な2つの企業がどうやって生まれたのか？どのように成長していったのか？をストーリー仕立てにした番組。 もともとは海外の番組で、それを日本語に翻訳した番組でありちゃんと構成が練られている。
新刊の本の内容をドラマ化や、要約して配信する番組。近年、YouTubeでよく見る本の要約のプロ版だと思う。劇団員やナレーションが声優をしていそうに見える。しかし、現在 2020年で更新は止まっている。
大手企業相手の人事コンサルタントである楠田祐が、様々な有名企業の人事部をゲストに、人事評価ってどうやるのか、社内コミュニケーションをどうするのか、リモートワークの対応はどうなのかなど、 どのような人を採用するのかなど、人事に関する貴重な話を聞ける。
フリーランス全般に関して、家賃をどうしているだとか、発注に関する話だとか、 業界を限定しないフリーランスの話を聞ける。しかしコロナ禍の始まりと共に更新が止まっており 、コロナ禍以降、彼らはどうしたのか気になって仕方がない。
転職サイトのGreen編集部が配信している番組で、転職にまつわる話題を話したり、ユニークな事業をしている企業をゲストに迎えて話す番組。
散財王のドリキンと、長らく Web系記事のライターで活躍していた松尾さんがメインでお送りする番組です。主にガジェット系の話でApple 製品や カメラの話などを語っています。かつてはIT系のニュースについて話す番組だったが、 最近は自由気ままに好きなことについて話す番組となっている。AIに関する話題も聞ける。 コミュニティ活動も盛んな様子です。
テック系のポッドキャストも多く聞いてるのですが、 テック系に興味がない方もいると思うので 別にまとめます。 YouTubeの場合、IT系の番組は初心者向けすぎたり極端な意見を述べる番組を散見するが、ポッドキャストは本格的に技術的に語る番組が多い気がする。
宮川達彦さんが運営している番組で、知り合いのエンジニアたちをゲストに迎えて、あれこれ雑談する話で、サンフランシスコで働いているエンジニアも居ますが、意外と技術 寄りの話は少なく雑談が多い。過去に、Perll開発者のラリー・ウォールや、Ruby開発者のまつもとゆきひろが出演していた。
ブラウザの仕様変更やフロントエンド系のフレームワークの最新動向などをキャッチアップして放送する番組で、そういう情報は基本的に英語なので日本語で話してくれると、とても 勉強になるのだが、話の内容が本格的すぎて気軽に聞ける番組ではない。
特定の技術の専門家を招き、深堀って専門的な話を聞してもらえる番組。これまた、えらく話が専門的で理解が難しいことが多い。最近、t_wadaさんがTDDの誤解について語っていて勉強になった。
Qiitaプロダクトマネージャーの方が、Qiitaに投稿している人をゲストに迎えて話を聞ける番組。ミノ駆動さんや、無職やめ太郎の話が聞けて興味深い。
LINEヤフーのフロントエンド チームが送る ポッドキャスト 番組で、フロントエンドの最前線の話が聞ける。インターン組のレベル高すぎて、それを聞いてるワイは死にそうになった。
「Androidを支える技術」を書いているkarino2さんが配信している番組。技術的な話や、プログラマーがどうあるべきかなどの心構え などを語っている。この番組が特徴的なのは、定期的にkarino2さんがほとんど1人で延々と喋って配信している点であり、ポッドキャスト番組の中には一人で喋っていることに限界を感じて ゲストを迎える 番組も多いのに珍しいと思う。なろう系について語り続ける場合もある。
おそらく、サイバーエージェント系の会社で一緒だった人たちが始めている番組で、 主に雑談や近況報告など。気軽に流し聞きできて良い。
スクラム道関西というコミュニティが運営しているアジャイルやスクラムについて話す番組です。アジャイルやスクラムの世界の話が聞ける。アジャイルやスクラムではない近況報告や雑談などのほうが多い気もする。
主にエンジニア的な組織論に関する話です。組織に関する抽象度の高い哲学的な話が多く、毎回、理解できるような、難しくて理解できないような気持ちに駆られる。
PHPにまつわる配信番組なのですが、最近更新されていないのが残念。
はてなの開発部もポッドキャストを公開してます。非常に淡々とした雰囲気。
安住紳一郎アナウンサーの番組も ポッドキャスター化されており いつか聞いてみたと思う
コミュニケーション力が上がりそうなので いつか聞いてみたいと思う
コンピューターサイエンス系の論文を紹介している番組らしいのでいつか聞いてみたいと思う
