デジタルサービス開発におけるAI駆動開発の現在地と未来
このNoteでデザインとエンジニアリングの融合には何が必要かを記載したが、今回はデジタルサービス開発における生成AIのインパクト、もしくはデザインとエンジニアリングの融合からみたAI駆動開発の現在地について、当社の取り組みも含めて整理してみた。
フロントエンド開発とAI駆動の現在地
figma MCPとデザインシステムの取り組みは最近多く見られるようになってきた。当社でもデザインシステム構築と運用の相談は増えてきている。これらに共通しているのは、以前とフロントエンド開発のあり方は大きく変わろうとしているということだ。UIデザイン領域におけるfigmaは圧倒的な地位を有していて、Adobeが買収をしたかった理由もよくわかる。
一方でフロントエンド開発の最近の潮流と言えば、デザインシステムのようにDesign Tokenやコンポーネントが定義されていれば、figmaデザインからコードを生成するのではなく、もはやコードからUIデザインを設計した方が早いんじゃないだろうか？という流れだ。いずれにせよ生成AIの進化により、UIデザインという仕事、そしてプログラミングという仕事は大きく変わろうとしているようにも見える。
当社でもCursorを標準的に配布して多くのプロジェクトで活用しているが、現在の生成AI(LLM)の進化は目覚ましいもののまだ万能ではなく、AIがそもそも得意な領域と不得手な領域も見えてきた。
不得意な領域としては、残念ながらプレゼンテーション側のフロント側での生成AIの適用だ。生成AIを用いたコーディングではバックエンドの方が向いている。スペック駆動開発も取り入れる中でGithub Spec Kitの適用などもしているが、現段階でみている限りでは、やはりバックエンド側の開発で効果を発揮しやすい。
フロントエンドの領域ではfigmaからソースコードに出すところはDesign Token等をちゃんと使えている場合にはある程度は対応可能だが、画面の再現だけではなく、アプリケーションの構築の場合にはどうステータスを維持し継承するか、APIをどう分割するか、など考慮すべきポイントは多い。これらについても社内で複数人でプロジェクトを担当する場合には、ある種、無邪気にソースコードを吐き出してくるLLMに対してCursor Rulesをブラッシュアップすることによって、分割統治の適用等も含めて進めているものの、まだまだ改善の余地は大きい。
AI駆動開発が効果を発揮しづらい現実世界
AI駆動開発ならびに生成AIをシステム開発の領域において適用したい大きな目的は、開発全体のスピードアップ、もしくは生産性向上のはずだが、プロジェクトによってはフロント開発は当社のようなモダンスタックな会社、バックエンドを従来型のSIerの棲み分けされることも多い。
この場合には結合テストの際になんらかの想定外等が少なからず発生して、プロジェクト全体では生成AIを開発に取り入れたとしてもシステム開発の劇的な効率化が図りづらい。
皮肉なことに、スペック駆動開発やAI駆動開発の効果を出しやすいバックエンド側の開発を担当するSIerが生成AIを活用できていないケースが多いので、効果を十分に発揮しきれない。フロント開発側だけが生成AIをフル活用したとしても効果が上がりづらいのが実態というところだろうか。
なのでやるとしたら、プロジェクト全体をAI駆動開発にしないと効果が出づらい。しかも生成AIの適用もコーディングといった製造工程だけでなく、要求整理、要件定義、設計といった前工程から活用したほうがいい。
とはいっても具体的にどうすればいいか、またある程度の大規模なシステム開発のエリアでもより適用できるようにするにはどうするかが問題になる。
最近の我々の研究では、デジタルサービス開発領域で、それなりの大規模システムで以下のようにAI駆動開発を適用するとデジタルサービス開発の仕方も大きく変えられるのではないかと考えている。
i3DESIGN - AI駆動開発プロセス
自社のノウハウを曝け出すようで何だが、現在、我々が取り組んでいるアプローチでいくと、RDRA(リレーションシップ駆動要件分析)-ドメイン駆動開発(DDD）-OOUI（オブジェクト指向ユーザーインターフェース）の開発手法をLLMを活用して解像度を上げ、そして高密度で回転させることによって品質も担保できるのではないかと幾つかのプロジェクトで実践投入している。
もうちょっとだけ具体的に説明すると以下のように事をやっている。
ビジネス要件、システム要件、サービス要件を決める要求整理の段階は、RDRA(リレーションシップ駆動要件分析)の手法を使ってのユースケースとステートの把握し全体像の解像度を上げる。
その後ドメイン駆動開発(DDD)のドメイン分割とOOUI（オブジェクト指向ユーザーインターフェース）を接続することで、エンジニアはシステムの要求整理の複雑度をある程度の網羅性をもって把握でき、かつこれをドメイン駆動に落としやすくなり、デザイナーともユビキタス言語で会話ができるようにする。
RDRAで検討するユースケースならびに、ステートと、DDDでのドメインの情報をもとにUIデザイナーはユーザーの利用ケース、対象となる画面のオブジェクトを分解しやすくなる。結果、OOUIでの画面設計が可能になり、UX設計とUIデザインがやりやすくなる。
ドメイン駆動ならびにRDRAでのユースケースとはもちろん以前よりあった手法等だが、LLMの進化が、これらの複雑度を効率的に整理することができ、かつこれをプロジェクト内において高速回転させることで、作るべきシステムの解像度をより上げることができLLMの問題点も回避できる。
LLMを使ってRDRA-DDD-OOUIを一本の線で結び、かつこれをクラウドネイティブな環境で実装することで、ある程度大規模なシステム開発プロジェクトにおいてもシステムとしての柔軟性、拡張性、セキュリティーの担保、そしていいUI/UXの実現が以前より大幅に複雑度を下げることが可能になってきた
端的には、最近のLLMの大幅な進化は、大規模なシステム開発プロジェクトでUI/UXデザインを考慮した拡張性のあるシステム開発をより現実的なものにしている
アプリケーションのアーキテクチャー設計とUI設計の統合がよりやり易くなって、大規模システムへの適用を担当するエンジニアやデザイナーの負荷を下げることができ、ある種の標準化が可能なのではないかと期待している。
このプロセスや手法が標準化されると、デザインとテクノロジーの融合は単にモバイルアプリ開発やウェブシステムのフロントエリアの再現や実装だけに留まらない。ある程度の規模のシステム開発においても再現性をもって実現可能なプロセスにでき、適用エリアも大幅に広がると考えている。
デジタルサービス開発と生成AIの進化
デジタルサービス開発領域が、大手SIerが得意としている基幹システム領域と違うのは、その対象の多くが顧客接点(フロントシステム)系のシステムか、業務システム領域で、他社との差別化要素(攻めのDXの領域)が大きい。
企業側を主語にすると開発部門の内製化を進めているのは主にこれらのエリアだ。これに付け加えるとすると、いわゆるモダナイゼーションの対象のシステムだ。現在、多くの企業では既存システムをクラウドシフトさせて、アーキテクチャー等の刷新（モダナイゼーション）をやろうとしているが、このエリアにおいてもこの手法は大いに役立つ。
上のような業務システムならびに顧客接点のフロント系のシステムの場合、通常、何が問題になるかというと、要求整理ならびに要件定義が必然的に複雑度が増す。理由は端的にToBEが定義しづらい、もしくはビジネス環境の変化により要求仕様の前提が大きく変わることがあるからだ。またこのエリアのシステムは概ね、以下のようなニーズを伴うことが多い
いいUI/UXにしたい(使い勝手のいいシステムにしたい)
変更に柔軟に耐えられるシステムにしたい
開発したシステムをSaaSのように横展開していきたい
これらの要求に応えて、エンタープライズ企業のある程度の規模のウェブシステムを開発する際には、以前は上流工程からデザイナーをアサインして、デザイナーは利用ユーザーの理解をするために、ドメイン知識や業務要件も深く理解することが求めれらた。
この際の大きな問題点としては、端的にデザイナーの負荷が高い、かつデザイナーには高い能力が求められる。かつデザイナーがどれだけ業務を理解をしても、システム開発のロジックとは異なるため、システムの実装に落とし込む際に色んな抜け漏れが発しがちになる。その為、ある種、デザイナーとエンジニアで要件定義を2回、回すようなイメージだった。
理想としてはUI/UXデザインを考慮できる優秀なSEをアサインできて、一発でUI/UXの考慮とシステム設計が行えるのが理想だが、現実世界において、残念ながら世の中にそんな優秀な人材は決して多くはない。
ましてやモバイルアプリだけでなく、大規模なシステムになればなるほど、複雑度が増すために、エンジニア、デザイナーの両方に、大規模なシステムの要件を整理し、いいUI/UXデザインを考慮し、拡張性のあるアーキテクチャー設計を実現するのは色んな意味でハードルが高い。
当社にとっても、これは組織の拡張ならびに人材のオンボーディングを設計する上でも長年の課題だった。
これらの問題に対応するために、当社ではこれまでは開発プロセスやデザインプロセスの整備で行ってきたが、対象となるプロジェクト規模が大きくなるに連れて、それでも限界を感じていた。それが、ここにきて生成AIの進化が劇的に我々の開発プロセスにも変化をもたらそうとしている。これを従来の手法に掛け合わせると、大規模システムにも応用できる標準化プロセスができそうな未来が見えてきた。
AI駆動開発の現在と今後
2025年は明らかにAI駆動開発元年で、色んな会社が開発プロセスに何らかの生成AIならびにAIエージェントを導入し始めている。当社でも社内での積極的なR&Dの経験をベースにした実践的なAI駆動開発支援を実施している。
AI駆動開発を実践もしくは導入をしている企業の多くは、SaaS企業等の自社のプロダクト開発への適用で、受託開発エリアはまだ限られているように見えている。これは単純にエンタープライズマーケットでのシステム開発は制限が多く、実行に移せていない企業が多い為だろう。
一方で、当社でも各クライアント話をしている中で見えてきているのは、積極的に開発プロセスにAIを組み込んでいる企業とそうでない企業とで同じシステム開発といっても見えている世界が変わってきているということだ。
恐らく近い将来、人月工数という概念がよく分からない日が来るのではないかとも考えている。これについては別途記事を纏めたい考えている。
そんな中、我々が見えている世界は、生成AIを使えばどの企業でもAI駆動開発が同じレベルでできる訳ではない。個人レベルのVibeコーディングの情報は世の中に多く出てきているが、エンタープライズ領域でAI駆動開発を行うためには、品質、セキュリティー等を考慮したアウトプットのコントロールが重要になってくる。
いわゆるガードレールの整備(社内ではこれを鰻のタレと言っているが、実際のプロジェクトを通しての経験値の蓄積)の成熟度が、各社のAI駆動開発のレベルを大きく分けて行くと想像している。
AI駆動開発によるシステム開発の変革は始まったばかりだ。デジタルサービス開発領域において、我々はAI駆動開発のトップランナーを担いたいと考えている。
