ハクソク

世界を動かす技術を、日本語で。

みんながAIを持っているのに、会社は何も学ばない時

10時間前原文(www.robert-glaser.de)

概要

  • AI導入は個人の生産性向上が組織全体の成果に直結しないという課題
  • AI活用が組織内で広がるにつれ、「混沌の中間期」に突入
  • 従来の変革手法ではAIの学習や知見共有が追いつかない現状
  • 重要なのは「ループインテリジェンス」：AIが生み出す学習や意思決定の質に着目
  • 監視ではなく学習促進のための仕組み作りが必要

AI導入の「混沌の中間期」と組織的学習の壁

  • Ethan MollickはAI導入において、個人の生産性向上がそのまま組織の成果に反映されないと指摘
  • **AIツール（GitHub Copilot, ChatGPT Enterprise, Claude, Gemini, Cursorなど）**のライセンス配布が進み、組織内での利用が部分的・非公式に広がる現状
    • 先進的な個人やチームが公式の教育資料を超えて独自に活用
    • 管理側はライセンス利用状況やPoC（概念実証）でROIを測ろうとするが、実態把握は困難
  • AI活用の「混沌の中間期」：利用は広がるが、学習や成果の組織的共有が追いつかない段階
    • チームや個人ごとにバラバラな使い方
    • 成果や気づきが見えにくく、組織学習につながりにくい

AI導入初期と「混沌の中間期」の違い

  • 初期段階：座席購入、利用規定、トレーニング、チャンピオンネットワーク、事例共有など、従来型の展開
  • 中間期：
    • チームごと、個人ごとに利用方法や成果が大きく異なる
      • Copilotを補完ツールとして使うだけのチーム
      • Claude Codeで自動化ループを回すチーム
      • プロダクトオーナーがAIでプロトタイプを作成
      • 上級エンジニアがAIに根本原因分析を委任
      • サポートチームが独自にワークフロー自動化
    • 組織単位ではなく、業務内のループ単位でAI活用が進行
    • Mollickの「Leadership, Lab, Crowd」フレームが有効
      • Leadership：方向性と許可
      • Crowd：現場で実際に使い、新たなユースケース発見
      • Lab：発見を共通実践・ツール・システムに昇華
    • 課題：知見や学習がどう伝播するかが不明瞭

従来の変革手法の限界

  • 従来手法（コミュニティ、勉強会、チャンピオン、デモ、サーベイなど）はAI活用のスピードに追いつかない
    • 実際のAI活用は日々の業務（コードレビュー、提案書、研究、インシデント対応など）で発生
    • ベストプラクティスとして形式知化される頃には、肝心な学びが失われていることも多い
    • 本質的な学習は「摩擦」や「失敗」から生まれる

ループインテリジェンスの重要性

  • AIコラボレーションは一様ではなく、緊密な共同作業から緩やかな委任まで幅広い
  • 重要なのは「AIを使っているか」ではなく、「どのループで、どの学習が生まれているか」
    • どのループが早く閉じたか
    • どの意思決定が改善されたか
    • どの分析やレビューが鋭くなったか
    • どのチームが再利用可能なパターンを学んだか
  • トークン消費量や出力数ではなく、「トークン→学習」の質が重要

エージェント運用・ループインテリジェンス・エージェント能力

  • Agent Operations：どのAI/エージェントが、どのシステム・データにアクセスし、どの権限・監査・可視性があるか

  • Loop Intelligence：どのAI支援ループが学習を生み、どこが停滞・逸脱・過監督に陥っているか

  • Agent Capabilities：有用なエージェント能力を、組織全体にどのように分配し、業務現場に流し込むか

    • これら3つが連携しないと、制御の官僚主義・分析だけの層・ツールの乱立に陥る

フィードバックハーネスとLoop Intelligence Hub

  • フィードバックハーネス：現場の業務ループ（タスク、プロンプト、仕様、レビュー、意思決定など）から学習の痕跡を収集
    • 監視目的ではなく、どのループで学習が生まれたかを理解
    • 小規模なワークフローから始め、意図・AI作業・検証・人間の判断のポイントを可視化
  • Loop Intelligence Hub：収集したシグナルを、組織の意思決定や能力開発に還元
    • 例：新たな教育ニーズ、投資判断、再利用可能なワークフロー、ガバナンスギャップの特定
    • 重要なのはダッシュボードそのものではなく、そこから生まれる意思決定

監視ではなく学習促進のための仕組み

  • 従業員監視やAI利用量のスコア化に陥ると、現場は形だけの利用や数字合わせに走る
  • 本質は「どこでAIが学習を生み、組織知となったか」を見極め、それを現場に還元すること
  • Loop Intelligence Hubを通じて、現場の知見を組織全体に循環させる仕組み作りが鍵

（続きや詳細なテーマごとの深掘りが必要な場合は、追加でご指示ください。）

Hackerたちの意見

> 昨年、Anthropicに支払った200万ユーロのROIはどこにあるの？CEOはオフィスにYouTubeスタイルのプラチナトークンのプレートを持ってるけど。
この投稿は、混沌とした中間部分を的確に捉えてるね。自分の責任がある開発者にとって、この種のインテリジェンスループを開発する動機は全くないよ。管理職がどんなに優しく頼んでも、自分の生産性向上を無償で会社全体と共有するつもりはない。役立つツールなら共有するかもしれないけど。AIを扱ったりエージェントを設定する方法を学ぶことは、共有しても認識されないなら自分だけのものにしておいた方がいい。うちの会社は「今週のプロンプト」賞や、導入を広めるためのブラウンバッグセッションを設けたけど、明らかに彼らはこれらのイベントを自分たちの生産性としてアピールするために設定してる。実際の（つまり「金銭的な」）インセンティブや雇用の安定がないと、知識を広めるリスクとコストは開発者にかかってくる。
└
なんで多くの人がこう考えないのか、ちょっと理解できない。例えば、今のAIの状況が始まるずっと前に、自分の仕事を楽にするためにCLIを作ったんだ。スクリプトを自動化するのも簡単になったし、同僚たちがそのツールに気づいて「シェアしたら？」って言ってきたけど、私の丁寧な返事は「いいえ」だよ。サポートすることや、他の人たちが私と同じくらい生産的になるのを手伝うのは、マイナスにしかならないから誰にもシェアしない。さらに、リーダーシップは私のアイデアを資産として認めてくれないから、仕事の安定もないし。心の優しさで会社を助けるつもりはないし、近い将来にクビになる可能性もあるからね。もし開発者たちが今の市場の状況で仕事を心配しているなら、個人のワークフローを企業秘密として扱うべきだと思う。私の例はAIに特有のものではないけど、AIのワークフローにも同じことが言えるよ。労働者市場では、そういう知識を組織とシェアするのが楽しかったこともあったけど、雇用者市場では、私の個人的な選択にアクセスしたいならお金を払ってもらうべきだね。
└
> でも、私は自分の生産性の向上を広く会社と無償で共有するつもりはない。もし雇用主があなたが無償で時間を共有することを期待しているなら、あなたは損をしている。ほとんどの人は自分の仕事をするために給料をもらっている。もちろん、勤務中は雇用主のために働くことが期待されているけど。
└
職場を敵対的に扱うのは嫌だけど、企業が「みんなすごく生産的で、たくさんの成果を上げてるのに、なんでこんなに人がいるの？」ってゼロサムの考え方を持っている限り、仕方ないよね。私は「職場は家族！」みたいなタイプじゃないけど、ただ自分の仕事をしっかりやって、お互いにそれを共有できればいいのにって思う。自分の首を絞めることを心配せずに。
└
隠されているこれらの「秘密」は、基本的にゲイリー・タンの超強力なプロンプトリストと同じレベルだよ。実際、誰もが思いつくようなことではないし、そんなにクレイジーでもない。私の経験から言うと、自分のプロンプトやスキルを共有しても、ほとんどの人が使わないんだよね（あるいは、あまりにも基本的すぎて、みんな自分のバージョンを持っていたり）。例えば、誰かがAIの前にxyzに興味がなかったら、AIの後でも興味を持たないと思う。たとえそれを銀の皿で提供しても。
└
別の視点として、AIツールは最初に個人に利益をもたらし、そのユーザーは生産性の向上（見た目上のものも含めて）をスラックタイムの形で得るってことがあるよね。ここで面倒な作業がほぼ排除されて、あっちで問題が解決されて、私たちの一日には余分な1時間か4時間が戻ってくる。じゃあ、その人はその取り戻した時間で新しい仕事を探しに行くのかな？多分、会社のためじゃない限り、特別なモチベーションがないと無理だと思う。
大企業の世界では、AIの導入は開発チームの外には出ていないよ。GitHub Copilotにアクセスできるのは開発者だけ。コードがコミットから本番環境に出るまでに6〜12ヶ月かかる。開発スピードがボトルネックだったことはない。時間がかかるのは、インフラの準備、テスト、承認、変更管理、デプロイのスケジューリングなど、他のプロセスなんだ。AIはこれらの開発後のボトルネックをさらに悪化させる。変更がリリーストレインに乗るのを待って、ドアの前に積み重なってる。大企業は、トークン支出のROIを確保したいなら、ソフトウェアをもっと早く出荷する方法を学ぶ必要がある。出荷されていないコードは資産じゃなくて負債だよ。
└
> 大企業はソフトウェアをもっと早く出荷する方法を学ぶ必要がある 彼らは「コードは少ない方がいい」ってことすらまだ学んでないから、基本を学ぶ前に「もっと高度な」ことを突然学ぶのを待っても無駄だよ。
└
そうだね。十分に大きなシステムは、実際にはもっとコードが必要なわけじゃないポイントに達すると思う。栄養やカロリーもある程度までしか役に立たなくて、その後は効果が薄れて、最終的にはマイナスになることもある。異なるシステムを説明してるから完璧なアナロジーではないけど、より多くを生み出すことがしばしば逆効果であることを理解するのに役立つ。ちなみに、今日、顧客からフィードバックをもらったんだけど、私たちのドキュメントは完璧で詳細すぎるから、ちょっと圧倒されているって。要点を数個挙げる方が、5ページの文書よりもアイデアを伝えるのに良いみたい。今はそれが明らかだね。
└
「リリーストレイン」…「ソフトウェアをもっと早く出荷する方法を学ぶ」SAFeは毒だね。
└
> 開発のスピードは決してボトルネックではなかった。時間がかかるのは他のプロセス：インフラの準備、テスト、承認、変更管理、デプロイのスケジューリングなど。マネジメント（中間管理職も役員も）は、ソフトウェアをまるで組み立てラインのように考えている。「フォードが車を作るように、私たちもソフトウェアを作る」と。コードを製品として扱っている。もちろん、ほとんどのソフトウェア開発が非常に非効率的であることは否定できないけど、重要な部分は全く考慮されていない。「仕事」とはコードを書くことだと見なされていて、どのコードを書くべきかを知るためのリサーチは無視されている。AIのマーケティングに関しては、これはほぼビデオゲームのような弱点だ。マイクロソフトは「50%早いコード！」と宣言し、すべてのマネジメントのバカは「50%早い製品；50%早いお金！」と思っている。> 大企業は、トークン支出のROIを確保したいなら、ソフトウェアをもっと早く出荷する方法を学ぶ必要がある。ROIが求められると、災害になるだろう。今は誰もそれを測ることに問題を感じていない。投資家はハイプに酔っていて、社内の誰もソフトウェア開発の生産性を正しく測ることがほぼ不可能だと認めたくない。でも、そのハイプは永遠には続かない。遅かれ早かれ、投資家は「200万ドルの支出」を見て「400万ドルの純利益」を要求するようになるけど、それは実現しないだろう。CopilotやClaudeは本当のボトルネックに対処することはない。彼らは10年前の組織知識を掘り起こすことはできないし、コードが悪いのか、特定の文書化されていない問題を解決するためのものなのかを判断することもできないし、将来の使い方を予測することもできない。コードは製品ではない。本当の仕事ではない。実際、コードベースが健康な状態であれば、それは設計とリサーチプロセスの結果としてほぼ無料で出力されるものだ。例えば、「調達チームが検索を使いにくい」と言うのを実用的なチケットに洗練させる頃には、適切な検索フィルター用のReactコンポーネントはほぼすでに書かれている。コードを書くのはただの形式的な作業に過ぎない。Copilotに聞くと、10分の仕事が5分で終わる。すごいけど、そのために6時間の会議や電話があったことを考えると、あまり感心できないね。
└
古いものがまた新しくなる [0][1][2] 制約理論 - AI時代 [0] https://en.wikipedia.org/wiki/Theory_of_constraints [1] https://www.goodreads.com/book/show/113934.The_Goal [2] https://www.goodreads.com/en/book/show/17255186-the-phoenix-...
└
> 出荷されていないコードは、資産ではなく負債だ。「あ、バグを見つけたんだけど-」「クロードで既に見つけたよ、次のリリースを待ってるところ。」それより悪いのは、プロダクションには存在しないバグで、コードがどんどん変わっていくから、バグが出るまで気づかないこと。ニッチなユーザーが忘れられたような使い方をしていて、次のデプロイでシステム全体をクラッシュさせることになるかもしれない。
└
私の大企業の世界では、AIの導入が悪化しているように見える。ファイナンスの人たちが、自分たちのアプリをCopilot/Cursor/Claudeを使ってコーディングできるか聞いてきた。彼らは「CFOがそう言った」とか「CFOがLovableをテストして、確信しているからアプリをコーディングするように言ってる」とか、私の管理が凍りつくのを知っているから、その理由を持ち出してきた。さらに「このアプリを試さないと、企業のファイナンスで適切なデータセキュリティと保守性を持ったアプリが存在できるか確かめられない」と、きれいにまとめた理由を付け加えてきた。ちなみに、これは20億ドル以上の収益を上げている会社での話。
└
> コードがコミットからプロダクションに至るまでには、6〜12ヶ月かかる。それってすごく特殊な分野じゃない？
└
それが一番のボトルネックではないかもしれないけど、同じ時間を持ちながらエンジニアの数を30%減らせるなら、それは大きな勝利だよね。人数が少なくなると、コミュニケーションや調整もずっと少なくなるし。ただ、万能薬ってわけじゃないけどね。
└
それもエンタープライズテクノロジーなの？古い非テクノロジー企業での導入状況が気になるな。隣のオフィスでは、20代から30代の若者たちにパワーポイントのプレゼンテーションを使って保険ブローカーのやり方を教えてるんだ。プレゼンをLLMにコピー＆ペーストしたら、全員を置き換えられちゃうよね。もしこのまま突き進んでいったら、10年から20年後はちょっと暗い未来が待ってる気がする。
いい記事だね。私が特に注目したのは、組織が仕事を定義する方法の変化だよ。昔のモデルでは、パフォーマンスやOKRは専門分野、職務タイトル、役割ごとの期待に基づいていた。でもAIの時代では、その境界が崩れ始めてる。もっと深い問題は心理的かつ組織的なもので、人々は「これが私の仕事」と「これは私の責任ではない」の境界を常に交渉している。それが重要な導入の問題を生んでいる。目に見える形でAIの専門家として認識されることのメリットは何なの？もし私がより早く、より良く、よりクロスファンクショナルな仕事ができると知られたら、会社が認識、報酬、キャリア成長のための明確なシステムを作らない限り、なぜそれを明らかにする必要があるの？
└
もし専門のAIユーザーに報酬を与えるシステムを作ったら、そのキャリアには問題が出てこない？新しいキャリアの存在に引き寄せられた誰かが、会社の特有の事情に自分のアドバイスを統合して、（数週間）より現代的なアプローチを取ることになると、ドメインエキスパートとしての役割が消えてしまうことになる。
└
まあ、それはいいけど、チームメイトがデフォルトでそういうことを全部やって、彼らと他のチームとの間にギャップができると問題だよね。
└
結局、プロダクトのインシデントを修正したり、維持管理する責任がある人がオーナーになるんだよね。エージェントがその境界を越えている世界では、確かにそれは結構混乱してると思う。AIエンジニアが自分のエージェントの大群を持って、全てを動かし続ける責任があるのかな？正直、そうは思えないけど、どうなるか見てみよう。
AI自体はあまり役に立たないよ。エージェントは忘れたり、十分なミスをするから、すべての作業をチェックしなきゃいけなくて、結果的に生産性がマイナスになることもある。AIは他のツールを作ることができる道具として扱うときにこそ、本領を発揮するんだ。例えば、一定の品質に達するまで作業を続けさせるツールを作らせたり、出力のコンプライアンスチェックを行わせて、どこを修正する必要があるかを教えたりする。そうなって初めて、その作業を信頼できるようになる。今のところ、ほとんどの役割やワークフローは、特定の仕事をするために与えられたツールを扱うことを中心に設計されている。その体制では、AIは周辺にしか入り込めない。
3年前に退職したシステムアナリストとして、若い同僚たちが心配だよ。2023年には、私のチームでAIを使ってレガシーコードを解決した最初の一人だったんだ。Perlで重要なミッションをこなしていたコードで、元の作者はとっくに辞めていて、コメントやドキュメントについて何も理解していなかった。新しい技術にみんな驚いていたけど、最近はそれが自分に何かを「される」ものになってきている気がする。誰もこれを求めていなかった。インスピレーションや考えが、瞬時に物事を進めるために無価値になってしまうのはいつなんだろう。仕事に魂がない。
AIの約束をドットコムバブルと比較するのが役立ってる。似ているところが多いよ。でも、インターネットはビジネスにとってはシンプルな概念だった。基本的には、今は人々のコンピュータから販売できるってこと。AIの約束って何だろう？物事に関する推論を近似できるってこと？これは本当に解決するのが難しい実装のパズルだと思う。コーディングタスク以外で実質的なものを見たことがないな。
今、この分野で働くのは本当に最悪だ。私が働いている会社では、上司が全員に使わせている、非開発者でもね。本当に辞めて別の分野で働きたいけど、残念ながら私の住んでいるところでは初任給じゃ家賃も払えないし、年齢も気になってきた。
私がエンジニアとして働いてきた多くの中規模企業では、成長計画を作るように頼まれることが多かったし、それをマネージャーと共有することもあった。四半期の終わりには、その成長計画を見直して、マネージャーが実際の成長に同意するかどうかを判断し、それに見合ったパフォーマンスボーナスをもらう感じ。私は、AIとのやり取りから生まれる自己トレーニングの副産物を社員が作ることを提案したい。そして、その副産物が成長計画の一部になるように、キューバ人のマネージャーと一緒に働くことも。これで、インテリジェントなAIシステムとやり取りする機会を失わずに成長を保証できると思うよ（会社の短期、中期、長期の戦略的な利点に関連するトピックで）。
俺みたいな普通のエンジニアにとって、会社でAIを使うメリットはあんまりないよ。俺たちを搾取してるだけだ。もちろん、HNのエリート（投資家、経営者、有名人、トップエンジニア）は「イノベーションに反対するなんてどうかしてる」って言うけど、AIやLLMはTCP/IPやLinux、Postgresのようなイノベーションじゃないからね。はっきり言うと、claude/codex/gemini/grok/なんでもいいけど、利益のために存在してて、最後の生産性を搾り取って、何も残らなくなったら使い捨て（解雇）されるんだ。AIが好きなら、オープンソースのモデルを使って、サイドプロジェクトで活用すればいい。
└
1) ゲームは終わってるわけじゃなくて、変わってるだけ。AIはたくさんのコードを生成できるけど、実際に何が起こってるのかを理解しているエンジニアはまだ必要だ。それが常にボトルネックだった。ジュニアのポジションはなくなるかもしれないけど、シニアは今のところ大丈夫。2) これは俺にとって厳しい教訓だったけど、自然と反対意見を持つ俺でも、管理側が求めることをやるために雇われてるってことだ。抵抗しても、気づかれないか、気にされないことを祈るしかないけど、あんまり変わらないと思う。