【AIでプログラミング不要】という幻想
この記事は「paiza Advent Calendar 2024」の最終日の記事です。
最終日はpaiza株式会社で社長をやっている片山がお送りいたします。
ちなみにタイトルある「幻想」は、ペガサス幻想と同様に、「ファンタジー」と読みかえてください。
ちなみに、paizaはITエンジニア向け国内最大の転職・就職・学習プラットフォームです。（paiza.jp)
この記事を書くに至った背景
約2年前の2022年11月30日にChatGPTが登場して以来、AIでプログラミングは自動化され不要になり、そしてITエンジニアの仕事もなくなるだろう、と盛り上がっています。
弊社はITエンジニア向けの転職・就職・学習サービスを展開している関係で「ITエンジニアの仕事はなくなるのか？どうなっていくのか？」「プログラミングを学ぶ必要はなくなるのでしょうか？プログラミング不要になるのでしょうか？」という質問を社内外から良く聞かれることがあり、その都度色々考えたり調べたりして回答してきたのですが、折角なのでそれらについてまとめてみました。
つまり今回は、「AIの登場によりITエンジニアの仕事がなくなるのか？」、「AIでプログラミングは不要になるか？」についての考察する記事です。
プログラミングは無くなるのか？
AIの登場によりITエンジニアの仕事がなくなるのでしょうか？
もしくはAIでプログラミングは不要になるのでしょうか？
勉強しないでもITエンジニアになれ、軽々年収1,000万円overで札束風呂を目指せるのでしょうか？
夢見るのは自由ですが、私の答えは「No」です。
ITエンジニアの仕事はなくならないし、プログラミングは不要にならないし、今後よりプログラミングへの理解は重要になると考えます。
なぜでしょうか？
それは皆が考えるより、プログラミングにおいてAIが代替できる領域が少ないからです。
良く「AIに任せればプログラミングをしてくれる」という話がありますが、AI任せるためには、まずコードを書く部分をタスク化する前工程の作業が発生します。AIに的確なコードを出力させるためには（一般的な言い方だと「AIにプログラミングさせるには」）、的確に指示を出せるスキル、出力されたコードを読みとけるスキル、修正を依頼するためのスキルなど、ITエンジニアとしての基本的なスキルが必要になります。
つまり、AIによってコードを書く作業は効率化できるのですが、プログラミングというのはコードを書くことだけを指すわけではなく、コードを書く部分に持っていくための前工程や、コードを書いたあとの後工程まで含めてプログラミングなので、プログラミングの仕事はそう簡単にはなくならないのです。
このあたりについてもう少し詳しく考えて行きましょう。
まずは歴史を見てみよう
少し話は変わりますが、メディアは煽りがち、という事例について、昨今のAIブームと似たような話があるのでまずそれを紹介します。
先日、「ストーリーとしての競争戦略」で有名な、一橋大学院特任教授の楠木建さんのセミナーに行ってきました。とても素敵なイケオジでした。彼はセミナーのなかで次のように言っていました。
日経ビジネスを1969年の創刊（55年前）から調べてみたところ「戦後最大の危機」が2年に一度ぐらいのペースで訪れている
23回目の「戦後最大の危機」はコロナ、そして翌年には24回目の「戦後最大の危機」としてウクライナ侵攻が出てきた
同様に、毎年のように日経ビジネス上では「産業革命」が起きている(！)
「戦後最大の危機」と「産業革命」が毎年のように出てくるので実質的に大安売り状態です。毎年100年に一度の当たりが出るボジョレ・ヌーボーや、毎年過去最大を更新するスギ花粉の様相を呈しています。（起きている事象についてではなく、言い回しとしての話です）
楠木建さんの著書「逆・タイムマシン経営」でも次のような一説がありました。
現在のロボットはまだ、溶接や塗装などに適用分野が限られているし、知能レベルがだいぶ劣る。現在、経営者が関心を強めているのは、組み立て作業など、もっと複雑で、省力効果の大きい分野のロボット化だ。 こうした作業を満足にこなせるのは、知的機能を備え自分である程度判断できる、知能ロボットである。すでに初歩的なものが登場し始めている。
では、実用化はいつか。松下通信工業の唐津一常務は、「知能ロボットの技術は5、6年で完成し、生産システムに大きな革命が起こるだろう」と予測する。 （中略）
キーをたたかなくとも、話を聞きとる音声入力が事務機で実用化されるのも、「速ければ5年以内」（東京芝浦電気）という。技術的には、意外な早さでロボットショックがやってくる。次世代、すなわち息子たちは、完全にその渦中にあるだろう。
10年ぐらい前の話かな、と言うようにも読めますが、実に41年前（1983年）の日経ビジネスの記事です（日経ビジネス1983年4月5日号「迫りくるロボットショック。息子たちに仕事はあるのか」）。
「キーをたたかなくとも、話を聞きとる音声入力が事務機で実用化されるのも、速ければ5年以内」とありますが、AppleのSiriが登場するのが2011年（28年後）、AmazonのAlexaが登場するのが2014年（31年後）、Googleアシスタントが2017年（34年後）と、随分待たされたわけです。そして未だにSiriもAlexaもgoogleアシスタントも、正直なところたいして使いやすくはありません。（アホなところが可愛くはありますが）
で、何がいいたいのかというと、人間は新しいものを「過剰に評価しすぎる」ということです。
何度もITエンジニアの仕事はなくなるはずだった
ITエンジニア領域、プログラミング領域でも「ITエンジニアの仕事がなくなる！」という過剰評価が過去何回か起きています。これまで何回もITエンジニアの仕事はなくなるはずだったのです。
4GL(第4世代言語)・CASEツールブーム（1980～1990年代）
COBOLやCといった当時主流の手続き型言語を使った低レベルなコーディングを不要にする「第4世代言語（4GL）」や「CASEツール (Computer-Aided Software Engineering Tools)」が盛んに注目されました。これらは要件定義や設計情報から自動的にコードを生成できる、いわゆるモデル駆動のアプローチを取ることで、エンジニア不要論が叫ばれた時期でもあります。Visual BasicやPowerBuilder、RADツール（1990年代）
Windowsアプリケーション開発の草創期には、Visual Basic、PowerBuilder、Delphiなど、ドラッグ＆ドロップでGUIを配置し簡単にアプリを組み立てられる「Rapid Application Development (RAD)ツール」が注目され、「これでコーディングが大幅に軽減され、プログラマーはいらなくなるのでは？」という声が上がりました。Delphi学んでみようかと考えていたことがあるので懐かしいです…。ノーコード・ローコードプラットフォームの台頭（2000年代後半～現在）
SalesforceのLightning Platformや、Microsoftの「Power Apps」、国内ではサイボウズの「kintone」など、ノーコード・ローコードプラットフォームが登場し、ビジネスユーザーがGUI上でアプリを組み立てられるようになりました。これにより「プログラマーなしでビジネスアプリ構築可能」というマーケティングが再度浮上し、「エンジニア不要論」が再燃しました。Webサイトビルダー、WYSIWYGエディタ（1990年代～2000年代）HTMLコーダー
これは純粋なプログラミング言語の話ではありませんが、HTMLコーディング、JavaScriptの文脈で、WYSIWYGエディタの登場時も「コーディング不要でプロレベルのWebサイト作成が可能」「もうWeb開発者はいらない？」というような言説は出てはいたようです。
上記にあげたような事例は様々あり、初期は機械語からアセンブラ、アセンブラから高級言語、高級言語からWebフレームワーク、SQLからORMといった変遷の中でも「書かなくて良くなる」「仕事がなくなる」的なことはくり返し言われてきました。（SQL、いまだにみんな書いてますよね…）
しかし「ITエンジニアやプログラマーの仕事がなくなる」と騒がれながら、結局は今現在ITエンジニア不足が続いており、2030年には79万人のIT人材不足、アジャイル/DevOpsエンジニアを含む先端IT人材は2030年人54.5万人足りなくなると言われています。仕事がなくなるどころか爆発的に仕事は増えているのです。
ではなんで、これほど便利そうなツールの登場や言語の進化があってもITエンジニアの仕事はなくならないのでしょうか？
プログラムが書けない人は、ロジックも組めない
プログラミングのことを良く知らない人は、ITエンジニアの仕事をキータイピングっぽく考えがちです。
「なんかこう、キーボードをカタカタ打ってる仕事？みたいな？」という理解です。もう少し解像度が高い人だと「こういうシステムが欲しいというと、カタカタやって作ってくれる仕事」という感じです。
「キーボードをカタカタ」はAIやノーコードローコードがやってくれるようになればITエンジニアいらないよね、となりがちです。
では実際それ（ITエンジニアいらないよね）を実践してみるとどうなるのでしょう？
先日研修をおこなっている企業の方と話をする機会があったのですが、まさに「ITエンジニアいらないよね」という事例について話を聞くことができました。
以下がその事例です
研修を依頼してきたのはノーコード・ローコード中心に開発を行っている2,000〜3,000名のIT企業
ノーコード・ローコードでプログラミング不要なので、プログラミングに触れたことがない学生（その方いわく、「キラキラ系ゆるふわ文系学生」）を大量採用（文系差別の意図はありません。リアリティをもってもらうためにその方が言った言葉を書いています。）
プログラミングに触れたことがない学生ではロジックが組めず、ノーコード・ローコードもまともに開発できなかった
ロジック組めるようにしたいということで、Javaの研修を依頼された
研修を行ったが、そもそもプログラミングやロジックを組むことに適性がない人も多く頭を悩ませている（「なんでこんな面倒な事やらないといけないのか」という不満が多いとのこと…）
プログラミングやったことある新卒取った方が良いよね、となっている
自分で直接見たわけではなく、担当の方から聞いた話なので多少盛られている部分はあるかもしれません（文系でもプログラミング適正ある方は多く見てきました）が、この採用基準だと概ねそうなるであろうことは容易に想像がつきます。
プログラムのロジックを組む際は、こういうことを実現したいという表面上の要望から、それをどういう処理、手順であれば実現できるのか？例外的なケースではどのように対応すべきなのか？どのようなデータの持ち方をすれば再利用性がたかくなるか？そもそも何を実現したいのか？作る必要あるのか？別の実現方法はないか？今後どういう発展があるのか？というようなことを考えながらロジックに落とし込んでいくわけです。
頭の中でフローチャートやデータ構造、状態がどう変化していくかを考える抽象度の高い仕事になりますが、プログラミングをしたことがなければこういったことを身につける機会というのは殆どありません。
その結果、プログラミングできないとロジックも組めず、ロジックが組めないとノーコード・ローコードでも開発できない、となります。これはAIにプログラミングをさせようとしても同じことがおきます。
ロジックが組めない人は、まずロジックをまともに読み解けないし、ロジックの良し悪しも判断もできないのです。曖昧な依頼でも、AIからは「何となくそれらしも」のは出てきますが、適切なロジックでなければ意図しない振る舞いになり、そのまま本番稼働させれば大きな事故の要因ともなります。適切なロジックをベースとした、的確な指示をAIにおこない、その指示通りにできているかのチェックができなければ業務では使えないのです。
最低限基本的なロジックを考え自分でコードが組めるぐらいのレベル感でなければ、AIに対しての的確な指示は難しいでしょう。例えばですが、paizaのプログラミングスキルチェックで最低限Aランクぐらいが取れないと、AIを効率的に使うことすらできないと思ったほうが良いと思います。そのぐらいのプログラミングスキルがなければ、なぜこのコードなのか、ということを説明することすらできないからです。AIを使うのではなく、AIに使われるのが関の山です。
興味がある方はpaiza上で無料でプログラミングスキルチェックができるので、自分がAIを使う側か使われる側なのか、ぜひ試してみ見てください
狭義のプログラミングと広義のプログラミング
狭義のプログラミングは「コードを書くこと」です。仕様書があり、時と場合によってはフローチャートまであり（最近殆ど見かませんがが）、それをプログラムコードに落としこむコーディングを指します。この部分はAIによって効率化をしやすい領域です。
とはいえ最近ではフローチャートもあまり見かけませんし、あったとしてもロジックとしてヌケモレがないとも言えず、仕様書も一定のヌケモレがあるものです（そもそもヌケモレのない仕様書って見たことない！）。
となると、その抜け漏れている部分はどうするかを企画側と検討しながら、全体として破綻がないよう実装方法検討する必要があります。AIによるコード生成は、現時点だと指示の曖昧さを独自解釈しながらそれらしいものを出力してしまうので、それらを見つけながら補正をしていく必要が出てきます。そのため現時点では100％の自動化は難しく、調整役が必要となります。
広義のプログラミングは企画側とのミーティング、仕様調査、既存コードの読み込み、実装方法の検討、テスト設計、ローンチタイミングの調整など、コードを書く前後工程までを指します。実際のITエンジニアの仕事は、広義のプログラミングを行うことであり、ここの部分に関してはAIは現時点だとあまり役に立ちません。
AIが、せっせとPdMやデザイナーに話を聞きに行って調整してくれるわけでもないし、業務フローを調査してくれるわけでもなければ、仕様調査してくれるわけでもありません。（仕様調査はそのうちやってくれそうですが）。
現状のAIは、自主性のない指示待ち人間みたいと言われても仕方がありません。
現時点でAIで効率化ができるのはコーディング部分であり、ITエンジニアの仕事でも狭義のプログラミング部分だけです。AIにプログラミングを出力させるためには、的確な指示を出せるスキル、出力されたコードを読みとけるスキル、修正を依頼するためのスキルなど、ITエンジニアとしてのスキルが必要になります。（こういった仕事を「ITエンジニアの仕事ではない」という人は本物のITエンジニアではないと思われます。）
AIで、プログラミングはどのぐらい効率化できるのか？
ではコードを書く部分で実際どのぐらい効率化が可能なのでしょうか？
paiza社内のエンジニアから17名ほどに協力してもらい、Mtg、仕様調査、既存コードの読み込み、実装方法の検討など除外したコードを書く部分の業務を、1週間40時間のうち何時間程度行っているかアンケートを取ってみました。
業務におけるコーディングが占める時間（paiza社内エンジニア調べ）
週32時間コードを書く：回答者の0％
週28時間コードを書く：回答者の0％
週24時間コードを書く：回答者の0％
週20時間コードを書く：回答者の12％
週16時間コードを書く： 回答者の0％
週12時間コードを書く：回答者の29％
週8時間コードを書く：回答者の53％
週4時間コードを書く：回答者の0％
週4時間未満コードを書く：回答者の6％
コードを書く時間は、平均すると週40時間のうち約10時間（25％）ということでした。n数は少ないですが、元々自分が思っていたエンジニアの仕事のうちのコードを書く時間感覚ともそれほど齟齬はありませんでした（私も昔は開発をしていました。）
このコードを書く10時間をAIによって効率化したとしても、試行錯誤は発生するため10時間の作業が2時間ぐらいになるのが限界値でしょう。そうすると週40時間のうち8時間（約20％）の効率化が最大値となります。
少し前にAIで有名な東大松尾研の松尾教授の話を聞きに行った際に「AIで業務効率化できているのは15％」とおっしゃっていましたが、それともだいたい合います。
※松尾教授の界隈では「その15％を何に使うのか？」という議論がされていると話されておりました。「AIがプログラミングしてくれる」という話しからすると、これまたずいぶん遠い話です。
では何が起きるか？
ITエンジニアの仕事の20％の効率化されるとして何が起きるのでしょうか？
「20％のITエンジニアが不要になる！」メディアはそう書きたがるかもしれません。そういうことをすでに色々書かれてもいます。しかしそんな事はありません。
皆さん（とくに経営者、PdM、企画側の方は）、胸に手を当てて良く考えてみてください。今まで一度でも良いので、開発したい機能のすべてが実装され、やること、やりたいことがなくなったことがあるでしょうか？
そんな事、一度たりともあったためしはありません。機能を削る話はあれども、もっとやれますと言われたことはありません。
（エンジニアの皆さんすみません、言い過ぎました。ごくごくたまにもっとやれます言ってもらえることはあります。）
競合が出してきた新機能、新サービス、気にならない人はいるのでしょうか？ 営業の人ならば、「これすぐできます」と思わず盛って言って案件取ってきてしまったことはないのでしょうか？
ないんです、そんな事。一度たりとも。
幻想（ファンタジー）です。
「仕事がなくなる！」と言っている人たちの頭の中には、世の中の仕事量が常に一定であるという無邪気でお花畑のような無自覚な前提条件があります。確かに仕事量が一定量であれば効率化された分、仕事はなくなります。
しかしこれは間違っていて、原理原則としてエントロピー増大の法則が示すように「物事は放っておくと乱雑・無秩序・複雑な方向に向かい、自発的に元に戻ることはありません」。
何がいいたいのかというと、人は余剰ができればいろいろなことを試し始めるのです。
色々試すことこそがイノベーションに繋がるのです。
余裕があれば色々やりたくなる心は誰にも抑えきれません。
ペガサス幻想（ファンタジー） そうさ夢だけは
誰も奪えない 心の翼だから
では今後何が起きるかというと、次のような流れが考えられます
ITエンジニアの仕事が20％ぐらい効率化され、新機能リリースまでの速度が上がる
20％ITエンジニアを減らそうとなる（そうはならないんですが）
その間に競合は新しい機能をリリースし優位性を築く
放おっておくと優位性がどんどん損なわれるため、競合と同様に開発速度を上げようとなる
結果、減らしたITエンジニア枠を再度採用し、さらに採用余力があるところまで採用して競合優位性を作ろうとする
つまり全世界的に開発速度が上がり、仕事はなくならないどころか、施策を試す量が増え、それとともに開発量は増え、それによりシステムの複雑度が増し、今まで以上に忙しくなることでしょう。
まとめ
いろいろとダラダラ書いてしまったしたが、まとめると次のようになります。
プログラミングとは実現したいことを整理し、ロジックを考え、タスク化する事自体を含む
ロジックが組めなければコードは書けないし、殆どの場合コードが書けなければロジックも組めない
一定のプログラミングスキルレベル（paizaランクAランクぐらい）がなければAIも使いこなせない
ITエンジニアの仕事のコードを書く業務は全体の25%程度とそこまで多くない
現在AIが効率化できる領域はタスク化されたコードを書く領域
現在のITエンジニアの仕事は20%程度は効率化される可能性はある
今後コードを書く時間は減るが、コードを書く以外の仕事のほうが多いのでITエンジニアの仕事は減らない
開発速度が上がれば変化の速度は今以上に早く、複雑になり、よりITエンジニアの仕事は増える
というようなことになります。
こうなると初学者がコードを書き、ロジックを組む鍛錬の場が失われ、AIを使って効率化をするベテランとの差が開くことが課題になってくるかもしれません。
そんな人にはpaizaラーニングと、paizaスキルチェックがおすすめです。
さいごに、少し哲学的な話かもしれませんが、人間は誰かに責任を求めたいものです。大きな投資を伴う開発となればなおさらです。責任とは何でしょうか？それはきっと痛みを伴うものです。人間は死があるから痛みがあるのです。死を回避するシステムとして痛みがあるのです。しかしAIには死もなければ痛みもありません。AIは今のところ責任は取りません。
人は責任を求めたい。もしかすると死があるから責任が取れるのかもしません。それがAIにも生まれたときにシンギュラリティは起こるのかもしれません。
最後までお読みいただきありがとうございました！
この記事を読んでプログラミングスキルをはかってみたいと思った方
↓こちらのスキルチェックをどうぞ