AI時代の「コードと人間の関係」を問い直す—デブサミ関西2026で考えた、アーキテクチャの未来とコミュニティの価値 #devsumi

デブサミ関西2026に参加してきた。
デブサミ関西2026で踊る「AIによる自動化」や「FDE」の波。一見スマートな潮流に違和感を覚えたのはなぜか？
AI時代のプログラミングの本質、ITビジネスの構造、そして20年続くコミュニティの絆から、エンジニアが手放してはならない「思考の領域」と真の資産を考えてみた。
感想をラフなメモ書き。

Developers Summit 2026 KANSAI（2026.08.21）

【1】講演者の大半は、AIで手作業のプログラミングはなくなる、価値創造にフォーカスを当てるべきだ、エンジニアもビジネスにシフトしようと言っているが、むしろ、僕は、AIが普及しても人間によるプログラミング、アーキテクチャ設計は変わらないと思う。

確かに、AIによるプログラミングの方が人間の手作業によるプログラミングよりも高速で品質も一定だ。
人間のプログラミングは、漏れが多く、考慮する範囲やレベルも一般的に低い。
しかし、そんな状況でも、AIよりも人間のプログラミングが重要な点は2つある。

1つ目は、AIのプログラミングは、無駄にたくさんの機能を作り、無駄にたくさんの仕様を盛り込みすぎて、品質基準を超過しすぎる。
人の成果物は品質基準に不足しすぎるが、AIの成果物は品質基準を超過しすぎる: プログラマの思索
AIは高速かつ品質基準もクリアできるために、無駄に作った機能がないか、変な方向に機能作り込みしていないか、人間がコードレビューしている感じだ。
つまり、人間もAIが作ったコードを読んで理解する必要があるので、プログラミング力が不要になることはない。

2つ目は、ソフトウェのあるべき姿を考える時に、人間もプログラムという肝心の部品を理解する必要があるからだ。
AIは高速かつ品質基準もクリアできるツールなので、極端に言えば、システム中身のソフトウェアもアーキテクチャも、ブラックボックスでいい。
つまり、プログラミングやアーキテクチャも知らなくても、テスト駆動開発で仕様を満たせれば、中身のソフトウェアが汚くても無関係だ。
なぜならば、AIでいつでも作り直せるならば、いくら大規模なシステムでも、プロトタイプを作る感覚で、何度でもリプレースしてしまえばいい。
アーキテクチャもプロトタイピングの都度、極論、何度でも大幅変更しても、AIで対応できてしまうからだ。
大規模システムを今日はJavaで作った、明日はC#で作り直した、明後日はRubyで作り直した、1週間後にはRustで全部作り直した、というやり方も、AIなら問題なく可能だ。
AIなら、じきに品質保証という監査プロセスそのものもAIで自動化できるだろう。

AIによるプログラミングは、20年前に流行したモデル駆動開発やノーコード開発と同じだ。
プログラミングを知らなくても、GUIの設計だけでプログラムを自動生成すればいいという考え方だ。
今でも、SalesforceやKintoneによるローコード開発も似たような発想だ。

Xユーザーのakipiiさん: 「AIでプログラミング代替により、プログラムは使い捨てになる。あるいは昔のノーコード開発になる。本当にそれがあるべき姿なのか？僕は違うと思う。 #devsumi」 / X

モデル駆動開発、ノーコード開発、ローコード開発であれば、アーキテクチャを考える必要性はない。
すでにアーキテクチャが存在している前提で、アプリ層のビジネスロジックを実装するだけ、という発想だからだ。

しかし、それが本当のソフトウェア開発なのだろうか？
ソフトウェア開発にアーキテクチャなんて無視して、ビジネス要件さえ満たしていれば、中身はブラックボックスでよくて、QAなんか無関係で、ソフトウェア工学も品質保証も無関係でいいのだろうか？

僕は違うと思う。
AIがこれだけ高速かつ高い能力を持ったとしても、ソフトウェアのあるべき姿を思考する行為そのものは自分の範疇に納めたい。
AIが本当に良いソフトエアを作ってくれるのか、その仕組は理解したい。
AI自体の思考プロセスを理解したい。
アーキテクチャを自分が指定して、AIに指示させたい。

上記の理由は中途半端だけど、思考プロセスそのものをAIに手渡したくないのだ。

【2】FDE（Forward Deployed Engineer）はパランティアのエンジニアのモデルから生まれたらしい。
FDEは、ソフトウェア派遣委託のSESと同じだと思う。

Xユーザーのakipiiさん: 「#devsumi FDE（Forward Deployed Engineer）はパランティアテクノロジーズのビジネスモデルから生まれた、とスピーカーから聞いた。それなら理解しやすい。」 / X

FDE（Forward Deployed Engineer：前線配備エンジニア）とは、顧客企業の現場（最前線）に直接入り込み、自社プロダクトやAI技術を用いて、課題の発見からシステムの迅速な実装・運用改善までを一気通貫で担う職種だ。
確かに、従来のSEのように、顧客先に常駐して、顧客の要望に従って、WF型開発に沿って受託開発するわけではない。

しかし、外側から見れば、客先に常駐して、顧客の要望を収集したうえでプログラミングしてシステム開発スタイルは変わらない。
従来のSESであれば、顧客から指定されたアーキテクチャやWF型開発プロセスに従ってプログラミングするだろう。
一方、FDEは、自社のフレームワーク、特にパランティアのようなオントロジーのフレームワークの上でシステム開発して高速に開発サイクルを回し、顧客に確認しながらシステムを順次提供していくだけだ。
つまり、SESとFDEの違いは、ソフトウェア開発の基盤が違うだけで、ビジネスモデルは全く同じだと思う。

せいぜい、SESは準委任契約だろうが、FEDは成果連動の契約つまり請負契約に近い契約なので、その点は違うだろう。

【3】では、僕がなぜ、FDEはSESみたいだね、ビジネスモデルも契約形態もそんなに変わらないと思う理由は何なのか？
理由は、マッキンゼー、デロイト、アクセンチュアなどの大手ITコンサルタントであっても、彼らも客先常駐ないし客先と準委任契約中心の高級派遣業であって、SESの契約形態と本質的に変わらないと思うためだ。

SESはWF型開発従った受託開発のビジネスモデルだ。
いわゆる人月ビジネスであり、従来から凄く批判されている。

一方、アクセンチュアのようなITコンサルタントも、SESから高級派遣業にアップグレードしたに過ぎない。
どれだけのコンサル人数を入れて、売上を増やしていくか、というビジネスモデルだ。

FDEも客先常駐のスタイルは変わらない。
ただし、客先指定のオレオレ開発基盤の受託開発から、AIによる自社オントロジー開発基盤の受託開発に変わっただけだから。

【4】デブサミ関西に久しぶりに出たら、10年以上前に関西アジャイル開発コミュニティで一緒に活動していた仲間からたくさん声掛けしてもらって、まるでOB会みたいな感情が沸き起こった。
以前の会社の職場にいた同僚や上司も昇進していたし、その他の仲間も職場を変えても皆活発に活動されていた。

年数が経っても、昔は一緒に苦労したね、昔も楽しかったね、今も一緒にやろう、みたいに言える雰囲気があるのは楽しい。

会社に所属する期間は所詮65歳定年までであって、会社から離れると、守秘義務などもあるので基本的に関係はなくなる。
しかし、コミュニティ活動で一緒に苦労し何かを達成した仲間は、いくら転職しても、フリーランスで働いても、無職になっても、長年一緒に経験した人間関係は一生残る。

プライベートな人間関係につながるからこそ、ビジネスを超えた環境であっても、その人の人柄や能力、人格が優れていれば、自然に人は集まる。
人間関係は細く長く続けることで、その偉大さを20年後に初めて感じるわけだ。

今後も色々やっていきたいと思う。