ハクソク

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

AIはあなたの思考を高めるべきであり、置き換えるべきではない

5時間前原文(www.koshyjohn.com)

概要

  • AI活用によるエンジニアの分化が進行中
  • 価値あるエンジニアはAIを理解しつつ活用
  • 思考の外部委託は長期的なリスク
  • 初期キャリアほどAI依存の弊害が大きい
  • 組織の健全性維持にはリーダーシップが重要

ソフトウェアエンジニアリングにおけるAI活用の分岐

  • テック業界のエンジニアリングマネジメント間でAI活用の二極化が顕著
  • 第一のグループ：AIで単純作業を削減し、問題設定や意思決定など本質業務に集中
    • 問題の枠組み設定
    • トレードオフの判断
    • リスクの発見
    • 本質的な洞察の創出
  • 第二のグループ：AIに思考を委託し、生成物を自分の考えとして提示
    • 一見生産的・有能に見えるが、実際には成長や価値創出が停滞
  • 将来価値の高いエンジニア：AIで機械的作業を委譲しつつ、全体を理解・判断する人材
  • AI活用の姿勢がエンジニアの将来を左右

新たな失敗パターン：思考の外部委託

  • AIは既にコード生成・会議要約・設計ドラフト作成・レポート作成などを自動化可能
  • 問題点：AIによる“見せかけの有能さ”の再現が容易
    • 理解や説明ができない出力を自分の成果として提示
    • 本人の判断力や理解力が養われない
  • 知的依存が“レバレッジ”と誤認される危険性
  • 自分で考える訓練を省略すると、将来的な能力が損なわれる

優れたエンジニアが取るべき行動

  • AI活用を積極的に行うが、“使い方”が本質
    • ルーチン作業や調査業務をAIに任せ、空いた時間を本質業務へ投資
    • 鋭い問いを立てる
    • 本当の問題を定義する
    • 明快で簡潔なアウトプットを追求
    • 新しい知識や価値の創出に注力
  • AIで生まれた時間を“思考の深化”や“判断力強化”に再投資

本当の価値の源泉

  • ソフトウェアエンジニアリング＝単なるコード生産ではない
  • 本当の価値は“判断力”にある
    • 隠れた制約の発見
    • 問題設定の誤りを指摘
    • 抽象化や設計原則の創出
    • 議論を明確化し、ノイズを整理
  • AIは補助役であり、価値創出の主体ではない
  • 最も価値あるエンジニアは、AIを活用しつつ新たな知見や設計原則を生み出す人材

初期キャリアのエンジニアが直面するリスク

  • 基礎スキルは“摩擦”や“試行錯誤”からしか得られない
    • デバッグ直感
    • システム直観
    • 問題分解力
    • “なぜ動くか”を説明する力
  • AIで全てを自動化すると、学習ループから摩擦が消え、成長が阻害
  • 短期的には効率的でも、長期的には“理解力の欠如”が致命傷
  • 例え：大学でカンニングし続けて就職した人／計算機に頼り続けて数感覚が育たない人／自動運転に頼って運転スキルが身につかない人

判断力に近道はない

  • 真の習熟は“自分で考え抜く経験”からしか得られない
  • AIによる説明や出力を受け取るだけでは、判断力や深い理解は身につかない
  • 機械的作業の委譲・効率化は歓迎だが、“スキル形成”は代替不可
  • AI活用の最大の誤解は、“時間短縮＝能力向上”と錯覚すること
  • 本質は、短期的な効率化の裏で“弱い判断力・浅い理解・適応力不足”というツケが将来に回る点

まとめ：分岐線と組織的示唆

  • 分岐線：
    • AIによって理解・思考・レベルアップが促進されているか
    • AIによって理解や責任から逃げていないか
  • 前者は価値を増幅し、後者は能力を空洞化させる
  • 将来求められるのは、AIに“何を委譲し、何を自分で担うか”を正確に見極め、思考の質を高めるエンジニア
  • 今こそ、自身のAI活用姿勢を見直すべき時期

組織健全性へのさらなる重要性

  • エンジニアリングマネジメントも同じ分岐線に直面
  • AIで“理解促進”している人材と“理解の演出”をしている人材の見極めが重要
  • リーダーがこの違いを見抜けない組織は、表面的な成果や流暢さばかりを評価し、技術的深みや独自性を見逃すリスク
  • 優秀なエンジニアは、知見・設計判断・フィードバックで組織全体やAIの価値を高める存在
  • “思考の外部委託”が蔓延すると、レビューや設計議論が浅くなり、ドキュメントは綺麗でも実質が伴わなくなる
  • 結果として、組織全体の知識環境・技術的判断力が劣化
  • 真に強い組織は、“レバレッジと依存”、“加速と模倣”、“本質的能力と表面的成果”を見極めて運用
  • 採用・評価・チーム設計・文化形成の全てで“本物の理解”を重視する体制が不可欠

編集注記：本記事の内容は筆者個人の見解であり、所属企業の公式見解を示すものではありません。

Hackerたちの意見

考えられないエンジニアはたくさんいるし、AIがその点を変えることはないよ。
└
どうやって考えられないのにエンジニアの学位を卒業できるの？大学でカンニングした同僚たちも、カンニングがバレないようにするにはクリティカルシンキングが必要だったよ。これを嫌う人もいるかもしれないけど、上手にカンニングするにはかなりの思考力が求められるんだよね。
└
ちゃんと考えられないのが本当の問題みたいだね。それがSEの分野がほとんど崩壊している理由の一つだと思う。AIは助けにならない、ただ大きな混乱を遅らせるだけだよ。
現代のIDEなしでは働けないエンジニアや、メモリ管理のない言語では仕事ができないエンジニアもたくさんいるよ。GitHubやパッケージマネージャーのライブラリを使えないとかなり厳しいし。あんまり違いを感じないな。「エンジニア」という言葉も変わってきてるかもね。WebflowやWordPressしか使えない「ウェブ開発者」もいるし。
└
今のところ、ほとんどの人がこれらのモデルをローカルで動かすのは実用的じゃないと思う。クラウドサービスに依存するのは、ローカルの（おそらくオープンソースの）ツール、例えばIDEとはかなり違うからね。
└
大きな違いは、最終的にどれくらいのコストがかかるかわからないことだよ。AIを使うのにSlackのサブスクリプション代がかかるの？チームメイトのコストがかかるの？それとも、AIにアクセスできる人を雇わなきゃいけないの？
└
「エンジニア」という言葉はすでにかなり変わってきてるよ。「ソフトウェアエンジニアリング」の分野では、厳密な定義に従うと実際には誰もエンジニアじゃないからね。エンジニアは認定されていて、国によっては肩書きもついてくるし。
└
IDEは無料だし、ライブラリも無料、言語も無料。これはまるでインターネットのサブスクリプションみたいになってきて、Anthropicの思い通りになるかもしれない。ゴミ収集機と非決定的なスロップ生成器の違いは分かると思うけど、曖昧にするのは気持ちいいから、こうなっちゃった。
└
「君はどんなエンジニアなの？」 - ジェシー・プレモンスが真っ赤なサングラスをかけて
└
>「できなかった」ってこと？それとも「やりたくなかった」？キャリアの初めは、基本的に何でもやるのが楽しかったから、できないことなんてほとんどなかったよ。でも今は、できるって分かってても、やりたくないことのリストが長いんだ。ただ楽しくないからね。
だから、個人プロジェクトにはAIを使わないんだ。頭を鋭く保ちたいからね。AIを取り入れたプロジェクトなら別だけど、コーディングには使わない。でも、仕事では気にしないよ。給料をもらってるから、マネージャーがClaudeを使ってコードを書くように言ってきたら、それは彼の選択だし、技術的負債を払うのは私じゃないからね。
このポイントが（繰り返し）言われるたびに、その表現力がどんどん良くなってるのを感じる。でも、まだ完全には掴めてない気がする。つまり、まだ「名言」の段階には達していないんだよね（例えば、「メディアはメッセージである」、「組織図を出荷する」、「9人の母親では1ヶ月で赤ちゃんは作れない」など）。このような認識の彫刻には、何年も、場合によっては数十年かかるんだ。AIがそれをやってくれるわけじゃないし、私たちが意味を作る方法を知らないからね。編集：9人の赤ちゃん → 9人の母親
└
この考え方は、その段階には達しないと思う。あまりにも強く彫ると、崩れてしまうからね。普通のプログラマーがもう学ばなくなった低レベルのタスクは無数にあるし、私たちの知識のキャパは無限じゃないから、次の抽象レベルに進むためにできるだけ多くのことを外部に任せてるんだ。
└
> つまり、私たちはまだ「格言」の段階には達していない、実践を通じて学ぶんだ。
└
>「1ヶ月で9人の赤ちゃんは作れない」ってことは、「9人の女性が1ヶ月で赤ちゃんを作れない」ってことだよね。
└
「知能の増幅、人工知能じゃなくて」ってどう？「IA、AIじゃなくて」って短くもできるし、スペイン語に訳すともっと面白くなるよ。「AI、no IA」ってね。
└
手作業は外注して、頭は外注しないでね。
└
>「メディアがメッセージである」 もし100人のアメリカ人にこの格言の意味を聞いたら、マクルーハンの本来の意味を理解できる人は一人もいないと思うよ。
AIは大きく分けて2つの使い方があると思う。1) 自分が「所有」していて、完全に理解しているコードを書くのを手伝ってもらう。2) コードを書くための抽象レイヤーとして使う。コードがある意味、コンパイルの対象になる感じ。AIなしで変更を頼まれたら、他人のコードみたいに感じるだろうね。2)はプロトタイプや例、参考資料みたいな短命なものにはいいと思う。コードの質や理解度が重要じゃないからね。でも、1)が必要な仕事に対して2)を使って自分や他人を騙すと、トラブルになると思う。早くて簡単だからね。でも、それは嘘だよ。コードベースを担保に入れてるようなもんだし、こういうことをすると萎縮が始まると思う。
└
1)を楽にするために2)を使ってインフラを構築しようとするのは、たくさんのエンジニアがAIが近い未来に1)を完璧にできると思っているから、売り込みが難しいんだよね。
└
でも、担保に入れてる感じすらしないんだ。出荷や機能は問題なく見えるし、すべてが順調に見える。だけど、何かが壊れて、自分のコードをデバッグするのにまたモデルに聞かないといけないことに気づくんだ。
今のAIの使い方は、過去20年間のプログラミングよりも疲れる気がする。問題を出して、提案を評価して、これが「正しいもの」だと思うのを選んで、AIが変なことを提案するのを見て、それを指摘して、提案をちょうど良くなるまで練り直す（ここが疲れる部分）、それから提案をコードにしてもらう。コーディングは1〜5時間かかって、質的に2、3週間かかるものができる。こんな計画を5時間もやると、もうヘトヘト。プログラミングだけでこんなに疲れたことはなかったな。新しいことを学んでるのかな？マネジメントみたいな感じだね。 :)
└
AIの利点の一つは、始めて続けられることだと思う。でも、ペース配分や先延ばしが逃げ道になるかもね？
└
それ、めっちゃわかる。LLMと一緒に問題を定義して、妥当な解決策を見つけるためには、もっと「オン」でいる必要があると思う。フロー状態にはあまりなれないし、山のような出力を処理して、重要なポイントを何度も何度も見つけ出さないといけない。ほとんどいい感じなのに、ちょっと不安定な感じが常に残るのが気になる。変なエラーや推論の問題もあって、注意を払うのがすごく疲れるよね。あとは、こういうものの非人間的なコミュニケーションスタイルを解析するのも同じように大変だし…。
AIは僕のアウトプットを増幅させた気がする。やりたいことは分かってるけど、自分で全部やる時間がないからね。自由な時間に情熱プロジェクトで何ができるか見てみて（オープンソースのGoogleフォトの代替）。自分が何をしたいかははっきりしてるし、AIにそれを実行してもらってるよ：https://opennoodle.de
すごく的を射た見出しだと思う。数年前からAIには反対派だったんだけど、最近いい使い道を見つけたんだ。高価なアプリを使って、Wordでの高度なライティングチェック（主に文法チェックや言い回しの修正）をしてる。母国語じゃないのに、アメリカ英語をたくさん書くんだけど、AIのおかげで前よりずっと上手く書けるようになった。デンマーク語を書くのが思ってたよりもずっと下手だって気づいたし、実際、デンマーク人なのにアメリカ英語の方が上手く書けるってちょっと驚き。今回のエントリーを書くのにAIは使ってないけど、このライティングツールがもう大好き！友達からも、AIが長い文書を要約するのが得意だって話を聞いたことがある。だから、個人的にはAIが思考を高めることができると思ってる。今はデンマーク語とアメリカ英語の文法について、10年前よりもずっと学んでるし、ライティングが急に楽しくなったのはスキルが成長するからだね。
なんでAIに考えることをアウトソースしちゃいけないのかわからない。AIがもっと能力を持つようになったら、最終的には平均的なエンジニアよりも優秀になると思う。その時、企業はAIに大きな決定をさせるべきだよね。今年の終わりには、AIが最高のエンジニア以外には勝ってるかもしれない。そしたらどうするの？
└
それ、1年のデータに基づいたかなりの推測だね。実際にはまだ結果が出てないのが主な問題だと思う。
numbaを再構築してるんだけど、手作業でやるのは想像もつかない。数年前にやってみたけど、すごく苦痛だった。遅いし、めちゃくちゃだった。何年もかけて積み重なった小さなことがたくさんあるからね。今はLLMを使って再挑戦してるけど、正直、数週間かかってたことが一晩で終わるようになった。ただ、生成されたCの出力やコードを確認しなきゃいけないし、将来的に自分とLLMが使いやすいようにアーキテクチャをコントロールする必要もある。これが自分の考えを置き換えてるのかはわからない。手動で何ヶ月もかけて書き直してたら、コンパイラやトランスパイラについてもっと学べたかもしれないけど、それだけに集中することになってたと思う。代わりに、Golangでカスタムファイルシステム用のカスタムNFSサーバーのサポートを書く時間もあったし。