AI時代に市場価値が落ちるSEの特徴──コードより先に磨くべき仕事

コードを書ける。設計もできる。真面目にやってきた。
それなのに、ふと求人票を見ると、胸がざわつく。求められているのは、以前と同じSEのはずなのに、どこか自分の立ち位置が薄くなっている気がする。

僕はこの不安を、能力不足だとは思わない。
ただ、評価軸が変わった。AIがコードを書くようになった今、SEの価値は実装量では測られにくくなり、別の場所に移っている。

今日は、AI時代に市場価値が落ちやすいSEの特徴を整理した上で、コードより先に磨くべき仕事を、実務の言葉で解像度高く書く。

市場価値が落ちるSEに共通する特徴

1) 作業者としての自分を売ってしまう

AIが得意なのは、既存知識を組み合わせて、そこそこ正しいコードを高速で生成すること。
だから、要件が固まっていて、設計も決まり、後は実装するだけ──この工程では、人が「打鍵量」で差別化するのが難しくなる。

市場価値が落ちるSEは、職務経歴の説明がこうなりがちだ。

• APIを実装しました

• バッチを作りました

• 画面を作りました

• テストをしました

これだと、AIでも代替できる領域の説明になってしまう。
本当は、その実装に至るまでに、どんな判断をして、どんなリスクを潰し、どんな品質を守ったのかが価値なのに、そこが書かれていない。

2) 要件が曖昧なまま進めてしまう

AIは「正しい問い」がないと、正しい答えを出せない。
要件が曖昧なまま実装に突っ込むSEは、AI時代ではさらに評価が落ちやすい。

なぜなら、曖昧な要件のままAIにコードを書かせると、速く間違えるから。
そして、その間違いを最後に回収するのは、現場のSEだ。結果として、炎上の中心に立つ。

「要求が曖昧でも、とりあえず形にする」
これは、以前は推進力として評価される場面もあった。だが今は、負債を増やす行動として見られやすい。

3) 品質と運用を「後で考える」癖がある

AIで実装が速くなると、リリースは前倒しになりやすい。
そのとき、差が出るのが運用設計だ。

• 監視はどうするか

• 障害時の切り戻しは？

• データ不整合が起きたら？

• 想定外の入力が来たら？

• ログは誰が、何のために読むのか？

市場価値が落ちるSEは、ここを「運用チームが何とかする」と切り離してしまう。
でも現実は、運用で事故った瞬間に、原因究明と恒久対策の主役は開発側に戻ってくる。

AIで作れる“動くコード”が増えたぶん、運用設計の弱さは、以前より目立つ。

4) 意思決定の理由を残さない

設計や実装の判断には、必ず前提がある。
「なぜこの方式にしたのか」が説明できないSEは、AI時代に弱い。

AIは案を量産する。
案が増えれば増えるほど、最後に必要なのは「選ぶ力」だ。

• どの案が今の制約に合うのか

• 何を捨て、何を守るのか

• どんなリスクを受け入れるのか

• 撤退条件は何か

意思決定の理由が残っていないと、後から必ず揉める。
そして揉めたとき、説明できない人は、評価を落とす。

コードより先に磨くべき仕事は何か

結論から言う。AI時代のSEが磨くべきは「実装能力の前工程」だ。
もっと具体的に言うと、次の5つ。

1) 問いを作る力（要件の再定義）

AI時代のSEは「仕様を受け取る人」ではなく、「仕様を作り直す人」になる。
言い換えると、曖昧な要求を、実装可能な問いに変換する仕事だ。

例えば、ユーザーが「検索を速くしたい」と言ったとき、ここで止まってはいけない。

• 何が遅いのか（DB？API？フロント？）

• “速い”とは何秒なのか

• 同時アクセスはどれくらいか

• 検索対象は増えるのか

• その速度改善は本当に必要か（利用頻度は？）

この問いを詰めるのが、価値。
AIにコードを書かせる前に、AIに渡す問いを設計できるSEが強い。

2) 境界を引く力（スコープと責任分界）

炎上の多くは、技術の難しさではなく「境界の曖昧さ」から起きる。
AIで実装が速くなるほど、境界が曖昧なプロジェクトは、より早く壊れる。

• どこまでが今回の範囲か

• どこからは次フェーズか

• 障害時の一次対応は誰か

• データの正はどこか

• 外部サービスの責任分界は？

境界線を引く力は、地味で、評価されにくい。
でも、ここが強いSEは、炎上を未然に潰す。結果として信頼が積み上がる。

3) 選ぶ力（意思決定の型）

AIが提示する案は、正しそうに見える。
だからこそ、人間側には「選び方の型」が必要になる。

おすすめは、意思決定を次のテンプレで残すこと。

• 選択肢A/B/C

• 比較軸（コスト、性能、保守性、セキュリティ、納期）

• リスクと対策

• 今回の前提（制約条件）

• 撤退条件（この条件が崩れたら見直す）

これを残せるSEは、説明責任を果たせる。
説明責任を果たせる人は、役割が上がる。役割が上がれば、市場価値は落ちない。

4) 品質を仕組みにする力（レビュー・テスト・運用）

AIでコード生成が高速化すると、品質は「人の注意力」では保てない。
注意力は枯れるからだ。

だから、品質は仕組みに移す必要がある。

• レビューの観点をテンプレ化

• テスト戦略（何を自動化し、何を手動で担保するか）

• 監視設計（何を見れば異常に気付けるか）

• ログ設計（誰が、何のために読むのか）

• 事故時の手順（切り戻し、影響範囲、連絡フロー）

AI時代に強いSEは、ここを「自分の仕事」として扱う。
運用を軽く見ないSEは、長期的に信頼を得る。

5) 成果を翻訳する力（ビジネス言語・採用市場言語）

市場価値が落ちる人は、成果があっても伝えられない。
逆に言えば、伝えられる人は強い。

例を出す。

悪い例：

• APIを実装しました

良い例：

• 問い合わせ増により検索遅延が発生していたため、検索APIを設計見直し。計測指標を定義し、ボトルネックを特定して改善。レスポンスp95を◯秒→◯秒に短縮、障害問い合わせを月◯件削減

ここまで言えると、AIが書いたコードかどうかは関係なくなる。
価値は「問題設定と解決の設計」にあるから。

じゃあ、実装力はもういらないのか？

これは誤解されやすい。実装力は要る。
ただし、実装力は“差別化要素”から“前提条件”に近づく。

AI時代に価値が上がるのは、実装そのものよりも、実装を成立させる前後の仕事。
要件、合意、判断、品質、運用、説明。ここを担えるSEが残る。

最後に：あなたの仕事は、コードを書くことだけだった？

もし今、少しでも胸が痛んだなら、それは責める話じゃない。
これまでの現場は、コードを書く人を必要としてきた。だから、その役割を真面目にやってきただけだ。

でも、AIが入ってきた今、役割の中心が移動した。
だからこそ、今のうちに問いを作り、境界を引き、選び、品質を仕組みにし、成果を翻訳できる人に寄っていくべきだ。

あなたはこれから、どの仕事を自分の中心に置きたい？
コードの先にある仕事へ踏み出すなら、最初の一歩はどこから始める？

次に読む：

はじめての方へ：

マガジンの紹介：

IT業界の「技術×キャリア×整える」を束ねるマガジンを公開中です！
ビジネスや心と体を整える良記事が集まってきていますので、
是非、覗いてみてくださいね。
気に入って頂けたらマガジンのフォローもよろしくお願いします！