今、キャリアを根本から考え直している
正直に言う。ここ数ヶ月、自分のキャリアの方向性を根本から考え直していた。
きっかけはAIの進化速度だ。2022年のChatGPT登場くらいから「便利なツールだな」と思っていたのが、Claude CodeやCursorを触るようになってから明らかに感覚が変わった。「これ、もしかして仕事の前提が変わるやつじゃないか？」という感覚。
最初はその感覚を打ち消そうとしていた。「エンジニアの仕事はなくならない」「AIはあくまでアシスタント」。そういう楽観論を探して安心しようとしていたんだけど、自分でコードを書きながらAIと並走していると、だんだんそういう言い訳が通じなくなってきた。
僕の出発点はちょっと変わっている。携帯ショップに中途採用で約6年勤めてからエンジニアに転身した、完全な後発組だ。その話は後でするとして、まずひとつ言っておきたいことがある。
今回の変化は、過去の技術革新とは「桁」が違うと思っている。
クラウドが普及したとき、コンテナが登場したとき、いずれも「覚えることが増えた」という感覚だった。新しいツールを習得すれば追いつける。でも今は違う。AIが「知識を持っていること」の価値を根底から問い直している。「勉強して詳しくなること」をゴールにしてきたエンジニアとして、これはけっこう揺さぶられる話だ。
この記事は、そういう揺さぶりを受けながら自分なりに考えた思考ログだ。同じような揺さぶりを感じているエンジニアの誰かに、「ああ、同じこと考えてる人いたんだ」と思ってもらえたら十分だ。
積み上げの時代——「一つを深く掘る」戦略で生き残ろうとした
少し自分のキャリアの話をさせてほしい。
エンジニアになる前は携帯ショップ店員だった。中途採用で入社し、約6年ほど勤めた。スマートフォンが普及し始めてちょっと経った頃で、新しく入ってくる機種のスペックを覚えて、お客さんに説明するのが仕事だった。プログラミングとは無縁の世界だ。
エンジニアへの転身は完全に独学だった。学生時代にExcelのマクロでポップアップウィンドウを出して遊んでいたことをふと思い出した。そして調べてプロゲートでHTMLを触り始めたのがきっかけだ。そこから色々とあってPHPを学び、受託会社にバックエンドエンジニアとして採用された。
バックエンドエンジニアになってしばらくして、「このまま広く浅くやっていても、経験の長い人たちには勝てない」という焦りが出てきた。後発組の現実を肌で感じていた時期だ。
そこで選んだのが「一つを深く掘る」戦略だった。ちょうどDBエンジニアとしての採用の声がかかったのがきっかけだ。「DBは需要がなくならない、これで安泰だ」と思ってその道に進んだ。転職後はインデックスの仕組みや実行計画の読み方を学び、PostgreSQLが面白いと思えるくらいには仕組みを理解しはじめていた。
そんな中、会社の意向でSREへの転進を打診された。より幅広くできることが増えるならと納得して転身した。SREでは、システムの信頼性を支えるインフラ全体を見渡す仕事をしてきた。
ここまでの仕事の中で、ある問題に何度も直面した。「属人化」だ。
特定のシステムについて詳しいのが一人だけ、みたいな状況が至る所にある。障害が起きたとき、その人がいなければ誰も動けない。引き継ぎのドキュメントを書こうとしても、文章にしきれない暗黙知が大量にある。「この手順書の通りにやっても、なぜこのコマンドを打つのかを理解していないと判断できない場面がある」——そういう状況が山ほどあった。
Google SRE本の第7章（Automation at Google）では自動化を5段階で定義していて、一番下のStage 1が「手動オペレーション、特定の人が対応する世界」だ。自分が関わったシステムの多くは、正直このステージに留まっていた。改善しようと動いてはいたけれど、属人化の解消は本当に難しい問題だった。
この時代の成功法則はシンプルだった。「知識の深さ=市場価値」。深く知っている人が強い、という世界だ。
転換点——「深く学ぶ」戦略の前提が崩れていく感覚
その成功法則が揺らぎはじめたのが、最近のことだ。
きっかけは日々の業務での体験だった。「このコマンドのオプションを調べよう」とドキュメントを開こうとして、ふとAIに聞いてみる。すると数秒で正確な答えが返ってくる。「この設定のベストプラクティスは？」と聞けば、文脈を踏まえた回答が来る。初級から中級レベルの「知識を調べてわかること」は、AIがほぼカバーしてしまっている。
これは何を意味するんだろう、と考えた。
「DBならあいつに聞け」という専門性が価値を持っていたのは、その知識を持っている人が少なかったからだ。習得に時間がかかり、経験が必要で、簡単には替えが効かなかった。でも今は、基礎的な知識ならAIが即答してくれる。「詳しい人に聞く」というコストが劇的に下がっている。
「まるでマネージャーのようだ」と感じる瞬間が増えた。AIに指示して、出てきた結果を確認して、方向性を決める。実装の大部分はAIがやっている。これはエンジニアとして嬉しいことのはずなのに、どこか落ち着かない気持ちがあった。自分が積み上げてきたものって、何のためだったんだろう、という感覚。
ここではっきり気づいた。自分がやってきたのは、ひたすらHow（やり方）を覚えることだった。
技術的なHowを覚えることに注力してきた。「どうやってDBをチューニングするか」「どうやってオンコール対応するか」。でも、「なぜその構造が問題なのか」「どう設計すればスケールするのか」——そういうWhyとWhatの部分を、自分はどれだけ深く考えてきただろう？
AIが「How」を圧倒的な速度でカバーする時代に、「How職人」として戦い続けることに未来はあるのか。ここで初めて、キャリアの方向性を根本から見直す必要があると認識した。
発見——Agent Skillsとの出会いで「これだ」と思った
転換点の後、いろんな情報を漁りながら試行錯誤していた中で、Claude CodeのAgent Skillsという仕組みに出会った。
シンプルな話だ。Markdownファイルに専門的な手順や判断基準を書いておくと、AIがそれを「スキル」として使いながら作業してくれる仕組みだ。たとえば「このリポジトリでのコードレビューの観点」や「障害対応のチェックリスト」をMarkdownに書いておくと、AIがその文脈を踏まえて動いてくれる。
最初は「便利なプロンプトの保存場所だな」くらいに思っていた。でも使っていくうちに、これは単なる利便性の話じゃないと気づいた。
これまで何年も悩んできた「属人化問題」の解答がここにある、という感覚だった。
具体的に考えてみる。「Aさんしかできないオンコール対応」があったとする。Aさんの頭の中には、「このアラートが出たときはまずここを見る」「この症状のときはこのコマンドで確認する」「ここの数値が閾値を超えたら次はこう判断する」という判断フローが蓄積されている。それが属人化している本質だ。
これをSkillsとして言語化すると何が起きるか。
まず「特定の人しかできない」が崩れる。Skillsとして文書化された知識はAIを通じて誰でもアクセスできる。「Aさんが休暇中だから対応できない」という状況がなくなる。
次に「引き継ぎの困難さ」が解消される。口頭で伝えないといけなかった暗黙知が、ポータブルな資産になる。新しいチームメンバーがきても、そのSkillsを通じてAIと一緒に対応できる。
そして「スケールしない」という問題が変わる。一人のエキスパートは同時に一つのことしかできないが、Skillsとして書き出した知識は24時間、複数の場面で同時に使える。
「自動化スクリプトを書く」という従来のアプローチとも本質的に違う。スクリプトは手順を自動化できても、判断は自動化できなかった。「この数値が異常かどうか」「この状況でどのコマンドを打つか」——そこは結局、経験のある人間が見るしかなかった。Skillsはその「判断」の部分を書き出す仕組みだ。
そういえば、GoogleやAppleといったテック企業が、哲学者を正社員として雇用しているという話がある。「なぜ？」と最初は思ったが、考えてみれば納得できた。AIに「どう考えるか」を設計し、言語化できる人材が必要だからだ。思考の構造を言葉にする能力、それ自体が価値を持ちはじめている。
Agent Skillsはまさにこれと同じ構造をしている。どう判断するか、何を優先するか、どの順序で確認するか——そういう思考の骨格をMarkdownで書き出す行為だ。自分がエンジニアとして長年悩んできたのも、結局このことだった。属人化していた判断基準を、チームで共有できる形にできなかったことだ。Skillsはその問いに対する、シンプルで実践的な答えだと思った。
クラウドが普及したとき、コンテナが出てきたとき、CI/CDが当たり前になったとき——いずれも「新しいツールを覚えれば追いつける」という感覚だった。「ツールの進化」だったからだ。でも今回は違う。「知識を持っていること」より「知識をどう構造化して渡すか」に価値が移っている。これはツールの話というより、エンジニアとしての仕事の定義が変わる話だと感じた。
戦略——全員が後発組の競技場に賭ける
ここまで考えてきて、自分なりの結論が出た。
後発組の現実を直視するところから始める。CS出身のベテランエンジニアたちと、従来のスキル——コーディング力、アルゴリズム、システム設計——で正面から戦っても、勝算は低い。単純な現実として受け入れている。後発で積み上げた時間が短い以上、積み上げ勝負では不利だ。
でもAI領域を見ると、状況が違う。
AIエンジニアリング、エージェント設計、Skillsの構築——こういった領域では、経験10年のCSベテランも、僕のような後発組も、スタートラインはそう変わらない。新しい競技場だから、「以前からずっとやっている」という優位が薄い。実質的に全員が後発組だ。
そこに賭けることにした。
具体的には「AIを活かした仕組みづくり」を軸にする。AIそのものを作る（研究・開発）ではなく、AIを組み込んだシステムを設計・運用する側だ。
これまでの経験がここで活きる。DBエンジニアとしてもSREとしても、現場で繰り返し直面してきた問題の核心は「属人的な運用をスケーラブルな仕組みに置き換えること」だった。その発想は、AIを使ったSkills設計と同じ構造を持っている。「Aさんがいなくても回る」という目標が、「AI + Skills で回る」という形で実現できる。
プラットフォームエンジニアへの移行を進めているのも、同じ文脈だ。「仕組みを作る側」になること。個人の実装力より、チーム・組織全体の生産性を上げる設計力のほうを磨く方向に舵を切った。
エンジニアの役割が変わっていると感じている。実装を自分でやることが中心だった世界から、「何を作るべきか」「どう設計するか」「AIをどう使わせるか」を決める意思決定が中心の世界へ。これはマネージャーになるということではなく、「AIのマネージャー」になるということだ。
指示の精度、判断基準の言語化、システムとしての設計眼——これらがエンジニアとして求められる能力の中心になっていく、と踏んでいる。
まとめ——あらゆる経験がSkillsの素材になる
長々と書いてきたけれど、ここで言えることは3つある。
「深く学ぶこと」は無駄にならない。ただしゴールが変わった。
知識を持っていることよりも、知識をシステム化して渡すことに価値が移っている。DBを深く学んだ経験は、「DBのSkillsをどう設計するか」という形で活きる。積み上げてきたものは捨てる必要はない。使い方が変わっただけだ。
後発組は弱みではなく、「異なる視点」という武器になりうる。
携帯ショップでお客さんに説明する仕事をしていたとき、「なぜこの機能が必要か」「どう説明すれば伝わるか」を考えていた。その感覚は、AIに指示を渡すときや、Skillsで判断基準を言語化するときに意外と役に立つ。技術の外側からきた視点が、「使う人のための設計」に活きる。
あらゆる経験がSkill化の素材になる。
エンジニアリングの経験だけじゃなく、接客の経験、試行錯誤の経験、失敗の経験——全部が「どう判断するか」の言語化に使える。これまでの仕事で見てきた属人化の問題、DBチューニングで培ったデバッグの思考——これらをSkillsとして書き出すことができる。
最後に、読んでくれた人に一つだけ提案させてほしい。
自分の仕事の中で、「この判断は自分にしかできない」と思っているものを一つ見つけてほしい。なぜそう判断するのか、どの情報を見て判断するのか、例外はどんなときか——それを言葉にしてみてほしい。うまく書けなくてもいい。そのプロセス自体が、これからの時代の「スキル」になる。
AIが急速に進化する時代は、外から変わることを強いられる感覚が強い。でも、自分の経験を見直して、新しいやり方で活かすことを内発的に考えられるなら、この時代はむしろチャンスだと思っている。
少なくとも、携帯ショップ出身の後発組エンジニアはそう信じて動いている。