委託時代③：Impact vs Activity――委託時代の職業方法論

AI に実行を渡せるようになると、人間の履歴には何が残るのか。

この問いは、少し怖いです。

コードを書いた量。チケットを閉じた数。会議に出た時間。資料を作った枚数。そういうものは、これまで仕事をしている証拠になっていました。

でも、AI が activity、つまり作業そのものを安くしていくと、作業量はだんだん価値の証明になりにくくなります。

では何が残るのか。

Kelsey Hightower のキャリアは、その答えを早くから実演していたように見えます。

14歳で McDonald’s で働き始め、15歳で店の鍵を預かる assistant manager になった。19歳で大学を離れ、35ドルの A+ 認定教材を買って技術職に入った。Google ではデータセンター技術者から始まり、最終的に Google Cloud の Distinguished Engineer になった。そして 43歳で、業界の頂点に近い場所から引退した。

この経歴を「努力家の成功物語」として読むこともできます。

でも、それだけでは少し浅い。

Hightower が一貫してやっていたのは、たくさん働くことではありません。

何が本当の成果なのかを、早く見抜くことです。

電話を取ることと、問題を消すことは違う

Pragmatic Engineer Podcast の対談で、Hightower はキャリア初期の経験をいくつも話しています。

その中に、Pier 1 のテクニカルサポート時代の話があります。

普通に考えれば、サポートの仕事は電話を取ることです。キューに入った電話を受け、目の前の相手に対応し、次の電話を取る。たくさん対応した人がよく働いた人に見えます。

でも、彼が気にしたのは電話の数ではありませんでした。

チケットが滞留していることでした。

電話を取るのは activity です。

チケットの山を消すのが impact です。

この違いは、AI 時代にそのまま戻ってきます。

AI は activity を増やすのが得意です。メールの下書きを作る。コードを書く。調査メモを並べる。議事録をまとめる。スライド案を出す。動いている感じはすぐ出ます。

でも、その activity が仕事の本体とは限りません。

顧客の不満が減ったのか。事故が減ったのか。売上が上がったのか。意思決定が速くなったのか。後工程が楽になったのか。

そこまで見ないと、ただ AI で作業量を増やしただけになります。

Hightower の強さは、若い頃からそこを混同しなかったことです。

仕事は、次の仕事の面接になっている

Hightower のキャリアには、偶然に見える跳躍が何度もあります。

Google のデータセンターで働いていた時、彼は与えられた作業だけをこなしていたわけではありません。機械の故障を見抜く精度を上げ、返ってくる修理を減らし、他の人より多く直せるようになった。本人の語りでは、転職や配置換えのたびに、およそ 25% ずつ報酬が上がっていったといいます。

Puppet への関わりもそうです。

夜や週末にオープンな場で貢献していたら、後にそれを見ていた人が現れ、次の機会につながる。

CoreOS との出会いも似ています。講演の中でデモをしていたら、その場に CoreOS の人たちがいた。本人は面接のつもりではない。でも、仕事は見られていた。

対談の最後で、聞き手の Gergely Orosz は、Hightower の「every job is an interview」という考え方を取り上げていました。

これは、きれいなキャリア格言ではありません。

activity ではなく impact を出している人だけに起きる現象です。

単に忙しくしている姿は、外から見えません。見えても伝わりません。

でも、問題を解いた成果は残ります。ドキュメントとして残る。OSS の貢献として残る。講演として残る。誰かの記憶に残る。

AI 時代には、ここがもっと露骨になります。

作業そのものは誰でも増やせる。AI を使えば、たくさん書ける。たくさん試せる。たくさん投稿できる。

だからこそ、「何を変えたか」が残る。

コードを書くことは、仕事の最後の一歩にすぎない

Hightower の AI への見方は、冷めています。

彼は GenAI の否定派ではありません。むしろ、道具としては現実的に使います。ただし、投資先や相談相手には、最初の説明で「AI」と言わないよう求めることがあるそうです。

なぜか。

AI という言葉を使うと、価値の説明が曇るからです。

何の問題を解いているのか。今その業界ではどう処理されているのか。どこに痛みがあるのか。新しい技術で、何が本当に良くなるのか。

そこを説明できないまま「AI です」と言っても、impact にはなりません。

これはソフトウェアエンジニアにも刺さる話です。

対談の後半で、彼は「ソフトウェア開発者の仕事はコードを書くことだけだったのか」と問い直します。コード生成が安くなると、不安になる人がいる。なぜなら、自分の仕事を「組織で唯一コードを書ける人」だと思っていたからです。

でも、ソフトウェア開発にはもともと、もっと多くの判断がありました。

どのデータベースを使うのか。

どのスキーマにするのか。

本当に社会保障番号のような情報を集めてよいのか。

この機能は作れるとして、作るべきなのか。

Hightower は、コードを書くことは最後のステップだ、という趣旨を話しています。

この感覚は、委託時代の中心にあります。

AI はコードを書けます。これからもっと速く、もっと広く書けるようになります。

でも、何を作るべきか、どこで止めるべきか、どの設計なら後で壊れないか、どの速度なら事故らないかは、まだ人間の判断です。

むしろ、AI が速くなるほど、その判断は重くなります。

速さだけでは、危ない

Hightower はセキュリティの例でも、速さの危うさを話しています。

攻撃者は、相手を急がせます。飛行機に乗る直前、CEO からのように見えるメッセージが来る。今すぐ送金しなければならない、と言われる。文面も、相手の事情も、関係性も合っている。そこで急ぐと、間違える。

賢くないから騙されるのではありません。

速すぎるから間違える。

これは AI コーディングにも当てはまります。

AI が一瞬でコードを出す。動いているように見える。では、そのまま出してよいのか。

保険会社が、保険料を見積もる機能を持っているとします。AI を使えば、決済機能も、配送アプリのようなものも、作れるかもしれません。

でも、作れることと、作るべきことは違います。

Hightower は、コードを書いている時間には、考える時間も含まれていたと見ています。書きながら、データ構造の悪さに気づく。後工程のレポートが壊れると分かる。設計を上から変える必要に気づく。

AI がその時間を圧縮すると、考える間もなく進めてしまう危険があります。

だから、委託時代のエンジニアに必要なのは、AI より速く手を動かすことではありません。

AI が速く出したものを、どこで止めるかです。

20年の経験か、1年の経験を20回か

Hightower の話で一番厳しいのは、経験年数への見方です。

長く働いていることは、それだけでは価値になりません。

20年の経験に見えて、実は 1年目の経験を 20回繰り返しているだけ、ということがある。

この言い方は、日本の職場にも刺さります。

年数は数えやすい。勤続年数、在席時間、担当年数、プロジェクト数。どれも評価しやすい。

でも、AI が activity を安くすると、年数の中身が見えます。

新しい状況で判断してきたのか。

失敗からモデルを更新してきたのか。

自分の職務の外側まで理解を広げてきたのか。

顧客、設計、運用、販売、セキュリティの間をつなげるようになったのか。

それとも、同じ作業を繰り返してきただけなのか。

AI はこの差を隠してくれません。

むしろ、作業量という覆いをはがします。

Freedom tokens という考え方

Hightower のキャリアには、お金の扱い方も一貫しています。

対談のまとめでは、彼が money を freedom tokens と見ていたことが紹介されていました。収入が上がっても生活水準を連動させすぎず、働かない選択肢を持てる状態を作る。

これは単なる節約術ではありません。

判断力を守るための土台です。

生活が報酬に完全に縛られると、人は嫌な仕事でも受けるしかなくなります。会社の評価に合わせるしかなくなる。自分が activity に閉じ込められていると分かっていても、そこから出にくくなります。

Hightower は、43歳で引退しました。

もちろん、誰もが同じことをできるわけではありません。アメリカのトップエンジニアの報酬、Google での立場、運もある。

それでも、考え方としては参考になります。

自由は、急に来るものではありません。

早い段階から、どの仕事に自分を縛らせるかを選ぶことです。

Kubernetes が勝った理由も、impact の話だった

Hightower といえば、Kubernetes の語り手としても有名です。

対談では、Kubernetes が広がった理由として、Docker の存在、コミュニティ、ドキュメントなどが語られていました。とくに Docker によって、Java か Python か Ruby かという争いではなく、コンテナをどうスケジュールするかという話に絞れたことが大きかった、という整理です。

ここにも同じ構図があります。

Kubernetes の価値は、単にたくさんの YAML を書けることではありません。

開発者と運用者が、同じ単位でアプリケーションを扱えるようにしたことです。インフラの細部を全部手で命令するのではなく、望む状態を宣言し、システムに近づけさせる。

つまり、activity を減らし、impact に集中させる設計でした。

AI エージェントも同じ方向に進んでいます。

細かい実行を渡し、何を実現したいかを宣言する。

その時、人間に残るのは、より上位の判断です。

日本の「在席時間」は危ない

日本の読者に引き寄せるなら、年功序列や在席時間の文化は、activity 評価の極端な形です。

長くいる。遅くまでいる。会議に出る。手戻りにも付き合う。忙しそうにしている。

それが悪いと言いたいわけではありません。現場を支える仕事には、目に見えない負担がたくさんあります。

ただ、AI が activity を増幅する時代には、「忙しい」はますます当てにならなくなります。

AI を使えば、忙しそうな成果物はいくらでも作れます。

長い議事録。厚い資料。大量の比較表。たくさんのコード。たくさんの案。

でも、組織に必要なのは、その量ではありません。

どの案を捨てるか。

どの顧客の痛みを先に解くか。

どの設計を選ぶか。

どこで止まるか。

どの間違いを許さないか。

Hightower のキャリアは、委託時代のエンジニアにとって、きれいな成功談というより警告です。

AI に渡せるものは増えます。

だから、人間の価値は「たくさんやった」では残りません。

何を変えたか。

なぜそれを選んだか。

その判断を、次の状況でも使える形にできるか。

activity が安くなるほど、impact だけが目立つ。

次回は、その impact をさらに奥まで見ます。

判断力は価値であるだけでなく、外に渡してはいけない最後の線でもあります。Tony Fadell の話は、その境界をはっきり示しています。