🐈‍⬛

生成ai時代によるチーム小人数化の懸念をDevExチームで対策するという仮説

に公開
1

概要

想定読者:

  • 生成AI等により、一つ一つの開発組織の組織体制がどのようになるのかと考えたり気になってる同志

想定読者ではないかもです😭:

  • 生産性を上げれる生成AIの種類等を詳しく知りたい方:開発組織形成に関するこれからの仮説でありますため、具体的な生成aiに関してはスコープ外としております🙇

結論


経緯

  • 今「生成aiによる1事業に割り当てる開発チームの縮小化」が急速に進んでいる。
    と言うのも、生成aiによる開発生産性向上により少人数での開発が可能になっている。
  • これらを踏まえて多くの方・及び会社で導入されつつあるのが一事業あたりの開発チーム体制のミニマム化である。
  • これまで3~10人以下と言われているスクラムチームに生成aiというアプローチが変わってくると考えている。
  • よく言われているのは「1事業3人チーム制」のような状態になるのではと言われている。
  • 従来ならば、事業エンジニアが3人レベルはスタートアップ期だったりだったのが、民主的になるのではないかという意見。
  • この時流は生成aiの成長に伴って然るべき流れ、賛成!だと思いつつ、ふと「リカバリが難しくならないか?」という懸念が浮かんだのでこの懸念を整理しつつ、仮説的に対策案も策定する。

スクラムチームは、敏捷性を維持するための⼗分な⼩ささと、スプリント内で重要な作業を完
了するための⼗分な⼤きさがあり、通常は 10 ⼈以下である。⼀般的に⼩さなチームのほうがコ
ミュニケーションがうまく、⽣産性が⾼いことがわかっている。

https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
https://note.com/gimupop/n/nd164cfdf7652#8d6afe2a-166e-436e-9b22-63484a196283
https://enablex-inc.com/insight/0000008/


イメージ付け:数字遊び

従来とこれからを数値的に表せる例を作成してみる。


  • メンバー構成は一番可能性の高い定義を採用
    • 従来6人:PO,スクラムマスター,バック×2,フロントエンド,QA
    • これから3人:PO及びスクラムマスターを全員で兼業(一人が便宜的責任者),バック及びフロントエンドを全員で兼業(一人が便宜的責任者), QAを全員で兼業(一人が便宜的責任者), ※生成aiによるアプローチを前提
  • メンバーが出す利益を個人成果利益とコラボレーション利益に分解
    • 個人成果利益:個人によって創出する事業利益(コードをかく、QA検証を行う etc)
    • コラボレーション利益:他者の能力を増幅させることによって創出する事業利益(レビュー依頼対応、ナレッジ作成、チーム内でのコミュニケーション促進 etc)
  • 個人成果利益:Max 1、平均 0.5〜0.7
  • コラボレーション利益:重み w × Σ個人成果、wは0.1〜2

従来とこれからは計算が以下のようになるのではないかと考えている。
あくまで思考としての計算例だが、生成aiによる個人及びチームでの生産性増加で6人で出す利益と近しい利益を出しうる状態に近いうちなる(一部の新規事業チームはこの状態になっている)と考えている。

  • 従来
    • 個人成果利益:Max 1、平均 0.5
    • コラボレーション利益(主に人):重み w × Σ個人成果、wは0.1〜2:平均1
  • これから
    • 個人成果利益:Max 2、平均 0.7
      • 生成aiによる個人パフォーマンス増加
    • コラボレーション利益(主に人及び生成ai):重み w × Σ個人成果wは0.5〜3:平均1
      • 生成ai及び人数が減少でコミュニケーション複雑度が減少することによるコラボレーション利益増加
  • 計算例(wを一定と仮定した場合)
    • 6人:Σ個人=3、w=0.75 → 総計=3+3×0.75=5.25
      • wは基本1で、1.5(増幅させてくれる人)と、0.5(個人プレーが目立つ人)で0.75
    • 3人:Σ個人=2.1、w=1.4 → 総計=2.1+2.1×1.4=5.04
      • wは基本1で、2(生成aiによりさらに強化された増幅させてくれる人)と、0.75(個人プレーが目立つが生成aiにより緩和された人)で1.4

画一的な訳はないのであくまで「スタートアップ関係なく、生成aiにより少人数でも事業利益を出すチームが成立する」というのを数字で表現してみた。
ただここで以下の懸念があると思う。


懸念 — 「メンバーが減少する」事象による生産性低下割合が増加するのでは?

この懸念は「メンバー減ったらリカバリコスト増えるのでは?」という懸念だが、
先ほどの例を利用して同様に数字化してみる。
先述の通り数字遊びの領域であるので実測値ではないが、どのパターンでも一人減ることによるダメージが大きくなるというのが言いたいこと。


  • 人が辞めるということは、以下3パターン実施

    • 1.個人成果を単純に引き算
    • 2.総利益/Nを単純に引き算
    • 3.個人成果を単純に引き算かつ、重みを人数増加に対して減少させてさらに引き算
  • パターン1:個人成果を単純に引き算:

    • 従来6人:5.25→4.375で0.5減少
    • 従来5人に減少:5.25-0.5 = 4.25
    • これから3人:5.04→3.36で0.7減少
    • これから2人に減少:5.04-0.7 = 4.34
  • パターン2:総利益/Nを単純に引き算:

    • 従来6人:5.25→4.375で0.875減少
    • 従来5人に減少:5.25-6(5.25) = 4.375
    • これから3人:5.04→3.36で1.68減少
    • これから2人に減少:5.04-3(5.04) = 3.36
  • パターン3:個人成果を単純に引き算かつ、重みを人数増加に対して減少させてさらに引き算

    • 前提:関係数 E(N)=N(N-1)/2 に比例して 重みwがスケールすると定義
      • w' = w × E(N-1)/E(N) = w × (N-2)/N
    • 結果:
    • 従来6人:5.25→3.75で1.5減少
    • 従来5人に減少:5.25-0.5(単純利益減少)-{(3-0.5)×0.75×(4/6)(コラボレーション利益減少} = 3.75
    • これから3人:5.04→2.05で2.99減少
    • これから2人に減少:5.04-0.7(単純利益減少)-{(2.1-0.7)×1.4×(1/3)(コラボレーション利益減少} = 2.05

しかし経緯に記載した通り、一事業に対するエンジニア少人数制の時流は止まらず民主化すると思う。
その前提の上で対策を考えたい。


対策 — DevExチームの重要性とジョブ範囲の変更によるアプローチ

もちろん規模やアクシデントが起きたロールにもよるが、
DevExチームの重要性とジョブ範囲 がポイントとなってくる。

4要素に分けてみた。

促進:生成ai駆動による最新体制整備による最適化

  • これまでも最適化が必要なのは変わらないが、近年の最新技術の移り変わりは異常なスピードである。
  • このスピードへのキャッチアップ及び業務運用レベルでの整備をテックリードを中心とした開発メンバーが開発を行いながらするのは負担が大きくなる。故にDevExチームによる最適化がより効力を発揮する。

維持:他チームないしメンバーのキャッチアップがやりやすい生成aiコラボレーション環境の整備

  • こちらは、生成aiによるコラボレーション利益をチーム内だけの暗黙知の状態で利用しているか、他メンバーが入った時に享受できる形式知として利用しているかの観点
  • マンパワーで押し切っていたツケがこれまでよりクリティカルになるこれからは、暗黙知→形式知に落とし込めているかがより重要になる
  • 従来体制でも重要であることは分かりきっているのに暗黙知化するのは、シンプルに当事者的には何の利益もない短期的に見れば業務の負荷増加であるため。責任範囲を明確に分けて他者視点で整備されているという環境にしておかなければならない。

促進:平常時のスポット参加を通したジョブローテ整備によるチーム間知見の促進

  • これまで以上にジョブローテが重要になってくると思う。
  • 上述二つで形式知にするまでの流れができているので、形式知をもしもの時に他チームメンバーが利用できるようにするため
  • もちろん属人化解消のみならず視点の増加等、ジョブローテによる長期的観点での利益は大きい
  • ただ短期的な事業利益という観点では中々業務を離せずジョブローテを本格的に実践までには移せない
  • この経緯を把握した上でDevExチームとして、ジョブローテによる長期的利益を享受できるようにやり切る重要性が増してくる

維持:メンバー減少時支援・実行による人的工数カバー

  • これら3つをやったとしても人が欲しい!でも他チームも手を離せない!っていうような超イレギュラーが発生しうる。なぜなら6→5か3→2かなシンプルにチーム内でカバー不可能の可能性が大きくなるからだ。
  • 外から募集もするがどうするか...という時に助っ人要素として、DevExチームのメンバーが実行責任を持てる準備はする必要があると考えている
  • この最終プランがDevExにおけるジョブ定義の変更と判断している箇所である。DevExチーム自身も支援に徹する原則と、もしもの時の実行責任を負える胆力を備え持つ必要性が生じると考えている。

体制案

これから

  • これから、一概には言えないが確実に少人数で事業を成立させる時代がくる。
  • ただ一方で一人一人の生み出す事業利益も増えるということである。
  • それは生成aiとの掛け算が為した結果であり、人がいなくなった状態で生成aiがひとりでに生み出せる時代ではまだない。
  • だとしたら「人の増減」の一発一発がこれまでより重くなることへのアプローチが必要であり、このアプローチを担うのはDevExチームになるのではないかと考えている。
  • 生成aiとの共存によりどのように利益創出を爆発的に増やすかと、
    この大きな変更によるリスクカバーができる体制の両立をどのようにするかが、
    これからの開発組織体制における重要な議論点であるので、継続して最適解を考えたい。

参考資料

https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
https://note.com/gimupop/n/nd164cfdf7652#8d6afe2a-166e-436e-9b22-63484a196283
https://enablex-inc.com/insight/0000008/
https://engineering.mercari.com/blog/entry/20250624-building-a-company-wide-framework-for-improving-devex-in-mercari-group/

Discussion