1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AIでのプログラム生成と私たちのこれから

1
Last updated at Posted at 2026-02-19

生成AI・LLMはとても便利ですね。

質問を投げかけると丁寧に回答してくれますし、初歩的なことから聞けるので専門分野から少し外れた技術にも心を砕くことなく進められるようになりました。1

納得いくまで何度でも質問できる。
具体的なコードを題材に理解を深められる。
すべてを作り直しても、深夜でも働いてくれる。

世間ではソフトウェアエンジニアの仕事がなくなるのではないかという心配や、マネージメント層からは遠慮せずに大量の仕事を進めるパートナーとして重宝され、スピード感が出せて楽しいという言葉を耳にします。

私はそれぞれの意見に強く共感します。

image0218.png

非エンジニアとエンジニアでの成果にはまだまだ差がある

生成AIのおかげでキータイプの数は格段に減っていますが、生成AIの現在地としてはまだエンジニア不要論は尚早と感じています。

雑に依頼したものは、雑にしか出来ておらず、要件に適合しない箇所がいくつも発生し、そして軌道修正が難しいコードになる傾向があります。

乱雑なコードとならないようにするには、要件に最適な構成や技術スタックをAIと相談しながら選定し、AIと人間の双方がひとつひとつ咀嚼し、歩幅を合わせながら進めることが重要だと感じています。

レールとガードレール

4de1accb-9ce4-4e8b-bdc7-7e6a66aa19f5.png

AIと会話を適切な状態で成り立たせ、ときに指摘し軌道修正をかけるには過去にプログラムコードを書いてきた経験や知識が活きてきます。

精度向上には技術スタックを絞ったり制約をかけることでゴールまでのレールやガードレールを整備することとなり開発はスムーズとなります。

これは他のエンジニアとチームで仕事するときにも言えることですね。

Vanilla JavaScriptよりReact、Vanilla CSSよりTailwind CSS

技術スタックを指定せずに開発を依頼した際に、生成AIはSPAのようなアプリケーションでもVanilla JavaScriptでライブラリやフレームワークを使用せず実装することがあります。
これは必ずしも害なわけでもないですし、簡易な実装であれば依存ライブラリをなるべく用いず(なんならビルドツールすらも導入せず)というのが正解の場合もあるでしょう。

しかし、一定のボリュームを超えると、どのように値を伝播しているか、どのようなルールでファイルを分割しているか、共通の取り決めや枠組みがない状態で、AIが生成したコードを読み取って、懸念があればフィードバックするのは骨の折れる作業となります。

ここでReactやVue.jsなどの指定を予めしておけば、ファイルの分割ルールや記述のお作法などが明瞭となり、読み解くのが容易になります。

また、CSSもTailwind CSSを用いることで、修正を重ねるごとにスタイルの影響箇所や衝突への心配、すでに参照されなくなったコードの除去を不安な気持ちで進めることを回避できます。

相性の良いプログラム言語

レールやガードレールの整備で期待との齟齬を回避できる。これはプログラミング言語の選択においても言えます。JavaScriptより型情報のしっかりとしたTypeScriptのほうが良いでしょう。
PHPより、やはりTypeScriptのほうが修正のラリーが少なく、思った通りのコードになるまでの手数が少なく済む傾向にあります。2

テストコードやLintも良いガードレールとお互いの仕様理解につながります。

業務内容の変化

ソフトウェアエンジニアおよびその他のホワイトカラー職の仕事がなくなるというのは、その業務内容の一部のみを指し示すのであれば正しいかもしれません。

「採用するアーキテクチャや技術選定、サーバー構成、運用ルールと要件が明瞭になったプロジェクトにおいて、切り出されたタスクを元にコードをコミットする」という業務はほとんどなくなるでしょう。3

しかし、顧客の課題をヒアリングし、抽象的にモデル化しつつ具体的なコードに落とし込むためのコミュニケーション能力を対人と対AIの両輪で身につけるのは一朝一夕には身につきません。
生成AIの書くコードの品質がどれだけ上がったとしても、アーキテクチャやソフトウェアの原理原則への理解がなければ、その場に応じたトレードオフとなる判断を適切に行えず、顧客への説明や運用フローにのせることもままならないでしょう。

これからは実際のコードをタイピングする時間が削減された分、AIと協業しながら新しい知識の習得や理解を促進するというのが業務の中心となります。

中長期的には業務負荷は格段に上がる

オンライン会議が普及したことで業務時間から移動に使う時間が格段に減りました。
同様に生成AIによってCRUD(Create Read Update Delete)やETL(Extract Transform Load)、一般の業務領域における開発やプログラム言語の文法にそってプログラムコードをタイピングする仕事を取り上げられようとしています。

こうなると『明瞭になった作業は私(AI)が進めておくので、あなたは中核の業務領域の特定や矛盾するステークホルダーからのさまざまな要求を整理して下さい。』と背中を押されることになるのです。

人間にはもう単純なCRUDやETL、グラフィックデザインツールで作成された画面をコードに落とし込む作業はあまり残されません。

何をどう進めるべきか混乱する事象、単純な一つの解とならない課題、心をかき乱す仕事(相手の期待しない報告、謝罪、要望の取捨選択と説明責任)などに人間は取り組むことが求められます。

人員の要求レベルも格段に上がる

career.png

時代に応じた組織の変化と共に歩む仲間の招待状』で “今のステージがどこであれ、少なくとも近い未来でステージ後期のキャリアや働き方を意識している人、その道程を歩む覚悟のある人を求めています。” と書きましたが、おそらく業界全体でこの流れは避けられないでしょう。

「それってただのCRUDでしょ?」

10年以上前に言われた言葉です。当時から熟練したエンジニアはドメイン駆動設計に精通しており、ただのCRUDやETLに価値がないものと扱っていました。
一方で、多くのWebアプリケーションフレームワークが付属のCLIツールでデータベースに対応するCRUDの骨子を自動生成できましたが、完成に近づける作業はどうしても人力が必要でした。

一般の業務領域や補完の業務領域であったとしても、単価の低い人員で成り立つにしろ、必要な仕事として存在していました。しかし、これからはそれらを生成AIが代替するため、状況は一変するでしょう。

生成AIの進化により、ソフトウェア開発には特別な専門知識は不要になるという意見もありますが、これはおそらく逆です。
生成AIと会話のプロトコルを合わせるには知識や経験、さらには数学への理解や工学的知識が重要となります。

私はどうなのか

私自身の現在地としてどうなのかというと、このままでは立ち行かないという危機感や不安が多くあります。
ZEN大学で2度目の大学生になって1年が経った』の内容には非常に共感できました。
私も今、何かを深く学ぼうとした場合、根本的なところから理解しようとしたときに理数の壁をとても感じるようになりました。

生成AIの助けによって業務時間の密度が向上し残業時間は減ったため、それらを前述した “AIと協業しながら新しい知識の習得や理解を促進する” ための時間へ転換しています。

まずは高校数学の復習を進めています。
学び直す中で、因数分解して共通因数を出したり、複雑な式を簡易化したり、公式化して当てはめたりしていく様は、まさに日々の業務で行う課題解決のための抽象化やDB設計、プログラム作成との類似性を痛感します。

ソフトウェア開発、ひいてはホワイトカラー職全般において仕事は抽象と具体を行ったり来たりしながら進めるものです。なぜ抽象化が役立つのかが簡潔で読みやすいボリュームに記載された本です。
ソフトウェアエンジニアはあまり意識せずともこの抽象と具体を使い分けますが、改めて言語化されたものを捉えることで、なぜ人によっては話が噛み合わないか、どういう認識の違いが起きているかイメージしやすくなりました。
上記の本は『おい、つなげろ』の記事の中での紹介で知りました。

アーキテクチャへの理解やプログラムの定石、ソフトウェア工学の原則を知るとAIとの共通言語として利用できるようになります。
これらはチームの他の人間に対してコードレビューする際にも役立ちますし、AIへ的確な指示出しを行う場合にも役立ちます。
『クリーンコードクックブック』の中で幾度となく出てくる現実世界の事物とソフトウェア内のオブジェクトの間にある全単射の関係は前述の数学や具体と抽象の話とやはり地続きになります。

この記事中に用いている、中核の業務領域・一般の業務領域・補完の業務領域という言葉は『ドメイン駆動設計をはじめよう』の言葉の定義を利用させて頂きました。

ドメイン駆動設計という概念をコードとして具体化する工程がとてもわかり易く記載されています。
この記事の中で “テストコードやLintも良いガードレールとお互いの仕様理解につながります。” と記載しましたが、『つくりながら学ぶ! ドメイン駆動設計 実践入門』ではオニオンアーキテクチャの依存方向の制約を具体的なESLintの設定に落とし込んだコードやビジネスルールをテストコードとして定義する手法が紹介されています。

この記事の前半に記載したとおり、言語の特性的にTypeScriptは生成AIと相性の良い選択肢となります。
一方でJavaScriptのスーパーセットであるがゆえの落とし穴、型や型演算はJavaScriptの生成時に消去されるという特性は時に混乱を招きます。

何が起きているか、どうするべきかが様々なパターンの解説を通して学ぶことによって、生成AIとの会話の精度向上が期待できます。

私たちはどうあるべきか

これからの時代どうあるべきか、毎日のように考えますが、約2年前に記載した内容から現時点での結論も変わっていません。

時代の変化はこれまで以上に急速になり、指数関数的に我々の取り巻く状況は変化するでしょう。

我々の仕事は社会のニーズと合致しなければ、価値を提供できなければ持続できません。

本質的な課題は何か、どうすれば受け入れられるか、どう振る舞うべきか、これらは終わりのない探求となります。

これもまた、私はプロジェクト進行と同じく物語として捉えています。

完全な答えが出ないこの旅路を、困難も乗り越え、自身の成長と顧客貢献への冒険の物語を、一緒に歩む仲間を探しています。

混沌としており、一方で楽しくもある今の時代を一緒に歩む仲間を探しております。
ご興味のある方はコーポレートサイトまたはWantedlyからご応募ください。

関連記事

よろしければこちらもどうぞ。

  1. 若い頃は質問を投げる相手がおらず、誰か、どうにか助けてほしい、ベストプラクティスを教えてほしいという苦悩を過去幾度となく味わいました。試行錯誤しながら自信が持てないまま取り組んでいたときと比較するとAIは孤独を埋めつつ頼れるパートナーです。

  2. PHPであってもPHPStanを導入したり、Symfonyのような重厚なフレームワークを導入するとまた状況は異なりそうです。

  3. 正確には生成AIを用いて人が時間をかけずにつくるという作業となりますが、タスクを切り出す側の人間からすると人に作業を振るコストより自身が生成AIを用いてつくるコストのほうが下回ります。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?