Zennでこんな記事を読みました。
⇒ なぜ、ITの職場において低スキル者を排除することが成功のために重要だと誰も言わないのか？
タイトルだけ見ると、いかにも角の立つ話です。実際、職場で口に出したら空気が凍るでしょう。
ただ中身は、能力の優劣ではなく配置の話でした。そして読み進めるうちに、妙な気分になってきまして…。
私、これとほぼ同じことを、まったく別の入口から書いていたんですよね。
定義が、私の「見分けポイント」と丸かぶりだった
元記事の一番の肝は、冒頭の定義だと思っています。
自分の誤解を検知できない、指摘を吸収できない、分からないことを分からないと言えない。この自己修正能力の欠如こそが、本稿で扱う低スキルの正体です。
作業が遅いことではない、と最初に切っている。ここが上手いところで、「遅い」は納期と範囲を調整すれば何とかなります。どうにもならないのは上記の部分。
これに対し、私が以前 【非エンジニア向け】AIを使いこなせる人材の見分け方 に書いた「見分けポイント」を並べてみます。
- 同じ指摘を3回した時、その人が何をするか。4回目も同じ指摘をする羽目になるなら向いていない
- 「あと何が残ってますか？」に「ほぼ完成です」しか返ってこないなら危険
- 先週と同じ愚痴が今週も出てくるなら赤信号
誤りの反復・分からないと言えない・指摘を防衛で返す。元記事の挙げる兆候そのものです。
こちらは「AIを使いこなせる人の見分け方」として書き、あちらは「誰を重要工程に置くかの判断基準」として書いている。入口が全然違うのに、同じ場所に出ました。
AIは、兆候を早く濃く出す
ではAI時代になって、この話は薄まったのか？ 逆です。
昔の低スキル者は、穴を掘るのが遅い人でした。今の低スキル者は、ユンボに乗って猛スピードで、要らない場所に間違った穴を掘ります(汗)
私は以前、バイブコーディングで作られたアプリを、ゼロから作り直す という仕事をしました。作り直した理由は、動いていなかったからではありません。動いているように見えていたからです。
理解の浅い人の成果は、以前なら「半人前の成果物」として出てきました。量が少ないので、周りも気づけた。
今は違います。AIが乗るので、一人前の速度で、検証されていない成果物が出てきます。画面は動くし、ボタンも押せる。本人も本気で「もう8割できてる」と思っている。
元記事は、理解不足や判断ミスが周囲の確認・修正・説明の負担として溜まっていく現象を「認知負債」と呼んでいます。
これはAIが来ても消えていません。出力が増幅されたぶん負債も増幅されて、しかも見た目がきれいになって出てくるからタチが悪い。
動いて見えるものを止めるには、こちらが中を全部読むしかない。読んだ結果「作り直した方が早い」になる。この作業、進捗表には1行も出てきません(笑)
「仕組みで吸収すればいい」の限界線は、AIで動いたのか
元記事には、耳の痛い一節があります。
能力不足を隠すための標準化は、職場全体を低い水準に合わせます。優秀な人は余計な手続きに縛られ、低スキル者は本質を理解しないまま手順だけをなぞります。
分かります。分かるんですが…私はAIに対し、CLAUDE.md だの SKILL.md だののルールファイルを書きまくっている側の人間です(汗)
「それ、あなたが同意してる標準化そのものでは？」と言われたら、返す言葉がある…と思っています。あると思わせてください。
人間向けのチェックリストが機能しないのは、人間が手順を理解しないままなぞるからです。なぞった結果、なぜその手順があるのかは誰も知らないまま項目だけが増えていく。
AIは、そこがまったく違います。理解こそしませんが、書いてあることは何度でも同じように読みます。同じ指摘を100回されても疲れないし、腹も立てない。※こちらの財布は痛みますが。
つまりAIは、「手順化で吸収できる能力差」の上限をそこそこ引き上げました。ここは素直に認めていい部分だと思っています。
分かれ目が、1段ずれただけ
そのルールファイルを書けるかどうか自体が、自己修正能力の試験になっている。 プログラマーの三大美徳とHRTの記事 で書いた通り、◯◯.md が育つのは勤勉だからではなく、同じ説明を3回するのが面倒くさいからです。
AIが間違えるたびに律儀に手作業で直す人と、直した基準をファイルに書く人。この2人は、来月には別世界にいます。
AIは能力差を埋めませんでした。埋めたように見せて、判定を数ヶ月ぶん早めただけです。
育てないとは言っていない
必ず「人を育てないのか」が来るので先に。先日 AI未経験の人を約1週間でHP制作者に仕立て上げる という事をやりましたが、あれは失敗しても誰も困らない場所でやりました。本人の趣味のページを作らせ、盛大にAI臭を放つ物を出させ、それを教材にしています。
新人を要件定義の主担当に置いて「実戦で育てる」と言うのは、育成とは呼びにくい。損失を顧客と後工程に付け替えているだけですので。※そして請求書はだいたい現場に届きます。
それ、50年前の本に書いてあります
最後に。この「排除」という言葉、強すぎて損をしていると思うんですよね。
『人月の神話』を読み直した記事 で、ブルックスの「外科手術チーム」を紹介しました。10人チームでも、切るのは執刀医1人だけ。残り9人は全員、その1人が切ることに集中できるように支える。
なぜそこまでするかというと、設計する頭が増えるほどシステムが継ぎ接ぎになるからです。ブルックスはこれを概念的完全性と呼びました1。
これは要するに、「重要工程には適性のある人を置き、他の人には影響範囲を制御した仕事を与える」という話です。元記事の結論と、使っている言葉が違うだけですよね。
50年前の本には堂々と書いてある。海外の技術書にも書いてある。なのに会議室では誰も言わない。元記事が指摘している通りです。
かく言う私も、職場で言う気は1ミリもありません。角が立つので。
この記事も、Qiitaだから書けています。ゴメンナサイ。
-
ついでに言うと、人を足すと増えるのはコミュニケーションパスで、
n(n-1)/2で膨らみます。低スキル者を1人足すと、パスが増えるうえに1本1本が重くなる。二重に効きます。 ↩