コードを書く「コーダー」は、当然、完全に消える。だが本章の主題はその先だ ── 設計までする「ソフトウェアエンジニア」の仕事も、AI がするようになる。
1-02で、保守も開発も AI と対話する作業に変わることを見た。本章はその裏面 ── 役割の側 ── を扱う。言っているのは「プログラマー全員が消える」ではなく、「コーダーとソフトウェアエンジニアという役割定義が消える」だ。この区別が本章の半分である。
コーダーとソフトウェアエンジニア
本書では、二つの役割を区別する。
- コーダー ── コードを書くこと自体が仕事の中心。要件も設計も別の人から降りてくる。評価軸は「速く、正しく、読みやすく書く」。
- ソフトウェアエンジニア(SE) ── 設計まで踏み込む。何をどう作るかの構造を自分で決め、そのうえでコードを書く。コーダーより広い。
どちらも、具体的な人ではなく 役割の定義だ。同じ人がある場面ではコーダー、別の場面では SE として働くことは普通にある。消えるのは、人ではなく役割の方だ。
これらの役割が成立してきたのは、人間がコードを書き、設計するのに時間がかかったからだ。一つのシステムを形にするだけで膨大な工数が要り、書く人手も設計する人手も揃える必要があった。SIer・受託開発・元請け下請け構造は、すべてこの前提の上に建っている(3-03で扱う)。
AI が、コーダーにもソフトウェアエンジニアにもなる
1-01で、AI が最強の SIer になった ── コードを書き、文脈を理解して設計もする ── という事実を据えた。能力には幅がある:
- Opus ── 一流の コーダー。意図を渡せば、動くコードに翻訳する
- Fable / Mythos ── ソフトウェアエンジニア。文脈を理解して設計まで踏み込み、構造を自分で決められる
つまり AI は、コーダーの仕事も、ソフトウェアエンジニアの仕事もする。コードを書くだけのコーダーは、当然消える。だが、設計までする SE も同じだ ── 設計もコードも AI がやるなら、人間が「自分で設計してコードを書く」役割で立つ場所は、なくなる。設計とコードの帯の市場価値は、ほぼゼロに収束する ── 労働観ではなく、価格の話だ。
人間に残るのは、AI と対話する仕事 ── それはもう SE ではない
では、人間に何が残るのか。設計でもコーディングでもない ── AI と対話して、システムを作り・動かす仕事だ。
- 何を作るかを決める ── 文脈は、人間が持っている
- ハードを調達する(物理の世界)
- 関係者と協議する(社会の世界)
- 動かし、直し続ける(運用・保守)
- 方向を決め、責任を取る
AI は文脈を 与えられれば 処理し、設計もする。だが、何を文脈に含め、現実と何をすり合わせるか を決め、責任を取るのは人間だ ── その主体は、現状の制度では AI ではない。これは、自分で設計しコードを書く「ソフトウェアエンジニアの仕事」ではない。AI と対話して形にする ── これは別の役割だ。1-04で「ビルダー」と呼ぶ。
人間に残るのは、設計でもコーディングでもない。 AI と対話して、システムを作り・動かす仕事 ── それはもうソフトウェアエンジニアではなく、ビルダーだ。
消えるのは「自分で設計し、コードを書く役割」だ
だから消えるのは、「自分で設計し、コードを書く役割(コーダーとソフトウェアエンジニア)」と、SIer がそれを量産するために組んだ 役割分業だ。需要が消えるのではなく、設計もコードも AI に置き換わって価格が立たなくなる。一人が AI と対話してシステムを作り・動かす ── その役割(1-04で「ビルダー」と呼ぶ)に移る。
(何を作るか・ハード調達
関係者協議・運用・責任)"] A["AI
(コード=Opus
設計=Fable/Mythos)"] H <-->|対話・相互理解| A end Old ==>|分業が解ける| New classDef good fill:#e8f5e9,stroke:#7a9a6d,color:#3a4d34 classDef bad fill:#fef3e7,stroke:#c89559,color:#5a3f1a class New good class Old bad
二つの図で、顧客は同じ場所にいる。違うのは、かつて SIer に発注するだけだった顧客が、いまは自分で作り・動かす側に立つことだ。かつては発注するだけでも、RFP 作成・業者選定・要件すり合わせ・契約交渉と相当の手間がかかった。設計までする AI(Fable / Mythos)の水準では、その「発注する手間」があれば、顧客自身が作り上げてしまう(1-05で扱う)。
かつては、SIer に発注するだけでも相当の手間がかかった。いまは、その手間があれば ── 顧客自身が作ってしまう。
これは「すべてのプログラマーが失業する」ではない。呼ばれてきた人々は二つに分かれる:
- (a) ソフトウェア開発から離れる ── 別の業界・別の役割へ
- (b) ビルダーに移る ── AI と対話してシステムを作り・動かす側に立つ(1-04で定義)
逆に、ビルダーになるのはプログラマーだけではない。現場の人 ── 業務や顧客を実際に知っている人 ── も、ビルダーになれる。ビルダーに要るのは、コードを書く力ではなく、現場の文脈を掴み、AI と対話して形にする力だからだ。むしろ、文脈を手元に持っている現場の人のほうがビルダーに近い(1-05で「顧客自身が作る」として詳しく扱う)。
歴史も同じだ。日本では 1970 年代、電卓が算盤による商業計算の技能を消したが、数字の意味を読み業務を回せる人は経理・会計に残った。欧米の 計算手(human computer)、活版から写植への組版工も同じ。 手作業が機械に置き換わると、より広い側(段取り・対話・運用・責任)に移れる人と移れない人で分かれる。同じことが、ソフトウェア開発 ── コーディングも設計も ── で起きている。
注意したいのはスピードだ。電卓は Casio Mini(1972 年、¥12,800) など低価格機種が出てから、およそ十年でそろばんをオフィスと家庭から押し出した。「この種の変化は数十年かかる」という直感は、振り返るとゆっくりに見えるだけで、渦中の当事者には速い。今回の AI 化は価格が桁違いに低い段階で始まっている(1-01)。同じか、それ以上の速度で進むと見るのが妥当だ。耐えられるかどうかは個人の選択ではなく、業界構造 の問題になる(3-06)。
次の章へ
設計もコードも AI が担う一方、何を作るか・ハード・人・運用・対話・責任は人間に残る ── この役割を、誰が担うのか。そしてその役割の 基盤となる学問が、ソフトウェア工学からリベラルアーツへ移る ── これが本サブシリーズの通奏低音だ。次章で、その役割 ── ビルダー ── を定義する。