「で、結局どうすればいいの？」

#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に間違いを含むコードを書かせ、探す練習
② ドメイン知識を武器にする	業界・業務の深い理解	「なぜこの仕様なのか」を聞く習慣
③ 対話スキルを鍛える	文脈の引き出しと変換	ユーザーとの会話に同席する

導入編はここまでです。次の連載では、それぞれのテーマをもっと具体的に、実際の現場のケースを交えながら掘り下げていく予定です。

引き続きよろしくお願いします。

記事を読んでくださった方、ありがとうございました。「自分はこう対応している」「こんな視点もあるよ」という意見、ぜひコメントで聞かせてください。一人一人の現場の声が、この連載をよくする材料になります。