/note/tech

AIで生産性が3倍になった私たちが、チームを置き去りにした話

要約:

■ 1. 置き去りは構造で起きる

  • 上司の「正しいことを言っているのだと思う」:
    • 週次の報告会でAIで作ったスライドとHTMLレポートを映したところ、上司はすぐには理解できないが正しいと述べた
    • そのときは好意的な反応として受け取ったが、あれはレビューが壊れた瞬間だった
  • 筆者の立場:
    • 大手製造業のDX推進部門でマネージャーを務める
    • この1年ほどチームの若手中堅メンバーと一緒にAI活用を進めてきた
  • 生産性3倍と置き去りの同時発生:
    • 体感の生産性は3倍になり、同じ時期に上司とベテランメンバーを置き去りにした
  • 置き去りの性質:
    • 誰の悪意でも怠慢でもなく、構造で起きる
    • 置き去りにした側も損をする
  • 悪役の不在:
    • 上司は誠実、ベテランは真面目、若手は優秀であり、それでも壊れた
    • だからこの話は、たぶん他の組織でも起きる
  • 対象読者:
    • 組織のAI活用を推進している人、チーム内のAI活用の温度差にモヤモヤしている人
    • 一部の若手だけが突っ走っていると感じている管理職

■ 2. 私たちが走った道

  • AI活用の入口:
    • 製造現場出身で、転職を機にPythonを1から勉強した
    • 製造ライン向けのアプリを現場に入れるようになり、やがてAIコーディングを使い始めた
  • 標準化から仕様駆動開発へ:
    • 作る人によって構造がバラバラで引き継げないため、標準仕様を作ろうとした
    • そこで仕様駆動開発という思想を知り、Claude Codeでそれを回す取り組みを始めた
  • 業務時間外での学習:
    • 30代前後の若手中堅が中心の取り組みメンバーと議論するうちに面白くなった
    • 気づけばプライベートの時間にも情報を集め、試すようになっていた
  • 報告資料の変化:
    • 本社や幹部への報告資料は、それまで1週間ほど頭を支配される仕事だった
    • AIとの壁打ちなら1日集中すればだいたい形になり、そこから手直しはする
    • 頭を占有される期間が1週間から1日になった
  • コーディング外への拡大:
    • アプリ開発は仕様さえあれば待っているだけで出来るようになった
    • 気を使うメールの下書きは一瞬で出る
    • 打ち合わせのメモを雑多に投げれば、ToDoとテーマの進捗が自動で更新される
  • 自分用の秘書エージェント:
    • markdownのリポジトリを記憶の置き場にし、AIがそれを読み書きしながら育っていく仕組みにしてある
  • 3倍の中身:
    • 作業のスピードではなく、同時に抱えられるテーマの数が3倍になった
    • 解放されたのは時間ではなく、頭の占有だった
    • 1件あたりが3倍速く終わるのではなく、並行して持てる件数が増える
    • 体感は少し速くなったではなく、働き方が別のものに変わったに近い

■ 3. 効率化の可視化と爆発

  • 見えない場所で進んだ効率化:
    • AIコーディングは上司から見えない場所で進んでいた
    • コードが速く書けても、上司の目に入るのは成果物とスケジュールだけだった
    • 1年かけた変化は、上司にとって順調に進んでいるらしいという以上の解像度を持たなかった
  • 報告会での断絶:
    • AIで作ったスライドとレポートが報告会に出た瞬間に置き去りが可視化された
    • 上司にとっては段階的な変化ではなく、ある日突然現れた断絶であり、驚くのが当たり前である
  • 置き去りの一般法則:
    • 進行中には気づかれず、可視化された瞬間に一気に表面化する
    • 表面化したときには、もう差は1年分ついている

■ 4. レビューが上下両方向で壊れた

  • 壊れたものの正体:
    • 個人の能力ではなく、レビューという組織の品質保証機構が上下の両方向で同時に壊れた
  • 上から私へのレビューの機能不全:
    • AI製の資料は情報が濃く、AIと壁打ちしながら考えを詰めるぶん私自身の視座も上がっていた
    • 結果として、上司がレビューできる点がなくなった
  • 信頼と検証の分離:
    • 正しいと思うは信頼の言葉であって、検証の言葉ではない
    • 検証が抜けて承認だけが残り、信頼はレビューにおいては機能不全の症状である
  • 逆転した知識の勾配:
    • 上司は中身にはついていけなくて申し訳ない、持ち帰ってちゃんと読む、勉強します、教えてくださいと言うようになった
    • 職制上の関係は何も変わっていないのに、知識の勾配だけが逆転していた
    • レビューの場が、いつのまにか謝罪の場になっていた
  • 上司の誠実さ:
    • 自分のギャップを公の場で認め、AIで急速に変化が起きており自分が一番キャッチアップが必要だとメンバーに言えた
    • 分からないことは自分で調べて、この場で質問していこうと促していた
    • できることをやっていたが、それでも壊れた

■ 5. 作っても定着しなかった自動化

  • 上司の定型集計業務:
    • 手元のデータを所定のフォーマットにまとめるだけの仕事に見えるが、例外的な扱いをする項目がいくつもあった
    • そのルールは上司の頭の中にしかなく、毎回それなりの時間を取られていた
  • 3時間での自動化:
    • まずルールを本人に書き出してもらい、それをもとにアプリ化してマニュアルを付けた
    • このアプリをどうやってAIと作ったかの手順もレポート形式でまとめて添えた
    • 作り方まで見てもらえば、AIでアプリを作る感覚を少しでも掴んでもらえると考えた
  • 自動化が業務移管に化けた:
    • 上司は次の集計タイミングである1ヶ月後までまともに触らなかった
    • 触らないうちに使い方が分からなくなり、最終的にアプリごと集計業務を別のメンバーに渡すことになった
    • 良かれと思って添えた作り方のレポートも、たぶん誰も読まなかった
  • OJTを省いた言い訳:
    • このときあえてOJTをほとんどせず、実験のつもりだった
    • マニュアルも手順も揃っているのだから、読んで試して、詰まったら調べて動かせるはずだと考えていた
    • 今思えばこれは実験ではなく、教える手間を惜しんだ自分への言い訳であり、無理だった
  • 自走力の希少性:
    • 説明を読んでやってみる、詰まったら調べてまたやってみるという自走力は、実は希少なスキルである
    • マニュアルを配れば全員が使えるようになるという前提が成り立った現場を見たことがない
    • エンジニアの世界にいると基礎スキルに見えるが、人間のデフォルトはたぶん逆側にある
  • 管理職は時間の貧困の最深部:
    • 上司には自分の会議、部門の調整、上からの依頼がある
    • 持ち帰ってちゃんと読むと言った本人が、一番その時間を持っていない
    • 自走力の問題だと思っていたが、その手前に時間の問題があった
    • 新しいことを覚える時間が最もない人に、新しいことを覚えてもらおうとしていた
  • 定着リードタイムは潰せない:
    • 開発リードタイムはAIで潰せたが、定着リードタイムは潰せなかった
    • 作るのは3時間で済むが、定着は人間の時間で動く
    • AIによって開発が速くなるほど、ボトルネックは開発から定着へ移動する

■ 6. 上から若手へのレビューの崩壊

  • 若手の報告への違和感:
    • 自分の専門から外れたテーマの説明で、資料はきれいなのに自分の言葉になっていなかった
    • 詰まるわけでも劇的な破綻もなく、書いてあることをそのまま読んでいるように聞こえた
    • そういう場面が一度ではなく増えていき、上司はそれを指摘できなかった
  • 検知器としての資料の崩壊:
    • これまで資料が書けないことは、理解していないことの検知器だった
    • 分かっていない人間にはそれらしい資料が作れず、資料作成自体が理解度のテストとして機能していた
    • AIはこれを壊し、資料の完成度と本人の理解度を切り離した
  • 検知器の質問への移動:
    • 本人の言葉かどうかを見抜くには、的確な質問をぶつけるしかない
    • AI活用についていけていない上司には、その質問が出せない
    • 検知器が移った先に、検知できる人がいなかった
  • 私が質問しなかった理由:
    • できなかったのではなく、しなかった
    • 人前で答えられない状態を作れば指摘ではなく晒しになり、そこで恥をかかせるのは違うと思った
  • 質問という検知器の副作用:
    • 相手に恥をかかせるという副作用がついてくる
    • 上司は質問できず、私は質問しなかったが、検知されなかったという結果だけが同じだった
  • 自分の原体験:
    • 学生時代に論文やネットから拾った言葉をそのままスライドに貼り付けて発表し、質問に答えられず叱られた
    • 以来、自分の資料は一言一句自分の言葉で説明できなければならないを自分のルールにしてきた
    • この原則はAI以前からあり、AIはこの失敗モードを大量生産できるようにしただけである
  • 若手に責任はない:
    • AIがなければ彼は勉強して出直しますと言っていたはずである
    • 能力の前借りは道具の性質であって、本人の資質の問題ではない

■ 7. 時間の貧困ループと双方向の恨み

  • 非対称になった時間の使い方:
    • AIを使うメンバーは資料作成もデータ集計も極力自動化し、空いた時間を創造的な仕事に使うか、単に楽をする
    • 使わないメンバーは相変わらず資料作成とデータ集計に時間をかけている
  • 自己強化する非対称:
    • 作業に時間を取られている人にはAIを学ぶ時間が生まれず、学ばないから作業が減らない
    • 自動化した側は空いた時間でさらに学んで差を広げる
    • 同じ職場に逆向きに回る2つのループが立ち、分断は放置しても自然には解消しない
  • 時間を作るだけでは解決しない:
    • 奪われているのは時間だけではなく、頭の占有である
    • 来週の報告資料に頭を支配されている人は、空き時間を与えられてもその頭では新しいことを学べない
    • 占有そのものを外す道具がAIである以上、ループの入口はAIしかなく、だからこそ外からの介入が要る
  • 共通言語の消失:
    • AI活用の話をしても通じなくなった
    • ただただ凄いことをやっている人たちという見られ方になり、それは理解ではなく畏怖である
  • 当時の私たちの苛立ち:
    • 自分たちばかりが仕事をこなしている、なぜ自分で情報を取りに行かないのか、なぜ勉強しないのかと感じていた
    • これは間違いだった
  • 学ばないことの道徳化:
    • プライベートの時間を投じて学んだ人間は、学ばないことを意欲の問題として道徳化してしまう
    • 実際には学習機会の構造の問題だった
    • 私たちが学べたのは意欲が高かったからではなく、たまたま面白いテーマに当たり、たまたま自分の時間を使えたからだ
  • 分断が完成する条件:
    • 技術の差がついたときではなく、お互いが相手を道徳的に責め始めたときに完成する

■ 8. ベテランの静かな退場

  • ベテラン層の反応:
    • 40代以降のベテラン層からはあきらめを感じた
    • 自分たちはもう自分が知っていることでやっていくという静かな退避だった
    • 驚き、動揺し、ついていこうとした上司とは違った
  • 促されても出ない質問:
    • 上司はこの状況に危機感を持ち、ベテランメンバーのこともちゃんと心配していた
    • だからこそ分からないことは自分で調べて、この場で質問していこうと言ってくれていた
    • それでも質問が出なかった
  • あきらめの危険性:
    • あきらめが可視化された形は、質問が出ないことだった
    • 驚きは声になるが、あきらめは声にならない
    • 声にならないから問題として表面化せず、表面化しないまま固定化する
    • だから畏怖よりあきらめの方が危険である
  • 質問が出なかった原因は私にもある:
    • 普段から浅い発言にはすぐに厳しく追及していた
    • 悪気はなく議論の質を上げるつもりだったが、質問すると詰められる場を日常的に作っていた
    • 上司がいくら質問しようと促しても、質問が出るわけがない
  • 最初に必要だったもの:
    • 底上げに必要だったのは教材でも時間でもなく、質問が出る場だった
    • そして私は、それを壊す側にいた
  • 降りる側の合理性:
    • 降りたくて降りる人はいない
    • 何十年もかけて自分のやり方を作り上げた人にとって、道具が変わることは仕事のやり方そのものを疑われることに近い
    • 持ち込んだのが一回り以上年下の人間で、質問すれば詰められる場なら、降りる方が合理的である
    • あきらめは、置かれた条件に対する妥当な判断でもある
  • 暗黙知の時限問題:
    • 降りたベテランは、自分の知識をAIの射程の外に置いたまま現場を去っていく
    • 不良の因果、工程パラメータの勘所、過去の失敗など、最もAIに載せる価値のある暗黙知を持つ人から先に離れていく
    • 底上げは追いつかせる話であると同時に、その知識が失われる前に接続する時限問題でもある

■ 9. これはあなたのチームの予告編

  • 分断を駆動した2つの要因:
    • 学習機会の非対称であり、業務の仕組みではなく個人の余暇で学ぶ構造だったから、学べる人と学べない人に割れた
    • 道具が業務の形そのものを変えたことであり、働き方が変わったから使う側と使わない側で仕事の形が乖離した
  • 固有事情の不在:
    • ここにうちのチーム固有の事情は何ひとつない
    • この力学はチームから部門へ、部門から会社へ、会社から社会へ、スケールを変えてそのまま働く
    • これはうちのチームの失敗談ではなく、あなたのチームの予告編である
  • 社外カンファレンスでの確信:
    • AI時代の開発生産性をテーマにした社外のカンファレンスに参加した
    • 個人の開発生産性が上がっても、なぜ組織の生産性は上がらないのかというテーマが繰り返し語られていた
    • 開発の現場ではないのに、私たちの状況とほとんど同じだった
  • 先頭集団の普遍的問題:
    • AI導入で先を行くソフトウェア業界が、すでにこの問題に組織として取り組んでいる
    • 私たちの悩みは個別の失敗ではなく、先頭集団が直面している普遍的な問題である
    • 製造業から見れば、あの業界の議論は他人事ではなく、数年後の自分たちの姿である
  • 共通言語の有無という条件差:
    • ソフトウェア業界で語られる格差は、基本的にエンジニア同士の格差である
    • コードとレビューという共通言語を全員が最初から持つため、キャッチアップという言葉が成立する
    • 私たちの現場では置き去りにされた側がそもそもコードを書かず、共通言語は最初から存在しなかった
    • 共通言語がある組織では追いつく話で済むが、ない組織では言葉から作らなければならない
  • DX部門の存在意義:
    • この部門がAIを諦めれば、ツールは新しくなっても仕事の形は変わらず、ただのデジタイゼーションで止まる
    • それはイノベーションには繋がらない
    • まだAIを使っていない側との合流は、福利厚生でも人材育成でもなく、部門の存在意義そのものの防衛である

■ 10. 底上げは優しさではなく自衛

  • 底上げの位置づけ:
    • 置いていかれた人への優しさではない
  • 動いた3つの理由:
    • レビューが機能しない組織では、私たちの成果は正しく評価されない
    • ベテランの暗黙知は、彼らが現場を去る前にしか接続できない
    • AIを諦めた瞬間に、DX部門は存在意義を失う
  • やるべきことは教えるではない:
    • 置き去りは構造で起き、誠実な上司がいても起きる
    • 分断は時間の貧困ループで自己強化するから、放置では解消しない
    • 驚きは声になるが、あきらめは声にならない
    • そして、質問が出ない場を作ったのは私だった
  • ハンズオン教育の2つの設計:
    • 上司も含めたチーム全体へのClaude Codeハンズオン教育を始めた
    • 資料を配る方式をやめて、隣で手を動かしてもらう形にした
    • 私が講師をやらず、教えるのは私より若いメンバーに任せ、私は同席するが多くは喋らない
  • 私が教えない理由:
    • チームで一番知識のある人間が教えないのは奇妙に見えるかもしれない
    • 質問が出ない場を作ったのが自分である以上、私が前に立てば同じことが起きる
    • 教える力より、聞ける場を優先した