営業やマーケティングの担当者が、自分で簡易的なコードや自動化スクリプトを書くようになりました。これまでエンジニアに依存していた小規模な案件が、社内で片づくようになっています。
Ragate代表の益子竜与志は2025年10月16日のブログで、この状況を前提に、エンジニアの差別化要因がどこへ移るのかを整理しています。運用保守の現場から次のキャリアを考えている人にとっては、どこに時間を使うべきかの地図になる内容です。
個別最適から、組織全体の最適化へ
まず指摘されているのは、仕事の単位が変わることです。
非エンジニアがエンジニア領域に入ってくる時代には、エンジニアは個別最適から組織全体の最適化へシフトする必要がある。具体的には、全社アーキテクチャの設計、セキュリティの策定、システム連携基盤の構築が専門領域になるべきだ、と書かれています。
一つのシステムを速くつくる力から、複数のシステムが噛み合う状態をつくる力へ。守備範囲が広がる方向です。
課題定義力と、構造化思考
そのうえで、差別化要因として最初に挙げられるのが課題定義力です。
顧客の表面的な要望ではなく、本質的な経営課題を見抜き、技術で解決可能な形に構造化する能力。記事では「システムが遅い」という訴えの背景に業務プロセスの非効率が隠れている、という例が出てきます。速度を改善しても、本当の問題は解けないかもしれない。
Ragateでは必ず経営課題からプロジェクトをスタートさせる、と明記されています。
引き出しの多さと、深さの両方
課題を構造化したあとに要るのが、それを解決する手段の知識です。
サーバーレス、コンテナ、マネージドサービスといった幅広い技術領域への精通に加えて、各技術の適用限界や実装パターンについての深い専門性が必要になる。広く知っているだけでは選べず、深く知っているだけでは選択肢が足りません。
そして、生成AIの出力は参考値に過ぎない、という一文が続きます。ビジネスコンテキストに合わせた判断ができるエンジニアが求められている、と。
生成AIは、使い手の思考レベルを超えない
この記事で繰り返し出てくるのが、この認識です。
生成AIは道具であり、使い手の思考レベルを超えない。深い専門性を持つエンジニアだけが質の高いプロンプトを書き、高度な出力を引き出せる。表面的な知識では表面的な回答しか得られず、この差が今後の市場価値を左右する、と書かれています。
Ragateでは、生成されたコードをそのまま使わず、セキュリティ強化やパフォーマンス最適化を施すプロセスを重視しています。同じことは、代表がOpenClawを社内導入したときの記録にも出てきます。9割以上は自動でやってくれるが、残りの1割は自分でアーキテクチャを理解したうえで意思決定しないといけない、と。
AIが書いたものを評価できる人だけが、AIを使えます。
楽しさの在り処が、移動している
記事の中盤では、エンジニアの充足感の話が出てきます。
従来、エンジニアの充足感は技術の追求そのものにあった。しかし生成AI時代には、顧客の課題を解決し、事業の成長を加速させることへ価値が移行している。CTOの経験を通じて、技術はあくまで手段であり、目的は事業の成功にあることを学んだ、と益子は書いています。
「技術屋からビジネスパートナーへ」。この転換が、これからのエンジニアに求められる変化として提示されています。
Ragateが職種の境界を無くし、案件ごとに担うロールで語る体制にしたのは、この移動に組織の形を合わせた結果です。FDEというロールが「顧客の課題を引き出し、そのまま自分の手でつくる」と定義されているのは、まさにこの人材像を指しています。
非効率な経験が、効率を生む力になる
効率化の時代だからこそ、と益子が強調しているのが試行錯誤や失敗経験の価値です。
フリーランス時代の「遠回り」がなければRagateの創業もなかった。効率化を自発的に生み出す力は、非効率な経験から培われる。若い世代に対して、最短ルートだけを歩むのではなく、時には非効率な選択をすることの価値を伝えたい、と書かれています。
この主張は、AIが最短ルートを提示してくれる時代にこそ意味を持ちます。回り道の経験がない人は、AIの提示した道が妥当かどうかを判断できません。
本当の仕事は、顧客の成功を設計すること
結論は明快です。エンジニアの本来の仕事はコードを書くことではなく、顧客のビジネスの成功を導くこと。
システム納品後の運用最適化、スケーラビリティの確保、セキュリティ管理といった長期視点での設計判断が求められる。22歳でサーバーレス技術に感銘を受け、それが23歳でのRagate創業につながった、という自身の経緯に触れたうえで、顧客の未来を見据えた責任あるエンジニアこそが生成AI時代に求められる存在である、と記事は締めくくられています。
Ragateの評価が、技術力を必要条件としたうえでソフトスキルを重く見る設計になっているのは、ここに理由があります。論点を整理する力、相手に合わせて情報を設計する力、難しいことを難しいまま話さない力。どれも、顧客の成功を設計するための能力です。