生成AIの進化で、IT技術者の仕事の重心が確実に動いています。これまで「どれだけ速く正確にコードを書けるか」が評価の中心だった現場でも、AIがコード生成・補完・テスト・リファクタ・ドキュメントまで手伝ういま、競争の主戦場は「書くこと」から「何を書くか」へ移りつつあります。
本稿では、AI時代にIT技術者が自分ごととして磨くべき力と、明日から実践できる行動まで、段落のつながりを意識して整理します。概念論で終わらせず、会議の参加の仕方・成果物の出し方・AIの使い方まで落とし込みます。若手が伸ばすべき力や設計する側に回る理由については筆者の記事一覧の関連記事でも触れているので、あわせて読むと 「正しく聞き、仮説を形にして検証する」 ところの位置づけがよりはっきりします。
コードを書く人から、課題を形にする人へ——役割のシフト
これからのIT技術者に問われるのは、実装能力そのものだけではありません。何を作るべきかを見極める力、現場の課題を正しく理解する力、関係者と対話しながら仕様を具体化する力、そしてAIを使って素早く形にし、検証し、改善する力です。
つまり、役割は「コードを書く人」から、課題を発見し、要件に落とし、価値として実装する人へと変わってきています。このシフトを頭では理解していても、日々の打ち合わせや設計でどう動けばよいかが曖昧だと、なかなか行動に移せません。そこでまず、なぜ「書く力」だけでなく「聞く力」と「形にする力」が効いてくるのかを、現場で起きがちなズレから見ていきます。
AIが変えたのは「速度」であって、「正しさ」ではない
生成AIを使うと、画面部品・APIの雛形・SQL・テストコード・バッチ・ログ・例外処理の骨格など、多くの実装を短時間で進められます。開発のボトルネックは「書くこと」そのものではなくなりつつある一方で、多くの現場が見落としがちな点があります。AIは要件の正しさまでは保証してくれないということです。
AIは与えられた指示に基づいて、非常に高速にそれらしいものを作ります。裏を返せば、前提が間違っていれば、間違ったものを高速かつ大量に生産してしまうのです。
たとえば、顧客が「申請業務を効率化したい」と言っているとします。技術者側がすぐにワークフロー画面や承認機能を作り始めたとしましょう。しかし実際には、問題は申請画面ではなく、申請前に必要な情報収集や確認作業が部門ごとにバラバラなことだった——そんなケースは珍しくありません。この場合、どれだけ高品質に承認機能を作っても、本質的な改善にはなりません。AI時代に怖いのは、こうしたズレが今まで以上に速く進むことです。だからこそ、実装前の理解がこれまで以上に重要になります。
技術者の価値は「正しく聞く力」で決まる
従来の開発では、営業・コンサル・PM・PL・設計・実装と役割が分かれ、顧客の要望が複数人を経由して伝わることがよくありました。大規模開発では必要な面もありますが、その過程で現場の文脈やニュアンスが失われやすいという問題があります。
たとえば顧客が言う「使いにくい」は、実際には次のどれかかもしれません。操作手順が多い、欲しい情報が見つからない、入力項目の意味が分からない、部門ごとに例外処理が多い、現場の運用とシステム設計思想が合っていない——これらは表面上は「使いにくい」の一言で片づけられがちです。しかし、技術者がそこを掘り下げなければ、適切な設計はできません。
これからのIT技術者には、「依頼されたものをそのまま作る力」よりも、相手の言葉の奥にある業務構造や制約を読み解く力が必要になります。これは営業力というより、課題構造化力に近いものです。この力があると、AIを使うときに「何を聞き、何を形にすべきか」がはっきりし、実装の質が一気に上がります。
要件定義は「文書作成」ではなく「仮説検証」になる
昔ながらの開発では、詳細な要件定義書を作り、確定させてから設計・実装へ進む流れが一般的でした。ただしAIによってプロトタイプ作成のコストが大きく下がったいま、文章だけで合意したつもりでも、完成物を見た瞬間に「思っていたのと違う」が起きるという限界が、よりはっきり見えています。このズレは、業務システム・社内ツール・管理画面・分析基盤のどれでも起こり得ます。
今後は、要件定義の精度を上げるために、文章を延々と精緻化するよりも、まず小さく動くものを作り、見せて、修正するほうが圧倒的に有効です。たとえば、最初の1〜2日でAIを使って最低限の画面モックや処理フローを作り、利用者から「ここは違う」「この列が足りない」「この承認順は現場では使えない」といったフィードバックをもらう。その会話をもとに業務理解を深め、仕様を修正していく——このやり方なら、紙の上の想像で仕様を詰めるよりも、はるかに早く本質に近づけます。
AI時代の要件定義は、仕様書を作る工程というより、試作品を通じて認識を合わせる工程になっていきます。
「現場通訳者」としての技術者像
今後価値が高まる技術者は、単にコードが書ける人ではなく、現場と言語の違う人たちのあいだをつなげられる人です。現場担当者は業務には詳しくても、システム設計の言葉では話しません。一方でエンジニアはデータ構造や責務分割・非機能要件では考えられても、業務現場の細かな例外や心理的抵抗感までは見えにくいことがあります。ここを橋渡しする人材が重要になります。
たとえば、現場の発言をそのまま受け取るのではなく、その作業の目的は何か、誰が困っているのか、どの条件のときに例外が起きるのか、手作業が残る理由は何か、それは業務ルールなのか単なる慣習なのか——まで掘り下げて整理できる人です。この力がある技術者は、AIを使うことでさらに強くなります。自分で理解した内容をそのまま素早くモックや設計に変換し、その場で確認できるからです。間に何人も挟まなくても、理解と実装の往復を高速化できます。
明日から変える三つの姿勢
「ヒューマンスキルが大事」「要件定義が重要」と言われても、現場で何をすればよいかが曖昧だと行動に移りません。ここでは、実務で取り組みやすい三つの姿勢に絞ります。
会議では「メモを取る」だけで終わらせない
要件定義や打ち合わせで、単にメモを取り、宿題を持ち帰るだけでは不十分です。次の3つを必ず確認するようにしましょう。その要望が誰のどんな困りごとから出ているか。その業務の成功条件は何か。例外ケースと運用上の制約は何か。
たとえば「CSVを出したい」という依頼が来たときも、そこで止めないことです。なぜCSVが必要なのか、誰がどこで加工するのか、毎日なのか月次なのか、Excelで集計するのか他システム連携なのか、文字コードや列順に制約があるのか——ここまで聞けるだけで、設計の質は大きく変わります。
成果物は「完成してから」ではなく「早く見せる」
文章だけで合意を取ろうとせず、可能な限り早くサンプルを見せます。画面のワイヤーフレーム、APIの入出力例、テーブル定義のたたき台、バッチの処理フロー図、サンプルデータ入りのCSV、AIで作った簡易プロトタイプなど、どんな形でもよいので見えるものを早期に出します。「まだ完成していないから見せない」のではなく、完成していないからこそ見せる、という考え方に変えると、誤解を早い段階で潰せます。
AIは「実装」だけでなく「理解・整理・確認」に使う
AIを「コードを書く道具」としてだけ使うと、価値を半分も引き出せません。ヒアリング内容の論点整理、要件候補の洗い出し、業務フローの可視化、画面項目案のたたき台作成、テスト観点の抜け漏れ確認、非機能要件のチェックリスト生成、利用者向け説明文の作成——こうした理解・整理・確認の補助として積極的に使うと、実装前のズレを減らせます。
明日からできる五つの実践
より具体的に「何をやればいいか」を、五つの実践に落とします。
実践1：打ち合わせ後5分で「課題メモ」を作る
会議が終わったら、議事録とは別にA4半ページ程度で、次の4項目をまとめます。顧客が表面上ほしいと言っているもの、本当の目的として推測できるもの、まだ曖昧な点、次回確認すべき例外条件。このメモを毎回書くだけで、受け身の要件確認から一歩抜け出せます。AIに投げて論点整理させてもよいです。
実践2：要件定義の段階で最低1つは“見えるもの”を出す
どんな案件でも、最初の段階で何かしら視覚化します。管理画面なら画面モック、APIならJSON例、データ分析ならダッシュボードのラフ、業務フローなら図です。人は文章よりも、見えるものに対して具体的な違和感を言いやすいです。この違和感こそ、良い要件の材料になります。
実践3：AIに「実装」だけでなく「批評」もさせる
「この機能を実装して」だけでなく、「この設計の抜け漏れを指摘して」「利用者が困りそうな点を挙げて」「運用上の例外を想定して」「この仕様で手戻りが起きそうなポイントを教えて」と聞くようにします。AIは万能ではありませんが、思考の壁打ち相手としては非常に有効です。
実践4：業務理解のために“現場の言葉”を集める
要件書に書かれた言葉だけでなく、現場が普段どう表現しているかをメモします。開発側は「案件ステータス」と呼ぶが、現場は「止まってる」「差し戻し」「仮登録」といった運用語で認識している——こうしたズレを理解せずに設計すると、ユーザーにとって違和感の強いシステムになります。業務システムは、現場の用語と揃えると一気に使いやすくなります。
実践5：自分の価値を「何行書いたか」ではなく「何を減らしたか」で測る
AI時代には、コード量そのものは差別化要因になりにくくなります。むしろ、手戻りを減らした、仕様の曖昧さを早期に潰した、利用者の確認工数を減らした、例外処理を事前に見つけた、プロトタイプで誤解を解消した、運用負荷を減らした——こうした成果を自分の価値として意識すると、技術者としての立ち位置が変わります。
若手こそ、いまから伸ばすべき力
若手やこれからIT業界に入る人は、「自分はまだ高度な実装ができない」と不安になるかもしれません。しかしAI時代では、単純な知識差だけでは優位性を保ちにくくなります。その代わり、早い段階から次の力を意識して伸ばすと強いです。
相手の話を整理して聞く力。曖昧な要求を構造化する力。たたき台をすばやく出す力。フィードバックを受けて修正する力。分からないことをそのままにしない力。これらは派手ではありませんが、AI時代の現場では極めて強い武器になります。筆者の記事一覧で触れている「技術者のTaste」や「選択の質」と合わせて、聞く力・形にする力・選ぶ力をセットで磨いておくと、長く活躍しやすくなります。
まとめ——技術と対話で問題解決する人へ
これから求められるIT技術者は、単なるプログラマーでも、単なる御用聞きでもありません。現場の課題を理解し、AIを活用して素早く形にし、相手と認識を合わせながら価値を磨き込める人です。言い換えれば、技術を使って作る人から、技術と対話を使って問題解決する人へ。このシフトが起きています。
AIによってコードを書くハードルは下がります。だからこそ、何を作るべきかを見抜く力、現場に入り込んで本音を引き出す力、曖昧な要求を形にする力が、これまで以上に重要になります。本当に重要なのは「AIに仕事を奪われない技術者になること」ではなく、AIを使うことで、より本質的な仕事に時間を使える技術者になることです。
その第一歩は、コードを書く前に、「これは誰の、どんな困りごとを解決するのか」を一段深く聞くことから始まります。
作成日：2026年3月14日