ドメイン専門性は常に本当の堀だった
(brethorsting.com)- ソフトウェアの難しさはコード入力そのものより、給与・交通のような現実のルールを理解してドメインモデルを作ることにあり、コードはその理解の産物だった
- エージェント型AIは、ドメイン理解がなくてもソフトウェアを生産できるようにし、ボトルネックを「作れるか」から「正しいと判断できるか」へ移した
- 物流の配車担当者、臨床コーダー、保険数理人のようなドメイン専門家は、コードを知らなくても出力が法規・請求・運用ルールに合っているかを判定できる
- 汎用エンジニアはアーキテクチャや信頼性を検証できるが、臨床コーディングのように正解がドメイン知識に結びついた領域では、もっともらしい誤りを見逃すことがある
- 最も価値ある能力は、生成されたコードの健全性と出力の真実性をあわせて検証する判断であり、熟練エンジニアにとってはドメイン専門性への投資がより重要になる
ソフトウェアのボトルネックは実装から検証へ移る
- ソフトウェア作成で難しいのはコード入力自体ではなく、まず頭の中にドメインモデルを作ることだった
- 給与システムには差押え、税引前控除、給与期間が賃金変更の時点にまたがる場合の処理が含まれる
- 交通アプリにはGTFSフィード、tripとrouteの違い、「定時」のバスがそれでもなお不正確でありうる理由が反映される
- コードはこうした理解を書き写した結果であり、理解を獲得することこそが実際の仕事だった
- エージェント型AIはドメイン理解とソフトウェア生産のあいだの結びつきを弱める
- 今ではドメインモデルを自分で直接作らなくてもソフトウェアを生産できる
- ソフトウェア職全体が依存してきた前提が揺らいでいる
- 昨年の見方のように、こうしたツールが判断力のあるシニア開発者を増幅するという説明は正しいが、それだけでは十分ではない
- さらに具体的な変化は、ボトルネックが「作れるか」から「正しいと判断できるか」へ移ったことにある
エージェント型ツールをうまく使う人
-
ドメイン専門家はコードを知らなくても正解を判定できる
- 物流の配車担当者、臨床コーダー、保険数理人のような人は、スタックトレースを読めず、hash mapとlistの違いを説明できないかもしれない
- それでもエージェントが作ったスケジュールを見れば、どの運転手が法的にそのシフトに入れないかを即座に見抜ける
- 特定のコード組み合わせによる保険請求が支払われないことも分かる
- 彼らは入力と出力の中で10年を過ごしてきたため、与えられた入力に対する正しい出力を知っている
- エージェントが彼らに提供するのは不足していたコード生産能力であり、彼らが持ち込むのはエージェントにない**正解の基準(ground truth)**である
-
汎用エンジニアは、よく作られたソフトウェアと正しいソフトウェアを区別できないことがある
- 優秀な汎用エンジニアは、アーキテクチャ、信頼性、テスト、午前2時にシステムが崩壊しないようにする方法を知っている
- しかし臨床コーディングのようなドメインでは、もっともらしいが誤った答えと正しい答えを見分けられないことがある
- エージェントはコンパイルが通り、エンジニアが考えたテストにも合格する一方で、微妙で高コストな請求ルールの誤りを生み出すことがある
- エンジニアはソフトウェアがうまく作られているかは検証できても、正しさが全面的に自分の頭の中にないドメインによって定義される場合、正確性を検証するのは難しい
-
エージェント以前には、エンジニアに有利な学習経路があった
- エンジニアは専門家について回り、仕様を読み、運用環境で失敗しながら、ゆっくりとドメインを学べた
- 多くの分野で、この過程はキャリアラダーの中核だった
- ドメイン専門家には対称となる経路がなかった
- 信頼できるソフトウェアの作り方を学ぶには何年もかかり、彼らにとって現実には歩みにくい道だった
-
エージェント型ツールは片側の経路だけを崩した
- エンジニアの強みだった、ドメインモデルを動くコードへ翻訳する能力は安価になった
- ドメイン専門家の強みである、何が正しいかを知る能力は安価になっていない
- プロンプトだけでこの能力を得ることはできず、何千回もの給与計算を正しく処理してきた人の暗黙知を収めたskill fileも存在しない
-
最も価値ある人は二層の両方で検証できる人である
- 生成されたコードが健全かを知り、そのコードが出す答えが真であることも分かる人が最も重要になる
- 「運転手は11時間を超えて働けない」というテストを書けるのは、そのルールを知っているからだ
- そのテスト自体に意味があるかを判断できるのも、何をテストしているのかを理解しているからだ
- エージェントは書き起こしを担い、人間はコードとドメインという二つの層で判断する
- 熟練エンジニアにとって重要な投資は、実際のドメインに関する深く検証されたモデルを得ることだ
- 明確なアイデアをきれいなコードへ変換する機械的な能力の価値は大きく下がった
- なお希少なのは、実際の業界、ツール、規制体系、物理的プロセスに対する深い理解である
- プログラミング言語やフレームワークを学んだのと同じように、一つのドメインを選んで学ぶべきだ
- エージェントが代替できず、今もっとも価値が高まっている部分こそがドメイン専門性である
厳選された技術トピックを続けて受け取りたいですか？
Telegramチャンネルをフォローしてください。 @GeekNewsJP
1件のコメント
Hacker News のコメント
個人レベルでAIをどう使うべきかを誰も分かっていない、ということを認めるまでに、あとどれだけ長広舌が必要なのか分からない
最初は優れた開発者で、なおかつAIの使い方を学べば十分だと言い、次はアーキテクチャ設計能力だと言い、その次はセンスがすべてを分けると言い、今ではドメイン専門家だけが重要だと言っている
AIの改善または停滞が安定的で予測可能な状態になるまでは、こうした解釈は今後も無意味で、たいていは間違っている可能性が高い
できることの基準を大きく引き上げるので、結果として難しくなる。個人開発者がはるかに難しいプロジェクトを引き受けられるようになり、結局のところ制約は常に時間であり、AIは与えられた時間の中でより多くのことをできるようにしてくれる
しかし、その時間内に達成できること自体がはるかに難しくなった。理解しなければならないことはずっと増え、AI以前の慣れた安全地帯の外へ大きく踏み出さなければならない
以前なら、不慣れなシステム領域だったり新しいライブラリを学ぶ必要があったりして、コードベースのリファクタリングや小さな機能のリリース準備に数日かけるのは受け入れられていた
コーディングエージェントのおかげで、その学習曲線をずっと速く登れるようにはなったが、それでも自分で登らなければならない。そして入ってくる情報量ははるかに多い
非技術系のバイブコーダーに仕事を奪われるのではと心配しているなら、正しい対応は、彼らよりずっと良いソフトウェアを作ることだ。そのためには、より高いスキル、より大きな野心、より多くの経験が必要で、簡単ではない
これまでで最もしっくりきた比喩は、現代の電動ドリルドライバーと、ドライバーや手回しドリルのような旧式の道具との比較だ
旧式の道具に比べれば、非常に短い時間で驚くような結果を出せる
例えば「一日がかりの床の固定を1時間で終えて、その合間に何度もタバコまで吸えた」みたいな驚きの逸話があり得る。ネイルガンを使っていれば半分の時間で終わっていたかもしれないが、後でその床を簡単に剥がすのは難しく、費用も2倍くらいかかっていたかもしれない
オンプレミスのLLMも複数使っていて、ほかのモデルにもアクセスできるので、いつかはこの比喩をブランドの違いにまで広げることになりそうだ
ただ、それで新しい仕事を探すことになるとは思わない。電動ドリルドライバーは大工や現場作業員ではなく、人がいなければ役に立たない
20年後にはClaudeとの共作ゴミを片付けているだろうと思う
https://mastodon.gamedev.place/@JeremiahFieldhaven/116654345...
2018年に、コーディング経験がまったくなかった人が、特定のニッチ市場を知っていたという理由だけで、1か月コーディングして、かなり良いお金を生むツールを作るのを見た
コードの一部を見せてもらったが、私の最初のプログラムと同じくらいひどかった。それでも現実の問題を解決していた
例えば「スポーツがうまくなるには完全な左右対称性が必要で、これは胎児期の発達の安定性と強く相関する。対称性が高いほど完全な発達だ」と言う
その後数年して、Bruce Leeは片脚がもう片方よりかなり短く、Usain Boltにも同様の非対称な発達がある、という話が出てくる
すると彼らは例外事例だと言って、最初の主張をひっくり返しながら一般則は影響を受けないと取り繕う
ただ面白いものを作ればよくて、うまくいくかもしれない
最近、バイブコーディングでほぼ作られたアプリをレビューした。所有者は、ほぼリリース準備が整っており、簡単なチェックだけ必要だと言っていた
見てみると、データベース設計がめちゃくちゃだった。動く機能もあれば、動かない機能もあった。欠けている部分と、なぜ壊れるのかを説明した。元の記事のように、その人はドメイン専門家だった
先月だけで数十億トークンを使っており、ツールは急速に良くなっている。しかし、ドメイン専門家にAIを与えたからといって、ソフトウェアエンジニアが不要になるわけではない
ドメイン専門家はAIでソフトウェアを作れるし、ソフトウェアエンジニアはAIでドメインを学べる。両者は異なる専門性を持ち込む
ドメイン専門家たちがコーディングエージェントを使い始めるときに、安全に守るためのガードレール、検証、プロンプトライブラリ、エージェントと手動レビューを作る仕事になる
社内向けのT2/T3カスタマーサポートやサポートエンジニアに少し似ている。日常的な問題を100%自分で解決するというより、危険なポイントや奇妙なエッジケースを捕まえ、設定がすべて正しいことを確認する役割だ
もちろん、横断的な関心事も多く扱うことになる
ただし、新しいアイデアを素早く試し、深掘りするためのツールとしては素晴らしい。好奇心があるなら、優れた学習加速器にもなり得る
一日中Claude Code(Opus 4.6、最大努力設定)を使っていても、どうすればそうなるのか分からない。その使用量が本当に見返りを生んでいるのかも気になる
私がよく分かっていないだけかもしれないが、本当にどうやってそうなるのか分からない
最近経験したとても良い例がある
釣り旅行の最中で、私が取り組んでいる無料アプリ(https://oceanconnect.ca)が仕事の助けになるかもしれないので、船長に一度見てみる気があるかと尋ねた
私は海で人々が海洋データをどう使うのかをよく知らない。何を知りたがっているのか、なぜそうなのかもよく分からない。人々がデータをどう使うのか、私たちがそのデータで何ができるのかについての質問や情報が次々と出てきて、まったく準備ができていなかったし、その視点を得られたのは本当に素晴らしく興味深かった
モデルはそれが抽象化しているシステムそのものではなく、モデルを開発する知識は、それを使う知識とはほとんど関係がないのだと改めて思い出させられた
この人は水上で気象データをどう使うかについて膨大な知識を持っていた。ある意味では私よりもデータをよく知っていて、本人がそれに気づいていなかったりデジタル表現を理解していなかったりしても、もしプログラミングさえできれば、自分のような人たちのための有用なアプリをはるかに上手く作れそうだった
こういう人たちがLLMを前にしてアイデアを画面に落とし込めるなら、本当にすごいものを作れるだろうと思った。いつか資金ができたら、毎日海に出る人たちにインタビューして製品を磨き込みたい。そのドメイン知識は非常に特殊で、複雑なドメインで何十年も生きてきた人たちは、絶対に予想できないことを知っている
この記事で描かれているソフトウェア・ジェネラリストにもドメイン専門性はある。そのドメインはソフトウェアだ
今、優れたジェネラリストのソフトウェアエンジニアなら、AIを避けるために何か無作為な別のドメインへ飛び込んだりはしない。ソフトウェアが自分のドメインであり、そのドメインが拡張され変形していく間も、引き続きその中にとどまることになる
おそらく良い知らせは、西部で最高のスプレッドシート職人の会計士であっても、検証を行うには結局ある程度のプログラミング経験が必要だという点だ
LLMに「このコードは何をしていて、Yのとき常にXになるのか」と尋ねることはできるが、それは検証問題を別の検証問題の中に入れ子にしているだけだ
本質はそもそもコードではなかった
この5年間、ベンチャーキャピタルとプライベートエクイティ向けのソフトウェアを作ってきたが、この記事は本当に刺さった。コードを書くことは私の仕事の中で断然いちばん簡単な部分で、企業顧客が実際に必要としているものを理解するための金融工学と繊細な文脈のほうが難しい部分だ
私たちは、できるならシニアのファンド会計士を雇ってプログラミングを教えたいと冗談を言っていた。問題は、そういう人がほとんどいないことだ。エンジニアにファンド会計の細部を、ソフトウェアに落とし込めるほど理解させるのも難しい
実際、私のキャリアの半分くらいは、「チケットやエピックを閉じるだけのドメイン知識はあったが、結局多くの技術的負債を残した」ものの後始末だった
たとえばドメイン知識があっても人はミスをするし、より良い方法を知らないし、フィードバックを反映しなかったり、さらに悪いことにコーディングエージェントが書いた内容を再確認しなかったりするので、PRは非常に注意深くレビューしなければならなかった
「技術的には正しいが、あまりにひどく書かれていてタイムアウトしたり、マネージャーやDBAに怒鳴られたりするもの」をリファクタリングすることも多かった
本当に優れたソフトウェアエンジニアには、ドメインを学ぶ能力と意志があるが、学べる方法が用意されていなければならない。会社やチーム、同僚がそれを可能にしてくれた場所もあれば、口では重要だと言いながら、結局JIRAや会議中に非IT部門の人が漏らす話から推測するしかない場所もあった
この5年ほどの大きなパラダイムシフトは、ほとんどの会社が人に限界まで働くことを期待し、そのせいで重要な会話をする余裕をむしろ奪って逆効果になっている点だと思う
文化が大きな変数だ。少なくとも隣で短く話したり会議を気軽に設定できたりする場所もあれば、きちんと議論する時間を求めるにはchange.orgに請願でも出さなければならないのではと思うような場所もあった
それでも核心は正しい。結局、要件はコードより重要だ。すべての要件が満たされ、チームが設計判断を承認したにもかかわらず、実装中ずっと席を外していた人が戻ってきて、書き方が気に入らないという理由だけで機能が遅延した場所もあった
そうしているうちに、いつの間にか「バッチプロセス」が %numberOfRecord%*10 件の挿入を実行し、誤って設計されたデータモデルのせいで追加の問い合わせまで行い、しかも最悪のやり方でSQLアップサートをしていることに気づく。つまり、まずDBから取得し、存在しなければ挿入するレコードを追加する、という形だ。それでもデータ層のクエリパターンを見直すのではなく、「パフォーマンス改善」の名のもとに、ますます怪しいことを続けていく。キャリアの中で一度以上見たことがある
AI対応の助言のように見える非常に一般的な文章を読むたびに、ソフトウェア業界は建設業界に似ていると思い出す
決して整然とはせず、完全に最適化されることもなく、常にカスタムであるほかない。好み、文脈、地域性が極端に異なる現実に合わせなければならないからだ
ときどき良いツールや原材料が現れることはある
ソフトウェアの本当の堀は、システムとドメインの両方について広範な知識や経験を実質的に要求しないことにある、と考えていた
センスとネットワーク効果を複製するほうがはるかに難しい。実際、バイブコーディング以前であっても、人材と資源が豊富なベンチャー投資のスタートアップが市場で地位を築くことはまれだった
だから20代の人でも複数分野の専門家と競争できた。今の反発は、他の成熟産業でよく見られる「業界経験X年」の人たちが生まれてきたことによるものだと思う
アナリストとして働いており、私たちのグループでは、強い技術力、つまりソフトウェアエンジニアリング能力を持つアナリストが約20%で、残りは従来型のアナリストやドメイン専門家だ
この1年で、非技術系アナリストが開発部分にAIモデルを活用し、社内ツール開発の生産性が上がるのを見てきた
以前はほぼすべてがTableauで開発されていた。開発者ではない人が動くツールを作るための、最もアクセスしやすい方法だったからだ
数日前にも、私たちのグループのあるアナリストが作業中のツールを発表したが、基本的にはTableauレポートをより柔軟なアプリに移植したものだった
こうしたBI企業は大きな苦境に陥ると思う。特に、ヒストグラムのような単純なものですらほとんど描けないようにしているTableauのような会社はなおさらだと思う
私の友人は電気工学者で、最近 FIDEチェスレーティング 2000 を超えた。30年間チェスを指していて、高校時代にはチェスクラブも作った。大学ではマイクロコントローラを扱う中で、少しプログラミングを学んだ程度だ
私はコンピュータサイエンスの学位を持つインフラ／運用寄りの何でも屋に近く、30年間趣味でプログラミングをしてきた。Lichessのレーティングは、調子のいい日でも1000だ
私たちはチェスボット大会をやってみた。オープンブックで、AIでプログラミングしてもよく、オープニングブックやエンドゲームテーブルなど何でも持ち込み可の自由対決だった。私は彼を完全に圧倒したが、実際の盤上チェスでは20年間で2回しか勝ったことがない
彼は現実の対局なら無作為なプレイヤーの99%に勝つだろうし、私はたぶん20%くらいにしか勝てない
自分が正確に何を言おうとしているのかは分からないが、今ではドメイン知識がすべてではないのかもしれない、という気がしている。あるいは、ドメインそのものが変わったのかもしれない
君は彼にプログラミング勝負を挑んだのであって、はるかに経験豊富なプログラマである君が勝ったということだ。AIが使えたとしても、この場合は君のドメイン知識が決定的だったと見る