Skip to content
←

필사 모드: 何が高いまま残るのか — 生成が安くなるとき値が上がる四つ

日本語
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

道具のリストで答えると、その答えはすぐ古びる

これから何を準備すべきかという問いに最もよく返ってくる答えは、学ぶものの一覧です。一覧は読みやすく、読みやすい分だけ早く古びます。五年前の一覧を今開けば、半分は名前ごと消えており、残りの半分は別のものに吸収されています。

一覧が古びるのは項目の選び方が悪いからではなく、軸の取り方が悪いからです。道具は軸になれません。道具は変数です。必要なのは、道具が入れ替わっても保たれる判別式です。

このシリーズが使う判別式は一つだけです。値が残る技術とは、検証が高いままの技術である。コードを書く仕事は安くなりましたが、そのコードが正しいかを判定する仕事と、そもそもそれを作る価値があったのかを判定する仕事は安くなっていません。これから九回で扱う能力はすべて、この一文から導かれます。

二軸で四つの枠を描くと見えるもの

一つの仕事を二つのコストに分けてみます。成果物を作るのにかかる生成コストと、その成果物が正しいかを確かめるのにかかる検証コストです。

検証が安い検証が高い
生成が安いすでに自動化され、値は残っていない今、多くの仕事が移った枠
生成が高い自動化が次に食べる枠今も人が残る枠

左上は形式変換、ボイラープレート、定型的な移行作業です。ここに実力を積んできた人は、すでに値が下がるのを経験しました。

左下が面白いところです。作るのは難しいが、当たったかどうかの判定は易しい仕事。答えの決まったアルゴリズム問題、コンパイル通過で分かれる変換、ベンチマークのある最適化がここにあります。採点規則が存在すれば試行錯誤を機械が代わりに回せるので、この枠は生成がどれだけ難しくても長くは持ちません。自動化の本当の条件は、問題が易しいことではなく、出力が採点できることです。

右下は作るのも難しく判定も難しい仕事です。十年もののシステムの移行経路を決めること、規制と契約と性能が同時にかかった設計を選ぶことがここにあります。

危ないのは右上の枠

最も注目すべきは右上です。作るのは安くなったのに判定は依然として高い枠で、今日のソフトウェア作業のかなりの部分がここへ引っ越しました。

この枠が危ないのは、成果物がもっともらしく見えるからです。間違いが目に見えて間違って見えるなら、コストは小さい。問題はほぼ正しい結果のほうです。Stack Overflowが2025年に公開した開発者調査では、AIツール利用時の最大の不満として「ほぼ正しいが、正確には正しくない解答」を挙げた回答が66パーセントでした。続いて45パーセントが、AIが生成したコードのデバッグに時間がかかると答えています。同じ調査で、ツールの正確性を信頼しないという回答は46パーセントで、信頼するという33パーセントを上回りました。

調査は体感の記録であって成果の測定ではありません。ですからこの数字を生産性の結論に移してはいけません。ただ一つだけははっきり読めます。ボトルネックが作る側から判定する側へ移ったと、使っている本人たちが自ら報告しているという事実です。

検証を高くするもの

では何が判定を高くするのか。おおむね四つです。

一つめは暗黙の文脈です。判定に必要な情報がコードにも文書にもなく、人の記憶と組織の慣行にしかないとき、その情報を持つ人だけが判定できます。

二つめは遅れて来る結果です。今は緑でも、半年後の運用で崩れる設計があります。結果が遅く来る仕事ほど、今それを判定するには経験から来る予測が要ります。

三つめは判定基準の不在です。ランキングの品質、インターフェースの良し悪し、モデル出力の適切さのように正解表がない領域では、判定そのものを設計しなければなりません。

四つめは責任の帰属です。誰かがこの決定に名前を掛けねばならず、署名は委譲できません。署名するには理解が要るので、責任は理解を強制する装置でもあります。

反転 — 高い検証を安くするのが仕事

ここまでで読み終えると結論が妙になります。検証が高いほど自分の値が上がるなら、検証を高いまま保つのが得だという話になるからです。それは誤りで、その地点でこの枠組みが実務とつながります。

エンジニアの仕事はちょうど逆です。高い判定を安い判定に変える装置を作ることです。人が毎回読まないと分からなかったことを型で釘づけにし、運用で半年後に現れていたことをリリース時点の指標へ前倒しし、正解表のなかった領域に代理指標と標本レビューの手順を立てます。

まとめるとこうなります。判定を実行する仕事は自動化され、判定を設計する仕事は残ります。良いテストを書くのは高く、そのテストを回すのはタダ、という構造と同じです。このシリーズで扱う能力はすべて、この設計の側にあります。

体感を根拠にしない

最後に一つ押さえておくことがあります。この領域で自分の体感は信頼できる根拠ではありません。

METRが2025年7月に公開した無作為化比較試験がそれをよく示しています。自分のオープンソースリポジトリに慣れた熟練開発者16名が246件の作業を行い、作業ごとにAIツール使用の可否が無作為に割り当てられました。結果は、ツール使用が許された作業のほうが19パーセント長くかかったというものでした。参加者は実験前に24パーセント速くなると予想し、実験後もなお20パーセント速くなったと信じていました。

この結果を一般化してはいけません。研究者自身が、標本が16名であること、参加者が自分のコードベースに非常に慣れていたこと、品質基準の厳しいリポジトリだったこと、ツールの習熟が進めば結果が変わりうることを明記しています。この試験が示すのは道具が悪いということではなく、速くなった感覚と実際に速くなったこととの間に、向きが逆の隔たりがありうるという事実です。

だからこのシリーズの助言はすべて、記録で確かめよという但し書きを付けて進みます。感覚は仮説であり、仮説は測るものです。

手を動かす

今週一つだけ選ぶならこれです。直近二週間にやった作業を十個ほど書き出し、それぞれを上の四つの枠のどれかに入れてみてください。入れ方に迷う作業があれば、それが最も重要な信号です。まだ判定の仕方を決めていない仕事だという意味だからです。

  • エンジニア スキルコース — Linux・ネットワーク・DB・Kubernetes・AI/LLMのトラックをユニット単位で進み、自分の位置を確認できます。
  • 思考力トレーニング — 初めて見る問題の前で使える九つの手を練習します。判定基準を立てる練習に最も近いものです。

この枠組みが合わない場合も書いておきます。利用者が少なく失敗コストの低い初期プロダクトでは、判定装置を先に敷いてプロダクトを出せないほうが損失が大きい。検証の設計は、賭けているものがあって初めて値が出ます。

続けて読む

高いまま残る技術シリーズ

参考資料

현재 단락 (1/36)

これから何を準備すべきかという問いに最もよく返ってくる答えは、学ぶものの一覧です。一覧は読みやすく、読みやすい分だけ早く古びます。五年前の一覧を今開けば、半分は名前ごと消えており、残りの半分は別のもの...

작성 글자: 0자원문 글자: 3,552자작성 단락: 0/36