職場で生産的に見せること
(nooneshappy.com)- 生成AIは、訓練を受けていない人でも別の専門領域の成果物を作れる領域横断生成を可能にし、初心者が結果をレビューする判断力なしに生産性を高めたように見せてしまう
- 職場では、コード、データシステム、文書のように見た目には進捗に見える成果物が増える一方で、利用者が実際の動作を説明できなかったり、初期のスキーマと目標の段階から誤っていたりすることが起きる
- AIは、成果物の品質が生産者の能力を示していた関係を断ち切り、成果物と能力の分離を生み出し、利用者を結果を評価できないまま受け渡す導管に近い存在にしてしまう
- 社内文書や更新は生成コストの低下で長文化するが、読むコストは下がらないため、組織内でシグナルを見つけることがいっそう難しくなり、給与を受け取る人が作る新しい形のAIスロップになる
- 生成AIは、人が最終判断者として残り、素早いフィードバックが可能な下書き、例示、要約、ブレインストーミング、校正に向いており、信頼できる仕事を提供する能力は依然として企業の競争優位であり続ける
職務上の生産性に見えるAI成果物の問題
- 生成AIは、専門性がなくても専門的な成果物のように見える結果を作り出せるが、失敗は二つの形で現れる
- ある分野の初心者が、自分の判断力よりも速く、あるいはより高度に見える結果を作る場合
- その分野の訓練を受けたことのない人が、別の専門領域の成果物を作る場合
- 既存研究は主に前者を測定してきたが、より危険なのは、訓練を受けていない人が別分野の成果物を作り出す領域横断生成である
- 公開チャンネルで、同僚がClaudeによると思われる回答をそのまま貼り付け、実際には理解していない技術を自信ありげに扱っているように見えることが起きている
- この状況では、相手は実際に会話の向こう側にいるというより、モデルの出力を転送する存在として機能している
領域横断生成
- コードを書けない人がソフトウェアを作り、データシステムを設計したことのない人がデータシステムを設計することが起きている
- その大半はリリースされないが、社内で熱心に共有されたり、ひっそり使われたりし、ときには顧客の目に触れる
- 現在のエージェント型ツールで複雑な仕事をきちんとこなす実務者もいるが、それは稀で、主にコード生成領域で見られる
- 個人レベルでのAI活用能力は伸びたが、実務の現場ではうまくスケールしていない
- ある非エンジニア職の同僚は、今年初めの2か月間で、本来なら正式なデータアーキテクチャ訓練を受けた人が設計すべきシステムを構築した
- 彼は現在のAIツール活用評価基準に照らせば、ツールをうまく使い、多くのコードや文書、見た目には進捗に見える成果物を生み出した
- しかし質問されると、実際の動作を説明できなかった
- スキーマと目標は初日から誤っており、その分野で2年の経験がある人なら気づけるレベルのミスだった
- 複数の人がそれを把握し、V.P.レベルまで報告されていたが、管理者はすでに推進力の外観に投資しており、それを揺るがしたがらなかった
- このツールは彼をより悪い同僚にしたのではなく、訓練を受けていない分野を数か月にわたってもっともらしく真似できるようにした
- 組織のインセンティブは、その真似を継続させる方向に傾く
- これは管理の失敗かもしれないが、AIを受け入れようとする管理層の意思が、リスク受容を促している
- モデルが成果物について正直に評価してくれれば緩和できるかもしれないが、実際にはそうではない
- ChengらによるStanfordの研究 Sycophantic AI decreases prosocial intentions and promotes dependence は、主要モデルが人間の回答者より約50%同調的で、根拠がない場合でも利用者を肯定することを示している
- Berkeley CMRの Seven Myths About AI and Productivity: What the Evidence Really Says によれば、AI活用スキルのある利用者でも、自分の成果を過大評価することが多い
- NBERの Generative AI at Work によれば、生成AIはサポート担当者のうち初心者の生産性を約3分の1高めた一方で、熟練者にはほとんど役立たなかった
- Harvard Business Schoolの Navigating the Jagged Technological Frontier も、コンサルティング業務で同じパターンを確認している
- 結果として、初心者は自分の専門外の領域で個人の生産性を高められる一方、その成果物が正しいかレビューする能力は不足したままになる
導管の問題
- この現象は次第に成果物と能力の分離(output-competence decoupling) と呼ばれるようになっている
- 以前は、成果物の品質はおおむね生産者の能力を示すシグナルだった
- 初心者の文章は初心者らしく読めたし、初心者のコードは初心者らしい形で失敗した
- AIはこの関係を断ち切り、初心者でももはや初心者だと露呈しない成果物を作れるようにした
- 成果物が反映している能力は、利用者の能力ではなくシステムの能力である
- 利用者は結果を受け手に渡すことはできても、その受け渡しの途中で評価できない導管に近くなる
- 成果物を作る能力と判断する能力はもともと別だったが、実際に作業を行う過程が判断力を育てていた
- 成果物を作る第一の能力は、かなりの部分が機械に移った
- 判断する第二の能力は依然として人間に残っているが、それを学ぼうとする人、活用しようとする人は減っている
- 以前のアーキテクチャ批評は、教育を受けた人、あるいは類似システムを何度も作って壊してきた人が提供していた
- 今では、作ったり壊したりした身体化された記憶を持たないモデルから、そうした批評が出てくる
- 遅さとは、実作業に伴うコストではなく、作業が良くなり、人が熟練し、会社が顧客に一定の品質を約束できるようになる過程そのものだった
- 現世代のエージェント型システムは、人間がボトルネックだという前提を中心に設計されている
- 人がこれから起こることを読み、判断する遅延が少ないほど、ループはより速く、よりクリーンになるという仮定である
- 多くの場合、これは正反対であり、ループ内の人間は過去の遺物ではなく、結果に利害関係を持つ唯一の構成要素である
- Human-in-the-loop(HITL)から人を取り除くことは、効率化ではなく、システムが自らの誤りを検出できる唯一の仕組みを放棄することだ
内部のAIスロップ
- 業務文書は急速に長文化している
- 1ページだった要件文書が12ページになる
- 3文だったステータス更新が、要約の要約をさらにbullet化した文書になる
- レトロスペクティブ、障害報告書、設計メモ、キックオフデッキなど、長くなりうるあらゆる成果物が長くなる
- 生成コストはほぼゼロに近づいたが、読むコストは下がらず、むしろ上がっている
- 読み手は、文書が本来何を伝えようとしていたのかを見つけるために、合成された文脈をふるいにかけなければならない
- 各個人が文書を増やす選択は合理的に見え、独立して報われる
- Beyond the Steeper Curve: AI-Mediated Metacognitive Decoupling によれば、読み手は説明の正確さと無関係に、より長いAI生成説明に対して強い確信を抱く
- その結果、職場の中でシグナルを見つけることは以前よりも難しくなる
- チェックポイントは文書の中に埋もれ、人々は実際には「簡潔に」しようという意図があっても、文書作業に沈んでいく
- これは公開市場に広がるAIスロップより高コストな、新しい形のスロップである
- それを作っている人々が給与を受け取っているからだ
- 判断力を教えていた作業はツールが担うようになり、その学習が起きていた新人ロールは、ツールが仕事をできるという理由で縮小している
- 多くのオフィスでは動きは多いが、以前の動きが生んでいた実際の成果は減っている
- 公開の議論は主に公開市場へ流れ込むAIスロップに集中しており、University of Floridaの Generative AI and the market for creative content もその流れを扱っている
- しかし同じ力学は組織内部でも起きている
- AIがなくてもよかった仕事、誰にも読まれない成果物、ツールが安く作れるようになったために生まれたプロセスに時間が使われる
- 以前ならわざわざ言う必要もなかったこと、あるいは自明とされていたことをデッキ化して展開する場面が増えている
対応方法
- この環境で必要な規律は、むしろ古典的なやり方に近い
- ツールが作った結果を正確に検証できる場面でのみ使うべきである
- モデルに確認を求めてはいけない
- ツールは誰にでも同意し、同意する側にコストがかからない同意には価値がない
- 生成AIが適しているのは、フィードバックが速く、おおむね正しければ十分であり、人が最終判断者として残る仕事である
- メモの下書き作成
- 例の生成
- 読み手が望めば検証できる資料の要約
- University of Illinoisの Generative AI Guidance と、PLOS Computational Biologyの Ten simple rules for optimal and careful use of generative AI in science は、次のような使い方を推奨している
-
ブレインストーミング
-
校正
-
自分のアイデアの再構成
-
すでに理解しているデータにおけるパターン検出
-
- 推奨されるすべての用途では、人が判断を提供し、ツールはスループットを提供する
- これは単なるHuman-in-the-loopよりも強い立場である
- ツールは作業の外側にとどまり、招かれた場所でのみ貢献し、それ以外では静かであるべきだ
- これは現在多くのエージェント型システムが向かっている方向と逆である
- 企業にとっては、信頼できる仕事を提供する能力が依然として競争優位であり続ける
- 競合が自らをコンテンツ生成パイプラインに変え、顧客がそれに気づかないことを期待するほど、信頼できる仕事の価値は高まる
- 問題はすでに表面化し始めている
- Deloitteは、AIハルシネーションを含む政府報告書に関連して44万ドルの手数料の一部を返金した
- 次の問題は、幻覚に基づく仕様で構築された運用システムかもしれないし、この1年間、自分がきちんとレビューできない仕事を名目上レビューしてきたと気づくシニアエンジニアかもしれない
- きちんと仕事をする企業は、その仕事に価格を付けられる立場に立てる
- 自らを空洞化させた企業は、顧客が対価を払っていた対象が、まさにその空洞化した部分だったと知ることになる
- 職場ではAIの誤解と誤用が蔓延している
- 専門性には、より速く納品し、より多くを作り、ツールをより深く統合し、「仕事を進める」同僚の邪魔をするなという圧力がかかる
- 成果物は積み上がるが、仕事は積み上がらない
- その成果物の向こう側では、顧客が納品物を開き、要約リストを読み、それから自分でレビューすることを選ぶかもしれない
1件のコメント
Hacker Newsのコメント
以前は1ページで済んでいた要求仕様書が12ページになる、というような 業務成果物の冗長化 には強く共感した
高校のエッセイで1000語の最低文字数を満たすためにわざと冗長に書いていた頃を思い出したし、今ではプロっぽい書式・分量・明快な文章が、もはや手間や品質のシグナルではなくなっている
だから今の 生産性向上のボトルネック は、依然として人間が直接レビューするだけの注意を払う人たちなのだと思う
最近では、書式やASCIIアートで埋まった10〜30ページの 仕様書 でさえ、実際には口頭で適当に投げられたアイデアに過ぎない可能性が高く、そう受け取ることに慣れる必要がある
管理職は私が送った内容をチャットボットやエージェントで要約・評価するのだろうが、こちらが最初から要約版を送るのは許されない
履歴書のATSチェッカーのように、自分の文章にもAIチェッカーが必要になるわけで、結局AIが書いた文章を別のAIがパースすることになり、とてつもないエネルギーの無駄になりそうだ
もっと効率的にやり取りするための、合意されたルール・構造・標準・手順のようなものがあるといい
検索結果の上位に上がるために何でも長く引き延ばす文章の産物だ
そんなものを送ってくる人はどうせ後追い確認もしないので、問題は自然に消える
ここで描写されている状況は、自分の経験とも非常によく似ている
うちの会社には何年もコードを書いていない管理職が多く、18か月前に採用したアーキテクトはAIですべてを設計していた
シニア開発者には何もかもがひどく過剰設計なのは明らかだったが、正しい用語を全部使うので、上級経営陣には他のシニアマネージャーより有能に見え、指摘されると人格攻撃で返していた
6か月ほどで何人も去り、残った人たちはAIに全振りし、有能な社員が去った穴を埋めるため、この12か月は エージェント型ワークフロー を作っている
結果として、この18か月で価値のあるものは何一つリリースされず、設計を誤ったソリューションに大量のクラウドコンピューティング費用を浪費した末、今は採用凍結でコストを削っている
経済性が大きく変わると、実質的にダムを取り払うようなもので、残りのシステムにはるかに大きなストレスがかかる
組織のリーダーがその潜在的な副作用やリスクを見ていなければ、大きな痛手を受けかねない
この技術は普遍的な改善として売り込まれたにもかかわらず、今後こうした会社が急増して転落していくのを見ることになりそうだ
生き残る会社はこの暴れ馬を飼いならす方法を広めるだろうし、理想を言えば将来そこから何かを学べるはずだ
ただ、今の素朴な熱狂ぶりには驚かされるし、新しく手に入れたバイブコーディング能力に過剰に浮かれた人たちが絶えず流れ込む 終わらない9月 がしばらく続きそうだ
2社前では、バイブコーディングがまだ実用的ですらなかったのに、何人かがLLMですべてをさらに膨らませることに夢中で、どんな質問にもイエス/ノーの答えを得るのが難しかった
Slackの1行、20秒で済む質問への返答が、結論のない2ページ分のぼんやりしたブログ記事だったし、追加質問はさらに時間を浪費させた
最後の職場では、PMが徐々に バイブコーダーたちのバイブマネージャー になっていくのを見た
技術的な議論に割って入り、各段階でAIを使って方向付けし、こちらが反論すると、話題を理解していない人がAIの翻訳結果を持ち出してくるのと戦うことになり、本当に苦痛だった
もはや反対意見すら許されず、AIのせいで職を失うかもしれないといった圧力までかけられた
その後、全員にバイブコーディングを義務化し、その量まで監視し始め、しかもそのPMはPM・エンジニア・アーキテクトの役割を同時に担っていたので、同じ作業に対して要件が完全に異なるチケットを複数作っていた
その結果、あるチームメンバーは一つのやり方でバイブコーディングし、別のメンバーはまた別のやり方で実装することになった
年間ほぼ1億ドルの利益を出していた20人規模の収益性あるチームが、無用で無意味な作業によって壊れていくのを見るのは本当につらく、結局辞めた
ソフトウェア業界のこうした変化に対してシニカルにならないよう努めているが、本当に難しい
マネージャーがドメインを不完全にしか理解していないのにClaudeを使って 専門家の助言と提案 を出し、会社の複数の非技術職が組織全体に配布される社内ソフトウェアツールを作り、そうしたデモで評価や報酬を得ようとしていた
経営陣は予想通り、そのような概念実証に感心して承認した
やたら活動的な同僚たちは中身をまったく理解していないのに専門家らしく見えるデモを見せ、リーダーシップはそれを受け入れる
この問題をどう表現すればいいのかわからなかったが、この文章はそこをうまく言い当てている
もちろんAIがあれば、さらに少なくしか作らない助けにはなる
かなり有害な環境に聞こえる
LLMを活用して質の高いソフトウェアを作る最も生産的なチームは、おおむねこういう使い方をするのだと思う
インテリジェントなオートコンプリート は、開発者が作業中のコードの文脈を保ったまま、生成コードが思考の延長として使われる本来のLLM活用であって、思考そのものをLLMに外注するやり方ではない
ブレインストーミングでは、曖昧な概念・アイデア・方向性を新たに広げて創造性を刺激できる
問題解決では、パッケージ競合、ランダムな例外、バグレポートのようなデバッグにかなり有用で、隣に同僚がいないときでも根本原因にたどり着く助けになることがある
コードレビューでは、人が見落としたいくつかを拾う場合があり、より賢いlint工程に近いが、人間のコードレビューを置き換えるものではない
概念実証では、問題へのさまざまなアプローチを生成し、より慎重に作られた解法の着想源にできる
こうした活用は、開発速度を上げつつも、開発者が何をなぜ作るのかを理解していなければならないという責任を維持する
逆に エージェント型コーディングに全振り するチームは、長期的にはプロダクトとチームを意図せず壊してしまう可能性が高いように見える
ここ最近いくつか尋ねた結果は、完全にもっともらしいのに完全に間違っていて、しかもそもそも話題にも合っていなかった
コードレビューでは 偽陽性 が圧倒的に多く、それが改善する理由もあまり見えない
それでも、こういう方向で役立つ可能性はある
個人的には1年ほど前に切って、従来のJetBrains IDEのオートコンプリートに戻った
自分の経験では、AI提案がまさに欲しいものを予測したのは1%未満、有用だったのも10%程度で、残りは単に間違っているか邪魔なだけだった
メソッド・変数などを素早く検索したりたどったりできる標準的なIDE機能のほうが、思考をコードへ移すのにずっと役立った
うちのチームもいくつかツールを試したが、指摘されることの大半は非常に表面的か、そもそも問題ではないものだった
スキルの低いチームメンバーのコードをレビューするときには、もっと深い問題を見逃していたし、人間のレビューアならより良い形で解ける問題に対して誤った変更が入っているのを見抜けていた
マネージャーはその結果を、私たちが何をしているのかわかっていないという自分のバイアスを裏付ける証拠として使った
コードレビューツールの絵文字だらけの出力をPRコメントに貼り付け、私たちが些細な問題を直すと「コードレビュー第2ラウンド」と投稿していた
士気は大きく落ち、一部のチームメンバーはレビューそのものをあきらめて、PRをそのまま承認するようになった
自分のコードを見直す用途としては悪くないが、プロセス上の強制的な制約になってはならないと思う
コードレビューの本来の目的は、お互いの改善を助けるために時間を投資することだったので、それを機械に外注するとチーム内の 社会的契約 が壊れてしまう
2年前には、ただのオートコンプリート強化版と高機能なGoogleにすぎないと言っていた
AIに悲観的な人たちは毎年外し続けているのに、今のAIができる水準は絶対に無理だと自分たちが言っていた事実を、なかったことにしている
ソフトウェアエンジニアリングでは、いくつかの理由からこうしたことが特に起こりやすいように思える
多くのソフトウェアエンジニアは、キャリアを通じて本当のエンジニアリングをしてこなかったし、大企業ではなおさらだ
小さな歯車として大きな機械に組み込まれ、誰かが昇進のために作った設定言語を覚え、その設定を整理・リファクタリングし、別の社内フレームワークの成果物を設定ノブの調整で「修正」しているうちに、5年たってもまだ同じことをしている
業界には 準エンジニアリング職 も多い
人と働くのが好きでコーディングをやめた人、プロダクトやユーザーの仕事に魅了された人などが、大企業から小企業までさまざまな .*M の役職を埋めている
大企業では列車の進みが遅く、コミットが本番に到達するまで数か月、6か月でも普通だ
大きく重要なシステムの中には、エージェント型コードがまだ本番に到達してすらいないものもある
だからAIは一部の見せかけの仕事を置き換え、コードの周辺にいた人たちが突然バイブコーディングを楽しみ始め、動きの遅い会社ではその成果物がまだ爆発していない
表面上は 生産性ブーム のように見える
「コードを書けない人がソフトウェアを作り、データシステムを設計したことのない人がデータシステムを設計する」というくだりを読んで、「大手テック企業でプロジェクトをリリースする方法」を思い出した
特に「リリースとは会社の中の社会的構築物だ。具体的には、会社の重要人物たちがリリースされたと信じたとき、そのプロジェクトはリリースされたことになる」という部分が頭に浮かんだ
https://news.ycombinator.com/item?id=42111031
良い文章だったし、見た目を保つこと と、そう見えることが常に重要であり、しかも私たちが思う以上にずっと重要な場合が多い、というなかなか良い議論も生んでいた
職場でAI導入の初期に、何人かの同僚が 過剰な主体性 を見せるためにこの技術を使っていることに気づいた
毎週新しいTOD、新しいリファクタリング案、古い問題をきらびやかな新アルゴリズムで解く方法といったものが出てきた
今ではこの現象が倍増し、より積極的に見せようとする試みとAI解雇への恐怖が結びついて、問題が完全に定義される前に解決策を作っている
たとえば、会社全体に関わるあるアーキテクチャ問題を調査する仕事を任され、しっかりした解決策を出せば評価されると思っていたが、もう遅かった
すでにインターンが解決策を見つけてTODを書いており、もう競う気力も尽きた
昨日はほとんどの時間を、LLMが生成したコードを削除して置き換えることに費やした
たいていLLMの助けは有益だったが、今回は狂ったような スレッドコード を大量に出してきて、数年ぶりにアプリがクラッシュし始めた
自分のアプリはクラッシュしない
他に問題はいろいろあっても、クラッシュはその一つではなく、自分はそこに執拗なほどこだわっている
私の経験則では、新しいスレッドにディスパッチすることはほとんどない
OS SDKにそうさせてその判断を尊重することはよくあるが、自分でワーカースレッドを立ててデバッグの苦痛以上の見返りを得られることはほとんどない
あらゆる種類のアプリに当てはまるわけではないが、自分が作るアプリには当てはまる
LLMはスレッドが大好きで、おそらく流行り物に飛びついた熱狂的な人たちが投稿した学習用コードが多いのだろう
結局、画面まわりのコードを切り取って自分でコードを書き直すと、性能は目に見えて良くなり、クラッシュも止まった
教訓は 買い手責任 だ
モデルからの出力をそのままコピペしているのが見え見えの人と議論するか迷った、という話には共感する
そういう人たちに同じやり方で応じるささやかな面白さを感じたことがある
相手のAI出力を自分のAIに貼り付け、自分のAIの返答をまた貼り付ける、という具合だ
2人の人間が機械のように振る舞い、2台の機械が人間のようにコミュニケーションする コスプレ をしていることになる
本当に壮観だった
友人同士の概念実証ではAWSで過剰設計するよりVercelで素早く出すべきだ、という自分のシニアとしての方針についての単純な質問に、彼は AIごった煮チャート を送ってきた
兄がAWSを使っていて自分もそちらのキャリアを望んでいる、という枠組みに強くとらわれすぎていて、友人同士の概念実証でなぜそのやり方が妥当なのか自分で考える代わりに、思考をAIに外注していた
読んだかと聞かれたので、AIで要約して読んだが返答はしなかったと答えたら、会話はすぐ終わった
「専門家には役に立たない」という話は、少し近視眼的すぎる
どれだけ優秀な人でも、弱い領域や自動化できる退屈な領域はある
自分の場合、過去のキャリアで足を引っ張っていたのは、多数の作業を一度に整理すること、組織全体に変更点を効果的に伝えること、そしてJiraのような場所で文書化やチケット管理をすることだった
今ではそれがもはや悩みの種ではなく、その部分の 効率向上 は絶大だった
自分が得意な中核業務では、タイピングをかなり速くしてくれる以上の大きな助けにはならないが、それでも十分ありがたい
慣れていないことをやらせると、たいてい自分よりうまくやるか、少なくとも、より多くの情報を持って意思決定できる方向へ導いてくれる
「モデルに検証を求めるな。ツールは誰にでも同意する」という言葉には同意する
LLMは、こちらが適当に何か間違っていると言うと、こちらが正しいとわかっているコードに対しても、どうにかして欠陥を見つけ出す
問題は、LLMがしばしばあまりに文字通りに受け取りすぎることだ
計画を立てさせても、LLMが システム全体を自律的に設計 することに成功したことは一度もない
LLMがコードを書いた後、いろいろな角度から正しいかどうかを尋ねると、実際の問題を見つけることがかなりある