コードを書くコーダーという役割は、当然、立たなくなる。だがこの章の主題はその先だ。設計までするソフトウェアエンジニアの仕事も、AI がするようになる。
1-02 で、保守も開発も AI と対話する作業に変わることを見た。この章は、その裏面を扱う。役割の側の話だ。言っているのは「プログラマー全員が消える」ではない。「コーダーとソフトウェアエンジニアという役割定義が消える」だ。この区別が、この章の半分である。
コーダーとソフトウェアエンジニアは、別の役割だ
この連載では、二つの役割を区別する。
- コーダー ── コードを書くこと自体が仕事の中心。要件も設計も、別の人から降りてくる。評価軸は「速く、正しく、読みやすく書く」。
- ソフトウェアエンジニア(SE)── 設計まで踏み込む。何をどう作るかの構造を自分で決め、そのうえでコードを書く。コーダーより広い。
どちらも、具体的な人ではなく、役割の定義だ。同じ人が、ある場面ではコーダー、別の場面では SE として働くことは普通にある。消えるのは、人ではなく役割の方だ。
これらの役割が成立してきたのは、人間がコードを書き、設計するのに時間がかかったからだ。一つのシステムを形にするだけで膨大な工数が要り、書く人手も設計する人手も揃える必要があった。SIer、受託開発、元請け下請け構造は、すべてこの前提の上に建っている(3-04 で扱う)。
AI は、コーダーの仕事もソフトウェアエンジニアの仕事もする
1-01 で、AI が最強の SIer になったという事実を据えた。二つの能力が、同時に最上層に達したという事実だ。
- コードを書く力 ── 意図を渡せば、動くコードに翻訳する
- 構造を決める力 ── 文脈を理解し、設計まで踏み込んで、何をどう作るかを決める
この二つは、別々の AI が分担しているのではない。1-01 で見たとおり、攻撃・設計・検証と同じく、一つの力の別の顔だ。だから一つの AI が、コーダーの仕事もソフトウェアエンジニアの仕事もする。
コードを書くだけのコーダーは、当然消える。だが、設計までする SE も同じだ。設計もコードも AI がやるなら、人間が「自分で設計してコードを書く」役割で立つ場所は、なくなる。設計とコードの帯には、もう価格が立たない。労働観の話ではない。価格の話だ。
人間に残るのは、AI と対話する仕事だ
では、人間に何が残るのか。設計でもコーディングでもない。AI と対話して、システムを作り、動かす仕事だ。
- 何を作るかを決める ── 文脈は、人間が持っている
- ハードを調達する(物理の世界)
- 関係者と協議する(社会の世界)
- 動かし、直し続ける(運用・保守)
- 方向を決め、責任を取る
AI は、文脈を与えられれば処理し、設計もする。だが、何を文脈に含め、現実と何をすり合わせるかを決めるのは人間だ。責任を取るのも人間だ。その主体は、現状の制度では AI ではない。これは、自分で設計しコードを書く「ソフトウェアエンジニアの仕事」ではない。AI と対話して形にする、別の役割だ。1-04 で「ビルダー」と呼ぶ。
人間に残るのは、設計でもコーディングでもない。 AI と対話して、システムを作り、動かす仕事だ。それはもうソフトウェアエンジニアではなく、ビルダーである。
自分で設計しコードを書く役割は、ビルダーに移る
だから退くのは、自分で設計しコードを書く役割 ── コーダーとソフトウェアエンジニア ── と、SIer がそれを量産するために組んだ役割分業だ。需要が減るのではない。設計もコードも AI に置き換わって、価格が立たなくなる。一人が AI と対話して、システムを作り、動かす。その役割に移る。1-04 で「ビルダー」と呼ぶ役割だ。
(計画と仕様・ハード調達
関係者協議・運用・責任)"] A["AI
(コードを書く力
構造を決める力)"] 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 を相手にするなら、その発注する手間があれば、顧客自身が作り上げてしまう(1-05 で扱う)。
かつては、SIer に発注するだけでも相当の手間がかかった。いまは、その手間があれば、顧客自身が作ってしまう。
これは「すべてのプログラマーが失業する」ではない。プログラマーと呼ばれてきた人々は、二つに分かれる。
- (a) ソフトウェア開発から離れる ── 別の業界、別の役割へ
- (b) ビルダーに移る ── AI と対話してシステムを作り、動かす側に立つ (1-04 で定義する)
逆に、ビルダーになるのはプログラマーだけではない。現場の人 ── 業務や顧客を実際に知っている人 ── も、ビルダーになれる。ビルダーに要るのは、コードを書く力ではないからだ。現場の文脈を掴み、AI と対話して形にする力である。むしろ、文脈を手元に持っている現場の人のほうが、ビルダーに近い(1-05 で「顧客自身が作る」として詳しく扱う)。
歴史にも同じ形がある。日本では、算盤による商業計算の技能が、計算機の側に移った。だが、数字の意味を読み、業務を回せる人は経理・会計に残った。欧米の計算手(human computer)も、活版から写植に移ったときの組版工も同じだ。手作業が機械に置き換わると、より広い側 ── 段取り、対話、運用、責任 ── に移れる人と移れない人で分かれる。同じことが、ソフトウェア開発で起きている。コーディングも設計も、まとめてだ。
注意したいのは、安い道具が入るときの速さだ。カシオミニは 1972 年 8 月に 12,800 円で出た。従来機種の三分の一を下回る値で、*発売から 10 か月で 100 万台*売れた(カシオ計算機の社史、情報処理学会コンピュータ博物館)。そろばんの側も動いている。播州そろばんの生産は 1960 年の 360 万丁が頂で、いまは年に約 15 万丁 ── 頂の二十四分の一ほどだ。それでも全国の約 7 割を占める (小野市「小野市の地場産業」)。
この数字が言っているのは「何年で入れ替わったか」ではない。*安い道具は、出たら一気に入る*ということだ。入れ替わりそのものは、そこから長く続く。今回の AI 化は、その「安い道具」の段階から始まっている(1-01)。入るのは、同じように速い。耐えられるかどうかは個人の選択ではなく、業界構造の問題になる(3-07)。
まとめ
設計もコードも AI が担う。一方、何を作るか、ハード、人、運用、対話、責任は人間に残る。この役割を、誰が担うのか。
そして、その役割の基盤となる学問は、ソフトウェア工学からリベラルアーツへ移る。これが、この連載の通奏低音だ。
次の章で、その役割 ── ビルダー ── を定義する。