この記事は連載「生成AI時代、エンジニアは何で食っていくのか」の導入編 #03 です。
- #01 「作れる」は武器じゃなくなった。これからは「見抜ける」が問われる時代
- #02 PM・SE・PG というロールは消える。代わりに来るのは、まだ名前もない職種だ
- #03 変化の波に飲まれないために。今すぐできる、3つの方向転換 ← 今ここ
「で、結局どうすればいいの？」
#01・#02 と読んでくれた方、ありがとうございます。「価値が変わる」「ロールが変わる」——そう言われても、「じゃあ今から何をすればいいんだ」という話が一番気になるところだと思います。
私自身も答えを探しながら、ここ1年くらい色々試してきました。この記事では、その中で見えてきた「方向性」を3つ共有します。
「これをやれば絶対大丈夫」という魔法の答えではないです。でも、少なくとも**「これをやっておけば方向はズレない」と確信している3つ**です。
方向転換① AIの「粗」を言語化できる人になる
まず最初にやるべきことは、AIのアウトプットを批判的に・言語化して評価できるようになることです。
「なんか変な気がする」で止まっているうちは、AIツールのユーザーと変わりない。「どこが、なぜ、どう問題なのか」を説明できて初めて、エンジニアとしての価値が出てきます。
具体的に何をするか
① AIに意図的に間違ったコードを書かせて、その粗を探す練習をする
たとえばこういうプロンプトを試してみてください。
以下の仕様でコードを書いてください。
ただし、意図的にセキュリティ上の問題を1〜2個含めてください。
その後、「どこに問題があるか」を問題を含めないバージョンと比較して説明してください。
[仕様]
ユーザーIDとパスワードを受け取ってログイン処理を行うAPI
こういう練習を繰り返すと、「AIが犯しやすいミスのパターン」が見えてきます。
② コードレビューの観点を言語化してドキュメントにする
あなたが今まで感覚的にやっていたレビューの観点——それを文章にしてみてください。「このパターンは危ない」「この書き方は後で詰む」という知識が言語化されていれば、AIのアウトプット評価にもそのまま使えます。
③ AIと「議論する」習慣をつける
AIが出したコードや設計に対して、「なぜこの実装にしたのか」「別の方法と比べてどうか」「このアプローチのデメリットは何か」と質問してみる。AIの答えが正しいかどうかを自分で判断する訓練になります。
方向転換② ドメイン知識を「エンジニアの武器」にする
AIはコードを書けても、「この業界の商習慣でこれは絶対にNGだ」という判断はできません。
特定のドメインに詳しいエンジニアは、これから希少になります。
なぜドメイン知識が武器になるのか
AIが苦手なのは、「表に出ていないルール」を知ることです。
たとえば金融業界だと、「この処理は日銀の規制上、ログを何年保持しないといけない」とか「この金額の閾値を超えたら自動的に上長承認フローが必要」とか——そういう知識はドキュメントを読んだだけでは得られない、現場でしか身につかない知識です。
医療・介護、製造、物流、公共——どの業界も、外からは見えない「暗黙のルール」があります。そこを知っているエンジニアは、AIと組み合わせたときに圧倒的に強い。
具体的に何をするか
① 今の現場のドメインを「深める」ことに時間を使う
技術の勉強ばかりでなく、自分が開発しているプロダクトのビジネスモデル、業界の規制、ユーザーの実際の業務フローを理解することに意識的に時間を使います。
PMやビジネスサイドの人と話す時間を増やすのも有効です。
② ドメインの「なぜ」を聞ける関係を作る
「この仕様、なんでこうなってるんですか？」と気軽に聞ける関係が、ドメイン知識を早く深める最短ルートです。業務要件の背景を理解すると、AIへの指示も精度が上がります。
③ 自分のドメイン知識をアウトプットする
技術ブログでもいいし、社内ドキュメントでもいい。「エンジニア目線でこの業界を語る」コンテンツを作ることで、知識が整理されるし、同じ悩みを持つ人とつながれます。
方向転換③「人と話す」スキルを技術スキルと同列に鍛える
これが3つの中で、もっとも見落とされがちなことだと思っています。
「コミュニケーション大事ですよね」という話は耳にタコができるくらい聞いてきたと思う。でも今回は少し違う角度の話をします。
「ユーザーの言葉をAIへのインプットに変換する」スキルが、エンジニアの核心スキルになっていくという話です。
なぜこれが重要になるのか
AIを使ったシステム開発でいちばん難しいのは、「何をAIにさせるかを決めること」です。
ユーザーは「なんかうまくいかない」「もっとこうしてほしい」という言葉で話します。その言葉から「本当に困っていること」を引き出し、「AIが処理できる精度の言語」に変換する——これは人間にしかできない仕事です。
コードを書く部分はAIに任せられるようになっても、「何を作るべきか」を正確に引き出す上流の力は、むしろ重要性が増していきます。
具体的に何をするか
① 「5回なぜを聞く」を実践する
ユーザーやビジネスサイドから要望が来たとき、表面の要望をそのまま受け取らず、「なぜそれが必要なのか」を最低3〜5回掘り下げる習慣をつける。
「検索機能が欲しい」→「どんな情報を探すのに困っているのか」→「今はどうやって探しているのか」→「それだとどこが不便なのか」……という感じで。本質的な課題が見えてくると、AIへの指示もはるかに精度が上がります。
② ユーザーインタビューに同席させてもらう
PMやUXデザイナーがユーザーと話すとき、エンジニアとして同席させてもらえるよう頼んでみる。エンジニアがユーザーの生の声を聞く機会は少ないですが、そこで得られる「文脈」は、後のAI活用の精度を大きく変えます。
③ 要件定義のメモを自分でとる習慣をつける
AIにメモをとってもらうのは便利ですが、「自分の言葉で要件を整理する」練習は続けた方が良いと思います。人の言葉を構造化する力は、使わなければ衰えます。
「生き残る」より「アップデートする」
3つ並べてみて思うのは、これらはどれも「防衛的なスキルアップ」ではないということです。
- AIの粗を見抜く力 → エンジニアとしての深みが増す
- ドメイン知識 → 自分の関わるプロダクトへの理解が深まる
- 対話力 → ユーザーや組織との関係が良くなる
どれも、やった後に「なんか仕事が面白くなった」という感覚につながるものだと思っています。
「変化の波に飲まれないために」というより、「この変化を使って、自分の仕事をもっと面白くする」くらいの気持ちでいる方が、長続きする気がしています。
まとめ
| 方向転換 | 核心 | 今日から始められること |
|---|---|---|
| ① AIの「粗」を言語化する | 批判的評価力 | AIに間違いを含むコードを書かせ、探す練習 |
| ② ドメイン知識を武器にする | 業界・業務の深い理解 | 「なぜこの仕様なのか」を聞く習慣 |
| ③ 対話スキルを鍛える | 文脈の引き出しと変換 | ユーザーとの会話に同席する |
導入編はここまでです。次の連載では、それぞれのテーマをもっと具体的に、実際の現場のケースを交えながら掘り下げていく予定です。
引き続きよろしくお願いします。
記事を読んでくださった方、ありがとうございました。「自分はこう対応している」「こんな視点もあるよ」という意見、ぜひコメントで聞かせてください。一人一人の現場の声が、この連載をよくする材料になります。