初級ソフトウェアエンジニア

論文の付録では、システムソフトウェア開発者は最高曝露五分位のなかで就業者数の第7位にあり、ソフトウェア開発は著者が事例研究として取り上げた二職種の一つである。データは ADP の米国民間部門の給与記録で、数百万人分、2022年11月から2026年6月まで。11%の減少は最高曝露の二つの五分位における22-25歳のもので、同じ年齢層でも最低曝露の三つの五分位では約10%増えている。経験のある層には同様の差が見られず、著者は経済全体に広がる置き換えの証拠は見つからなかったと明言している。分析は記述的であって因果的ではなく、業務(タスク)単位ではなく職業単位で測られている。

採用、人員、労働時間、職務範囲の、検証できる変化。最も重い——ただし因果の帰属は、前提とするのではなく論じられなければならない。

法的義務にもとづく一斉調査である。報告するすべての機関に同じ20問が出され、各問にYかNで答え、製品名とライセンス数の規模を書く。「AIによるコード生成」は45機関中31機関がYで、挙げられた製品はどれも三年前には存在しなかったものだ。Yは雇用主がそのツールを持っていると報告しているのであって、ツールがどれだけのコードを書き、そのうちどれだけが残るかを測ったものではない。ライセンス数の規模も、それでコードを書いている人の数ではない。設問は経験十年のエンジニアと十か月のエンジニアを区別していない。この記録がここに付くのは、定型的なコード——CRUDのエンドポイント、フォーム、標準的な連携、既知のパターンのテスト——を書くことがまさにこのタスクだからであり、調査がジュニア開発者について何か言っているからではない。

雇用主がそれを本番に置いた。基準線を動かしうる——規模と、その場がどれだけ似ているかで重みづけされる。

内務省のソフトウェアチームを拘束するエンジニアリング標準である。チームは役に立つところでAIを使うべきだとし、AIの支援を受けた出力は本番に届く前に人がレビューし承認しなければならず、追跡できなければならないとし、そしてAIの道具はシステムに加えられる決定、設計、変更についての人の判断、理解、オーナーシップ、責任を置き換えられないので、AIの支援を受けたすべてのコードと出力について、チームが全面的に説明責任を負い続けるとしている。はっきりした「must」が掛かっているのは人によるレビューであり、設計についての一文は説明責任の表明である。拘束するのは一つの政府省庁のエンジニアだけである。

失敗、撤回、規制、あるいは費用が導入を抑えている。判断を下げる、あるいはその不確かさを広げることがある。

あるITコンサルティング会社の一つのプロジェクトで、言語モデルに要件仕様書を起草させた大学の研究であり、評価したのはその会社の熟練アナリストである。一部のユーザーストーリーは、どのモデルでも扱われないままだった。アナリストが持つ知識は暗黙のものでありうるし、要件を引き出すための文書には書かれていないからである。アナリストは起草時間の削減を10%から15%と見積もり、著者たちは、モデルは初期の文書作りを助けられるが、人の関与を置き換えることはできないと結論づけている。一つのプロジェクトと一人の専門家であり、調べられた役割は開発者ではなく要件アナリストである。

実際の場での小規模な試行。導入の条件が試されていることを教えてくれるのであって、それが成り立つことを教えてくれるのではない——だから一件の試行は単独では決して足りず、独立した二件で足りる。

大手技術企業一社の、自社申告の数字であり、「生成された」の測り方(補完なのか関数まるごとなのか)の定義はない。採用については何も語っていない。レビューの段はエンジニアの手に残った。

雇用主がそれを本番に置いた。基準線を動かしうる——規模と、その場がどれだけ似ているかで重みづけされる。

Google のエンジニアが自社の社内ツールを説明したものである。Google は全開発者の50%を無作為に割り当てて、IDE のなかで壊れたビルドへの ML による修正の提案を受け取らせ、11週間にわたって残りの開発者と比べた。その後、ある月にビルドの破損を経験した利用者の約34%がそうした修正を適用し、ML によるビルド修復は Google の全開発者に対して有効にされた。開発者はそれぞれの修正を事前に確かめ、受け入れるか退けるかを選ぶ。これらはビルドとコンパイルのエラー——投稿自身がよく理解されていると呼ぶ種類のもの——であって、原因が症状から遠く離れた実行時の障害ではない。Google は開発者向けのAIツールを売っている。

雇用主がそれを本番に置いた。基準線を動かしうる——規模と、その場がどれだけ似ているかで重みづけされる。

この職業は、最初の一群のなかで入口と上級の落差が最も鋭い。若手の職を経済的に成り立たせていた業務こそが自動化されつつあり、上級の仕事を定義している業務のほうは自動化されていない。危ないのはプログラミングが職業でなくなることではなく、梯子の上のほうはそのままに、一番下の段が外されつつあることである。具体的に言えば——量ではなく判断を示す必要があり、しかも普通ならまだ求められない時期にそれを示す必要がある。

あなたの位置は比較的強い。ただしそれは、判断力を遅い道のりで身につけた人が供給され続けることに依存している。入口の段が壊れたままなら、数年後にやってくる制約は自動化ではなく、ツールの出力をレビューできるだけの経験を誰も積んでいない、ということになる。あとになってからではなく今、採用と育成の問題として考える価値がある。

留まって強くする

梯子が期待するより速く判断力をつくる

希少なのは、生成されたコードが正しいかどうかを言える人である。二年待たなくても、初日から示しはじめられる。

職の形を組み替える

間違いが高くつく領域で深くなる

決済、セキュリティ、データ整合性、インフラ——自信たっぷりの誤答が実際のお金を失わせる領域では、人が輪のなかにしっかり残る。

隣へ移る

エンジニアリングと問題のあいだに立つ職

ソリューションエンジニアリング、開発者体験、技術寄りのプロダクト——系のしくみと、誰かがそこに何を求めているかの両方を分かっていることが価値になる職である。

業種をまたぐ

ソフトウェア以外の領域にエンジニアリングの考え方を持ち込む

その分野を分かっていて、しかも作れる人が、ほとんどいない業種は多い。この組み合わせは希少で、生成と競合しない。

学ぶべきである。ただし五年前とは理由が違う。かつてプログラミングを学ぶことは、コードを産み出せるようになることだった。いま価値があるのはコードを判断できることであり、自分に書けなかったコードは判断できない。訓練としては今も効く。変わったのは、その判断力を身につけているあいだ給料を払ってくれる入口の求人が、もう当てにならないという点である。最初の職が教えてくれると当て込むのではなく、その空白を明示的に見込んでおくこと。

その職が存在していた経済的な理由——仕様のはっきりした仕事を安く大量にこなすこと——は弱まっており、それは景気の波ではなく構造の変化である。とはいえ、若手の採用をやめてしまったチームは自分で自分の問題をつくる。数年後、出力を苦労して判断できるようになった人が誰もいなくなるからである。この職は、生産ではなくレビューと判断を軸に定義し直され、チームあたりの人数は以前より減る、と見ておくのがよい。

入口のエンジニアにとっての信号はモデルの能力ではなく、勤め先の新卒採用である。今年の若手採用数を二年前と比べてみること。若手の採用枠を削った組織のいくつかは、上級者を生み出す道そのものを取り払ったと公に述べている——その表明こそが追う価値のある出来事である。

定型的なコードを書くこと——自動化と印をつけた業務であり、かつて若手の最初の二年を埋めていた仕事である。システム設計と要件は危うくないが、それはその二年を経た先にあるものであり、その道に代わるものは現れていない。

学ぶ意味はある。ただし理由が変わった——いまプログラミングを学ぶのは、コードを産み出すためではなく、コードをレビューするためである。流暢なのに間違っている出力をきちんとレビューするには、同じものを自分で書いたことが要る。つまり出力の市場が縮んだあとも、学びのほうは相変わらず遅い道を通らなければならない。