前提

タイトルは言い切ってますが、勝手な予想です。

この記事の関心は開発組織をどうつくるか？です。
そのためのシステムがどう作られるのかを整理しています。

最初に結論

コアドメインの理解は業種によっては深く、エンジニアがキャッチアップすることが手間である。その場合、その専門家が直接AIを通して実装する世界が来る
システム的な制約は今後も存在していて、まだAIでは対応しきれない可能性が高い。低レイテンシーレスポンス、大規模なデータを取り扱うシステムをつくる必要がある場合はシステム的な特性を理解した実装は今後も必要。非機能要件的な例外ハンドリングは職人の技で成り立っており、金融や医療など堅牢性や安全性が求められるシステムはエンジニアは健全なシステムをつくる観点が必要になる
逆を言えば、特性が深くないシステムはエンジニアだけのものではなくなり、自由になる。toCの軽いシステムはエンジニアのアイデアで自由に１人で作れるかもしれないし、toBの軽いシステムは業務に詳しい使い手が欲しいものを自由につくれるかもしれない。

この記事を書こうと思った経緯

今、会社でもAI開発を絶賛推進していて、更に加速が必要だと感じています。
それ以外にも、直近で話をした人から良い問いをもらい、とても関心がある状態でした。

そこに元同僚で一緒に働いた阿川さんのこの資料である
https://speakerdeck.com/atty303/software-architecture-in-an-ai-driven-world

とても刺激を受けて、自分の考えていたことと重なることも多くありました。
(それでも、広く深く整理されていて流石だ！！って感じです）

自分は技術と組織を横断する設計がどうなるのかを考えたくなり、今の自分の結論をアウトプットしたくなり雑多にこの記事を書こうと考えました。

ドメインを中心とした開発

これまでコアドメインの実装はエンジニアがドメインエキスパートなどから必要なロジックを又聞きしながら実装をしていた部分である。

これのエンジニアは不要になる。エンジニアではなく、ドメイン整理のエキスパートが必要だ。
コアドメインはシステム的な特性が非常に低い部分である。
これはアーキテクチャの工夫によって既に確立している。

ドメイン駆動設計 (DDD)が名前的にも役割的にも近い。
システム外の観点も多くある手法のため、今回は観点が広がってしまうので、まずは実装の話をクリーンアーキテクチャで話をする。

なぜクリーンアーキテクチャで話すので良いかと言うと、基本的にこれらは阿川さんの主張と完全同意でこのアーキテクチャの用語でも十分に意図に即した説明ができるからだ。
https://speakerdeck.com/atty303/software-architecture-in-an-ai-driven-world?slide=49

そんな訳で、大事なのはドメイン、関心の分離、テスト容易性である。
次に自分が関心をもったのは、どんなスキルが必要なのか？です。
ドメイン知識、システム特性、関心の分離があるとして、これら３つを全てエンジニアにインプットしていたのです。それはコーディングの工程が必須で、めちゃくちゃ面倒なことをしてたわけです。

AIを使えば対応すべき特性に合わせて、それぞれに分離できる。
ドメインが難しいなら、ドメイン詳しい人が上手く作れるような作りのアーキテクチャにすれば良い。
それが、DDDをベースにしたAI DDDが作られるでしょう。

PaCに繋がるユビキタス言語の価値が高まり、言語や要件整理でコアドメインのロジックはAIが正しく実装してくれる。

https://speakerdeck.com/atty303/software-architecture-in-an-ai-driven-world?slide=34

しかし、必要なのはドメインだけじゃない。システム的な制約を上手くつなぎ合わせる必要があります。それをDDDやクリーンアーキテクチャはちゃんとレイヤー分けしてあるわけです。

このように分類しました。階層が違うかもしれませんが、ある意味セットになっている部分はカッコ内にまとめています。

Domain (Entities)
UseCase
Presentation (UI/Web/Devices)
Controllers (internal development API)
Gateways (external system API)
Persistence (DB、File)

これらを分類する観点で３つの観点を考えました。

a. ドメイン特性の理解の影響が大きい
b. システム特性の理解の影響が大きい
c. ドメイン理解もシステム理解も深い理解が不要な開発

これらの特性は事業単位のこともあれば、機能単位のこともあります。．

これらを担保することが必要な品質の実現になる。
前提としてPaC (Project as Code)は進んでおり、ドキュメント等の情報はAIにインプットされて生成されるものとします。

a. ドメイン特性の理解の影響が大きい

Domain
UseCase

システム特性は非常に薄く、ドメインの処理のハンドリングが重要になる。
ドメインエキスパートが対応する。

b. システム特性の理解の影響が大きい

Controllers (internal development API)
Gateways (external system API)
Persistence (DB)

システム特性が高く、メモリやCPU、ネットワークなどの挙動の理解とエラーハンドリングが必要になる。
特にDBのようなものは変更コストが非常に高く、初期に考慮すべきことが非常に多い。
今後もエンジニアが対応する。

c. ドメイン理解もシステム理解も深い理解が不要な開発

Presentation (UI/Web/Devices)

実際にはデザインスキル、体験設計の力が必要だが、システムは動かないわけではない。
デザイナーの専門スキルとも言える。深さが不要で、動くだけでいいなら自由に作れる。

コアドメインを中心にした開発で、こんな感じの開発になるのかなと想像しました。
PaC (Project as Code)とDDDの相性が非常によく、この考え方をベースに必要なスキル区分を分け、組織を設計する。

つまりAI DDDが広がる

DDDはAIに適したフレームワークだと感じています。
今後は更に最適化されたフレームワークが出てくると考えられますが、DDDは実装と組織運営が一体となったフレームワークであり、既にPaCにつかえる知識が多く定義されています。

ユビキタス言語などを使いドメインとシステムの言葉を揃え、ドメインの言葉をシステムにそのまま写し取ることが大事に考えられている。
そして、コアドメインと周辺のシステム依存するレイヤードスタイルのアーキテクチャを実現することで、ドメインのシステム特性の影響を最小限にして実装できるようにしている。それが、AI開発にピッタリの構造分解を作り出している。

Feature(機能)モジュール化された開発

１つめのアイデアであるAI DDD、もう１つのアイデアが開発が機能単位でモジュール化した開発である。

重要なのはコンテキストをなるべく分けること、そして、複雑ではないシステムは丸ごと作り直すために疎結合にしておくこと。
技術選定の戦略の１つにある、捨てやすくつくることだ。
この捨てやすい範囲がAIによってそれなりに大きな範囲を扱うことができるようになる。

ではそのコンテキスト境界で分かりやすいのが何かというと、シンプルに機能単位での開発にしようというはなしだ。
ドメインが深くないのであればDDDは過剰になる。プレゼンテーション層からDBの操作まで機能単位に必要な処理は全て作ってしまえばいい。機能単位に疎結合にすれば、AIで何度も丸ごと作り直すこともありだろう。

つまりFeature(機能)モジュール化された開発とは、機能単位に捨てやすくつくることです。
おそらく普段から最もやっている開発を厳密にしながら、システム的考え方をあまり知らない人が使っても問題ないように整えることが必要と考えます

AIでコントロール可能な条件

システム特性もドメイン特性も一般的な範囲内で収まることです。
その場合、機能単位に捨てやすくつくること、その単位で作業分担をすることが人の負荷を適切に扱える分担になる。

機能単位に取り扱うための基盤開発

まあ、普通の開発と同じで、基盤になる部分を選考して開発する必要があります。
アーキテクチャを決め、一定のルールをつくることで逸脱したシステムを産まないようにしつつ、作りやすくすることは最初に必要そうかもしれません。

これはシステムを長期的に維持する観点で最低限担保しておく必要がある部分を担うイメージです。
この土台を作る部分はエンジニアがつくる必要があると思います。

この土台をつくるには、今、事業でやりたいことを考慮するだけでなく、将来に事業でやりたいことを考慮してつくることが前提となります。
そうなった場合、現在のテックリードやEM程度のスキルは必要になると考えました。

ここまでを考えたときの組織体制

この記事で整理した話は、要はHITLの人間部分に求める特性とエージェンティックに進めた時の人間部分に求めるリソース限界の見極めの話なのだと、自分で書いていて理解した。

それを考えたとき、自分は少人数で多職種の体制の開発はあらゆる場所で起こることは想像の通りに感じた。
しかし、全てがそうなるのかと言われると、そうは思わない。

コードの生産量が数倍になっても、他のボトルネックはまだまだあるので、リソース的限界と特性的限界は存在していて、それらを上手く組織化することは必要に感じられた。

とはいえ、エンジニアがエージェントでできるレベルのシステム特性の理解しか考え出せないのであれば、そのエンジニアは不要になるのかもしれない。

つまり、テックリードやエンジニアリングマネージャの価値が大きくなる方向性は変わらない。

１人でつくるシステム

ここまでの２つの作り方は前提に大規模な開発であることだ。なぜならば、開発組織について検討を考えていたからである。
私は大きな開発組織はなくならないと考えている。どこまで行っても作りたいことはたくさんあって、１０倍作れるようになれば１０倍の作りたいものをつくるだけなのだ。
50年前に比べてCPUは1億倍早くなっており、記憶媒体は100万倍多くなっている。それでも遅いと感じることもあり、容量が足りないと感じることもある。
そういうインフラができれば、それを前提にしたやりたいことがたくさん生まれる。

大規模開発の可能性はそんな風に感じているが、それでも１人開発の可能性は広がるでしょう。
まだまだ多くの人が必要なケースがあると自分は考えているが、
事業を最速のスピードで実現するためにシステムづくりが必要なとき、１人でつくることが最速なこともある。

１人でつくるシステムが良いときはどういうものなのだろうか、ちょっとだけついでに触れてみる。

全てを１人で作るシステム

次に、コアドメインが不要のシステム開発もある。
主な目的が自動化やアイデアの検証の場合は、１人でイメージを具体化する方が早い。

全てを１人で作れる人

ドメイン特性を深く理解し、システム特性を深く理解している人。
事業もシステムの理解も深いCTOやEM、テックリードのような人は全部１人で作れる可能性がある。

そして大規模開発化するときには、このような人の需要が爆発的に増加する。
これまでの10倍の生産性を出せるのならば2-3倍の報酬を出してもお釣りが来る可能性もある。

この開発も多くなりそう。
だが、１人で開発できることの限界は変わらず存在するので、多職種体制や複業体制は加速しそうだ。

まとめ

これだけみると１人開発で今まで作られていたものがカバーされることも多くあると感じられる。
特にCTO、EM、テックリードの力は今後の生成AI開発がもっと進めば数倍以上に高まると感じる。

その中で、大きな開発をするときには今と違うエンジニアの活躍の仕方はデザインが必要になりそうだ。

ドメインを整理する役割がドメイン整理屋として別の職種として専業になることがありそうに感じる。
コンサルやSEがやっている領域だが、むしろこの領域が更に大事になる。

次に、ドメイン自体を取り扱うドメインエキスパートもシステムを作り始める。
エンジニアだけしか出来なかった実装作業に直接協力することになる。

エンジニアは本質的な意味で、何をどうつくるかがもっとハイレベルに問われることになる。
なんとなしに技術の流行に乗ってコードを書くだけでは生きていけない時代がくるだろう。

そんなエンジニアをどう再配置するのかを考えると、大きな変化がどの企業にも起きそうだ。

本質的な価値を見極め、システムの特性を本質的に理解し、それらをつなげあわせることが求められる。
実は今までの開発でも必要だったことが、もっと贅肉が削ぎ落とされた形で本当にそれができないと価値のない人になる時代が来ることになりそうだ。

AIを使いこなすために必要なのはAIに指示を出し、教育する能力だ。
自分で扱うだけでなく、人に教えるレベルでのスキル理解を常に求められる時代になる