AI時代でも、プログラマーの需要がすぐになくなるとは考えにくい一方、仕事内容は変わっていく可能性があります。
これから目指す人も現役のプログラマーも、「AIで仕事がなくなるのではないか」「効率化されたはずなのになぜ楽にならないのか」と、不安や戸惑いを感じることがあるでしょう。
朝からAIが生成したコードをレビューし、問題があれば修正を依頼する。
確認を終える頃には次の実装が上がってきて、またレビューが始まる。
コードを書く時間は減ったのに、確認する仕事は減らない。
こうした状況を見るときは、1案件あたりの工数と、一定期間の総仕事量を分けて考える必要があります。
設計や実装が速くなっても、浮いた時間が追加開発に使われれば、レビューや確認の件数は増え得ます。
反対に、開発件数を増やさない場合や、レビューやテストまで効率化できる場合は、人間の負担が減ることもあります。
この記事では、公的データからIT人材の需要を確認し、AIによって設計、実装、レビュー、テスト、デバッグがどう変わるのかを見ていきます。
「今から目指してもよいのか」「この仕事を続けてよいのか」と迷っている人が、自分なりに判断するための材料を整理します。
【1】AI時代でもプログラマーに将来性はあるのか
AI時代でも、プログラマーを含むIT人材への需要はあります。
ただし、人材が不足しているからといって、今と同じ仕事内容がそのまま残るとは限りません。
プログラマーの将来性を見るときは、今後も人が必要とされるかだけでなく、AIによって何を担当する仕事へ変わっていくのかも分けて考える必要があります。
IT人材の需要は公的データから確認する
「AIがコードを書くなら、プログラマーはいらなくなるのではないか」と考えるのは自然なことです。
まずは、IT人材全体の需要を公的データから確認します。
経済産業省の「IT人材需給に関する調査」では、IT市場が高位成長するシナリオで、2030年に約79万人のIT人材が不足すると推計されています。
IPAの「DX動向2025」でも、2024年度の調査で日本企業の85.1％が、DXを推進する人材について「やや不足している」または「大幅に不足している」と回答しています。
少なくとも、これらのデータからIT関連の人材需要が近いうちに消えるとは考えにくいでしょう。
ただし、約79万人という数字は市場成長などを前提にした推計で、確定した不足人数ではありません。
IT人材やDX推進人材には、プログラマー以外の職種も含まれます。
IT人材不足という数字だけで、プログラマーの雇用まで保証されるわけではありません。
IT人材の需要があってもプログラマーの仕事内容は変わり得る
IT人材が不足していても、企業が人に任せたい仕事の中身は変わり得ます。
企業が必要としているのは、コードを書く行為そのものではなく、ソフトウェアを開発し、改善し、運用することです。
その途中にあるコード作成の一部をAIが担えば、人間が使う業務の配分も変わります。
これまで自分でコードを書いていた時間が、AIの生成結果を確認したり、修正方針を決めたりする時間へ移ることもあります。
つまり、プログラマーへの需要が残ることと、これまでと同じ作業が残ることは別です。
人材不足だけを見ていると、この変化が見えてこなくなります。
AIでコード作成が効率化してもプログラマーが不要になるとは限らない
AIは、コードの生成や補完、修正案の作成を支援できます。
コードを書く作業の一部は、今後さらに効率化されるでしょう。
それでも、ソフトウェア開発はコードを書けば終わりではありません。
実装の前後には、設計、レビュー、テスト、デバッグがあります。
コード生成が速くなっても、それらの工程まで同じ割合で自動化されるとは限りません。
そのため、コード作成の自動化だけを見て、プログラマーという職業そのものが不要になるとはいえません。
一方で、職業が残っても、コードを書く時間まで今と同じとは限らない点は分けて考える必要があります。
プログラマーの将来性は需要と仕事内容の両方で判断する
プログラマーの将来性は、需要が残るかだけでなく、仕事内容がどう変わるかまで含めて考えたほうが実態に近づきます。
これから目指す人なら、コードを書くことに加えて、設計や検証の比重が増える働き方を自分がどう感じるかも判断材料になります。
現役のプログラマーなら、今担当している仕事のうち、AIに任せやすい作業と、人が確認したり決めたりする作業を分けて見ると、今後どのスキルを磨けばいいのかがわかりやすくなります。
IT人材への需要が続くことは、一つの材料です。
そのうえで、変わっていく仕事内容にも携わりたいと思えるかまで含めて見ると、自分にとっての将来性を判断しやすくなります。
【2】AIでプログラマーの仕事はどう変わっているのか
AIの影響は、コードを書く作業だけではありません。
設計、レビュー、テスト、デバッグにも広がっています。
ただ、効率化しやすい作業は工程ごとに違います。
どこでAIを使いやすく、どこに人の確認が残るのかを分けて見ると、仕事内容の変化がつかみやすくなります。
コード作成はAIで効率化しやすくなっている
変化がわかりやすいのは、コードを書く工程です。
生成AIに仕様や目的を伝えると、それに沿ったコード案が返ってきます。
既存コードの補完や定型処理の作成、修正案を考える用途にも使えます。
たとえば、データ加工や入力チェックの処理なら、ゼロから書かずにAIへ生成を任せる方法もあります。
一行ずつコードを書く時間を減らせる場面は増えています。
ただ、生成されたコードをそのまま既存システムへ組み込めるとは限りません。
仕様どおりに動くか、既存コードと矛盾しないかを確かめる作業は残ります。
コード作成が速くなっても、実装工程全体の人間工数が同じ割合で減るわけではありません。
設計も人間だけの作業からAIとの共同作業へ変わる
AIは、実装前の設計にも使われます。
要件をもとに仕様書のたたき台を作る、複数のシステム構成案を出す、機能の実現方法を洗い出すといった使い方です。
これまで担当者が資料を読みながら作っていた案も、AIを使えば候補を早く用意できることがあります。
ただし、要件が曖昧だったり、業務に必要な情報が足りなかったりすれば、出てきた設計案も適切とは限りません。
最終的には、内容を確かめ、関係者と認識を合わせる必要があります。
設計案を早く用意できるようになると、同じ人数でも一定期間に検討できる案や仕様が増えることがあります。
レビュー・テスト・デバッグでもAI活用が進んでいる
コードを書いたあとの工程でも、AIは使われています。
レビューでは、問題になりそうな箇所を挙げ、修正案まで示してくれます。
人がコード全体を一から読み解く負担を減らす助けになります。
テストでは、仕様をもとにテストケースやテストコードを生成します。
正常な入力だけでなく、入力ミスなどの異常な条件を洗い出す用途にも向いています。
デバッグでは、エラーメッセージや関連コードから原因候補を挙げ、修正の手がかりを示します。
原因調査に入るまでの時間を短くできる場合があります。
ただ、AIが問題を見落としたり、不適切な修正案を出したりすることはあります。
Stack Overflowの2025年調査では、AIツールを利用している、または利用予定の開発者が84％だった一方、AI出力の正確性を信頼しない回答は45.7％でした。
利用が広がっていても、出力をそのまま信頼できるわけではないことがわかります。
AIによる効率化の度合いは開発工程ごとに異なる
工程ごとに見ると、AIが使いやすい部分と、人に残る作業は次のように分かれます。
| 開発工程 | 従来の人間の役割 | AIで効率化しやすい部分 | 人間に残る作業 |
|---|---|---|---|
| 設計 | 要件整理、仕様書作成、設計案の検討 | 要件整理の補助、設計案の生成・比較 | 要件の確認、設計案の選定 |
| 実装 | コードの記述、修正 | コード生成、補完、修正案の作成 | 生成コードの確認、統合 |
| レビュー | コードの問題点の確認 | 問題候補の検出、改善案の提示 | 指摘内容の検証、修正確認 |
| テスト | テストケース作成、動作確認 | テストケースやテストコードの生成 | テスト結果の確認、追加検証 |
| デバッグ | 原因調査、コード修正 | 原因候補の提示、修正案の生成 | 原因の特定、修正結果の確認 |
コード生成だけが速くなっても、レビューやテストに時間がかかれば、開発全体が同じ割合で速くなるわけではありません。
反対に、作れるコードや設計案が増えれば、その後に確認する対象も増えます。
AIによる効率化を見るときは、一つの作業時間だけでなく、前後の工程まで含めて考える必要があります。
【3】AIで開発が速くなっても人間の仕事量は減るとは限らない
AIによって設計や実装が速くなれば、プログラマーの仕事も減るように思えます。
しかし、1案件あたりの作業時間が短くなることと、総仕事量が減ることは話が別です。
浮いた時間を追加開発に回せば、レビューや確認する案件が増え、かえって忙しくなる場合もあります。
1案件あたりの工数削減と一定期間の総仕事量は別に考える
AIによる効率化を考えるときは、次の三つを区別します。
- 1案件あたりの人間工数：一つの案件を終えるまでに、人間が設計、実装、レビューなどへ使う作業時間
- 一定期間の開発量：1週間や1か月など、決まった期間に処理する案件数
- 一定期間の総仕事量：同じ期間に、人間が開発業務へ使う作業時間の合計
たとえば、AIによって1案件あたりの人間工数が半分になっても、同じ期間に処理する案件数が2倍になれば、総仕事量は変わりません。
つまり、1案件あたりの工数が減っただけでは、仕事全体が楽になったとは判断できないのです。
開発量がどれだけ変わったかも関係します。
設計が速くなると一定期間に進められる開発も増え得る
AIによる効率化は、コードを書く前の設計工程にも及びます。
設計では、実装する機能や仕様を決めます。
AIが要件整理や設計案の作成を支援すれば、同じ人数でも一定期間に進められる設計が増える場合があります。
ただし、設計が速くなっただけで開発件数が増えるわけではありません。
追加開発に必要な予算や人員があり、企業が浮いた時間を新しい案件に回せば、実装へ渡る仕事も増えます。
つまり、設計の効率化が開発量の増加につながるかどうかは、企業が生まれた余力を何に使うかによって変わります。
開発量が増えればレビュー・確認・修正の対象も増え得る
設計や実装のあとには、レビュー、テスト、デバッグなどの確認作業が続きます。
AIによって実装する案件が増えれば、その分だけ確認するコードや機能も増えます。
たとえば、レビュー1件にかかる時間が短くなっても、対象となる件数がそれ以上の割合で増えれば、総レビュー時間は増加します。
「コードを書く時間は減ったのに、確認する仕事が増えた」と感じる背景には、1件あたりの負担ではなく、確認する件数の増加があるのかもしれません。
ただし、レビューが増える原因はAIだけではありません。
事業の拡大や人員不足、開発体制の変更でも同じ状況は起こり得ます。
浮いた工数を追加開発へ回すと下流の総負担は増え得る
ここで、仮の数値を使って仕事量の変化を確認します。
AI導入前は、1案件あたり設計に40時間、実装とレビューに60時間かかっていたとします。
導入後は、設計が20時間、実装とレビューが40時間に短縮されたと仮定します。
企業が設計担当者の余力を追加開発へ回し、同じ期間に2案件を進めた場合、仕事量は次のように変わります。
| 状態 | 1案件あたりの人間工数 | 一定期間の開発量 | 一定期間の人間の総仕事量 |
|---|---|---|---|
| AI導入前 | 設計40時間＋下流60時間＝100時間 | 1件 | 設計40時間＋下流60時間＝100時間 |
| AI導入後（追加開発あり） | 設計20時間＋下流40時間＝60時間 | 2件 | 設計40時間＋下流80時間＝120時間 |
| AI導入後（追加開発なし） | 設計20時間＋下流40時間＝60時間 | 1件 | 設計20時間＋下流40時間＝60時間 |
※数値は仕組みを説明するための仮定であり、実際のAI導入による工数削減率ではありません。
表の「追加開発あり」では、1案件あたりの人間工数が100時間から60時間へ減る一方、案件数は1件から2件に増えています。
設計に使う総工数は40時間で変わりませんが、実装とレビューの総工数は60時間から80時間に増加します。
その結果、一定期間の総仕事量も100時間から120時間へ増えています。
これは、設計で浮いた20時間を2件目の開発に回したことで、下流工程の仕事が増えたためです。
AIが直接仕事量を増やしたのではなく、効率化で生まれた余力の使い方が、総仕事量の増加につながっています。
なお、この表は人間工数の合計を示すモデルです。
個々のプログラマーの負担が増えるかどうかは、人員配置や担当範囲によっても変わります。
追加開発を増やさなければ人間の総仕事量は減り得る
一方、AIで設計や実装が速くなっても、開発件数を増やさなければ、総仕事量は減る可能性があります。
先ほどの表では、AI導入後も1案件だけを開発する場合、人間工数は100時間から60時間に減っています。
企業が浮いた時間を追加開発に回さず、納期の短縮や作業負担の軽減に使えば、案件数の増加によって下流工程が忙しくなることもありません。
同じ工数削減でも、追加開発を増やすかどうかによって、一定期間の総仕事量は変わります。
AIレビューや自動テストで下流まで効率化できる場合もある
もう一つ考えられるのが、レビューやテストなどの下流工程も効率化される場合です。
設計や実装だけが速くなり、レビューやテストの処理速度が変わらなければ、確認待ちの仕事が増えやすくなります。
反対に、AIレビューや自動テスト、デバッグ支援によって確認作業も短縮できれば、開発件数が増えても総仕事量を抑えられる場合があります。
AI導入後の仕事量は、1案件あたりの工数削減、開発件数の増加、下流工程の効率化によって変わります。
追加開発によって増えた工数が、各工程で削減できた工数を上回れば、一定期間の総仕事量は増えます。
逆に、削減できた工数のほうが大きければ、開発件数が増えても総仕事量は減ることになります。
【4】AI時代に人間へ残りやすい仕事は何か
AIが設計案やコードを生成しても、実際の開発に採用するには、仕様や品質、事業上の条件を踏まえた判断が必要です。
そのため、プログラマーの仕事は、コードを書く作業から、設計や検証、判断を担う作業へ比重が移る可能性があります。
何を作るかを決める設計判断は人間が担当
たとえば、利用者から求められた機能をすべて実装すると、予定していた納期に間に合わない場合があります。
納期を延ばせないなら、どの機能を優先し、何を次回の開発へ回すか決めなければなりません。
AIが複数の設計案を提示しても、予算や開発期間、利用者への影響を踏まえて、どの案を採用するかは現時点では人間側が決める必要があります。
関係者と認識を合わせ、実装する機能や仕様を確定する仕事も残ります。
AI生成コードの検証・デバッグには人間の判断が必要になる
AIが生成したコードは、正常に動いても、そのまま実際のシステムに採用できるとは限りません。
仕様どおりに動作していても、既存機能に影響したり、将来の修正が難しい構造になっていたりする場合があるためです。
人間による検証では、主に次の点を確認します。
- 仕様で求められた動作を満たしているか
- 既存機能やデータに想定外の影響を与えないか
- 不具合が発生した場合に原因を特定し、修正できるか
たとえば、不具合の原因が一つの処理にあるなら、その部分の修正で済むかもしれません。
しかし、設計そのものに問題があれば、より広い範囲を見直す必要があります。
AIが原因候補や修正案を示しても、その内容が適切とは限りません。
別の不具合を生まないよう、修正する範囲を決め、修正後の動作まで確かめる必要があります。
公開するプログラムの最終判断と責任は人間
ソフトウェア開発では、実装やテストが終わっても、公開してよいかを決める仕事が残ります。
たとえば、軽微な不具合が見つかったとき、予定どおり公開するか、修正を優先して延期するか。
不具合の影響範囲だけでなく、利用者への影響や事業上の事情も関係する判断です。
AIがテスト結果を分析し、公開の可否を提案することはあっても、その提案を採用するかは企業の品質基準や許容できるリスクによって変わります。
公開後に問題が起きれば、一般的な企業開発では会社や担当者が利用者への説明や修正対応を担います。
具体的な責任の所在は契約や開発体制によって異なりますが、AIそのものが企業に代わって説明責任をしてくれるわけではありません。
プログラマーの役割はコード生成から判断・検証へ比重が移り得る
AIによるコード生成が速くなれば、プログラマーが自分でコードを書く時間は減っていきます。
その分、生成されたコードを検証し、修正や採用を決める仕事の比重が高まることも考えられます。
ただし、すべてのプログラマーが同じ働き方へ移るわけではありません。
担当するシステムや開発体制、AIの活用状況によって、実装と検証にかける時間の割合は変わります。
コードを書くことが好きな人にとっては、AIが生成したコードを確認する仕事が増える変化を、どう受け止めるかも気になるところでしょう。
たとえば、生成コードの不具合を調べ、修正して動作確認まで担当する。
あるいは、設計段階から関わり、機能の優先順位や採用する仕様を決める。
今後の働き方を考えるなら、まずは直近の開発で自分が担当した作業を振り返ってみる方法があります。
コードを書いた作業、AIの出力を検証した作業、自分で修正方針や仕様を決めた作業を分けて書き出す。
その中から、今後も続けたい仕事と、これから経験してみたい仕事を選んでみると、次に担当したい役割を具体的に考えられます。
【5】AI時代にプログラマーを目指す人・続ける人が伸ばしたい力
AI時代にプログラマーとして働くには、コードを書く力に加えて、AIを使いこなし、その出力を理解して検証する力も求められます。
ただし、最初からすべての開発工程を担当する必要はありません。
今の経験を土台に、少しずつ担当できる仕事を広げていく方法があります。
コーディング力はAI生成コードを理解・修正する土台になる
AIがコードを生成する時代でも、プログラミングの基礎を学ぶ意味はあります。
生成されたコードを実務で使うには、処理の流れを理解し、不具合があれば自分で修正できる力が必要だからです。
たとえば、AIが作ったコードが想定と違う結果を返したとき、変数や条件分岐、データの流れを理解していなければ、原因を調べるのも難しくなります。
文法だけでなく、処理の仕組みやデバッグの基礎まで身につけることが、AI生成コードを読み解く土台になります。
AIを使って実装・調査・検証する力を身につける
プログラミングの基礎を身につけたら、AIを実際の開発作業でどう使うかも経験しておきたいところです。
実装ではコード案を生成させ、調査では既存コードの処理を説明させる。
不具合が起きたら、エラーメッセージをもとに原因候補を洗い出す使い方もあります。
ただ、AIの回答をそのまま採用するだけでは、正しく動くかまで判断できません。
生成コードを実行し、必要なテストを追加して結果を確かめる。
問題があれば修正し、もう一度動作を確認する。
AIにどこまで任せ、どこから自分で確かめるかを判断できることが、実務でのAI活用につながります。
要件整理・設計・レビュー・デバッグまで経験を広げる
実装を中心に担当している人は、その前後の工程にも経験を広げる方法があります。
たとえば、実装前の仕様確認に参加する、ほかの人が書いたコードをレビューする、不具合の原因調査を担当するといった仕事です。
すぐに管理職や別職種を目指す必要はありません。
今の仕事とつながる工程を一つ経験するだけでも、コードを書く前に何が決まり、完成後にどんな確認が行われるのかを知る機会になります。
最初は担当者の補助からでも、設計や検証に関わる経験を積めます。
実装だけに閉じず設計や検証まで担当できる範囲を広げる
新しい工程を経験したら、そこで自分が何を判断できたかも確かめたいところです。
たとえば、仕様の曖昧さを見つけたなら、何を確認し、どう解決したか。
レビューで問題を指摘したなら、なぜ修正が必要だと考えたのか。
設計案を比較した場合も、採用した理由と結果を記録しておくと、自分で判断できた範囲がわかります。
参加した案件数だけでなく、判断した内容とその結果を残すことで、次に担当できそうな仕事も具体的になります。
自分の経験段階とやりたい仕事から次に伸ばす力を選ぶ
次に取り組む仕事は、現在の経験に合わせて選べます。
期間、成果物、評価基準を決めておくと、取り組んだ結果を確かめやすくなります。
これからプログラマーを目指す人
1〜2か月を目安に、小規模なアプリを一つ完成させます。
アプリ本体、README、テスト結果、AIを利用した箇所と自分で修正した内容を残します。
主要な処理を説明できるか、生成コードを修正できるか、正常時と異常時の両方をテストできるかが評価基準です。
実装を中心に担当している現役プログラマー
1〜2か月を目安に、実装の前後にある工程を一つ担当します。
仕様整理メモ、レビュー記録、不具合調査記録などを残します。
仕様の不足を発見できたか、指摘した問題の理由を説明できたか、不具合の原因から修正結果まで確認できたかを振り返ります。
レビューやデバッグも担当している現役プログラマー
2〜3か月を目安に、一つの機能や改修へ設計段階から関わります。
複数の設計案を比較した記録や、技術的なリスクをまとめたメモを残します。
実装前に問題を予測し、設計案を採用した理由まで説明できるかが評価の目安です。
設計まで担当している現役プログラマー
3か月程度を目安に、自分が設計した機能をリリース後まで追います。
設計時の想定と実際の結果を比較し、障害や問い合わせからわかった改善点を記録します。
想定と異なった理由を説明し、次の設計で何を変更するか具体的に決められることが目標です。
なお、これらの期間は能力の習得を保証するものではなく、実践と振り返りの目安です。
次に経験する仕事を選ぶ際は、身につけたい力だけでなく、その仕事を今後も続けたいと思えるかも考えてみてください。
まとめ｜プログラマーの将来性は需要だけでなく仕事内容の変化で判断する
AI時代でも、プログラマーの需要がすぐになくなるとは考えにくい状況です。
ただし、IT人材への需要があっても、これまでと同じ仕事内容が続くとは限りません。
AIによってコード作成や設計が速くなれば、人が直接コードを書く時間は減り、生成されたコードの検証や修正、設計上の判断に使う時間が増えることもあります。
また、1案件あたりの工数が減っても、企業が追加開発を増やせば、レビューや確認の総仕事量が増える可能性があります。
反対に、開発件数を増やさない場合や、レビューやテストまで効率化できる場合は、人間の負担が減ることもあるでしょう。
これからプログラマーを目指す人は、コードを書く基礎を学びながら、AIが生成したコードを理解し、修正や検証まで経験しておくと、実際の仕事内容をイメージしやすくなります。
現役のプログラマーなら、今の担当業務から少し範囲を広げ、仕様確認やレビュー、設計などにも関わってみる方法があります。
ただ、できる仕事が増えることと、その仕事を続けたいと思えることは別です。
コードを書くことが好きだった人にとって、確認や判断が中心になる働き方は、必ずしも望んでいた変化ではないかもしれません。
今後の働き方に迷っているなら、まずは自分がコードを書いている時間と、確認や判断に使っている時間を振り返ってみてください。
これから目指す人なら、AIが生成した小さなプログラムを自分で修正し、動作を確かめてみる。
現役のプログラマーなら、今の仕事で続けたい作業と、これから経験してみたい工程を一つずつ書き出してみる。
そうして選んだ仕事を実際に経験することが、次に何を学び、どんな役割を目指すかを決める手がかりになります。
よくある疑問
Q. AIが普及するとプログラマーの仕事はなくなりますか？
AIが普及しても、プログラマーの仕事がすぐになくなるとは考えにくい状況です。
ただし、コードを書く作業の一部はAIによって効率化され、仕事内容が変わる可能性があります。
今後はコード作成だけでなく、設計や検証、修正方針の判断などを担当する機会が増えることも考えられます。
Q. AIでコードを書けるなら、今からプログラミングを学ぶ意味はありますか？
AI時代でも、プログラミングを学ぶ意味はあります。
AIが生成したコードを実際の開発で使うには、処理の仕組みを理解し、不具合があれば修正できる基礎が必要だからです。
これから学ぶなら、自分でコードを書く練習に加え、AIが生成したコードを読み、動作を確かめる経験も役立ちます。
Q. AIを導入すればプログラマーの仕事量は減りますか？
AIを導入しても、プログラマーの仕事量が必ず減るわけではありません。
1案件あたりの工数が減っても、企業が追加開発を増やせば、レビューや確認に使う総時間が増える場合があります。
反対に、開発件数を増やさなければ、仕事量は減り得ます。
レビューやテストまで効率化できるかどうかも、負担を左右します。
Q. AI時代のプログラマーにはどんな仕事が残りやすいですか？
設計方針の決定、AI生成コードの検証、不具合の修正方針の判断、公開可否の決定などが残りやすい仕事です。
たとえば、AIが複数の設計案を出しても、納期や予算を踏まえてどれを採用するかは、現時点では人間側が決める必要があります。
ただし、人間が担当する範囲は、AIの性能や企業の開発体制によって変わる可能性があります。
Q. 現役プログラマーはAI時代に何から始めればよいですか？
まずは、今担当している仕事の一つ前か一つ後ろの工程を経験する方法があります。
実装が中心なら仕様確認やコードレビュー、レビュー経験があるなら設計への参加など、今の仕事とつながる工程から始められます。
その際は、何を確認し、どう判断したかを記録しておくと、自分ができるようになったことを振り返りやすくなります。
編集後記
私がいちばん気になっていたのは、AIでコードを書く時間が減っているのに、仕事そのものはあまり楽になっていないように見えたことです。
AIによって設計や実装が速くなり、次々と新しいコードが上がってくる。
そのたびにレビューをして、問題があれば修正を依頼し、また確認する。
コードを書く時間が減った分、確認する仕事に追われているように感じます。
もちろん、どの開発現場でも同じことが起きているわけではないでしょう。
AIによって作業の負担が減り、以前より余裕を持って働けるようになった人もいると思います。
ただ、プログラムを書くことが好きでこの仕事を選んだ人にとって、レビューや確認が中心になる業務の変化は、単に仕事が効率化されたという話では片づけられない気がします。
私自身、プログラマーの将来性を考えるとき、「AIに仕事が取られないか」だけでは足りないと思っています。
これから残っていく仕事を、自分はやりたいと思えるのか。
たとえプログラマーという職業が残っても、コードを書く楽しさを感じる時間が減り、確認する仕事ばかりになったとしたら。
その変化をどう受け止めればよいのか、私にはまだ引っかかるものがあります。
参照・参考サイト
経済産業省「IT人材需給に関する調査」調査報告書
https://www.meti.go.jp/policy/it_policy/jinzai/houkokusyo.pdf
IPA「DX動向2025」本文
https://www.ipa.go.jp/digital/chousa/dx-trend/tbl5kb0000001mn2-att/dx-trend-2025.pdf
Stack Overflow「2025 Developer Survey AI」
https://survey.stackoverflow.co/2025/ai
GitHub Docs「タスクに適した AI ツールを選択する」
https://docs.github.com/ja/copilot/concepts/choosing-the-right-ai-tool-for-your-task
GitHub Docs「GitHub Copilotによるコードレビューについて」
https://docs.github.com/ja/copilot/concepts/code-review/code-review
GitHub「Research: quantifying GitHub Copilot’s impact on developer productivity and happiness」
https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/
コメント