AIでコード生成が速くなっても忙しい理由
AIが数秒で完璧なコードを出力してくれるようになったのに、なぜ現場のプログラマーは今日も残業しているのか?
そうですね。これって本当に不思議な現象ですよね。
リスナーの皆さんもこんな疑問を持ったことはありませんか?
今日は、あなたのキャリアや毎日の働き方に関わるこの奇妙な矛盾について深掘りしていこうと思います。
魔法のツールを手に入れたはずの開発現場で、今まさに大きなパラドックスが起きていますからね。
そうなんです。タイピングの時間は劇的に減ったはずなのに、なんだか以前より忙しくなっているという声があちこちから聞こえてくるんですよ。
はい。これは単にプログラマーという仕事がなくなるかどうかといった単純な話ではないんです。
なるほど。
仕事の性質そのものがどう変質しているのかを直視する必要があるんですよね。
これ、例えるならレストランの厨房みたいな状況ですよね。
厨房ですか?
はい。超高速で野菜を刻む最新の調理ロボットを導入したような状態というか。
なるほど。それは分かりやすいですね。
人間が包丁を握って玉ねぎとか人参をみじん切りにする時間は確かにゼロになったわけです。
あっという間に終わりますからね。
でも結局料理長である人間がおいおいロボットが塩と砂糖を間違えてないかとか、
そもそもこれお客さんが求めていた味になってるかって次から次へと味見して回らなきゃいけない。
そうなんですよ。
だから結局厨房のバタバタした忙しさは全く変わっていないという、
まさに今のソフトウェア開発現場のリアルな光景と重なりますね。
やっぱりそうですか。
AIというアシスタントは私たちがこういう機能が欲しいと伝えると、
驚くべきスピードで膨大なコードの案を出してくれます。
本当に一瞬ですよね。
はい。既存のコードの続きを書いたり、データを処理する部分を作ったり、
でもその刻まれた野菜がそのまま安全な料理としてお客様に出せるかというと話は別なんですよね。
そこで味見、つまり人間による確認作業が絶対に必要になるわけですね。
その通りです。AIが出してきたコードが本当に使用通りに動くのかどうか、
既にある複雑なシステムと矛盾を起こさないかとか、
他の機能に悪影響、つまりバグを生み出さないか、そういった検証作業です。
それって既存のシステムという大きなお皿にどう盛り付けるかを見るみたいなことですよね。
まさにそれです。この作業は絶対に減りません。
むしろコードが生成されるスピードが速くなった分、
次から次へとこれどうですかってAIから提案が上がってくるわけですから。
それは逆にパニックになりそうですね。
そうなんですよ。自分でタイピングする時間は減っても、
AIが書いたコードの意図を読み解いて検証する仕事は全く減っていないんです。
IT人材不足とプログラマーの役割の変化
ちょっと待ってください。状況を少し整理しましょう。
もしAIがそこまで高速に作業をこなしてくれるなら、
ずっと言われているIT人材不足って嘘になりませんか?
その疑問は最もですね。
ですよね。今後の高い成長シナリオなんかを見ると、
2030年に約79万人のIT人材が不足するとか言われていますし。
国内企業の85%以上がDX推進の人材が足りないと感じているというデータもありますね。
AIが人間の何倍も速くコードを書くなら、
その不足分なんてあっという間に解消される気がするんですが。
ここで興味深いのは、その数字の裏に潜んでいる罠なんですよ。
罠ですか?
確かに、単にコードをタイピングする量だけを計算すれば、
不足はたちまち解消されるように見えます。
でも、企業が本当に求めているのは、コードを書くという行為そのものではないんです。
と言いますと?
事業の課題を解決するシステムを作り上げて、それを安全に運用することなんですよね。
つまり、解決したいビジネスの課題自体が世の中に多すぎるってことですか?
その通りです。
AIがタイピングを型変わりするようになっても、
その手前にある、そもそも何を解決すべきかを定義する仕事は残ります。
なるほど。
それから、AIが出した結果をビジネスの要件にすり合わせる、
いわゆるシステム開発のマネジメントの需要も全く減っていません。
じゃあ、IT人材としての雇用自体は強く残るわけですね。
強く残ります。
でも、今まで通りエディタに向かって黙々とコードを書き続けるような、
そういう従来のプログラマーとしての仕事が保証されるわけではないんです。
仕事のスコープ、責任範囲が完全にスライドしているんですね。
まさにそういうことです。
厳しい現実へのシフトが起きているんですよ。
設計からデバッグまでの人間とAIの分担
じゃあ、具体的に実際の開発プロセスの中で、
人間とAIはどう役割分担していくんでしょうか?
ここ、リスナーのあなたも一番気になるところだと思います。
そうですね。
ソフトウェア開発を大きく、設計、実装、レビューとテスト、
そしてデバッグ、この4つの段階に分けて解剖してみましょう。
はい、お願いします。
まず、コードを書く前の設計の段階ですね。
ここでは、AIが曖昧な要望から必要な機能の整理をしてくれたり、
使用書の叩き台をいくつも出してくれたりします。
それはすごく助かりますね。
はい。でも、人間の要望って常に矛盾しているじゃないですか。
安く、早く、でも高品質で、みたいに。
ありますね、そういう無茶振り。
そういう矛盾の中で、予算や納期に合わせて、
今回はどの案を採用するかというトレードオフの決断を下すのは人間なんですよ。
なるほど。
AIが優秀なブレスト相手で、人間が編集長として決断を下すという感じですね。
はい。そこまではすごくいいチームワークに見えます。
でも、問題は次の実装やレビューの段階です。
何が起きるんですか?
AIが生成したコードを既存のシステムに組み込む際、
AIは局所的な解決策を出すのは得意なんですが、
システム全体への影響を完璧に把握することはまだ苦手なんです。
全体が見えていないということですね。
ええ。例えば、AIが一見完璧なショッピングカートの決済コードを書いたとしますよね。
はい。
でも、それを本番環境に繋いだ瞬間、
2人のユーザーが全く同じミリ秒で最後の1つの商品を買おうとした時、
というような特殊な条件下でだけ、エラーを起こすような抜け穴を生み出してしまうことがあるんです。
それは怖すぎます。
そうなんですよ。
しかも、AIが書いたコードですから、
どこにそんな落とし穴があるのか、人間がぱっと見では気づけないんです。
自分で書いてないから余計にわからないですよね。
だからこそ、レビューやテスト、そしてエラー原因を突き止めるデバッグの工程で、
人間の負担が激増するわけです。
AIがここが問題になりそうですって指摘してくれてもダメなんですか?
AIの指摘が本当に致命的な問題なのか、それともただの誤検知なのかを検証するには、
結局人間がシステム全体の構造を深く理解していなければならないんですよ。
皮肉な話ですよね。これってどういうことなんでしょうか?
ええ。
私たち、ものすごく作業が早いけれど、時々とんでもないミスを犯すアシスタントを雇ってしまったみたいな感じですよね。
まったくその通りです。
実際、多くの開発者がAIツールを使っている一方で、
約半数の人は、AIの回答の正確性を完全には信頼していないという現状もあります。
信頼しきれないからこそ、結局は人間による検証と判断に丸投げされて、レビューの負担が私たちを押しつぶそうとしているわけですね。
ええ。まさにそこがパラドックスの中心なんです。
ジェボンズのパラドックスと増える総仕事量
でも、ちょっとリスナーの皆さんの疑問を代弁させてください。
はい、なんでしょうか。
アシスタントが優秀で、一つの機能を作る時間が劇的に減っているなら、
いくら確認作業が増えても、トータルの労働時間はやっぱり減るんじゃないですか?
ああ、普通はそう思いますよね。
はい。早く仕事が終わって、みんな定時で帰れるようにはならないんでしょうか?
残念ながら、経済の仕組みはそうはなっていないんです。
全体像と結びつけて考えてみると、ここでジェボンズのパラドックスという経済学の概念が見えてきます。
ジェボンズのパラドックスですか?
はい。ある資源を効率的に使えるようになると、むしろその資源の消費量が増えてしまうという現象のことです。
効率が上がると消費が増える。どういうことか、もう少し詳しく教えてもらえますか?
はい。これ、まるでマジックのような算数のからくりがあるんですよ。
マジックですか?
具体的な数字で考えてみましょう。仮に、AI導入前、一つの案件で設計に40時間かかっていたとします。
はい。設計が40時間。
そして、実装とレビューに60時間かかっていたとします。合計で一案件100時間ですね。
一案件100時間。分かりました。
ここに、AIを導入して効率化に成功しました。設計が20時間になり、実装とレビューが40時間に短縮されたとします。
おお。
これで、一案件が60時間で終わるようになりました。
40時間も起きましたね。最高じゃないですか。
しかし、ビジネスの世界は空白を嫌うんです。司法主義においては、時間が余ったとなれば、経営層やクライアントはこう考えます。
な、なんて考えるんですか?
同じ期間と予算内で、もう一つ別の機能も開発しよう、とか、競合に勝つためにもっと案件を詰め込もう、と。
ああ、嫌な予感がしてきました。空いた時間は、結局新しい仕事で埋め尽くされるんですね。
そういうことです。じゃあ、計算してみましょう。
同じ期間で、二つの案件をやることになったとします。
はい。
一案件の設計は20時間だったので、二案件で設計はトータル40時間になります。これは、AI導入前と同じ時間ですね。
確かに、設計の時間は元通りになりましたね。
問題は、次のレビュー作業です。一案件の実装とレビューが40時間。それが二案件になるから。
ちょっと待ってください。40時間×2で80時間ですか?
そうなんです。
導入前は、レビューに60時間しかかかっていなかったのに。
全体を足すと、設計40時間プラス実装とレビュー80時間で、トータルの総仕事量は120時間になってしまうんです。
うわあ、100時間の仕事が、AIを入れたせいで120時間に増えてるじゃないですか。
これがカラクリです。AIのおかげで、一案件は劇的にスピードアップしたのに、効率化された分だけ案件数が倍増してしまう。
しかも、一番精神的負担の重い人間の確認作業が、導入前より膨れ上がってしまうわけですね。
はい。これこそが、AIを入れたのに前より忙しいという声の正体なんです。
AI時代に人間が担う判断と責任
これは恐ろしいパラドックスですね。じゃあ、総労働時間が増える中で、私たちが担当するのは具体的にどんな責任なんでしょうか?
ここからが本当に面白いところなんですが、究極的には判断の重みを引き受けることなんです。
判断の重み。
ねえ。
先ほどの設計でのトレードオフの決断もそうですが、最も重いのは公開の判断です。
公開の判断ですか?リリースするかどうかという?
そうです。例えば、リリース直前に致命的ではないけれど、軽微なバグが見つかったとします。
よくある胃が痛くなるシチュエーションですね。
このままスケジュール通りリリースして後から修正を当てるか、それともクライアントに頭を下げてでもリリースを延期するか。
うーん。
このビジネス上のリスク許容度を天秤にかける決断はAIには絶対にできません。
確かにそうですね。AIは一瞬で数万行の行動をかけますけど、いざバグが起きたときにスーツを着てクライアントのところに謝罪に行ったりはできないですから。
ええ、法的な責任を負うこともできません。ごめんなさい、AIがやりましたはビジネスでは通用しないんです。
つまり、責任の所在を引き受けることこそが人間ならではの最後の役割なんですね。
おっしゃる通りです。コードを直接書く作業がAIに代替されても、生成された結果がビジネス要件を満たしているか検証し、最終的なゴーサインを出す。
そして問題が起きれば責任を取る。これがAI時代のプログラマーの主戦場になっていきます。
初心者と現役プログラマーの学び方
だとすると、これを聞いているリスナーのあなたは明日からどう動けばいいのかという話になりますよね。
そうですね。実践的なアクションプランを考えてみましょう。
例えば、もし私がこれからプログラミングを学ぼうとしている初心者だとしたら、どうせAIが全部書いてくれるなら、もう面倒な基礎なんて勉強しなくていいやって思っちゃいそうなんですが。
それは最も危険な罠ですね。
罠ですか。
ええ。なぜなら、基礎的な構造を知らないと、AIが最もらしい嘘をついた時に、どこが間違っているのか原因を調べることすらできないからです。
ああ、なるほど。
外国語の文法を知らないのに、翻訳機が間違えた部分を直そうとするようなものです。
結局、変数の動きや行動の理解は必須ってことですね。じゃあ、初心者はどう学べばいいんでしょうか。
初心者の方には、1ヶ月から2ヶ月かけて、小さなアプリを1つ、自力とAIのハイブリッドで作ってみることをお勧めします。
ハイブリッドで。
はい。そして、どこをAIに任せて、どこを自分が修正したかをしっかり記録しておくんです。
記録に残すんですね。
さらに、そのアプリの処理の仕組みを自力で説明できるようになること。これが、AIを使いこなすための最強の土台になります。
なるほど。じゃあ、すでに現場でバリバリやっている現役のプログラマーはどうでしょう。無理に管理職を目指すべきなんでしょうか。
いえ、無理に管理職になる必要はありません。今の自分の担当工程から、1つ前か1つ後ろへと経験を広げることをお勧めします。
1つ前か1つ後ろ。
例えば、いつも実装を中心にやっているなら、1つ前の仕様整理の段階から首を突っ込んでみる。あるいは、1つ後ろのテストや公開後の運用結果まで追いかけてみる。
視野を広げるわけですね。
はい。そして何より重要なのは、自分がなぜその修正や判断をしたのか、理由を記録に残すことです。
AIはどう直すかは一瞬で出してくれますけど、なぜそうすべきかという理由は人間にしかわからないですからね。
その判断のログこそが、AI時代を生き抜くための強力なキャリアの防具になるんです。
残る仕事と望む働き方は別問題
これは重要な問題を提起していますね。今日のエピソードを振り返ると、ある残酷な真実が見えてきます。
残酷な真実ですか。
ええ、それはプログラマーという仕事が残ることと、あなたが続けたい仕事が残ることは全くの別問題だということです。
ああ、確かにその通りですね。
もしあなたがひたすらタイピングしてゼロからコードを作るのが好きだったのだとしたら、来る日も来る日もAIの監視やレビューばかりして責任だけを負わされる未来は本当にハッピーな働き方と言えるでしょうか。
需要があるからといって安易に飛びつくのではなく、自分はどんな働き方をしたいのかを見極める必要がありますね。
はい。リスナーの皆さんも、激変する仕事内容の中で自分の心がどんな作業に喜びを感じるのか、冷静に向き合うタイミングが来ているんだと思います。
そうですね。
さて最後に一つ、あなたに考えてみてほしいことがあります。もし近い将来、AIが人間の何倍ものスピードでコードを書き、自らバグすらも見つける世界が来たとしたら。
はい。その時もしかすると、究極のプログラミングスキルとはコンピューターとの対話ではなく、このシステムを使う人間の本当の悩みは何かを理解する心理学や人間への深い共感力に乗るのかもしれません。
人間らしさが一番の武器になるということですね。
ええ。あなたの持つその人間らしさは、AI時代のワークフローのどこで一番輝くでしょうか。ぜひ明日パソコンを開くときに少しだけ考えてみてください。
とても深い問いですね。
はい。それでは次回のディープダイブでまたお会いしましょう。
