blog.unresolved.xyzblog.unresolved.xyz

LLM時代におけるソフトウェア開発について思うこと

Sat Feb 14 2026
  • AI
  • poem

LLM(大規模言語モデル)がソフトウェア開発の現場に浸透してきて、「開発がつまらなくなった」という声を耳にすることがあります。本当にそうなのか、自分なりの考えをまとめてみたいと思います。

Table of contents

LLMはソフトウェア開発をつまらなくしたのか?

「つまらなくなった」と感じる人と、そうでない人それぞれがいると思います。

そして、僕はむしろソフトウェア開発が非常に楽しくなった、と感じる側です。

過程を目的にする人と、目的のための手段として捉える人

エンジニアリングの楽しみ方には、大きく分けて二通りあるのではないでしょうか。

一つは、過程そのものを目的にしている人です。コードを書くこと、デバッグで原因を突き止めること、設計を考えること、そういった行為そのものが楽しい。手を動かして、頭を使って、何かが形になっていくプロセスに没入する喜びがある。

もう一つは、目的のための手段として捉えている人です。プロダクトを作る、問題を解決する、価値を届けることが目的で、コードを書くのはそのための手段。早く正確に届けられれば、手段は何でもよい。

LLMは後者にとっては強力なツールです。やりたいことの実現が早くなるし、ボイラープレートや定型的な処理は任せられる。一方で前者にとっては、「自分がやりたかったこと」をAIに任せる形になり、達成感や没入感がほとんどなくなってしまうというのは想像に難くないと思います。

以前書いた「労働と仕事」の話にも通じる部分があると思います。働くことがそれ自体を目的とした純粋な行為であってほしい、という気持ちを持っている人にとっては、LLM時代の開発は少し物足りなく感じるのかもしれません。

これからも価値のあるソフトウェアエンジニアであるために

LLM時代において価値のあるソフトウェアエンジニアであるためには何が重要なのかを考える機会も増えました。

改めて言うまでもなく、コードを書く量ではなく、何を作るか・なぜ作るかを決める力がより重要になると思います。つまり、指示を出す側になることです。

文脈の理解、要件の言語化、優先順位づけ。技術的負債をどう扱うか、アーキテクチャをどう設計するか。こういった判断は、AIに丸投げしにくい領域です。ここで適切な判断ができるかどうかが、これからのエンジニアの価値に直結するのではないでしょうか。

ソフトウェアは一度作るとサービス終了までメンテナンスコストが伴います。人員が採用しづらいテックスタックを採用してしまっていれば採用のコストもあがりますし、ドメインの複雑度の許容量を見誤れば人間の認知負荷やバグの発生率に影響します。

これらは一般的にはテックリードなどのポジションの人が「最終的に自分で責任を取れる」という前提で意思決定してきた領域なのではないかと考えています。

これらを考えていた結果、僕は最近「ソフトウェアエンジニア」という言葉より「ビジネスパーソン」という言葉を使うことが多くなりました。

指示を出す先という観点でのAIと人間の差異

ほんの数ヶ月前までは、AIと人間それぞれに指示を出す際の違いとして、「AIには明確に指示しなければならず、人間には曖昧な指示が許容される」というふうに考えていたことがありました。

しかし最近はほとんどこれが気にならないほどにLLMが進化してきたと感じます。

「作業の成果」という観点で今まだ残っている差異があるとすれば、人間へ指示を出した場合は稀に期待した成果を超えてくることがある、という点でしょうか。

しかしこれも、AIが近いうちに実現可能になるでしょうし、指示者の能力にも影響する指標であるため、AIという文脈だけで論じるのは難しいと思っています。

それでも、何を作りたいか、何が欲しいかを言語化する力は、AIに限らず人間にも指示を出す際に重要なので、これからも価値が下がることはないと思います。

まとめ

LLMがソフトウェア開発をつまらなくしたかどうかは、エンジニアリングの楽しみ方の違いによる部分が大きいと思います。過程そのものを目的にしている人にとっては、確かに物足りなく感じることもあるかもしれません。

一方で、これからは「指示を出す」「何を作るか決める」力がより重要になります。そのための訓練として、言語化する力、要件を定義する力、Issue を書く力が、これまで以上に価値を持つ時代になってきているのではないかと思います。