AI時代、「10歳からプログラムを書いています」が武器にならなくなった日
私は10歳からプログラムを書いてきました。この経歴は長い間、それだけで信頼を得られる武器でした。しかしAIが実装能力を平均化した今、経験年数だけでは差別化できません。本記事では、経験年数という武器を失ったエンジニアが、経験そのものをどう市場価値へ変えていくのか、その考え方と判断軸を整理します。
はじめに
私は10歳の頃からプログラムを書いています。
以前はこの話をすると、「10歳からですか」と驚かれました。「20年以上開発しています」と言えば、それだけで一定の信頼を得られました。経験年数が、そのまま名刺として機能していた時代です。
しかし最近、その反応は変わりました。理由はAIです。
誤解のないように先に書いておくと、私はAIを否定していません。今でも毎日AIを使って開発していますし、使わない理由はないと思っています。
それでも、忘れられない出来事があります。
ある実装方針について、私は数時間考え込んでいました。トレードオフを洗い出し、過去の似た案件を思い出しながら、どの構成が妥当かを検討していました。その内容をAIに投げたところ、30秒で、私が出そうとしていた結論とほぼ同じ提案が返ってきました。
正直に言えば、悔しかったです。
「20年以上積み重ねてきたものは、もう武器ではないのか。」
そう思いました。
ですが、この悔しさは無駄ではありませんでした。この出来事があったからこそ、「AI時代に、本当に価値があるものは何か」を考え続けることになったからです。
考え続けた結果、一つの結論に辿り着きました。
武器ではなくなったのは、経験そのものではありません。「経験年数という説明」です。
本記事では、その違いがどこにあるのか、そして経験年数という武器を失ったエンジニアが、経験をどう価値へ変えていくのかを書きます。
第1章:AIが平均化したのは「実装」であり、「経験」ではない
「いつからプログラムを書いているんですか。」
採用面接でも、商談の場でも、この質問は定番でした。そして私たちは、その質問に答えるための数字を用意していました。10年、15年、20年。経歴の長さは、技術力を保証する通貨として通用していたからです。
これを読んでいる方も、一度は経験年数を名刺代わりに使ったことがあるのではないでしょうか。私にとってのそれが「10歳から書いています」でした。
では、そもそもなぜ経験年数は武器だったのでしょうか。
答えはシンプルで、経験年数が技術力の近似値として機能していたからです。
かつて、実装力は時間でしか買えませんでした。ライブラリの挙動、フレームワークの癖、障害のパターン、設計の定石。これらは書籍だけでは身につかず、現場で年数をかけて浴びるしかありませんでした。だから発注側も採用側も、「何年やっているか」を聞けば、おおよその実力を推定できました。経験年数は、実力を測るコストを下げるための、社会的なショートカットだったのです。
AIが揺るがしたのは、このショートカットです。
今は経験数年のエンジニアでも、AIを使えば高品質なコードを書けます。知らないライブラリの使い方は数秒で出てきます。設計パターンの候補も並べてくれます。かつて丸一日かかっていたエラーの原因調査が、数分で終わることもあります。
私の感覚では、差はこう変わりました。
昔は「経験20年 ＞ 経験数年」でした。比較になりませんでした。
今は「経験20年 ＞ 経験数年 + AI」です。まだ上回ってはいますが、その差は驚くほど縮まりました。
この現実を認めるところから始めるべきだと私は思います。「AIのコードは信用できない」と言って目を逸らすこともできますが、実務では通用しません。AIが出すコードの平均品質は、経験の浅いエンジニアが一人で書くコードの平均品質を、多くの場面ですでに上回っています。
この変化は、経歴を話す場面で分かりやすく現れます。「20年やってきたんですね、すごいですね」という反応は、今でも返ってきます。ただ、そこに「でも最近はAIもありますからね」という一言が添えられるようになりました。経験年数への信頼が消えたわけではありません。ですが、その凄さの一部が、AIに持っていかれるようになったのです。
ただし、ここで一つ整理しておくべきことがあります。
AIが平均化したのは「実装」です。「経験」ではありません。
実装とは、決まったことをコードにする工程です。ここはAIの得意領域で、だから平均化しました。一方で経験とは、実装の前後にあるものを含みます。曖昧な要件から論点を切り出した回数。技術選定を誤って苦しんだ記憶。障害の夜に何を優先したかという判断。顧客と揉めた末に合意へ辿り着いたプロセス。
これらはAIの学習データには存在しません。あなたの中にしか存在しないからです。
つまり、失効したのは「20年やっています」というラベルであって、20年の中身ではありません。ラベルと中身を混同すると、「経験は無価値になった」という誤った絶望か、「AIなんて大したことはない」という誤った楽観のどちらかに落ちます。どちらも判断を誤らせます。
判断軸としてはこうなります。自分の経験のうち、「時間をかければ誰でも到達できた部分」はAIに平均化されます。「判断と責任が伴った部分」は平均化されません。たとえば「フレームワークの書き方を覚えた」は前者です。「炎上した案件で、何を切り捨てて何を守るかを決めた」は後者です。自分のキャリアをこの二つに仕分けること。それがAI時代の戦略の出発点です。
次章から、平均化されない側の中身を具体的に見ていきます。
第2章:「理解して採用する」と「理解せず採用する」の間にある断層
AIの出したコードを、そのまま採用していないでしょうか。
ここに、AI時代のエンジニアの価値を分ける最大の断層があると私は考えています。
具体例で考えます。あるBtoBシステムで、セッション管理の高速化が課題になったとします。AIに相談すると、「Redisを使いましょう」と提案が返ってきました。サンプルコードも付いていて、動かせばそのまま動きます。
ここで、二種類のエンジニアに分かれます。
一人は、動くことを確認してそのまま採用するエンジニア。もう一人は、採用する前に立ち止まるエンジニアです。
立ち止まるエンジニアは、こう考えます。
【AIの提案を採用する前に考えること】
・なぜRedisなのか。RDBのキャッシュ機構やアプリ内キャッシュでは足りない理由は何か
・このデータは消えてもよいのか。永続化は必要か
・Redisが落ちたとき、システムはどう振る舞うべきか
・運用するのは誰か。チームにRedisの運用経験はあるか
・そもそも、高速化すべきボトルネックは本当にここか
重要なのは、この問いの多くをAI自身にぶつけられることです。「なんでこの実装なの?」と聞けば、AIは理由を答えてくれます。代替案との比較も出してくれます。AIへの質問は、理解のための強力な手段です。
ですが、最終的なゴールは「AIが説明できること」ではありません。「自分が理解していること」です。
理由は明確で、その先の工程を担うのがAIではなく人間だからです。
顧客に「なぜこの構成なのですか」と聞かれたとき、説明するのは自分です。障害が起きたとき、状況を整理して意思決定するのも自分です。そのとき「AIがそう言ったので」という説明は、一度でも口にした瞬間、積み上げてきた信頼を失います。発注者から見れば、それは「この人は自分の作っているものを理解していない」という自白に等しいからです。
ここで、責任という言葉を定義し直したいと思います。
責任とは、障害対応で頭を下げることではありません。責任とは、理解した上で、自分の判断として採用することです。
障害対応は責任の結果の一つに過ぎません。本体は採用の瞬間にあります。AIの提案を理解し、顧客・チーム・運用・予算という自分の文脈に照らして妥当だと確認し、「これは私の判断です」と言える状態で取り込む。ここまでやって初めて、AIを使いこなしていると言えます。
逆に言えば、理解せず採用した時点で、そのコードの責任者は不在になります。動いている間は問題が表面化しないだけで、システムの中に「誰も説明できない部分」が増え続けます。これはある意味で技術的負債より深刻です。負債は少なくとも認識されていますが、こちらは認識すらされていないからです。
この章の判断軸は一つです。「このコードについて、顧客の前で自分の言葉で説明できるか。」説明できるなら採用してよい。できないなら、理解するまで採用を保留する。それだけのことですが、これを守れるかどうかで、数年後の市場価値は大きく変わります。
では、「理解できるかどうか」は何で決まるのでしょうか。それが次章のテーマです。
第3章:基礎力はAIを「使う」ためではなく、「評価する」ために要る
AI時代の学習論は、たいてい「AIの使い方を学ぼう」で終わります。プロンプトの書き方、ツールの選び方、エージェントの組み方。
私の結論は逆です。AIを使うからこそ、学び直すべきは基礎です。データベース、ネットワーク、セキュリティ、認証。基本情報技術者試験(FE)や応用情報技術者試験(AP)で問われるような、一見枯れた知識です。
なぜか。前章の続きで考えると分かります。
AIの提案を「理解した上で採用する」ためには、提案を評価できなければなりません。そして評価には、比較対象と判断基準が要ります。それを供給するのが基礎知識です。
先ほどのRedisの例に戻ります。
「なぜRDBではなくRedisなのか」という問いは、RDBのインデックスやキャッシュの仕組みを知らなければ、そもそも立てられません。「永続化は必要か」という問いは、Redisのデータがメモリ上にあることを知らなければ出てきません。「Redisが落ちたらどうするか」は、単一障害点という概念がなければ思いつきません。
基礎知識がない状態でAIの提案を見ると、選択肢が一つしか見えません。一つしか見えなければ比較は発生せず、評価もできず、残るのは「動いたから採用」だけです。
基礎知識がある状態では、同じ提案が「複数の選択肢の中の一つ」として見えます。ここで初めて、「この文脈ではこれが妥当か」という評価が可能になります。
つまり、基礎力は判断力の土台です。かつて基礎知識は「自分で実装するため」に必要でした。今は「AIの実装を評価するため」に必要です。用途が変わっただけで、重要度はむしろ上がっています。
もう一つ、基礎が重要になる理由があります。AIの間違い方です。
AIは、文法エラーのような分かりやすい間違いはほとんどしません。間違えるのは、文脈の穴です。認証トークンの有効期限設計が要件に合っていない。個人情報を含むログをそのまま出力している。どれも「動くコード」であり、レビューで落とすには知識が要ります。
実際にあった例を書きます。AIに書かせたLaravelのコードで、Eloquentのリレーションをループの中で呼んでいて、N+1クエリになっていたことがありました。withを一つ足せば済む話です。ですが厄介なのは、開発環境の数十件のデータでは何の問題もなく動いていたことでした。本番の数万件で初めて顕在化する種類の欠陥です。
このコードをレビューで止められるかどうかは、プロンプトの書き方とは何の関係もありません。ORMがどうSQLを発行するかを知っているかどうか、それだけです。
表面的には正しく見えるコードから文脈上の欠陥を見つける仕事は、実装というよりレビューの仕事です。そしてAI時代のエンジニアの仕事の重心は、書くことから、このレビューへ確実に移っています。レビューの精度を決めるのは、プロンプトの技術ではなく基礎知識です。
私がFEやAPの学習範囲に今も意味があると考えるのは、この理由からです。あの範囲は「広く浅い」とよく揶揄されます。ですが、AIの提案を評価する仕事は、まさに広く浅い知識の網で異常を検知し、引っかかった箇所を深掘りする仕事です。網の目が粗ければ、欠陥は素通りします。
正直に書くと、私にはずっと焦りがあります。長く使われている技術だけに頼っていては、置いていかれるという焦りです。時流を感じ取り、新しい技術やセキュリティを追い続けなければ、積み重ねた年数はそのまま力にはなりません。
たとえば同じ10年でも、一つの領域で積み重ねた10年と、インフラ・バックエンド・フロントを横断した10年とでは、できることの幅がまるで違います。問われるのは結局「何ができるか」であって、年数という見てくれの数字ではありません。
この章の判断軸です。新しい技術やAIツールを学ぶかどうか迷ったときは、「これは選択肢を増やす学習か、評価軸を増やす学習か」を考えてみてください。選択肢を増やす学習は、AIがかなりの部分を肩代わりしてくれます。評価軸を増やす学習は、あなたの判断力に直接積み上がります。迷ったら後者を選ぶ。それがAI時代の学習戦略です。
第4章:単価はコードの外側で決まる ── 判断・説明・合意・人柄
ここまで、判断力、責任、基礎力の話をしてきました。この章では、それらが実際にどこでお金に変わるのかを書きます。
単価70万円のエンジニアと100万円のエンジニアの違いは何でしょうか。私の答えは、コードの品質差ではありません。コードの外側の仕事を任せられるかどうかです。
実務のプロジェクトを思い出してください。コードを書き始める前に、いくつもの工程があります。顧客の要望は曖昧なまま届きます。「管理画面をもっと使いやすくしたい。」この一文から、誰が、どの業務で、何に困っていて、何が解決すれば成功なのかを掘り起こす。選択肢を並べ、トレードオフを言語化し、顧客が判断できる形に翻訳して、合意を作る。ここまでがコードの前の仕事です。
コードの後にも仕事があります。仕様変更の要望に対して、影響範囲を整理して伝える。障害が起きたら、技術的な事実を、相手の関心に合わせた言葉で説明する。「何が起きたか」を話したい技術者と、「業務への影響と復旧見込み」を知りたい顧客との間を翻訳する。
AIはこの工程のどこを代替したでしょうか。ほぼ、どこも代替していません。AIが平均化したのは、この長い工程の真ん中にある「実装」だけです。
だからこそ、構造的にこうなります。実装の価値が下がった分、前後の工程の価値は相対的に上がりました。単価100万円の壁は昔からコードの外側にありましたが、AIによって、それがいっそう鮮明になったのです。
エンジニアの仕事の重心が「書くこと」から「決めること」へ移っていく構造については、以前、別の記事で詳しく書きました。あのときは組織の中でレイヤーが上がる話として書きましたが、AIによって同じことが、レイヤーに関係なく起き始めています。
ここで、私がAI時代に価値が上がると考えている力を整理します。判断力、問題解決能力、コミュニケーション能力、基礎技術力、人柄、そして責任を持つ姿勢。この六つです。
大事なのは、これらが並列のリストではなく、一つの連鎖だということです。
基礎技術力があるから、選択肢を評価して判断できます。判断できるから、曖昧な問題を構造化して解決へ動かせます。自分で判断した内容だから、自分の言葉で説明でき、合意を作れます。説明と結果に責任を持ち続けるから、信頼が積み上がります。そして、その積み上がった信頼が、外から見たときに「人柄」と呼ばれるものになります。
人柄というと生まれつきの性格のように聞こえますが、実務における人柄とは「この人に任せると安心だ」という予測可能性のことです。ごまかさない。分からないことを分からないと言う。決めたことの理由を説明できる。問題が起きたら隠さず最初に報告する。どれも技術ではなく姿勢ですが、この姿勢は経験の中でしか鍛えられません。
そして単価を最終的に決めているのは、この予測可能性です。発注者の立場で考えれば当然で、月100万円を払う相手に求めているのは、コードではなく「安心して任せられる範囲の広さ」だからです。実装だけを任せられる人と、要件の整理から顧客への説明までを任せられる人では、同じコードを書いていても値段が違います。
この章の判断軸です。「自分は、プロジェクトのどの範囲までを任せられているか。」コードを書く範囲しか任されていないなら、実装力が平均化した市場で価格競争に晒され続けます。任される範囲を一つ外側へ広げること。それが、AI時代における最も確実な単価戦略です。
第5章:経験年数ではなく、経験の質を語る
最後の章では、ここまでの内容を「語り方」に落とします。
平均化されない力を持っているだけでは、市場価値にはなりません。相手に伝わって初めて価値になります。そして多くのベテランが、ここでつまずきます。力は持っているのに、語る言葉が「経験年数」しかないのです。
「20年やっています」は、今でも一定の信頼を生みます。ですが、AIという但し書きが付くようになった今、それだけで差別化できる時代ではなくなりました。問われるようになったのは、「その20年で、何ができるようになったのか」です。
だから、これからの自己紹介や商談で語るべきは、年数ではなく中身です。
text【経験の語り方を変換する】 「ECサイトを何件も作ってきました」 → 「決済処理で二重課金が起きる構造を経験したので、 冪等性の設計から入ります」 「大規模案件の経験があります」 → 「リリース直前の仕様変更で炎上した経験から、 変更が来る前提で影響範囲を分離する設計をします」 「障害対応の経験が豊富です」 → 「障害の初動では、復旧作業より先に影響範囲の特定と 顧客への一報を優先します。その順番を誤って信頼を 失う現場を見てきたからです」
変換の共通点は、「何をしたか」ではなく「何を判断できるようになったか」を語っている点です。失敗した経験。責任を負った経験。合意を作った経験。それが今、どんな判断基準として自分の中に残っているか。ここまで言語化されて初めて、経験は聞き手にとって意味を持ちます。
この言語化には、もう一つ大きな効用があります。自分の棚卸しになることです。
やってみると分かりますが、これは簡単な作業ではありません。私自身、20年を振り返って「判断として何が残ったか」を書き出したとき、最初はほとんど言葉になりませんでした。漠然と「経験がある」と思っていたものの大半は、言語化しようとすると輪郭を失いました。逆に、言語化できたものは、どの案件でも通用する再現性のある判断基準でした。
コツが一つだけあります。うまくいった話ではなく、ヒヤッとした話から思い出すことです。順調に終わった案件の記憶は薄く、判断も言葉になりにくいものです。一方で、障害や炎上、顧客との衝突の記憶は細部まで残っています。そして判断基準とは、たいていその痛みから生まれています。
手順にすると、次の四つのステップになります。この記事を閉じたあと、実際に手を動かしてみてください。
text【経験の変換シート】 STEP 1 ── 一番痛かった案件を一つ選ぶ 障害、炎上、顧客との衝突。 順調に終わった案件ではなく、今でも細部を覚えている案件を選ぶ。 STEP 2 ── あのとき、何を優先して何を捨てたかを書く 例:「復旧作業より先に、影響範囲の特定と一報を優先した」 例:「機能を削ってでも、リリース日を守ることを選んだ」 STEP 3 ── その次の案件で、何を変えたかを書く 判断基準として残ったものは、必ずここに現れる。 何も変わっていないなら、それはまだ経験になっていない。 STEP 4 ── 次の型に流し込む 「____（痛かった経験）を経験したので、 ____（今の判断基準）から入ります」
書けるものが一つでもあれば、それがあなたの新しい名刺です。逆に、どの案件を選んでもSTEP 3が埋まらないとしたら、それは経験年数の問題ではなく、振り返りの機会がなかっただけです。過去に遡って埋めることもできます。
言語化できない経験は、実は自分でも使えていない可能性が高い。言語化できた経験だけが、次の案件で意図的に再現できます。つまり経験の言語化は、営業のためのテクニックではなく、経験を資産へ変換する工程そのものです。
そしてこの言語化は、AIには代替できません。AIはあなたの現場にいなかったからです。あなたがどの案件で何を間違え、何を学び、次にどう活かしたか。その因果はあなたの中にしかなく、あなたが語らなければ、存在しないのと同じです。
この章の判断軸を置いて締めます。自分の経験を語るとき、「年数・件数・規模」で語っていたら黄色信号です。それらはすべて、AI時代に価値が下がった指標です。「どんな判断ができるようになったか」で語れているなら、あなたの経験はすでに武器に戻っています。
おわりに:経験を語る言葉を変える
「10歳からプログラムを書いています。」
以前は、この一言が武器でした。今は違います。
ですが、武器でなくなったのは私の20年間ではありませんでした。20年間を「経験年数」としてしか語ってこなかった、私の語り方でした。
AIは実装を平均化しました。この流れは戻りません。私はこれからも毎日AIを使いますし、AIの精度が上がるほど、私の仕事は速くなっていくはずです。
一方で、AIが強くなるほど価値が上がるものもあります。提案を理解して評価する基礎力。文脈に照らして決める判断力。決めたことを説明し、合意を作る力。そして、自分の判断として責任を引き受ける姿勢。どれも、経験の中でしか育たない力です。
あの日、AIに30秒で追いつかれて悔しかったのは、実装で追いつかれたからでした。ですが、実装は私の価値の中心ではありませんでした。それに気づけたことが、あの悔しさの一番の収穫だったと今は思っています。
経験年数を誇る時代は終わった。
経験で培った人間の力を語る時代になった。