はじめに
こんにちは、Watanabe Jin(@Sicut_study)です。
AIエージェントが開発を行うようになり、多くのエンジニアがClaude Codeなどを利用して仕事を進められるようになりました。
しかし、便利になったと感じると同時に、こんな瞬間はありませんでしたか？
- なぜそう動くのか、人に説明しろと言われると詰まる
- AIに仕事を奪われるのではないかと最近感じることが多い
- 一年前と比べてスキルがついた実感がない
私はプログラミングコミュニティを運営したり、メガベンチャーで働いていく中で、AIが本格的に普及したこの半年でもエンジニアのキャリアははっきりと分かれていると感じています。
一部の人は、AIを使いながらも「何を解決すべきか」を自分の頭で考え続け、どんどん力をつけている。
一方で、多くの人は、AIに指示を出す作業そのものが仕事になり、気づけば「考えているようで、考えていない」状態に陥っている。
AIで開発スピードが加速したので考える時間は少なくなり、とにかくタスクをこなすことに時間を使っていてスキルが身につかない。
今回は、この分かれ道の正体が具体と抽象という思考の力にあるという話をしていきます。
具体の仕事が、なぜこんなにも多かったのか。エンジニアの現場を考えると、それがあなたの能力の問題ではなく、業界の仕組みとしてそうなっていたことが見えてきます。
その仕組みの上にAIが乗ったとき、何が消えて、何が残るのか。
コードが書けるようになった今だからこそ、自分の仕事が「あなたじゃなくてもいい仕事」なのかどうかが、はっきりしてきます。
ここ半年間多くのエンジニアを見てきて、まさに今エンジニアとして活躍できるのかどうかの分かれ道が来ていると感じます。
なぜシステム開発が具体の仕事が多かったのか？
AIで仕事は本当になくなるのか？
どのようにすればエンジニアとして活躍できるのか？
具体と抽象を中心としながら話していきます。
動画でも解説
この記事の内容は動画教材も用意していますので合わせてご覧ください
この記事の対象者
- AIでコードが書けるようになった今、自分のキャリアに漠然とした不安がある人
- 設計や上流工程に踏み込みたいが、何を勉強すればいいか分からない人
- 「具体と抽象」という言葉は聞いたことがあるが、実務にどう活かせばいいか分からない人
- ジュニアからミドル、ミドルからシニアへとステップアップしたい人
なぜAIでエンジニアの仕事がなくなるのか？
不安の正体は、仕事がなくなることではありません。
具体の仕事が、業界の仕組みとして多かったことです。
システム業界では、SIer(システムインテグレーター)のビジネスモデルが多くあります。
そこにはSESから派遣されるという形で働いている人も多くいて、エンジニアの大部分を占めています。
SIerのビジネスモデルは「人月商売」と呼ばれることがあります。
1人のエンジニアが1ヶ月稼働するコストを単位に、「人月単価×人数」で売上を計算する仕組みで、これは建設業界の工数計算とよく似ています。
この構造から「ITゼネコン」とも呼ばれることがあります。
建設業界のゼネコンと同じく、案件を受けた元請けが工程を分割し、下請け企業へ再発注していく多層構造です。実際に手を動かすのは、三次・四次下請けやSESの技術者であることが多いのが実情です。元請けはプロジェクト全体の管理や要件定義・基本設計といった上流(抽象)工程を担当し、実際の開発作業の多く(具体)は下請け企業に委託されます。
つまり、上流(抽象的な問題発見や設計)は元請けが、下流(具体)は下請けが担う、という構造が、業界の仕組みそのものとして組み込まれてきたのです。
SIerでは仕様書通りにやることが善であり、このコードはこうしたほうが良いと思いますという意見も却下されて、言われたとおりにやればいいんだと言われることもしばしばあります。
大規模なシステムには、圧倒的な人数を投下する。これが日本のIT業界の体質でした。
しかし、この「具体」の部分を、AIが代替し始めています。
コーディングという作業そのものは、現時点でも確実にAIに奪われつつあります。
エンジニアの誰もが「自分たちの仕事はなくなるのか」と一度は考えたことがあると思います。
ではエンジニアの仕事は本当になくなるのでしょうか？
私はそうは思いません。
むしろ、仕事の総量は増えると考えています。
効率化のたびに、仕事は増えてきた
経済学に「ジェヴォンズのパラドックス」という有名な法則があります。
蒸気機関が効率化されて、石炭消費は減るはずだったのに
実際は、爆発的に増えた。
効率化によって使い道が広がり、全体の消費量が増えていったのです。
19世紀、イギリスの経済学者ウィリアム・スタンレー・ジェヴォンズが指摘した話です。
実は、エンジニアの世界でも何度も起きています。
ノイマン型コンピュータが登場したときも、同じです。
当時、コンピュータという言葉は機械ではなく、計算する人間の職業名でした。
弾道計算や天文計算を、手作業で分担する計算手です。
ENIACの時代、プログラムは配線盤のケーブルを差し替えることでした。
変更に数日かかる世界です。
そこにノイマンが、プログラムをメモリに置くプログラム内蔵方式を提唱しました。
機械を配線し直さなくても、プログラムを書けば動くようになり、計算は一気に速く、安くなりました。
計算手という職業は、たしかに消えました。
計算する仕事は機械に移りました。
しかし、プログラムを書く人が生まれ、コンピュータが使える場所そのものが広がっていきました。
その後も、10年に一度くらいのペースで、同じことが起きています。
1950年代末、FORTRANとCOBOLが登場したときが、最初のプログラマ不要論です。
COBOLは英語に近い文法で、当時は自動的にコードを書いてくれるツールと呼ばれていました。
事務員でもプログラムが書けるようになり、プログラマはいなくなる、と言われました。
1990年代には、Visual BasicやDelphiといったIDEツールが登場します。
画面をドラッグ＆ドロップで組み立てられるようになり、また「これでプログラマーはいらない」と言われました。
でも、結果は逆です。
アメリカでは、プログラマとアナリストを中心としたコンピュータ専門家が、1960年の約1.2万人から1980年には約58.5万人まで増えています。
コードを書くのが楽になった分、ソフトウェアを入れる場所が増え、直す場所が増え、作るものが増える。
COBOLのとき、プログラマの仕事は「機械を理解すること」から「ビジネスを理解すること」へ、一段抽象度の高い側へ移りました。
つまり、AIもこの延長線上にあります。
NVIDIAのCEO、ジェンスン・フアンは2024年にこう言いました。
これからはPythonもC++もいらない。普通の人間の言葉でコンピュータを動かせるようになる。
COBOLの「英語を書けば事務員でも足りる」と、同じ型です。
効率化のたびに仕事は増えてきた。今回も同じです。
今回のAIだけは違うと感じるかもしれない。
昔のエンジニアも、同じことを思っていたのです。
エンジニアは仕事からタスクに移り変わる
仕事の総量は、増えます。
ただし、増える仕事の中身は、同じではありません。
増えるのは、人がたくさん必要なタスクです。
AIが書いたコードの確認、つなぎ、直し、運用。
細かく割れて、人数を投下しないと回らない仕事です。
一方で、何を解決すべきかを自分の頭で決める人はごく一部になります。
それが、これまでのエンジニアの仕事でした。
実は、いまエンジニアの現場でも同じことが起きています。
これまでのエンジニアの仕事は、要件を理解し、設計を考え、実装し、動かして確かめる。
この一連の流れを自分の頭でつなげる仕事でした。
考える力、つまり創造性を発揮する場面が、あちこちにありました。
いまは、AIがその「考える」部分を先に済ませてしまいます。
人間は、思っている以上に考えなくなっています。
プロンプトを投げて、出てきたものを受け取り、次のプロンプトを投げる。
これが仕事の中心になりつつあります。
しかも、開発のスピードはどんどん上がっていきます。
速く終わらせることが求められるほど、立ち止まって考える時間は削られます。
目の前のタスクをただ消化することが仕事になっていきます。
これまでのように、考えながら仕事をするということが、環境そのものとしてできなくなっているのです。
速くなった感覚と、実際に理解が進んでいるかどうかは、別のものです。
MetaがAIツールを使う実務経験者を対象に行ったランダム化比較試験では、開発者は自分では速くなったと感じていたにもかかわらず、実際には19%遅くなっていたという結果が出ています。
ここに関しては以前に私がt-wadaさんの「質とスピード」を現代的に考えた動画を作ったのでぜひ見てください。
考えるのも面倒になってきてもいる感覚がしています。
一度AIが書いたコードをちゃんとみたいとも全く思わなくなり、気づいたらAIになんとかしてもらって問題がおきたらAIになんとかしてもらう。
おそらくこの先待っているのは、AIが書いた複雑なコードを、自分では書いていないまま直す仕事です。
修正するにも多くのやり取りが必要で、エラーや不具合が起きるたびに、プロンプトを送っては直す。
そんな時間のかかるタスクです。
コードを理解していないのだから、仕方ありません。
そういう仕事は、人がたくさん要ります。だから増えます。
増えるのはタスクです。問題解決をするエンジニアは、ごく一部になります。
この状態には、名前がついています。
オードリー・タンさんは、AIが考えて人が従う状態を「逆ケンタウロス」と呼んで警告しています。
ケンタウロスは、人が頭で考え、機械が力を足す姿です。
逆ケンタウロスは、機械が決めて、人が手足として動く姿です。
プロンプトを投げて、出てきたものを受け取って、また投げる。
頭はAIで、手足だけが自分、になっているとしたら、それが逆ケンタウロスです。
果たしてあなたはどちらになるのでしょう。
具体と抽象とは？
この分かれ道を見る軸が、具体と抽象です。
あなたがAIを操っているのか、操られているのか。
その差は、一段上の階段にいるかどうかです。
柴犬もトイプードルも三毛猫も、それぞれ違う一匹です。これが具体にあたります。
その3匹に共通するものだけを取り出した「動物」という言葉が、抽象となります。
ただ、具体と抽象には、もう少し踏み込んでおきたい性質が3つあります。
1つ目は、具体と抽象に絶対的な境目はない、ということです。
『具体と抽象』という本を書いた細谷功さんは、「おにぎりは具体か抽象か」という問いを立てています。
目の前にある、ラップに包まれた鮭おにぎり1個だけを見れば、それは具体です。
でも「おにぎり」という言葉自体は、無数のおにぎりから共通点を取り出した抽象概念でもあります。
さらに一段上から見れば、おにぎりは「米料理」の一種であり、「炭水化物」の一種でもあります。
つまり具体と抽象は、白か黒かで分けられるものではなく、階段のように何段も重なっています。
ある段から見れば具体でも、もう一段上から見れば、それ自体がすでに抽象なのです。
2つ目は、議論がかみ合わない理由の多くが、この階段のどの段で話しているかのズレだ、ということです。
「もっと丁寧に仕事をすべきだ」という抽象度の高い主張に対して、「具体的にどのタスクのことですか」と聞き返す。
どちらも間違っていないのに、話がかみ合いません。
これは、片方が階段の上の段で、もう片方が下の段で話しているからです。
エンジニアの現場でも、この行き違いはよく起きます。
「なぜこの設計にしたんですか」という抽象度の高い問いに対して、「このメソッドはこう書きました」という具体のレベルでしか答えられない。
段がズレたまま話しても、いつまでもかみ合いません。
3つ目が、上の段は、下の段から見えないということです。
細谷さんはこれを「マジックミラーの法則」という言葉で説明しています。
抽象度の高い人からは、具体のレベルで何が起きているかがよく見えます。
しかし、具体のレベルにいる人からは、その上に何があるのか、そもそも見えていません。
自分が今どの段にいるのか、下からは分からない。
これが、具体だけで仕事をしている人が「自分には何が足りないのか」に気づきにくい理由です。
見えていないものを、目指しようがないのです。
具体と抽象は、才能で分かれるものではありません。ただ、上の段は自分から意識して登らないと、一生見えないままです。
ここからは、この階段がエンジニアの現場で何を分けるのかを見ていきます。
なぜ今、エンジニアの格差が急速に広がっているのか？
抽象を使ってきた人と、使ってこなかった人の差が、AIで一気に開いています。
中学・高校と6年間英語を勉強したのに、社会人になって使わなくなったら、簡単な単語すら出てこなくなった。
そんな経験はないでしょうか。
あれだけ時間をかけて覚えたはずなのに、使わなければ抜け落ちていく。
ちょうど、筋肉と同じです。
使えば強くなり、使わなければ衰えていきます。
実は、この構図が、抽象化の力にもそのまま当てはまります。
前に話した通り、SIerの下請けという現場は、上流(抽象)を元請けが、下流(具体)を下請けが担う構造になっていました。
仕様書通りにやることが善とされ、「こうしたほうがいいと思います」という提案は、たいてい通りません。
言われた通りに、言われた分だけ作る。それが評価される現場です。
ここで働いてきた人は、悪いわけではありません。
ただ、抽象を使う機会そのものを、構造的に与えられてこなかったのです。
そこに、AIが入ってきました。
抽象をすでに使っていた人にとって、AIは強力な武器です。
設計や問題発見という、もともと自分の頭でやっていた仕事に、より多くの時間を使えるようになります。
抽象を、さらに使い続けられます。
一方、抽象を使う機会がなかった人にとって、AIは最後の具体作業まで奪っていきます。
仕様書通りに実装することが仕事だった人から、その実装さえもAIがやるようになる。
残るのは、AIに指示を出し、出てきたものを確認するという、さらに受け身のタスクです。
最近、経営者自身がClaude Codeでコードを書き始めるケースが増えています。
エンジニアはもういらないんじゃないか
これは象徴的な出来事です。
経営者は、もともと事業や顧客の課題という抽象側を扱う仕事をしてきました。
足りなかったのは、それを形にする具体、つまり実装の手数だけです。
AIが実装を肩代わりしてくれるようになったことで、その最後のピースが埋まり、経営者自身が一気にプロダクトを作れるようになりました。
ビジネスが一気に動き始めたのは、抽象側の力を持つ人から、具体という制約が外れたからです。
これは、FDEにもそのまま表れています。
現場に入って、課題の発見から設計・実装まで一気通貫で担う人です。
そういう人は、AIによって身動きがさらに軽くなります。
抽象の仕事をしていた人ほど、具体に時間を使わずに済むようになり、勝ちがさらに広がっていく構造です。
これは、能力の差ではありません。
スタート地点の差が、AIによって掛け算のように広がっている、という話です。
もともと抽象を使う側にいた人は、AIを味方につけてさらに加速する。
もともと具体しか任されてこなかった人は、その具体さえAIに奪われ、最後にはAIにプロンプトを打ち込む仕事しか残りません。
同じ会社の同じチームにいても、この2つの曲線は、もう別の速度で進み始めています。
さらに、厄介なことがもう一つあります。
この差は、気づいてから慌てて取り戻そうとしても、簡単には縮まりません。
英語も、単語帳を読み直せば喋れるようになるわけではありません。
実際に声に出して、間違えて、言い直す。
その繰り返しがないと、感覚は戻ってきません。
抽象化も同じです。
「具体と抽象は大事らしい」と本で読んで知識を増やしても、それはスタートラインに立っただけです。
自分の頭で何かを実際に抽象化し、それをまた別の形で具体化する。
この動きを自分の手を動かして繰り返さないと、スキルにはなりません。
しかも一度身につけても、使わなければまた同じように衰えていきます。
つまり、格差が生まれる理由と、その差が縮まりにくい理由は、同じ根っこから来ています。
「使ってこなかったこと」自体が、次の一歩を重くしているのです。
AI時代でも仕事を奪われないエンジニアとは？
仕事を奪われない人は、抽象の仕事をしている人です。
言語やフレームワークの知識があるのは、大前提です。
AIがなくても使える、本質的な知恵が土台にあり、そのうえに抽象の仕事は成り立ちます。
それがないと、AIが出したコードが正しいかどうかも、判断できません。
最近はエンジニアだと仕事無くなりそうだから、PMや上流の仕事を希望する人が増えているようです。
ただ、具体ができないのに抽象をやることは、マジックミラーの原則から考えても無理な話です。
具体は、この言語で書く、このライブラリを使う、この書き方をする、という一つひとつです。
抽象は、何を解決するのか、どこに境界を引くのか、なぜこう作るのか、という共通点を取り出す側です。
エンジニアの多くは、いまAIのツールを調べて使う、といった具体ばかりしています。
ツールは時代とともに変わります。
具体だけを追っていると、ずっと勉強していないといけなくなります。
抽象の側にいれば、言語が変わっても問題ありません。
具体をやるのは簡単です。
必要なものを学べば使えるし、AIに指示すればやってくれます。
エンジニアとして今後更に活躍していきたいと思うのであれば、抽象のスキルをつける必要があります。
そのためには、具体の本質的なスキルを素早く身に着けて、前の章で話した抽象の階段を、一段上がる必要があります。
これが最初の分岐点です。
この時点でAIが発展して学ぶ機会が減った現代で、具体の本質スキルが身に付けられず諦めていきます。
次の分岐点は、そこから抽象の階段を1つ登るための練習ができるかどうかです。
AIは、具体の手数を肩代わりします。
文法も、よくある書き方も、かなりの部分をやれます。
でも、何を作るべきかは、人間が決めないといけません。
現場の業務の本質は、もともとデータになっていません。
だからAIの学習データにも、入りようがないのです。
残るのは、抽象的な仕事です。
問題を発見する。設計する。トレードオフを判断する。
これは、人間がする仕事です。
言語やフレームワークを知っていることは、スタートラインです。
そこから一段、抽象の側へ上がった人だけが、AIに仕事を奪われません。
AIに奪われないのは、一段上の階段にいる人です。
エンジニアに求められる抽象力の正体
一段上の階段にいる人がやる仕事。その正体は、設計です。
設計のなかでも、問題解決につながるドメインモデリングが重要です。
ドメインモデリングという言葉を、初めて聞く人も多いかもしれません。
ドメインとは、そのソフトウェアが扱う世界のことです。
通販なら「買う・届ける・会員」の世界。
スーツ店なら「採寸して、服を仕立てる」の世界。
プログラムの話ではなく、現場の話です。
モデルとは、その世界の見取り図です。
全部は描けません。
だから、このシステムに本当に必要な要素を現実世界から抽出して表現します。
モデリングとは、その見取り図を作る作業です。
頭の中にある「現場はこうなっている」というメンタルモデルを、言葉と構造にします。
ドメイン駆動設計の生みの親であるエリック・エヴァンスは、こう定義しています。
モデルは、ドメインの選ばれた側面を記述する抽象のシステムである。
すべてをモデル化するのではありません。
選ばれた側面だけを切り取る。
その切り取りを、現場の人たちが頭の中で持っている見方と一致させること。
それが、ソフトウェア設計の狙いだとエヴァンスは言っています。
この「何を選び、何を捨てるか」を決める側が、戦略的設計です。
コアになる問題はどこか。
モデルの境界はどこまでか。
全部を同じ重さで扱わない。
核だけを濃くモデルにする。
クラスをどう分けるかより先に、まずこの切り取りがあるのです。
たとえば、ECサイトには「ユーザー」という概念があります。
ユーザーに入っている要素は、名前や年齢です。
では、あなたの左手の長さは、ユーザーにいるでしょうか。
腕の長さはいらないですよね。
でも、これがオーダーメイドのスーツのサイトだったらどうでしょう。
左手の長さは、必要になります。
つまり、ドメインモデリングとは、どのように問題を切り取るかという作業です。
エヴァンスの言う「選ばれた側面」です。
同じ「ユーザー」でも、切り取り方で中身が変わる。
何を残して、何を捨てるか。
そこが、設計なのです。
ドメインこそが、商品の勝ちになります。
フレームワークでも、きれいなコードでもありません。
どの問題を解くかを決めること。
それが、問題解決です。
この切り取りは、AIにはできません。
仮に、目の前にカメラがあって、AIがリアルタイムで見ていたとしましょう。
そこに、私がスマートフォンを触っている写真がある。
では、ここで何の問題を感じているでしょう。
分かりません。
充電がなくなっている可能性もある。
画面が割れている可能性もある。
スマホが重いと思っている可能性もある。
同じ光景を見ていても、問題は一つに決まりません。
問題を掴むこと自体が、AIには無理なのです。
だから、それは人間の仕事です。
これから求められるのは、抽象的な問題発見のスキルです。
そして、自分たちが心に持っているメンタルモデルを、いかに言語化するか。
言語化したものを、いかにコードに閉じ込めるか。
ここの作業が、めちゃくちゃ重要です。
コードに書くこと自体は、具体です。
だからAIにもできます。
でも、そこに至るためのメンタルモデルを、どういう言葉にするか。
ここが超重要です。
言葉にできて初めて、コードという具体に落とせる。
言葉にできないものは、AIに渡すことすらできません。
設計が大事です。その中心にあるのが、ドメインモデリングです。
問題を切り取り、メンタルモデルを言語化し、コードに閉じ込める。
この一連をやる人が、一段上の階段にいます。
具体抽象を身につける大事な考え方
本を読むだけでも、普段から意識するだけでも、具体抽象は身につきません。
具体と抽象の本は、たくさんあります。
しかし、本そのものが抽象の話が多く、読んだあとに実践し続けられる人はほとんどいません。
結局のところ、普段から使わざるを得ない環境にいるからこそ、強制的に身についていくのです。
しかし、システム業界の構造では、話は別です。
具体の作業が上から降りてきて、創造性を発揮できない仕組みになっていたことを、前に話しました。
日常の中で自然に身につかない場合、どうすればよいのでしょうか？
重要となるのはマジックミラーの法則です。
上の段は、下の段から見えません。
見えていない段の登り方を、自分だけで意識しても、やり方がわかりません。
何を抽象にすればいいのか。
どこまで具体に落とせばいいのか。
その段差そのものが、見えないのです。
だから、具体抽象をスキルとして身につけるのが難しいのです。
では、どうすればよいのか？
答えは簡単です。
一段上の抽象ができる人に、階段を具体まで落としてもらい、登り方を体験として教えてもらえばよいのです。
知識として教わっても、本を読んでいるのと変わりません。
経験して、階段の登り方を理解するのです。
自転車に乗ったことがない人が、いくらYoutubeの動画で乗り方を見ても、乗れるようにはなりません。
実際に乗って学んでいくことが大事です。
一段上の階段も、同じです。
上から見える人だけが、「今のあなたの話は、この段だ」と指を差せます。
具体抽象は、身につけるのがとても難しいスキルです。
だからこそ、身につけたらエンジニアとしてはトップに立てます。
AIにも、奪われません。
そして今の時代、この難しいスキルを、いかに早く身につけられるかが、大きな分岐点になっています。
AIによって、仕事の構造がいつ変わるかわかりません。
明日にも、変わるかもしれません。
一人で本を閉じて「意識しよう」では、間に合いません。
一段上の人に階段を落としてもらい、自分の仕事という具体のうえで往復する。
その実践の場が、要るのです。
今の分岐点は、この難しいスキルを、いかに早く、実践で身につけられるかです。
おわりに
今回は、具体と抽象を中心に、AI時代のエンジニアの仕事について話してきました。
具体の仕事が多かったのは、あなたの能力の問題ではありません。
上流は元請け、下流は下請け、という業界の仕組みそのものでした。
効率化のたびに、仕事の総量は増えてきました。
ただし、増えるのはタスクです。
問題解決をする人は、ごく一部になります。
残るのは、抽象の仕事です。
設計です。
その中心にあるのが、ドメインモデリングです。
ドメインの切り取りこそが、商品の勝ちになります。
でも、本を読むだけでも、普段から意識するだけでも、具体抽象は身につきません。
上の段は、下から見えません。
一段上の人に階段を落としてもらい、体験として登るしかないのです。
抽象力を身につけないと、「あなたじゃなくてもいい仕事」の方に、だんだんと流されていきます。
まずは、自分の仕事の中で一つでいいので、「なぜ」を掘り下げてみてください。
「何を作ればいいですか」ではなく「何を解決したいんですか」と、自分に問い直してみてください。
この記事をレビューしてもらうにあたって、実際に具体抽象のスキルを、ワークで学ぶ機会がほしいというコミュニティのメンバーから要望を受けました。
なので、9月27日（土）に、勉強会を開催することにしました。
オンラインもあります。
来れる方は、来てください。
ここまで読んでいただけた方はいいねとストックよろしくお願いします。
また明日の記事でお会いしましょう！
JISOUのメンバー募集中！
プログラミングコーチングJISOUでは、新たなメンバーを募集しています。
日本一のアウトプットコミュニティでキャリアアップしませんか？
興味のある方は、ぜひホームページからお気軽にカウンセリングをお申し込みください！
▼▼▼
図解ハンズオンたくさん投稿しています！