取締役兼ACS事業部長の上林です。
生成AIによるAI駆動開発・AI Powerd DevOpsなどの概念が出現してきたことにより、開発のスタイルはもちろん、開発組織自体も大きく変革を迎えようとしております。その未来予測をしてみたいと思います。
生成AI登場により変化するBizDevOpsの開発チーム（Stream Alignedチーム）
一番大きな変化として予想されるのが、これはすでにこういった海外のblogでも言われていますが、開発チーム（Stream Alignedチーム）の編成自体が大きく変わるということです。これまでは高速な開発(FastFlow)を実現するために、いわゆる2ピザチームが一単位となる考えでした。外部の力を借りずに開発タスクをコンプリートするため、8名程度のクロスファンクションなスキルを持ったメンバーで構成されたチームです。
ここが上級エンジニア2名で編成するペアチームになっていくこと予想されます。上級エンジニアをここでは事業ドメインとシステムアーキテクチャーがわかるエンジニアと粗く定義します
これは直感としても理解頂けるのではないでしょうか。生成AIによりコーディング部分は自動化され、開発チームの代わりに大量のコードが作れるフィジビリティが生まれています。その為「なにを作るか」がより重要になり、さらに生成AIのアウトプット品質をチェックできる「アーキテクチャー視点のスキル」を保有する上級SEが重要になってきます。そして人間ですので、話し相手や病欠時の補完関係は必要です。ですので2ペアチームが効率的ということになります。この概念に基づいてもう少し未来予測を深堀りしていきたいと思います。
チームの分割による「開発デュオ」の増加による福音
仮に6名の開発者が生成AIの力を活用できることになり、新しく再編されるとなると2人ペアの開発チーム(以下仮称開発デュオとします)が3つになることになります。
ちなみに、6名のタスクを2名で代替されるのであれば、残り4人はリストラされる可能性はないのでしょうか？ 個人的には日本においてはそうはならないと考えています。私の見聞きする限り、価値の探索も含めた企業の開発のバックログは大量に存在し、消化されてないというのが現状です。また、日本の法律では雇用の継続が前提となりますので、退職パッケージなどが出せる大手企業でない限りは基本的には開発者のみなさんに新たな業務を作っていく方向になると想定しています（なお外注の場合、契約終了の可能性はあり、我々含めた開発のSIを行うベンダー・個人事業主は大きなリスクとして捉えるべきかなとも考えています）。
話を戻すと、仮に単純計算で3倍の生産性を出せるのであれば、先ほども書いた通りバックログを多く抱えた企業にとってはROIが高まるわけで、これは福音となります。しかしながら、これはSRE、Platformチームなど開発を支える側のチームにとっては悪夢とも言えます。なぜならば開発チームとのコミュニケーションパスが劇的に増加するからです。
コミュニケーションパスの圧倒的増加による悪夢
もともとのTeam Topologiesの考えでもありますがチーム(デュオ)が増えるということは、チーム間の連携の為のコミュニケーションも増えることになります。開発チーム間の連携はシステムに反映されますので、逆コンウェイ戦略の通り作りたいシステムのアプリ間の境界の定義と、それに合わせたチーム(デュオ)とチームの間のコミュニケーションを検討していく必要があります。これ自体はこれまでのTeam Topologiesの考え方と変わりません。
しかし、そのコミュニケーションパスはあまりに大量にできるので、それを削減するため、一定数のアプリケーションチームをまとめる「小ユニット」が新たなStream Alignedチームのような存在になるのかもしれません。そうなると、Team Topologies自体が一定のアップデートを行わなければならなそうです。
そしてそれ以上に問題になるのは、開発側とSREやPlatformチームなど開発を支援するチーム側とのコミュニケーションパスです。
今まで1つだったパスが3つに増えるということになります。例えば10チームある開発組織であれば、100あったパスが300になるわけで200のコミュニケーションパスが増えるということになります。もちろん単純計算通りパスが増えるわけではなく、上記のように一定のまとまりである「小ユニット(開発デュオのひとまとまり)」が管理のまとまりになる可能性は高いとは思います。
そうなったとしても、開発デュオそれぞれに自律性を認める場合、SREやPlatformチームとのパスはやはり激増します。その場合、このパスに応じて、問い合わせ・依頼などが殺到することも予想されます。また新たに作られる開発デュオは全員が上級SEというわけにはいかず、スキルにもばらつきがあり、そのチームの様々なレベルに合わせてPlatformやセキュリティについて検討していく必要があります。これこそがSRE・Platformチームにとっての悪夢ではないでしょうか。
対策としてのPlatform Engineering
では対策としてはなにが考えられるでしょうか？
まず一つに、SREやPlatformチームなどの支援側も生成AIを適用するから同じように楽になるのでは、という考えがあると思います。しかしながら、現在の流れで見てもインフラ側の業務も生成AIで楽になる部分はあるものの、開発と同じレベルで代替することは少し時間がかかりそうです(これだけで1トピックになるので今回は詳細は省きます)。
では、単純にSREを3倍にするアプローチはどうでしょうか？ これは難しそうです。コストもかかってしまいますし、そもそも育成も難しく、人材市場にも人材が不足しているため簡単に採用できるものでもありません。
となると、少ない人で対応できる状況を作ることが必要です。人が動くのではなくコンピュータが仕事をする自動化やその先のセルフサービス化はより重要になりますし、開発デュオ全体に対してSREやプラットフォームを提供していくのではなく、上記「小ユニット」ごとにSREやPlatformを標準化していくような動きも必要になるはずです。
必要なものをプロダクト的にPlatformとして提供し、セルフサービス化を行うことで、開発チームからの大量の依頼や問い合わせを開発側が自分自身で解決できる、そんな仕組みに変えていく必要があります。例えば、ChatBotとMCPサーバを連携させて、様々な問い合わせに対応することが考えられるでしょう。また、様々なスキルレベルの開発デュオに対応するため、リスキリング的なトレーニング、スキルが不足の場合でも対応可能なゴールデンパスの整備や、ガードレールをテンプレート化してPlatform提供していくことで企業全体のガバナンスを維持することも考えられます。
おわりに
いかがだったでしょうか。現在相談が増えつつあるAI駆動開発の開発体制を整えることを議論・検討していくうえで、Platform Engineeringは改めて重要な概念となってくると感じており、こんな未来像を描いてみました。思考実験レベルの話ではありますが、現在の流れから考えると一つの仮説としては成り立つかなと考えています。是非みなさんのご意見もうかがわせて頂けるとありがたいです。
ACS事業部のご紹介
私達ACS事業部はクラウドネイティブ技術、Azure AI サービス、Platform Engineering、AI駆動開発支援などを通して、攻めのDX成功に向けた開発者体験・開発生産性の向上・内製化のご支援をしております。
www.ap-com.co.jp
www.ap-com.co.jp
また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。
www.ap-com.co.jp
