生成AIの登場でシステム開発のやり方が大きく変わろうとしています。
こうなると、要件さえ与えればすぐにシステムが生成できる未来も、決して夢ではないのかもしれません。 こんな状況で、僕たちがこれまで大切にしてきた「設計」って、本当に意味があるのだろうかと疑問に思うのは自然な流れです。 僕自身、最近このテーマについて真剣に考え、結論としては「生成AI時代でも設計は欠かせない工程だ」と感じるようになりました。
設計工程が重要になりそうだということはここでも書いた。
エンタープライズシステム開発における直接コード生成の限界
エンタープライズシステムは、規模も大きく、複数の機能やサービスが連携するため、要件定義がどうしても抽象的になりがちです。 こんな抽象的な要件から直接コードを生成しようとすると、保守性や拡張性、何よりシステム全体の整合性を確保するのが非常に難しくなります。
現状の生成AIは、オセロやテトリスのような小さなプログラムの生成は得意です。 一方で、GitHub Copilotに巨大なソースツリーを見せても、全体構造をしっかり把握させるのは至難の業です。 現状の生成AIでは、全体の設計理念や複雑な依存関係、変更がシステム全体に与える影響など、大局的な視点でインクリメンタルな修正を加えるには限界があるように思われ、 局所的な改善はできても、システム全体のアーキテクチャを俯瞰しながら一貫性を保つ修正を自律的に実行するのは、現段階では大きな課題だと感じます。 部分的にできたとしても、全体の整合性が取れていなければ、それをシステムと呼ぶのは難しいのではないでしょうか。
設計工程の意義
設計工程は、要件定義と実装の間に位置する重要なプロセスです。 抽象的な要件を、具体的な技術仕様へと段階的に落とし込む—これが「段階的詳細化」というアプローチです。 つまり、大きな複雑性を持つシステムが、一貫性を保ちながら、徐々に具体的な形になっていくプロセスを指します。
このアプローチによる成果物は、生成AIに対して、コード生成に対するガイドラインや制約条件としても機能するはずで、 意図に沿ったシステムを作り上げる確率をあげるだけでなく、（完全ではないにせよ）出力される成果物の安定性・再現性も確保しやすくなります。
さらに、設計は生成AIによるコード生成と、僕たち人間のレビューや判断を繋ぐ架け橋としても大切です。 たとえ生成AIが要件からシステムを作るようになっても、「どんな思想・方針でシステムが作られているのか」というフィードバックを与える対象は、設計文書が中心になるでしょう。 なぜなら、細かい部分に対して個々にフィードバックを与えても、全体としての一貫性が確保しづらいためです。個々の詳細にフィードバックを与えるのではなく、より抽象度の高いレイヤにフィードバックを与え、その上で「詳細」を再生性することになるのではないでしょうか。
まとめ
生成AI技術はシステム開発の進め方に大きな変化をもたらす一方で、エンタープライズシステムのような大規模で複雑なシステムにおいては、直接要件定義からコードを生成するのは難しそうです。 設計工程は、要件定義と実装の間に立って、システム全体の整合性、保守性、拡張性を確保するためのしっかりとした枠組みを提供します。 そして、生成AIを使った「設計」という工程が、局所的な自動生成の弱点を補い、全体として一貫性を保ちながら柔軟な変更に対応できるようにするのでしょう。
結局のところ、生成AI時代になっても、設計工程はシステム開発全体の品質と信頼性を決定づける、不可欠なプロセスであるという結論に至ります。 これからも生成AI技術が進化する中で、設計プロセスの改善とその重要性は、より堅牢で柔軟なエンタープライズシステムの実現を支えるのでしょう。
ただ、「設計」というプロセスが人に露出する「程度」は、生成AIの進化によって少なくなると思っていて、 設計工程のほとんどは生成AIの中で進んでしまうことになるんでしょうね。 十分に発達した生成AI時代の設計工程は、もはや無いのと見分けがつかない。
