本記事では、AIに代替されやすい業務と、エンジニアやプログラマーが介在する価値、これから必要になるスキルを、開発を担う方や開発体制を考える立場の方に向けて解説します。今後の役割を考える参考にしてください。
プログラミングの仕事はAIに奪われるわけではない
AIによるコード生成は、ここ数年で急速に進化しました。自然言語で指示を出すだけでアプリが動くところまで作れるようになり、コードを書く作業の負担は確実に軽くなっています。
自動化が進んだのは、仕様がはっきりしている実装や既存コードをもとにした作業です。こうした領域では、AIに任せられる範囲が確実に広がっています。
ただし、プログラマー全体が不要になるという結論にはつながりません。開発の仕事は、コードを書くことだけで成り立っているわけではないためです。何を作るかを決め、複数の条件を比べて設計を選び、できあがったものが正しいかを確かめる。この工程を担う人がいなければ、AIが速くコードを出しても使えるシステムにはなりません。
奪われるかどうかより、担当する範囲が移っていくと考えるほうが実態に近いはずです。コーディングAIそのものについては、コーディングAIとは？仕組み・メリット・主要ツール・活用のポイントを解説もあわせてご覧ください。
AIに代替されやすいプログラミング業務
AIに任せられる業務は、仕様が明確で判断の余地が少ないものに集中しています。実際に人の手から離れていく作業を4つ挙げます。
- 定型的なコード生成や補完
- テストコードやドキュメントの作成
- 既存コードの解析や単純な修正
- プロトタイプや小規模な機能の実装
定型的なコード生成や補完
定型的なコードは、AIがもっとも得意とする領域です。データの登録、参照、更新、削除といった基本的な処理は書き方がほぼ決まっているため、指示さえ出せば正確なコードが返ってきます。
画面の入力フォームやAPIの受け口など、過去に何度も書いてきた形のコードほど、AIに任せる効果が出ます。手を動かす時間が減るぶん、設計を考える時間へ回せる点も利点です。
テストコードやドキュメントの作成
テストコードやドキュメントも、AIに下書きを作らせましょう。既存のコードを読み込ませれば、どんな入力に対してどんな結果を期待するかを整理し、テストの形に落としてくれます。
仕様書やコメントの生成も同じです。後回しになりがちな作業を短時間で形にできるため、品質を保ちながら開発を進めやすくなります。ただし、書かれた内容が実態と合っているかの確認は人が担うことに注意しましょう。
既存コードの解析や単純な修正
既存コードの読み解きは、AIに任せると時間を大きく短縮できます。ドキュメントが残っていないコードでも、処理の流れや依存関係を説明させられるためです。
エラーの原因調査や、変数名の変更のように影響範囲が限られる修正も同様です。書いた本人がいない古いコードを引き継ぐ場面で、AIの解析は実務的な助けになります。ただし、AIの説明が正しいかどうかは動かして確かめる必要があります。
プロトタイプや小規模な機能の実装
要件がはっきりしている試作品なら、AIにひととおり作らせる進め方も有効です。社内で使う小さなツールや、企画を説明するためのデモ画面は、その代表になります。
動くものを早く見せられると、関係者との認識合わせが進みやすくなります。一方で、そのまま本番へ持っていける品質かどうかは別の話です。試作と本番の線引きは、人が判断する部分になります。
AI時代にエンジニアやプログラマーが介在する価値
AIが書ける範囲が広がるほど、人が担う仕事の輪郭ははっきりしてきます。エンジニアやプログラマーが介在する価値を5つに整理しました。
- 曖昧な要求を具体的な要件へ落とし込む
- システム全体を見て設計を判断する
- AIが生成した成果物の品質を検証する
- プロジェクト固有の制約を判断する
- 関係者と合意形成し最終的な責任を担う
曖昧な要求を具体的な要件へ落とし込む
曖昧な要求を要件の形にする仕事は、人が担います。顧客や社内の依頼者が、最初から完成した仕様を持っているとは限らないためです。
たとえば『売上をすぐ確認できるようにしたい』という依頼には、誰が、どの単位で、いつ見るのかが書かれていません。AIは渡された条件を整理できますが、渡されていない条件を掘り起こす動きは苦手です。足りない部分を質問で引き出す作業は、人が担うべきでしょう。
システム全体を見て設計を判断する
システム全体を見て設計を選ぶ判断も人がしなければならない仕事のひとつです。動くコードと適切な設計は別物だからです。
たとえば、性能、コスト、安全性、保守のしやすさは、多くの場合衝突することが多いです。処理を速くすればコストが上がり、機能を足せば保守の手間が増えるといった調整は、組織の事情を踏まえないと決められません。AIは選択肢を並べる作業までは担えても、そのどれを採るかは人の判断です。
AIが生成した成果物の品質を検証する
AIが出した成果物を検証する役割は、AIを使うほど重くなります。生成されたコードは、動いていても想定と違う処理をしている場合があるためです。
コードレビュー、テストの設計、脆弱性の確認といった工程は、AIに書かせた分だけ増えていきます。とくに個人情報や決済を扱う部分では、見落としが事故に直結します。書く量が減っても、確かめる量が減るわけではない点に注意してください。
プロジェクト固有の制約を判断する
プロジェクト固有の制約を判断できるのは、その現場を知る人だけです。既存システムとのつながり、社内の業務ルール、使えるハードウェアの性能、法令や安全規格といった条件は、AIの学習データには入っていないからです。
組込み開発では、この差がとくに大きく出ます。限られたメモリで動かす、決められた時間内に必ず応答する、安全規格に沿って設計するといった制約は、一般的なコードの書き方とは前提が異なる部分です。制約を織り込んだ判断ができる人がいるかどうかで、開発の質は変わるため、必ずプロジェクト固有の制約の判断は人がおこないましょう。
関係者と合意形成し最終的な責任を担う
関係者との合意形成と最終的な責任はAIではなく人が担います。顧客、開発者、運用担当のあいだで意見が割れたとき、どこに落とすかを決めるのは組織の判断だからです。
不具合が起きたときに説明を求められるのも、AIではなく担当した人です。そのため、なぜその設計にしたのか、どこまで確認したのかを語れる状態にしておく必要があります。決めた理由を記録に残しておく習慣をつけておくことで、設計の理由や確認の進捗を説明できるでしょう。
AIの普及でエンジニアやプログラマーの仕事はどう変わる？
AIの普及でエンジニアやプログラマーの仕事が奪われるわけではなく、仕事の内容が変わると理解しましょう。具体的な変化の方向について 3つ紹介します。
- コードを書く作業からAIへ指示する作業が増える
- 実装だけでなく開発工程全体を見る役割になる
- AIを使える人と使えない人で生産性に差が出る
コードを書く作業からAIへ指示する作業が増える
AIの普及によって、人がコードを書く作業は減り、AIへ指示する作業が増えます。開発の入り口になるのは、何を作りたいのか、どんな条件を守ってほしいのかを言葉にする作業です。
AIによるプログラミングのよしあしは、AIに渡す前提情報の質によって決まります。用語の定義や既存の設計方針、使ってはいけないライブラリなどの情報を揃えて伝えることで、修正を減らして、理想に近いコードを書けるでしょう。
実装だけでなく開発工程全体を見る役割になる
エンジニアやプログラマーは実装だけでなく、開発工程全体を見る役割を担うようになります。AIが実装を速くする分、設計の甘さやテストの不足があると、ミスに気付かぬまま開発が進んでしまうためです。
そのため、今後はエンジニアやプログラマーは要件の整理から設計、テスト、運用まで見渡すスキルが必要になります。工程のどこにAIを入れて、どこで人がストップをかけるかを見極められる人が、チームの成果を左右するといって良いでしょう。
AIを使える人と使えない人で生産性に差が出る
もちろん、仕事をAIに奪われるエンジニアやプログラマーがいないとは言えません。AIを使いこなせる人とそうでない人のあいだで、生産性の差が開きやすくなるためです。同じAIツールを渡されていたとしても、AIへの指示の出し方や任せ方の判断で結果が変わります。
AIを導入すればプログラミングが速くなるわけではなく、最初のうちは生成されたコードの確認や手直しに時間を取られ、かえって遅くなる場面もあるでしょう。AIに慣れ親しんでいる人はAIに任せる作業の判断、手直しを減らす指示の出し方ができるため、このような時間を削減して成果を出せるようになるはずです。反対に、AIが使えない人はAIに任せたほうが仕事に時間がかかるといった事象も生まれるでしょう。
AI時代に求められるエンジニア・プログラマーのスキル
エンジニアやプログラマーがAI時代に身につけたいスキルは、コードを書くスキルではなく、AIとの分担を設計する力です。とくに重要なスキルについて2つ紹介します。
- AIに何を任せ何を確認するかを設計するスキル
- 業務やドメインを理解するスキル
AIに何を任せ何を確認するかを設計するスキル
エンジニアやプログラマーは、AIに何を任せて、人が何を確認するかを設計するスキルを身につけましょう。AI時代にはプロンプトを上手に書く技術よりも、任せる範囲と確認の方法を設計できるかどうかの方が大切です。
たとえば、画面の見た目はAIに任せて権限のチェックは人が書く、テストはAIに書かせて境界値の条件は人が指定するなど、こうした線引きは人が決めてチームで共有しておくべきです。
これにより誰が作業しても品質は揃いやすくなり、属人化の防止にもつながるでしょう。
業務やドメインを理解するスキル
業務やドメインの知識は、AIが持っていない領域です。自社の商習慣、業界特有の規制、現場の運用ルールは、公開された情報として出回っていません。
たとえば製造業のシステムなら、ラインの稼働時間や検査の手順を知らなければ、要件そのものを書けません。AIが一般的な正解を出せるほど、自社固有の事情を知っている人の価値は上がって行くといえるでしょう。
開発の知識と業務の知識を両方もつ人材の確保については、IT人材不足はなぜ起こる？「当たり前」と言われる7つの原因と企業・求職者が取るべき対策もあわせてご覧ください。
AIを活用したシステム開発ならブライセンへ
AIでコード生成を自動化するだけでは、品質や安全性まで担保できるとは限りません。速く書けるようになったぶん、人が確かめる工程をどう組むかが問われます。
弊社では、AIが得意な作業と人の判断が必要な作業を切り分けた開発体制のご提案が可能です。とくに組込み分野では、限られたリソースや安全規格といった制約を理解したエンジニアが、AIの成果物を評価しながら開発を進めます。
体制づくりの段階からご相談いただけますので、ぜひお問合せください。
Safety & Modern 組込みAI駆動開発｜xTECHソリューション｜ブライセン
まとめ
プログラミングの仕事がAIにすべて奪われる可能性は低いです。定型的なコード生成、テストやドキュメントの作成、既存コードの解析といった作業はAIへ移っていきますが、開発の仕事はそれだけで成り立っているわけではありません。
曖昧な要求を要件に落とし込み、条件を比べて設計を選び、できあがったものを検証し、関係者と合意を取る。この部分は人が担い続けます。
AIに書かせるコードの量が増えるほど確認の役割や責任は重くなっていくため、人の仕事が奪われるというよりは担う役割が上流工程に近くなっていくと考えた方が良いでしょう。
これから身につけたいのは、AIに何を任せて何を確認するかを設計する力と、自社の業務やドメインを理解する力です。まずは自社の開発工程のうち、どこをAIに任せられるかを洗い出すところから始めてみてください。
\あらゆる業界のDX化をおまかせください！/
お問い合わせ
